{"id":104306,"date":"2022-06-07T09:36:47","date_gmt":"2022-06-07T07:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta"},"modified":"2022-06-07T09:36:47","modified_gmt":"2022-06-07T07:36:48","slug":"protokol-http-3-0-poluchil-status-predlozhennogo-standarta","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta","title":{"rendered":"Das Protokoll HTTP\/3.0 hat den Status eines vorgeschlagenen Standards erhalten.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das IETF-Komitee (Internet Engineering Task Force), das sich mit der Entwicklung von Internetprotokollen und -architekturen besch\u00e4ftigt, hat die RFC f\u00fcr das Protokoll HTTP\/3.0 abgeschlossen und ver\u00f6ffentlichte die dazugeh\u00f6rigen Spezifikationen unter den Identifikatoren RFC 9114 (Protokoll) und RFC 9204 (Technologie zur Kompression von Headern QPACK f\u00fcr HTTP\/3). Die Spezifikation HTTP\/3.0 erhielt den Status \u201eEntwurf eines Standards\u201c, woraufhin die Arbeit an der Erteilung des RFC-Status als Entwurf (Draft Standard) beginnen wird. Dies bedeutet faktisch eine vollst\u00e4ndige Stabilisierung des Protokolls und ber\u00fccksichtigt alle ge\u00e4u\u00dferten Anmerkungen. Gleichzeitig wurden aktualisierte Versionen der Spezifikationen f\u00fcr die Protokolle HTTP\/1.1 (RFC 9112) und HTTP\/2.0 (RFC 9113) ver\u00f6ffentlicht, sowie Dokumente, die die Semantik von HTTP-Anfragen (RFC 9110) und die HTTP-Header zur Cache-Steuerung (RFC 9111) definieren. <\/p>\n
Das HTTP\/3-Protokoll definiert die Verwendung des QUIC-Protokolls (Quick UDP Internet Connections) als Transportmittel f\u00fcr HTTP\/2. QUIC ist ein Layer \u00fcber dem UDP-Protokoll, das die Multiplexierung mehrerer Verbindungen unterst\u00fctzt und Methoden zur Verschl\u00fcsselung bereitstellt, die TLS\/SSL entsprechen. Das Protokoll wurde 2013 von Google als Alternative zur Kombination TCP+TLS f\u00fcr das Web entwickelt. Es l\u00f6st Probleme mit langen Zeiten f\u00fcr den Verbindungsaufbau und die Aushandlung in TCP und eliminiert Verz\u00f6gerungen bei Paketverlusten w\u00e4hrend der Daten\u00fcbertragung.
<\/center> <\/p>\n
Derzeit wird die Unterst\u00fctzung f\u00fcr QUIC und HTTP\/3.0 bereits in allen g\u00e4ngigen Webbrowsern aufrechterhalten (in Chrome, Firefox und Edge ist die Unterst\u00fctzung f\u00fcr HTTP\/3 standardm\u00e4\u00dfig aktiviert, w\u00e4hrend sie in Safari unter der Einstellung \u201eErweitert > Experimentelle Features > HTTP\/3\u201c aktiviert werden muss). Auf der Serverseite ist die Implementierung von HTTP\/3 f\u00fcr nginx (in einem separaten Branch und als separates Modul), Caddy, IIS und LiteSpeed verf\u00fcgbar. Auch das Content Delivery Network Cloudflare unterst\u00fctzt HTTP\/3. <\/p>\n
Hauptmerkmale von QUIC: <\/p>\n
\n
Hohe Sicherheit, die der TLS entspricht (im Wesentlichen erm\u00f6glicht QUIC die Nutzung von TLS \u00fcber UDP); <\/li>\n
Stream-Integrity-Kontrolle zur Vermeidung von Paketverlusten; <\/li>\n
Die M\u00f6glichkeit, sofort eine Verbindung herzustellen (0-RTT, in etwa 75 % der F\u00e4lle k\u00f6nnen Daten sofort nach dem Senden des Verbindungsaufbau-Pakets \u00fcbertragen werden) und die minimalen Verz\u00f6gerungen zwischen der Anfrage und dem Empfang der Antwort (RTT, Round Trip Time) zu gew\u00e4hrleisten;
<\/center> <\/li>\n
Verwendung einer anderen Sequenznummer bei der erneuten \u00dcbertragung eines Pakets, was Mehrdeutigkeiten bei der Bestimmung empfangener Pakete vermeidet und Zeit\u00fcberschreitungen beseitigt; <\/li>\n
Ein Paketverlust beeinflusst nur die Zustellung des damit verbundenen Streams und stoppt nicht die \u00dcbertragung von Daten in parallel \u00fcber die aktuelle Verbindung \u00fcbertragenen Streams; <\/li>\n
Fehlerkorrekturma\u00dfnahmen, die Verz\u00f6gerungen durch die erneute \u00dcbertragung verlorener Pakete minimieren. Einsatz spezieller Fehlerkorrekturcodes auf Paketebene zur Verringerung von Situationen, die eine erneute \u00dcbertragung verlorener Daten erfordern. <\/li>\n
Die Grenzen der kryptografischen Bl\u00f6cke sind an die Grenzen der QUIC-Pakete angepasst, was den Einfluss von Paketverlusten auf die Dekodierung des Inhalts nachfolgender Pakete verringert. <\/li>\n
Keine Probleme mit der TCP-Warteschlangensperre. <\/li>\n
Unterst\u00fctzung f\u00fcr eine Verbindungs-ID, die die Wiederherstellungszeit f\u00fcr mobile Clients verk\u00fcrzt. <\/li>\n
Die M\u00f6glichkeit, erweiterte Mechanismen zur \u00dcberwachung der Verbindungs\u00fcberlastung zu integrieren. <\/li>\n
Der Einsatz von Bandbreitenvorhersagetechniken in beide Richtungen sorgt f\u00fcr eine optimale Paketversandintensit\u00e4t und verhindert das Abgleiten in einen \u00dcberlastungszustand, der zu Paketverlusten f\u00fchrt. <\/li>\n
Merklicher Leistungs- und Bandbreitenzuwachs im Vergleich zu TCP. F\u00fcr Videodienste wie YouTube zeigte die Anwendung von QUIC eine Reduzierung der Pufferungsoperationen beim Video-Streaming um 30%. <\/ul>\n
Zu den \u00c4nderungen in der Spezifikation von HTTP\/1.1 geh\u00f6rt das Verbot der isolierten Verwendung des Carriage Return (CR) au\u00dferhalb des Inhaltsk\u00f6rpers, d. h. im Protokollelement kann das CR-Symbol nur zusammen mit dem Line Feed-Symbol (CRLF) verwendet werden. Der Algorithmus zur Chunked-Anforderung wurde \u00fcberarbeitet, um die Trennung angeh\u00e4ngter Felder und der Header-Sektion zu vereinfachen. Empfehlungen zur Behandlung mehrdeutiger Inhalte wurden hinzugef\u00fcgt, um \u201eHTTP Request Smuggling\u201c-Angriffe zu blockieren, die es erm\u00f6glichen, sich in den Inhalt der Anfragen anderer Benutzer im Fluss zwischen Frontend und Backend einzuschieben. <\/p>\n
In der Aktualisierung der HTTP\/2.0-Spezifikation wird die Unterst\u00fctzung von TLS 1.3 ausdr\u00fccklich definiert. Das Verfahren zur Priorit\u00e4tsbestimmung und die damit verbundenen Felder in den Headern wurden als veraltet eingestuft. Der bislang wenig verbreitete Mechanismus zur Verbindungsaktualisierung von HTTP\/1.1 wurde f\u00fcr obsolet erkl\u00e4rt. Die Anforderungen an die \u00dcberpr\u00fcfung von Feldnamen und Werten wurden reduziert. Einige zuvor reservierte Rahmenarten und Parameter wurden zur Nutzung vorgeschlagen. Verbotsfelder in Bezug auf die Verbindung wurden pr\u00e4ziser definiert. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Das](\"\/wp-content\/uploads\/2022\/06\/0821fd634337ac1f1cc0924abb4f55dc.jpg\")
<\/center> <\/p>\n![\"Das](\"\/wp-content\/uploads\/2022\/06\/d416668e500fd2b79304fa0b13f793e3.jpg\")
<\/center> <\/li>\n