Websocket

Kifejlesztésének fő motivációja volt, hogy a webböngészőben futó alkalmazás képes legyen a szerverrel való kétirányú kommunikációra a Comet barkácsmegoldásai (több HTTP-kapcsolat nyitva tartása; XMLHttpRequest vagy <iframe> és long polling) nélkül, bizonyos esetekben a szükségtelen fejlécforgalom akár 500:1-1000:1 arányú, a késleltetés 3:1 arányú csökkentésével. Korlátozó tényező volt a HTTP 1.1 specifikációja, mely kimondja, hogy a böngészőnek legfeljebb két kapcsolatot szabad egyidejűleg nyitva tartani a webszerver felé. A WebSocketet megelőzően nem volt lehetséges komplexebb, a szerverrel valós idejű kommunikációt igénylő webes alkalmazást, pl. csevegő alkalmazások, árfolyamkijelzők, játékok, levelezőkliensek a HTTP-kapcsolat nem rendeltetésszerű használata nélkül megvalósítani.

Bár a fő cél a webböngészőkben és webszervereken való implementáció, más kliens-szerver megoldásokban is használható. A WebSocket API-t a W3C szabványosítja, míg a WebSocket protokollt az IETF az RFC 6455-ben írja le. Mivel nem otthoni környezetben a nem a 80-as TCP portra irányuló kapcsolatokat a rendszergazdák sok esetben blokkolják, a WebSocket arra is használható, hogy a korlátozások ellenére – és a protokollból eredő némi vízfej mellett – az egyetlen hozzáférhető TCP porton több WebSocket-szolgáltatást multiplexáljanak.

A kliensoldalon a WebSocketet eddig a Firefox 4, a Google Chrome 4, az Opera 11 és a Safari 5 böngészőkben valósították meg, továbbá része a Safari mobil verziójának az iOS 4.2-ben. Az OS7-ben lévő BlackBerry Browser is támogatja. A protokoll korai verziójának sebezhetősége miatt a Firefox 4, Firefox 5 és Opera 11 böngészőkben alapértelmezetten kikapcsolták. A WebSocket protokoll hibáját a -07 verzióban orvosolták, amit a Firefox 6-ban, illetve a -10 verziót a Chrome 14-ben implementáltak és alapértelmezetten be is kapcsoltak.

Létezik továbbá a Google Chrome-nak egy parancssori kapcsolója (--enable-websocket-over-spdy), ami lehetővé teszi a WebSocket SPDY protokoll fölötti korai, kísérleti implementációjának használatát.

A WebSocket kapcsolat kiépítéséhez a kliens egy kézfogási kérelmet küld (handshake request), amire a szerver kézfogási válasszal (handshake response) felel, ahogy az alábbi példák mutatják:

draft-ietf-hybi-thewebsocketprotocol-00

Ez a korábbi kézfogási mechanizmus; lejjebb olvashatók az újabb verziók.

A kliens kérelme a szervernek:

GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: example.com Origin: http://example.com Sec-WebSocket-Key1: 4 @1  46546xW%0l 1 5 Sec-WebSocket-Key2: 12998 5 Y3 1  .P00  ^n:ds[4U 

A szerver válasza:

HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Location: ws://example.com/demo Sec-WebSocket-Protocol: sample  8jKS'y:G*Co,Wxa- 

A Sec-WebSocket-Key1, a Sec-WebSocket-Key2 mezők, és az utánuk következő 8 bájt egy-egy véletlenszerű token, amiből a szerver a kézfogás befejezésekor 16 bájtos tokent állít össze, amivel igazolja, hogy elolvasta a kliens kézfogását.

A 16 bájtos token a következőképp áll össze: a szerver az első kulcs számjegyeit összeolvassa, majd elosztja a szóközök számával. Ezt megismétli a második kulccsal is. Az eredményül kapott két számot (mindkettő big-endian előjel nélküli 32 bites egész) összeolvassa, és hozzáírja a kliens kérésének utolsó nyolc bájtját. Végül az így kapott string MD5 ellenőrzőösszegét képezik.

A kézfogás a HTTP-re hasonlít, de valójában nem az. Lehetővé teszi azonban, hogy a szerver a kézfogási kérelmet a HTTP protokoll szerint értelmezze, majd átválthasson a WebSocket használatára.

Ha kiépült a kapcsolat a WebSocket adatkereteket full duplex módon lehet a kliens és a szerver között továbbítani. A full duplex szöveges keretek minimálisan két bájtnyi keretinformációt tartalmaznak: minden keret 0x00 bájttal kezdődik és 0xFF bájttal ér véget, a kettő között pedig UTF-8 kódolású szöveges adatot tartalmaz. A bináris keretek JavaScript alapú klienssel nem támogatottak. A WebSocket szöveges keretei lezáró bájtot (terminator) használnak, míg a bináris keretek a fejlécben meghatározott fix hosszúságúak.

draft-ietf-hybi-thewebsocketprotocol-06

A WebSocket 06-os draftjában némileg megváltozott a kliens és szerver közötti handshake pontos menete:

GET /ws HTTP/1.1 Host: pmx Upgrade: websocket Connection: Upgrade Sec-WebSocket-Version: 6 Sec-WebSocket-Origin: http://pmx Sec-WebSocket-Extensions: deflate-stream Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== 

A szerver válasza:

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= 

A kliens egyetlen, base64-kódolású Sec-WebSocket-Key kulcsot küld el. A szerver ehhez a következő mágikus stringet fűzi hozzá: "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", ezt SHA1-gyel hasheli és újra base64-gyel kódolja. Lényeges, hogy a kliens által base64-gyel kódolt Sec-WebSocket-Key kulcsot nem dekódolja a szerver. Az eredmény a szerver a fejléc "Sec-WebSocket-Accept" mezőjében küldi vissza.

Példa a Sec-WebSocket-Key → Sec-WebSocket-Accept átalakításra:

• Az "x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11" kiindulási string SHA1-gyel kódolva a "1d29ab734b0c9585240069a6e4e3e91b61da1969" hexadecimális értéket adja.
• Ez base64-gyel kódolva, például a következő Unix paranccsal: `printf "\x1d\x29\xab\x73\x4b\x0c\x95\x85\x24\x00\x69\xa6\xe4\xe3\xe9\x1b\x61\xda\x19\x69" | base64` megadja a válaszstringet: "HSmrc0sMlYUkAGmm5OPpG2HaGWk="

A WebSocket protokoll kliensoldali implementációi megpróbálják detektálni, hogy a user agent (tehát a kapcsolódást végző program) proxy használatával kapcsolódik-e; ha igen, a HTTP CONNECT metódusával próbálnak állandó csatornát létrehozni.

Bár a WebSocket protokoll nem foglalkozik a proxyszerverekkel és tűzfalakkal, a használt kézfogási mechanizmus a HTTP-vel kompatibilis, ezért a HTTP-szerverek megoszthatják alapértelmezett HTTP és HTTPS portjaikat (80 és 443) egy WebSocket átjáróval vagy szerverrel. A WebSocket protokoll definiál egy ws:// és wss:// URI-prefixumot a WebSocket, illetve WebSocket Secure kapcsolat jelzésére. Mindkét séma a HTTP 1.1 upgrade mechanizmusát használja a WebSocket protokollra való átváltáshoz. Ez egyes proxykkal problémamentesen működik, mások megakadályozzák a WebSocket kapcsolat kiépülését. Egyes esetekben a proxyszerver konfigurálására, vagy upgrade-jére lehet szükség.

Ha titkosítatlan WebSocket forgalom halad át akár egy explicit, akár egy transzparens proxyn, jelenleg a proxy megfelelő viselkedésétől függetlenül, a kapcsolat jó eséllyel nem tud kiépülni; a WebSocket elterjedésével valószínűleg egyre több proxy fogja felismerni és átengedni a WebSocketet. Ebből következik, hogy a titkosítatlan WebSocket kapcsolatokkal csak a legegyszerűbb hálózati topológiákban érdemes kísérletezni.

A titkosított WebSocket esetén a WebSocket Secure kapcsolatnál alkalmazott Transport Layer Security (TLS) biztosítja, hogy explicit proxy szervernél ki legyen adva a HTTP CONNECT parancs. Ez kiépít egy csatornát, ami a HTTP proxyn keresztülengedi az alacsony szintű, végponttól végpontig terjedő TCP-alapú kommunikációt a WebSocket Secure kliens és a WebSocket szerver között. Transzparens proxyk esetén a böngésző nincs tudatában a proxy jelenlétének, így HTTP CONNECT-et sem küld. Mivel azonban a forgalom titkosított, a köztes, transzparens proxy szerverek jó esetben egyszerűen keresztülengedik a titkosított forgalmat, így nagyobb az esély a sikeres WebSocket kapcsolat kiépülésére, mint a titkosítatlan esetben. A titkosítás némi erőforrást felemészt, de nagyobb esélyt kínál a sikerre.

Egy 2010 közepi draft verzió (version hixie-76) elrontotta a reverse proxykkal és átjárókkal való kompatibilitást, mivel a fejlécek után 8 bájtnyi kulcsadatot küldött anélkül, hogy ezt megjelölte volna egy Content-Length: 8 fejlécsorral. Ez az adat így eldobásra kerülhetett, ami meghiúsítja a kapcsolódást. Az újabb draft verziók (pl. a hybi-09) a kulcsadatot a Sec-WebSocket-Key fejlécben helyezik el, ami hatásosan megoldja ezt a problémát.

A WebSocket protokoll specifikációja két új URI sémát határoz meg: ws: és wss:, a nyílt, illetve a titkosított kommunikációhoz. A séma nevén túl a használt URI komponensek az URI általános szintaxisának (RFC 3986) megfelelnek.

Jelenleg kliensoldalon csak a Firefox 11, a Chrome 16 és az Internet Explorer 10 böngészők támogatják a WebSocket protokoll legutolsó verzióját (RFC 6455). Egy részletes tesztjegyzőkönyvben olvashatók a böngészők konkrét megfelelőségi adatai.

A Microsoft a draft-ietf-hybi-thewebsocketprotocol-04-et az Internet Explorerben a HTML5 Labs-ában található böngésző-prototípusaiban támogatja csak.

• Ez a szócikk részben vagy egészben a WebSocket című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

• IETF Hypertext-Bidirectional (HyBi) working group
  • The WebSocket protocol - Internet-Draft at IETF
  • The WebSocket protocol (Network Working Group) - Old protocol
• The WebSocket API Archiválva 2015. június 7-i dátummal a Wayback Machine-ben - W3C draft specification of the API
• WebSocket.org - a web-site dedicated to WebSocket
• WebSocketsTest.com - a web-site to test WebSocket support and operation in your browser.
• HTML5 Server-Push Technologies, Part 2 - explains WebSocket
• Websockets in HTML5 - Easy to understand read on WebSocket
• HTML5 WebSockets: An example with jetty and chrome - A complete example on WebSocket with jetty.
• Web Socket API in BlackBerry Browser with OS7
• InfoQ: HTML 5 Web Sockets vs. Comet and Ajax
• WebSocket.org: HTML5 Web Sockets: A Quantum Leap in Scalability for the Web Archiválva 2011. szeptember 23-i dátummal a Wayback Machine-ben