Internet Protocol Suite – Wikipedia

before-content-x4

Satz von Kommunikationsprotokollen

Das Internet Protocol Suite ist das konzeptionelle Modell und der Satz von Kommunikationsprotokollen, die im Internet und ähnlichen Computernetzwerken verwendet werden. Es ist allgemein bekannt als TCP / IP denn die grundlegenden Protokolle in der Suite sind das Transmission Control Protocol (TCP) und das Internet Protocol (IP). Während seiner Entwicklung wurden Versionen davon als bekannt Verteidigungsministerium (DoD) Modell- weil die Entwicklung der Netzwerkmethode vom US-Verteidigungsministerium über DARPA finanziert wurde. Seine Implementierung ist ein Protokollstapel.

Die Internetprotokoll-Suite bietet eine End-to-End-Datenkommunikation, in der festgelegt wird, wie Daten paketiert, adressiert, gesendet, weitergeleitet und empfangen werden sollen. Diese Funktionalität ist in vier Abstraktionsschichten unterteilt, die alle zugehörigen Protokolle nach dem Umfang der Vernetzung klassifizieren.[1][2] Vom niedrigsten zum höchsten sind die Schichten die Verbindungsschicht, die Kommunikationsmethoden für Daten enthält, die in einem einzelnen Netzwerksegment (Verbindung) verbleiben. die Internetschicht, die das Internetworking zwischen unabhängigen Netzwerken ermöglicht; die Transportschicht, die die Kommunikation von Host zu Host handhabt; und die Anwendungsschicht, die einen Datenaustausch von Prozess zu Prozess für Anwendungen bereitstellt.

Die technischen Standards, die der Internetprotokollsuite und ihren Protokollen zugrunde liegen, werden von der Internet Engineering Task Force (IETF) verwaltet. Die Internetprotokollsuite ist älter als das OSI-Modell, ein umfassenderes Referenzframework für allgemeine Netzwerksysteme.

Geschichte[edit]

Frühe Forschung[edit]

Diagramm der ersten Internetverbindung

Die Internetprotokollsuite entstand aus Forschungen und Entwicklungen, die Ende der 1960er Jahre von der Defense Advanced Research Projects Agency (DARPA) durchgeführt wurden.[3] Nach der Initiierung des wegweisenden ARPANET im Jahr 1969 begann DARPA mit der Arbeit an einer Reihe anderer Datenübertragungstechnologien. Im Jahr 1972 wechselte Robert E. Kahn zum DARPA Information Processing Technology Office, wo er sowohl an Satellitenpaketnetzen als auch an bodengestützten Funkpaketnetzen arbeitete und den Wert der Fähigkeit erkannte, über beide zu kommunizieren. Im Frühjahr 1973 arbeitete Vinton Cerf, der an der Entwicklung des bestehenden NCP-Protokolls (ARPANET Network Control Program) beteiligt war, gemeinsam mit Kahn an Verbindungsmodellen mit offener Architektur, um die nächste Protokollgeneration für ARPANET zu entwerfen.[citation needed] Sie stützten sich auf die Erfahrungen der ARPANET-Forschungsgemeinschaft und der International Networking Working Group, deren Vorsitzender Cerf war.[4]

Bis zum Sommer 1973 hatten Kahn und Cerf eine grundlegende Neuformulierung ausgearbeitet, bei der die Unterschiede zwischen lokalen Netzwerkprotokollen durch Verwendung eines gemeinsamen Netzwerkprotokolls verborgen wurden und statt wie bei den vorhandenen ARPANET-Protokollen das Netzwerk für die Zuverlässigkeit verantwortlich ist wurde diese Funktion an die Hosts delegiert. Cerf schreibt Hubert Zimmermann und Louis Pouzin, Designer des CYCLADES-Netzwerks, wichtige Einflüsse auf dieses Design zu.[5][6] Das neue Protokoll wurde 1974 als Übertragungssteuerungsprogramm implementiert.[7]

Ursprünglich verwaltete das Übertragungssteuerungsprogramm sowohl die Übertragung von Datagrammen als auch das Routing. Mit zunehmender Erfahrung mit dem Protokoll empfahlen die Mitarbeiter jedoch, die Funktionalität in Schichten unterschiedlicher Protokolle zu unterteilen. Zu den Befürwortern gehörte Jonathan Postel vom Information Sciences Institute der University of Southern California, der die Request for Comments (RFCs) herausgab, die technische und strategische Dokumentenserie, die die Internetentwicklung sowohl dokumentiert als auch katalysiert hat.[8] und die Forschungsgruppe von Robert Metcalfe bei Xerox PARC.[9][10] Postel erklärte: “Wir vermasseln unser Design von Internetprotokollen, indem wir gegen das Prinzip der Schichtung verstoßen.”[11] Die Kapselung verschiedener Mechanismen sollte eine Umgebung schaffen, in der die oberen Schichten nur auf das zugreifen konnten, was von den unteren Schichten benötigt wurde. Ein monolithisches Design wäre unflexibel und würde zu Skalierbarkeitsproblemen führen. In Version 3 von TCP, die 1978 geschrieben wurde, wurde das Übertragungssteuerungsprogramm in zwei unterschiedliche Protokolle aufgeteilt, das Internetprotokoll als verbindungslose Schicht und das Übertragungssteuerungsprotokoll als zuverlässiger verbindungsorientierter Dienst.[12]

Das Design des Netzwerks beinhaltete die Erkenntnis, dass es nur die Funktionen zum effizienten Übertragen und Weiterleiten von Verkehr zwischen Endknoten bereitstellen sollte und dass sich alle anderen Informationen am Rand des Netzwerks in den Endknoten befinden sollten. Dieses Design wird als End-to-End-Prinzip bezeichnet. Mit diesem Design wurde es möglich, andere Netzwerke mit dem ARPANET zu verbinden, die unabhängig von anderen lokalen Merkmalen dasselbe Prinzip verwendeten, wodurch Kahns anfängliches Internetworking-Problem gelöst wurde. Ein beliebter Ausdruck ist, dass TCP / IP, das spätere Produkt von Cerf und Kahn, über “zwei Blechdosen und eine Schnur” laufen kann.[citation needed] Jahre später wurde als Scherz die formale Protokollspezifikation IP over Avian Carriers erstellt und erfolgreich getestet.

DARPA beauftragte BBN Technologies, die Stanford University und das University College London mit der Entwicklung von Betriebsversionen des Protokolls auf mehreren Hardwareplattformen.[13] Während der Entwicklung des Protokolls stieg die Versionsnummer der Paketroutingschicht von Version 1 auf Version 4, die 1983 im ARPANET installiert wurde Internetprotokoll Version 4 (IPv4) als das Protokoll, das neben seinem aktuellen Nachfolger, Internet Protocol Version 6 (IPv6), noch im Internet verwendet wird.

Frühzeitige Implementierung[edit]

1975 wurde ein TCP / IP-Kommunikationstest mit zwei Netzwerken zwischen Stanford und dem University College London durchgeführt. Im November 1977 wurde ein TCP / IP-Test mit drei Netzwerken zwischen Standorten in den USA, Großbritannien und Norwegen durchgeführt. Mehrere andere TCP / IP-Prototypen wurden zwischen 1978 und 1983 an mehreren Forschungszentren entwickelt.

Ein Computer, der als Router bezeichnet wird, verfügt über eine Schnittstelle zu jedem Netzwerk. Es leitet Netzwerkpakete zwischen ihnen hin und her.[14] Ursprünglich wurde ein Router aufgerufen TorDer Begriff wurde jedoch geändert, um Verwechslungen mit anderen Arten von Gateways zu vermeiden.[15]

Annahme[edit]

Im März 1982 erklärte das US-Verteidigungsministerium TCP / IP zum Standard für alle militärischen Computernetzwerke.[16] Im selben Jahr verabschiedeten die Forschungsgruppe von NORSAR und Peter Kirstein am University College London das Protokoll.[13][17][18] Die Migration des ARPANET zu TCP / IP wurde am Flaggentag 1. Januar 1983 offiziell abgeschlossen, als die neuen Protokolle dauerhaft aktiviert wurden.[19]

1985 veranstaltete das Internet Advisory Board (später Internet Architecture Board) einen dreitägigen TCP / IP-Workshop für die Computerindustrie, an dem 250 Vertreter von Anbietern teilnahmen, um das Protokoll zu fördern und zu einer zunehmenden kommerziellen Nutzung zu führen. 1985 konzentrierte sich die erste Interop-Konferenz auf die Netzwerkinteroperabilität durch eine breitere Einführung von TCP / IP. Die Konferenz wurde von Dan Lynch, einem frühen Internetaktivisten, gegründet. Von Anfang an nahmen große Unternehmen wie IBM und DEC an dem Treffen teil.[20]

IBM, AT & T und DEC waren die ersten großen Unternehmen, die TCP / IP eingeführt haben, obwohl sie über konkurrierende proprietäre Protokolle verfügten. In IBM hat die Gruppe von Barry Appelman ab 1984 die TCP / IP-Entwicklung durchgeführt. Sie navigierten durch die Unternehmenspolitik, um einen Stream von TCP / IP-Produkten für verschiedene IBM Systeme zu erhalten, einschließlich MVS, VM und OS / 2. Zur gleichen Zeit begannen mehrere kleinere Unternehmen wie FTP Software und die Wollongong Group, TCP / IP-Stacks für DOS und Microsoft Windows anzubieten.[21] Der erste VM / CMS-TCP / IP-Stack stammte von der University of Wisconsin.[22]

Einige der frühen TCP / IP-Stacks wurden von einigen Programmierern im Alleingang geschrieben. Jay Elinsky und Oleg Vishnepolsky [ru] von IBM Research schrieb TCP / IP-Stacks für VM / CMS bzw. OS / 2.[citation needed] 1984 schrieb Donald Gillies am MIT eine ntcp TCP mit mehreren Verbindungen, das auf der IP / PacketDriver-Schicht ausgeführt wurde, die von John Romkey 1983–4 am MIT verwaltet wurde. Romkey nutzte dieses TCP 1986, als FTP Software gegründet wurde.[23][24] Ab 1985 erstellte Phil Karn eine Mehrfachverbindungs-TCP-Anwendung für Amateurfunk-Systeme (KA9Q TCP).[25]

Die Verbreitung von TCP / IP wurde im Juni 1989 weiter vorangetrieben, als die University of California in Berkeley sich bereit erklärte, den für BSD UNIX entwickelten TCP / IP-Code öffentlich zugänglich zu machen. Verschiedene Unternehmensanbieter, einschließlich IBM, haben diesen Code in kommerzielle TCP / IP-Softwareversionen aufgenommen. Microsoft hat einen nativen TCP / IP-Stack in Windows 95 veröffentlicht. Dieses Ereignis hat dazu beigetragen, die Dominanz von TCP / IP gegenüber anderen Protokollen in Microsoft-basierten Netzwerken, einschließlich IBMs Systems Network Architecture (SNA), und auf anderen Plattformen wie DECnet von Digital Equipment Corporation, zu festigen. Open Systems Interconnection (OSI) und Xerox Network Systems (XNS).

In den späten 1980er und frühen 1990er Jahren waren Ingenieure, Organisationen und Nationen jedoch über die Frage polarisiert, welcher Standard, das OSI-Modell oder die Internetprotokollsuite zu den besten und robustesten Computernetzwerken führen würden.[26][27][28]

Formale Spezifikation und Standards[edit]

Die technischen Standards, die der Internetprotokollsuite und ihren Bestandsprotokollen zugrunde liegen, wurden an die Internet Engineering Task Force (IETF) delegiert.

Die charakteristische Architektur der Internet Protocol Suite ist ihre breite Unterteilung in Betriebsbereiche für die Protokolle, die ihre Kernfunktionalität bilden. Die definierende Spezifikation der Suite ist RFC 1122, die im Großen und Ganzen vier Abstraktionsschichten umreißt.[1] Diese haben sich bewährt, da die IETF diese Struktur nie verändert hat. Als solches Netzwerkmodell ist die Internet Protocol Suite älter als das OSI-Modell, ein umfassenderes Referenz-Framework für allgemeine Netzwerksysteme.

Wichtige architektonische Prinzipien[edit]

Konzeptioneller Datenfluss in einer einfachen Netzwerktopologie aus zwei Hosts (EIN und B.) durch eine Verbindung zwischen ihren jeweiligen Routern verbunden. Die Anwendung auf jedem Host führt Lese- und Schreibvorgänge so aus, als ob die Prozesse durch eine Art Datenleitung direkt miteinander verbunden wären. Nach dem Einrichten dieser Pipe sind die meisten Details der Kommunikation vor jedem Prozess verborgen, da die zugrunde liegenden Kommunikationsprinzipien in den unteren Protokollschichten implementiert sind. In Analogie erscheint die Kommunikation auf der Transportschicht als Host-zu-Host ohne Kenntnis der Anwendungsdatenstrukturen und der Verbindungsrouter, während auf der Internetworking-Schicht einzelne Netzwerkgrenzen an jedem Router durchlaufen werden.

Kapselung von Anwendungsdaten, die durch die in beschriebenen Ebenen absteigen RFC 1122

Das End-to-End-Prinzip hat sich im Laufe der Zeit weiterentwickelt. Sein ursprünglicher Ausdruck brachte die Aufrechterhaltung des Zustands und der allgemeinen Intelligenz an die Ränder und nahm an, dass das Internet, das die Ränder verband, keinen Zustand behielt und sich auf Geschwindigkeit und Einfachheit konzentrierte. Die realen Anforderungen an Firewalls, Netzwerkadressübersetzer, Webinhalts-Caches und dergleichen haben Änderungen in diesem Prinzip erzwungen.[29]

Das Robustheitsprinzip besagt: “Im Allgemeinen muss eine Implementierung in ihrem Sendeverhalten konservativ und in ihrem Empfangsverhalten liberal sein. Das heißt, sie muss vorsichtig sein, wohlgeformte Datagramme zu senden, muss jedoch jedes Datagramm akzeptieren, das sie interpretieren kann ( z. B. keine Einwände gegen technische Fehler, bei denen die Bedeutung noch klar ist). “[30] “Der zweite Teil des Prinzips ist fast genauso wichtig: Software auf anderen Hosts kann Mängel enthalten, die es unklug machen, legale, aber unklare Protokollfunktionen auszunutzen.”[31]

Die Kapselung wird verwendet, um die Abstraktion von Protokollen und Diensten bereitzustellen. Die Kapselung ist normalerweise auf die Aufteilung der Protokollsuite in Schichten allgemeiner Funktionalität ausgerichtet. Im Allgemeinen verwendet eine Anwendung (die höchste Ebene des Modells) eine Reihe von Protokollen, um ihre Daten über die Ebenen zu senden. Die Daten werden auf jeder Ebene weiter eingekapselt.

Ein frühes Architekturdokument, RFC 1122betont architektonische Prinzipien über Schichtung.[32]RFC 1122betitelt Host-Anforderungen, ist in Absätzen strukturiert, die sich auf Ebenen beziehen, aber das Dokument bezieht sich auf viele andere Architekturprinzipien und betont nicht die Überlagerung. Es definiert lose ein Vier-Ebenen-Modell, wobei die Ebenen Namen und keine Zahlen wie folgt haben:

  • Die Anwendungsschicht ist der Bereich, in dem Anwendungen oder Prozesse Benutzerdaten erstellen und diese Daten an andere Anwendungen auf einem anderen oder demselben Host übertragen. Die Anwendungen nutzen die Dienste, die von den zugrunde liegenden unteren Schichten bereitgestellt werden, insbesondere die Transportschicht, die zuverlässig oder unzuverlässig ist Rohre zu anderen Prozessen. Die Kommunikationspartner zeichnen sich durch die Anwendungsarchitektur aus, z. B. das Client-Server-Modell und das Peer-to-Peer-Netzwerk. Dies ist die Schicht, in der alle Anwendungsprotokolle wie SMTP, FTP, SSH, HTTP ausgeführt werden. Prozesse werden über Ports angesprochen, die im Wesentlichen Dienste darstellen.
  • Die Transportschicht führt Host-zu-Host-Kommunikation entweder im lokalen Netzwerk oder in Remote-Netzwerken durch, die durch Router getrennt sind.[33] Es bietet einen Kanal für die Kommunikationsanforderungen von Anwendungen. UDP ist das grundlegende Transportschichtprotokoll, das einen unzuverlässigen verbindungslosen Datagrammdienst bereitstellt. Das Transmission Control Protocol bietet Flusskontrolle, Verbindungsaufbau und zuverlässige Datenübertragung.
  • Die Internetschicht tauscht Datagramme über Netzwerkgrenzen hinweg aus. Es bietet eine einheitliche Netzwerkschnittstelle, die die tatsächliche Topologie (Layout) der zugrunde liegenden Netzwerkverbindungen verbirgt. Es ist daher auch die Schicht, die das Internetworking etabliert. In der Tat definiert und etabliert es das Internet. Diese Schicht definiert die Adressierungs- und Routingstrukturen, die für die TCP / IP-Protokollsuite verwendet werden. Das primäre Protokoll in diesem Bereich ist das Internetprotokoll, das IP-Adressen definiert. Seine Funktion beim Routing besteht darin, Datagramme zum nächsten Host zu transportieren, der als IP-Router fungiert und die Konnektivität zu einem Netzwerk hat, das näher am endgültigen Datenziel liegt.
  • Die Verbindungsschicht definiert die Netzwerkmethoden im Rahmen der lokalen Netzwerkverbindung, über die Hosts kommunizieren, ohne dass Router eingreifen. Diese Schicht enthält die Protokolle, die zur Beschreibung der lokalen Netzwerktopologie und der Schnittstellen verwendet werden, die zur Beeinflussung der Übertragung von Datagrammen der Internetschicht an Hosts des nächsten Nachbarn erforderlich sind.

Verbindungsschicht[edit]

Die Protokolle der Verbindungsschicht arbeiten im Rahmen der lokalen Netzwerkverbindung, an die ein Host angeschlossen ist. Dieses Regime heißt das Verknüpfung im TCP / IP-Sprachgebrauch und ist die unterste Komponentenschicht der Suite. Der Link enthält alle Hosts, auf die zugegriffen werden kann, ohne einen Router zu durchlaufen. Die Größe der Verbindung wird daher durch das Netzwerkhardware-Design bestimmt. Im Prinzip ist TCP / IP hardwareunabhängig und kann auf praktisch jeder Link-Layer-Technologie implementiert werden. Dies umfasst nicht nur Hardware-Implementierungen, sondern auch virtuelle Verbindungsebenen wie virtuelle private Netzwerke und Netzwerktunnel.

Die Verbindungsschicht wird verwendet, um Pakete zwischen den Schnittstellen der Internetschicht von zwei verschiedenen Hosts auf derselben Verbindung zu verschieben. Die Prozesse zum Senden und Empfangen von Paketen auf der Verbindung können im Gerätetreiber für die Netzwerkkarte sowie in der Firmware oder durch spezielle Chipsätze gesteuert werden. Diese führen Funktionen wie das Framing aus, um die Pakete der Internetschicht für die Übertragung vorzubereiten und schließlich die Rahmen an die physikalische Schicht und über ein Übertragungsmedium zu übertragen. Das TCP / IP-Modell enthält Spezifikationen für die Übersetzung der im Internetprotokoll verwendeten Netzwerkadressierungsmethoden in Adressen der Verbindungsschicht, z. B. MAC-Adressen (Media Access Control). Alle anderen Aspekte unterhalb dieser Ebene werden jedoch implizit als vorhanden angenommen und im TCP / IP-Modell nicht explizit definiert.

Die Verbindungsschicht im TCP / IP-Modell hat entsprechende Funktionen in Schicht 2 des OSI-Modells.

Internetschicht[edit]

Für das Internetworking müssen Daten vom Quellnetzwerk an das Zielnetzwerk gesendet werden. Dieser Prozess wird als Routing bezeichnet und durch Hostadressierung und -identifizierung mithilfe des hierarchischen IP-Adressierungssystems unterstützt. Die Internetschicht bietet eine unzuverlässige Datagrammübertragungsfunktion zwischen Hosts in potenziell unterschiedlichen IP-Netzwerken, indem Datagramme an einen geeigneten Next-Hop-Router zur weiteren Weiterleitung an sein Ziel weitergeleitet werden. Die Internetschicht hat die Verantwortung, Pakete über potenziell mehrere Netzwerke zu senden. Mit dieser Funktionalität ermöglicht die Internetschicht das Internetworking, das Zusammenspiel verschiedener IP-Netzwerke und baut im Wesentlichen das Internet auf.

Die Internetschicht unterscheidet nicht zwischen den verschiedenen Transportschichtprotokollen. IP überträgt Daten für eine Vielzahl verschiedener Protokolle der oberen Schicht. Diese Protokolle sind jeweils durch eine eindeutige Protokollnummer gekennzeichnet: Beispielsweise sind das Internet Control Message Protocol (ICMP) und das Internet Group Management Protocol (IGMP) die Protokolle 1 bzw. 2.

Das Internetprotokoll ist die Hauptkomponente der Internetschicht und definiert zwei Adressierungssysteme, um Netzwerkhosts zu identifizieren und im Netzwerk zu lokalisieren. Das ursprüngliche Adressensystem des ARPANET und seines Nachfolgers, des Internets, ist Internet Protocol Version 4 (IPv4). Es verwendet eine 32-Bit-IP-Adresse und kann daher ungefähr vier Milliarden Hosts identifizieren. Diese Einschränkung wurde 1998 durch die Standardisierung von Internet Protocol Version 6 (IPv6) beseitigt, die 128-Bit-Adressen verwendet. IPv6-Produktionsimplementierungen wurden ungefähr 2006 eingeführt.

Transportschicht[edit]

Die Transportschicht erstellt grundlegende Datenkanäle, die Anwendungen für den aufgabenspezifischen Datenaustausch verwenden. Die Schicht stellt eine Host-zu-Host-Konnektivität in Form von End-to-End-Nachrichtenübertragungsdiensten her, die unabhängig vom zugrunde liegenden Netzwerk und unabhängig von der Struktur der Benutzerdaten und der Logistik des Informationsaustauschs sind. Die Konnektivität auf der Transportschicht kann entweder als verbindungsorientiert, in TCP implementiert oder verbindungslos, in UDP implementiert kategorisiert werden. Die Protokolle in dieser Schicht können eine Fehlerkontrolle, Segmentierung, Flusskontrolle, Überlastungskontrolle und Anwendungsadressierung (Portnummern) bereitstellen.

Um prozessspezifische Übertragungskanäle für Anwendungen bereitzustellen, legt die Schicht das Konzept des Netzwerkports fest. Dies ist ein nummeriertes logisches Konstrukt, das speziell für jeden Kommunikationskanal zugewiesen wird, den eine Anwendung benötigt. Für viele Arten von Diensten sind diese Portnummern wurden so standardisiert, dass Client-Computer bestimmte Dienste eines Server-Computers ohne Beteiligung der Diensterkennung oder Verzeichnisdienste adressieren können.

Da IP nur eine bestmögliche Bereitstellung bietet, bieten einige Transportschichtprotokolle Zuverlässigkeit.

TCP ist ein verbindungsorientiertes Protokoll, das zahlreiche Zuverlässigkeitsprobleme bei der Bereitstellung eines zuverlässigen Bytestreams behebt:

  • Daten kommen in der richtigen Reihenfolge an
  • Daten haben minimale Fehler (dh Korrektheit)
  • doppelte Daten werden verworfen
  • verlorene oder verworfene Pakete werden erneut gesendet
  • Beinhaltet die Kontrolle von Verkehrsstaus

Das neuere Stream Control Transmission Protocol (SCTP) ist ebenfalls ein zuverlässiger, verbindungsorientierter Transportmechanismus. Es ist nachrichtenstromorientiert, nicht bytestromorientiert wie TCP und bietet mehrere Streams, die über eine einzige Verbindung gemultiplext werden. Es bietet auch Multihoming-Unterstützung, bei der ein Verbindungsende durch mehrere IP-Adressen (die mehrere physische Schnittstellen darstellen) dargestellt werden kann, sodass bei einem Ausfall die Verbindung nicht unterbrochen wird. Es wurde ursprünglich für Telefonieanwendungen entwickelt (um SS7 über IP zu transportieren).

Zuverlässigkeit kann auch erreicht werden, indem IP über ein zuverlässiges Datenverbindungsprotokoll wie die High-Level Data Link Control (HDLC) ausgeführt wird.

Das User Datagram Protocol (UDP) ist ein verbindungsloses Datagrammprotokoll. Wie IP ist es ein unzuverlässiges Protokoll nach bestem Wissen und Gewissen. Die Zuverlässigkeit wird durch Fehlererkennung unter Verwendung eines Prüfsummenalgorithmus erreicht. UDP wird normalerweise für Anwendungen wie Streaming-Medien (Audio, Video, Voice over IP usw.) verwendet, bei denen eine pünktliche Ankunft wichtiger ist als Zuverlässigkeit, oder für einfache Abfrage- / Antwortanwendungen wie DNS-Lookups, bei denen der Aufwand für die Einrichtung von a zuverlässige Verbindung ist unverhältnismäßig groß. Das Echtzeit-Transportprotokoll (RTP) ist ein Datagrammprotokoll, das über UDP verwendet wird und für Echtzeitdaten wie Streaming Media ausgelegt ist.

Die Anwendungen an einer bestimmten Netzwerkadresse unterscheiden sich durch ihren TCP- oder UDP-Port. Konventionell sicher bekannte Häfen sind bestimmten Anwendungen zugeordnet.

Die Transport- oder Host-zu-Host-Schicht des TCP / IP-Modells entspricht in etwa der vierten Schicht im OSI-Modell, die auch als Transportschicht bezeichnet wird.

Anwendungsschicht[edit]

Die Anwendungsschicht enthält die Protokolle, die von den meisten Anwendungen zum Bereitstellen von Benutzerdiensten oder zum Austauschen von Anwendungsdaten über die Netzwerkverbindungen verwendet werden, die von den Protokollen niedrigerer Ebene hergestellt werden. Dies kann einige grundlegende Netzwerkunterstützungsdienste wie Protokolle für das Routing und die Hostkonfiguration umfassen. Beispiele für Protokolle auf Anwendungsebene sind das Hypertext Transfer Protocol (HTTP), das File Transfer Protocol (FTP), das Simple Mail Transfer Protocol (SMTP) und das Dynamic Host Configuration Protocol (DHCP).[34] Daten, die gemäß Protokollen der Anwendungsschicht codiert sind, werden in Protokolleinheiten der Transportschicht (wie TCP- oder UDP-Nachrichten) eingekapselt, die wiederum Protokolle der unteren Schicht verwenden, um die tatsächliche Datenübertragung zu bewirken.

Das TCP / IP-Modell berücksichtigt nicht die Besonderheiten der Formatierung und Darstellung von Daten und definiert keine zusätzlichen Schichten zwischen der Anwendungs- und der Transportschicht wie im OSI-Modell (Präsentations- und Sitzungsschicht). Solche Funktionen sind der Bereich von Bibliotheken und Anwendungsprogrammierschnittstellen.

Protokolle der Anwendungsschicht behandeln die Protokolle der Transportschicht (und niedriger) im Allgemeinen als Black Boxes, die eine stabile Netzwerkverbindung für die Kommunikation bereitstellen, obwohl die Anwendungen normalerweise die Schlüsselqualitäten der Verbindung der Transportschicht wie die IP-Adressen des Endpunkts und den Port kennen Zahlen. Protokolle der Anwendungsschicht sind häufig bestimmten Client-Server-Anwendungen zugeordnet, und allgemeine Dienste haben sehr bekannt Portnummern, die von der Internet Assigned Numbers Authority (IANA) reserviert wurden. Beispielsweise verwendet das HyperText-Übertragungsprotokoll den Serverport 80 und Telnet den Serverport 23. Clients, die eine Verbindung zu einem Dienst herstellen, verwenden normalerweise kurzlebige Ports, dh Portnummern, die nur für die Dauer der Transaktion zufällig oder aus einem bestimmten Bereich zugewiesen werden, der im Internet konfiguriert ist Anwendung.

Die Transportschicht und die Schichten der unteren Ebene sind nicht mit den Besonderheiten der Protokolle der Anwendungsschicht befasst. Router und Switches untersuchen normalerweise nicht den gekapselten Verkehr, sondern stellen lediglich eine Leitung dafür bereit. Einige Firewall- und Bandbreitendrosselungsanwendungen müssen jedoch Anwendungsdaten interpretieren. Ein Beispiel ist das Resource Reservation Protocol (RSVP). Manchmal ist es auch erforderlich, dass beim Durchlaufen des NAT (Network Address Translator) die Nutzdaten der Anwendung berücksichtigt werden.

Die Anwendungsschicht im TCP / IP-Modell wird häufig als äquivalent zu einer Kombination aus der fünften (Sitzung), sechsten (Präsentation) und der siebten (Anwendung) Schicht des OSI-Modells verglichen.

Darüber hinaus unterscheidet das TCP / IP-Modell zwischen Benutzerprotokolle und Unterstützungsprotokolle.[35] Support-Protokolle stellen Dienste für ein System der Netzwerkinfrastruktur bereit. Benutzerprotokolle werden für tatsächliche Benutzeranwendungen verwendet. Beispielsweise ist FTP ein Benutzerprotokoll und DNS ein Unterstützungsprotokoll.

Ebenennamen und Anzahl der Schichten in der Literatur[edit]

Die folgende Tabelle zeigt verschiedene Netzwerkmodelle. Die Anzahl der Schichten variiert zwischen drei und sieben.

RFC 1122Internet STD 3 (1989) Cisco Academy[36] Kurose,[37] Forouzan[38] Comer,[39] Kozierok[40] Hengste[41] Tanenbaum[42] Arpanet-Referenzmodell (RFC 871) OSI-Modell
Vier Schichten Vier Schichten Fünf Schichten Vier + eine Schicht Fünf Schichten Fünf Schichten Drei Schichten Sieben Schichten
“Internetmodell” “Internetmodell” “Fünf-Schichten-Internetmodell” oder “TCP / IP-Protokollsuite” “TCP / IP 5-Schicht-Referenzmodell” “TCP / IP-Modell” “TCP / IP 5-Schicht-Referenzmodell” “Arpanet Referenzmodell” OSI-Modell
Anwendung Anwendung Anwendung Anwendung Anwendung Anwendung Bewerbungsprozess Anwendung
Präsentation
Session
Transport Transport Transport Transport Host-to-Host oder Transport Transport Host zu Host Transport
Internet Internetwork Netzwerk Internet Internet Internet Netzwerk
Verknüpfung Netzwerkschnittstelle Datenverbindung Datenverbindung (Netzwerkschnittstelle) Netzwerkzugang Datenverbindung Netzwerkschnittstelle Datenverbindung
Körperlich (Hardware) Körperlich Körperlich Körperlich

Einige der Netzwerkmodelle stammen aus Lehrbüchern, bei denen es sich um sekundäre Quellen handelt, die im Widerspruch zur Absicht von stehen können RFC 1122 und andere IETF-Primärquellen.[43]

Vergleich der TCP / IP- und OSI-Schichtung[edit]

Die drei obersten Schichten im OSI-Modell, dh die Anwendungsschicht, die Präsentationsschicht und die Sitzungsschicht, werden im TCP / IP-Modell, das nur eine Anwendungsschicht über der Transportschicht aufweist, nicht getrennt voneinander unterschieden. Während einige reine OSI-Protokollanwendungen wie X.400 diese ebenfalls kombinierten, besteht keine Anforderung, dass ein TCP / IP-Protokollstapel eine monolithische Architektur über der Transportschicht auferlegen muss. Das NFS-Anwendungsprotokoll wird beispielsweise über das Präsentationsprotokoll eXternal Data Representation (XDR) ausgeführt, das wiederum über ein Protokoll namens Remote Procedure Call (RPC) ausgeführt wird. RPC bietet eine zuverlässige Datensatzübertragung, sodass der UDP-Transport mit dem besten Aufwand sicher verwendet werden kann.

Verschiedene Autoren haben das TCP / IP-Modell unterschiedlich interpretiert und sind sich nicht einig, ob die Verbindungsschicht oder das gesamte TCP / IP-Modell Probleme der OSI-Schicht 1 (physische Schicht) abdeckt oder ob eine Hardwareschicht unterhalb der Verbindungsschicht angenommen wird.

Mehrere Autoren haben versucht, die Schichten 1 und 2 des OSI-Modells in das TCP / IP-Modell zu integrieren, da diese in modernen Standards häufig verwendet werden (z. B. von IEEE und ITU). Dies führt häufig zu einem Modell mit fünf Schichten, wobei die Verbindungsschicht oder die Netzwerkzugriffsschicht in die Schichten 1 und 2 des OSI-Modells aufgeteilt wird.

Die Bemühungen zur Entwicklung des IETF-Protokolls befassen sich nicht mit strikten Schichten. Einige seiner Protokolle passen möglicherweise nicht sauber in das OSI-Modell, obwohl RFCs manchmal darauf verweisen und häufig die alten OSI-Schichtnummern verwenden. Die IETF hat wiederholt erklärt[citation needed] Die Entwicklung von Internetprotokollen und -architekturen soll nicht OSI-konform sein. RFC 3439In Bezug auf die Internetarchitektur enthält es einen Abschnitt mit dem Titel: “Schichtung als schädlich”.

Beispielsweise wird davon ausgegangen, dass die Sitzungs- und Präsentationsebenen der OSI-Suite in der Anwendungsschicht der TCP / IP-Suite enthalten sind. Die Funktionalität der Sitzungsschicht ist in Protokollen wie HTTP und SMTP zu finden und wird in Protokollen wie Telnet und dem Session Initiation Protocol (SIP) deutlicher. Die Funktionalität der Sitzungsschicht wird auch durch die Portnummerierung der TCP- und UDP-Protokolle realisiert, die die Transportschicht in der TCP / IP-Suite abdecken. Funktionen der Präsentationsschicht werden in den TCP / IP-Anwendungen mit dem MIME-Standard im Datenaustausch realisiert.

Konflikte treten auch im ursprünglichen OSI-Modell ISO 7498 auf, wenn die Anhänge zu diesem Modell nicht berücksichtigt werden, z. B. das ISO 7498/4 Management Framework oder die ISO 8648 Internal Organization of the Network Layer (IONL). Wenn die IONL- und Management Framework-Dokumente berücksichtigt werden, werden ICMP und IGMP als Schichtverwaltungsprotokolle für die Netzwerkschicht definiert. In gleicher Weise bietet die IONL eine Struktur für “subnetzwerkabhängige Konvergenzfunktionen” wie ARP und RARP.

IETF-Protokolle können rekursiv gekapselt werden, wie durch Tunnelprotokolle wie Generic Routing Encapsulation (GRE) gezeigt wird. GRE verwendet denselben Mechanismus wie OSI für das Tunneln auf Netzwerkebene.

Implementierungen[edit]

Die Internetprotokollsuite setzt keine bestimmte Hardware- oder Softwareumgebung voraus. Es ist lediglich erforderlich, dass Hardware- und Softwareschicht vorhanden sind, die Pakete in einem Computernetzwerk senden und empfangen kann. Infolgedessen wurde die Suite auf praktisch jeder Computerplattform implementiert. Eine minimale Implementierung von TCP / IP umfasst Folgendes: Internetprotokoll (IP), Adressauflösungsprotokoll (ARP), Internetsteuerungsnachrichtenprotokoll (ICMP), Übertragungssteuerungsprotokoll (TCP), Benutzerdatagrammprotokoll (UDP) und Internetgruppenverwaltung Protokoll (IGMP). Zusätzlich zu IP, ICMP, TCP, UDP erfordert Internet Protocol Version 6 NDP (Neighbor Discovery Protocol), ICMPv6 und IGMPv6 und wird häufig von einer integrierten IPSec-Sicherheitsschicht begleitet.

Anwendungsprogrammierer befassen sich normalerweise nur mit Schnittstellen in der Anwendungsschicht und häufig auch in der Transportschicht, während die folgenden Schichten Dienste sind, die vom TCP / IP-Stapel im Betriebssystem bereitgestellt werden. Die meisten IP-Implementierungen sind für Programmierer über Sockets und APIs zugänglich.

Zu den einzigartigen Implementierungen gehören Lightweight TCP / IP, ein Open Source-Stack für eingebettete Systeme, und KA9Q NOS, ein Stack und zugehörige Protokolle für Amateur-Paketfunksysteme und PCs, die über serielle Leitungen verbunden sind.

Die Mikrocontroller-Firmware im Netzwerkadapter behandelt normalerweise Verbindungsprobleme, die von der Treibersoftware im Betriebssystem unterstützt werden. Nicht programmierbare analoge und digitale Elektronik sind normalerweise für die physikalischen Komponenten unterhalb der Verbindungsschicht verantwortlich, wobei typischerweise ein anwendungsspezifischer ASIC-Chipsatz (Integrated Circuit) für jede Netzwerkschnittstelle oder einen anderen physikalischen Standard verwendet wird. Hochleistungs-Router basieren größtenteils auf schneller, nicht programmierbarer digitaler Elektronik, die eine Verbindung auf Verbindungsebene durchführt.

Siehe auch[edit]

Literaturverzeichnis[edit]

  • Douglas E. Comer. Internetworking mit TCP / IP – Prinzipien, Protokolle und Architektur. ISBN 86-7991-142-9
  • Joseph G. Davies und Thomas F. Lee. Microsoft Windows Server 2003 TCP / IP-Protokolle und -Dienste. ISBN 0-7356-1291-9
  • Forouzan, Behrouz A. (2003). TCP / IP Protocol Suite (2. Aufl.). McGraw-Hill. ISBN 978-0-07-246060-5.
  • Craig Hunt TCP / IP-Netzwerkadministration. O’Reilly (1998) ISBN 1-56592-322-7
  • Maufer, Thomas A. (1999). IP-Grundlagen. Prentice Hall. ISBN 978-0-13-975483-8.
  • Ian McLean. Windows (R) 2000 TCP / IP-Blackbook. ISBN 1-57610-687-X
  • Ajit Mungale Pro .NET 1.1 Netzwerkprogrammierung. ISBN 1-59059-345-6
  • W. Richard Stevens. TCP / IP Illustrated, Band 1: Die Protokolle. ISBN 0-201-63346-9
  • W. Richard Stevens und Gary R. Wright. TCP / IP Illustrated, Band 2: Die Implementierung. ISBN 0-201-63354-X
  • W. Richard Stevens. TCP / IP Illustrated, Band 3: TCP für Transaktionen, HTTP, NNTP und die UNIX-Domänenprotokolle. ISBN 0-201-63495-3
  • Andrew S. Tanenbaum. Computernetzwerke. ISBN 0-13-066102-3
  • Clark, D. (1988). “Die Designphilosophie der DARPA-Internetprotokolle”. Symposium über Kommunikationsarchitekturen und -protokolle – SIGCOMM ’88 (PDF). SIGCOMM ’88 Symposium Proceedings on Communications Architectures and Protocols. ACM. S. 106–114. doi:10.1145 / 52324.52336. ISBN 978-0897912792. S2CID 6156615. Abgerufen 16. Oktober 2011.

Verweise[edit]

  1. ^ ein b RFC 1122, Anforderungen an Internet-Hosts – KommunikationsschichtenR. Braden (Hrsg.), Oktober 1989.
  2. ^ RFC 1123, Anforderungen an Internet-Hosts – Anwendung und SupportR. Braden (Hrsg.), Oktober 1989
  3. ^ Cerf, Vinton G. & amp; Cain, Edward (1983), “The DoD Internet Architecture Model”, Computernetzwerke7, North-Holland, S. 307–318, CiteSeerX 10.1.1.88.7505
  4. ^ Abbate, Janet (2000). Das Internet erfinden. MIT Press. S. 123–4. ISBN 978-0-262-51115-5.
  5. ^ Cerf, V.; Kahn, R. (1974). “Ein Protokoll für die Paketnetzwerk-Interkommunikation” (PDF). IEEE-Transaktionen zur Kommunikation. 22 (5): 637–648. doi:10.1109 / TCOM.1974.1092259. ISSN 1558-0857. Die Autoren möchten einer Reihe von Kollegen für hilfreiche Kommentare während der frühen Diskussionen über internationale Netzwerkprotokolle danken, insbesondere R. Metcalfe, R. Scantlebury, D. Walden und H. Zimmerman; D. Davies und L. Pouzin, die die Fragmentierungs- und Rechnungslegungsfragen konstruktiv kommentierten; und S. Crocker, der die Schaffung und Zerstörung von Assoziationen kommentierte.
  6. ^ “Der fünfte Mann im Internet”. Ökonom. 13. Dezember 2013. Abgerufen 11. September, 2017. In den frühen 1970er Jahren schuf Herr Pouzin ein innovatives Datennetzwerk, das Standorte in Frankreich, Italien und Großbritannien miteinander verband. Seine Einfachheit und Effizienz wiesen den Weg zu einem Netzwerk, das nicht nur Dutzende von Maschinen, sondern Millionen von ihnen verbinden konnte. Es erregte die Fantasie von Dr. Cerf und Dr. Kahn, die Aspekte seines Designs in die Protokolle einbezogen haben, die jetzt das Internet antreiben.
  7. ^ Vinton Cerf, Yogen Dalal, Carl Sunshine (Dezember 1974), RFC 675, Spezifikation des Internet Transmission Control Protocol (Dezember 1974)
  8. ^ Internet Hall of Fame
  9. ^ Panzaris, Georgios (2008). Maschinen und Romanzen: Die technische und narrative Konstruktion des vernetzten Rechnens als Allzweckplattform, 1960-1995. Universität in Stanford. p. 128.
  10. ^ Pelkey, James L. (2007). “Yogen Dalal”. Unternehmerischer Kapitalismus und Innovation: Eine Geschichte der Computerkommunikation, 1968-1988. Abgerufen 5. September 2019.
  11. ^ Postel, Jon (1977), “Abschnitt 3.3.3.2”, Kommentare zu Internet Protocol und TCP
  12. ^ “Das TCP / IP-Handbuch – TCP / IP-Übersicht und Verlauf”. www.tcpipguide.com. Abgerufen 11. Februar 2020.
  13. ^ ein b von Vinton Cerf, wie Bernard Aboba (1993) erzählt. “Wie das Internet entstand”. Archiviert von das Original am 26. September 2017. Abgerufen 25. September 2017. Wir haben begonnen, gleichzeitig Implementierungen an Stanford, BBN und dem University College London durchzuführen. Die Bemühungen zur Entwicklung der Internetprotokolle waren daher von Anfang an international. … März ’82 – Norwegen verlässt das ARPANET und wird eine Internetverbindung über TCP / IP über SATNET. Nov ’82 – UCL verlässt das ARPANET und wird eine Internetverbindung.
  14. ^ RFC 1812, Anforderungen für IP Version 4 RouterF. Baker (Juni 1995)
  15. ^ Crowell, William; Contos, Brian; DeRodeff, Colby (2011). Konvergenz der physischen und logischen Sicherheit: Unterstützt von Enterprise Security Management. Syngress. p. 99. ISBN 9780080558783.
  16. ^ Ronda Hauben. “Vom ARPANET ins Internet”. TCP Digest (UUCP). Abgerufen 5. Juli 2007.
  17. ^ Martin, Olivier (2012). Die “versteckte” Vorgeschichte des europäischen Forschungsnetzwerks. Trafford Publishing. ISBN 978-1466938724.
  18. ^ Kirstein, Peter T. “Erste Erfahrungen mit ARPANET und Internet in Großbritannien”. Forschungsgruppe für Informatik, Systeme und Netzwerke, University College London. Abgerufen 13. April 2016.
  19. ^ “TCP / IP-Internetprotokoll”. Abgerufen 31. Dezember, 2017.
  20. ^ Leiner, Barry M.; et al. (1997), Kurze Geschichte des Internets (PDF), Internet Society, p. 15
  21. ^ Wollongong
  22. ^ “Eine kurze Geschichte der Internetprotokolle am CERN”. Archiviert von das Original am 10. November 2016. Abgerufen 12. September 2016.
  23. ^ Baker, Steven; Gillies, Donald W. “Desktop TCP / IP im mittleren Alter”.
  24. ^ Romkey, John (17. Februar 2011). “Über”. Abgerufen 12. September 2016.
  25. ^ Phil Karn, KA9Q TCP Website herunterladen
  26. ^ Andrew L. Russell (30. Juli 2013). “OSI: Das Internet, das nicht war”. IEEE-Spektrum. Vol. 50 nr. 8.
  27. ^ Russell, Andrew L. “Grober Konsens und laufender Code” und der Internet-OSI-Standardkrieg “ (PDF). IEEE-Annalen zur Geschichte des Rechnens. Archiviert von das Original (PDF) am 17. November 2019.
  28. ^ Davies, Howard; Bressan, Beatrice (26. April 2010). Eine Geschichte des internationalen Forschungsnetzwerks: Die Menschen, die es möglich gemacht haben. John Wiley & Sons. ISBN 978-3-527-32710-2.
  29. ^ Das Design des Internets überdenken: Die End-to-End-Argumente gegen die schöne neue Welt, Marjory S. Blumenthal, David D. Clark, August 2001
  30. ^ Jon Postel, Hrsg. (September 1981). Internetprotokoll DARPA Internet Program Protocol Specification. p. 23. doi:10.17487 / RFC0791. RFC 791.
  31. ^ R. Braden, Hrsg. (Oktober 1989). Anforderungen an Internet-Hosts – Kommunikationsschichten. p. 13. doi:10.17487 / RFC1122. RFC 1122.
  32. ^ B. Carpenter, Hrsg. (Juni 1996). Architekturprinzipien des Internets. doi:10.17487 / RFC1958. RFC 1958.
  33. ^ Hunt, Craig (2002). TCP / IP-Netzwerkadministration (3. Aufl.). O’Reilly. S. 9–10. ISBN 9781449390785.
  34. ^ TCP / IP Illustriert: die Protokolle, ISBN 0-201-63346-9, W. Richard Stevens, Februar 1994
  35. ^ RFC 1122, Anforderungen an Internet-Hosts – Kommunikationsschichten1.1.3 Internet Protocol Suite1989
  36. ^ Farbstoff, Mark; McDonald, Rick; Rufi, Antoon (29. Oktober 2007). Netzwerkgrundlagen, CCNA Exploration Companion Guide. Cisco Press. ISBN 9780132877435. Abgerufen 12. September 2016 – über Google Books.
  37. ^ James F. Kurose, Keith W. Ross, Computernetzwerke: Ein Top-Down-Ansatz, 2008 ISBN 0-321-49770-8
  38. ^ Forouzan, Behrouz A.; Fegan, Sophia Chung (1. August 2003). Datenkommunikation und Vernetzung. McGraw-Hill Hochschulbildung. ISBN 9780072923544. Abgerufen 12. September 2016 – über Google Books.
  39. ^ Comer, Douglas (1. Januar 2006). Internetworking mit TCP / IP: Prinzipien, Protokolle und Architektur. Prentice Hall. ISBN 0-13-187671-6. Abgerufen 12. September 2016 – über Google Books.
  40. ^ Kozierok, Charles M. (1. Januar 2005). Das TCP / IP-Handbuch: Eine umfassende, illustrierte Referenz zu Internetprotokollen. Keine Stärkepresse. ISBN 9781593270476. Abgerufen 12. September 2016 – über Google Books.
  41. ^ Stallings, William (1. Januar 2007). Daten- und Computerkommunikation. Prentice Hall. ISBN 978-0-13-243310-5. Abgerufen 12. September 2016 – über Google Books.
  42. ^ Tanenbaum, Andrew S. (1. Januar 2003). Computernetzwerke. Prentice Hall PTR. p. 42. ISBN 0-13-066102-3. Abgerufen 12. September 2016 – über das Internetarchiv. Netzwerke.
  43. ^ RFC 3439, Einige Internet-Architekturrichtlinien und -PhilosophieR. Bush, D. Meyer (Hrsg.), Dezember 2002.

Externe Links[edit]

after-content-x4