{"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\/pl\/blog\/news\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta","title":{"rendered":"Protok\u00f3\u0142 HTTP\/3.0 uzyska\u0142 status propozycji standardu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Komitet IETF (Internet Engineering Task Force), kt\u00f3ry zajmuje si\u0119 rozwojem protoko\u0142\u00f3w i architektury internetu, zako\u0144czy\u0142 tworzenie RFC dla protoko\u0142u HTTP\/3.0 i opublikowa\u0142 powi\u0105zane specyfikacje pod identyfikatorami RFC 9114 (protok\u00f3\u0142) i RFC 9204 (technologia kompresji nag\u0142\u00f3wk\u00f3w QPACK dla HTTP\/3). Specyfikacja HTTP\/3.0 uzyska\u0142a status \u201eProponowanego standardu\u201d, po czym rozpocznie si\u0119 praca nad nadaniem RFC statusu standardu roboczego (Draft Standard), co de facto oznacza pe\u0142n\u0105 stabilizacj\u0119 protoko\u0142u i uwzgl\u0119dnienie wszystkich zg\u0142oszonych uwag. Jednocze\u015bnie opublikowano zaktualizowane wersje specyfikacji dla protoko\u0142\u00f3w HTTP\/1.1 (RFC 9112) i HTTP\/2.0 (RFC 9113), a tak\u017ce dokumenty definiuj\u0105ce semantyk\u0119 zapyta\u0144 HTTP (RFC 9110) i nag\u0142\u00f3wki HTTP do zarz\u0105dzania cache'owaniem (RFC 9111). <\/p>\n
Protok\u00f3\u0142 HTTP\/3 definiuje wykorzystanie protoko\u0142u QUIC (Quick UDP Internet Connections) jako transportu dla HTTP\/2. QUIC jest nadbudow\u0105 nad protoko\u0142em UDP, wspieraj\u0105c\u0105 multiplexing wielu po\u0142\u0105cze\u0144 i zapewniaj\u0105c\u0105 metody szyfrowania, r\u00f3wnowa\u017cne TLS\/SSL. Protok\u00f3\u0142 zosta\u0142 stworzony w 2013 roku przez firm\u0119 Google jako alternatywa dla po\u0142\u0105czenia TCP+TLS w sieci, rozwi\u0105zuj\u0105ca problemy z d\u0142ugim czasem nawi\u0105zywania i negocjacji po\u0142\u0105cze\u0144 w TCP oraz eliminuj\u0105ca op\u00f3\u017anienia zwi\u0105zane z utrat\u0105 pakiet\u00f3w podczas przesy\u0142ania danych.
<\/center> <\/p>\n
Obecnie wsparcie dla QUIC i HTTP\/3.0 jest ju\u017c zrealizowane we wszystkich popularnych przegl\u0105darkach internetowych (w Chrome, Firefox i Edge wsparcie HTTP\/3 jest w\u0142\u0105czone domy\u015blnie, a w Safari wymaga w\u0142\u0105czenia ustawienia \u201eAdvanced > Experimental Features > HTTP\/3\u201d). Po stronie serwera implementacje HTTP\/3 s\u0105 dost\u0119pne dla nginx (w oddzielnej ga\u0142\u0119zi i w formie osobnego modu\u0142u), Caddy, IIS i LiteSpeed. Wsparcie dla HTTP\/3 zapewnia r\u00f3wnie\u017c sie\u0107 dostarczania tre\u015bci Cloudflare. <\/p>\n
Kluczowe cechy QUIC: <\/p>\n
\n
Wysokie bezpiecze\u0144stwo, podobne do TLS (w zasadzie QUIC zapewnia mo\u017cliwo\u015b\u0107 u\u017cycia TLS nad UDP); <\/li>\n
Kontrola integralno\u015bci strumienia, zapobiegaj\u0105ca utracie pakiet\u00f3w; <\/li>\n
Mo\u017cliwo\u015b\u0107 natychmiastowego nawi\u0105zania po\u0142\u0105czenia (0-RTT, w oko\u0142o 75% przypadk\u00f3w dane mog\u0105 by\u0107 przesy\u0142ane zaraz po wys\u0142aniu pakietu nawi\u0105zania po\u0142\u0105czenia) oraz zapewnienie minimalnych op\u00f3\u017anie\u0144 mi\u0119dzy wysy\u0142aniem \u017c\u0105dania a otrzymywaniem odpowiedzi (RTT, Round Trip Time);
<\/center> <\/li>\n
U\u017cycie innego numeru sekwencji przy retransmisji pakietu, co pozwala unikn\u0105\u0107 niejednoznaczno\u015bci w okre\u015blaniu otrzymanych pakiet\u00f3w i eliminowa\u0107 timeouty; <\/li>\n
Utrata pakietu wp\u0142ywa na dostarczanie tylko powi\u0105zanego z nim strumienia i nie zatrzymuje dostarczania danych w r\u00f3wnolegle przesy\u0142anych strumieniach przez bie\u017c\u0105ce po\u0142\u0105czenie; <\/li>\n
\u015arodki korekcji b\u0142\u0119d\u00f3w, minimalizuj\u0105ce op\u00f3\u017anienia spowodowane ponown\u0105 transmisj\u0105 zagubionych pakiet\u00f3w. Wykorzystanie specjalnych kod\u00f3w korekcji b\u0142\u0119d\u00f3w na poziomie pakiet\u00f3w w celu zmniejszenia liczby sytuacji wymagaj\u0105cych ponownej transmisji danych zagubionego pakietu. <\/li>\n
Granice blok\u00f3w kryptograficznych s\u0105 wyr\u00f3wnane z granicami pakiet\u00f3w QUIC, co zmniejsza wp\u0142yw utraty pakiet\u00f3w na dekodowanie zawarto\u015bci nast\u0119pnych pakiet\u00f3w; <\/li>\n
Brak problem\u00f3w z blokowaniem kolejek TCP; <\/li>\n
Wsparcie dla identyfikatora po\u0142\u0105czenia, co pozwala skr\u00f3ci\u0107 czas na ponowne nawi\u0105zanie po\u0142\u0105czenia dla klient\u00f3w mobilnych; <\/li>\n
Mo\u017cliwo\u015b\u0107 pod\u0142\u0105czenia rozszerzonych mechanizm\u00f3w kontroli przeci\u0105\u017cenia po\u0142\u0105czenia; <\/li>\n
Wykorzystanie techniki prognozowania przepustowo\u015bci w ka\u017cdym kierunku, aby zapewni\u0107 optymaln\u0105 intensywno\u015b\u0107 wysy\u0142ania pakiet\u00f3w, zapobiegaj\u0105c wpadni\u0119ciu w stan przeci\u0105\u017cenia, w kt\u00f3rym wyst\u0119puje utrata pakiet\u00f3w; <\/li>\n
Wyra\u017any wzrost wydajno\u015bci i przepustowo\u015bci w por\u00f3wnaniu do TCP. W przypadku serwis\u00f3w wideo, takich jak YouTube, zastosowanie QUIC wykaza\u0142o 30% zmniejszenie liczby operacji buforowania podczas odtwarzania wideo. <\/ul>\n
W zmianach w specyfikacji HTTP\/1.1 mo\u017cna zauwa\u017cy\u0107 zakaz oddzielnego u\u017cywania znaku powrotu karetki (CR) poza tre\u015bci\u0105 z zawarto\u015bci\u0105, tzn. w elementach protoko\u0142u znak CR mo\u017ce by\u0107 stosowany tylko razem ze znakiem nowej linii (CRLF). Algorytm kompozycji zapyta\u0144 chunked zosta\u0142 poprawiony w celu uproszczenia podzia\u0142u za\u0142\u0105czonych p\u00f3l i sekcji z nag\u0142\u00f3wkami. Dodano zalecenia dotycz\u0105ce przetwarzania niejednoznacznej zawarto\u015bci w celu zablokowania atak\u00f3w typu \u201eHTTP Request Smuggling\u201d, kt\u00f3re pozwalaj\u0105 na infiltracj\u0119 zawarto\u015bci zapyta\u0144 innych u\u017cytkownik\u00f3w w strumieniu mi\u0119dzy frontendem a backendem. <\/p>\n
W aktualizacji specyfikacji HTTP\/2.0 wyra\u017anie zdefiniowano wsparcie dla TLS 1.3. Przeniesiono do kategorii przestarza\u0142ych schemat okre\u015blania priorytet\u00f3w i zwi\u0105zane z nimi pola w nag\u0142\u00f3wkach. Og\u0142oszono przestarza\u0142ym mechanizm aktualizacji po\u0142\u0105czenia z HTTP\/1.1, kt\u00f3ry nie zyska\u0142 popularno\u015bci. Skr\u00f3cono wymagania dotycz\u0105ce sprawdzania nazw p\u00f3l i warto\u015bci. Zaproponowano do u\u017cycia niekt\u00f3re wcze\u015bniej zarezerwowane typy ramek i parametry. Dok\u0142adniej zdefiniowano zabronione pola nag\u0142\u00f3wk\u00f3w odnosz\u0105ce si\u0119 do po\u0142\u0105czenia. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Protok\u00f3\u0142](\"\/wp-content\/uploads\/2022\/06\/0821fd634337ac1f1cc0924abb4f55dc.jpg\")
<\/center> <\/p>\n![\"Protok\u00f3\u0142](\"\/wp-content\/uploads\/2022\/06\/d416668e500fd2b79304fa0b13f793e3.jpg\")
<\/center> <\/li>\n