Názory k článku
HTTP 2.0 bude binární protokol
-
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é.
-
Filip JirsákStříbrný podporovatel
Podle mne vůbec nejde o rychlost při síťovém přenosu, ale o rychlost při zpracování na straně serveru. Představte si nějaký loadbalancer, webhosting se spoustou webů, CDN. Generování nějaké stránky z DB, to prostě nějakou dobu bude trvat a přenosový protokol na tom nic nezmění. Ale kolem té stránky je spousta bižuterie, obrázky, styly, skripty – na jednu stránku jsou jich desítky. A tam se server potřebuje rychle rozhodnout, kam požadavek předat dál, rychle poznat, že může odpovědět 304 atd.
Všimněte si, co se v naposledy na HTTP rozvíjelo – Connection keep-alive, chunked encoding, SPDY. První a třetí je optimalizace právě pro rychlejší získání bižuterie, chunked encoding umožňuje průběžné odesílání ze serveru, tedy opět snížení zátěže serveru. Binární protokol HTTP jenom v tomhle trendu pokračuje.
Taky mi vadí, že ladění už nebude tak pohodlné jako s textovým protokolem. Ale chápu, že je dnes požadováno co nejrychlejší odbavení na serveru, a textový protokol v tom má limity. Vždyť se kvůli zrychlení vymýšlejí i náhrady protokolu TCP/IP, aby se obešel úvodní handshake…
-
Jenže co mi binární protokol v tomto směru přinese navíc ? Nic...
Serializovat požadavky na bižuterii - OK, konec konců se to děje už dnes v podobě různých js a css kompresorů, nebo obrázkových map. Takže v konečný fázi můžu mít stránku o jednom středně velkém javascriptu, jednom podobně velkém stylu, obrázku a nakonec html. Díky kompresi i ten relativně velký textový soubor bude zmáčknutý do jednotek kb.
Mimochodem, generování stránek se řeší různými cache na všech frontách a to včetně bižu, a v konečném stádiu prostě nebude stíhat IO, pokud toho bude tak moc.
To co chápu jako přínos je nenavazování 150ti malých spojení, které ve skutečnosti stáhnou méně dat než nosný protokol. K tomu ale není potřeba binárního protokolu.
-
Filip JirsákStříbrný podporovatel
Binární protokol přinese to, že specializovaný server (loadbalancer, CDN) zpracuje požadavek mnohem rychleji. Nebude muset zpracovávat hlavičky znak po znaku, ale nezajímavé hlavičky přeskáče a vytáhne si těch pár, které ho zajímají – Host, E-tag, If-*, Accept-*.
Dál bude možné jedním TCP/IP spojením možné přenášet několik požadavků najednou (ne po sobě, jak je to dnes) – to samo o sobě by čitelnost pro člověka výrazně zhoršilo.
Nakešované soubory má server ideálně v RAM a ten kus paměti jednoduše zkopíruje do paketu – na tom už se toho moc zrychlit nedá. Naopak zpracování hlaviček, kdy dnes musíte je od začátku znak po znaku a čekat, zda se neobjeví zajímavá hlavička, se zrychlit dá.
-
d.c. (neregistrovaný)
No jasne. Proste jsou lidi (nebo spis firmy), kterym je decentralizovana a otevrena povaha internetu od zacatku nepochopitelna a/nebo trnem v oku. Uz aby se z toho konecne podarilo udelat centralni distribuci manipulace (chci rict obycejny prostredek masove komunikace). Zda se, ze po W3C (a lobby pro DRM) je i IETF ponekud "neverne" technologii a pod tlakem "zlobru".
-
Filip JirsákStříbrný podporovatel
Kdyby binární protokol měl nějakou aspoň vzdálenou souvislost s centralizací/decentralizací a s otevřeností/uzavřeností internetu, mohl váš komentář dávat nějaký smysl. Škoda, že tomu tak není.
-
Filip JirsákStříbrný podporovatel
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).
-
Filip JirsákStříbrný podporovatel
Ž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ě.
-
Problém ale je, že toto v reálu tak velký problém není. Ano je snazší skočit na konkrétní místo v datech, než iterovat znaky a hledat ty správné hlavičky které mě zajímají. Ale protože tu máme IPv6, které rychlost trochu komplikuje, protože síla strojů pořád celkem rychle roste, tak změna na binární protokol je ve stínu tisíce dalších aspektů naprostou výkonostní banalitou.
Nehledě na to že load-balancing na úrovni http proxy serverů je první krok k řešení zátěže, ale pak existují ještě minimálně 3 další řešení, o úroveň jinde, a tudíž je jim nějaké HTTP úplně volné.
Proto jestli binární protokol přinese nějaké zrychlení, tak jen na úrovní http proxyn, které zpracovávají http hlavičky. A to ještě zrychlení v konečném stavu krajně pochybné.
Serializace / paralelizace není na binární podobě protokolu nijak závislá.
Embeded zařízení, které tu někdo zmínil jsou úplně mimo, protože ty musí zvládat ipv6, variabilně dlouhé dns a hromadu jiných věcí. Takže parsovat jednoduché textové hlavičky, které jsou napsány tak, aby se snadno parsovali, je záležitost těch nejzákladnějších funkcí libovolného programovacího jazyka.
-
Filip JirsákStříbrný podporovatel
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ší.
-
Filip JirsákStříbrný podporovatel
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é.
-
Filip JirsákStříbrný podporovatel
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.
-
Ivan (neregistrovaný)
Na binarni protokoly je tu wireshark. Tak jako se prohlizec postupne meni v tenkeho aplikacniho klienta, tak se i HTTP protokol meni v aplikacni protokol.
HTTP je vlatne vyjimka. Vetsina IP protokolu je binarnich. Viz http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
-
Liška Eliška (neregistrovaný)
VoIP binární protokol H.323, který byl perfektně definován pomocí jazyka ASN.1, umřel na to, že byl binární a nikomu se nechtělo studovat ty datové struktury.
Zatímco konkurenčnímu SIP, který vychází z HTTP, pšenka těžce komerčně kvete, navzdory tomu, že právě v textových parserech implementací byly (jsou) bezpečnostně kritické chyby.
Tak se nechme překvapit, jestli se tím web stane bezpečnějším místem. A jestli budou ta binární data dostatečně jednoznačně a kvalitně popsána tak, aby je parsery dokázaly sanitizovat. A jestli to celé časem neumře na znechucení adminů či co...
-
Pavel Burgr (neregistrovaný)
Binární protokol určitě přinese zrychlení na "velkých" serverech a load balancerech, ale další oblastí kde binár pomůže jsou embeded zařízení. Pársování textového HTTP když nemáte k dispozici skoro ani libc není moc velká zábava... Dnes se to může zdát jako okrajová oblast, ale s nástupem Internet Of Things, M2M a pod. to znamená velké množství zařízení a aplikací.
-
Pokud se vas server neumi rychle rozhodnout, tak to rozhodne neni tim, ze hlavicky nemate binarni, ale tim co si pod pojmem server predstavujete. Pokud to delate v skriptovacim jazyce, nebo v jave, ktere bezi ve svem vm, a jeste to cele provozujete ve virtualu, tak se nedivte ze Vam to nestiha.
Kdyz si vezmu pomerne stare zelezo, 4 jadra po 3GHz, na 1G siti... to mame 100MB/s hlavicek a procesor zvladne zpracovat 4x 3G = 12GB/s. To mame 120 pohledu na kazde pismenko hlavicky. A nepocitam zde prinos 32/64b architektury, nebo berlicky skrze SSE.
Proste jste linej, nebo neumite programovat a hledate problem tam kde neni. Lidi by meli prestat pouzivat FB a jine nesmysly a premyslet zas vlastni hlavou, pak by mozna na neco i prisli. Pred 10-20-30 lety byl hardware vyuzit na 100%, ale dnes? Dnes mame prevazne neschopne lidi kteri si rikaji vyvojari.
-
Filip JirsákStříbrný podporovatel
Loadbalancery nejsou dělané ve skriptovacím jazyce a spuštěné ve virtuálním počítači. Je to specializovaný hardware, který má v sobě protokoly více či méně zadrátované.
Váš pohled je sice hezký, ale řešíte web na úrovni nějakého bložínku z dovolené. Já jsem psal o nasazení na trochu jiné úrovni, kdy se řeší, aby se obsah paketu v paměti zbytečně nekopíroval, aby se minimalizovalo přepínání mezi uživatelským prostorem a jádrem, aby se zpracování drželo na jednom jádru a využila se tak data načtená v cache nebo aby byla data v paměti uspořádaná tak, aby v cache bylo maximum užitečných dat. Mimochodem, takovéhle věci jsou napsané i v Javě a mohou běžet ve virtuálu, protože se tím žádný výkon neztratí. On je to totiž nakonec stejně optimalizovaný nativní kód běžící na procesoru, a je jedno, že ten kód vytvořila JVM a že někde okolo se vedle jádra plácá také hypervizor. Ono taky to, čemu dnes říkáme procesor, by před pár lety bylo nazýváno virtuální počítač nebo emulátor -- dnešní procesory už nevykonávají jednu instrukci za druhou tak, jak přicházejí, ale převádějí instrukce třeba x86 nebo amd64 do interní instrukční sady procesoru, optimalizují kód, odhadují větvení a spekulativně provádějí instrukce napřed... Tenhle hardwarový "virtuální stroj" (moderní procesor) opravdu neslouží ke zpomalení programů, právě naopak.
-
Mozog (neregistrovaný)
>Proste jste linej, nebo neumite programovat a hledate problem tam kde neni. Lidi by meli prestat pouzivat FB a jine nesmysly a premyslet zas vlastni hlavou, pak by mozna na neco i prisli. Pred 10-20-30 lety byl hardware vyuzit na 100%, ale dnes? Dnes mame prevazne neschopne lidi kteri si rikaji vyvojari.
Bohuzel Vam musim dat za pravdu. Je to des velebnosti.
-
muf (neregistrovaný)
Na tomto (a podobných případech) je dobře vidět postupná degenerace Internetu, který kdysi býval elegantní, otevřenou a svobodnou sítí.
Ve chvíli, kdy kolem jeho technologií začaly otravovat firmy jako jsou třeba Apple, Microsoft a další podobné, nastalo to, co je nedílnou součástí jejich působení - spousta uživatelů pochybné inteligence, zneužívání ke kšeftu, balast, zamlžování podstaty, podivně "vylepšované" protokoly..... :-( -
-
Filip JirsákStříbrný podporovatel
Já když napíšu chrome https://root.cz, tak si web taky klidně přečtu. Naopak když bych si chtěl root.cz přečíst opravdu „ručně“, budu se muset vypořádat s binárním IP, s binárním TCP a s binárním UDP, s binárním DNS. A teprve pak přijde na řadu textové HTTP, ovšem hned v těle odpovědi dostanu zagzipované HTML a následně zagzipované binární PNG a JPG.
Pochybuju, že textové HTTP to celé zachrání.
-
Degenerovaný nerudný závislák, 5 min před kolapsem (neregistrovaný)
On možná autor původního příspěvku chtěl vyjádřit něco jiného. Akorát to ještě neumí pořádně pojmenovat.
Dnes když se podívá do přenášených dat, dokáže si udělat jakous takous představu o tom co a kam se přenáší.
Proč ale příjmout nějaký nový formát přenosu dat, navíc vyvinutý velkou firmou/firmami jimž už dnes prostě nikdo nevěří (oni jsou prostě proti lidem a svobodě). I pokud by samotný protokol byl čistý jak víno a neobsahoval nic co nechceme, jak si budeme (podobně jako dnes - "na koleně") ověřovat co kdo k jakému přenosu připojil navíc, nebo data modifikoval.Prostě zatím necítíme potřebu cokoli měnit. Snad jen toužíme opustit ty nedůvěryhodné firmy zcela, ale zatím není pro vše alternativa.
-
Filip JirsákStříbrný podporovatel
Že si z HTTP dokážete udělat představu, co a kam se přenáší, je jen naivní představa někoho, kdo to nikdy nezkusil. Dnes ta komunikace s velkými firmami, které se vám nelíbí, je převážně HTTPS. Podívat se, co se uvnitř přenáší, je řádově složitější, než podívat se do binárního HTTP. Pokud to nebude HTTPS, bude obsah nejspíš aspoň zagzipovaný -- což je pořád méně čitelný formát, než binární HTTP. Navíc binární HTTP se týká hlaviček protokolu, nikoli obsahu. No a když by ty velké firmy chtěly něco tajného dávat do hlaviček (což by od nich byla hloupost), proč zrovna do hlaviček HTTP? Proč ne třeba IP nebo TCP? A to oba jsou binární protokoly odjakživa.
Ale s větou "necítíme potřebu cokoli měnit" souhlasím. To je myslím ten nejzávažnější (a možná jediný) důvod, který zdejší odpůrci HTTP 2.0 mají.
-
mc (neregistrovaný)
Když se řekne Internet a mám si představit nějaké protokoly v aplikační vrstvě, tak první co ne napadne je: HTTP a SMTP.
Jde o protokoly, které jsou s námi opravdu dlouho a jsou všeobecně uznávané. Nejde v jejich případě o nějaký současný hit, který pozítří zmizí v propadlišti dějin. Oba protokoly jsou čitelné člověkem. Na rychlo testy vystačíte s telnet či s něčím jako je netcat (pokud je užito SSL je to komplikovanější, ale vnitřní základ zůstává). Nejsem si jist klady binarizace HTTP. Snad rychlost odezvy při častých malých AJAX požadavcích.
Ano ještě k těm dvěma je vhodné přidat protokol DNS, abych měl sadu co dělá základ Internetu v aplikační vrstvě kompletní. Hmm...
