WebSockety jsou přece pořád postavené nad HTTP, ne?
Nová verze WebSocket ve vývojovém Google Chrome
I když se může zdát, že se kolem Chrome OS nic neděje, opak je pravdou. Základem Chrome OS bude webový prohlížeč Chrome a ten jde dopředu mílovými kroky.Vývojáři postupně pracují na vlastnostech, které teď možná nevypadají nějak použitelně, ale Google s nimi má rozhodně velké plány. Krom jiného se nyní do nočních buildů dostala nová verze WebSocket protokolu, který umožňuje prohlížeči komunikovat se serverem mnohem efektivněji než přes HTTP. WebSocket je stále pod silným vývojem a pokud něco s podporou tohoto protokolu vyvíjíte, tak mějte na paměti, že stará verze protokolu na serveru nebude s tou novou v prohlížeči fungovat.
Dále čtěte…
- Google: milion dolarů za úspěšný útok na Chrome 29. 2. 2012 10:33
- Zabezpečení uživatelských účtů na webových službách podle Googlu 20. 2. 2012 9:18
- Chrome Web Store změnil kategorie 16. 2. 2012 8:03
- Chrome 17 přináší přednačítání webů a lepší bezpečnost 9. 2. 2012 8:18
- Chrome pro Android má první betaverzi 8. 2. 2012 10:38
Re: HTTP
celé vláknoWebSockets se blíží spíše obecnému TCP spojení. Po navázání spojení, kdy se vymění hlavičky podobné těm v HTTP, je ve WebSockets k dispozici duplexní trvalé spojení, po kterém lze posílat libovolná data. Zaslání dat serverem vyvolá událost, kterou lze obsloužit v JS. Je to ideální pro AJAX/AJAJ aplikace – nemusí se pořád navazovat nová spojení a přenášet HTTP hlavičky.
Re: HTTP
celé vláknosouhlas, ale asi by ve zprávičce mělo být „mnohem efektivněji než přes prosté HTTP“, protože takhle to vypadá, jako by WS na HTTP nestavěly.
BTW: koncept je to zajímavý, možná by to šlo použít i mimo web – už kdysi jsem uvažoval o tom, že by byla fajn nějaká vrstva pro abstrakci nad TCP – spojení by se mohlo obnovit (např. po probuzení počítače ze spánku nebo po přechodu do jiné sítě) a aplikace by nic nepoznala, jen by do té doby byl pozastavený přenos dat.
Re: HTTP
celé vláknoNeviem ci by to slo az tak jednoducho pretoze to vyzaduje aplikacnu podporu. Neviem si predstavit ze server bude cakat 2–3 hodinky az sa pripojim a budem pokracovat. Specificke protokoly ako napr. ftp to maju ale vstavane priamo do protokolu mimo transparentnej vrstvy.
Re: HTTP
celé vláknono, ta abstrakce a podpora by musela být na obou stranách a prostě by to zablokovalo čtení/zápis – na krátké výpadky třeba wifi by to bylo ideální, na ty delší (třeba přes noc) je otázka, jestli je to žádoucí (např. IM klienta je asi lepší odpojit, než aby to tam viselo online).
Re: HTTP
celé vláknotakhle to vypadá, jako by WS na HTTP nestavěly
Také na něm nestaví, je to úplně jiný protokol, viz http://www.whatwg.org/specs/web-socket-protocol/
Re: HTTP
celé vláknono jo, zmátlo mne, že požadavek začíná:
GET /demo HTTP/1.1 Host: example.com
a odpověď:
HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket
ono se to tváří jako HTTP, ale není. :-) Docela chyták.
Ale už čtu specifikaci:
The WebSocket protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request.
BTW: nebylo by čistější kdyby tam místo HTTP/1.1 (což znamená protokol/verze) bylo něco jako WS/1.0, když je to jiný protokol?
Re: HTTP
celé vláknoTo by bylo v rozporu s HTTP specifikací http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42
WebSockets jsou záměrně navrženy tak, aby je šlo iniciovat přes HTTP Upgrade, a šlo je tak snadno používat přes stávající infrastrukturu HTTP – webové servery, proxy servery, firewally, …
Jen UTF-8?
celé vláknoNaposledy o vánocích jsem četl komplet specifikaci a zjistil jsem, že je možné posílat pouze validní UTF-8 data. Teď jsem to proletěl jen zběžně, ale nenašel jsem žádnou zmínku, že by se v tohle něco změnilo. To mi příjde jako úplná debilita. Proč tam proboha někdo zabudovává takováto omezení. Když jsou rámce v protokolu definovány délkou, tak není žádný důvod, aby byla payload cokokliv, teda klidně i to UTF-8. Tkhle, aby člověk vymýšlel nějakou formu kódování, když chce skutečně poslat cokoli. Co třeba obrázek? Pakárna na n-tou.
Re: Jen UTF-8?
celé vláknoProtokol má do budoucna možnost přenášet binární data, ale to dnes prohlížeče neumí. Takže skutečně dnes lze přenášet pouze UTF-8 řetězce, které však nejsou definovány délky, ale ukončeny pomocí OxFF. Rámce určené délkou jsou určeny právě pro budoucí použití a pro možné přenášení binárních dat.
Nicméně přenášet třeba obrázky jako binární data nemá moc smysl – co s tím budete v Javascriptu dělat? Implementovat dekompresní algoritmy pro JPEG/GIF/PNG a pomocí canvasu vykreslovat bod po bodu. Můžete je jedině tak pomocí DOM zobrazit, což lze udělat pomocí URL schématu data: a tam musí být binární data stejně zakódovaná pomocí base64.
Nicméně k WebSockets existuje mnoho výhrad. Kromě některých principiálnách věcí je protokol popsán hixionštinou, takže je 3× delší než by misel být. Pro zajímavé čtení o nedostatcích WebSockets doporučuji např. http://blogs.webtide.com/gregw/entry/how_to_improve_websocket
Re: Jen UTF-8?
celé vláknoSorry za překlepy, neměl bych dělat tolik věcí najednou. Přidám alespoň ještě jedno zajímavé čtení: http://blogs.webtide.com/gregw/entry/websockets_ietf_v_whatwg
Re: Jen UTF-8?
celé vláknoNo, způsob jak je ten protokol popsán to je kapitola sama o sobě. Vlastně nechápu jak se pod něco takového firma jako Google může vůbec podepsat. To tam rovnou mohli napsat referenční implementaci v assembleru. No nic.

