QUIC: Das steckt hinter dem ex­pe­ri­men­tel­len Google-Protokoll

Dank immer schnel­le­rer DSL-Zugänge ist die Ladezeit von In­ter­net­sei­ten im All­ge­mei­nen immer geringer geworden. In der Kon­se­quenz werden schnelle Sei­ten­auf­ru­fe heute als selbst­ver­ständ­lich angesehen, sodass langsam ladende Web­pro­jek­te kaum noch Chancen haben, auf dem Markt zu bestehen. Er­schwe­rend kommt hinzu, dass auch das Thema Ver­schlüs­se­lung zunehmend an Bedeutung gewinnt: Der HTTPS-Standard erweist sich zwar als ver­läss­li­cher Ver­bün­de­ter beim Schutz der Nutzer-Pri­vat­sphä­re, hat aber durch TLS-Handshake sowie Zer­ti­fi­kats- und Schlüs­sel­aus­tausch eine zu­sätz­li­che Ver­zö­ge­rung des La­de­pro­zes­ses zur Folge – eine Situation, die das von Google in­iti­ier­te QUIC-Protokoll zukünftig lösen soll.

Bei QUIC handelt es sich um ein ex­pe­ri­men­tel­les Trans­port­pro­to­koll des Such­ma­schi­nen­rie­sen Google, das der Öf­fent­lich­keit erstmals im Jahr 2013 vor­ge­stellt wurde. Der Name des Pro­to­kolls steht dabei für „Quick UDP Internet Con­nec­tions“, was darauf zu­rück­zu­füh­ren ist, dass es das schnelle und un­kom­pli­zier­te Versenden einfacher Da­ten­pa­ke­te über das ver­bin­dungs­lo­se UDP-Protokoll (User Datagram Protocol) er­mög­licht. Hin­ter­grund der Arbeiten an QUIC war der Wunsch, eine Al­ter­na­ti­ve zu der eta­blier­ten Si­cher­heits­lö­sung aus TCP, HTTP/2 und TLS/SSL zu ent­wi­ckeln, die den gleichen Schutz bietet, gleich­zei­tig aber eine re­du­zier­te Ver­bin­dungs- und Trans­port­ver­zö­ge­rung aufweist und Multiplex-Ver­bin­dun­gen er­mög­licht.

Google hat QUIC zu diesem Zweck so entworfen, dass das Protokoll die Ver­bin­dungs­kon­trol­le selbst regelt. Beim ersten Handshake zwischen Sender und Empfänger tauschen diese die Zer­ti­fi­ka­te und Schlüssel aus, die für die Ver­schlüs­se­lung der ver­sen­de­ten Da­ta­gram­me benötigt werden. Bei späteren Kom­mu­ni­ka­tio­nen entfällt dieser Austausch, was die Latenz minimiert. Als Ver­schlüs­se­lungs­pro­to­koll kommt dabei die aktuelle, ge­schwin­dig­keits­op­ti­mier­te TLS-Version 1.3 (im März 2017 stan­dar­di­siert) zum Einsatz, die den Vorzug vor der haus­ei­ge­nen Crypto-Lösung erhielt. In Sachen Mul­ti­plex­ing ori­en­tiert sich QUIC an dem ebenfalls von Google er­ar­bei­te­ten SPDY-Protokoll, das die Vorlage zu HTTP/2 gab: Über eine einzige Client-Server-Ver­bin­dung können mehrere ver­schie­de­ne Da­ten­strö­me über­tra­gen werden, wodurch die Ladezeit zu­sätz­lich reduziert wird.

Einige wichtige Ei­gen­schaf­ten und Vorzüge von QUIC sind bereits zur Sprache gekommen, sollen an dieser Stelle gemeinsam mit weiteren Ver­bes­se­run­gen aber noch einmal etwas genauer be­leuch­tet werden. Als Ver­gleichs­pro­to­koll dient TCP, das zwar als Weg­be­rei­ter im Konzept des auf­stre­ben­den Trans­port­pro­to­kolls eine wichtige Rolle spielt, dem Google-Protokoll aber in einigen Punkten deutlich un­ter­le­gen ist, wie folgende Vorteile von QUIC ver­deut­li­chen.

Der Haupt­grund für das Per­for­mance-Plus von QUIC gegenüber TCP ist der we­sent­lich schnel­le­re Ver­bin­dungs­auf­bau. Selbst ohne Ver­schlüs­se­lung via SSL/TLS setzt eine Ver­bin­dung über das klas­si­sche Trans­port­pro­to­koll mit dem so­ge­nann­ten Drei-Wege-Handshake mehr Schritte voraus als die UDP-basierte Google-Lösung. QUIC startet eine Ver­bin­dung mit einem einzigen Paket (bzw. zwei Paketen, wenn es sich um die erste Ver­bin­dungs­auf­nah­me handelt) und über­mit­telt dabei sogar alle not­wen­di­gen TLS- bzw. HTTPS-Parameter. In den meisten Fällen kann ein Client also Daten direkt an einen Server senden, ohne auf eine Antwort von diesem an­ge­wie­sen zu sein, während TCP zunächst die Be­stä­ti­gung des Servers einholen und ver­ar­bei­ten muss.

TCP greift auf die TCP-Ports und IP-Adressen der ver­bun­de­nen Systeme zurück, um eine Ver­bin­dung zu iden­ti­fi­zie­ren. Aus diesem Grund ist es nicht möglich, dass ein Client in einer einzigen Ver­bin­dung über mehrere Ports mit dem Server kom­mu­ni­ziert. Das QUIC-Protokoll löst die Situation auf andere Weise: Es greift auf eine 64-Bit-Ver­bin­dungs­er­ken­nung und ver­schie­de­ne „Streams“ zum Transport der Daten innerhalb einer Ver­bin­dung zurück. Eine QUIC-Ver­bin­dung ist daher nicht an einen be­stimm­ten Port (in diesem Fall UDP-Port), eine IP-Adresse oder einen be­stimm­ten Endpunkt gebunden. Port- und IP-Wechsel sind in der Kon­se­quenz ebenso möglich wie die bereits er­läu­ter­ten Multiplex-Ver­bin­dun­gen.

Jedes Da­ten­seg­ment einer QUIC-Ver­bin­dung erhält eine eigene Se­quenz­num­mer, un­ab­hän­gig davon, ob es sich um ein ori­gi­na­les oder um ein wei­ter­ge­lei­te­tes Segment handelt. TCP macht diesen Un­ter­schied stan­dard­mä­ßig nicht, weshalb ein Host den Status einer Sequenz auch nicht ermitteln kann – erst durch den Einsatz der Timestamps-Er­wei­te­rung (dt. „Zeit­stem­pel“) er­mög­licht auch das klas­si­sche Trans­port­pro­to­koll eine solche Un­ter­schei­dung. Die fort­lau­fen­de Mar­kie­rung der Pakete ist deshalb von Vorteil, weil sie eine ak­ku­ra­te­re Schätzung der Pa­ket­um­lauf­zeit (RTT: Round Trip Time) er­mög­licht.

Verloren gegangene Pakete stellen beim Da­ten­trans­port über QUIC kein großes Problem dar. Dank eines einfachen XOR-basierten Feh­ler­kor­rek­tur­sys­tems ist keine erneute Über­tra­gung der ent­spre­chen­den Daten notwendig. Diese können jederzeit mithilfe von FEC-Paketen (Forward Error Correction) – Back-ups der Ori­gi­nal­pa­ke­te für eine Da­ten­grup­pe – re­kon­stru­iert werden. Die Feh­ler­kor­rek­tur funk­tio­niert al­ler­dings nicht, wenn mehrere Pakete einer Da­ten­grup­pe fehlen.

TCP versucht Daten immer so schnell wie möglich zu versenden, was für schnelle Da­ten­ver­bin­dun­gen zwar von Vorteil, aber auch mit einer gewissen Ver­lust­ra­te verbunden ist. Geht ein Paket verloren, wird ebenso schnell die Neu­über­tra­gung (TCP Fast Re­trans­mit) initiiert. Hierfür ver­klei­nert TCP jedoch vor­über­ge­hend das Stau­fens­ter, was häufig zur Folge hat, dass die Daten stoßweise über­tra­gen werden. Das QUIC-Protokoll wirkt der­ar­ti­gen Last­spit­zen mithilfe des so­ge­nann­ten Packet Pacing entgegen. Das Verfahren sorgt dafür, dass die Über­tra­gungs­ra­te au­to­ma­tisch begrenzt wird. So kommt es auch bei Ver­bin­dun­gen mit geringer Band­brei­te nicht zu Über­las­tun­gen. Neu ist diese Technik jedoch nicht: Einige Linux-Kernel nutzen das Verfahren auch für das TCP-Protokoll.

Der Si­cher­heits­aspekt stand bei der Planung und Kon­zi­pie­rung von QUIC von Beginn an im Fokus. Im Zuge dessen haben sich die Ent­wick­ler auch einem der größten Probleme von TCP gewidmet: Der Header der ver­schick­ten Pakete liegt im Klartext vor und kann ohne vorherige Au­then­ti­fi­zie­rung gelesen werden. Man-in-the-Middle-Attacken und Pa­ket­ma­ni­pu­la­tio­nen (z. B. der Se­quenz­num­mern) sind daher keine Sel­ten­heit. QUIC-Pakete jedoch sind immer au­then­ti­fi­ziert und größ­ten­teils ver­schlüs­selt (inklusive Payload). Die Teile des Headers, die nicht in ver­schlüs­sel­ter Form vorliegen, sind aufgrund der Au­then­ti­fi­zie­rung auf Emp­fän­ger­sei­te vor Injektion und Ma­ni­pu­la­ti­on geschützt.

Ein weiterer großer Vorteil von QUIC gegenüber TCP: Das Google-Protokoll ist vom System losgelöst. Während das TCP-Protokoll von den je­wei­li­gen Platt­for­men bzw. Geräten un­ter­stützt werden muss, damit eine Kom­mu­ni­ka­ti­on möglich ist, ist die QUIC-Un­ter­stüt­zung lediglich auf An­wen­dungs­ebe­ne notwendig. Software-Firmen haben es also prin­zi­pi­ell selbst in der Hand, das Protokoll ein­zu­bin­den – sie sind dabei nicht auf die Hardware-Her­stel­ler an­ge­wie­sen. Bis dato sind es zwar vor allem Google-An­wen­dun­gen wie die Google-Server, Chromium oder Chrome, die über QUIC-Im­ple­men­tie­run­gen verfügen. Mit dem Browser Opera, der Server-Software Caddy und den Load-Balancing- und Webserver-Produkten von LiteSpeed Tech­no­lo­gies gibt es aber bereits Dritt­an­bie­ter-Ap­pli­ka­tio­nen, die Ver­bin­dun­gen über das neue Trans­port­pro­to­koll er­mög­li­chen.

Dass QUIC künftig wohl immer häufiger zum Einsatz kommen dürfte, ist vor allem auf das En­ga­ge­ment der IETF zu­rück­zu­füh­ren. Dank der An­pas­sun­gen an all­ge­mei­ne Standards seit Gründung der Ar­beits­grup­pe im Jahr 2016 hat sich das Protokoll von einem stark auf Google aus­ge­rich­te­ten zu einem all­ge­mei­nen Netz­werk­pro­to­koll ent­wi­ckelt, das zunehmend an Bedeutung gewinnt. Der Op­ti­mie­rungs­pro­zess ist al­ler­dings noch lange nicht ab­ge­schlos­sen: Das QUIC-Team befasst sich auch weiterhin mit be­stehen­den Problemen, für die es die passenden Lösungen zu finden gilt.

Ins­be­son­de­re das Thema Si­cher­heit, eines der wich­tigs­ten bei der Ent­wick­lung des Pro­to­kolls, sorgt dabei für Dis­kus­si­ons­stoff. Denn während Au­then­ti­fi­zie­rung und Ver­schlüs­se­lung zwei­fels­oh­ne für einen si­che­re­ren Da­ten­trans­port sorgen, sind sie gleich­zei­tig auch für einen ent­schei­den­den Nachteil von QUIC ver­ant­wort­lich: Da die Paket-Header weniger Klar­text­in­for­ma­tio­nen enthalten als es bei TCP-Ver­bin­dun­gen der Fall ist, sind Aufgaben wie Feh­ler­be­he­bung, Traffic-Re­gu­lie­rung oder Netzwerk-Ma­nage­ment bei QUIC-Ver­bin­dun­gen deutlich erschwert. Netz­be­trei­ber sowie Her­stel­ler von Firewalls und anderen Mit­tel­bo­xen sehen deshalb Schwie­rig­kei­ten darin, die Qualität ihrer Dienste zu ge­währ­leis­ten.

Ein weiteres Problem des QUIC-Pro­to­kolls ist, dass die au­to­ma­ti­sche Über­las­tungs­steue­rung bei Da­ten­ver­bin­dun­gen mit hoher Band­brei­te in einigen Fällen zu einer schlech­te­ren Über­tra­gungs­ra­te führen kann.

Wollen Sie das Protokoll de­ak­ti­vie­ren, wählen Sie einfach den Eintrag „Disabled“ aus und klicken an­schlie­ßend auf die Schalt­flä­che „JETZT NEU STARTEN“. Chrome wird in der Folge beendet – beim nächsten Start des Browsers sind die neuen Ein­stel­lun­gen aktiv. Wollen Sie das Protokoll wieder ak­ti­vie­ren, gehen Sie auf die gleiche Weise vor, wählen jedoch entweder die ei­gent­li­che Ein­stel­lung „Default“ oder al­ter­na­tiv den Punkt „Enabled“ aus.