Logo von Developer

Suche
preisvergleich_weiss

Recherche in 2.302.663 Produkten

Maik Wojcieszak 20

Internet-Protokolle, Teil 1: TCP/IP, der Grundstein für Anwendungsprotokolle

Internet-Protokolle, Teil 1: TCP/IP, der Grundstein für Anwendungsprotokolle

Ob Internet oder Machine to Machine (M2M), ob Peer to Peer oder Client/Server, Anwendungsprotokolle verbinden die Knoten eines digitalen Netzes. Für Entwickler ist es wichtig, Unterschiede zwischen Internet-Protokollen wie HTTP, SMTP und FTP zu kennen.

Neue Entwicklungen im Internet wie Web APIs und Software as a Service führen vorhandene Protokolle an ihre Grenzen, weshalb in nächster Zeit einige neue zu erwarten sind. Das SPDY-Protokoll von Google und der nicht unumstrittene Entwurf des HTTP/2-Standards zeigen eine klare Tendenz, welche Funktionen derzeit gebraucht werden.

Ein Vergleich von Anwendungsprotokollen sowie eine Klassifizierung und Betrachtung immer wiederkehrender Funktionen lohnen sich und erleichtern dem Anwender die Entscheidung, welches der vielen Protokolle zur Bewältigung einer Aufgabe geeignet ist. Wenn es doch notwendig sein sollte, ein eigenes Protokoll zu entwickeln, kann ein Überblick außerdem helfen, den Aufwand besser einschätzen zu können.

Vielschichtige Verbindungen

1973 begann eine kleine Forschergruppe am MIT im Auftrag der US-Luftwaffe, Internetzwerk-Protokolle für das ARPA-Netz zu entwickeln. Sie schuf ein Protokoll, das unter dem Namen Transmission Control Program (TCP) 1974 formell in RFC 675 dokumentiert wurde. Es diente als Grundlage für Interprozesskommunikation in Netzwerken und gilt als Vorgänger der heute verwendeten TCP/IP-Protokollsuite.

Über die Artikelserie Internet-Protokolle

Vernetzte Anwendungen sind heute selbstverständlich. Der Transport von Daten durch das Internet wird von Protokollen organisiert, die sich in den letzten zwei Jahrzehnten nicht oder nur wenig verändert haben. Diese Artikelserie beschreibt die Technik der Internet-Protokolle aus Sicht des Anwendungsentwicklers. Möglichkeiten und Grenzen existierender Standards und zukünftiger Lösungen stehen dabei im Vordergrund. Der erste Teil beschreibt Grundbegriffe der TCP/IP-Protokollsuite. Im zweiten Teil werden häufig verwendete Anwendungsprotokolle beschrieben und verglichen. Der dritte und letzte Teil widmet sich den "Next Generation"-Protokollen, die leistungsfähigere Verbindungen im Internet ermöglichen sollen.

Das Transmission Control Program nahm die Daten der Prozesse über Sockets entgegen, verpackte sie in Pakete und organisierte deren Transport durch das Netzwerk. Auf der Seite des Empfängers wurden die Daten der Anwendung bereitgestellt, für die sie bestimmt waren.

Jon Postel, einer der wichtigsten Pioniere des Internet und TCP/IP, stellte jedoch 1977 den monolitischen Aufbau von TCP in Frage. Er veröffentlichte im Zuge dessen eine Reihe von Kommentaren über den Stand von TCP (Internet Engineering Note Nummer 2, oder IEN 2):

"We are screwing up in our design of internet protocols by violating the principle of layering. Specifically we are trying to use TCP to do two things: serve as a host level end to end protocol, and to serve as an internet packaging and routing protocol. These two things should be provided in a layered and modular way. I suggest that a new distinct internetwork protocol is needed, and that TCP be used strictly as a host level end to end protocol." – Jon Postel, IEN 2, 1977

Postel legte damit den Grundstein für die Aufteilung in TCP als Transportschicht und IP als Netzwerkschicht. Die genaue Definition der beiden Protokolle wurde 1981 in RFC 793 (TCP) und RFC 791 (IP) veröffentlicht. Die in Abbildung 1 dargestellten Schichten zeigen den modularen Aufbau der modernen TCP/IP-Protokollsuite.

Jede Schicht hat eine andere Aufgabe [1]:

  1. Die Verbindungsschicht besteht aus dem Gerätetreiber für die Netzwerkkarte und den für dessen Verwendung notwendigen Teilen des Betriebssystems. Zusammen behandeln sie alle Details der physikalischen Verbindung zum Netzwerk.
  2. Die Netzwerkschicht sorgt dafür, Datenpakete über das Netzwerk zu bewegen. Neben dem IP (Internet Protocol) bilden ICMP (Internet Control Message Protocol) und das IGMP (Internet Group Management Protocol) die Netzwerkschicht der TCP/IP-Protokollsuite.
  3. Die Transportschicht organisiert den Datenfluss zwischen Anwendungen im Netzwerk. Neben TCP enthält sie das User Datagram Protocol (UDP), das sich von TCP erheblich unterscheidet.
  4. Die Anwendungsschicht stellt die für eine Anwendung notwendigen Funktionen zur Verfügung. Durch die Vielzahl unterschiedlicher Aufgaben, die Programme im Netz erfüllen, ist die Anzahl der verwendeten Protokolle in dieser Schicht deutlich größer. Das richtige auszuwählen, kann zeitraubend sein. Oft ist die getroffene Entscheidung am Ende ein Kompromiss zwischen den tatsächlichen Anforderungen der Anwendung und den Möglichkeiten des gewählten Protokolls.
Die TCP/IP-Protokollsuite lässt sich in Schichten unterteilen (Abb.1)
Die TCP/IP-Protokollsuite lässt sich in Schichten unterteilen (Abb. 1)

TCP/UDP

TCP/UDP: zwei ungleiche Geschwister

Bei der Auswahl eines für die eigene Anwendung geeigneten Protokolls beginnt die Qual der Wahl bereits bei der Entscheidung, ob TCP oder UDP verwendet wird. Das User Datagram Protocol (UDP) wird in RFC 768 beschrieben und erlaubt das Senden von Nachrichten (Datagram) an einen oder mehrere Empfänger. Eine Verbindung zwischen Sender und Empfänger wird dabei nicht aufgebaut. Der Sender hat keine Möglichkeit festzustellen, ob eine Nachricht angekommen ist. Es ist ebenfalls nicht sicher, ob Nachrichten in der gleichen Reihenfolge beim Empfänger ankommen, in der sie gesendet wurden.

Da UDP der eigentlichen Nachricht nur wenige Informationen im Header hinzufügt und die Daten ohne weitere Kontrollmechanismen an den Empfänger geliefert werden, ist die Übertragung sehr schnell. Die richtige Reihenfolge der Nachrichten herzustellen und verloren gegangene Daten erneut anzufragen, ist dabei jedoch Aufgabe der Anwendung.

Mehrere Empfänger lassen sich innerhalb eines Sub-Netzes mit einer Broadcast-Adresse erreichen. Besonders diese Eigenschaft macht UDP für Anwendungen interessant, die Knoten im Netz Ereignisse signalisieren oder automatisch andere Knoten suchen. Bei Letzterem verschickt man eine Nachricht an alle Knoten. Erfolgt nach einer bestimmten Zeit keine Reaktion, wird die Anfrage wiederholt.

Beim Transmission Control Protocol (TCP) steht die gesicherte Übertragung der Daten im Vordergrund. Vor Beginn der Übermittlung muss eine Verbindung hergestellt sein. Zwischen den beiden Endpunkten der Verbindung ist ein Datenstrom in beide Richtungen möglich (vollduplex). TCP sorgt dafür, dass Empfänger die Daten in genau der Reihenfolge erhalten, in der sie der Sender schickt (Pipe).

Die wichtigsten Unterschiede zwischen UDP und TCP sind:

Das Transmission Control Protocol ermöglicht es Anwendungen, Daten zuverlässig zu übertragen, ohne sich mit den Details der Netzwerkschicht befassen zu müssen. Die Spezifikation und Implementierung von Anwendungsprotokollen, die TCP zur Grundlage nehmen, wird dadurch erheblich vereinfacht. Dennoch müssen sie je nach Anforderung viele Aufgaben erfüllen. Um zu verstehen, welche Funktionen ein Anwendungsprotokoll genau bieten muss, damit es modernen Internetanwendungen eine solide Grundlage bietet, sollen im Folgenden einige grundlegende Funktionen von TCP erläutert werden.

Verbindung gesucht

Jede TCP/IP-Verbindung wird zwischen zwei sogenannten Sockets aufgebaut. Ein Socket ist eine Kombination aus IP-Adresse und TCP-Port. Die IP-Adresse bezeichnet eine Netzwerkschnittstelle. Das kann zum Beispiel eine Netzwerkkarte (NIC), eine WLAN-Verbindung oder das interne localhost-Interface sein. Ein Rechner kann über eine Vielzahl von Schnittstellen zu unterschiedlichen Netzen verfügen. Die Netzwerkschicht ermöglicht den Datenaustausch zwischen unterschiedlichen Netzen. Dieser Vorgang wird Forwarding genannt. Häufig wird in dem Zusammenhang der Begriff Routing verwendet, der jedoch das Ermitteln einer Route durch das gesamte Netz, vom Sender bis zum Empfänger, bezeichnet.

TCP-Ports werden mit einer Nummer bezeichnet und dürfen pro Netzwerkinterface nur einmal vergeben werden. Beispielsweise ist es nicht möglich, zwei Internetserver zu starten, die auf dem gleichen Netzwerkinterface auf Port 80 Verbindungen zulassen.

Damit sich eine TCP-Verbindung zwischen zwei Knoten im Netzwerk herstellen lässt, muss ein Knoten bereit sein, eine Verbindung auf einem bekannten Port (well known port) zu erlauben. Dieser Zustand der Verbindung wird Abhörstatus (Listening) genannt. Erst jetzt kann man von einem anderen Knoten aktiv eine Verbindung aufbauen (initiate). Dabei wird dem Listener unter anderem der frei zugeteilte Port des Initiators mitgeteilt.

Übertragungsmechanismen

Langsam anfangen

Sobald eine TCP-Verbindung erfolgreich aufgebaut ist, beginnt die Übertragung der Daten. Da es sich bei der Verbindung um eine Vollduplex-Pipe handelt, kann jeder der beiden verbundenen Knoten sowohl Sender als auch Empfänger sein.

Für eine sichere Übertragung durch ein Netz teilt TCP den Datenstrom in Pakete auf (segmentieren). Die einzelnen Segmente oder Pakete werden nacheinander geschickt. Pakete die den Empfänger erreichen, bestätigt dieser (Acknowledge/ACK). Passiert das nicht innerhalb einer bestimmten Zeit (Timeout), gelten die Pakete als verloren, und der Sender muss sie erneut verschicken. Je mehr Segmente neu zu senden sind, desto langsamer ist die Übertragung.

Innerhalb eines lokalen Netzes (LAN) treten Timeouts selten auf. TCP-Pakete, die weitere Strecken zurücklegen müssen (in einem Wide Area Network, WAN), passieren jedoch Hindernisse auf ihrem Weg. Neben Routern, die eine Vielzahl von TCP-Paketen verarbeiten, können auch langsame Verbindungen zum Flaschenhals werden.

Schickt man zu viele Pakete gleichzeitig auf den Weg, kommt es an den Hindernissen zu Staus. Die Pakete am Ende der Schlange erreichen ihr Ziel nicht innerhalb der erwarteten Zeit, sodass keine Bestätigung erfolgt. Durch das erneute Senden der Pakete wird die Situation im Staubereich weiter verschlechtert und es kommt im schlimmsten Fall zu einem kompletten Zusammenbruch der Verbindung. Abbildung 2 zeigt, wie TCP-Pakete sich an Engpässen stauen.

Auf dem Übertragungsweg kann es zu Datenstaus kommen. (Abb. 2)
Auf dem Übertragungsweg kann es zu Datenstaus kommen. (Abb. 2)

Nicht nur Datenpakete auf ihrem Weg zum Empfänger werden verlangsamt, sondern auch deren Bestätigung wird ausgebremst.

Um das zu verhindern, verwendet TCP eine Kombination aus einem langsamen Steigern der Anzahl der Pakete, die gleichzeitig auf die Reise gehen (Slow Start[2]), und einem Stau-Vermeidungs-Algorithmus (Congestion Avoidance Algorithm[3]). Je nachdem welcher Algorithmus verwendet wird, ist die Reaktion auf verlorene Pakete unterschiedlich.

Die maximale Menge an Daten, die ohne Bestätigung gesendet werden darf, bestimmt jedoch der Empfänger. Die Größe dieses Sendefensters teilt er dem Sender mit.

Wohlfühlfenster

Neben Staus durch Hindernisse im Netz kann der Empfänger selbst Daten vielleicht nicht so schnell verarbeiten, wie ein Sender sie schickt. Der Speicherbereich (Puffer) für die Verwaltung der empfangenen Pakete wäre schnell voll, und weitere Pakete ließen sich nicht mehr annehmen. Die ausbleibende Bestätigung führt dann zum erneuten Senden der verworfenen Pakete.

Damit es nicht soweit kommt, teilt der Empfänger dem Sender mit, wie viele Daten er schicken darf, ohne auf eine Bestätigung zu warten. Diese Größe bezeichnet man als Fenster (Window). Sobald Datenpakete vom Empfänger bestätigt wurden, verschiebt sich das Fenster um die Menge der quittierten Daten (Sliding Window[4]). Abbildung 3 zeigt, wie sich ein Sendefenster abhängig von empfangenen Bestätigungen (ACK) bewegt. So ist zu jedem Zeitpunkt sichergestellt, dass der Sender nur so viele Daten verschickt, wie der Empfänger verarbeiten kann.

Das Sendefenster bewegt sich und stellt sicher, dass beim Empfänger nicht mehr ankommt, als er verarbeiten kann. (Abb. 3)
Das Sendefenster bewegt sich und stellt sicher, dass beim Empfänger nicht mehr ankommt, als er verarbeiten kann. (Abb. 3)

Fazit und Ausblick

Rollentausch

Häufig werden in Bezug auf TCP-Verbindungen die Begriffe Client und Server verwendet. Dabei handelt es sich jedoch nicht um festgelegte Rollen der Knoten im Netz. Für TCP-Verbindungen "horcht" zwar ein Knoten, der Listener auf einem Port, jedoch nur so lange, bis eine Verbindung aufgebaut ist. Die Bezeichnungen Listener und Initiator stellen diesen Sachverhalt genauer dar. Nachdem eine Verbindung aufgebaut ist, spielt es keine Rolle mehr, welcher der Knoten Listener oder Initiator war. Die verbundenen Knoten sind dann sowohl Sender als auch Empfänger, da es sich bei einer TCP-Verbindung um eine Vollduplex-Pipe handelt und sich Daten gleichzeitig senden und empfangen lassen.

Jeder der beiden Knoten kann folglich aktiv Daten an den anderen schicken und wird dadurch zum Sender, was dem anderen für diese Daten in die Rolle des Empfängers bringt. Werden keine Daten übertragen, gibt es weder Sender noch Empfänger. Beide Knoten unterscheiden sich, bezogen auf die Möglichkeiten der Datenübertragung, nicht. Auch für das Beenden einer Verbindung spielt es keine Rolle, welcher Knoten sie ursprünglich aufgebaut hat. Jeder kann eine bestehende Verbindung trennen.

Was braucht man mehr?

TCP bietet einer Anwendung, neben komfortablen Möglichkeiten, Daten zwischen Knoten auszutauschen, auch Funktionen, Fehler bei der Übertragung zu erkennen und darauf zu reagieren. Häufig ist trotzdem zusätzlich ein Anwendungsprotokoll nötig. Dieses kann sehr einfach strukturiert sein. Mit TCP/IP Sockets Textnachrichten, die durch ein bestimmtes Zeichen terminiert sind, zu verschicken, ist schnell programmiert. Oft wachsen jedoch die Anforderungen an die Kommunikation während eines Projekts, und es stellt sich heraus, dass der Aufwand für dessen Implementierung unterschätzt wurde.

Nachrichten durch ein festgelegtes Zeichen voneinander im TCP Datenstrom zu trennen ist ein einfaches Framing. Natürlich darf das gewählte Zeichen in den Nachrichten selbst nicht mehr verwendet werden. Syntax und Semantik des Inhalts und die Art und Darstellung der Daten (Encoding) müssen festgelegt sein. Sicherheit der Datenübertragung, Authentifizierung und Verschlüsselung sind ebenfalls Aufgabe der Anwendung. Jedes Anwendungsprotokoll sollte darüber hinaus über eine Möglichkeit der Fehlererkennung verfügen (Reporting), falls die Regeln des Protokolls verletzt werden. Für asynchrone Nachrichten ist zusätzlich Multiplexing (Zusammenfassen mehrerer Signale zum Versenden über ein gemeinsames Medium) und Flusskontrolle nötig, was in jedem Fall den Rahmen einer trivialen Implementierung sprengt.

Fazit und Ausblick

Das Transmission Control Protocol wird seit vielen Jahrzehnten erfolgreich für Verbindungen im Internet eingesetzt. Eine Vielzahl von Texten beschreibt im Detail dessen Funktionen. Trotz oder gerade wegen dieser Flut an Informationen gibt es immer wieder Missverständnisse, was das Zusammenspiel zwischen TCP und Anwendungsprotokollen angeht.

Kaum noch eine Anwendung kommt ohne Netzwerk aus. Dabei spielt es keine Rolle, ob sie im Internetbrowser abläuft, als App auf einem mobilen Gerät wie Smartphone und Pad, oder als installiertes Programm auf Desktop-PCs und Notebooks. Deshalb sollte jeder Anwendungsentwickler eine konkrete Vorstellung von den Möglichkeiten und Grenzen verwendeter Netzwerkverbindungen haben. Besonders das Wissen über dessen Grenzen beugt unrealistischen Erwartungen wirksam vor.

Im nächsten Teil dieser Artikelserie sollen Funktionen von Anwendungsprotokollen Thema sein. Dabei werden unter anderem Kommunikationsmuster wie Client/Server, Peer-to-Peer, Request/Response und Publish/Subscribe betrachtet und gegenübergestellt. Neue Protokolle wie CoAP und MQTT werden mit etablierten Protokollen wie HTTP, SMTP und FTP verglichen und Probleme aktueller Webanwendungen beschrieben, für die sich Lösungen bisher nicht durchsetzen konnten. (jul)

Maik Wojcieszak
ist Gründer und Geschäftsführer der Kieler Firma wobe-systems GmbH. Er entwickelt seit mehr als 10 Jahren mit seinem Team verteilte Systeme für industrielle Anforderungen.

Literatur
[1] W. R. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994. Kapitel 1.3 TCP/IP Layering
[2] W. R. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994. Kapitel 20.6 Slow Start
[3] W. R. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994. Kapitel 21.6 Congestion Avoidance Algorithm
[4] W. R. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994. Kapitel 20.3 Sliding Windows

20 Kommentare