The Internet protocol suite, commonly known as TCP/IP, is a framework for organizing the communication protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP). Early versions of this networking model were known as the Department of Defense (DoD) Internet Architecture Model because the research and development were funded by the Defense Advanced Research Projects Agency (DARPA) of the United States Department of Defense.

The Internet protocol suite provides end-to-end data communication specifying how data should be packetized, addressed, transmitted, routed, and received. This functionality is organized into four abstraction layers, which classify all related protocols according to each protocol's scope of networking.[1][2] An implementation of the layers for a particular application forms a protocol stack. From lowest to highest, the layers are the link layer, containing communication methods for data that remains within a single network segment (link); the internet layer, providing internetworking between independent networks; the transport layer, handling host-to-host communication; and the application layer, providing process-to-process data exchange for applications.

The technical standards underlying the Internet protocol suite and its constituent protocols are maintained by the Internet Engineering Task Force (IETF). The Internet protocol suite predates the OSI model, a more comprehensive reference framework for general networking systems.

History

Early research

An SRI InternationalPacket Radio Van, used for the first three-way internetworked transmission

Die Internetprotokollfamilie hat ihre Wurzeln in der Forschung und Entwicklung von Computernetzwerken, die Ende der 1960er Jahre von der Defense Advanced Research Projects Agency ( DARPA ) gefördert wurde. Im August 1968 wurde BBN von ARPA mit dem Bau der Interface Message Processors (IMPs) für das ARPANET , den Vorläufer des modernen Internets, beauftragt . [ 3 ] [ Anm. 1 ] Die IMPs waren die allererste Generation von Gateways , die heute als Router bekannt sind . Unter der Leitung von Frank Heart und Bob Kahn wurden von September bis Dezember 1969 vier IMPs für fast eine Million US-Dollar produziert. [ 4 ] [ 5 ] Der erste IMP wurde im September 1969 an die University of California, Los Angeles ( UCLA) geliefert , der zweite einen Monat später an das Stanford Research Institute (SRI) . [ 6 ] Die erste Nachricht zwischen den beiden IMPs lautete „LO“ – phonetisch „Hello“ –, doch der SRI-Host stürzte ab, bevor der UCLA-Forscher den Befehl „LOGIN“ vollständig eingeben konnte. [ 7 ] [ 8 ]

Nachdem DARPA 1969 das wegweisende ARPANET initiiert hatte, gründete Steve Crocker eine „Netzwerk-Arbeitsgruppe“, die ein Host-zu-Host-Protokoll, das Network Control Program (NCP), entwickelte. [ 9 ] Anfang der 1970er-Jahre begann DARPA mit der Entwicklung verschiedener weiterer Datenübertragungstechnologien, darunter mobiler Paketfunk, Paketsatellitendienste, lokale Netzwerke und andere Datennetze im öffentlichen und privaten Bereich. 1972 trat Bob Kahn dem DARPA Information Processing Technology Office bei , wo er sowohl an Satelliten- als auch an bodengestützten Funkpaketnetzen arbeitete und den Wert der Kommunikation zwischen beiden erkannte. Im Frühjahr 1973 begann Vinton Cerf von der Stanford University die Zusammenarbeit mit Kahn, um die nächste Protokollgeneration für das ARPANET zu entwickeln und so die Vernetzung von Netzwerken zu ermöglichen . [ 10 ] [ 11 ] Sie nutzten die Erfahrungen der internationalen Forschungsgemeinschaft über die International Network Working Group (INWG) unter dem Vorsitz von Cerf, der Forscher aus der ARPANET-Gemeinschaft, Xerox PARC , dem Vereinigten Königreich und Frankreich angehörten. [ 12 ] [ 13 ] [ 14 ]

Im Sommer 1973 erarbeiteten Kahn und Cerf eine grundlegende Neuformulierung, in der die Unterschiede zwischen lokalen Netzwerkprotokollen durch ein gemeinsames Netzwerkprotokoll verschleiert wurden . Anstatt dass das Netzwerk – wie bei den bestehenden ARPANET-Protokollen – für die Zuverlässigkeit verantwortlich war, wurde diese Funktion an die Hosts delegiert. [ 15 ] Cerf und Kahn würdigen mehrere Mitglieder der INWG für ihren maßgeblichen Einfluss auf diesen Entwurf, der im Mai 1974 veröffentlicht wurde. [ 16 ] Die erste Spezifikation dieses Übertragungssteuerungsprogramms wurde im Dezember 1974 von Cerf, Yogen Dalal und Carl Sunshine an der Stanford University verfasst . [ 17 ]

DARPA beauftragte 1975 BBN Technologies , die Stanford University und das University College London mit der Entwicklung funktionsfähiger Versionen des Protokolls auf verschiedenen Hardwareplattformen. [ 18 ] Mehrere Versionen wurden im Rahmen der Internet Experiment Note (IEN)-Reihe entwickelt. [ 19 ] Anfänglich bot das Transmission Control Program (TCP), der Vorläufer der späteren Protokollfamilie, lediglich einen zuverlässigen Byte-Stream- Dienst, keine Datagramme . [ 20 ] Mit zunehmender Erfahrung mit dem Protokoll empfahlen die Mitarbeiter, die Funktionalität in Schichten unterschiedlicher Protokolle aufzuteilen und so einen direkten Zugriff auf den Datagramm-Dienst zu ermöglichen. Zu den Befürwortern gehörten Bob Metcalfe , Yogen Dalal und John Shoch von Xerox PARC; [ 21 ] [ 22 ] [ 23 ] Danny Cohen , der es für seine Arbeit im Bereich der Paketvermittlung benötigte ; und Jonathan Postel vom Information Sciences Institute der University of Southern California , der die Request for Comments (RFCs) herausgab – die Reihe technischer und strategischer Dokumente, die die Entwicklung des Internets sowohl dokumentierte als auch beschleunigte. [ 24 ] Postel erklärte: „Wir machen Fehler beim Entwurf der Internetprotokolle, indem wir das Schichtenprinzip verletzen.“ [ 25 ] Die Kapselung verschiedener Mechanismen sollte eine Umgebung schaffen, in der die oberen Schichten nur auf die benötigten Ressourcen der unteren Schichten zugreifen konnten. Ein monolithischer Entwurf wäre unflexibel und würde zu Skalierungsproblemen führen. In Version 4 , die 1978 geschrieben wurde, teilte Postel das Transmission Control Protocol in zwei separate Protokolle auf: das Internet Protocol (IP) als verbindungslose Schicht und das Transmission Control Protocol (TCP) als zuverlässigen, verbindungsorientierten Dienst . [ 26 ] [ 27 ] [ 28 ] [ nb 2 ]

Diagramm der ersten vernetzten Verbindung. An einem regnerischen Dienstag, dem 22. November 1977, flossen Daten vom Lieferwagen über England, Boston und Schweden zum SRI in Menlo Park und zur University of Southern California über drei Netzwerktypen: Paketfunk, Satellitennetzwerk und ARPANET. [ 29 ]

Das Netzwerkdesign berücksichtigte, dass es ausschließlich die effiziente Übertragung und Weiterleitung von Datenverkehr zwischen Endknoten gewährleisten sollte und alle weiteren intelligenten Funktionen am Netzwerkrand, in den Endknoten, angesiedelt sein sollten. Dieses End-to-End-Prinzip wurde von Louis Pouzin und Hubert Zimmermann im CYCLADES- Netzwerk [ 30 ] [ 31 ] auf Basis der Ideen von Donald Davies [ 32 ] [ 33 ] entwickelt . Dank dieses Designs konnten andere Netzwerke, die dasselbe Prinzip nutzten, unabhängig von lokalen Gegebenheiten an das ARPANET angebunden werden, wodurch Kahns ursprüngliches Internetworking-Problem gelöst wurde. Virginia Travers , die die erste Gateway-Software für TCP entwickelt hatte, reiste monatelang zu Standorten in den USA und Europa, um die Software an den für den großen Test benötigten Punkten zu installieren, beispielsweise am University College London und an der Norwegischen Verteidigungsforschungsanstalt in Oslo für die Verbindung zum Atlantischen Satellitennetzwerk [ 34 ] .

Das Internetprotokoll Version 4 (IPv4) wurde 1983 im ARPANET installiert und bildete die Grundlage für die im Internet verwendeten Netzwerkprotokolle . Ursprünglich als DOD-Internetarchitekturmodell bezeichnet [ 35 ] , wurde es zusammen mit dem Transmission Control Protocol allgemein als TCP/IP bekannt .

Frühe Umsetzung

1975 wurde ein IP-Kommunikationstest mit zwei Netzwerken zwischen Stanford und dem University College London durchgeführt. Im November 1977 folgte ein IP-Test mit drei Netzwerken zwischen Standorten in den USA, Großbritannien und Norwegen. Zwischen 1978 und 1983 wurden an verschiedenen Forschungszentren mehrere weitere IP-Prototypen entwickelt. [ 19 ]

Ein Computer, der als Router bezeichnet wird , verfügt über eine Schnittstelle zu jedem Netzwerk. Er leitet Netzwerkpakete zwischen den Netzwerken hin und her. [ 36 ] Ursprünglich wurde ein Router als Gateway bezeichnet, aber der Begriff wurde geändert, um Verwechslungen mit anderen Gateway -Typen zu vermeiden . [ 37 ]

Annahme

In March 1982, the US Department of Defense declared TCP/IP as the standard for all military computer networking.[38][39][40] In the same year, Norway (NORSAR and NDRE) and Peter Kirstein's research group at University College London adopted the protocol.[41] The migration of the ARPANET from NCP to TCP/IP was officially completed on flag day January 1, 1983, when the new protocols were permanently activated.[38][42]

In 1985, the Internet Advisory Board (later Internet Architecture Board) held a three-day TCP/IP workshop for the computer industry, attended by 250 vendor representatives, promoting the protocol and leading to its increasing commercial use. In 1985, the first Interop conference focused on network interoperability by broader adoption of TCP/IP. The conference was founded by Dan Lynch, an early Internet activist. From the beginning, large corporations, such as IBM and DEC, attended the meeting.[43][44]

IBM, AT&T and DEC were the first major corporations to adopt TCP/IP, this despite having competing proprietary protocols. In IBM, from 1984, Barry Appelman's group did TCP/IP development. They navigated the corporate politics to get a stream of TCP/IP products for various IBM systems, including MVS, VM, and OS/2. At the same time, several smaller companies, such as FTP Software and the Wollongong Group, began offering TCP/IP stacks for DOS and Microsoft Windows.[45] The first VM/CMS TCP/IP stack came from the University of Wisconsin.[46]

Einige Programmierer sind für frühe TCP/IP-Stack-Implementierungen bekannt. Jay Elinsky und Oleg Vishnepolsky von IBM Research entwickelten Software für VM/CMS bzw. OS/2. [ 47 ] 1984 schrieb Donald Gillies am MIT ein ntcp-basiertes Multi-Connection-TCP, das auf der von John Romkey 1983/84 am MIT entwickelten IP/PacketDriver-Schicht aufbaute. Romkey nutzte dieses TCP 1986 bei der Gründung von FTP Software. [ 48 ] [ 49 ] Ab 1985 entwickelte Phil Karn eine Multi-Connection-TCP-Anwendung für Amateurfunksysteme (KA9Q TCP). [ 50 ]

Die Verbreitung von TCP/IP wurde im Juni 1989 weiter beschleunigt, als die University of California, Berkeley, zustimmte, den für BSD UNIX entwickelten TCP/IP-Code der Öffentlichkeit zugänglich zu machen. Verschiedene Unternehmen, darunter IBM, integrierten diesen Code in ihre kommerziellen TCP/IP-Softwareprodukte. Für Windows 3.1, das in der ersten Hälfte der 1990er-Jahre das dominierende PC-Betriebssystem für Privatanwender war, spielte Peter Tattams Veröffentlichung des Trumpet Winsock TCP/IP-Stacks eine entscheidende Rolle, um das Internet für Heimanwender zugänglich zu machen. Trumpet Winsock ermöglichte TCP/IP-Operationen über eine serielle Verbindung ( SLIP oder PPP ). Der typische Heim-PC jener Zeit verfügte über ein externes, Hayes -kompatibles Modem , das über eine RS-232-Schnittstelle mit einer 8250- oder 16550- UART verbunden war , welche diesen Stack benötigte. Später veröffentlichte Microsoft einen eigenen TCP/IP-Zusatzstapel für Windows for Workgroups 3.11 und einen nativen Stapel in Windows 95. Diese Ereignisse trugen dazu bei, die Dominanz von TCP/IP gegenüber anderen Protokollen in Microsoft-basierten Netzwerken, zu denen auch IBMs Systems Network Architecture (SNA) gehörte, sowie auf anderen Plattformen wie Digital Equipment Corporations DECnet , Open Systems Interconnection (OSI) und Xerox Network Systems (XNS) zu festigen.

Dennoch herrschte Ende der 1980er und Anfang der 1990er Jahre unter Ingenieuren, Organisationen und Nationen Uneinigkeit darüber, welcher Standard – das OSI-Modell oder die Internetprotokollfamilie – die besten und robustesten Computernetzwerke hervorbringen würde. [ 51 ] [ 52 ] [ 53 ]

Formale Spezifikation und Standards

Die technischen Standards, die der Internetprotokollfamilie und ihren Teilprotokollen zugrunde liegen, wurden an die Internet Engineering Task Force (IETF) delegiert. [ 54 ] [ 55 ]

Die charakteristische Architektur der Internetprotokollfamilie ist ihre grobe Unterteilung in Betriebsbereiche für die Protokolle, die ihre Kernfunktionalität bilden. Die definierenden Spezifikationen der Familie sind RFC 1122 und 1123, die im Wesentlichen vier Abstraktionsschichten (sowie zugehörige Protokolle) beschreiben: die Sicherungsschicht, die IP-Schicht, die Transportschicht und die Anwendungsschicht, zusammen mit unterstützenden Protokollen. [ 1 ] [ 2 ] Diese haben sich bewährt, da die IETF diese Struktur nie geändert hat. Als solches Netzwerkmodell ist die Internetprotokollfamilie älter als das OSI-Modell, ein umfassenderes Referenzrahmenwerk für allgemeine Netzwerksysteme. [ 53 ]

Als Nachfolger wurde das Internetprotokoll Version 6 (IPv6) entwickelt, um Probleme wie die Erschöpfung der IPv4-Adressen zu beheben . [ 56 ]

Wichtige architektonische Prinzipien

Konzeptioneller Datenfluss in einer einfachen Netzwerktopologie mit zwei Hosts ( A und B ), die über eine Verbindung zwischen ihren jeweiligen Routern verbunden sind. Die Anwendung auf jedem Host führt Lese- und Schreiboperationen so aus, als wären die Prozesse direkt über eine Datenleitung miteinander verbunden. Nach dem Aufbau dieser Leitung sind die meisten Details der Kommunikation für die einzelnen Prozesse verborgen, da die zugrundeliegenden Kommunikationsprinzipien in den unteren Protokollschichten implementiert sind. Analog dazu erscheint die Kommunikation auf der Transportschicht als Host-zu-Host-Kommunikation, ohne Kenntnis der Anwendungsdatenstrukturen und der verbindenden Router, während auf der Netzwerkschicht an jedem Router die individuellen Netzwerkgrenzen überschritten werden.
Kapselung von Anwendungsdaten, die die in RFC 1122 beschriebenen Schichten durchlaufen

Das End-to-End-Prinzip hat sich im Laufe der Zeit weiterentwickelt. Ursprünglich lag die Verantwortung für die Zustandsverwaltung und die Gesamtintelligenz an den Netzwerkrändern, und es wurde angenommen, dass das Internet, das diese Ränder verbindet, keinen Zustand speichert und sich auf Geschwindigkeit und Einfachheit konzentriert. Reale Anforderungen wie Firewalls, Netzwerkadressübersetzer, Web-Content-Caches und Ähnliches haben jedoch Änderungen an diesem Prinzip erzwungen. [ 57 ]

Das Robustheitsprinzip besagt: „Im Allgemeinen muss eine Implementierung beim Senden konservativ und beim Empfangen liberal vorgehen. Das heißt, sie muss darauf achten, wohlgeformte Datagramme zu senden, aber jedes Datagramm akzeptieren, das sie interpretieren kann (z. B. technische Fehler nicht beanstanden, solange die Bedeutung klar ist).“ [ 58 ] : 23 „Der zweite Teil des Prinzips ist fast ebenso wichtig: Software auf anderen Hosts kann Mängel aufweisen, die es unklug machen, zulässige, aber schwer verständliche Protokollmerkmale auszunutzen.“ [ 1 ] : 13

Die Kapselung dient der Abstraktion von Protokollen und Diensten. Sie orientiert sich üblicherweise an der Aufteilung der Protokollsuite in Schichten mit allgemeiner Funktionalität. Im Allgemeinen verwendet eine Anwendung (die oberste Ebene des Modells) eine Reihe von Protokollen, um ihre Daten an die nachfolgenden Schichten zu senden. Die Daten werden auf jeder Ebene zusätzlich gekapselt.

Zwei frühe Architekturdokumente, RFC  1122 und 1123 mit dem Titel „ Requirements for Internet Hosts“ , betonen Architekturprinzipien gegenüber der Schichtung. [ 59 ] RFC 1122/23 sind zwar in Abschnitte gegliedert, die sich auf Schichten beziehen, erwähnen aber auch viele andere Architekturprinzipien und legen keinen Schwerpunkt auf die Schichtung. Sie definieren im Wesentlichen ein Vier-Schichten-Modell, wobei die Schichten Namen und keine Nummern tragen, wie folgt: [ 1 ] [ 2 ]

  • Die Anwendungsschicht ist der Bereich, in dem Anwendungen ( Prozesse) Benutzerdaten erzeugen und diese an andere Anwendungen auf demselben oder einem anderen Host übermitteln. Die Anwendungen nutzen die Dienste der darunterliegenden Schichten, insbesondere der Transportschicht, die zuverlässige oder unzuverlässige Verbindungen zu anderen Prozessen bereitstellt. Die Kommunikationspartner werden durch die Anwendungsarchitektur charakterisiert, beispielsweise durch das Client-Server-Modell oder Peer-to-Peer -Netzwerke. Auf dieser Schicht laufen alle Anwendungsprotokolle wie SMTP, FTP, SSH und HTTP. Prozesse werden über Ports adressiert, die im Wesentlichen Dienste repräsentieren .
  • Die Transportschicht ermöglicht die Kommunikation zwischen Hosts im lokalen Netzwerk oder in entfernten, durch Router getrennten Netzwerken. [ 60 ] Sie stellt einen Kanal für die Kommunikationsbedürfnisse von Anwendungen bereit. Das User Datagram Protocol (UDP) ist das einfachste Protokoll der Transportschicht und bietet einen unzuverlässigen, verbindungslosen Datagrammdienst. Das Transmission Control Protocol (TCP) hingegen ermöglicht die Flusssteuerung, den Verbindungsaufbau und die zuverlässige Datenübertragung.
  • Die Internetschicht tauscht Datagramme über Netzwerkgrenzen hinweg aus. Sie stellt eine einheitliche Netzwerkschnittstelle bereit, die die tatsächliche Topologie (das Layout) der zugrunde liegenden Netzwerkverbindungen verbirgt. Sie ist daher auch die Schicht, die die Vernetzung von Netzwerken ermöglicht. Tatsächlich definiert und etabliert sie das Internet. Diese Schicht definiert die Adressierungs- und Routingstrukturen, die für die TCP/IP-Protokollfamilie verwendet werden. Das primäre Protokoll in diesem Bereich ist das Internetprotokoll (IP), das IP-Adressen definiert . [ 61 ] [ 62 ] Seine Routing-Funktion besteht darin, Datagramme an den nächsten Host – einen sogenannten IP-Router – weiterzuleiten, der über eine Verbindung zu einem Netzwerk verfügt, das dem endgültigen Datenziel näher liegt. [ 62 ]
  • Die Sicherungsschicht definiert die Netzwerkmethoden innerhalb des lokalen Netzwerklinks, über den Hosts ohne zwischengeschaltete Router kommunizieren. Diese Schicht umfasst die Protokolle zur Beschreibung der lokalen Netzwerktopologie und die Schnittstellen, die für die Übertragung von Internet-Datagrammen an benachbarte Hosts erforderlich sind. [ 63 ]

Die Protokolle der Sicherungsschicht arbeiten innerhalb des lokalen Netzwerks, an das ein Host angeschlossen ist. Dieser Bereich wird in der TCP/IP-Terminologie als „ Link“ bezeichnet und ist die unterste Komponentenschicht des Protokollpakets. Über den Link sind alle Hosts erreichbar, ohne dass ein Router durchlaufen werden muss. Die Größe des Links wird daher durch die Netzwerkhardware bestimmt. TCP/IP ist prinzipiell hardwareunabhängig und kann auf nahezu jeder Sicherungsschichttechnologie implementiert werden. Dies umfasst nicht nur Hardware-Implementierungen, sondern auch virtuelle Sicherungsschichten wie VPNs und Netzwerktunnel .

Die Sicherungsschicht dient der Übertragung von Datenpaketen zwischen den Schnittstellen der Internetschicht zweier verschiedener Hosts über dieselbe Verbindung. Die Prozesse des Sendens und Empfangens von Paketen auf der Verbindung können im Gerätetreiber der Netzwerkkarte , in der Firmware oder durch spezielle Chipsätze gesteuert werden . Diese führen Funktionen wie das Framing durch, um die Pakete der Internetschicht für die Übertragung vorzubereiten und sie schließlich an die physikalische Schicht und über ein Übertragungsmedium zu senden . Das TCP/IP-Modell enthält Spezifikationen für die Übersetzung der im Internetprotokoll verwendeten Netzwerkadressierungsmethoden in Adressen der Sicherungsschicht, wie z. B. MAC-Adressen ( Media Access Control ). Alle anderen Aspekte unterhalb dieser Schicht werden jedoch implizit vorausgesetzt und sind im TCP/IP-Modell nicht explizit definiert.

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

Internetschicht

Für die Vernetzung ist es erforderlich, Daten vom Quellnetzwerk zum Zielnetzwerk zu senden. Dieser Vorgang wird als Routing bezeichnet und durch die Adressierung und Identifizierung von Hosts mithilfe des hierarchischen IP-Adressierungssystems unterstützt . Die Internetschicht stellt eine unzuverlässige Datenübertragung zwischen Hosts in potenziell unterschiedlichen IP-Netzwerken bereit, indem sie Datagramme an einen geeigneten Router weiterleitet, der sie dann an ihr Ziel sendet. Die Internetschicht ist für die Übertragung von Datenpaketen über potenziell mehrere Netzwerke verantwortlich. Mit dieser Funktionalität ermöglicht die Internetschicht die Vernetzung, also die Zusammenarbeit verschiedener IP-Netzwerke, und bildet somit die Grundlage des Internets.

Die Internetschicht unterscheidet nicht zwischen den verschiedenen Transportprotokollen. IP transportiert Daten für eine Vielzahl unterschiedlicher Protokolle höherer Schichten . Jedes dieser Protokolle wird durch eine eindeutige Protokollnummer identifiziert : Beispielsweise sind das Internet Control Message Protocol (ICMP) und das Internet Group Management Protocol (IGMP) die Protokolle 1 bzw. 2.

Das Internetprotokoll (IP) ist die zentrale Komponente der Internetschicht und definiert zwei Adressierungssysteme zur Identifizierung und Lokalisierung von Netzwerk-Hosts. Das ursprüngliche Adressierungssystem des ARPANET und seines Nachfolgers, des Internets, ist IPv4 . Es verwendet eine 32-Bit -IP-Adresse und kann daher etwa vier Milliarden Hosts identifizieren. Diese Beschränkung wurde 1998 durch die Standardisierung von IPv6 aufgehoben , das 128-Bit-Adressen verwendet. Erste IPv6-Implementierungen kamen etwa 2006 auf den Markt.

Transport layer

The transport layer establishes data channels that applications use for task-specific data exchange. The layer establishes host-to-host connectivity in the form of end-to-end message transfer services that are independent of the underlying network and independent of the structure of user data and the logistics of exchanging information. Connectivity at the transport layer can be categorized as either connection-oriented, implemented in TCP, or connectionless, implemented in UDP. The protocols in this layer may provide error control, segmentation, flow control, congestion control, and application addressing (port numbers).

For the purpose of providing process-specific transmission channels for applications, the layer establishes the concept of the network port. This is a numbered logical construct allocated specifically for each of the communication channels an application needs. For many types of services, these port numbers have been standardized so that client computers may address specific services of a server computer without the involvement of service discovery or directory services.

Because IP provides only a best-effort delivery, some transport-layer protocols offer reliability.

TCP is a connection-oriented protocol that addresses numerous reliability issues in providing a reliable byte stream:

  • data arrives in-order
  • data has minimal error (i.e., correctness)
  • duplicate data is discarded
  • lost or discarded packets are resent
  • includes traffic congestion control

The newer Stream Control Transmission Protocol (SCTP) is also a reliable, connection-oriented transport mechanism. It is message-stream-oriented, not byte-stream-oriented like TCP, and provides multiple streams multiplexed over a single connection. It also provides multihoming support, in which a connection end can be represented by multiple IP addresses (representing multiple physical interfaces), such that if one fails, the connection is not interrupted. It was developed initially for telephony applications (to transport SS7 over IP).

Reliability can also be achieved by running IP over a reliable data-link protocol such as the High-Level Data Link Control (HDLC).

Das User Datagram Protocol (UDP) ist ein verbindungsloses Datagrammprotokoll . Wie IP arbeitet es nach dem Best-Effort-Prinzip und ist daher nicht zuverlässig. Die Zuverlässigkeit wird durch Fehlererkennung mittels Prüfsummenalgorithmus gewährleistet. UDP wird typischerweise für Anwendungen wie Streaming-Medien (Audio, Video, Voice over IP usw.) verwendet, bei denen die pünktliche Zustellung wichtiger ist als die Zuverlässigkeit, oder für einfache Abfrage-/Antwortanwendungen wie DNS- Lookups, bei denen der Aufwand für den Aufbau einer zuverlässigen Verbindung unverhältnismäßig hoch ist. Das Real-Time Transport Protocol (RTP) ist ein Datagrammprotokoll, das über UDP verwendet wird und für Echtzeitdaten wie Streaming-Medien konzipiert ist .

Die Anwendungen an einer bestimmten Netzwerkadresse werden durch ihren TCP- oder UDP-Port unterschieden. Konventionsgemäß werden bestimmte bekannte Ports spezifischen Anwendungen zugeordnet.

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

QUIC etabliert sich rasant als alternatives Transportprotokoll. Obwohl es technisch gesehen über UDP-Pakete übertragen wird, bietet es im Vergleich zu TCP eine verbesserte Transportverbindung. HTTP/3 funktioniert ausschließlich über QUIC.

Anwendungsschicht

Die Anwendungsschicht umfasst die Protokolle, die von den meisten Anwendungen zur Bereitstellung von Benutzerdiensten oder zum Austausch von Anwendungsdaten über die von den Protokollen der unteren Schichten hergestellten Netzwerkverbindungen verwendet werden. Dies kann grundlegende Netzwerkunterstützungsdienste wie Routing-Protokolle und Hostkonfiguration umfassen. Beispiele für Protokolle der Anwendungsschicht sind das Hypertext Transfer Protocol (HTTP), das File Transfer Protocol (FTP), das Simple Mail Transfer Protocol (SMTP) und das Dynamic Host Configuration Protocol (DHCP). [ 64 ] Daten, die gemäß den Protokollen der Anwendungsschicht codiert sind, werden in Protokolleinheiten der Transportschicht (wie TCP-Streams oder UDP-Datagramme) gekapselt , die wiederum Protokolle der unteren Schichten verwenden , um die eigentliche Datenübertragung zu ermöglichen.

Das TCP/IP-Modell berücksichtigt nicht die Besonderheiten der Datenformatierung und -darstellung und definiert im Gegensatz zum OSI-Modell keine zusätzlichen Schichten zwischen Anwendungs- und Transportschicht (Darstellungs- und Sitzungsschicht). Laut TCP/IP-Modell fallen solche Funktionen in den Zuständigkeitsbereich von Bibliotheken und Anwendungsprogrammierschnittstellen (APIs ). Die Anwendungsschicht im TCP/IP-Modell wird häufig mit einer Kombination der fünften (Sitzungs-), sechsten (Darstellungs-) und siebten (Anwendungs-) Schicht des OSI-Modells verglichen.

Anwendungsschichtprotokolle sind häufig bestimmten Client-Server- Anwendungen zugeordnet, und gängige Dienste verwenden bekannte, von der Internet Assigned Numbers Authority (IANA) reservierte Portnummern . Beispielsweise nutzt das Hypertext Transfer Protocol (HTTP) Serverport 80 und Telnet Serverport 23. Clients, die sich mit einem Dienst verbinden, verwenden üblicherweise dynamische Ports , d. h. Portnummern, die nur für die Dauer der Transaktion zufällig oder aus einem in der Anwendung konfigurierten Bereich zugewiesen werden.

Auf der Anwendungsschicht unterscheidet das TCP/IP-Modell zwischen Benutzerprotokollen und Unterstützungsprotokollen . [ 1 ] : §1.1.3 Unterstützungsprotokolle stellen Dienste für ein System der Netzwerkinfrastruktur bereit. Benutzerprotokolle werden für eigentliche Benutzeranwendungen verwendet. Beispielsweise ist FTP ein Benutzerprotokoll und DNS ein Unterstützungsprotokoll.

Obwohl Anwendungen üblicherweise wichtige Eigenschaften der Transportschichtverbindung wie Endpunkt-IP-Adressen und Portnummern kennen, behandeln Anwendungsschichtprotokolle die Transportschichtprotokolle (und darunterliegende Protokolle) im Allgemeinen als Blackboxes , die eine stabile Netzwerkverbindung für die Kommunikation bereitstellen. Die Transportschicht und die darunterliegenden Schichten kümmern sich nicht um die Details der Anwendungsschichtprotokolle. Router und Switches untersuchen den gekapselten Datenverkehr in der Regel nicht, sondern stellen lediglich einen Kanal dafür bereit. Einige Firewall- und Bandbreitenbegrenzungsanwendungen nutzen jedoch Deep Packet Inspection , um Anwendungsdaten zu interpretieren. Ein Beispiel hierfür ist das Resource Reservation Protocol (RSVP). [ 65 ] Für Anwendungen, die von NAT betroffen sind, ist es mitunter auch notwendig , die Nutzdaten der Anwendung zu berücksichtigen.

Schichtentwicklung und Darstellungen in der Literatur

Die Internetprotokollfamilie entwickelte sich durch Forschung und Entwicklung, die über einen längeren Zeitraum finanziert wurde. Dabei veränderten sich die Details der Protokollkomponenten und ihrer Schichtung. Parallel dazu konkurrierten Forschungs- und kommerzielle Interessen von Branchenverbänden mit den Designvorgaben. Insbesondere die Bemühungen der Internationalen Organisation für Normung (ISO) verfolgten ein ähnliches Ziel, jedoch mit einem breiteren Fokus auf die Netzwerktechnik im Allgemeinen. Der Versuch, die beiden Hauptrichtungen der Schichtung zu konsolidieren, die oberflächlich betrachtet ähnlich, in Details aber stark voneinander abwichen, veranlasste unabhängige Lehrbuchautoren zur Entwicklung von zusammenfassenden Lehrmaterialien.

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

Arpanet Reference Model(RFC 871)Internet Standard(RFC 1122)Internet model(Cisco Academy[66])TCP/IP 5-layer reference model(Kozierok,[67] Comer[68])TCP/IP 5-layer reference model(Tanenbaum[69])TCP/IP protocol suite or Five-layer Internet model(Forouzan,[70] Kurose[71])TCP/IP model(Stallings[72])OSI model(ISO/IEC 7498-1:1994[73])
Three layersFour layersFour layersFour+one layersFive layersFive layersFive layersSeven layers
Application/ Process Application Application Application Application Application Application Application
Presentation
Session
Host-to-host Transport Transport Transport Transport Transport Host-to-host or transport Transport
Internet Internetwork Internet Internet Network Internet Network
Network interface Link Network interface Data link (Network interface) Data link Data link Network access Data link
N/aN/aN/a(Hardware) Physical Physical Physical Physical

Some of the networking models are from textbooks, which are secondary sources that may conflict with the intent of RFC 1122 and other IETF primary sources.[74]

Comparison of TCP/IP and OSI layering

The three top layers in the OSI model, i.e. the application layer, the presentation layer and the session layer, are not distinguished separately in the TCP/IP model which only has an application layer above the transport layer. While some pure OSI protocol applications, such as X.400, also combined them, there is no requirement that a TCP/IP protocol stack must impose monolithic architecture above the transport layer. For example, the NFS application protocol runs over the External Data Representation (XDR) presentation protocol, which, in turn, runs over a protocol called Remote Procedure Call (RPC). RPC provides reliable record transmission, so it can safely use the best-effort UDP transport.

Different authors have interpreted the TCP/IP model differently, and disagree whether the link layer, or any aspect of the TCP/IP model, covers OSI layer 1 (physical layer) issues, or whether TCP/IP assumes a hardware layer exists below the link layer. Several authors have attempted to incorporate the OSI model's layers 1 and 2 into the TCP/IP model since these are commonly referred to in modern standards (for example, by IEEE and ITU). This often results in a model with five layers, where the link layer or network access layer is split into the OSI model's layers 1 and 2.[75]

Die IETF-Protokollentwicklung legt keinen Wert auf strikte Schichtenarchitektur. Einige ihrer Protokolle lassen sich möglicherweise nicht vollständig in das OSI-Modell einordnen, obwohl RFCs gelegentlich darauf Bezug nehmen und häufig die alten OSI-Schichtnummern verwenden. Die IETF hat wiederholt erklärt [ 54 ] , dass die Entwicklung von Internetprotokollen und -architekturen nicht auf OSI-Konformität abzielt. RFC 3439, der sich auf die Internetarchitektur bezieht, enthält einen Abschnitt mit dem Titel: „Schichtarchitektur wird als schädlich angesehen“ [ 74 ] .

Beispielsweise werden die Sitzungs- und Darstellungsschicht des OSI-Modells der Anwendungsschicht des TCP/IP-Modells zugeordnet. Die Funktionalität der Sitzungsschicht findet sich in Protokollen wie HTTP und SMTP und tritt besonders deutlich in Protokollen wie Telnet und dem Session Initiation Protocol (SIP) hervor. Auch die Portnummerierung der TCP- und UDP-Protokolle, die zur Transportschicht des TCP/IP-Modells gehören, ermöglicht die Nutzung der Sitzungsschicht. Funktionen der Darstellungsschicht werden in TCP/IP-Anwendungen mithilfe des MIME- Standards für den Datenaustausch realisiert.

Ein weiterer Unterschied liegt in der Behandlung von Routing-Protokollen . Das OSI-Routing-Protokoll IS-IS gehört zur Netzwerkschicht und ist für die Paketübermittlung zwischen Routern nicht auf CLNS angewiesen, sondern definiert seine eigene Schicht-3-Kapselung. Im Gegensatz dazu werden OSPF , RIP , BGP und andere von der IETF definierte Routing-Protokolle über IP transportiert, und Router fungieren beim Senden und Empfangen von Routing-Protokollpaketen als Hosts. Daher werden Routing-Protokolle der Anwendungsschicht zugeordnet. [ 36 ] Einige Autoren, wie beispielsweise Tanenbaum in „Computer Networks“ , beschreiben Routing-Protokolle auf derselben Schicht wie IP, da sie ihrer Ansicht nach die Entscheidungen der Router im Weiterleitungsprozess beeinflussen.

IETF-Protokolle lassen sich rekursiv kapseln, wie Tunnelprotokolle wie Generic Routing Encapsulation (GRE) zeigen. GRE nutzt denselben Mechanismus, den OSI für Tunneling auf der Netzwerkschicht verwendet.

Implementierungen

The Internet protocol suite is generally independent of a specific hardware or software environment. It only requires the hardware and a software layer to exist, capable of sending and receiving packets on a computer network. As a result, the suite has been implemented on essentially every computing platform. A minimal implementation of TCP/IP includes the following: Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Group Management Protocol (IGMP).[76] In addition to IP, ICMP, TCP, UDP, Internet Protocol version 6 requires Neighbor Discovery Protocol (NDP), ICMPv6, and Multicast Listener Discovery (MLD) and is often accompanied by an integrated IPSec security layer.

See also

Notes

  1. ^Cite error: The named reference NPL was invoked but never defined (see the help page).
  2. ^For records of discussions leading up to the TCP/IP split, see the series of Internet Experiment Notes at the Internet Experiment Notes Index.

References

  1. ^ abcdeR. Braden, ed. (October 1989). Requirements for Internet Hosts -- Communication Layers. Network Working Group. doi:10.17487/RFC1122. STD 3. RFC1122.Internet Standard 3. Updated by RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 and 9293.
  2. ^ abcR. Braden, ed. (October 1989). Requirements for Internet Hosts -- Application and Support. Network Working Group. doi:10.17487/RFC1123. STD 3. RFC1123.Internet Standard 3. Aktualisiert durch RFC  1349 , 2181 , 5321 , 5966 und 7766 .
  3. ^ Hafner & Lyon 1998 , S. 91
  4. ^ „Dave Walden, Rückblick auf die ARPANET-Bemühungen, 34 Jahre später – Internetgeschichte“ . livinginternet.com . Abgerufen am 22. Dezember 2018 .
  5. ^ Hafner & Lyon 1998 , S. 103
  6. ^ Hafner & Lyon 1998 , S. 103, 151
  7. ^ Zitatfehler: Die benannte Referenz wurde aufgerufen, aber nie definiert (siehe die Hilfeseite ).BBN's earliest days
  8. ^ Hafner & Lyon 1998 , S. 153
  9. ^ J. Reynolds ; J. Postel (November 1987). Der Leitfaden für die Einreichung von Kommentaren (Request for Comments Reference Guide) . Network Working Group. doi : 10.17487/RFC1000 . RFC 1000 .Status unbekannt. Ersetzt RFC  84 , 100 , 160 , 170 , 200 , 598 , 699 , 800 , 899 und 999 .
  10. ^ Hafner, Katie; Lyon, Matthew (1996). Wo Zauberer lange aufbleiben: Die Ursprünge des Internets . Internet Archive. New York: Simon & Schuster. S. 263. ISBN 978-0-684-81201-4Die
  11. Russell , Andrew L. (2014). Offene Standards und das digitale Zeitalter: Geschichte, Ideologie und Netzwerke . New York: Cambridge University Press. S. 196. ISBN 978-1107039193Archiviert vom Original am 28. Dezember 2022. Abgerufen am 20. Dezember 2022 .
  12. ^ Abbate 1999 , S.  3 „Der Leiter des ARPANET-Projekts, Lawrence Roberts, stellte ein großes Team von Informatikern zusammen … und griff dabei auf die Ideen von Netzwerkforschern in den Vereinigten Staaten und Großbritannien zurück. Auch Cerf und Kahn holten sich Unterstützung von Informatikern aus England, Frankreich und den Vereinigten Staaten.“
  13. ^ Taylor, Bob (11. Oktober 2008), „Mündliche Geschichte von Robert (Bob) W. Taylor“ (PDF) , Archiv des Computer History Museum , CHM-Referenznummer: X5059.2009: 28
  14. ^ Isaacson, Walter (2014). Die Innovatoren: Wie eine Gruppe von Hackern, Genies und Geeks die digitale Revolution schuf . Internet Archive. New York: Simon & Schuster. ISBN 978-1-4767-0869-0Die
  15. ^ Isaacson, Walter (2014). Die Innovatoren: Wie eine Gruppe von Hackern, Genies und Geeks die digitale Revolution schuf . Internet Archive. New York: Simon & Schuster. ISBN 978-1-4767-0869-0Die
  16. ^ Cerf , V.; Kahn, R. (1974). „A Protocol for Packet Network Intercommunication“ (PDF) . IEEE Transactions on Communications . 22 (5): 637–648 . Bibcode : 1974ITCom..22..637C . doi : 10.1109/TCOM.1974.1092259 . ISSN 1558-0857 . Archiviert (PDF) vom Original am 10. Oktober 2022. Abgerufen am 18. Oktober 2015. Die Autoren danken einer Reihe von Kollegen für ihre hilfreichen Kommentare in den frühen Diskussionen über internationale Netzwerkprotokolle, insbesondere R. Metcalfe, R. Scantlebury, D. Walden und H. Zimmerman ; D. Davies und L. Pouzin für ihre konstruktiven Anmerkungen zu Fragmentierungs- und Abrechnungsproblemen; sowie S. Crocker für seine Kommentare zur Erstellung und Auflösung von Assoziationen. 
  17. ^ V. Cerf ; Y. Dalal ; C. Sunshine (Dezember 1974). Spezifikation eines Internet-Übertragungssteuerungsprogramms . Network Working Group. doi : 10.17487/RFC0675 . RFC 675 .Veraltet. Ersetzt durch RFC  7805. NIC 2. INWG 72.
  18. ^ von Vinton Cerf, erzählt von Bernard Aboba (1993). „Wie das Internet entstand“ . Archiviert vom Original am 26. September 2017. Abgerufen am 25. September 2017. Wir begannen mit parallelen Implementierungen in Stanford, BBN und am University College London . Die Entwicklung der Internetprotokolle war also von Anfang an international.
  19. ^ a b Cerf, Vinton G. (1. April 1980). "Abschlussbericht des TCP-Projekts der Stanford University" .
  20. ^ Cerf, Vinton (März 1977). „Spezifikation des Internet Transmission Control Protocol TCP (Version 2)“ (PDF) . Archiviert (PDF) vom Original am 25. Mai 2022. Abgerufen am 4. August 2022 .
  21. ^ Panzaris, Georgios (2008). Maschinen und Romanzen: Die technische und narrative Konstruktion vernetzter Computer als universelle Plattform, 1960–1995 . Stanford University . S. 128. Archiviert vom Original am 17. Januar 2023. Abgerufen am 5. September 2019 .
  22. ^ Pelkey, James L. (2007). „Yogen Dalal“ . Unternehmerischer Kapitalismus und Innovation: Eine Geschichte der Computerkommunikation, 1968–1988 . Archiviert vom Original am 8. Oktober 2022. Abgerufen am 8. Oktober 2020 .
  23. ^ „Zum Design von TCP/IP“ . www.nethistory.info . Abgerufen am 5. Dezember 2025 .
  24. ^ Internet Hall of Fame
  25. ^ Postel, Jon (15. August 1977), 2.3.3.2 Kommentare zum Internetprotokoll und TCP , IEN 2, archiviert vom Original am 16. Mai 2019 , abgerufen am 11. Juni 2016
  26. ^ Abbate, Die Erfindung des Internets , 129–30.
  27. ^ Vinton G. Cerf (Oktober 1980). „Protokolle für vernetzte Paketnetzwerke“. ACM SIGCOMM Computer Communication Review . 10 (4): 10–11 .
  28. Russell , Andrew L. (2007). „Industriegesetzgebung“: Konsensstandardisierung in der zweiten und dritten industriellen Revolution (PDF) (Dissertation). Johns Hopkins University. Archiviert (PDF) vom Original am 28. Dezember 2022. Abgerufen am 28. Dezember 2022 .
  29. ^ „Geboren in einem Lieferwagen: Alles Gute zum 40. Geburtstag des Internets!“ . computerhistory.org/ . Abgerufen am 27. Mai 2026 .
  30. ^ „Der fünfte Mann des Internets“ . Economist . 13. Dezember 2013. Archiviert vom Original am 19. April 2020. Abgerufen am 11. September 2017. Anfang der 1970er-Jahre entwickelte Herr Pouzin ein innovatives Datennetzwerk, das Standorte in Frankreich, Italien und Großbritannien verband . Seine Einfachheit und Effizienz ebneten den Weg für ein Netzwerk, das nicht nur Dutzende, sondern Millionen von Rechnern verbinden konnte. Es inspirierte Dr. Cerf und Dr. Kahn, die Aspekte seines Designs in die Protokolle einfließen ließen, die heute das Internet antreiben.
  31. ^ Bennett, Richard (September 2009). „Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate“ (PDF) . Information Technology and Innovation Foundation. S. 7, 11. Abgerufen am 11. September 2017 .
  32. ^ Pelkey, James. „8.3 CYCLADES Network and Louis Pouzin 1971–1972“. Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968–1988 . Archiviert vom Original am 17. Juni 2021. Abgerufen am 21. November 2021. Die Inspiration für Datagramme hatte zwei Quellen . Zum einen die Studien von Donald Davies. Er hatte Datagrammnetzwerke simuliert, obwohl er keine gebaut hatte, und es schien technisch machbar. Die zweite Inspiration war mein Hang zur Einfachheit. Ich sah keine wirkliche technische Notwendigkeit, zwei Ebenen von Ende-zu-Ende-Protokollen übereinanderzulegen. Ich dachte, eine reiche aus.
  33. ^ Davies, Donald; Bartlett, Keith; Scantlebury, Roger; Wilkinson, Peter (Oktober 1967). Ein digitales Kommunikationsnetzwerk für Computer, das schnelle Reaktionen an entfernten Endgeräten ermöglicht (PDF) . ACM Symposium on Operating Systems Principles. Archiviert (PDF) vom Original am 10. Oktober 2022. Abgerufen am 15. September 2020. Alle Benutzer des Netzwerks werden sich selbst eine Art Fehlerkontrolle bereitstellen .
  34. ^ „Virginia Travers: Technologie entwickelt sich nicht linear“ . www.internethalloffame.org/ . Abgerufen am 27. Mai 2026 .
  35. ^ Cerf, Vinton G. & Cain, Edward (Oktober 1983). „Das Internetarchitekturmodell des US-Verteidigungsministeriums“. Computer Networks . 7 (5). North-Holland: 307–318 . doi : 10.1016/0376-5075(83)90042-9 .
  36. ^ a b F. Baker , Hrsg. (Juni 1995). Anforderungen an IP-Version-4-Router . Network Working Group. doi : 10.17487/RFC1812 . RFC 1812 .Vorgeschlagener Standard. Ersetzt RFC  1716 und 1009. Aktualisiert durch RFC  2644 und 6633 .
  37. ^ Crowell, William; Contos, Brian; DeRodeff, Colby (2011). Konvergenz von physischer und logischer Sicherheit: Unterstützt durch Enterprise Security Management . Syngress. S. 99. ISBN 9780080558783Die
  38. ^ a b Ronda Hauben. „Vom ARPANET zum Internet“ . TCP Digest (UUCP). Archiviert vom Original am 21. Juli 2009. Abgerufen am 5. Juli 2007 .
  39. ^ IEN 207 . IETF .
  40. ^ IEN 152 . IETF .
  41. ^ Hauben, Ronda (2004). „Das Internet: Über seine internationalen Ursprünge und seine kollaborative Vision“ . Amateur Computerist . 12 (2) . Abgerufen am 29. Mai 2009. März 1982 – Norwegen verlässt das ARPANET und stellt eine Internetverbindung über TCP/IP via SATNET her. November 1982 – Das University College London (UCL) verlässt das ARPANET und stellt eine Internetverbindung her.
  42. ^ „TCP/IP Internetprotokoll“ . Archiviert vom Original am 1. Januar 2018. Abgerufen am 31. Dezember 2017 .
  43. ^ Leiner, Barry M.; et al. (1997), Brief History of the Internet (PDF) , Internet Society , S. 15, archiviert (PDF) vom Original am 18. Januar 2018 , abgerufen am 17. Januar 2018
  44. ^ „Vinton G. Cerf: Eine mündliche Geschichte“ . Stanford Oral History Collections – Spotlight at Stanford . 2020. S. 113, 129, 145. Abgerufen am 29. Juni 2024 .
  45. ^ „Verwendung von Wollongong TCP/IP mit Windows for Workgroups 3.11“ . Microsoft Support . Archiviert vom Original am 12. Januar 2012.
  46. ^ „Eine kurze Geschichte der Internetprotokolle am CERN“ . Archiviert vom Original am 10. November 2016. Abgerufen am 12. September 2016 .
  47. ^ „Einführung in Computernetzwerke, Stanford Univ CS144 Herbst 2012“ (PDF) . S.  21– 22.
  48. ^ Baker, Steven; Gillies, Donald W. „Desktop TCP/IP im mittleren Alter“ . Archiviert vom Original am 21. August 2015. Abgerufen am 9. September 2016 .
  49. ^ Romkey, John (17. Februar 2011). „Über uns“ . Archiviert vom Original am 5. November 2011. Abgerufen am 12. September 2016 .
  50. ^ Phil Karn, KA9Q TCP-Download-Website
  51. ^ Andrew L. Russell (30. Juli 2013). „OSI: Das Internet, das es nicht gab“ . IEEE Spectrum . Band 50, Nr. 8. Archiviert vom Original am 1. August 2017. Abgerufen am 6. Februar 2020 .
  52. Russell , Andrew L. „Rough Consensus and Running Code“ und der Internet-OSI-Standardkrieg (PDF) . IEEE Annals of the History of Computing. Archiviert vom Original (PDF) am 17. November 2019.
  53. ^ a b Davies, Howard; Bressan, Beatrice (26. April 2010). Eine Geschichte der internationalen Forschungsnetzwerke: Die Menschen, die sie ermöglichten . John Wiley & Sons. ISBN 978-3-527-32710-2Archiviert vom Original am 17. Januar 2023. Abgerufen am 7. November 2020 .
  54. ^ a b „Einführung in die IETF“ . IETF . Abgerufen am 27. Februar 2024 .
  55. ^ Morabito, Roberto; Jimenez, Jaime (Juni 2020). „IETF Protocol Suite for the Internet of Things: Overview and Recent Advancements“ . IEEE Communications Standards Magazine . 4 (2): 41–49 . arXiv : 2003.10279 . Bibcode : 2020ICStM...4b..41M . doi : 10.1109/mcomstd.001.1900014 . ISSN 2471-2825 . 
  56. ^ B. Carpenter ; R. Hinden (1. April 2011). Anpassung von RFC 1149 für IPv6 . Internet Engineering Task Force . doi : 10.17487/RFC6214 . ISSN 2070-1721 . RFC 6214 . Zur Information. Dies ist eine Bitte um Kommentare zum 1. April .
  57. ^ Blumenthal, Marjory S.; Clark, David D. (August 2001). „Das Design des Internets neu denken: Die Argumente für eine durchgängige Verbindung vs. die schöne neue Welt“ (PDF) . Archiviert (PDF) vom Original am 8. Oktober 2022. Abgerufen am 8. Oktober 2022 .
  58. ^ J. Postel (Hrsg.). (September 1981). INTERNET PROTOCOL - DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION . IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26.Internetstandard 5. Ersetzt RFC  760. Aktualisiert durch RFC  1349 , 2474 und 6864 .
  59. ^ B. Carpenter (Hrsg.). (Juni 1996). Architekturprinzipien des Internets . Network Working Group. doi : 10.17487/RFC1958 . RFC 1958 .Zur Information. Aktualisiert gemäß RFC  3439 .
  60. ^ Hunt, Craig (2002). TCP/IP-Netzwerkadministration (3. Aufl.). O'Reilly. S.  9–10 . ISBN 9781449390785Die
  61. ^ Guttman, E. (1999). „Service location protocol: automatic discovery of IP network services“ . IEEE Internet Computing . 3 (4): 71–80 . Bibcode : 1999IIC.....3d..71G . doi : 10.1109/4236.780963 . ISSN 1089-7801 . 
  62. ^ a b Zheng, Kai (Juli 2017). „Ermöglichung von „Protokoll-Routing“: Eine Neubetrachtung des Transportschichtprotokolldesigns in der Internetkommunikation“ . IEEE Internet Computing . 21 (6): 52–57 . Bibcode : 2017IIC....21f..52Z . doi : 10.1109/mic.2017.4180845 . ISSN 1089-7801 . 
  63. ^ Huang, Jing-lian (7. April 2009). „Cross-Layer-Link-Adaption-Schema in drahtlosen lokalen Netzwerken“ . Journal of Computer Applications . 29 (2): 518–520 . doi : 10.3724/sp.j.1087.2009.00518 (inaktiv seit 1. Juli 2025). ISSN 1001-9081 . {{cite journal}}: CS1 Wartung: DOI inaktiv ab Juli 2025 ( Link )
  64. ^ Stevens, W. Richard (Februar 1994). TCP/IP Illustrated: the protocols . Addison-Wesley. ISBN 0-201-63346-9Archiviert vom Original am 22. April 2012. Abgerufen am 25. April 2012 .
  65. ^ Team, IR „Eine Erklärung der Deep Packet Inspection und ihrer Funktionsweise | IR“ . www.ir.com . Abgerufen am 13. Juli 2025 .
  66. ^ Dye, Mark; McDonald, Rick; Rufi, Antoon (29. Oktober 2007). Netzwerk-Grundlagen, CCNA Exploration Companion Guide . Cisco Press. ISBN 9780132877435Abgerufen am 12. September 2016 – via Google Books.
  67. ^ Kozierok, Charles M. (1. Januar 2005). Der TCP/IP-Leitfaden: Ein umfassendes, illustriertes Nachschlagewerk zu Internetprotokollen . No Starch Press. ISBN 9781593270476Abgerufen am 12. September 2016 – via Google Books.
  68. ^ Comer, Douglas (1. Januar 2006). Internetworking with TCP/IP: Principles, protocols, and architecture . Prentice Hall. ISBN 0-13-187671-6Abgerufen am 12. September 2016 – via Google Books.
  69. ^ Tanenbaum, Andrew S. ( 1. Januar 2003). Computernetzwerke . Prentice Hall PTR. S.  42. ISBN 0-13-066102-3Abgerufen am 12. September 2016 – via Internet Archive. Netzwerke.
  70. ^ Forouzan, Behrouz A.; Fegan, Sophia Chung (1. August 2003). Datenkommunikation und Netzwerke . McGraw-Hill Higher Education. ISBN 9780072923544Abgerufen am 12. September 2016 – via Google Books.
  71. ^ Kurose, James F.; Ross, Keith W. (2008). Computernetzwerke: Ein Top-Down-Ansatz . Pearson/Addison Wesley. ISBN 978-0-321-49770-3Archiviert vom Original am 23. Januar 2016. Abgerufen am 16. Juli 2008 .
  72. ^ Stallings, William (1. Januar 2007). Daten- und Computerkommunikation . Prentice Hall. ISBN 978-0-13-243310-5Abgerufen am 12. September 2016 – via Google Books.
  73. ^ ISO/IEC 7498-1:1994 Informationstechnik — Verbindung offener Systeme — Basisreferenzmodell: Das Basismodell .
  74. ^ a b R. Bush; D. Meyer (Dezember 2002). Some Internet Architectural Guidelines and Philosophy . Network Working Group. doi : 10.17487/RFC3439 . RFC 3439 .Informativ. Aktualisiert RFC  1958 .
  75. ^ Murray, Nick (28. November 2018). „Netzwerkschichten erklärt: OSI- und TCP/IP-Modelle [mit Beispielen]“ . Plixer . Abgerufen am 13. Juli 2025 .
  76. ^ Braden, Robert T. (1989). Anforderungen an Internet-Hosts – Kommunikationsschichten . IETF . doi : 10.17487/RFC1122 . RFC 1122 .

Bibliographie