Vlákno názorů k článku Jak funguje nový protokol HTTP/2 od Oxymoron - Jediné, co mě v článku zaráží, že přestože...
-
Filip JirsákStříbrný podporovatelCelé ty binární hlavičky znamená pouze to, že se pošle typ hlavičky (odkaz na název a hodnotu z tabulky, odkaz na název z tabulky a nová hodnota, nový název i hodnota), a podle typu pak buď index do tabulky hlaviček, nebo délka textového řetězce a za ní samotný textový řetězec. A ty číselné údaje se neposílají jako dekadické číslo zapsané v ASCII (jako to bylo v HTTP/1.1), ale zakódují se binárně. Obecně třeba když víte, že potřebujete poslat jedno číslo v rozsahu 0–3 a druhé číslo v rozsahu 0–63, nadefinuje se v protokolu, že se pošle jeden oktet (bajt, osm bitů), kde první dva bity budou představovat první číslo a zbývajících 6 bitů bude reprezentovat to druhé číslo. V HTTP/2 je to trošku složitější, protože tam není předem omezená velikost čísla, ale i takovýhle způsob kódování se běžně používá – asi nemá smysl tady opisovat specifikaci. Texty v hlavičkách pak ještě mohou být komprimovány Huffmanovo kódováním.
-
Filip JirsákStříbrný podporovatel
Tady máte příklad ze specifikace. Hlavička
Hexadecimální výpis::paths hodnotou/sample/path040c 2f73 616d 706c 652f 7061 7468Když se na to podíváte jako na ASCII text s výpisem kontrolních znaků pomocí stříšky, bude to: ^D^L/sample/pathTexty jsou tam jednak kvůli hodnotám hlaviček (host name, datum a čas, mime-typy, cookie…), jednak proto, že si každý může vytvořit svůj vlastní název hlavičky (nestandardní hlavičky se uvozují „X-“).
-
Filip JirsákStříbrný podporovatel
Třeba to, že ty dodatečné parametry posílá i server klientovi, takže nemá žádné URL za GETem, kam by ty parametry přidal.
Mimochodem, jednou z hlaviček, která původně nebyla ve standardu (HTTP/1.0) a nejprve ji svévolně začali používat klienti i servery, a až po té byla doplněna do standardu HTTP/1.1, je hlavička
Host. Protože na začátku nikoho nenapadlo, že se poruší oddělení jednotlivých vrstev síťových protokolů, doménové jméno přestane označovat jen počítač a bud označovat i "website", takže na jedné IP adrese bude hostováno mnoho různých "website" s různými doménovými jmény, a tudíž bude nutné zavléct doménové jméno i do aplikačního protokolu. Myslíte si, že to byla chyba v návrhu protokolu HTTP/1.0? -
Filip JirsákStříbrný podporovatel
Ne, nebylo. Lepší je ho navrhnout tak, aby se dal snadno rozšiřovat. Každý rozumně navržený protokol je rozšiřitelný, protože i kdyby ten protokol byl dokonalý teď, nikdo neví, jaké potřeby se objeví v budoucnosti.
-
Oxymoron (neregistrovaný)
host name - při šifrované komunikaci stejně bude muset probíhat jakási předkomunikace, během ní by šel pro hostname domluvit číselný identifikátor, takže hostname v textové podobě být nemusí,
datum a čas - jsou čísla, tedy nemusí být přenášeny v textové podobě, v binární podobě se navíc zjednoduší interpretace, neboť nebude nutné převádět čas z textu na číslo,
mime-typy - proč pro ně také neexistuje tabulka, jako pro hlavičky?
cookie - mohou být číselná, nas hodnoty mohou být převáděny pomocí tabulky,k čemu tedy texty v binárních hlavičkách?
-
JSH (neregistrovaný)
k host name : Tohle tam překvapivě je. Přečti si znova kapitolu "komprese hlaviček" a zjistíš, že je to vlastně to, co navrhuješ. Akorát je to jednodušší a není to omezené na host name.
k datum a čas : Takže místo ISO standardu mají použít nějaký vlastní nový způsob reprezentace data? Fakt?
k mime : Opět. Mime je standard, který se používá všude možně. Vymýšlet nějaký vlastní formát za ušetření pár B v hlavičce fakt nestojí.
-
Oxymoron (neregistrovaný)
hostname: no, akorát se na to nějak nedá moc spoléhat při prvním dotazu na tento server, protože nikdo neví, co v té tabulce je.
datum a čas: z hlediska zpracování by bylo mnohem jednodušší zpracovávat binární vyjádření času, kdybych věděl, třeba že první bajt jsou sekundy, druhý bajt jsou minuty, třetí bajt jsou hodiny, čtvrtý bajt je den, pátý bajt je měsíc a šestý a sedmý bajt je rok a třeba osmý bajt je den v týdnu.
V čem je komplikovanější získávat přímo hodnoty, než přechroustávat nějaký textový řetězec a převádět ho na tyto požadované hodnoty?
mime: Proč vlastní formát? stačila by tabulka a čtyřbajtové vyjádření by postačovalo pro pokrytí všech existujících mime typů. V jedné hlavičce je to sice jenom pár bajtů, ale při tom, kolik hlaviček denně proletí sítí, by to pár Tera uspořených bajtů udělat mohlo.
A navíc, tu tabulku by ani klient ani server nepotřebovali, těm by stačilo jenom to číslo, převod na mime potřebuje akorát tak uživatel. Takže programy by si ušetřili další parsování toho, co že jim to vlastně server posílá.
-
JSH (neregistrovaný)
Na začátku je prázdná. Cílem http/2 není ušetřit pár přenesených bytů, ale pár dotazů a odpovědí. Nezdržuje to přenášení dat, ale latence dotazů a odpovědí.
To už teda raději unix timestamp, nebo ntp datestamp. To co navrhuješ ty má nevýhody z obou stran. Je to zvytečně velké, nedá se to přímo použít a navrch je to ještě nečitelné.
S tím mime je to vtip? Kolik bytů si myslíš, že bys ušetřil? Jen hlavičky TCP/IP mají minimálně 40B. Data, kterých se to mime týká mají obvykle sakra víc. Nesnažíš se šetřit na dost blbém místě?
-
Pavel Satrapa (neregistrovaný)
Jen drobná korekce: Na začátku není prázdná - obsahuje pevně definovanou statickou část, ve které jsou nejběžněji používané hlavičky a jejíž obsah je definován specifikací - viz https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12#appendix-A
Na ni navazuje dynamická část, která je na začátku prázdná a plní se podle potřeb konkrétního spojení. Nechtěl jsem v textu rozpitvávat úplně všechny detaily, ale asi jsem měl ;-)
-
Oxymoron (neregistrovaný)
Pokud není cílem ušetřit pár bytů, tak binární hlavička nedává smysl. Zvlášť když mají být komprimované. U textu, zvlášť ASCII je komprese obvykle větší, než u binárních dat. Takže po komprimaci bych výsledky čekal více méně stejné.
Záleží, na co to použiješ. UNIX stamp má totiž jednu mouchu - vzhledem k různým počtům dnů v měsíci, přestupným dnům, přestupným sekundám, je získání třeba pořadového čísla dne v měsíci ne úplně triviální záležitostí - resp. je jednodušší ze data, kde jsou jednotlivé jeho části dány svojí hodnotou vypočítat unix stamp než naopak.
Třeba v hlavičce jaký typ souboru klient očekává by se tím takových 20 B a víc klidně ušetřit mohlo. Takhle těch 20 B zní bezzubě, ale když si vezmeš kolik hlaviček sítí projde denně, pár Tera to dá. Proč myslíš, že se u šroubů místo hlav velikosti 16 začali u některých výrobců dělat hlavy velikosti 15? Aby ušetřili materiál. Na jednom šroubu je to sice nic, ale v těch milionových sériích je to znát hodně.
-
JSH (neregistrovaný)
Dává to smysl. Jednotlivé řetězce v HTTP hlavičce jsou jednoznačné ale díky tomu, že je to text, tak se kolem nich vyskytují různé počty mezer, tabulátory a různé druhy konců řádků.
Tenhle binec pochází právě z toho, že je to text a použití binárního protokolu dost efektivně omezuje tuhle kreativitu. -
Filip JirsákStříbrný podporovatel
Mime typů je neomezené množství, takže konečná tabulka do standardu by se pro ně dělala těžko. Cookie nemohou být číselná, prohlížeč si do cookie může uložit libovolný text. Třeba si může do cookie uložit jméno, které uvádíte u svých komentářů na Rootu, abyste ho nemusel pokaždé znovu vyplňovat. To byste chtěl, aby jste si musel jméno "Oxymoron" zaregistrovat do HTTP standardu, aby jeho hodnota mohla být součástí cookie?
Další textové hlavičky jsou třeba hlavička Location pro přesměrování. Opět, to se má podle vás do standardu zařadit seznam všech adres, na které je možné přesměrovat, a když budete chtít přesměrovávat na novou adresu, budete si muset podat žádost a za 16 let se to dostane do příští verze standardu?
ČLÁNKY DO MAILU