Seite 4: Fazit und Ausblick

Inhaltsverzeichnis

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.

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 (jul)