Abo
  • Services:
Anzeige

Verbindungsturbo: Wie Googles Rack TCP deutlich schneller machen soll

Ethernet-Kabel
Ethernet-Kabel (Bild: Open Grid Scheduler / Grid Engine/CC0 1.0)

Mit dem Algorithmus Rack will Google das altehrwürdige TCP modernisieren und damit interaktive Anwendungen deutlich beschleunigen. Wir erklären, wie das funktionieren soll.
Eine Analyse von Wilhelm Nüßer

Das Transmission Control Protocol (TCP) ist ein altes Protokoll, aber immer noch eines der wichtigsten im Internet - trotz neuer Ansätze wie Quic. 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.

Anzeige

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).

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) relevant.

TCP und die verlorenen Segmente

Das von Google vorgeschlagene Rack (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.

  • Das alte, konventionelle TCP (Bild: W. Nüßer)
  • TCP-Verbesserung durch Dupack (Bild: W. Nüßer)
  • TCP-Verbesserung durch Sack (Bild: W. Nüßer)
  • Zeitlich verschobene Bestätigungen ...(Bild: W. Nüßer)
  • ... werden in Rack aktiv zum Beschleunigen genutzt. (Bild: W. Nüßer)
  • Rack hilft auch bei Tail Drops. (Bild: W. Nüßer)
Das alte, konventionelle TCP (Bild: W. Nüßer)

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 

eye home zur Startseite
Martin F. 04. Aug 2016

Mein letzter Stand war, dass bei Drittanbietern, die den Telekomanschluss nutzen, nur...

minecrawlerx 01. Aug 2016

Wir haben heute Speicher in rauen Mengen. Und Kernel Entwickler, die uns das...

ap (Golem.de) 29. Jul 2016

Bevor der Thread weiter abruscht, wird er geschlossen.

embr 28. Jul 2016

Es wird tatsächlich mal Zeit, TCP abzulösen (im Sinne von: töten, nicht, irgendwie mit...

yeti 28. Jul 2016

Ja das ist richtig. Problematisch wird es dann bei einem Live-Video-Stream vom Mars...



Anzeige

Stellenmarkt
  1. SEITENBAU GmbH, Konstanz
  2. Landesbetrieb IT.Niedersachsen, Hannover
  3. T-Systems International GmbH, Essen
  4. Robert Bosch Start-up GmbH, Ludwigsburg


Anzeige
Top-Angebote
  1. 66,90€ statt 89,90€
  2. 49,99€ statt 64,90€
  3. 79,90€ statt 109,90€

Folgen Sie uns
       


  1. Frontrow

    Halskette als Kamera zum Dauerfilmen

  2. Streetscooter Work XL

    Deutsche Post stellt Elektro-Lkw mit 200 km Reichweite vor

  3. Interview auf Youtube

    Merkel verteidigt Ziel von 1 Million Elektroautos bis 2020

  4. Ransomware

    Not-Petya-Angriff kostet Maersk 200 Millionen US-Dollar

  5. Spielebranche

    Mikrotransaktionen boomen zulasten der Kaufspiele

  6. Autonomes Fahren

    Fiat Chrysler kooperiert mit BMW und Intel

  7. Auto

    Toyota will Fahrzeugsäulen unsichtbar machen

  8. Amazon Channels

    Prime-Kunden erhalten Fußball-Bundesliga für 5 Euro im Monat

  9. Dex-Bytecode

    Google zeigt Vorschau auf neuen Android-Compiler

  10. Prozessor

    Intels Ice Lake wird in 10+ nm gefertigt



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Google Home auf Deutsch im Test: "Tut mir leid, ich verstehe das nicht"
Google Home auf Deutsch im Test
"Tut mir leid, ich verstehe das nicht"
  1. Kompatibilität mit Sprachassistenten Trådfri-Update kommt erst im Herbst
  2. Smarte Lampen Ikeas Trådfri wird kompatibel mit Echo, Home und Homekit
  3. Lautsprecher-Assistent Google Home ab 8. August 2017 in Deutschland erhältlich

Mercedes S-Klasse im Test: Das selbstfahrende Auto ist schon sehr nahe
Mercedes S-Klasse im Test
Das selbstfahrende Auto ist schon sehr nahe
  1. 3M Verkehrsschilder informieren autonom fahrende Autos
  2. Waymo Autonomes Auto zerstört sich beim Unfall mit Fußgängern
  3. Mobileye Intel will 100 autonom fahrende Autos auf die Straßen lassen

LG 34UC89G im Test: Wenn G-Sync und 166 Hertz nicht genug sind
LG 34UC89G im Test
Wenn G-Sync und 166 Hertz nicht genug sind
  1. LG 43UD79-B LG bringt Monitor mit 42,5-Zoll-Panel für vier Signalquellen
  2. Gaming-Monitor Viewsonic XG 2530 im Test 240 Hertz, an die man sich gewöhnen kann
  3. SW271 Benq bringt HDR-Display mit 10-Bit-Panel

  1. Re: schöne belanglose Unterhaltungen...

    Dieselmeister | 08:08

  2. Re: 200 km umgerechnet = maximal 2h fahrt mit 100Kmh

    Azzuro | 08:07

  3. Re: 8 Milliarden Diesel-Subventionen pro Jahr

    AllDayPiano | 08:05

  4. Re: 200km ist aber für ein Paket Fahrer ja nun...

    snadir | 08:04

  5. Re: [OT] functionalclam: "This page offers no...

    FreiGeistler | 08:03


  1. 07:40

  2. 07:21

  3. 16:57

  4. 16:25

  5. 16:15

  6. 15:32

  7. 15:30

  8. 15:02


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel