WebSocket er en integreret teknologi i mange moderne webapplikationer. Hvis du skriver kode til nettet, har du sikkert hørt udtrykket før, men måske er du ikke sikker på, hvad det præcist er, eller hvordan du bruger det. Heldigvis er WebSocket ikke et komplekst koncept, og du kan ret hurtigt få en grundlæggende forståelse af det.
Hvad er WebSocket?
WebSocket er desværre et af de navne, der ikke synes at give mening ved første øjekast. WebSocket er faktisk navnet på en kommunikationsprotokol der giver mulighed for tovejskommunikation mellem klienten og webserveren.
I simplere termer er WebSocket en teknologi, der gør det muligt for en klient og en server at skabe en forbindelse, hvor begge parter kan sende den anden en besked til enhver tid.
Dette er forskelligt fra en almindelig HTTP-forbindelse, hvor klienten skal starte en anmodning, og først derefter kan serveren sende et svar. Faktisk er WebSocket en helt anden kommunikationsprotokol end HTTP, der er designet til at være HTTP-kompatibel. Når en klientapplikation ønsker at starte en WebSocket-forbindelse, skal den bruge
HTTP-opgraderingsmekanisme for at skifte til WebSocket-protokollen.På dette tidspunkt tænker du måske: "en protokol er bare et sæt regler, hvordan kan du bruge det til at kode?".
Den manglende brik er noget, der hedder en protokol stak. Grundlæggende har enheder, der understøtter en protokol, hardware og software indbygget i dem, som giver dig mulighed for at skrive programmer, der kommunikerer ved hjælp af protokollen. Protokollen bruges ikke direkte til at bygge noget.
Hvorfor blev WebSocket oprettet?
For at illustrere behovet for WebSocket, overveje mekanismen bag chat på internettet.
Nogen sender en besked til chatserveren fra deres enhed, men serveren skal stadig sende beskeden til din enhed, før du kan læse den. Hvis serveren bruger HTTP, kan serveren ikke videresende den besked direkte til dig, fordi serveren ikke kan igangsætte anmodninger.
Der er et par måder at løse dette problem med HTTP. En måde er, at klienten konstant sender opdateringsanmodninger til serveren, og serveren videresender alle data, den har i svaret. Denne teknik kaldes polling, og hver anmodning kaldes en polling. Der er to varianter af afstemning: lang afstemning og kort afstemning.
Brug af den lange polling-variant betyder, at klientenheden konstant spørger serveren, om der er nye meddelelser tilgængelige. Hvis nye beskeder er tilgængelige, sender serveren beskederne som et svar. Hvis ikke, ville serveren forsinke svaret og holde forbindelsen åben, indtil den havde data at sende tilbage, og så ville klienten straks lave en ny anmodning.
Denne teknik er ineffektiv, fordi HTTP ikke var designet til at blive brugt på denne måde. Det fungerer tilstrækkeligt i lille skala, men hver HTTP-anmodning involverer at sende ekstra data i header, og det resulterer i en markant øget belastning på serveren, når mange klienter poller det.
Her er et diagram, der illustrerer lange afstemninger:
Den korte afstemningsvariant er endnu mindre effektiv. Kort fortalt holder serveren ikke forbindelsen åben, før der er nye data, hvilket betyder, at klienten skal blive ved med at polle serveren med faste, meget korte intervaller.
En anden teknik til tovejskommunikation i HTTP kaldes streaming.
I streaming, efter at den første anmodning er sendt, holder serveren forbindelsen åben på ubestemt tid og sender nye oplysninger som kontinuerlige delvise svar til klienten.
Brug af streaming resulterer i en mindre dataoverhead og serverbelastning end polling, fordi klienten ideelt set kun laver én HTTP-anmodning. Desværre skaber streaming problemer under visse forhold, fordi browsere og netværksformidlere (såsom proxyer) ofte forsøger at håndtere delvise svar som brudte stykker af et stort HTTP-svar (hvilket er normal HTTP-adfærd), i stedet for som de separate meddelelser, de var beregnet til at være.
WebSocket blev oprettet for at løse disse problemer. I modsætning til HTTP er WebSocket designet specifikt til tovejskommunikation. Med WebSocket, når en forbindelse er åbnet, kan klienten og serveren sende beskeder frem og tilbage uden problemer med polling eller streaming.
Brug Cases til WebSocket
WebSocket er fantastisk, men det betyder ikke, at det skal bruges overalt.
Implementering af WebSocket kan tilføje kompleksitet til din applikation, især på serversiden, så det bør ikke gøres, medmindre du har en god grund. Det rejser spørgsmålet: hvordan ser en god grund ud?
WebSocket er ideel til brugstilfælde, hvor hyppig tovejskommunikation med lav latenstid er påkrævet. Med andre ord giver WebSocket en fordel for applikationer, der skal kommunikere ofte eller i stor skala. Hvis kommunikationen ikke behøver at være i realtid, eller applikationen aldrig vil vokse til stor skala, kan polling eller streaming være tilstrækkeligt til brug i den applikation.
Typiske anvendelser af WebSocket er til opbygning af chatapplikationer, online multiplayer-spil, realtidssamarbejde og notifikationssoftware osv.
Sådan bruges WebSocket på klientsiden
Brug af WebSocket på serversiden kan være ret involveret, og processen varierer betydeligt afhængigt af sproget (som f.eks. C#, Javaosv.) og valgfrit bibliotek, så vi vil ikke dække det her. Dernæst vil vi kort diskutere, hvordan du bruger WebSocket på klientsiden.
Alle moderne browsere implementerer en web-API kaldet WebSocket API, som er browserens protokolstak for WebSocket-protokollen. Du kan bruge WebSocket i JavaScript ved hjælp af denne API. API'en giver dig mulighed for at oprette et WebSocket-objekt, hvorigennem du opretter en WebSocket-forbindelse og interagerer med WebSocket-serveren.
Du kan bruge følgende kodeformat til at oprette et WebSocket-objekt:
lad eksempelSocket = ny WebSocket("wss://www.example.com/socketserver", "dummyProtocol");Det første argument til konstruktøren er URI'en på den WebSocket-server, du vil oprette en forbindelse med. Det vil altid starte med "ws" eller "wss". Det andet argument er valgfrit. Dens værdi er enten en streng eller en række af strenge, som specificerer de underprotokoller, du understøtter.
WebSocket-objektet har en skrivebeskyttet egenskab kaldet readyState. Adgang til denne egenskab giver den aktuelle tilstand for WebSocket-forbindelsen. readyState har fire mulige værdier: "connecting", "open", "closing" og "closed".
Når denne kodelinje kører, vil browseren forsøge at oprette forbindelse til den angivne server. Forbindelsen vil ikke blive fuldført med det samme, så readyState of exampleSocket vil "forbinde". Ingen beskeder kan sendes eller modtages, før forbindelsen er fuldført, hvorefter værdien af readyState bliver "åben".
Det eksempelSocket objektet har en begivenhedslytter (som er forskellig fra DOM-begivenhedslyttere) kaldet "onopen", der giver dig mulighed for at udføre yderligere handlinger, efter at forbindelsen er etableret. Objektet har også en "send"-metode, der giver dig mulighed for at sende strenge, Blobs (binære data) og ArrayBuffers som beskeder til serveren.
Her er et eksempel, hvor du bruger disse sammen:
eksempelSocket.onopen = fungere (begivenhed) {
eksempelSocket.send("WebSocket er virkelig cool");
};API'en giver dig også mulighed for at reagere på de beskeder, serveren sender. Dette gøres med "onmessage"-begivenhedslytteren. Her er et eksempel:
eksempelSocket.onmessage = fungere (begivenhed) {
konsol.log(begivenhed.data);
}I stedet kan du også skrive en pilefunktion:
eksempelSocket.onmessage = (hændelse) => { konsol.log (event.data); }API'en giver også en tæt() metode til at lukke forbindelsen. Sådan ser det ud:
eksempelSocket.tæt();WebSocket muliggør effektiv tovejskommunikation
WebSocket er en tovejskommunikationsprotokol. Servere og browsere implementerer protokolstakke til at kommunikere ved hjælp af WebSocket. WebSocket eksisterer, fordi HTTP ikke er designet til at være tovejs. Der er metoder til at implementere tovejsforbindelser med HTTP, men de har problemer.
WebSocket er kraftfuld teknologi, men er ikke nødvendig i alle tilfælde, da det kan komplicere applikationsarkitekturen betydeligt. Brug af WebSocket på klientsiden sker med browserens WebSocket API.
