WebSocket är en integrerad teknologi i många moderna webbapplikationer. Om du skriver kod för webben har du säkert hört termen förut, men du kanske inte är säker på vad det är exakt eller hur du använder det. Lyckligtvis är WebSocket inte ett komplext koncept, och du kan få en grundläggande förståelse för det ganska snabbt.
Vad är WebSocket?
WebSocket är tyvärr ett av de namn som inte verkar vara vettigt vid första anblicken. WebSocket är faktiskt namnet på en kommunikationsprotokoll som möjliggör dubbelriktad kommunikation mellan klienten och webbservern.
I enklare termer är WebSocket en teknik som gör att en klient och en server kan skapa en anslutning där endera parten kan skicka ett meddelande till den andra när som helst.
Detta skiljer sig från en vanlig HTTP-anslutning, där klienten måste initiera en begäran, och först då kan servern skicka ett svar. Faktum är att WebSocket är ett helt annat kommunikationsprotokoll än HTTP som designades för att vara HTTP-kompatibelt. När en klientapplikation vill initiera en WebSocket-anslutning måste den använda
HTTP-uppgraderingsmekanism för att byta till WebSocket-protokollet.Vid det här laget kanske du tänker: "ett protokoll är bara en uppsättning regler, hur kan du använda det för att koda?".
Den saknade biten är något som kallas en protokollstack. I huvudsak har enheter som stöder ett protokoll hårdvara och mjukvara inbyggd i dem som gör att du kan skriva applikationer som kommunicerar med protokollet. Protokollet används inte direkt för att bygga någonting.
Varför skapades WebSocket?
För att illustrera behovet av WebSocket, överväg mekanismen bakom att chatta på internet.
Någon skickar ett meddelande till chattservern från sin enhet, men servern måste fortfarande skicka meddelandet till din enhet innan du kan läsa det. Om servern använder HTTP kan servern inte vidarebefordra meddelandet direkt till dig, eftersom servern inte kan initiera förfrågningar.
Det finns ett par sätt att lösa detta problem med HTTP. Ett sätt är att klienten hela tiden skickar uppdateringsförfrågningar till servern, och servern kommer att vidarebefordra all data som den har i svaret. Denna teknik kallas polling, och varje begäran kallas en poll. Det finns två varianter av omröstning: lång omröstning och kort omröstning.
Att använda den långa pollingvarianten innebär att klientenheten hela tiden frågar servern om några nya meddelanden finns tillgängliga. Om nya meddelanden är tillgängliga kommer servern att skicka meddelandena som ett svar. Om inte, skulle servern fördröja att svara och hålla anslutningen öppen tills den hade data att skicka tillbaka, och sedan skulle klienten omedelbart göra en ny begäran.
Denna teknik är ineffektiv, eftersom HTTP inte var designad för att användas på detta sätt. Den fungerar tillräckligt i liten skala, men varje HTTP-förfrågan innebär att extra data skickas i header, och det resulterar i en avsevärt ökad belastning på servern när många klienter pollar Det.
Här är ett diagram som illustrerar långa omröstningar:
Den korta valningsvarianten är ännu mindre effektiv. Kort sagt, servern håller inte anslutningen öppen förrän det finns ny data, vilket innebär att klienten måste fortsätta att polla servern med fasta, mycket korta intervall.
En annan teknik för dubbelriktad kommunikation i HTTP kallas streaming.
Vid streaming, efter att den första begäran har skickats, håller servern anslutningen öppen på obestämd tid och skickar nya delar av information som kontinuerliga delsvar till klienten.
Att använda streaming resulterar i en mindre dataoverhead och serverbelastning än polling, eftersom klienten helst bara gör en HTTP-förfrågan. Tyvärr skapar streaming problem under vissa förhållanden eftersom webbläsare och nätverksförmedlare (som proxyservrar) ofta försöker hantera partiella svar som trasiga delar av ett stort HTTP-svar (vilket är normalt HTTP-beteende), istället för som de separata meddelanden de var avsedda att vara.
WebSocket skapades för att lösa dessa problem. Till skillnad från HTTP har WebSocket designats specifikt för dubbelriktad kommunikation. Med WebSocket, när en anslutning väl har öppnats, kan klienten och servern skicka meddelanden fram och tillbaka utan problem med polling eller streaming.
Användningsfall för WebSocket
WebSocket är bra, men det betyder inte att det ska användas överallt.
Implementering av WebSocket kan lägga till komplexitet till din applikation, särskilt på serversidan, så det bör inte göras om du inte har en bra anledning. Det väcker frågan: hur ser en bra anledning ut?
WebSocket är idealisk för användningsfall där frekvent dubbelriktad kommunikation med låg latens krävs. WebSocket ger med andra ord en fördel för applikationer som behöver kommunicera ofta eller i stor skala. Om kommunikationen inte behöver vara i realtid eller om applikationen aldrig kommer att växa till stor skala, kan polling eller streaming vara tillräckligt för användning i den applikationen.
Typiska användningsområden för WebSocket är att bygga chattapplikationer, onlinespel för flera spelare, realtidssamarbete och aviseringsprogram, etc.
Hur man använder WebSocket på klientsidan
Att använda WebSocket på serversidan kan vara ganska involverat, och processen varierar avsevärt beroende på språket (som C#, Java, etc.) och valfritt bibliotek, så vi kommer inte att täcka det här. Därefter kommer vi kort att diskutera hur man använder WebSocket på klientsidan.
Alla moderna webbläsare implementerar ett webb-API som kallas WebSocket API, som är webbläsarens protokollstack för WebSocket-protokollet. Du kan använda WebSocket i JavaScript med detta API. API: et låter dig skapa ett WebSocket-objekt, genom vilket du skapar en WebSocket-anslutning och interagerar med WebSocket-servern.
Du kan använda följande kodformat för att skapa ett WebSocket-objekt:
låt exempelSocket = new WebSocket("wss://www.example.com/socketserver", "dummyProtocol");
Det första argumentet till konstruktorn är URI: n för WebSocket-servern som du vill skapa en anslutning med. Det börjar alltid med "ws" eller "wss". Det andra argumentet är valfritt. Dess värde är antingen en sträng eller en array av strängar, som anger de underprotokoll som du stöder.
WebSocket-objektet har en skrivskyddad egenskap som heter readyState. Åtkomst till den här egenskapen ger det aktuella tillståndet för WebSocket-anslutningen. readyState har fyra möjliga värden: "connecting", "open", "closing" och "closed".
När den kodraden körs kommer webbläsaren att försöka ansluta till den angivna servern. Anslutningen kommer inte att slutföras på en gång, så readyState of exampleSocket kommer att "ansluta". Inga meddelanden kan skickas eller tas emot förrän anslutningen är klar, då värdet för readyState blir "öppet".
De exempelSocket objektet har en händelseavlyssnare (som skiljer sig från DOM-händelseavlyssnare) kallas "onopen" som låter dig utföra ytterligare åtgärder först efter att anslutningen har upprättats. Objektet har också en "sänd"-metod som låter dig skicka strängar, Blobs (binära data) och ArrayBuffers som meddelanden till servern.
Här är ett exempel som använder dessa tillsammans:
exempelSocket.onopen = fungera (händelse) {
exempelSocket.send("WebSocket är riktigt coolt");
};
API: et ger dig också ett sätt att kunna reagera på de meddelanden som servern skickar. Detta görs med "onmessage"-händelselyssnaren. Här är ett exempel:
exempelSocket.onmessage = fungera (händelse) {
trösta.logga(händelse.data);
}
Istället kan du också skriva en pilfunktion:
exampleSocket.onmessage = (händelse) => { trösta.log (event.data); }
API: et tillhandahåller också en stänga() metod för att stänga anslutningen. Så här ser det ut:
exempelSocket.stänga();
WebSocket möjliggör effektiv dubbelriktad kommunikation
WebSocket är ett dubbelriktat kommunikationsprotokoll. Servrar och webbläsare implementerar protokollstackar för att kommunicera med WebSocket. WebSocket existerar eftersom HTTP inte var designad för att vara dubbelriktad. Det finns metoder för att implementera dubbelriktade anslutningar med HTTP, men de har problem.
WebSocket är kraftfull teknik, men är inte nödvändigt i alla fall, eftersom det kan komplicera applikationsarkitekturen avsevärt. Att använda WebSocket på klientsidan görs med webbläsarens WebSocket API.