© mezzotint123rf, 123RF.com

Mit TCP Fast Open hat Google eine Protokollerweiterung zum Verringern unnötiger Latenzen im Netzwerkverkehr vorgestellt, die je nach Anwendungsfall eine Beschleunigung von bis zu 41 Prozent verspricht und es bereits in die aktuellen Linux-Kernel 3.6 (als Client) und 3.7 (als Server) geschafft hat.

Den Löwenanteil des heutigen Internetverkehrs machen recht kurzlebige Datenflüsse aus, etwa der typische Aufruf einer Website: Die Rechner bauen mehrere, nicht selten mehrere Dutzend gleichzeitige TCP-Sessions auf, um dann aber nur verhältnismäßig wenig Daten vieler kleiner Elemente (HTML-Code, Mini-Grafiken, Javascript und Ähnliches) zu übertragen. Der (Zeit-)Aufwand für den Verbindungsaufbau steht dabei in keinem günstigen Verhältnis zum transferierten Inhalt. Untersuchungen zufolge initiiert ein Drittel aller Requests neue Verbindungen, ein Viertel aller durch Latenz verursachten Wartezeit stammt vom Verbindungsaufbau [1].

Viele Browser kontern dies, jeder auf eine andere Art [2]: Um einem erneuten Verbindungsaufbau vorzubeugen, versuchen manche nach dem Erstaufruf der Seite ungenutzte TCP-Verbindungen offen zu halten (so genannte HTTP Persistent Connections). Das aber bindet Ressourcen und ärgert Admins: Insbesondere bei stark frequentierten Servern setzen sie mittlerweile die Timeout-Stellschrauben auf sehr kurze Zeiträume. Bessere Ansätze bietet der Linux-Kernel ab Version 3.7 mit einem Google-Projekt: TCP Fast Open (TFO, [3]).

Latenzen vermeiden

Solche Störfaktoren erst gar nicht entstehen zu lassen und die Latenzen von vornherein zu vermeiden, das steht ganz oben auf dem Entwurf, den Mitte 2011 Googles “Make the Web faster”-Team um Sivasankar Radhakrishnan, Yuchung Cheng, Jerry Chu und Arvind Jain (den Autoren der Slides in [1]) unter dem Namen TCP Fast Open vorstellte.

Die Grundidee, den Aufbau einer TCP-Session effizienter zu gestalten, ist an sich nicht neu: Bereits 1994 spezifizierten RFC 1379 und RFC 1644 [4] mit T/TCP (Transactional TCP) im Prinzip ähnliche Vorgehensweisen. Doch wegen der von Charles Hannum im September 1996 zu ernsten Sicherheitsproblemen veröffentlichten Analysen [5] hat sich T/TCP nie auf breiter Front durchsetzen können. Die Arbeit war jedoch nicht umsonst: Aus dem daraus gewonnenen Wissen entwickelte nun das Google-Team mit TFO einen verbesserten Ansatz.

Linux ist gerüstet: Seit Kernel 2.6.34 ist TFO dabei [6], ab 3.6 samt Client-seitiger Infrastruktur, ab 3.7 auch als Server. Experimentierfreudige Benutzer können – einen topaktuellen Kernel vorausgesetzt – TCP Fast Open bereits aktivieren:

echo "1"> /proc/sys/net/ipv4/tcp_fastopen

»”1″« schaltet TFO für den Client-, »”2″« für den Serverbetrieb an. Das Setzen beider Bits (mit »”3″« ) aktiviert beide Modi. Mehr ist nicht nötig, ab sofort sollte zwischen allen derart konfigurierten Clients und Servern der Verbindungsaufbau deutlich schneller klappen, wenn Sockets und Clientsoftware mitspielen (siehe weiter unten in diesem Artikel).

Kernelquellen

Die praktische Umsetzung von TFO fand zwar bereits Eingang in den Linux-Kernel, aber die Feinheiten der Spezifikation werden in näherer Zukunft sicherlich noch für Detaildiskussionen auf diversen Mailinglisten führen. So ist beispielsweise der Algorithmus zum Generieren des TFO-Cookies implementationsabhängig: Je nach Server lässt sich die Priorität auf möglichst energiesparende oder auf hochperformante Ansätzen legen. Auch Aspekte der Sicherheit der Implementation bereiten sicherlich noch Arbeit, etwa der regelmäßige Austausch der Server-seitig zur Verschlüsselung der Client-IP genutzten Keys.

Wer sich in den Kernel-Quelltext rund um TFO einlesen will [7], findet den relevanten Code in der Datei »/net/ipv4/tcp_fastopen.c« , auch die genaue Vorgehensweise, wie das System das Cookie generiert. In »include/linux/tcp.h« (Listing 1) definieren die Entwickler die Rahmen für die Cookie-Größe.

01 /* TCP Fast Open */
02 #define TCP_FASTOPEN_COOKIE_MIN 4       /* Min Fast Open Cookie size in bytes */
03 #define TCP_FASTOPEN_COOKIE_MAX 16      /* Max Fast Open Cookie size in bytes */
04 #define TCP_FASTOPEN_COOKIE_SIZE 8      /* the size employed by this impl. */
05
06 /* TCP Fast Open Cookie as stored in memory */
07 struct tcp_fastopen_cookie {
08         s8      len;
09         u8      val[TCP_FASTOPEN_COOKIE_MAX];
10 };

Three Way Handshakes

Für den Aufbau einer TCP-Session ist nach dem klassischen Modell ein so genannter Three Way Handshake notwendig (Abbildung 1): Der Client fragt beim Verbindungsaufbau den entsprechenden Zielserver an (»SYN« , Synchronize), der antwortet gegebenenfalls mit einem »SYN ACK« , dass er die Verbindungsanfrage des Clients akzeptiert.

Abbildung 1: Der traditionelle Three Way Handshake des TCP-Verbindungsaufbaus.

Während dieser Phase setzen die Partner unter anderem die MSS fest (Maximum Segment Size, die zwischen den Verbindungsendpunkten maximal erlaubte Anzahl von Bytes an Nutzdaten in einem TCP-Segment) sowie die ISN (Initial Sequence Number, eindeutige Nummer zur Sicherstellung der Übertragung in korrekter Reihenfolge und Erkennung von Dubletten). Es findet jedoch noch kein Austausch von Nutzdaten statt.

Zwar erlauben es die TCP definierenden RFCs ([8], [9]), bereits hier Nutzdaten zu übermitteln, aber nicht ihre Weiterverarbeitung vor Abschluss des kompletten Verbindungsaufbaus. Den schließt der Client, der mit »ACK« antwortet, ab. Im Regelfall gelangen erst danach Nutzdaten an den Server, etwa die Adresse der Seite, die der Browser anzeigen soll.

Ein Cookie hilft Roundtrips einsparen

Bis zum ersten Transfer von Nutzdaten in Schritt drei des Verbindungsaufbaus sind die Pakete also bereits einmal vom Client zum Server hin- und wieder zurückgelaufen, ein Roundtrip also, und der hat die Roundtrip Time (RTT) benötigt. Nicht selten dauert die mehrere Dutzend Millisekunden, in mobilen Netzen auch mehr als 100 Millisekunden, im GSM-Netz mit schlechtem Empfang auch schon mal mehrere Zehntelsekunden.

Die Wartezeit ist zwar lästig, hat aber auch Sinn: Durch einen abgeschlossenen Verbindungsaufbau lassen sich unter anderem doppelt versandte »SYN« -Anfragen erkennen und verwerfen, die durch Netzwerkprobleme oder eventuell auch böswillig entstanden sind. Auch Angreifer, die mit Spoofing versuchen einen anderen Absender vorzugaukeln, haben es deshalb schwerer.

Dem muss TFO anders begegnen: Google hat sich vorgenommen, aus den Fehlern der Vergangenheit zu lernen, und will Sicherheitsprobleme wie die bei T/TCP vermeiden. Deshalb spezifiziert der Konzern so genannte TFO-Cookies: Bei der ersten Verbindungsanfrage eines TFO-fähigen Clients generiert der angefragte Server sofort das Cookie und sendet es für spätere Verbindungsaufbauten bereits im zweiten Schritt (»SYN-ACK« ) an den Client (Abbildung 2).

Abbildung 2: Der Verbindungsauf mit TCP Fast Open erzeugt ein TFO-Cookie, das den Client fortan wie ein Token identifiziert.

Außer dem virtuellen Keks tauschen die Rechner zu diesem Zeitpunkt keine weiteren Daten aus. Das Server-seitig erzeugte Cookie aber enthält die verschlüsselte IP-Adresse des Clients. Die Prozedur des Anfragens, Erzeugens und den Austausch des Cookies erledigt der TCP-Stack des Kernels, die Anwendungsentwickler sind aus dem Schneider.

Wie bei einem Token weist der Besitz den Client als berechtigt aus, in den Genuss der TFO-Abkürzung zu kommen. Für den Client stehen bei Bedarf spezielle Flags (»MSG_TFO« ) für die Systemcalls »sendto()« und »sendmsg()« bereit, für etwa einen Apache-Server gibt es Socket-Parameter wie »TCP_FASTOPEN« [10]. Googles Browser Chrome nutzt TFO bereits seit 2010, wenn ihn der User mit »–enable-tcp-fastopen« gestartet hat.

Neue TCP-Optionen

Nach erfolgreichem Abschluss des ersten Verbindungsaufbaus (mit den bereits beim traditionellen TCP üblichen drei Schritten) verfügt der Client jetzt über das TFO-Cookie, mit dem er künftige Verbindungen um einen kompletten Paketumlauf abkürzen kann. Dann sendet er bereits beim »SYN« -Request das TFO-Cookie und erste Nutzdaten, etwa eine URL, an den Server.

Damit das klappt, haben die Entwickler extra eine neue TCP-Option eingeführt: Der angefragte Server validiert das Cookie und stellt somit sicher, dass die im Cookie verschlüsselt hinterlegte IP-Adresse mit der des anfragenden Clients übereinstimmt. Im Erfolgsfall kann der Server bereits im zweiten Schritt des Verbindungsaufbaus und damit vor Empfang des »ACK« durch den Client Nutzdaten zurücksenden; verglichen mit dem traditionellen Weg spart dies eine vollständige RTT (Abbildungen 3 und 4).

Abbildung 3: Bei jedem weiteren Verbindungsaufbau überträgt der Client sein Cookie sofort, der Server antwortet mit Daten bereits im »SYN-ACK«-Paket.

http://1, S. 16)” width=”300″ height=”224″ /> Abbildung 4: Eine Präsentation der Entwickler zeigt das Potenzial, das TFO birgt. (Quelle: http://1, S. 16)

Für den Fall, dass der Server den Client nicht positiv validieren kann, sendet er keine Daten an den Client zurück, stattdessen greift als Fallback-Mechanismus der herkömmliche Drei-Wege-Handshake. Der Server bestätigt dem anfragenden Client lediglich den Empfang mit einem »ACK« .

Pools schwebender Verbindungen wehren Angriffe ab

Dass ein Client mit gültigem TFO-Cookie bereits Ressourcen auf dem Server in Anspruch nehmen kann, bevor der Handshake komplett abgewickelt ist, öffnet allerdings Resource-Exhaustion-Attacken auf den Server Tür und Tor. Doch dagegen hilft das auch im Falle von SYN-Flood-Attacken erfolgreiche Mittel eines begrenzten Pools “schwebender” Verbindungen, also solcher Verbindungen, die zwar ein gültiges TFO-Cookie enthalten, aber noch nicht den kompletten Handshake durchlaufen haben. Ist dieser Pool erschöpft, forciert der Server die Nutzung des traditionellen Weges.

Was in naher Zukunft noch nötig sein wird, ist neben der Implementierung in diversen Betriebssystemen die Vergabe einer offiziellen TCP Option Number durch die IANA, da TFO bisher pro forma auf eine TCP Experimental Option Number zurückgreift.

Von den niedrigen Latenzen profitieren hauptsächlich Admins und Benutzer, etwa bei Webservern. Für Anwendungsentwickler entsteht normalerweise keine zusätzliche Arbeit. Programme, die mit TFO nichts anfangen können, laufen aufgrund des automatischen Fallback mit den traditionellen TCP-Handshakes weiter. Dies betrifft auch Geräte wie Router, Firewalls und ähnliche, die mit bereits im »SYN« -Segment untergebrachten Nutzdaten nichts anfangen können.