October 6, 2022
Internet-Kernprotokoll: Das Transport Control Protocol erhält Update

Seit den 1980er Jahren regelt das Transmission Control Protokoll (TCP) einen Großteil des Internet-Verkehrs. TCP gehört damit bis heute zu den Eckpfeilern der Internetkommunikation. Mit dem Request for Comment 9293 (RFC 9293) werden jetzt erstmals über die Jahre nachgereichte kleine Änderungen zusammengefasst und eine Minimalanforderung zur Bewältigung von Überlast eingefügt.

Die von der Internet Engineering Task Force (IETF) im Jahr 1981 verabschiedete RFC-Spezifikation 793 war also rund vierzig Jahre lang gültig. Das Basis-Transportprotokoll fürs Internet regelt die Kommunikation zwischen einem Server und einem Client, die IP-Pakete unter Einsatz einer Fehlerkorrektur möglichst schnell austauschen wollen, aber keine konkreten Informationen darüber haben, wie schnell die Strecke ist, über die sie kommunizieren.

Insgesamt geht es in der TCP-Spezifikation um das Öffnen und Schließen einer Verbindung und die Gewährleistung einer vollständigen Übertragung der Datenpakete, beziehungsweise um die Methode, wie Sender und Empfänger Übertragungsfehler detektieren und beheben. Anders als die zugrundeliegende IP-Schicht und der Gegenentwurf UDP (User Datagram Protocol) ist TCP ein “zustandsorientiertes” Protokoll, das heißt, die beiden beteiligten Server wissen Bescheid über den Status der Verbindung.

Grundsätzlich hat sich am guten alten TCP, wie es Internet-Übervater Jon Postel in den 1980ern beschrieben hat, wenig geändert. Im Wesentlichen sei die neue Version eine “Zusammenführung von diversen Dokumenten, die sich seit RFC 793 angesammelt haben”, erklärt auch Professor Michael Scharf von der Hochschule Esslingen. Scharf war zwischen 2011 und März 2022 einer der Vorsitzenden der Arbeitsgruppe TCP Maintenance and Minor Extensions der IETF (TCPM).

Zu den nun integrierten Dokumenten gehört etwa die von 1989 stammende Definition eines Algorithmus zur Berechnung der Frist, nach der der Sender ein vom Empfänger nicht quittiertes Paket noch einmal versenden soll (RFC 1122). Das jüngste integrierte RFC stammt aus dem Jahr 2012 und ist letztlich nur eine Klarstellung der maximalen Größe von TCP-Segmenten. RFC 9293 führt all diese Dinge zusammen, erklärte Scharf. “Wer eine neue TCP-Implementierung entwickeln will, findet hier nun alles, was er braucht.”Viele der integrierten RFCs sind damit obsolet und werden damit zu “historischen Texten”.

Als historisch stuften die Renovierer wohl auch Postels Darstellung der “Philosophie des TCP” und auch den Hinweis auf den ursprünglichen Auftraggeber, das US-Verteidigungsministerium. Hingegen behandelt der neue, zu Postels Zeiten noch nicht gedachte Abschnitt “Security Considerations” mögliche Angriffe und Schwachstellen sowie die dafür teils angebotenen Sicherheitsmechanismen, etwa das wenig verbreitete TCPCrypt.

Eine Ausnahme hat das Redaktionsteam rund um Wesley Eddy, CTO der Software-Defined-Networking-Firma MTI Systems, aber doch gemacht. Erstmals legt der TCP-Standard Minimalanforderungen zur TCP-Staukontrolle fest (Congestion Control).

Die Wahl von Staukontroll-Algorithmen bleibt aber nach wie vor den Implementierern vorbehalten und bleibe damit flexibel, wie Scharf unterstreicht. Das ist notwendig, weil im Bereich der Staukontrolle neben den aktuell häufig eingesetzten Reno und Cubic auch neuere wie Googles BBR zur Verfügung stehen. Die nächste Generation sei schon in Arbeit.

Festgelegt ist im neuen TCP-Standarddokument aber, welchen Mindestanforderungen die Staukontrolle folgen muss, um Überlast zu vermeiden.

Nicht nur bei der Staukontrolle ist Bewegung im Standardisierungsprozess. Längst gibt es mit Quic einen TCP-Konkurrenten, dem manche Beobachter gute Chancen geben, dem älteren Transportprotokoll den Rang abzulaufen. Quic brachte ursprünglich Google in die Standardisierung ein; es gründet auf UDP und bringt Verschlüsselung gleich mit.

Trotz des anfangs sprunghaft gestiegenen Quic-Verkehrs sieht Scharf mehrere Bereiche, in denen TCP seine Rolle als Basisprotokoll weiter spielen wird. Für kleinere Internetanbieter fehle vorerst noch entsprechende Server-Software. Bisher sind weder Apache noch NGINX für Quic ausgelegt, sodass viele Webseiten ohne das neue Protokoll abgerufen werden. Außerdem bleibe TCP das Protokoll der Wahl für den Austausch von Routing-Informationen, also für den BGP-Verkehr.

Und während ein Teil des Geschwindigkeitsvorteils von Quic darauf zurückgeht, dass die Ingenieure mehrere Protokollschichten miteinander verschränkt haben, lockt TCP weiterhin mit seinem konventionellen Konzept und leichter überschaubarer Funktionalität, weil es eben nur eine Kommunikationsschicht abbildet. Für manchen Entwickler, der vor der Wahl steht, dürfte das den Ausschlag für TCP geben, weil es schnellere Implementierung und leichtere Fehleranalyse verspricht.

Scharf rechnet aber damit, dass manche Neuerung, die Quic gebracht hat, auch für TCP erwogen wird. “Für RFC 9293 hat man sich dezidiert entschieden, in Bezug auf die Funktionalität des Protokolls so nah wie möglich am Text von RFC 793 zu bleiben.” Das sei auch der enormen Zahl an Implementierungen geschuldet. Je näher RFC 9293 am ursprünglichen Wortlaut bleibt, desto geringer die Wahrscheinlichkeit für Fehler aufgrund von unterschiedlichen Interpretationen in den kommenden Implementierungen. Für die Zukunft aber sieht er durchaus die Chance, dem guten alten TCP in Quic erprobte Funktionen beizubringen.


Mehr von c't Magazin


Mehr von c't Magazin


()

Read More

Leave a Reply

Your email address will not be published.