Kniha HTTP/3 Explained

Daniel Stenberg, autor nástroje curl, publikoval knihu s názvem HTTP/3 Explained (pdf, GitHub) věnovanou nadcházející major verzi protokolu HTTP aneb HTTP nad protokoly QUIC a UDP.

27.11.2018 14:22 | Ladislav Hagara | Zajímavý článek

Komentáře

[trekker.dk]

I, for one, welcome our new Google overlords.

[Grunt]

Velice solidní prdel bude až se to fakt implementuje a někdo si přes to UDPčko dá tahat něco co nevleze do páč paketů (třeba gigový soubor). To bude pak velmi solidní DoS na router před klientem. Hodně štěstí přeju všem administrátorům sítí, ještě že já už se s tím srát nemusím.

[cezz]

No neviem, co si spominam tak Google uz implementoval ich verziu Quick v Chrome a tiez na serverovej strane, takze uz nejake tie gigabajty cez UDP pretiekli.

[Filip Jirsák]

Velice solidní prdel bude až se to fakt implementuje

Rok 2012 už byl, pokud je mi známo…

někdo si přes to UDPčko dá tahat něco co nevleze do páč paketů (třeba gigový soubor)

Videa na YouTube se podle vás vejdou do pár paketů, nebo aspoň ta delší, třeba hodinová, splňují vaše představy o velkém souboru?

Nebo že byste vůbec netušil, o čem je řeč? Že by vás třeba nenapadlo, že řízení toku nemusí být implementováno jen v protokolu TCP, ale může být implementováno i v jiných protokolech?

[Grunt]

Rok 2012 už byl, pokud je mi známo…

HTTP/2 bylo standardizováno v roce 2015. Holt to je tak když si svoje novinky tlačí do svého prohlížeče a pak je následně standardizuje.

Videa na YouTube se podle vás vejdou do pár paketů, nebo aspoň ta delší, třeba hodinová, splňují vaše představy o velkém souboru?

To bych nesměl používat youtube-dl Jenže jak se tak dívám i ten YouTube přehrávač má implementovaný jakýsi protokol, protože si nabuferuje pár paketů dle toho jak se přehrává, pak to potvrzuje, zas si něco málo nabufferuje, atd. To je ještě v pohodě (ostatně UDP se používalo na přehrávání videa už dávno před tím než vůbec nějaký YouTube vznikl).

Že by vás třeba nenapadlo, že řízení toku nemusí být implementováno jen v protokolu TCP, ale může být implementováno i v jiných protokolech?

Jenže nemusí být implementováno rozumně. TCP používá velmi solidní algoritmus a zahození paketu v některé queue způsobí okamžitou reakci a uzpůsobení šířce pásma. Naopak u některých najmenovaných „chytrých“ protokolů to způsobí tak akorát požadavek o opakování rámce. Připočtu-li k tomu šoupání v různých distribuovaných hashovacích tabulkách občas z toho může být solidní DDoS na router o kterém vlastní klient ani nemusí vědět. Proto z toho nejsem nějak extra nadšený. U videa není UDP problém protože např. živý stream má určitou pevně danou šířku pásma a zahození jednoho a pár paketu v něm nehraje roli (pakety se už neopakují). Naopak u služeb jako je web je prostě doručení kompletního obsahu povinnou podmínkou pro zobrazení vlastního obsahu. Ale jak říkám, já jsem akorát rád že to naštěstí nemusím řešit, takže nech si implementuje a standardizuje Google co chce, jak uzná za vhodné.

[Filip Jirsák]

Holt to je tak když si svoje novinky tlačí do svého prohlížeče a pak je následně standardizuje.

Mně to připadá jako velmi dobrý způsob, protože se pak standardizuje něco, co už je v praxi odzkoušené, a ne něco, co si někdo od zeleného stolu vymyslel, že takhle by to možná mohlo fungovat, tak to standardizujeme a uvidíme, jak to dopadne.

To bych nesměl používat youtube-dl Jenže jak se tak dívám i ten YouTube přehrávač má implementovaný jakýsi protokol, protože si nabuferuje pár paketů dle toho jak se přehrává, pak to potvrzuje, zas si něco málo nabufferuje, atd. To je ještě v pohodě (ostatně UDP se používalo na přehrávání videa už dávno před tím než vůbec nějaký YouTube vznikl).

Nejde o to, zda to používáte zrovna vy, ale o to, že už to používá docela dost lidí – a žádný DoS se nekoná.

Jenže nemusí být implementováno rozumně.

To nemusí být implementováno ani TCP. Akorát že ani na straně serveru ani na straně klienta nemá nikdo zájem používat nerozumnou implementaci, která bude akorát zahlcovat linku zbytečnými pakety. Protože na obou stranách to znamená jen zvýšení nákladů na konektivitu nebo výkon, a žádný přínos.

U videa není UDP problém protože např. živý stream má určitou pevně danou šířku pásma a zahození jednoho a pár paketu v něm nehraje roli (pakety se už neopakují). Naopak u služeb jako je web je prostě doručení kompletního obsahu povinnou podmínkou pro zobrazení vlastního obsahu.

Ale tady se bavíme o protokolu HTTP, který neumožňuje vynechávat pakety – v HTTP komunikaci musí dorazit všechny pakety, i u videa, kde už by třeba nebyly potřeba. Takže i když jde o video, doručuje se to pořád stejně, jako pro jakýkoli jiný web.

[Grunt]

Akorát že ani na straně serveru ani na straně klienta nemá nikdo zájem používat nerozumnou implementaci, která bude akorát zahlcovat linku zbytečnými pakety.

Proto HTTP/2 implementuje něco jako Server Push. Znám pouze jednu ještě lepší věc, distribuovaný Server Push se kterým brzo určitě nějaký chytrák přijde. Ale jo. Třeba bude QUIC standardizovaný do HTTP/3 super nádherný.

[Filip Jirsák]

Server Push ovšem neslouží k zahlcování linky zbytečnými pakety.

Nemáte s tím v životě problém, když u všeho očekáváte, že to bude implementované tím nejhorším možným způsobem, který bude všem jenom škodit?

[Grunt]

Server Push ovšem neslouží k zahlcování linky zbytečnými pakety.

Jasně, slouží ke zrychlení zobrazování s tím že při natažení stránky začne tlačit data i bez requestů, jenže v podání UDP to bude mít jeden jediný výsledek: namísto uspořádaných streamů bude HTTP série burstů s tím jak klient bude procházet stránky a posílat requesty jeden za druhým. Za kolik procent celkového provozu na internetu je HTTP zodpověděno? Googlu myslím můžu pogratulovat už teď.

Nemáte s tím v životě problém, když u všeho očekáváte, že to bude implementované tím nejhorším možným způsobem, který bude všem jenom škodit?

Že by zkušenost?

[Filip Jirsák]

Jasně, všichni jenom čekají na to, jak HTTP/3 naimplementovat co nejblběji. Co přesně implementovat stejně blbě už dneska třeba TCP, nebo HTTP/1.1 nebo HTTP/2?

[trekker.dk]

Server Push ovšem neslouží k zahlcování linky zbytečnými pakety.

Jistě, protože data, která mi tlačí, i když už je mám v cache prohlížeče, jsou velice užitečná.

[cezz]

Preco by to robil? (ignorujuc fakt, ze prehliadac ma moznost taky stream odmietnut)

Inak toto je presne vec ktoru sa snazi HTTP/2 riesit - momentalne je bezna prax take skripty, css a ktovie co este vkladat inline priamo do html. Alternativne sa to riesi tak, ze take subory zlepis dokopy a podobne workaroundy, aby si nemusel generovat tony requestov na zobrazenie stranky.

HTTP/2 ti umoznuje ich poslat/vyziadat ako jednotlive subory, ktore vies normalne ulozit do cache bez toho aby si musel robit tonu spojeni na server a opakovat handshake na urovni TCP, SSL a HTTP.

Jasne, bolo by super keby sme vsetci mali jednoduche html a na nejake css a javascripty sa vykaslali, ale realita je taka, aka je. (plus nie vzdy je to mozne)

[trekker.dk]

Preco by to robil? (ignorujuc fakt, ze prehliadac ma moznost taky stream odmietnut)

To může, problém je v tom, že na pomalém mobilním připojení s latencí v řádu sekund je v době, kdy prohlížeč ten stream odmítne, už přinejlepším několik desítek kilobytů na cestě a prostě budou přeneseny - to bude trvat jednotky i desítky sekund a všechno to budou data, která prohlížeč zahodí. Odmítnout lze pouze to, co webserver server nepředal síťovému stacku pod sebou.

Inak toto je presne vec ktoru sa snazi HTTP/2 riesit - momentalne je bezna prax take skripty, css a ktovie co este vkladat inline priamo do html.

Pletete si pojmy a dojmy. HTTP/2 nic takového neřeší, je to přenosový protokol pro (dneska občas i) HTML a pokud skripty a css inline vložíte přímo do HTML, bude to fungovat i na HTTP/1.1. (A naopak pokud to neuděláte, HTTP/2 vás nijak nevytrhne.)

HTTP/2 ti umoznuje ich poslat/vyziadat ako jednotlive subory, ktore vies normalne ulozit do cache bez toho aby si musel robit tonu spojeni na server a opakovat handshake na urovni TCP, SSL a HTTP.

Tak tohle od doby, co existuje keep-alive, HTTP/1.1 umí taky.

[Filip Jirsák]

To může, problém je v tom, že na pomalém mobilním připojení s latencí v řádu sekund je v době, kdy prohlížeč ten stream odmítne, už přinejlepším několik desítek kilobytů na cestě a prostě budou přeneseny - to bude trvat jednotky i desítky sekund a všechno to budou data, která prohlížeč zahodí. Odmítnout lze pouze to, co webserver server nepředal síťovému stacku pod sebou.

Proč by něco takového server dělal? Vy si myslíte, že mají provozovatelé serverů výkon a kapacitu linky zadarmo, aby do ní chrlili data, která se pak zahodí? Pokud chce webserver řídit tok dat (jako že v případě spojení přes UDP musí), nemůže síťovému stacku předat velký objem dat a nechat to neřízeně odeslat.

Tak tohle od doby, co existuje keep-alive, HTTP/1.1 umí taky.

Ne zcela. HTTP/1.1 odesílá odpovědi v takovém pořadí, v jakém přišly požadavky. Takže když přijde požadavek na stránku a za ním požadavky na styly, skripty, obrázky, aplikace nejprve kontaktuje databázi, získá příslušná data, vyrenderuje stránku a pak jí webserver začne odesílat. Teprve když jí odešle, začnou se posílat další soubory v pořadí, v jakém byly požadovány. Přitom ty už se mohly odesílat v té době, když se čekalo na databázi a vyrenderování stránky.

[petr_p]

Aplikace může pomocí chunked encoding poslat začátek stránky, který odkazuje na všechny externí dokumenty, a až si server spočítá data, může poslat zbytek. Nehledě na to, že dnes je v módě poslat prázdnou stránku a data dotáhnout dodatečně pře javascript.

[Martin Mareš]

Aplikace může pomocí chunked encoding poslat začátek stránky, který odkazuje na všechny externí dokumenty, a až si server spočítá data, může poslat zbytek.

Jak? HTTP/1 neumí prokládat odpovědi na jednotlivé requesty, a to ani jako chunky. Důvod je jednoduchý: v chunku není napsáno, ke kterému requestu patří.

[petr_p]

Proto TCP má porty.

[Martin Mareš]

Ach tak, já pořád myslel, že to snažíte udělat nějak rozumně po jednom spojení

Více spojení si samozřejmě můžete založit, ale hezky se to chovat nebude: čekáte na sestavení spojení, TCP nějakou dobu trvá, než dokonverguje k dobrému odhadu propustnosti linky atd.

[cezz]

Plus je realny limit na pocet spojeni na strane servera a na strane roznych middle boxov po ceste. Prakticky je takych spojeni k dispozicii cca 6-7. Cize stale plati, ze si obmedzeny tym, co vies realne stahovat sucasne.

Neviem teraz narychlo najst ten vyskum, ale prakticky to "funguje" tak, ze pre (tusim) Alexa top 100 stranok uz niekde od 5Mbps nema vyssia rychlost pripojenia prakticky vplyv na rychlost nacitania stranky. Prave preto, ze si obmedzeny poctom paralelnych spojeni. HTTP/2 toto riesi ciastocne, ale ma aj svoje nevyhody, ktore HTTP/3 riesi prechodom na UDP.

[Grunt]

Nehledě na to, že dnes je v módě poslat prázdnou stránku a data dotáhnout dodatečně pře javascript.

Nebo nad tím rovnou stavět kancelářské balíky. Není divu že pak Google potřebuje vlastní protokol.

[petr_p]

Protože majitel serveru ví, co má na stránce a bez jakých další dokumentů se stránka zobrazená podle představ majitele neobejde. Kdyby majitelé měli nedostatek výkonu a pásma, tak předně nebudou vypínat cachování dokumentů a domovská stránka nebude zabírat desítky megabajtů. V blahobytné postinformační společnosti výkon ani linka není problém. Problém je jak zobrazit informaci u uživatele co nejrychleji, protože zhýčkaný uživatel přece nebude čekat několik sekund na zobrazení.

[Filip Jirsák]

Nikdo nepsal o nedostatku výkonu a pásma na straně serveru. Ale poslat ze serveru data, která klient nedokáže přijmout a server je bude muset poslat znovu, je úplně k ničemu – přínos není žádný, jenom náklady.

[Martin Mareš]

Kde jste vzal, že klient je nedokáže přijmout? HTTP/3 má regulérní flow control, takže data dojdou v pořádku. Spíš se může stát, že klient je pečlivě přijme, načež zjistí, že je už dávno zná, takže novou kopii zahodí.

[Filip Jirsák]

Řeč byla o klientovi na pomalé lince, do které chybně implementovaný server vychrlí spoustu paketů. Buffery po cestě samozřejmě nejsou nekonečně velké, takže by se ty pakety někde cestou zahodily. Vy stejně jako já počítáte s rozumnou implementací, já jsem ale reagoval na komentáře, které očekávají tu nejhorší možnou implementaci řízení toku.

[Martin Mareš]

Chybně implementovaný server může samozřejmě klienta zahltit, ať už bude protokol jakýkoliv. Nemyslím si, že by chybných implementací HTTP/3 bylo na světě víc než chybných implementací TCP. Ty samozřejmě existují, ale naštěstí je většina autorů serverů dost líná na to, aby sáhla po nějaké běžně používané implementaci TCP. Čekal bych, že u HTTP/3 to dopadne velmi podobně.

[Filip Jirsák]

Mně to vysvětlovat nemusíte, já tvrdím to samé. Reagoval jsem na Grunta a trekkera.dk, kteří jsou zřejmě přesvědčeni, že těch chybných implementací HTTP/3 bude většina.

[trekker.dk]

Které tu nejsou, pouze jste nepochopil napsaný text.

[cezz]

To může, problém je v tom, že na pomalém mobilním připojení s latencí v řádu sekund je v době, kdy prohlížeč ten stream odmítne, už přinejlepším několik desítek kilobytů na cestě a prostě budou přeneseny - to bude trvat jednotky i desítky sekund a všechno to budou data, která prohlížeč zahodí. Odmítnout lze pouze to, co webserver server nepředal síťovému stacku pod sebou.

Stale sa ale bavime o teoretickej situacii kedy server posle nieco, co uz ma klient v cache, co je v zasade miskonfiguracia servera, pretoze normalne nema dovod to robit. Plus ma klient moznost nastavit mnozstvo in-flight dat (obdoba TCP window size), takze napriklad mobilny klient vie pre take pripady toto nastavit na minimum pre push objekty. (aby napriklad dostal len hlavicku na zaklade ktorej vie posudit, ci ma najnovsiu verziu v cache) Inak prakticky, pokial sa nebavime o uplnych extremoch je vo vacsine pripadov lepsie nejake data prijat a potencionalne zahodit nez stravit ten cas cakanim a robenim requestov. Je to proste dane tym, ze bezne pripojenie nie je vytazene na 100% stahovanim dat pre stranku, ale je vacsinu casu nevyuzite cakanim medzi requestmi. (ak si spravne spominam niekde od 5Mbps, pri mobilnom pripojeni uz niekde od 2Mbps tu linku zvycajne nevyuzivas na 100%)

Pletete si pojmy a dojmy. HTTP/2 nic takového neřeší, je to přenosový protokol pro (dneska občas i) HTML a pokud skripty a css inline vložíte přímo do HTML, bude to fungovat i na HTTP/1.1. (A naopak pokud to neuděláte, HTTP/2 vás nijak nevytrhne.)

Pri HTTP/1.1 nevies robit multiplexing, cize v zasade vies stahovat viac objektov naraz len tak, ze otvoris viac spojeni. Ten pocet spojeni je prakticky limitovany niekde na urovni 5-7. (bavime sa o praktickom limite danom browserom a zariadeniami po ceste) Cize pri HTTP/1.1 sa toto riesi viacerymi sposobmi - napriklad mas zdroje na viacerych domenach (domain sharding), alebo zlepis vsetky javascripty/css/obrazky do jedneho suboru aby si znizil pocet nutnych requestov. Pri zdrojoch ktore predpokladas ze klient nutne potrebuje pri kazdom nacitani stranky sa to casto riesi tak, ze to CSS/javacsript vlozis priamo do stranky. Toto vsetko su workaroundy, ktore maju svoje nevyhody. Domain sharding vyzaduje viac domen a casto sa to riesi stylom *.cdn.example.com kde potom webstranka odkazuje na ${random}.cdn.example.com objekt, cize tym zabijas cache. Zlepovanie suborov dokopy potom znamena, ze pri zmene jedneho suboru musis nacitat cely objekt znova. Pri obrazkoch (tzv sprites) musis tiez potom v css riesit to, aby si pouzil spravny vyrez na spravny element. Vkladanie css/js inline samozrejme vylucuje cache uplne, pretoze tie data dostanes ci sa ti to paci, ci nie.

HTTP/2 vsetky tieto workaroundy robi zbytocnymi, pretoze si mozes v ramci jedneho spojenia vyziadat omnoho viac objektov naraz a nie len to, vies si tiez nastavit a menit prioritu. (napriklad nacitas hlavicku obrazku s vysokou prioritou aby si vedel rozmery a vedel vypocitat rozlozenie stranky a data uz dotahas pomalsie lebo napriklad vies, ze obrazok bude mimo zaberu) Ale dolezite je, ze ti to opat umoznuje mat tam tie objekty jednotlivo a nechat browser rozhodnut co a kedy stahovat. Tiez ti to umoznuje ich ukladat jednotlivo v cache a nemusis robit CSS triky aby ti fungovali sprity. A sice je pravda, ze pokial bude autor webu stale pouzivat spominane HTTP/1.1 workaroundy, tak sa situacia zasadne nezlepsi, ale tiez je pravda, ze s HTTP/2 uz nebude nuteny ich pouzivat.

Tak tohle od doby, co existuje keep-alive, HTTP/1.1 umí taky.

Multiplexing a keep-alive su dve rozne veci. Keep-alive ti umoznuje poslat cez jedno spojenie viac requestov, ale stale su limitovane tym, ze su seriovo za sebou, cize nevies riesit dynamicky prioritu. Tiez HTTP/2 vie robit kompresiu hlaviciek napriec requestmi, takze nie si nuteny posielat komplet hlavicky s kazdym jednym poziadavkom ako HTTP/1.1.

[petr_p]

Stale sa ale bavime o teoretickej situacii kedy server posle nieco, co uz ma klient v cache, co je v zasade miskonfiguracia servera, pretoze normalne nema dovod to robit.

Server má křišťálovou kouli, která mu řekne, jestli prohlížeč má v cachi styly a ikonky z včerejší návštěvy?

Ten pocet spojeni je prakticky limitovany niekde na urovni 5-7. […] Cize pri HTTP/1.1 sa toto riesi viacerymi sposobmi - napriklad mas zdroje na viacerych domenach (domain sharding)

Krásně jste si popřel svých 5–7 spojení. To číslo není nějaká vlastnost protokolu, ale výchozí nastavení Firefoxu, aby uživatelé nezabili server, případně si sobě neucpali linku. Číslo poplatné době zanesení do zdrojového kódu.

[cezz]

Server má křišťálovou kouli, která mu řekne, jestli prohlížeč má v cachi styly a ikonky z včerejší návštěvy?

Tak trochu - vola sa to ETag.

Krásně jste si popřel svých 5–7 spojení. To číslo není nějaká vlastnost protokolu, ale výchozí nastavení Firefoxu, aby uživatelé nezabili server, případně si sobě neucpali linku. Číslo poplatné době zanesení do zdrojového kódu.

Za prve, nie je to len vlastnost firefoxu, vsetky ostatne prehliadace su limitovane podobne.

Za druhe aj ked pouzijes domain sharding, tak mas limit niekde na urovni 30-40 spojeni. Pre porovnanie - relativne jednoduche abclinuxu.cz so zablokovanymi reklamami robi cca 50 requestov. Bezne je to aj okolo stovy requestov - a to aj napriek tomu ze sa pouzivaju spomenute triky na znizenie poctu suborov.

Za tretie, keby si aj nastavil pocet spojeni na nejaky vyssi limit, tak prakticky su casto prehliadace limitovane na pomerne maly pocet spojeni zariadeniami po ceste. Prehliadace maju taky limit nie len preto, aby nerobili DDOS na server, ale aj preto aby nenarazili na tieto limity.

A stale plati, ze keby si mal k dispozicii nekonecno spojeni tak by si stale platil dan v podobe TCP/SSL/HTTP handshake.

[trekker.dk]

Tak trochu - vola sa to ETag

Který se vztahuje k tomu požadavku na stránku, nikoliv nutně k CSS a dalšímu bordelu okolo. A o tom, že to reálné aplikace budou vůbec nějak řešit, bych si dovolil s úspěchem pochybovat.

[cezz]

Který se vztahuje k tomu požadavku na stránku, nikoliv nutně k CSS a dalšímu bordelu okolo.

Nie je ziadny technicky dovod preco by sa Etag nutne musel vztahovat len na konkretnu poziadavku a nie na extra subory.

A o tom, že to reálné aplikace budou vůbec nějak řešit, bych si dovolil s úspěchem pochybovat.

Co som videl, tak sa to zvycajne riesi tak, ze server sa rozhoduje pushnut obsah na zaklade cookie ktora drzi poslednu verziu ktoru ma klient potencialne v cache a ak by mohol mat, tak sa push nekona. (cize worst case scenario je ze si to proste klient normalne vyziada)

A stale si dovolim tvrdit, ze ked sa push pouziva na veci kde to ma zmysel, (css, js, ikony pre interface a podobne) tak aj keby si pomerne hlupo posielal vsetko bez ohladu na cache, tak vo vacsine pripadov bude cena za zahodenie tych dat pre koncoveho pouzivatela zanedbatelna. (v tom zmysle ze vyuzije o kusok viac prenosove pasmo, ktore by inak bolo nevyuzite) Obzvlast ak to berieme v tom svetle, ze dnes defacto ten push robi vela stranok aj tak - a sice vo forme js a css vlozenych priamo v html. Tam uz ani nemas ako povedat serveru aby ti to neposielal a napriek tomu to vela stranok robi, lebo je to zvycajne aj tak rychlejsie.

[trekker.dk]

v tom zmysle ze vyuzije o kusok viac prenosove pasmo, ktore by inak bolo nevyuzite

Řekl člověk, který zjevně nemá praktické zkušenosti s přenosovým pásmem mobilního internetu. A tím myslím mobilní internet, tj. zařízení se pohybuje a ne zrovna uprostřed Prahy, kde je LTE.

[cezz]

To je pravda, v niektorych pripadoch je na tom HTTP/2 v urcitych sposoboch vyuzitia horsie ako HTTP/1.1 a toto bude prave jeden z nich. Jeden typicky pripad je velka stratovost linky, kedy ti to jedno HTTP/2 spojenie "vytuhne" pre par stratenych packetov a prakticky ti tak zastavi niekolko internych streamov. (na rozdiel od jedneho z viacerych spojeni pri HTTP/1.1 ktore s trochou stastia nemusi byt az tak dolezite)

A to je presne to, co sa HTTP/3 snazi riesit prechodom na UDP.

[cezz]

Inak asi by som mal dodat, ze si vies HTTP/2 v prehliadaci vypnut, protokol je spatne kompatibilny s HTTP/1.1 a server ti proste odpovie ako si povies, nie je to bud-alebo situacia.

[Grunt]

Jo, jo a jestli to dobře čtu, tak zrovna TCP congestion control je to co jim vadí (resp. fakt že v dnešní době je mezi serverem a klientem spousta různých boxů a každý si implementuje vlastní frontu s vlastním zahazováním). Nemůžu se dočkat toho TCP-like congestion control. Multiple streams a řídit to už nebude žádný box, ale server že?

[trekker.dk]

Ono co Googlu hlavně vadí, jsou krabice, které filtrují provoz. Protože pak někdo může na firemní krabici zablokovat zaměstnancům přístup ke Googlím službám a sledovačkám a to je naprosto nepřípustné.

[Martin Mareš]

To není hlavní problém. Náhodné krabice filtrující provoz bohužel znemožňují další rozvoj protokolů. I s tak triviálním rozšířením, jako je EDNS(0), má dodneška mnoho middleboxů zásadní problémy. Podobně jsou ještě dnes běžné middleboxy, přes které neprojde Path MTU Discovery.

Proto se autoři některých novějších protokolů snaží šifrovat všechno, co jde, aby middleboxy do packetů neviděly.

[trekker.dk]

Náhodné krabice filtrující provoz bohužel znemožňují další rozvoj protokolů.

Řekl bych, že tady by se slušelo napsat další nekompatibilní rozvoj. Což už není chyba jenom těch krabic.

Podobně jsou ještě dnes běžné middleboxy, přes které neprojde Path MTU Discovery.

Pokud se bavíme o IPv6, tak bych to viděl jako oddělený problém, PMTU discovery IMO není rozvoj, RFC je datováno cca půl roku po samotném IPv6 - v roce 1996. To bych spíš považoval za blbou implementaci než co jiného.

[cezz]

Řekl bych, že tady by se slušelo napsat další nekompatibilní rozvoj. Což už není chyba jenom těch krabic.

Nie, HTTP protokol umoznuje pomerne jednoducho a kompatibilne upgradovat protokol na HTTP/2 aj bez SSL, ale v praxi cca 20% takych requestov zlyha, alebo antivir/firewall/whatever taky request zablokuje lebo neimplementuje HTTP spravne.

[Martin Mareš]

Řekl bych, že tady by se slušelo napsat další nekompatibilní rozvoj. Což už není chyba jenom těch krabic.

Často byl protokol už na počátku navržen jako rozšiřitelný, takže je v jeho zprávách prostor na různé options, nové flagy apod. Specifikace přitom dost přesně říká, jak se má implementace chovat, pokud potká neznámý option/flag. Ovšem middleboxy toto naprosto běžně porušují a například všechny pakety, ve kterých je neznámý option, zahazují.

Pokud se bavíme o IPv6, tak bych to viděl jako oddělený problém

Nikoliv, měl jsem na mysli PMTU discovery pro IPv4. To je například standardní součást dnešních implementací TCP, ale některé middleboxy to kazí tím, že negenerují či nepropouštějí zprávy ICMP MTU Exceeded.

[trekker.dk]

Často byl protokol už na počátku navržen jako rozšiřitelný, takže je v jeho zprávách prostor na různé options, nové flagy apod.

Mám takový dojem, že EDNS zrovna nebyl tenhle případ - nebo jo?

Nikoliv, měl jsem na mysli PMTU discovery pro IPv4. To je například standardní součást dnešních implementací TCP, ale některé middleboxy to kazí tím, že negenerují či nepropouštějí zprávy ICMP MTU Exceeded.

Ok, pravda je, že co všechno lidi považují za dobrý nápad při filtrování ICMP, to člověku hlava nebere. Nejenom u middleboxů.

[Grunt]

1. Proč by zrovna ve firemním prostředí někdo zakazoval přístup ke službám Googlu? Vždyť nemají implementovaný ani stupidní Solitare.
2. No tak zrovna přechodem na UDP si teda pomůžou.

[trekker.dk]

No tak zrovna přechodem na UDP si teda pomůžou.

Cílem Google - někdo od nich to tak IIRC prezentoval na nějaké přednášce - je nejenom přechod na UDP, ale také měnit ten protokol tak často a tak hodně, aby se takové filtrovací krabice nedaly postavit.