Vlákno názorů k článku
HTTP 2.0 bude binární protokol
od belzebub - Imbecilita takoveho rozhodnuti je nebetycna.
99% vsech dat prenasenych...
-
belzebub (neregistrovaný)
Imbecilita takoveho rozhodnuti je nebetycna.
99% vsech dat prenasenych (pri normalnim prohlizeni internetu) tvori video, obrazky, flash, javascript.. pak dlouho nic, pak vlastni HTML, CSS, nejake ajax requesty, a to je asi tak vse, ne? NE! Zapomel jsem tam okurku.. ehm.. tedy myslel jsem rezii HTTP protokolu, ktera tvori z celkovych radove stovek kB na jednu stranku asi 0.00nic. Coz je jediny kus dat, ktery je mozne "binarizovat".
Co tedy binarni HTTP prinese?
* bude znemozneno snadne debugovani aplikaci (!!!) coz ja osobne povazuji za zlo
* snizi se pocet prenesenych dat o 0.000nic procent - obrazky, video ani flash objem nezmeni, javascript, html, json, css je mozne komprimovane prenaset uz v ramci HTTP 1.1
* nutnost resit endianess v kazdem HTTP serveru, coz pravdepodobne eliminuje zisk nekolika nanosekund usetrenych binarizaci tech par slovicek co HTTP protokol znaBinarni protokoly jsou v ojedinelych (!) pripadech opravnene, ale celym svym telem verim, ze pro binarizaci HTTP neexisuje jediny duvod.
Obrovsky uspech HTTP protokolu je zapricinen mimo jine tim, ze se jedna o textovy protokol - jeho portovani na libovolnou platformu bylo snadne a debugovani jeste snadnejsi. Kdyz se nad tim zamyslite, tak vsechny protokoly ("aplikacni" vrstva), ktere se masove pouzivaji jsou textove (XML-RPC, JSON-RPC/AJAX, HTTP, POP3, IMAP, SMTP, a dalsi a dalsi).
-
Santiago (neregistrovaný)
* Debugovani implementaci binarnich protokolu neni o moc tezsi nez u textovych - bud ma clovek dumpy primo v kodu, nebo stejne ty protokoly bude znat tcpdump a prelozi je do textove podoby.
* Binarni protokoly jsou casto podstatne jednodussi na specifikaci a implementaci (odpadaji formalni gramatiky, slozitejsi parsery ci problemy s escapovanim ridicich znaku).
* Preklad endianity je banalita, na to staci jedna instrukce. Oproti tomu nacteni cisla v textove podobe bude radove pomalejsi.
* I kdyz odmyslim low-level protokoly jako OSPF a IS-IS, tak je spousta binarnich bezne pouzivanych protokolu: DNS, BGP, SSH, SFTP, NTP, RTP a dalsi.
-
Filip JirsákStříbrný podporovatelK těm protokolům bych doplnil ještě IP, TCP/IP, SSL/TLS/HTTPS. Takže z protokolů, které používá dnešní webový prohlížeč, je HTTP jediná textová výjimka.
-
belzebub (neregistrovaný)
1) debugovani binarnich protokolu tezsi je, protoze potrebujete nastroj navic, navic nastroj, ktery zna i posledni verzi protokolu. U textoveho ne. Libovolny dobre navrzeny textovy protokol _APLIKACNI__VRSTVY_ muzu debugovat tim samym nastrojem - at uz se jedna o telnet, ncat apod. I s wiresharkem/tcpdump uspeji pouze tehdy, pokud je v nem jiz binarni protokol implementovan. U textoveho protokolu o nem nemusi wireshark/tcpdump nic vedet.
Pro debugovani binarniho protokolu potrebuji vzdy neco navic. Tedy debugovani textovych protokolu JE snazsi nez binarnich.2) Ze jsou binarni protokoly jednodussi na specifikaci a implementaci? To je silne diskutabilni. Ja jsem napr. presvedcen o opaku (a to jsem nekolik jak textovych, tak binarnich, protokolu implementoval). Zvlast kdyz se dostaneme k vecem jako 16b cislo rozdelene na 8 bitovych poli ruzne delky apod.
Navic textovy protokol je casto srozumitelny "od pohledu". To se o binarnim neda rict.3) endianita neni banalita - prestoze na nekterych architekturach pro to muze byt podpora v CPU, neni to v zadnem pripade pravidlo. Navic vubec nejde o podporu v CPU, jde o to, ze je to dalsi vec, kde muze implementator udelat chybu (kdybych mel korunu pokazde, kdyz vidim nekde spatne osetrenou endiannes v otvirani TCP/IP socketu, mel bych na par piv).
4) prectete si prosim presne co jsem psal - mluvil jsem o protokolu v APLIKACNI VRSTVE, tedy vesmes nad TCP/IP.
-
Filip JirsákStříbrný podporovatel
HTTP se často používá jako HTTPS, často se přes něj také přenáší zagzipovaný obsah. Máme obojí přestat používat, protože otevřený a nezkomprimovaný obsah se lépe debuguje pomocí telnetu a netcatu? Podobně pokud HTTP požadavek obsahuje tělo, musí být přítomna hlavička Content-Length, kterou si v případě telnetu musíte předem spočítat. To je taky nepohodlné – ale je to vada HTTP protokolu? Chunked kódování je další příklad – mám pokračovat?
Není v dnešní době „snadnost debugování“ (v tom smyslu, jak to vy používáte) tak okrajová věc, že nemá smysl se jí zabývat? Navíc když chci nějaký protokol debugovat, asi nástroje na jeho parsování mám… Za těch asi dvacet let působení v IT jsem dvakrát řešil s HTTP problém, který souvisel s tím, jak byl proud dat rozdělen do paketů. Ve všech ostatních případech stačil výstup z parseru HTTP, ať už v prohlížeči, v aplikaci a nebo z Wiresharku/tcpdumpu.
-
Lael Ophir (neregistrovaný)
Nechápu tu dnešní obsesi textovými protokoly. Binární protokoly jsou úspornější, v případě HTTP to navíc výrazně usnadňuje paralelní přenosy (o lahůdkách typu JS dekomprese běžte vyprávět o diskusi vedle, kde půlka diskutérů tvrdí, že JS je hnus a nemá na webu vůbec co dělat). A že nemůžete HTTP debuggovat bez nástroje? To nevidím jako problém.
Dalším příkladem je XML. Teoreticky je čitelné pro člověka, ale v praxi ho většinou potřebujete komprimovat, parsování je na dlouhé lokte, a čitelnost nic moc (otevřete si někdy dekomprimovaný soubor ODF nebo DOCX). Výsledkem je ve srovnání s binárními formáty výrazně vyšší náročnost na paměť i CPU, plus nutnost komprese, která vylučuje změny v části souboru.
Dobře navržený a dokumentovaný binární protokol je naprosto v pohodě, nevím co proti tomu máte.
-
Santiago (neregistrovaný)
1) Takze ten nastroj navic potrebuju i pro debugovani textovych protokolu, akorat nemusi dany protokol umet. Kazdopadne to je vcelku detail.
2) To ja jsem jich taky uz par implementoval. Ze muze byt pitome definovany binarni protokol je pravda, ale vetsinou je to dost primocare. Podstatne jednodussi nez detaily gramatik textovych protokolu.
> Navic textovy protokol je casto srozumitelny "od pohledu".
Tak maximalne syntax, ktera je vetsinou bez semantiky na houby. A kdyz uz mam specifikaci semantiky, tak u ni rovnou bude specifikace syntaxe.
Nehlede na to, ze 'od pohledu' je to dost problematicke - v textovych protokolech jsou casto speky typu ruzna pravidla pro whitespace znaky, ci nutnost escapovani ruznych znaku.
3) I kdyz ji nemas jako instrukci, tak je to porad radove rychlejsi nez nacteni cisla v ASCII podobe. Implementacni chyby se povetsinou eliminuji tim, ze standard je big-endian, takze pokud to nekdo neosetri-tak mu to na beznych litte-endian nepojede proti referencni implementaci.
V podstate ale bitova delka, endianita a signedness jsou jedine parametry, ktere u cisel u binarnich protokolu hraji roli. U textovych protokolu je mnohem vetsi volnost (a tim mnohem vetsi prostor neco pokazit) - napr. delka muze byt specifikovana jak max. hodnotou, tak max poctem dekadickych cislic, muze byt zakazan, povolen ci nakazan minimalni padding nulama, muze byt zakazano, povoleno ci nakazano znamenko (a to zvlast pro zaporne a kladne), je treba vzdy osetrit neplatny vstup (zatimco u takoveho u16 ci u32 muze byt kazda bitova kombinace platny vstup) ...
4) Vsechny z mnou uvadenych protokolu (s vyjimkou prvnich dvou, ale ty jsem zamerne uvedl zvlast a vyloucil) jsou protokoly v aplikacni vrstve, pulka z nich nad TCP, druha nad UDP.
-
Filip JirsákStříbrný podporovatel
K těm velkým a malým indiánům -- to je aspoň napsané ve specifikaci. U textových protokolů se bralo za samozřejmé, že je to ASCII. S nástupem UTF-8 se to někde začalo iterpretovat, že by to mohlo být i UTF-8, a sem tam se to explicitně objeví i v novější specifikaci. Takže se to implementuje, jak je zrovna v daný čas pro daný typ aplikace obvyklé.
