{"id":12206,"date":"2021-02-18T17:16:56","date_gmt":"2021-02-18T16:16:56","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=12206"},"modified":"2023-06-18T18:08:18","modified_gmt":"2023-06-18T16:08:18","slug":"quic-die-zukunft","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/02\/18\/quic-die-zukunft\/","title":{"rendered":"QUIC – Die Zukunft?"},"content":{"rendered":"\n

QUIC soll als neuer Standard das weit verbreitete TCP-Protokoll abl\u00f6sen. Welche Neuerungen QUIC mitbringt, wo seine St\u00e4rken liegen und warum \u00fcberhaupt eine Weiterentwicklung von TCP ben\u00f6tigt wird, versuche ich in diesem Artikel zu beantworten.<\/p>\n\n\n\n\n\n\n\n

QUIC allgemein<\/h3>\n\n\n\n

Um zu verstehen, was QUIC ist und was es verbessern m\u00f6chte, muss man zuerst einen Blick auf die heute verwendeten Protokolle werfen.
In den meisten F\u00e4llen stellt man heute eine Anfrage \u00fcber das HTTP\/2 Protokoll, das auf dem Transportprotokoll TCP basiert. Dieses wird als Basis verwendet, da es sich um ein robustes und zuverl\u00e4ssiges Protokoll handelt. Wenn ein TCP-Paket seinen Empf\u00e4nger nicht erreicht, wird das verloren gegangene Paket erneut angefordert. Dar\u00fcber hinaus garantiert TCP, dass die empfangenen Pakete in der selben Reihenfolge verarbeitet werden, in der sie versendet wurden.
HTTP\/2 und TCP sind Protokolle, die keine Verschl\u00fcsselung implementiert haben. Damit trotzdem verschl\u00fcsselt \u00fcbertragen werden kann, wird im Fall von HTTPS zus\u00e4tzlich TLS zur Verschl\u00fcsselung eingesetzt. [4]<\/p>\n\n\n\n

QUIC ist dahingegen ein Protokoll, dass nicht mehr auf TCP sondern auf UDP aufbaut. UDP ist im Vergleich zu TCP nicht robust und zuverl\u00e4ssig. Der Ansatz von UDP entspricht eher dem “‘Fire and Forget”‘ Ansatz. [1] Geht ein UDP Paket beispielsweise auf dem Weg zum Empf\u00e4nger verloren, wird dieses nicht erneut angefordert. Auch die Reihenfolge der empfangenen Pakete ist irrelevant.
UDP hat sich vor allem im Bereich des Streamings durchgesetzt. Wenn innerhalb eines Frames f\u00fcr einen einzelnen Pixel nicht alle Informationen empfangen wurden, ist dies nicht schlimm, da das menschliche Auge diesen Fehler mit recht hoher Wahrscheinlichkeit gar nicht erst wahr nimmt.
Dar\u00fcber hinaus besitzt UDP keinen Verbindungs-Handshake, wie das bei TCP der Fall ist (3-Way-Handshake).<\/p>\n\n\n\n

\"\"<\/a>
Vereinfachtes ISO\/OSI Schichtenmodell<\/figcaption><\/figure>\n\n\n\n

Da QUIC der Nachfolger von TCP werden soll, kann man sich an dieser Stelle berechtigterweise die Frage stellen, warum UDP als Basis verwendet wird. Es w\u00e4re auf den ersten Blick sicherlich logischer das TCP Protokoll weiterzuentwickeln. Dies f\u00fchrt aber zu einem entscheidenden Nachteil.
TCP liegt genauso, wie UDP und alle darunterliegenden Protokolle, wie beispielsweise IP, im sogenannten Kernel-Space. Dieser ist ein Teil des Betriebssystems. Beim \u00c4ndern der im Kernel-Space implementierten Protokolle muss daher der Kernel und damit das gesamte Betriebssystem, aktualisiert werden. Bei Millionen an Middle-Boxes, die unsere Anfragen durch das Internet routen, w\u00fcrde es Jahre dauern die teilweise heute schon stark veralteten Middle-Boxes zu aktualisieren. [1][2]<\/p>\n\n\n\n

QUIC ist im sogenannten User-Space implementiert. Das bedeutet, dass QUIC auf Anwendungsebene, wie beispielsweise in einem Browser, implementiert ist. Bei \u00c4nderungen des Protokolls muss daher auch nicht der Kernel-Space angepasst werden.
Einerseits hat dies den Vorteil, dass nicht erst alle Middle-Boxes aktualisiert werden m\u00fcsse. UDP ist bereits ein weitverbreitetes Protokoll und wird fl\u00e4chendeckend unterst\u00fctzt. Auf der anderen Seite k\u00f6nnen \u00c4nderungen deutlich schneller ausgespielt werden, wenn daf\u00fcr zum Beispiel nur die Aktualisierung des Browsers notwendig ist. Tests werden hierdurch auch vereinfacht. [1][2]<\/p>\n\n\n\n

Damit QUIC dieselbe Robustheit und Zuverl\u00e4ssigkeit wie TCP erreicht, m\u00fcssen die entsprechende Algorithmen in QUIC implementiert werden. Aus diesem Grund kann auch das unzuverl\u00e4ssigere aber flexiblere Protokoll UDP als Basis verwendet werden.
Zusammenfassend kann man sagen, dass QUIC die Schnelligkeit von UDP mit der Robustheit und der Zuverl\u00e4ssigkeit von TCP vereinen m\u00f6chte. [2]<\/p>\n\n\n\n

Eine weiter \u00c4nderung, die sich durch die Verwendung von QUIC und damit auch bei der Verwendung von HTTP\/3 ergibt, ist die standardm\u00e4\u00dfige Verschl\u00fcsselung. Bei den vorherigen HTTP-Versionen (HTTP 1.0, HTTP 1.1 und HTTP\/2) musste TLS als zus\u00e4tzliches Protokoll zur Verschl\u00fcsselung eingebunden werden.
Da QUIC selbst schon Algorithmen beinhaltet, die Multiplexing (Zusammenfassen) von Verbindungen erlaubt, muss eine neue HTTP Version (HTTP\/3) entwickelt werden. Diese hat einen geringeren Funktionsumfang als HTTP\/2, da neben dem Multiplexing von Verbindungen auch bereits Funktionalit\u00e4t zum Verbindungsmanagement in QUIC implementiert ist. [2]<\/p>\n\n\n\n

Initialer Verbindungsaufbau<\/h3>\n\n\n\n
\"\"<\/a>
HTTP\/2 Handshake [4]<\/figcaption><\/figure>\n\n\n\n

Wenn man mit HTTP\/2 eine Webseite aufrufen m\u00f6chte, muss zun\u00e4chst die TCP-Verbindung aufgebaut werden. Dabei wird der sogenannte 3-Way-Handshake des TCP-Protokolls ausgef\u00fchrt. Im ersten Schritt sendet der Client eine Anfrage (SYN) an den Server. Wenn dieser die Verbindung annimmt, antwortet er dem Client (SYN+ACK), dass er bereit ist Daten zu empfangen. Der Client muss daraufhin dem Server best\u00e4tigen, dass er dessen Antwort erhalten hat. Wenn diese Nachricht beim Server ankommt, ist der 3-Way-Handshake abgeschlossen und Nachrichten k\u00f6nnen \u00fcber TCP ausgetauscht werden.
Nach dem Aufbauen der TCP Verbindung muss zwischen dem Client und dem Server noch die Verschl\u00fcsselung mit TLS aufgebaut werden. Der Aufbau ben\u00f6tigt genauso, wie der Verbindungsaufbau von TCP, drei Nachrichten. [3][4]<\/p>\n\n\n\n

An dieser Stelle befindet sich bereits ein Problem. Das eigentliche Anliegen, also die HTTP-Anfrage an den Server wird erst nach diesem initialen Verbindungsaufbau an den Server gesendet. Umso mehr Pakete beim initialen Verbindungsaufbau \u00fcbertragen werden m\u00fcssen, desto l\u00e4nger dauert es, bis die eigentliche Anfrage beantwortet wird.
Dies f\u00fchrt vor allem dann zu Problemen, wenn ein Server sehr weit von einem Client entfernt ist. Durch die gro\u00dfe Entfernung kann die Latenz der Verbindung sehr hoch sein, was zu langen \u00dcbertragungszeiten f\u00fchrt. Verbunden mit der gro\u00dfen Anzahl an Paketen, die f\u00fcr den initialen Verbindungsaufbau ben\u00f6tigt werden, k\u00f6nnen Anfragen sehr lange dauern. Mit weniger Paketen, die \u00fcbertragen werden m\u00fcssen, k\u00f6nnte die Anfrage schneller beantwortet werden. [1]<\/p>\n\n\n\n

\"\"<\/a>
HTTP\/3 Handshake [4]<\/figcaption><\/figure>\n\n\n\n

An diesem Problem setzt QUIC an.
Initial besitzt UDP keinen Verbindungsaufbau. Um QUIC jedoch zuverl\u00e4ssiger zu machen, gibt es an dieser Stelle auch eine Art 3-Way-Handshake. Die Besonderheit an dieser Stelle ist jedoch, dass im Rahmen dieses Handshakes auch die Verschl\u00fcsselung aufgebaut wird. Nach dem Verbindungsaufbau kann dann die eigentliche HTTP-Anfrage \u00fcbertragen werden.
Unter HTTP\/2 wird im Vergleich dazu die TLS-Verschl\u00fcsselung erst nach dem Einrichten der Verbindung aufgebaut. [4]
Insgesamt bedeutet die Umstellung auf QUIC eine Halbierung der Paket, die f\u00fcr den initialen Verbindungsaufbau notwendig sind. Damit verbunden dauert der Handshake in der Theorie auch nur halb so lange.<\/p>\n\n\n\n

HTTP<\/h3>\n\n\n\n

Ein weiterer Grund f\u00fcr die Einf\u00fchrung von QUIC ist das sogenannte Head-of-Line Blocking. Dieses ist am Besten zu verstehen, wenn man die Entwicklung des HTTP Protokolls n\u00e4her betrachtet.<\/p>\n\n\n\n

HTTP 1.0<\/h4>\n\n\n\n

Bei der Verwendung von HTTP 1.0 muss f\u00fcr jeden Request eine neue eigene Verbindung aufgebaut werden. Das bedeutet, dass zwei Anfragen an den selben Server jeweils ihre eigene HTTP-Verbindung aufbauen m\u00fcssen. Dies beinhaltet pro Verbindung einen eigenen TCP- und TLS-Handshake. [4]<\/p>\n\n\n\n

HTTP 1.1<\/h4>\n\n\n\n
\"\"<\/a>
Anfagen mehrerer Ressourcen unter HTTP 1.1 [4]<\/figcaption><\/figure>\n\n\n\n

Da ein HTTP-Verbindungsaufbau durch seine Dauer ein recht “‘teures”‘ Vorhaben ist, wurde mit HTTP 1.1 die Idee verfolgt, Verbindungen wiederzuverwenden. Bei der Verwendung von HTTP 1.1 werden daher alle Anfragen an den selben Server \u00fcber eine TCP-Verbindung gesendet. Dabei werden die Anfragen sequenziell an den Server gesendet.
Dies bedeutet jedoch, dass man Ressourcen nur nacheinander anfragen kann, was in einem Performancenachteil resultiert. Beim Aufrufen einer Website werden oftmals mehrere Ressourcen ben\u00f6tigt und angefragt. Tests haben ergeben, dass das parallele Anfragen dieser, trotz des mehrfachen Verbindungsaufbaus schneller ist, als das sequenzielle Anfragen der Daten \u00fcber eine TCP-Verbindung. Aus diesem Grund wird das Feature kaum eingesetzt. [4]<\/p>\n\n\n\n

HTTP\/2<\/h4>\n\n\n\n
\"\"<\/a>
Multiplexung unter HTTP\/2 [4]<\/figcaption><\/figure>\n\n\n\n

Mit HTTP\/2 wurde dann Multiplexing eingef\u00fchrt. Multiplexing ist das Zusammenfassen mehrerer Verbindungen zu einer Verbindung. Der Unterschied zu den mit HTTP 1.1 eingef\u00fchrten \u00c4nderungen ist, dass nun parallele Anfragen \u00fcber eine Verbindung m\u00f6glich sind. Die Ressourcen m\u00fcssen nicht mehr sequenziell angefragt werden. Das hei\u00dft, dass nur noch eine Verbindung aufgebaut werden muss, \u00fcber welche Anfragen gestellt werden k\u00f6nnen. Die Besonderheit an dieser Stelle ist, dass nicht mehr auf Ergebnisse vorheriger Anfragen gewartet werden muss.
Durch das Multiplexing ergibt sich jedoch nun ein neues Problem: Head-of-Line Blocking. [4]<\/p>\n\n\n\n

Head-of-Line Blocking<\/h3>\n\n\n\n
\"\"<\/a>
Head-of-Line Blocking (1) [4]<\/figcaption><\/figure>\n\n\n\n

Beim Head-of-Line Blocking handelt es sich um das Blockieren der Verarbeitung bereits empfangener Pakete, durch den Verlust eines vorherigen Pakets.
Ein HTTP\/2-Server stellt bei einer Anfrage, die Ressourcen bereit und zerteilt diese in einzelne TCP Pakete. Die TCP Pakete werden daraufhin zum Client zur\u00fcckgesendet. Dabei kann es sein, dass das erste \u00fcbermittelte Paket von Ressource-A stammt und das zweite \u00fcbermittelte Paket zu einer ganz anderen Ressource geh\u00f6rt. Wenn der Server die Antwort-Pakete nun verschickt, kann es dazu kommen, dass irgendeine Middlebox im Internet eines der Pakete fallen l\u00e4sst. Die anderen Pakete werden ganz normal an den Empf\u00e4nger \u00fcbermittelt. [4]<\/p>\n\n\n\n

\"\"<\/a>
Head-of-Line Blocking (2) [4]<\/figcaption><\/figure>\n\n\n\n

Das TCP-Protokoll garantiert, dass die empfangenen Pakete in der Reihenfolge verarbeitet werden, in der sie versendet wurden. Im Fall des verloren gegangenen Pakets kann genau dies zum Problem werden. Bevor bereits empfangene Pakete verarbeitet werden k\u00f6nnen, die erst nach dem verloren Paket versandt wurden, muss das verlorene Paket nachgefordert werden. Dies blockiert die gesamte Verarbeitung der nachfolgenden Pakete, auch wenn diese komplett unabh\u00e4ngige Daten beinhalten. Von der Unabh\u00e4ngigkeit wei\u00df TCP jedoch gar nichts, da das Multiplexing Teil des HTTP\/2 Protokolls ist. [4]<\/p>\n\n\n\n

QUIC – kein Head-of-Line Blocking<\/h4>\n\n\n\n
\"\"<\/a>
Multiplexing bei der Verwendung von HTTP\/3 [4]<\/figcaption><\/figure>\n\n\n\n

Bei QUIC tritt das Head-of-Line Blocking nicht mehr auf. Dies liegt an der Verwendung von UDP. Auf der einen Seite besitzt UDP keinen Mechanismus um verlorene Pakete erneut anzufordern. Auf der anderen Seite spielt es bei der Verwendung von UDP-Paketen keine Rolle, in welcher Reihenfolge die Pakete verarbeitet werden.
Wenn ein Paket verloren gehen sollte, k\u00f6nnen bereits empfangene Pakete auf QUIC-Ebene schon weiterverarbeitet werden. Separat hiervon kann das verloren gegangene Paket nun von QUIC neu angefordert werden. [4]<\/p>\n\n\n\n

Performancetests<\/h3>\n\n\n\n

Interessant ist im n\u00e4chsten Schritt, ob diese theoretischen \u00dcberlegungen in der Praxis tats\u00e4chlich Performance-Verbesserungen hervorrufen. Aus diesem Grund wurden unter anderem von Cloudflare einige Performancetests durchgef\u00fchrt.<\/p>\n\n\n\n

Handshake<\/h4>\n\n\n\n
\"\"<\/a>
Time to first byte – HTTP\/2 und HTTP\/3 Handshake [6]<\/figcaption><\/figure>\n\n\n\n

QUIC halbiert die Anzahl der Nachrichten, die f\u00fcr den initialen Verbindungsaufbau notwendig sind. Um zu messen, welcher Verbindungsaufbau schneller ist wurde die “time to first byte”, also die Zeit bis das erste Byte \u00fcbertragen wird verglichen. Das Aufbauen der HTTP\/2 Verbindung hat dabei im Schnitt 201 ms gedauert. Der HTTP\/3-Verbindungsaufbau war im Vergleich dazu mit 176 ms im Durchschnitt 12,4 % schneller. [6]<\/p>\n\n\n\n

Synthetische Performancetests<\/h4>\n\n\n\n
\"\"<\/a>
Performancetests – Latenz bei 15KB Nachrichten [6]<\/figcaption><\/figure>\n\n\n\n

Danach wurde die Performance der Nachrichten\u00fcbertragung mit synthetischen Performancetests ermittelt. Dabei misst man die \u00dcbertragungsgeschwindigkeit der Paketen mit einer festen Paketgr\u00f6\u00dfe. Der erste Test umfasste HTTP\/2 und HTTP\/3 Pakete mit einer Gr\u00f6\u00dfe von 15 KB.
Im Durchschnitt ist HTTP\/3 mit QUIC bei diesem Test 15ms schneller als HTTP\/2 mit TCP. [6]<\/p>\n\n\n\n

\"\"<\/a>
Performancetests – Latenz bei 1MB Nachrichten [6]<\/figcaption><\/figure>\n\n\n\n

Der n\u00e4chste Test umfasste Nachrichten mit einer Gr\u00f6\u00dfe von 1 MB. Dabei stellte sich heraus, dass HTTP\/2 mit TCP besser performt als HTTP\/3 mit QUIC. Im Durchschnitt wurden die Nachrichten in diesem Test mit HTTP\/2 und TCP 27ms schneller empfangen als bei HTTP\/3. [6]<\/p>\n\n\n\n

\"\"<\/a>
Performancetests – Latenz bei 5MB Nachrichten [6]<\/figcaption><\/figure>\n\n\n\n

Bei Nachrichten mit einer Nachrichtengr\u00f6\u00dfe von 5 MB verst\u00e4rkt sich dieser Trend. Auch hier ist das \u00dcbermitteln der Nachrichten mit HTTP\/3 und QUIC langsamer als unter HTTP\/2 mit TCP. Der Unterschied liegt in diesem Fall im Durchschnitt sogar bei 126ms.<\/p>\n\n\n\n

Daran zeigt sich, dass die Performance bei der Verwendung von QUIC bei immer gr\u00f6\u00dferen Nachrichten, im Vergleich zu TCP immer schlechter wird. [6]<\/p>\n\n\n\n

Real-World Performancetests<\/h4>\n\n\n\n

Neben den synthetischen Performancetests wurden auch “Real-World” Performancetests durchgef\u00fchrt. Dabei wurde der Cloudflare-Blog (blog.cloudflare.com) auf einen HTTP\/3 Server deployed. Die Tests wurden dann mit Hilfe des WebPageTest-Frameworks durchgef\u00fchrt. In Kombination mit dem hauseigenen Monitoring-Tool “Browser Insights” wurden Metriken gesammelt um Aufschluss \u00fcber die Performance der Seite zu geben.<\/p>\n\n\n\n

\"\"<\/a>
Performancetests – Latenz bei der \u00dcbertragung des Cloudflare Blogs [6]<\/figcaption><\/figure>\n\n\n\n

Auch in diesem Test schneidet HTTP\/2 im Durchschnitt besser ab als HTTP\/3. Der Unterschied liegt hier bei circa 1-4%. [6]<\/p>\n\n\n\n

Insgesamt schneidet HTTP\/2 mit TCP in allen Tests, bis auf den reinen Handshake-Vergleich besser ab. Je gr\u00f6\u00dfer die zu \u00fcbermittelnden Nachrichten dabei werden, desto besser sind die \u00dcbertragungszeiten von HTTP\/2 im Vergleich zu HTTP\/3.<\/p>\n\n\n\n

Tests von Google zeigten dar\u00fcber hinaus, dass die CPU-Last der Server durch die Verwendung von QUIC doppelt so hoch, wie bei der Verwendung von TCP in Kombination mit TLS ist. Dies bedeutet, dass Google doppelt so viel CPU-Ressourcen zur Verf\u00fcgung stellen m\u00fcsste, um die selbe Anzahl an Anfragen verarbeiten zu k\u00f6nnen. [5]<\/p>\n\n\n\n

Auswertung<\/h3>\n\n\n\n

Die Cloudflare-Ingenieure vermuten, dass es aufgrund der verwendeten Congestion Algorithmen zu den Unterschieden in der Performance kommt. Bei Congestion Algorithmen handelt es sich um Algorithmen, die bei \u00dcberlastung eines Servers ankommende Pakete fallen lassen. [5][6]
Die Congestion Algorithmen, die auf TCP-Ebene verwendet werden, sind bereits \u00fcber viele Jahr optimiert worden. Auf Ebene von QUIC hat diese Optimierung noch nicht stattgefunden. Aus diesem Grund vermuten die Cloudflare-Ingenieure, dass die verwendeten Congestion Algorithmen den theoretischen Performancevorteil (bspw. kein Head-of-Line Blocking) von QUIC wieder zunichte machen. [6]<\/p>\n\n\n\n

Die erh\u00f6hte CPU-Last bei der Verwendung von QUIC kann an zwei Dingen liegen. Die erste M\u00f6glichkeit sind wieder die noch nicht optimierten Congestion Algorithmen. Auf der anderen Seite kann dies daran liegen, dass QUIC im Userspace verarbeitet wird. Dadurch ist Kommunikation zwischen den User- und dem Kernel-Space notwendig, die die CPU weiter belasten kann. TCP wird komplett im Kernel-Space verarbeitet und hat dieses Problem dadurch nicht. [5]<\/p>\n\n\n\n

Fazit<\/h3>\n\n\n\n

Abschlie\u00dfend kann man sagen, dass QUIC in der Theorie viele Probleme von TCP l\u00f6sen kann. Gerade in Kombination mit HTTP sind hier Performancevorteile zu erwarten.
In der Praxis zeigt sich jedoch, dass TCP und HTTP\/2 zur Zeit, vor allem bei gr\u00f6\u00dferen Nachrichten besser performen als QUIC und HTTP\/3. Bei kleinen Nachrichten und beim Verbindungsaufbau sind HTTP\/3 und QUIC bereits schneller.
Dies ist damit zu erkl\u00e4ren, dass f\u00fcr QUIC noch viele Optimierungen notwendig sind. So muss beispielsweise das HTTP\/3 Protokoll noch auf QUIC angepasst werden. Die Congestion Algorithmen sind dar\u00fcber hinaus auch noch nicht optimiert.<\/p>\n\n\n\n

Man sieht das QUIC damit im Vergleich zu TCP noch am Anfang steht. Trotzdem setzen viele der gro\u00dfen Tech-Firmen bereits auf das neue Protokoll und stellen ihre Dienste auch \u00fcber HTTP\/3 zur Verf\u00fcgung. Daher kann man davon ausgehen, dass weiterhin an der Optimierung von QUIC geforscht wird und dass QUIC immer h\u00e4ufiger Verwendung finden wird.<\/p>\n\n\n\n

QUIC und HTTP\/3 selber ausprobieren<\/h3>\n\n\n\n

Um auszuprobieren, welche Dienste bereits HTTP\/3 unterst\u00fctzen, ben\u00f6tigt man einen entsprechenden Client. F\u00fcr die Browser Firefox und Chrome gibt es daf\u00fcr jeweils den Nightly-Build:<\/p>\n\n\n\n