{"id":52181,"date":"2019-11-02T00:00:00","date_gmt":"2019-11-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/http-3-razrushenie-osnov-i-divnyj-novyj-mir"},"modified":"2020-02-18T13:59:51","modified_gmt":"2020-02-18T10:59:51","slug":"http-3-razrushenie-osnov-i-divnyj-novyj-mir","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ju\u017c od ponad 20 lat przegl\u0105damy strony internetowe za pomoc\u0105 protoko\u0142u HTTP. Wi\u0119kszo\u015b\u0107 u\u017cytkownik\u00f3w w og\u00f3le nie zastanawia si\u0119, co to jest i jak to dzia\u0142a. Inni wiedz\u0105, \u017ce gdzie\u015b pod HTTP znajduje si\u0119 TLS, a pod nim TCP, a pod TCP IP i tak dalej. A trzeci \u2013 heretycy \u2013 uwa\u017caj\u0105, \u017ce TCP to ju\u017c przesz\u0142o\u015b\u0107, chc\u0105 czego\u015b szybszego, bardziej niezawodnego i bezpiecznego. Jednak w swoich pr\u00f3bach wynalezienia nowego idealnego protoko\u0142u wr\u00f3cili do technologii z lat 80. i pr\u00f3buj\u0105 na nich zbudowa\u0107 sw\u00f3j wspania\u0142y nowy \u015bwiat.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat\" src=\"\/wp-content\/uploads\/2019\/11\/869bd86cc0b47c6c42f315cf20640018.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Troch\u0119 historii: HTTP\/1.1<\/h2>\n<p>\nW 1997 roku protok\u00f3\u0142 wymiany informacji tekstowych HTTP w wersji 1.1 uzyska\u0142 sw\u00f3j RFC. W tamtym czasie protok\u00f3\u0142 by\u0142 u\u017cywany przez przegl\u0105darki ju\u017c od kilku lat, a nowy standard przetrwa\u0142 jeszcze pi\u0119tna\u015bcie. Protok\u00f3\u0142 dzia\u0142a\u0142 tylko na zasadzie zapytanie-odpowied\u017a i by\u0142 przeznaczony g\u0142\u00f3wnie do przesy\u0142ania informacji tekstowych.<\/p>\n<p>HTTP zosta\u0142 zaprojektowany do pracy na protokole TCP, kt\u00f3ry gwarantuje niezawodne dostarczenie pakiet\u00f3w do odbiorcy. Dzia\u0142anie TCP opiera si\u0119 na ustanowieniu i utrzymaniu niezawodnego po\u0142\u0105czenia mi\u0119dzy punktami ko\u0144cowymi oraz podziale ruchu na segmenty. Segmenty maj\u0105 sw\u00f3j numer sekwencyjny i sum\u0119 kontroln\u0105. Je\u015bli jaki\u015b segment nie dotrze lub dotrze z nieprawid\u0142ow\u0105 sum\u0105 kontroln\u0105, to transmisja zostanie wstrzymana, a\u017c do momentu przywr\u00f3cenia utraconego segmentu.<\/p>\n<p>W HTTP\/1.0 po\u0142\u0105czenie TCP zamykano po ka\u017cdym \u017c\u0105daniu. By\u0142o to niezwykle nieefektywne, poniewa\u017c ustanowienie po\u0142\u0105czenia TCP (3-Way-Handshake) jest procesem niepr\u0119dko przebiegaj\u0105cym. W HTTP\/1.1 wprowadzono mechanizm keep-alive, kt\u00f3ry pozwala na ponowne u\u017cywanie jednego po\u0142\u0105czenia do wielu \u017c\u0105da\u0144. Jednak poniewa\u017c mo\u017ce on \u0142atwo sta\u0107 si\u0119 w\u0105skim gard\u0142em, w r\u00f3\u017cnych implementacjach HTTP\/1.1 dopuszcza si\u0119 otwarcie kilku po\u0142\u0105cze\u0144 TCP do jednego hosta. Na przyk\u0142ad w Google Chrome i najnowszych wersjach Firefox dozwolone jest do sze\u015bciu po\u0142\u0105cze\u0144.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSzyfrowanie r\u00f3wnie\u017c postanowiono powierzy\u0107 innym protoko\u0142om, dlatego na protokole TCP zacz\u0105\u0142 dzia\u0142a\u0107 protok\u00f3\u0142 TLS, kt\u00f3ry do\u015b\u0107 skutecznie chroni\u0142 dane, ale jeszcze bardziej wyd\u0142u\u017ca\u0142 czas wymagany do nawi\u0105zania po\u0142\u0105czenia. Ostatecznie proces uzgadniania wygl\u0105da\u0142 tak:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustracja Cloudflare<\/i><\/p>\n<p>Tak wi\u0119c HTTP\/1.1 mia\u0142 szereg problem\u00f3w:<\/p>\n<ul>\n<li>Wolne nawi\u0105zywanie po\u0142\u0105czenia.<\/li>\n<li>Dane s\u0105 przesy\u0142ane w formie tekstowej, co sprawia, \u017ce przesy\u0142anie obraz\u00f3w, film\u00f3w i innych informacji nie tekstowych jest nieefektywne.<\/li>\n<li>Jedno po\u0142\u0105czenie TCP jest u\u017cywane do jednego \u017c\u0105dania, co oznacza, \u017ce pozosta\u0142e \u017c\u0105dania musz\u0105 znale\u017a\u0107 inne po\u0142\u0105czenie lub czeka\u0107, a\u017c aktualne \u017c\u0105danie je zwolni.<\/li>\n<li>Obs\u0142ugiwana jest tylko model pull. W standardzie nie ma nic o server-push.<\/li>\n<li>Nag\u0142\u00f3wki s\u0105 przesy\u0142ane w postaci tekstu.<\/li>\n<\/ul>\n<p>\nJe\u015bli server-push jest w miar\u0119 wdra\u017cany za pomoc\u0105 protoko\u0142u WebSocket, to z pozosta\u0142ymi problemami trzeba by\u0142o sobie radzi\u0107 bardziej radykalnie.<\/p>\n<h2>Troch\u0119 nowoczesno\u015bci: HTTP\/2<\/h2>\n<p>\nW 2012 roku w Google rozpocz\u0119to prace nad protoko\u0142em SPDY (wymawia si\u0119 \u201espidi\u201d). Protok\u00f3\u0142 mia\u0142 na celu rozwi\u0105zanie g\u0142\u00f3wnych problem\u00f3w HTTP\/1.1, jednocze\u015bnie zachowuj\u0105c kompatybilno\u015b\u0107 wsteczn\u0105. W 2015 roku grupa robocza IETF przedstawi\u0142a specyfikacj\u0119 HTTP\/2, opart\u0105 na protokole SPDY. Oto jakie r\u00f3\u017cnice wyst\u0105pi\u0142y w HTTP\/2:<\/p>\n<ul>\n<li>Binarn\u0105 serializacj\u0119.<\/li>\n<li>MMultiplexowanie wielu \u017c\u0105da\u0144 HTTP w jednym po\u0142\u0105czeniu TCP.<\/li>\n<li>Server-push w pude\u0142ku (bez WebSocket).<\/li>\n<\/ul>\n<p>\nProtok\u00f3\u0142 sta\u0142 si\u0119 du\u017cym krokiem naprz\u00f3d. Znacz\u0105co <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">przewy\u017csza pierwsz\u0105 wersj\u0119 pod wzgl\u0119dem pr\u0119dko\u015bci<\/a><\/noindex> i nie wymaga tworzenia wielu po\u0142\u0105cze\u0144 TCP: wszystkie \u017c\u0105dania do jednego hosta s\u0105 multiplexowane w jedno. To znaczy, \u017ce w jednym po\u0142\u0105czeniu znajduje si\u0119 kilka tzw. strumieni, z kt\u00f3rych ka\u017cdy ma sw\u00f3j ID. Dodatkowym atutem jest fabryczny server-push.<\/p>\n<p>Jednak multiplexowanie prowadzi do innego fundamentalnego problemu. Wyobra\u017a sobie, \u017ce asynchronicznie wykonujemy 5 \u017c\u0105da\u0144 do jednego serwera. Przy u\u017cyciu HTTP\/2 wszystkie te \u017c\u0105dania b\u0119d\u0105 wykonywane w ramach jednego po\u0142\u0105czenia TCP, co oznacza, \u017ce je\u015bli jeden z segment\u00f3w kt\u00f3regokolwiek \u017c\u0105dania zostanie utracony lub przyjdzie niepoprawnie, przesy\u0142anie wszystkich \u017c\u0105da\u0144 i odpowiedzi zostanie wstrzymane, a\u017c zostanie odtworzony utracony segment. Oczywi\u015bcie, im gorsza jako\u015b\u0107 po\u0142\u0105czenia, tym wolniej dzia\u0142a HTTP\/2. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Wed\u0142ug szacunk\u00f3w Daniel'a Steinberga<\/a><\/noindex>, w warunkach, gdy utracone pakiety stanowi\u0105 2% wszystkich, HTTP\/1.1 w przegl\u0105darkach spisuje si\u0119 lepiej ni\u017c HTTP\/2, poniewa\u017c otwiera 6 po\u0142\u0105cze\u0144 zamiast jednego.<\/p>\n<p>Problem ten nosi nazw\u0119 \u201eblocking head-of-line\u201d i niestety rozwi\u0105zanie go podczas korzystania z TCP nie jest mo\u017cliwe.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustracja Daniel Steinberg<\/i><\/p>\n<p>W rezultacie tw\u00f3rcy standardu HTTP\/2 wykonali ogromn\u0105 prac\u0119 i zrobili praktycznie wszystko, co da\u0142o si\u0119 zrobi\u0107 na poziomie aplikacyjnym modelu OSI. Nadszed\u0142 czas, aby zej\u015b\u0107 na poziom transportowy i wynale\u017a\u0107 nowy protok\u00f3\u0142 transportowy.<\/p>\n<h2>Potrzebujemy nowego protoko\u0142u: UDP vs TCP<\/h2>\n<p>\nBardzo szybko sta\u0142o si\u0119 jasne, \u017ce wprowadzenie zupe\u0142nie nowego protoko\u0142u transportowego \u2013 w dzisiejszych realiach to zadanie niemo\u017cliwe do zrealizowania. Chodzi o to, \u017ce o poziomie transportowym wiedz\u0105 urz\u0105dzenia lub tace po\u015brednicz\u0105ce (routery, zapory, serwery NAT\u2026), a nauczenie ich czego\u015b nowego jest niezwykle trudne. Ponadto wsparcie dla protoko\u0142\u00f3w transportowych jest wbudowane w j\u0105dro system\u00f3w operacyjnych, a j\u0105dra te\u017c zmieniaj\u0105 si\u0119 niech\u0119tnie.<\/p>\n<p>Mo\u017cna by\u0142oby za\u0142ama\u0107 r\u0119ce i powiedzie\u0107: \u201eOczywi\u015bcie wymy\u015blimy nowy HTTP\/3 z preferencjami i kurtyzanami, ale jego wdro\u017cenie zajmie 10-15 lat (w przybli\u017ceniu w tym czasie wymieniona zostanie wi\u0119kszo\u015b\u0107 sprz\u0119tu)\u201d, ale istnieje jeszcze jeden mniej oczywisty wariant: u\u017cy\u0107 protoko\u0142u UDP. Tak, ten sam protok\u00f3\u0142, kt\u00f3rym rzucali\u015bmy plikami w lokalnej sieci pod koniec lat 90-tych i na pocz\u0105tku 2000-nych. Praktycznie wszystkie dzisiejsze urz\u0105dzenia potrafi\u0105 z nim pracowa\u0107.<\/p>\n<p>Jakie s\u0105 zalety UDP w por\u00f3wnaniu do TCP? Przede wszystkim to, \u017ce nie mamy sesji na poziomie transportowym, o kt\u00f3rej wie sprz\u0119t. Umo\u017cliwia to samodzielne definiowanie sesji na ko\u0144cowych punktach i tam r\u00f3wnie\u017c rozwi\u0105zywanie powstaj\u0105cych konflikt\u00f3w. To znaczy, \u017ce nie jeste\u015bmy ograniczeni do jednej lub kilku sesji (jak w TCP), a mo\u017cemy stworzy\u0107 ich tyle, ile potrzebujemy. Po drugie, przesy\u0142 danych przez UDP odbywa si\u0119 szybciej ni\u017c przez TCP. W ten spos\u00f3b, teoretycznie, mo\u017cemy przebi\u0107 dzisiejszy sufit pr\u0119dko\u015bci osi\u0105gni\u0119ty w HTTP\/2. <\/p>\n<p>Jednak UDP nie gwarantuje niezawodno\u015bci przesy\u0142u danych. W\u0142a\u015bciwie po prostu wysy\u0142amy pakiety, maj\u0105c nadziej\u0119, \u017ce po drugiej stronie je odbior\u0105. Nie odebrano? C\u00f3\u017c, pech... To wystarczy\u0142o do przesy\u0142ania film\u00f3w dla doros\u0142ych, ale do bardziej powa\u017cnych rzeczy potrzebna jest niezawodno\u015b\u0107, co oznacza, \u017ce trzeba b\u0119dzie co\u015b jeszcze nawin\u0105\u0107 na UDP.<\/p>\n<p>Podobnie jak w przypadku HTTP\/2, prace nad stworzeniem nowego protoko\u0142u rozpocz\u0119\u0142y si\u0119 w Google w 2012 roku, czyli mniej wi\u0119cej w tym samym czasie, co rozpocz\u0119cie prac nad SPDY. W 2013 roku Jim Roskind zaprezentowa\u0142 szerszej publiczno\u015bci <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">protok\u00f3\u0142 QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, a ju\u017c w 2015 roku zosta\u0142 wprowadzony Internet Draft w celu standaryzacji w IETF. Ju\u017c wtedy protok\u00f3\u0142 opracowany przez Roskinda w Google znacznie r\u00f3\u017cni\u0142 si\u0119 od wersji przedstawionej do standardu, dlatego wersja google'owska zacz\u0119\u0142a by\u0107 nazywana gQUIC.<\/p>\n<h4>Czym jest QUIC<\/h4>\n<p>\nPo pierwsze, jak ju\u017c wspomniano, jest to nak\u0142adka na UDP. Na bazie UDP ustanawiane jest po\u0142\u0105czenie QUIC, w kt\u00f3rym, analogicznie do HTTP\/2, mog\u0105 istnie\u0107 r\u00f3\u017cne strumienie. Strumienie te istniej\u0105 tylko na ko\u0144c\u00f3wkach i s\u0105 obs\u0142ugiwane niezale\u017cnie. Je\u015bli w jednym strumieniu dojdzie do utraty pakietu, inne nie s\u0105 w \u017caden spos\u00f3b dotkni\u0119te.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustracja Daniel Steinberg<\/i><\/p>\n<p>Po drugie, szyfrowanie jest teraz realizowane nie jako oddzielna warstwa, lecz jest w\u0142\u0105czone w protok\u00f3\u0142. To pozwala na nawi\u0105zywanie po\u0142\u0105cze\u0144 i wymian\u0119 kluczy publicznych w jednym u\u015bcisku r\u0119ki, a tak\u017ce umo\u017cliwia zastosowanie sprytnego mechanizmu 0-RTT handshake, eliminuj\u0105c op\u00f3\u017anienia przy handshake. Ponadto, teraz mo\u017cna szyfrowa\u0107 pojedyncze pakiety danych. To pozwala na nieczekanie na zako\u0144czenie odbioru danych ze strumienia, a na niezale\u017cne deszyfrowanie otrzymanych pakiet\u00f3w. Taki tryb pracy by\u0142 ca\u0142kowicie niemo\u017cliwy w TCP, poniewa\u017c TLS i TCP dzia\u0142a\u0142y niezale\u017cnie od siebie i TLS nie m\u00f3g\u0142 wiedzie\u0107, na jakie fragmenty TCP b\u0119dzie dzieli\u0142 dane. W zwi\u0105zku z tym nie m\u00f3g\u0142 przygotowa\u0107 swoich segment\u00f3w tak, aby odpowiada\u0142y segmentom TCP jeden do jednego i mog\u0142y by\u0107 deszyfrowane niezale\u017cnie. Wszystkie te ulepszenia pozwalaj\u0105 QUIC zmniejszy\u0107 op\u00f3\u017anienia w por\u00f3wnaniu z TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPo trzecie, koncepcja lekkich strumieni pozwala od\u0142\u0105czy\u0107 po\u0142\u0105czenie od adresu IP klienta. To jest istotne, na przyk\u0142ad, gdy klient prze\u0142\u0105cza si\u0119 z jednego punktu dost\u0119pu Wi-Fi na inny, zmieniaj\u0105c sw\u00f3j adres IP. W takim przypadku przy u\u017cyciu TCP nast\u0119puje d\u0142ugi proces, w kt\u00f3rym istniej\u0105ce po\u0142\u0105czenia TCP roz\u0142\u0105czaj\u0105 si\u0119 z powodu przekroczenia czasu i tworzone s\u0105 nowe po\u0142\u0105czenia z nowym IP. W przypadku QUIC klient po prostu kontynuuje wysy\u0142anie pakiet\u00f3w do serwera z nowego IP z zachowanym starym ID strumienia. Poniewa\u017c ID strumienia jest teraz unikalne i nie jest ponownie wykorzystywane, serwer rozumie, \u017ce klient zmieni\u0142 adres IP, dosy\u0142a utracone pakiety i kontynuuje komunikacj\u0119 pod nowym adresem.<\/p>\n<p>Po czwarte, QUIC jest realizowany na poziomie aplikacji, a nie systemu operacyjnego. Z jednej strony pozwala to na szybsze wprowadzanie zmian w protokole, poniewa\u017c aby uzyska\u0107 aktualizacj\u0119, wystarczy po prostu zaktualizowa\u0107 bibliotek\u0119, a nie czeka\u0107 na now\u0105 wersj\u0119 systemu operacyjnego. Z drugiej strony prowadzi to do znacznego wzrostu zu\u017cycia procesora.<\/p>\n<p>No i na koniec, nag\u0142\u00f3wki. Kompresja nag\u0142\u00f3wk\u00f3w odnosi si\u0119 dok\u0142adnie do r\u00f3\u017cnic mi\u0119dzy QUIC a gQUIC. Nie widz\u0119 sensu po\u015bwi\u0119ca\u0107 temu du\u017co czasu, powiem tylko, \u017ce w wersji zg\u0142oszonej do standaryzacji, kompresja nag\u0142\u00f3wk\u00f3w zosta\u0142a maksymalnie zbli\u017cona do kompresji nag\u0142\u00f3wk\u00f3w w HTTP\/2. Wi\u0119cej mo\u017cna przeczyta\u0107 <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">tutaj<\/a><\/noindex>.<\/p>\n<h4>Jak szybko jest to?<\/h4>\n<p>\nTo trudne pytanie. Chodzi o to, \u017ce p\u00f3ki co nie mamy standardu, wi\u0119c trudno jest co\u015b zmierzy\u0107. Prawdopodobnie jedyne dane statystyczne, kt\u00f3rymi dysponujemy, to dane z Google, kt\u00f3ry u\u017cywa gQUIC od 2013 roku i w 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">raportowa\u0142 przed IETF<\/a><\/noindex>, \u017ce oko\u0142o 90% ruchu kierowanego do ich serwer\u00f3w z przegl\u0105darki Chrome teraz korzysta z QUIC. W tej samej prezentacji informuj\u0105, \u017ce przy u\u017cyciu gQUIC strony \u0142aduj\u0105 si\u0119 oko\u0142o 5% szybciej, a w przypadku wideo strumieniowego wyst\u0119puje o 30% mniej zaci\u0119\u0107 w por\u00f3wnaniu do TCP. <\/p>\n<p>W 2017 roku grupa badaczy pod przewodnictwem Arasha Molavi Kakhki opublikowa\u0142a <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">wielk\u0105 prac\u0119<\/a><\/noindex> badanie wydajno\u015bci gQUIC w por\u00f3wnaniu z TCP. <br \/>\nBadanie ujawni\u0142o kilka s\u0142abo\u015bci gQUIC, takich jak niestabilno\u015b\u0107 przy mieszaniu pakiet\u00f3w sieciowych, nieuczciwo\u015b\u0107 w wykorzystaniu przepustowo\u015bci oraz wolniejsze przesy\u0142anie ma\u0142ych obiekt\u00f3w (do 10 kB). Ostatnie mo\u017cna jednak zrekompensowa\u0107 u\u017cywaj\u0105c 0-RTT. We wszystkich pozosta\u0142ych badanych przypadkach gQUIC wykaza\u0142 wzrost szybko\u015bci w por\u00f3wnaniu do TCP. O konkretnych danych tutaj trudno m\u00f3wi\u0107. Lepiej poczyta\u0107 <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">same badanie<\/a><\/noindex> lub <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">kr\u00f3tki post<\/a><\/noindex>.<\/p>\n<p>Tutaj trzeba powiedzie\u0107, \u017ce to s\u0105 dane dotycz\u0105ce gQUIC i nie s\u0105 aktualne dla rozwijanego standardu. Co b\u0119dzie w przypadku QUIC: na razie to tajemnica, ale istnieje nadzieja, \u017ce s\u0142abo\u015bci wykryte w gQUIC zostan\u0105 uwzgl\u0119dnione i naprawione.<\/p>\n<h2>Troch\u0119 o przysz\u0142o\u015bci: co z HTTP\/3?<\/h2>\n<p>\nTutaj wszystko jest jasne: API nie ulegnie zmianie. Wszystko pozostanie dok\u0142adnie tak, jak by\u0142o w HTTP\/2. Je\u015bli API pozostaje takie samo, przej\u015bcie na HTTP\/3 b\u0119dzie wymaga\u0142o u\u017cycia nowej wersji biblioteki na backendzie, wspieraj\u0105cej transport QUIC. Niestety, przez d\u0142ugi czas b\u0119dziemy musieli zachowa\u0107 wsparcie dla starszych wersji HTTP, poniewa\u017c internet obecnie nie jest gotowy na pe\u0142ne przej\u015bcie na UDP.<\/p>\n<h4>Kto ju\u017c wspiera<\/h4>\n<p>\nOto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">lista<\/a><\/noindex> istniej\u0105cych implementacji QUIC. Mimo braku standardu, lista jest ca\u0142kiem przyzwoita. <\/p>\n<p>\u017baden z przegl\u0105darek obecnie nie wspiera QUIC w stabilnej wersji. Niedawno pojawi\u0142a si\u0119 informacja, \u017ce w Chrome w\u0142\u0105czono wsparcie HTTP\/3, ale tylko w wersji Canary. <\/p>\n<p>Spo\u015br\u00f3d backend\u00f3w HTTP\/3 wspiera tylko <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> i <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, ale na razie w wersji eksperymentalnej. NGINX na pocz\u0105tku wiosny 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">og\u0142osili<\/a><\/noindex>, og\u0142osi\u0142, \u017ce pracuj\u0105 nad wsparciem HTTP\/3, ale jeszcze nie zako\u0144czyli.<\/p>\n<h4>Jakie s\u0105 problemy<\/h4>\n<p>\n\u017byjemy w realnym \u015bwiecie, gdzie \u017cadna du\u017ca technologia nie mo\u017ce przekroczy\u0107 granic mas, nie napotykaj\u0105c oporu, a QUIC nie jest wyj\u0105tkiem.<\/p>\n<p>Najwa\u017cniejsze, musimy jako\u015b wyt\u0142umaczy\u0107 przegl\u0105darce, \u017ce \"https:\/\/\" niekoniecznie prowadzi teraz do portu TCP 443. TCP w og\u00f3le mo\u017ce nie by\u0107 obecne. W tym celu u\u017cywany jest nag\u0142\u00f3wek Alt-Svc. Pozwala on poinformowa\u0107 przegl\u0105dark\u0119, \u017ce ta strona internetowa jest r\u00f3wnie\u017c dost\u0119pna na takim a takim protokole pod tak\u0105 a tak\u0105 adresem. Teoretycznie to powinno dzia\u0142a\u0107 bez zarzutu, ale w praktyce napotykamy problemy, \u017ce UDP mo\u017ce by\u0107 na przyk\u0142ad zablokowane w firewallu, aby unikn\u0105\u0107 atak\u00f3w DDoS.<\/p>\n<p>Ale nawet je\u015bli UDP nie jest zablokowane, klient mo\u017ce znajdowa\u0107 si\u0119 za routerem NAT, kt\u00f3ry jest skonfigurowany do utrzymywania sesji TCP pod adresem IP, a poniewa\u017c u\u017cywamy UDP, w kt\u00f3rym nie ma sesji sprz\u0119towej, NAT nie b\u0119dzie utrzymywa\u0142 po\u0142\u0105czenia, a sesja QUIC <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">b\u0119dzie si\u0119 ci\u0105gle zrywa\u0107.<\/a><\/noindex>. <\/p>\n<p>Wszystkie te problemy s\u0105 zwi\u0105zane z tym, \u017ce UDP wcze\u015bniej nie by\u0142 u\u017cywany do przesy\u0142ania tre\u015bci internetowych, i producenci sprz\u0119tu nie mogli przewidzie\u0107, \u017ce to kiedykolwiek si\u0119 zdarzy. W podobny spos\u00f3b administratorzy wci\u0105\u017c nie do ko\u0144ca rozumiej\u0105, jak prawid\u0142owo skonfigurowa\u0107 swoje sieci do pracy z QUIC. Ta sytuacja powoli b\u0119dzie si\u0119 zmienia\u0107, a w ka\u017cdym razie tego typu zmiany zajm\u0105 mniej czasu ni\u017c wdro\u017cenie nowego protoko\u0142u warstwy transportowej. <\/p>\n<p>Ponadto, jak ju\u017c opisano, QUIC znacznie zwi\u0119ksza zu\u017cycie procesora. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">oceni\u0142<\/a><\/noindex> wzrost zu\u017cycia procesora do trzech razy.<\/p>\n<h4>Kiedy nadejdzie HTTP\/3<\/h4>\n<p>\nStandard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">chc\u0105 go przyj\u0105\u0107.<\/a><\/noindex> Do maja 2020 roku, ale bior\u0105c pod uwag\u0119, \u017ce na chwil\u0119 obecn\u0105 dokumenty planowane na lipiec 2019 roku wci\u0105\u017c nie zosta\u0142y uko\u0144czone, mo\u017cna powiedzie\u0107, \u017ce data najprawdopodobniej zostanie przesuni\u0119ta.<\/p>\n<p>Google korzysta ze swojej implementacji gQUIC od 2013 roku. Je\u015bli spojrze\u0107 na zapytanie HTTP wysy\u0142ane do wyszukiwarki Google, mo\u017cna zobaczy\u0107 to:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: zburzenie podstaw i cudowny nowy \u015bwiat\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Wnioski<\/h2>\n<p>\nQUIC obecnie wygl\u0105da na do\u015b\u0107 niedopracowan\u0105, ale bardzo obiecuj\u0105c\u0105 technologi\u0119. Bior\u0105c pod uwag\u0119, \u017ce przez ostatnie 20 lat wszystkie optymalizacje protoko\u0142\u00f3w warstwy transportowej dotyczy\u0142y g\u0142\u00f3wnie TCP, QUIC, w wi\u0119kszo\u015bci przypadk\u00f3w wygrywaj\u0105cy pod wzgl\u0119dem wydajno\u015bci, wygl\u0105da ju\u017c teraz ca\u0142kiem dobrze. <\/p>\n<p>Jednak wci\u0105\u017c pozostaj\u0105 nierozwi\u0105zane problemy, z kt\u00f3rymi trzeba b\u0119dzie zmierzy\u0107 si\u0119 w najbli\u017cszych latach. Proces mo\u017ce si\u0119 przed\u0142u\u017cy\u0107 ze wzgl\u0119du na sprz\u0119t, kt\u00f3ry nikt nie lubi aktualizowa\u0107, jednak wszystkie problemy wydaj\u0105 si\u0119 by\u0107 do rozwi\u0105zania, i pr\u0119dzej czy p\u00f3\u017aniej wszyscy b\u0119dziemy korzysta\u0107 z HTTP\/3. <\/p>\n<p>Przysz\u0142o\u015b\u0107 jest tu\u017c za rogiem!<br \/>\n<br \/>\u0179r\u00f3d\u0142o: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/473930\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52181","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-01T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T10:59:51+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HTTP\/3: niszczenie fundament\u00f3w i wspania\u0142y nowy \u015bwiat | ProHoster","description":"Od ponad 20 lat przegl\u0105damy strony internetowe za pomoc\u0105 protoko\u0142u HTTP. Wi\u0119kszo\u015b\u0107 u\u017cytkownik\u00f3w w og\u00f3le nie zastanawia si\u0119, czym to jest i jak to dzia\u0142a.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster","og:description":"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-01T21:00:00+00:00","article:modified_time":"2020-02-18T10:59:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52181","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:48:31","updated":"2026-01-24 02:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}