HTTP/3 und QUIC Making the internet faster
•
1 j'aime•39 vues
Grazer Linuxtage, April 2023, Franz Wimmer (Senior Software Engineer @QAware GmbH) == Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! == Seit seiner Einführung setzt das HTTP-Protokoll auf TCP auf. Das macht es zwar verlässlich, aber auch relativ langsam, weil für jede angebotene Resource ein TCP-Handshake durchgeführt werden muss. HTTP/2 hat versucht, diesen Nachteil mit Multiplexing auszugleichen. Um die Beschränkungen von TCP loszuwerden, hat Google QUIC (Quick UDP Internet Connections) entwickelt. QUIC und das damit mögliche HTTP/3 sollen die Client-Server-Kommunikation im Internet signifikant beschleunigen. In diesem Talk sehen wir eine Zusammenfassung der alten HTTP-Protokolle und welche Vor- und Nachteile diese mitbringen. Wir lernen, wie sich QUIC und HTTP/3 in den OSI-Stack einfügen, welche Verbesserungen die neuen Protokolle mitbringen und wie es dabei mit der Kompatibilität und IT-Sicherheit aussieht. Außerdem werfen wir einen Blick darauf, welche praktischen Anwendungsmöglichkeiten es dafür heute bereits gibt.
Recommandé
Recommandé
Contenu connexe
Similaire à HTTP/3 und QUIC Making the internet faster
Similaire à HTTP/3 und QUIC Making the internet faster (20)
Plus de QAware GmbH
Plus de QAware GmbH (20)
HTTP/3 und QUIC Making the internet faster
- 1. qaware.de Franz Wimmer @zalintyre@chaos.social Making the internet faster HTTP/3 und QUIC
- 2. Franz Wimmer Senior Software Engineer @ QAware GmbH Seit 5 Jahren bei QAware Studium Informatik an der TH Rosenheim Vorlesung “Cloud Computing” @ TH Rosenheim Entwicklung von Cloud Native Applications DevOps Engineer Public Speaking * QAware | 2 * https://codefoundry.de/talks
- 3. Die Geschichte des WWW
- 4. Google IETF 3 Google IETF 2 Autor: Tim Berners-Lee IETF Version 1 Die Geschichte des WWW Zeitleiste HTTP 0.9 HTTP 1.0 HTTP 1.1 SPDY HTTP/2 HTTP/3 1991 1996 1997 2012 2015 2013 2019 QUIC
- 5. HTTP/0.9: Erster Entwurf ■ Autor: Tim Berners-Lee, 1991 ■ Request besteht nur aus einer einzigen Zeile ■ Der Server antwortet mit einem Dokument (HTML) $ telnet google.com 80 Connected to 74.125.xxx.xxx GET /about/ (hypertext response) (connection closed)
- 6. ■ Ein Response-Status wird eingeführt (200 / 404 / etc). ■ Request und Response können jetzt Header enthalten. HTTP/1.0 $ telnet website.org 80 Connected to xxx.xxx.xxx.xxx GET /rfc/rfc1945.txt HTTP/1.0 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Accept: */* HTTP/1.0 200 OK Content-Type: text/plain Content-Length: 137582 Last-Modified: Wed, 1 May 1996 12:45:26 GMT (plain-text response) (connection closed)
- 7. ■ Eine TCP-Verbindung kann für mehrere HTTP-Requests genutzt werden (Connection: Keep-Alive). ■ Die Requests erfolgen aber seriell. ■ Aushandlung von Content, Encoding, Sprache, etc. HTTP/1.1 GET /index.html HTTP/1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/html; charset=utf-8 Cache-Control: max-age=0, no-cache Transfer-Encoding: chunked <!doctype html>
- 8. ■ SPDY ist ein Tunnel um HTTP/HTTPS. ■ Requests werden modifiziert. ■ Keine Anpassung der Anwendung nötig. ■ Features: – Kompression – HTTP-Header werden nicht mehrfach gesendet – SPDY erfordert die TLS-Extension“Next Protocol Negotiation” (NPN) im Server und im Browser. – SPDY ist deprecated. SPDY
- 9. ■ Voll abwärtskompatibel zu HTTP/1.1. ■ Der Server kann ungefragt Resourcen zum Client pushen. ■ Der Standard umfasst HTTP und HTTPS. ■ Setzt die TLS-Extension “Application-Layer Protocol Negotiation” (ALPN) voraus. ■ Alle Browser unterstützen mit HTTP/2 nur noch mit TLS. ■ Kein Head of Line Blocking (HOL) mehr ■ Clients fragen immer mit HTTP/1.1 an. HTTP/2 wird deshalb ausgehandelt. HTTP/2
- 10. ■ Ich will HTTP/2 Server Push einsetzen, aber mein Appserver kann das nicht!? ■ Kein Problem! Nginx als Frontend-Webserver kann das. ■ Der Appserver muss nur einen Link-Header mitsenden: Hilfe, meine Anwendung spricht kein HTTP/2! HTTP/1.1 200 OK content-type: text/html; charset=UTF-8 Link: </style.css>; as=style; rel=preload <content> GET / HTTP/1.1 Host: rosencrime24.de
- 11. HTTP/3 und QUIC
- 12. ■ HTTP/2 löst nicht das Problem des “TCP Head of Line Blocking”. ■ Über eine TCP-Verbindung werden viele Dokumente übertragen. ■ Wenn auf dem Weg ein TCP-Paket verloren geht, wird die ganze Verbindung angehalten. ■ “TCP Retransmission” Probleme mit HTTP/2 und TCP
- 13. QUIC (Quick UDP Internet Connections)
- 14. ■ 2012 bei Google entwickelt ■ Protokoll: UDP, Port 443 ■ Übernimmt Funktionen von TCP und TLS – Verbindung wird in Streams aufgeteilt – Non-Blocking – Es werden weiter korrekte Daten zugestellt, auch wenn ein Stream gerade repariert werden muss ■ Jedes Paket ist einzeln verschlüsselt ■ Auf Anwendungsebene implementiert – Nicht im Kernel, wie z.B. TCP ■ Ziel: Overhead beim initialen Handshake reduzieren QUIC
- 16. ■ Load Balancing / Network Management mit TCP war einfach. – Pakete einer TCP-Verbindung landen immer beim richtigen Server (sticky sessions). ■ Überwachung wird eingeschränkt (mandatory encryption). ■ Bei UDP gibt es keine Sequenznummer im Header. – Die Infrastruktur muss jetzt die Connection ID im QUIC-Header beachten. HTTP/3 – Was nicht mehr geht
- 17. Benchmarks
- 21. Browser (https://caniuse.com/http3): ■ Chrome (87), Firefox (88), Edge (87) und Opera (74) unterstützen HTTP/3. ■ Selbst testen: https://cloudflare-quic.com/ | https://http3.is Webserver: ■ nginx (Preview): https://www.nginx.com/blog/binary-packages-for-preview-nginx-quic-http3-implementation/ ■ Apache: Kein Kommentar zu HTTP/3 ■ HAproxy (2.6) Tools: ■ curl unterstützt HTTP/3 seit Version 7.66.0. ■ wget: Kein Kommentar zu HTTP/3 ■ Support für go und Cloudflare Implementierungen von HTTP/3
- 22. Q & A Franz Wimmer https://codefoundry.de https://chaos.social/@zalintyre