Nová verze WebSocket ve vývojovém Google Chrome

WebSockety jsou přece pořád postavené nad HTTP, ne?

WebSockets 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.

souhlas, 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.

no, 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).

takhle 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/

no 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?

Naposledy 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.

Protokol 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

Sorry 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

No, 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.