Vlákno názorů k článku
HTTP 2.0 bude binární protokol od Ondřej Tůma - V dnešní době si tou binární podobou nejsem...

Kdyby binární protokol měl nějakou aspoň vzdálenou souvislost s centralizací/de­centralizací a s otevřeností/u­zavřeností internetu, mohl váš komentář dávat nějaký smysl. Škoda, že tomu tak není.

To jsem udělal samozřejmě před napsání předchozího komentáře. Zjistil jsem, že internet je postavený na binárním protokolu IP a dvojici TCP/IP a UDP - vše binární protokoly. Pro koncové uživatele je pak klíčový ještě protokol DNS - také binární. Takže podle vaší teorie je internet centralizovaný a uzavřený od samého počátku.

Ve skutečnosti ale decentralizace ani otevřenost nijak nesouvisí s tím, zda je protokol binární nebo textový. V případě protokolů souvisí jen s tím, zda je ten protokol standardizovaný a zda se ta standardizovaná verze reálně používá. Z toho důvodu je HTTP 2.0 krokem k větší otevřenosti. Dnes má Google svůj proprietární protokol SPDY a má sílu prosazovat jej. HTTP 2.0 má ale SPDY nahradit, a bude to protokol standardizovaný konsorciem, takže ho nemůže Google jen tak vzít a změnit (to v případě SPDY může, může ho i uzavřít).

Že by tedy d.c. jenom zaměnil příčinu a následek? Jinak ani ve vašem případě není „centralizovaný“ to správné slovo. Webový e-mail nebo vyhledávač jsou pořád decentralizované aplikace. Jenom shodou okolností pár hráčů udělalo ty aplikace tak dobré, že získali významný podíl na trhu. Pro ty aplikace se tedy nový protokol hodí ne proto, že by byly centralizované, ale proto, že obsluhují velké množství uživatelů současně.

Já tedy nevím o jiném problému, který by se dnes hromadně řešil napříč webovými servery (a nejviditelněji jej řeší Google). Nepodezíral bych je, že to dělají jen z pouhého rozmaru.

CDN server dokáže hlavičku 304 nebo i data z diskové cache odeslat na „pár“ taktů procesoru. Jenže před tím musí z hlaviček zjistit, co a zda má vůbec posílat – a je hloupé, když tahle operace je o několik řádu náročnější.

Paralelizace není na binárním protokolu závislá, ale je to jedna ze změn v HTTP 2.0, která sama o sobě přenášená data pro člověka velmi znečitelní. Holt asi čitelnost pro člověka není tak zásadní přínos – ostatně IP, TCP/IP, DNS nebo HTTPS jsou taky binární a pro člověka nečitelné protokoly.

Textové HTTP hlavičky nejsou napsané tak, aby se snadno parsovaly – vždyť i když chcete jenom oddělit jednotlivé hlavičky od sebe, musíte jet znak po znaku a hledat první CRLF, který není escapovaný uvnitř řetězce v uvozovkách a není následovaný bílým znakem.

Google dělá a zkouší různé věci. To že něco začne dělat google ještě neznamená že je to správná cesta, nebo cesta která se ujme.

Jenže před zpracováním http hlavičky je vrchol dané operace. Z obou stran se totiž musí zpracovat tcp/ip/ethernet a dalších jiných milion přerušení / signálů v rámci přepínání procesů / vláken, logování, různých tcp/ip pravidel, inicializací atd... Proto prostě nevěřím že to zrychlení bude tak super.

Chápu binární protokoly, v mnoha případech mají svůj zřejmý a jasný význam. Tím spíš, když se přenáší binární data. Ale u http 2.0 mě přijde, že si řekli, je to jeden z mála textových protokolů, uděláme z něj binární.

Ta paralelizace není zas až takový problém. Ano nepatřím k těm, co vidí problém v použití tcpdumpu a jiných nadstaveb, ale maily které chodí textově taky mohou obsahovat Xkrát vnořené přílohy a dá se v tom vyznat.

S těmi textovými hlavičky to snad ani nemyslíte važně? V čem je problém iterovat znaky až narazím na ':' a následně na CRLF ? Stejně tak porovnávání celých stringů je teoreticky náročnější proti číslu přesně tolikrát, kolik porovnáváte znaků.

Ano pokud bych psal nějaký http balancer pro AVR, asi by bylo fajn ušetřit těch pár taktů. Ale i tak bych musel řešit tolik věcí okolo, že textové hlavičky jsou jen zanedbatelnou prkotinou. Ta režie okolo, je prostě výrazně větší.

Google nebyl argument pro to, že je to správné řešení, ale pro to, že jde o reálný problém.

Zpracování příchozího paketu s minimem přerušení, kopírování a přepínání kontextů už je vyřešené. Ethernetové a TCP/IP hlavičky zpracuje už síťová karta, data umístí do hlavní paměti a jádro jen tuhle část paměti zpřístupní aplikaci. Pokud vím, v současné době se např. do linuxového jádra implementuje to, aby se pod zátěží nepoužívala pro čtení ze sítě přerušení. Textové hlavičky jsou tedy v současné době jediná věc, kterou nejde tímhle způsobem optimalizovat.

Problém s iterováním, dokud nenarazíte na CRLF, je v tom, že je to špatně :-) Tohle celé je jedna hlavička, ukončená až tím posledním CRLF:

X-Header: "ab\[CR]\[LF]cd"[CR][LF][SP]ef[CR][LF]

Na té režii okolo se asi neshodneme. Když tohle autoři webserverů optimalizují, já jim věřím, že vědí, proč to dělají.

Pravidla firewallu nahraje systém přímo do síťovky. A síťovka ani nepřijme paket pro neregistrovanej tpc port. Aplikace pak jen dostane naservírovaný data a po pár taktech je rovnou zpracuje. Přijde mi to moc super na to, aby to byla pravda.

A co se té víceřádkové hlavičky týče, to je pořád velmi jednoduchá logika.

Ale alespoň na něčem se shodneme. Na tom že se s tou režií neshodneme :)

Tak jako tak, standard nestandard, dokud ho nebudou mít masivně implementované obě strany (client i server), tak tu můžeme diskutovat donekonečna. Nehledě na to, že pořád musí existovat z5ná kompatibilita, alespoň do té doby, dokud to bude ekonomicky zajímavé.

Na takovémhle stroji nemají co dělat žádná pravidla firewallu. Mapování port -> aplikace je jednoduché.

Ta víceřádková a escapovaná hlavička má jednoduchou logiku, ale pořád musíte u každého znaku zjišťovat, zda to není jeden ze tří důležitých. Lépe řešeným protokolem se dostanete třeba na setinu nutných operací.

Se zpětnou kompatibilitou se určitě počítá. Podle mne to bude jako dnes s SPDY – klient se serverem se dohodnou, zda to podporují, a pokud ano, použijí novější protokol. No a pokud si budou uživatelé Firefoxu a Internet Exploreru stěžovat, jak to že se Google v Chrome načítá rychleji, naimplementují to i autoři ostatních prohlížečů. Podstatné je, že je to vytvářeno jako otevřený standard, že to nebude proprietární protokol Googlu, který by ostatní museli hackovat.