Dieses Jahr wird das Transmission Control Protocol (TCP) in der aktuell noch gültigen Version 40 Jahre alt. Im September 1981 erschien der Request For Comment (RFC) Nummer 793. Dieses Dokument ist nach wie vor der gültige TCP-Standard. Natürlich kamen später Ergänzungen hinzu, aber die Grundidee ist immer noch dieselbe wie vor 40 Jahren.
Ziel von TCP war von Anfang an, ein sehr verlässliches Host-zu-Host-Protokoll zur Nutzung in einem paketvermittelnden Netz bereitzustellen. TCP ist verbindungsorientiert, d.h., vor jeglicher Übertragung muss zunächst zwischen zwei Hosts eine Verbindung aufgebaut werden. TCP verlässt sich nicht auf die unteren Schichten, sondern erreicht die Verlässlichkeit der Übertragung durch eigene Mechanismen.
TCP ermöglicht den Austausch von Byte-Strömen in Segmenten. TCP muss jegliche Beschädigung, Verlust, Duplizierung oder Reihenfolgenänderung der Daten heilen. Dazu werden die Bytes durchnummeriert und vom Empfänger gesendete Bestätigungen (ACKs) erwartet. Wenn binnen einer Frist keine Empfangsbestätigung da ist, kommt es zu einer erneuten Übertragung, einer Retransmission.
Ein TCP-Empfänger stellt die korrekte Reihenfolge der Bytes wieder her. Dazu verwendet er einen Puffer. Wenn das TCP-Segment Nummer n+1 da ist, bevor das Segment n empfangen wurde, werden alle Segmente mit einer Nummer größer als n im Puffer zurückgehalten, bis n wieder da ist. Das führt bei Paketverlusten, die in IP-Netzen vorkommen können, zum sogenannten Head-Of-Line Blocking (HOL Blocking). Die Situation ist vergleichbar mit der an der Supermarktkasse. Weiß der Kassierer nicht, was der Kilopreis für die von Ihnen aufgelegten Orangen ist, muss er nachblättern oder eine Kollegin fragen. Das dauert, und möglicherweise spüren Sie die Verärgerung der Kunden hinter Ihnen an der heißen Luft, die Ihren Nacken streift.
Verlässlichkeit hat nun mal ihren Preis. Aber manchmal ist hundertprozentige Verlässlichkeit gar nicht nötig. Ob ein Paket verloren geht, ist bei einem Audio- oder Videostrom egal. Selbst einige IoT-Anwendungen arbeiten mit redundanten Daten verschiedener Sensoren, die für den Zweck der Datenübertragung nicht unbedingt vollständig übertragen werden müssen.
Daher bietet Youtube seit Jahren Streaming mittels QUIC an. Unterstützt der Client dieses neue Protokoll, wird QUIC statt TCP für Streaming genutzt. Für die Google-eigenen Clients trifft das zu.
QUIC ist seit Mai 2021 im RFC 9000 standardisiert. Wird TCP damit in Rente geschickt? Die Antwort ist definitiv nein. TCP dominiert weiterhin die weltweite und auch unternehmensinterne Kommunikation zu einem überwiegenden Anteil. Bei vielen Anwendungen gibt es keinen Grund, dafür auf die TCP-Nutzung zu verzichten. Auch bei Applikationen, die unter den Nachteilen von TCP leiden, wird es Jahre dauern, bevor sie umgestellt sind. Bei TCP kann man also mit Sicherheit von Rente mit 50+ ausgehen.
