WebSocket is eennetwerkprotocol datfull-duplex communicatie biedt over een enkeleTCP-verbinding. Het WebSocketprotocol is gestandaardiseerd door deInternet Engineering Task Force in 2011 alsRFC 6455 en de WebSocketAPI gemaakt inWeb IDL is gestandaardiseerd door hetWorld Wide Web Consortium.
WebSocket is ontworpen om te worden toegepast inwebbrowsers enwebservers. Het WebSocketprotocol is een zelfstandig opTCP gebaseerd protocol. WebSocket vertoont enige gelijkenis metHTTP, omdat dehandshake van het WebSocketprotocol doorHTTP-servers wordt geïnterpreteerd als een Upgraderequest. Het WebSocketprotocol maakt bidirectioneel dataverkeer mogelijk tussen webbrowsers en webservers. Dit kan doordat het protocol zorgt voor een standaard manier van dataverkeer zonder de noodzaak van een request door de webbrowser om vanaf de server data te sturen naar de browser. Daarnaast staat het protocol toe berichten heen en weer te sturen en daarbij de connectie tussentijds open te houden. Op deze manier is er een voortdurende bidirectionele conversatie tussen webserver en webbrowser. De communicatie vindt plaats over TCP-poort 80 (of TCP-poort 443 als de communicatie over TLS-versleutelde connecties gaat), wat een voordeel is in netwerkomgevingen waar poorten die niet bedoeld zijn voor het web (andere TCP-poorten dan 80 en 443) worden geblokkeerd door eenfirewall. Soortgelijk bidirectioneel dataverkeer is op andere niet-gestandaardiseerde manieren tot stand gebracht met stopgaptechnologieën zoalsComet.
Het WebSocketprotocol wordt momenteel ondersteund in de meeste grote browsers, waaronder:Google Chrome,Microsoft Edge,Internet Explorer,Firefox,Safari enOpera. WebSocket heeft ookwebapplicaties op de server nodig om het te ondersteunen.
In tegenstelling tot HTTP biedt WebSocket full-duplex-communicatie. Verder zorgt WebSocket voor de mogelijkheid een stroom van berichten te sturen bovenop een TCP-verbinding. TCP zelf regelt alleen een stroom van bytes en kent geen berichtenconcept. Voor WebSocket was full-duplexcommunicatie over poort 80 mogelijk met Comet-channels. Echter, de Comet-implementatie was geen standaard. Ook was de Comet-implementatie zwaarder omdat het werkte bovenop HTTP en het was inefficiënt voor kleine berichten. Het WebSocketprotocol heeft tot doel deze problemen te overwinnen zonder de veiligheid van het web in het geding te laten komen.
De WebSocketspecificatie definieertws enwss als twee nieuweURI-schema's, welke gebruikt kunnen worden voor niet-versleutelde en versleutelde verbindingen respectievelijk. Buiten fragmenten en schemanaam wordt de rest van de URI-componenten gedefinieerd volgensURI generic syntax.
Met gebruik van de Development Tools van de browser kunnen ontwikkelaars WebSockethandshakes en WebSocketframes inspecteren.
WebSocket werd eerstTCPConnection genoemd in deHTML5-specificatie als vervanger voor een opTCP gebaseerde socket-API. In juni 2008 werden discussies geleid door Michael Carter, welke resulteerden in de eerste versie van het nu hetende WebSocket.
Na deze discussies is door samenwerking tussen Ian Hickson en Michael Carter in de #whatwgIRC-chatroom de naam WebSocket bedacht. Daarop volgde toevoeging aan deHTML5-specificatie door Ian Hickson en werd de toevoeging aangekondigd op decometdaily-blog van Michael Carter. In december 2009 wasGoogle Chrome 4 de eerste grote webbrowser die de volledige standaard met WebSocket standaard aangezet ondersteunde. De ontwikkeling van het WebSocketprotocol werd daarna van hetW3C en de whatwg-groep verplaatst naar hetIETF in februari 2010 met twee revisies onder controle van Ian Hickson.
Nadat het protocol werd ondersteund door meerdere browsers en standaard aangezet was, is deRFC afgemaakt onder Ian Fette in december 2011.
Om een WebSocketconnectie te starten, stuurt de browser een WebSockethandshakerequest naar de server. De server reageert hierop met antwoord, zoals weergegeven is in de onderstaande figuur.
WebSockethandshakerequest (net zoals bij HTTP, elke regel moet eindigen met\r\n en er moet een lege regel aan het einde overblijven)
GET/chatHTTP/1.1Host:server.example.comUpgrade:websocketConnection:UpgradeSec-WebSocket-Key:x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol:chat, superchatSec-WebSocket-Version:13Origin:http://example.com
Serverantwoord:
HTTP/1.1101Switching ProtocolsUpgrade:websocketConnection:UpgradeSec-WebSocket-Accept:HSmrc0sMlYUkAGmm5OPpG2HaGWk=Sec-WebSocket-Protocol:chat
De WebSockethandshake lijkt op eenHTTP-request, zodat webservers zowel HTTP-connecties als WebSocketconnecties kunnen verwerken op dezelfde poort. Zodra de connectie is gemaakt door middel van de WebSockethandshake, wisselt de communicatie naar eenbidirectioneelbinair protocol, die niet meer voldoet aan het HTTP-protocol.
Naast de upgrade-headers stuurt de webbrowser ook deSec-WebSocket-Key-header mee. Deze header bevatbase64-gecodeerde willekeurige bytes die fungeren als een sleutel, de server reageert hierop met eenhash van de sleutel in deSec-WebSocket-Accept-header. Dit wordt gedaan om te voorkomen dat eencacheproxy een eerder verzonden conversatie opnieuw verstuurt. Dit mechanisme zorgt niet voor enige vorm vanprivacy,authenticatie of integriteit. De functie die dehash maakt, voegt de volgende tekst toe:258EAFA5-E914-47DA-95CA-C5AB0DC85B11(deUniversally unique identifier van de webserver) aan de inhoud vanSec-WebSocket-Key-header (zonder deSec-WebSocket-Key-header te decoderen vanuit base64), voert hier dan deSHA-1-hashingfunctie op uit en het resultaat wordt gecodeerd metbase64.
Wanneer de connectie gemaakt is, kunnen de webbrowser en server data- of text-frames heen en weer sturen infull-duplex-modus. De data wordt voorafgegaan aan een kleine header, welke gevolgd wordt door de ladingdata. WebSocket-transmissies worden omschreven als "messages", waarbij elke message kan worden verdeeld over meerdere text-frames. Dit biedt de mogelijkheid messages te sturen waarbij de totale lengte onbekend is maar de eerste data al wel beschikbaar is (het stuurt het ene data-frame na het andere totdat het einde bereikt is en wordt gemarkeerd met deFIN bit). Met uitbreidingen van het protocol kan dit ook worden gebruikt om meerdere datastromen simultaan te versturen en ontvangen, ook welmultiplexing genoemd.
Vanuit een veiligheidsoogpunt is het belangrijk om deOrigin-header te controleren tijdens het maken van een connectie vanuit de server. Zo voorkomt men Cross-Site WebSocket Hijacking-attacks, welke mogelijk zijn als de connectie wordt gecontroleerd metcookies of HTTP-authenticatie. Het is beter sleutels of vergelijkbare mechanismen te gebruiken om de betrouwbaarheid van een WebSocketconnectie te waarborgen wanneer er gevoelige informatie wordt verstuurd over de verbinding.