{"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\/news\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta","title":{"rendered":"Das Protokoll HTTP\/3.0 erhielt den Status eines vorgeschlagenen Standards.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Der IETF (Internet Engineering Task Force), der sich mit der Entwicklung von Protokollen und der Architektur des Internets besch\u00e4ftigt, hat die RFC f\u00fcr das Protokoll HTTP\/3.0 abgeschlossen und die damit verbundenen Spezifikationen unter den Identifikatoren RFC 9114 (Protokoll) und RFC 9204 (QPACK-Kompressionstechnologie f\u00fcr HTTP\/3) ver\u00f6ffentlicht. Die Spezifikation HTTP\/3.0 erhielt den Status 'Vorgeschlagener Standard', woraufhin die Arbeit an der Erlangung des Status eines Entwurfsstandards (Draft Standard) beginnt, was faktisch die vollst\u00e4ndige Stabilisierung des Protokolls und die Ber\u00fccksichtigung aller ge\u00e4u\u00dferten Anmerkungen bedeutet. 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 HTTP-Header zur Cachesteuerung (RFC 9111) definieren. <\/p>\n
Das Protokoll HTTP\/3 definiert die Verwendung des Protokolls QUIC (Quick UDP Internet Connections) als Transport f\u00fcr HTTP\/2. QUIC ist eine Erweiterung des UDP-Protokolls, die die Multiplexierung mehrerer Verbindungen unterst\u00fctzt und Verschl\u00fcsselungsmethoden bietet, die TLS\/SSL entsprechen. Das Protokoll wurde 2013 von Google als Alternative zur Kombination TCP+TLS f\u00fcr das Web entwickelt, um die Probleme mit der langen Zeit zur Herstellung und Aushandlung von Verbindungen in TCP zu l\u00f6sen und Verz\u00f6gerungen beim Verlust von Paketen w\u00e4hrend der Daten\u00fcbertragung zu beseitigen.
<\/center> <\/p>\n
Derzeit wird die Unterst\u00fctzung von QUIC und HTTP\/3.0 bereits in allen g\u00e4ngigen Webbrowsern umgesetzt (In Chrome, Firefox und Edge ist die Unterst\u00fctzung von HTTP\/3 standardm\u00e4\u00dfig aktiviert, w\u00e4hrend sie in Safari die Aktivierung der Einstellung 'Erweitert > Experimentelle Funktionen > HTTP\/3' erfordert). Auf der Serverseite sind Implementierungen von HTTP\/3 f\u00fcr nginx (in einem separaten Branch und in Form eines separaten Moduls), Caddy, IIS und LiteSpeed verf\u00fcgbar. Die Unterst\u00fctzung f\u00fcr HTTP\/3 wird auch vom Content Delivery Network Cloudflare bereitgestellt. <\/p>\n
Die Hauptmerkmale von QUIC: <\/p>\n
\n
Hohe Sicherheit, vergleichbar mit TLS (im Grunde erm\u00f6glicht QUIC die Verwendung von TLS \u00fcber UDP); <\/li>\n
Kontrolle der Integrit\u00e4t des Datenstroms, um Paketverluste zu verhindern; <\/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 Verbindungsaufbaupakets \u00fcbertragen werden) und minimalen Verz\u00f6gerungen zwischen dem Senden der Anfrage und dem Empfang der Antwort (RTT, Round Trip Time) zu gew\u00e4hrleisten;
<\/center> <\/li>\n
Verwendung einer anderen Sequenznummer f\u00fcr die erneute \u00dcbertragung eines Pakets, wodurch Mehrdeutigkeiten beim Bestimmen empfangener Pakete vermieden werden und Zeit\u00fcberschreitungen eliminiert werden; <\/li>\n
Paketverluste beeinflussen nur den damit verbundenen Datenstrom und stoppen nicht die Daten\u00fcbertragung in parallel \u00fcber die aktuelle Verbindung gesendeten Datenstr\u00f6men; <\/li>\n
Fehlerkorrekturma\u00dfnahmen, die Verz\u00f6gerungen aufgrund der erneuten \u00dcbertragung verlorener Pakete minimieren. Verwendung spezieller Fehlerkorrekturcodes auf Paketeebene, um Situationen zu reduzieren, die eine erneute \u00dcbertragung der Daten des verlorenen Pakets erfordern. <\/li>\n
Die Grenzen der kryptografischen Bl\u00f6cke sind an die Grenzen der QUIC-Pakete angepasst, was die Auswirkungen von Paketverlusten auf die Dekodierung der Inhalte nachfolgender Pakete verringert; <\/li>\n
Keine Probleme mit der Blockierung von TCP-Warteschlangen; <\/li>\n
Unterst\u00fctzung einer Verbindungs-ID, die die Zeit f\u00fcr die Wiederherstellung einer Verbindung f\u00fcr mobile Clients reduziert; <\/li>\n
Die M\u00f6glichkeit, erweiterte Mechanismen zur \u00dcberlaststeuerung der Verbindung zu integrieren; <\/li>\n
Einsatz von Bandbreitenvorhersagetechniken in jede Richtung, um die optimale Intensit\u00e4t der Paketsendung sicherzustellen und ein Abrutschen in einen \u00dcberlastzustand, der Paketverluste zur Folge hat, zu verhindern; <\/li>\n
Deutlicher Leistungs- und Bandbreitenschub im Vergleich zu TCP. F\u00fcr Video-Streaming-Dienste wie YouTube hat der Einsatz von QUIC eine Reduzierung der Puffervorg\u00e4nge beim Video-Streaming um 30 % gezeigt. <\/ul>\n
Zu den \u00c4nderungen in der Spezifikation HTTP\/1.1 geh\u00f6rt das Verbot der isolierten Verwendung des Wagenr\u00fccklaufzeichens (CR) au\u00dferhalb des Inhaltsk\u00f6rpers, d.h. im Protokoll k\u00f6nnen CR-Zeichen nur zusammen mit dem Zeilenumbruchzeichen (CRLF) verwendet werden. Der Algorithmus zur Erstellung von chunked-Anfragen wurde verbessert, um die Trennung angeh\u00e4ngter Felder und des Header-Bereichs zu erleichtern. Es wurden Empfehlungen zur Verarbeitung mehrdeutiger Inhalte hinzugef\u00fcgt, um Angriffe der Klasse 'HTTP Request Smuggling' zu verhindern, die es erm\u00f6glichen, sich in die Inhalte von Anfragen anderer Benutzer im Stream zwischen Frontend und Backend einzuschleichen. <\/p>\n
In der Aktualisierung der HTTP\/2.0-Spezifikation wurde die Unterst\u00fctzung f\u00fcr TLS 1.3 ausdr\u00fccklich definiert. Die alte Methode zur Priorisierung und damit verbundene Felder in den Headern wurde als veraltet erkl\u00e4rt. Der weniger verbreitete Mechanismus zur Aktualisierung der Verbindung zu HTTP\/1.1 wurde ebenfalls f\u00fcr obsolet erkl\u00e4rt. Die Anforderungen an die \u00dcberpr\u00fcfung von Feldnamen und Werten wurden reduziert. Einige zuvor reservierte Rahmen- und Parameterarten wurden zur Nutzung vorgeschlagen. Verbotene Headerfelder 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