Verbindungsturbo: Wie Googles Rack TCP deutlich schneller machen soll
Das Transmission Control Protocol (TCP) ist ein altes Protokoll, aber immer noch eines der wichtigsten im Internet – trotz neuer Ansätze wie Quic(öffnet im neuen Fenster) . Es wurde entwickelt, als stark interaktive Kommunikationen, komplexe Netzwerkgeräte und schnelle Verbindungen noch in weiter Ferne lagen. Da TCP zudem ein geradezu zwanghaft sorgfältiges Protokoll ist, erscheint es heute oft als schwerfällig und langsam. Das will Google mit dem neuen Verfahren Rack ändern.
Das Unternehmen schlägt eine Anpassung der etablierten Verfahren von TCP vor, um das Protokoll schneller auf spezielle Fehlerfälle reagieren zu lassen. Dieser Vorschlag ist noch kein Internetstandard, aber bei einer Google-Initiative kann dies mitunter zumindest aus Sicht von Entwicklern sehr schnell gehen. Obwohl noch keine konkreten Zahlen den Effekt von Rack belegen, beschreiben wir deshalb schon diesen neuen Ansatz, der bereits im Linux-Kernel vorhanden ist und der von den Browsern Chrome und Edge genutzt wird.
Das kann TCP
Zunächst gilt es, TCP besser zu verstehen. Das Protokoll ist darauf ausgelegt, verbindungsorientiert, voll-duplex und zuverlässig zu sein. Dabei bedeutet zuverlässig, dass mit TCP sehr intensiv versucht wird, alle Segmente, die über eine TCP-Verbindung fließen, korrekt und in der richtigen Reihenfolge zu übertragen und dabei auch die Last des Netzwerks möglichst gering zu halten. Dafür muss TCP mindestens drei verschiedene Aufgaben erfüllen.
Erstens müssen verloren gegangene Segmente erkannt und behandelt werden. Dafür sendet der Empfänger Bestätigungen (Ack, kurz für Acknowledgement) an den Sender, der daraufhin mindestens die verlorenen Segmente erneut sendet.
Zweitens implementiert TCP eine Flusskontrolle, durch die die Verarbeitungsgeschwindigkeiten von Sender und Empfänger aneinander angepasst werden. Die Sendegeschwindigkeit wird dafür durch ein sogenanntes Receive-Window beschränkt ( RFC 793(öffnet im neuen Fenster) ).
Drittens verwendet TCP eine Überlaststeuerung (Congestion Control), die nicht nur die Kommunikation zweier Partner, sondern die Last im Netzwerk optimieren soll. Auch hier muss sich der Sender beschränken. Die Art und Weise, wie dies geschieht, hat sich im Laufe der Jahre verändert. Derzeit sind Verfahren wie Slow Start und Fast Recovery ( RFC 5681(öffnet im neuen Fenster) ) relevant.
TCP und die verlorenen Segmente
Das von Google vorgeschlagene Rack(öffnet im neuen Fenster) (Recent Acknowledgement) widmet sich primär der Frage nach den verlorenen Segmenten. Für eine erfolgreiche Neuübertragung (Retransmit) sind stets zwei Fragen zu beantworten. Einerseits: Was ist erneut zu senden? Und: Wann wird es erneut gesendet?
Für TCP sind in seiner Geschichte immer ausgefeiltere Antworten auf diese Fragen gefunden worden. Rack ist das derzeit letzte Glied in dieser Kette und nur auf der Basis der vorhergehenden Ansätze zu verstehen. Die genaue Beschreibung von Rack beginnt deshalb zunächst mit dem klassischen Verfahren von TCP, das in Abbildung 1 vorgestellt wird.
In diesem Verfahren bestätigt TCP stets nur vollständige und korrekte Abfolgen von Segmenten. Dazu hat TCP die Konvention eingeführt, dass der Empfänger als Bestätigung die Nummer des jeweils nächsten erwarteten Segments zurücksendet. Wenn diese Bestätigung innerhalb einer bestimmten Zeit (Timer) eintrifft, die durch die Laufzeiten im Netzwerk berechnet wird, gilt das Segment als korrekt versendet.
Wenn nun aber wie in Abbildung 1 das erste Segment verloren geht, kann der Empfänger dieses Segment nicht bestätigen: Die Bestätigungszahl bleibt gleich (hier: 1). Der Sender erhält damit innerhalb des Timers keine passende Bestätigung und muss nach Ablauf dieser Zeit erneut senden. Da die an sich korrekt empfangenen Segmente 2 und 3 nicht in der korrekten Reihenfolge sind ("out of order", OOO), müssen sie in diesem Verfahren ebenfalls erneut gesendet werden.
Offensichtlich ist dieses klassische Verfahren, das laut üblichem Sprachgebrauch mit "kumulativen Acks" und einem globalen Timer arbeitet, zwar einfach zu implementieren, erkennt aber verlorene Segmente erst spät und führt zu vielen überflüssigen Neuübertragungen. Schon früh haben sich die TCP-Designer deshalb Gedanken über Verbesserungen gemacht. Das von Google vorgeschlagene Rack reiht sich damit in eine Liste mehrerer unterschiedlicher Versuche ein.
Rack zeigt: TCP kann es immer besser
Eine erste Optimierung Dupack, die in Abbildung 2 skizziert ist, soll das Erkennen eines Verlusts beschleunigen, also die Frage nach dem "Wann" beantworten. Wenn sich eine Bestätigungsnummer mehrfach (in der Regel dreimal, hier aus Platzgründen zweimal) nicht ändert, geht der Algorithmus davon aus, dass das zugehörige Segment verloren ging. Eine Neuübertragung kann damit auch vor Ablauf des Timers stattfinden. Dieser Ansatz wird deshalb auch als Fast Retransmit bezeichnet. Er zeigt in der Praxis allerdings Schwächen bei modernen Anforderungen, die Rack besser adressiert.
Eine zweite, für das Folgende sehr wichtige Optimierung soll die Menge der erneut zu sendenden Segmente reduzieren, also die Frage nach dem "Was" beantworten. Dazu werden auch OOO-Segmente beim Eintreffen am Empfänger "selektiv" bestätigt (Selective Acknowledgement, Sack, RFC 2018(öffnet im neuen Fenster) ). Dies geschieht über eine Option im TCP-Header und ist damit in der Implementierung durchaus aufwendig. Der Sender weiß nun, dass Segment 2 und 3 angekommen sind und muss nur noch Segment 1 erneut zu senden. Abbildung 3 zeigt das Verhalten von Sack. Dort wird es mit der Optimierung der Zeit gemäß Dupack kombiniert. Allerdings spricht nichts dagegen, auch andere Algorithmen zu verwenden, die die Zeit bis zur Erkennung einer notwendigen Neuübertragung reduzieren.
Genau an dieser Stelle setzt nun Googles Rack an. Es baut auf Sack auf, um die Menge der erneut zu sendenden Segmente zu begrenzen. Dann merkt es sich für jedes Segment den Zeitpunkt des Sendens. Ein verlorenes Segment wird auf dieser Basis dann dadurch erkannt, wenn ein später gesendetes Segment durch Ack oder Sack bestätigt wurde. Dafür kann jedes Segment genutzt werden, sei es erstmalig oder erneut versendet worden.
Die Vorteile von Rack
An zwei stark vereinfachten Beispielen sollen die Vorteile von Rack erläutert werden. In Abbildung 4 wird dafür zunächst eine einfache Abweichung von Abbildung 3 dargestellt: die beiden Bestätigungen werden im Netz irgendwo umgeordnet und eine geht deshalb erst nach dem Ablauf des Timers ein. Dies kann z. B. geschehen, wenn Segment 3 merklich weniger Daten trägt, weil die Anwendung nur noch wenige Daten zu senden hat, und damit schneller befördert wird.
Es handelt sich hier also nicht um ein generell langsames Netz, sondern um eine segmentspezifische Situation. In diesem Fall würde der bisherige Algorithmus mit Dupack und Sack nicht zu einer beschleunigten Neuübertragung von Segment 1 führen. In Abbildung 5 ist allerdings zu sehen, dass mit Segment (A1, SACK3) ein später gesendetes Segment bestätigt wurde. Rack schließt damit auf den Verlust von Segment 1 und startet die Neuübertragung nun früher.
Ein zweites Beispiel beschreibt das Verhalten von Rack bei den sogenannten Tail Drops, also Situationen, bei denen Segmente am Ende einer Übertragung verloren gehen, wie in Abbildung 6. Das geschieht zum Beispiel bei manchen Routern, wenn deren interne Queues überlaufen, die später eintreffenden Pakete also auf IP-Ebene verworfen werden. In diesem Fall reicht Rack schon ein einzelnes Bestätigungssegment (in Abbildung 6 gemäß kumulativen ACKs als A3 bezeichnet) für die erneute Versendung von Segment 3. Auch hier startet damit die erneute Sendung schneller.
Auch wenn zurzeit noch wenige praktische Erfahrungen mit Rack vorliegen, zeigt die Diskussion darum doch, wie Rack in vielen heute relevanten Situationen schneller als bisherige Implementierungen sein kann. Wohl auch deshalb experimentieren Google in Chrome ebenso wie Microsoft in dem Edge-Browser mit Rack.
Allerdings werden die Informationen, die die TCP-Implementierungen im Betriebssystem-Kern vorhalten müssen, wieder umfangreicher. Aber das soll ja nicht das Problem der Anwendungsentwickler und Nutzer sein. Schließlich gibt es Kernel-Entwickler, die sich gern mit solchen Problemen herumschlagen. Im Fall des Linux-Kernels ist dies von Google-Angestellten bereits umgesetzt worden. Für Provider und Nutzer kann ein so beschleunigtes TCP eigentlich nur von Vorteil sein.
Der Autor Wilhelm Nüßer ist Professor für Informatik an der FHDW Paderborn. Er lehrt dort unter anderem Netzwerke und verteilte Systeme und leitet zahlreiche Forschungsprojekte.
- Anzeige Hier geht es zu Linux: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.