Asynchrónny web alebo čo sú webové zásuvky. Pripojenie k TCP Socketu z prehliadača pomocou javascriptu

  • 18.06.2019

Čo je WebSocket. Čo je lepšie - webové zásuvky alebo AJAX?

5 (100 %) 3 hlasy

webovú zásuvku (webovú zásuvku) je plne duplexný komunikačný protokol cez pripojenie TCP. To znamená, že pomocou tohto protokolu môžete odosielať a prijímať správy súčasne. Umožňuje posielanie správ v reálnom čase medzi prehliadačom a serverom.

Webové zásuvky na dlhú dobu nie sú experimentálne, používa sa v prehliadačových hrách, interaktívnych systémoch, platobných systémoch. WebSockets sú už súčasťou moderného webu!

Prehliadač je webový server. Ako to funguje a čo je potrebné zmeniť?

Pre webových vývojárov bol vždy problém získať reakciu prehliadača na udalosti, ktoré sa vyskytujú na serveri. Protokol HTTP má určité nevýhody a pravdepodobne ho kritizovali všetci vývojári. Jednou z týchto nevýhod je problém trvalého pripojenia k serveru. Implementácia protokolu HTTP nezahŕňala tento druh interakcie. Napríklad, ak chceme získať údaje zo servera do prehliadača, musíme na server zadať ďalšiu požiadavku, a to znamená opätovné načítanie stránky. To znamená, že ak ste otvorili stránku v prehliadači, načítali stránku, prezerali si ju a dovtedy sa táto stránka na serveri zmenila, potom musíme stránku znova načítať, aby sme zmenu získali.

Existuje pomerne veľké množstvo úloh, pri ktorých musíme získať asynchrónnosť pomocou protokolu HTTP. To znamená, že ak dôjde k zmenám na serveri, musíte tieto zmeny získať v prehliadači bez opätovného načítania. Jedným z takýchto príkladov je chat, v ktorom ľudia komunikujú a keď jeden posiela správy druhému, príjemca ich okamžite vidí bez opätovného načítania stránky. Predtým nebolo vytvorenie tohto druhu aplikácie jednoduché, existovali rôzne stupne interpretácie, ktoré napodobňovali akcie servera push. Jedným z takýchto príkladov sú klientsky organizované rámce, ktoré sa načítavajú raz za sekundu a odosielajú požiadavky na server.

Tento prístup má veľa nevýhod - vytvára sa veľmi veľké množstvo požiadaviek na server, je ťažké zorganizovať správnu štruktúru aplikácie. Hlavným problémom je, že robíme emuláciu reakcie na udalosť servera. Klient (prehliadač) dostáva dáta vždy s veľkým oneskorením.

Teraz si pohovorme o AJAX. Keď objekt XMLHTTPRequest v prehliadačoch sa situácia mierne zlepšila. V tomto prípade môžeme komunikovať so serverom podľa schémy dlhé hlasovanie. Podstata tejto schémy je opísaná nižšie, bod po bode:

  • Klient (prehliadač) odošle požiadavku na server,
  • Spojenie nie je uzavreté a klient čaká na výskyt udalosti,
  • Keď nastane udalosť, klient dostane odpoveď na svoju požiadavku,
  • Klient ihneď odošle novú požiadavku.

Pri tomto prístupe dostávame asynchrónne požiadavky na server a odpovede sa spracúvajú pomocou funkcií spätného volania. Ale tento prístup má aj určité nevýhody. Hlavnou nevýhodou tohto prístupu je, že server a udalosti servera nie sú iniciátorom interakcie.

Nie je to tak dávno, čo sa objavil nový protokol, ktorý nemá nevýhody, ktoré sme uviedli vyššie. Nová technológia WebSockets je implementáciou plne duplexného komunikačného protokolu cez TCP spojenie.

Prečo WebSockets? Výhody a nevýhody protokolu ws

Pomocou technológie Web Sockets musíme zabudnúť na zaužívaný systém interakcie vo svete WWW. Musíme zaviesť štandardný model protokolu HTTP – „žiadosť / odpoveď na požiadavku“. V rámci technológie Web Sockets môžu prehliadač a server kedykoľvek odosielať a prijímať dáta, to znamená, že sa stávajú rovnocennými účastníkmi.

WebSocket vytvorí jedno pripojenie klient-server. Na prácu s WebSocketmi musia obe strany (klient aj server) podporovať túto technológiu. Všetky nové prehliadače podporujú protokol WS a serverovú časť implementuje vývojár. Keď sú server a klient pripravení „bojovať“, server a klient môžu posielať jednoduché textové správy cez WebSockets. Prenos a príjem dát prebieha okamžite, táto technológia vytvára obojsmerné komunikačné kanály.

Keďže spojenie s klientom a serverom nie je uzavreté (je neustále otvorené), predchádza sa tým prenosu nepotrebných údajov (HTTP hlavičky). V štandarde WebSockets nie je obmedzený počet otvorených pripojení a poradie požiadaviek.

V tejto lekcii sme sa dozvedeli, aké metódy existujú pre asynchrónne požiadavky na server, čo je WebSocket a aké výhody má v porovnaní s rámcami AJAX a HTML. V ďalšej lekcii začneme pracovať s WebSocket na Node.js, podrobnejšie zvážime túto technológiu v akcii a napíšeme chat na WebSocket a Node.js. Kompletný zoznam Node.js tutoriálov nájdete tu.

Pred pár týždňami vývojári Google Chromium zverejnili novinku o podpore technológie WebSocket. V IT buržoázii tieto správy vyvolali efekt vybuchujúcej bomby. V ten istý deň novinku vyskúšali rôzni známi IT ľudia a zanechali na svojich blogoch nadšené recenzie. Okamžite vývojári rôznych serverov/knižníc/rámcov (vrátane Apache, EventMachine, Twisted, MochiWeb atď.) oznámili, že podpora WebSocket bude implementovaná do ich produktov v blízkej budúcnosti.
Čo také zaujímavé nám sľubuje technológia? podla mna webovú zásuvku je najdramatickejším rozšírením protokolu HTTP od jeho počiatku. Toto nie sú triky, to sú Zmena paradigmy HTTP. Pôvodne synchrónny protokol, postavený na modeli požiadavka-odpoveď, sa stáva plne asynchrónne a symetrické. Teraz už neexistuje klient a server s pevnými rolami, ale výmeny údajov sú dvaja rovnocenní účastníci. Každý z nich funguje samostatne av prípade potreby posiela údaje inému. Odoslané - a ide sa ďalej, nie je čo čakať. Druhá strana odpovie, keď bude chcieť – možno nie hneď, možno vôbec. Protokol dáva úplnú voľnosť pri výmene dát, je len na vás, ako ho použijete.

Verím, že webové zásuvky sa vám budú hodiť, ak vyvíjate:
- webové aplikácie s intenzívnou výmenou dát, náročné na výmenný kurz a kanál;
- aplikácie podľa noriem;
- „dlhohrajúce“ webové aplikácie;
- komplexné aplikácie s mnohými rôznymi asynchrónnymi blokmi na stránke;
- aplikácie s viacerými doménami.

A ako to funguje?

Veľmi jednoduché! Keď sa vaša stránka rozhodne, že chce otvoriť webový soket pre server, vytvorí špeciálny objekt javascript:

  1. < script >
  2. ws = new WebSocket("ws://site.com/demo" );
  3. // a novému objektu priradí tri spätné volania:
  4. // prvý sa zavolá pri nadviazaní spojenia:
  5. ws.onopen = function () ( alert("Pripojenie otvorené..." ) );
  6. // sekunda - zatvorte pri pripojení
  7. ws.onclose = function () ( alert("Spojenie zatvorené..." ) );
  8. // a nakoniec tretí - zakaždým, keď prehliadač dostane nejaké dáta cez webovú zásuvku
  9. ws.onmessage = funkcia (evt) ( $("#msg" ).append("

    "+evt.data+"

    " ); };
* Tento zdrojový kód bol zvýraznený pomocou Zvýrazňovača zdrojového kódu.
A čo sa deje v sieti?
Všetko začína rovnako ako pri bežnej HTTP požiadavke. Prehliadač sa pripája cez TCP k portu servera 80 a dáva trochu nezvyčajnú požiadavku GET:
GET /demo HTTP/1.1
Aktualizácia: WebSocket
Pripojenie: Upgrade
Hostiteľ: site.com
Pôvod: http://site.com


Ak server podporuje WebSockets, odpovie takto:
HTTP/1.1 101 Handshake protokolu Web Socket
Aktualizácia: WebSocket
Pripojenie: Upgrade
WebSocket-Origin: http://site.com
Miesto WebSocket: ws://site.com/demo

Ak je s tým prehliadač spokojný, jednoducho odíde TCP spojenie otvorené. To je všetko - "podanie ruky" je hotové, kanál na výmenu údajov je pripravený.
Akonáhle jedna strana chce preniesť nejaké informácie na druhú, pošle dátový rámec v nasledujúcom tvare:

0x00,<строка в кодировке UTF-8>0xFF

Teda len riadok textu – postupnosť bajtov, ku ktorej je vpredu pripojený nultý bajt 0x00 a na konci 0xFF. A je to – žiadne hlavičky, žiadne metadáta! Čo presne poslať, nechali vývojári úplne na vašom uvážení: chcete XML, chcete JSON, no aspoň Puškinove básne.
Zakaždým, keď prehliadač prijme takúto správu, „stiahne“ vaše spätné volanie onmessage.

Je ľahké pochopiť, že účinnosť takéhoto protokolu má tendenciu k 95%. Nejde o klasickú AJAX požiadavku, kde na každý trik musíte poslať niekoľko kilobajtov hlavičiek. Rozdiel bude viditeľný najmä pri častej výmene malých blokov údajov. Rýchlosť spracovania sa tiež prikláňa k rýchlosti čistého TCP socketu – všetko je už predsa pripravené – spojenie je otvorené – stačí poslať bajty.

Lyrická odbočka:
A ešte jedna vec ma veľmi teší - UTF-8 je zvolené ako jediné povolené kódovanie! Už teraz bojazlivo dúfam, že po chvíli opustíme jednu z barlí pavučiny.

mozes poslat obrazok?
Pomocou WebSockets môžete tiež prenášať binárne dáta. Pre nich sa používa iný dátový rámec v nasledujúcom formulári:
0x80,<длина - один или несколько байт>, <тело сообщения>

Čo znamená „jeden alebo viac bajtov“? Aby sa nevytvorili obmedzenia na dĺžku prenášanej správy a zároveň neplytvali bajty iracionálne, použili vývojári veľmi ošemetný spôsob určenia dĺžky tela správy. Každý bajt v indikácii dĺžky sa posudzuje po častiach: najvýznamnejší bit udáva, či je tento bajt posledný (0) alebo sú za ním ďalšie (1) a spodných 7 bitov obsahuje skutočné dáta. Môžete to spracovať takto: akonáhle získate znamienko binárneho dátového rámca 0x80, vezmete ďalší bajt a vložíte ho do samostatnej „prasiatka“, pozriete sa na ďalší bajt – ak má nastavený vysoký bit , potom ho preneste do „prasiatka“ a tak ďalej, až kým nenarazíte na bajt s 0 vysokým bitom. Toto je teda posledný bajt v ukazovateli dĺžky – preneste ho tiež do „prasiatka“. Teraz zo všetkých bajtov v „prasiatku“ odstráňte vysoké bity a zaslepte zvyšok. Toto bude dĺžka tela správy. Môže sa tiež interpretovať ako 7-bitové čísla bez najvýznamnejšieho bitu.

Napríklad najdôležitejší obrázok webdizajnu - priehľadný jednopixelový GIF s veľkosťou 43 bajtov je možné preniesť takto:

0x80, 0x2B,<тело сообщения>

Objekt s veľkosťou 160 bajtov je zakódovaný s dĺžkou 2 bajty:
0x80, 0x81, 0x20,<байты объекта>

Nie je to veľmi elegantné?

Čo nám to dáva?

Rýchlosť a efektivita
Vysokú rýchlosť a efektivitu prenosu zabezpečuje malá veľkosť prenášaných dát, ktoré sa niekedy zmestia aj do jedného TCP paketu – tu samozrejme všetko závisí od vašej obchodnej logiky. (TSB môžete vložiť aj do dátového rámca, ale takýto prenos bude vyžadovať o niečo viac ako 1 TCP paket. :)).
Myslite tiež na to, že spojenie je už pripravené – netreba strácať čas a premávku na jeho zriadenie, podávanie rúk, vyjednávanie.
štandardná
WebSockets už pri svojom vydaní pošle Comet a všetky zatúlané veci, ktoré sú na ňom navinuté - Bayuex, LongPolling, MultiPart a tak ďalej na smetisko dejín. Všetko sú to užitočné technológie, ale väčšinou fungujú na hackoch, nie na štandardoch. Odtiaľto vznikajú periodické problémy: potom proxy „prežúval“ odpoveď a rozdal ju až po nahromadení niekoľkých odpovedí. Na „prepichovanie“ proxy sa často používal dvojkilobajtový „plunžer“ – t.j. množstvo prenesených dát sa zvýšilo o medzery (alebo iné nepodstatné znaky) až na 2K, ktoré mnohé proxy preniesli okamžite bez zdržania. Antivírusy pravidelne vyjadrovali svoju túžbu dostať odpoveď v plnom rozsahu, skontrolovať ju a až potom ju odovzdať príjemcovi. Samozrejme, dnes sú už všetky tieto problémy viac-menej vyriešené – inak by neexistovalo také množstvo webových aplikácií. Vývoj v tomto smere je však spojený so vznikom nových problémov – práve preto, že ide o snahu obísť štandard.

Podľa mňa po čase zostanú len 2 technológie: čistý AJAX a WebSockets. Prvý je vhodný na jednorazové alebo viacstránkové aktualizácie – v skutočnosti nie je racionálne spustiť na to výkonný webový soket. A všetko ostatné, čo teraz robí kométa a kolegovia, sa presunie do webových zásuviek, pretože. bude to jednoduchšie a efektívnejšie. Napríklad chcete živé sledovanie cien na devízovom trhu. Prosím: otvorte soket - server vám pošle všetky aktualizácie. Vašou úlohou je iba zavesiť správne spätné volanie na udalosť onmessage a zmeniť čísla na obrazovke. Rozhodnete sa niečo kúpiť, poslať asynchrónnu správu na server a súčasne pokračovať v prijímaní čísel. Elegantne? V porovnaní s tým vyzerá LongPolling s potrebou periodicky reštartovať aj neaktívny kanál (aby nebol proxovaný alebo zabuchnutý niekým iným) ako špinavý hack.

Životnosť kanála
Na rozdiel od HTTP nemajú webové sokety žiadne obmedzenia, pokiaľ ide o to, ako dlho môžu žiť v neaktívnom stave. To znamená, že už nemusíte pravidelne obnovovať pripojenie, pretože. nie je oprávnená „zabíjať“ žiadne proxy. To znamená, že pripojenie môže visieť v neaktívnej forme a nevyžaduje zdroje. Samozrejme, niekto môže namietať, že TCP sockety budú na serveri upchaté. Na to stačí použiť dobrý multiplexer a bežný server môže ľahko natiahnuť až milión otvorených spojení.
Komplexné webové aplikácie
Ako viete, HTTP poskytuje limit na počet súčasne otvorených relácií na jeden server. Z tohto dôvodu, ak máte na stránke veľa rôznych asynchrónnych blokov, museli ste vytvoriť nielen serverový, ale aj klientsky multiplexer - odtiaľ pochádza Bayeux Protocol.
Našťastie toto obmedzenie neplatí pre webové zásuvky. Otvorte toľko, koľko potrebujete. A koľko použiť - jednu vec (a cez to multiplexovať všetko) alebo naopak - každý blok má svoje prepojenie - je len na vás. Pokračujte z pohodlia vývoja, zaťaženia servera a klienta.
Aplikácie viacerých domén
A ďalší „kameň v topánke“ vývojára AJAX – problémy s aplikáciami medzi doménami. Áno, a tiež pre nich bolo vynájdených veľa hackov. Zamávajme im perom a utrime si zlomyseľnú slzu. WebSockets nemá žiadne takéto obmedzenia. Obmedzenia nie sú zavedené na princípe „z rovnakého zdroja“, ale z „povoleného zdroja“ a nie sú určené na klientovi, ale na serveri. Myslím, že tí pozorní si už všimli nový titul Origin. Informácie sa cez ňu prenášajú z miesta, kde sa chcú pripojiť k vašej webovej zásuvke. Ak vám táto adresa nevyhovuje, pripojenie odmietnete.
Všetky! Koniec cross-domény zopyanoy bolesti!
Cítite to rukami?
Môcť!

AKTUALIZÁCIA: Jednou z otvorených implementácií webových soketov je chat na www.mibbit.com (poznámka na ich blogu).
Implementácia PHP servera WebSocket je tiež poskytovaná ako modul do asynchrónneho rámca

22.9. Webové zásuvky

Kapitola 18 ukazuje, ako môžu skripty klienta JavaScript komunikovať so servermi cez sieť. Všetky príklady v tejto kapitole používajú protokol HTTP, čo znamená, že všetky sú obmedzené na pôvodnú povahu protokolu HTTP: tento bezstavový protokol pozostáva z požiadaviek klientov a odpovedí servera. Protokol HTTP je v skutočnosti vysoko špecializovaný sieťový protokol. Všestrannejšie sieťovanie cez internet (alebo cez LAN) sa často implementuje pomocou pripojení s dlhou životnosťou a poskytuje obojsmerné zasielanie správ cez TCP sokety. Nie je bezpečné poskytnúť klientskym skriptom JavaScript prístup k nízkoúrovňovým soketom TCP, ale špecifikácia „WebSocket API“ definuje bezpečnú alternatívu: umožňuje klientskym skriptom vytvárať obojsmerné pripojenia k serverom, ktoré podporujú protokol Web Sockets. To výrazne zjednodušuje riešenie niektorých sieťových úloh.

Web Sockets API sa úžasne ľahko používa. Najprv musíte vytvoriť soket pomocou konštruktora WebSocket():
var socket = new WebSocket("ws://ws.example.com:1234/resource");

Protokol webového soketu

Ak chcete použiť webové sokety v skriptoch JavaScript, bude stačiť ovládať rozhranie API klienta webových soketov, ktoré je popísané tu. Neexistuje žiadne ekvivalentné serverové API na vytváranie webových soketových serverov; táto časť poskytne jednoduchý príklad servera založeného na použití interpreta uzla (časť 12.2) a knižnice webového soketového servera tretej strany. Klient a server komunikujú cez dlhotrvajúce sokety TCP podľa pravidiel definovaných protokolom Web Sockets. Nebudeme tu zachádzať do špecifík protokolu, ale treba poznamenať, že protokol Web Sockets je veľmi starostlivo navrhnutý tak, aby webové servery mohli ľahko spracovať pripojenia HTTP a Web Socket na rovnakom porte.

Webové sokety získali širokú podporu medzi predajcami prehliadačov. Zistilo sa, že skorá, predbežná verzia protokolu Web Sockets má vážnu bezpečnostnú dieru, takže v čase písania tohto článku niektoré prehliadače deaktivovali podporu pre Web Sockets, kým nebola štandardizovaná bezpečná verzia protokolu. Napríklad vo Firefoxe 4 možno budete musieť explicitne povoliť podporu webových soketov otvorením stránky about:config a nastavením "network.websocket. override-security-block“ na hodnotu true.

*********************************************

argument konštruktéra WebSocket() je adresa URL, ktorá používa protokol ws:// (alebo wss:// pre zabezpečené pripojenia, podobne ako https://). Adresa URL určuje názov hostiteľa, ku ktorému sa chcete pripojiť, a môže tiež špecifikovať port (v predvolenom nastavení webové sokety používajú rovnaký port ako protokoly HTTP a HTTPS) a cestu alebo prostriedok.

Po vytvorení soketu sa v ňom zvyčajne zaregistrujú obslužné rutiny udalostí:

socket.onopen = function(e) ( /* Pripojenie nadviazané. */ );
socket.onclose = function(e) ( /* Spojenie uzavreté. */ );
socket.onerror = function(e) ( /* Niečo sa pokazilo! */ );
socket.onmessage = function(e) (
varmessage = e.data; /* Server odoslal správu. */
};

Ak chcete odoslať údaje na server cez soket, zavolajte metódu poslať () zásuvka:

socket.send("Ahoj server!");

Aktuálna verzia rozhrania Web Sockets API podporuje iba textové správy a odosiela ich ako reťazce kódované v UTF-8. Aktuálna verzia špecifikácie protokolu Web Sockets však zahŕňa podporu pre binárne správy a budúce verzie API môžu podporovať binárnu komunikáciu so serverom.

Keď skript dokončí interakciu so serverom, môže zatvoriť webový soket zavolaním svojej metódy Zavrieť() .

Webové sokety sú obojsmerné a klient a server môžu použiť jediné spojenie vytvorené cez webový soket na vzájomné posielanie správ v ľubovoľnom danom čase. Táto interakcia nemusí byť vo forme požiadaviek a odpovedí. Každá služba založená na websocket bude definovať svoj vlastný „podprotokol“ na prenos údajov medzi klientom a serverom. Tieto "podprotokoly" sa môžu časom vyvíjať a možno budete musieť implementovať klientov a servery, ktoré podporujú viacero verzií podprotokolov. Našťastie protokol Web Sockets obsahuje mechanizmus na vyjednávanie výberu podprotokolu, ktorý je podporovaný klientom aj serverom. Konštruktér WebSocket() môžete odovzdať pole reťazcov. Server ho dostane ako zoznam podprotokolov podporovaných klientom. Server si vyberie subprotokol, ktorý podporuje, a pošle ho späť klientovi. Po nadviazaní spojenia bude klient schopný určiť, ktorý podprotokol sa má použiť, kontrolou vlastnosti protokol objekt webovú zásuvku .

Časť 18.3 popisuje aplikačné rozhranie objektu EventSource a demonštruje jeho použitie implementáciou chatového klienta a servera ako príklad. Websockets ešte viac uľahčujú implementáciu týchto aplikácií. Príklad 22-16 ukazuje veľmi jednoduchý chatovací klient: je podobný príkladu 18-15, ale používa webové sokety na obojsmerné posielanie správ namiesto objektu EventSource na prijímanie správ a XMLHttpRequest na odosielanie.

Príklad 22.16. Chatovací klient založený na webovom sockete




https://github.com/miksago/node-websocket-server/. Pri kontaktovaní
* do prostriedku "/" vráti HTML súbor klienta chatu. V odpovedi na výzvu na akékoľvek
* Kód 404 sa vráti inému zdroju. Správy sa prijímajú prostredníctvom protokolu
* webové zásuvky a sú jednoducho vysielané cez všetky aktívne pripojenia.
*/
var http = vyžadovať("http"); // Použiť HTTP server v Node
var ws = require("websocketserver"); // Použiť externú knižnicu
// Prečítajte si zdrojový súbor s implementáciou chat klienta. Používa sa nižšie
var clientui = require("fs").readFileSync("wschatclient.html");
// Vytvorte HTTP server
var httpsserver = nový http.Server();
// Keď HTTP server prijme novú požiadavku, zavolá sa táto funkcia
httpsserver.on("požiadavka", funkcia (požiadavka, odpoveď) (
// Ak sa požaduje zdroj "/", pošlite implementáciu klienta chatu,
if (request. and rl === "/") ( // Požadovaná implementácia klienta chatu
response.writeHead(200, (""Typ obsahu": "text/html"));
odozva.zapis(clientui); odozva.end();
}
else ( // V odpovedi na akúkoľvek inú požiadavku pošlite kód 404 „Nenájdené“.
response.writeHead(404);
odozva.end();
}
});
// Zabalte HTTP server so serverom založeným na websocket
var wsserver = ws.createServer((server: httpsserver));
// Zavolajte túto funkciu, keď sú prijaté nové požiadavky na pripojenie
wsserver.on("spojenie", funkcia(zásuvka) (
socket.send("Vitajte v chate."); // Pozdravte nového zákazníka
socket.on("správa", function(msg) ( // Prijímanie správ od klienta
wsserver.broadcast(msg); // A pošlite ich všetkým ostatným
});
});
// Spustite server na porte 8000. Spustite server websocket
// tiež spustí HTTP server. Ak ju chcete použiť, pripojte sa.
// podľa adresy

(Web Sockets) je pokročilá technológia, ktorá vám umožňuje vytvoriť interaktívne spojenie medzi klientom (prehliadačom) a serverom na odosielanie správ v reálnom čase. Webové sokety na rozdiel od HTTP umožňujú pracovať s obojsmerným dátovým tokom, čo robí túto technológiu úplne jedinečnou. Pozrime sa, ako táto technológia funguje a ako sa líši od HTTP.

Ako funguje HTTP?

Schéma odosielania správ HTTP

Pravdepodobne viete, čo je HTTP (alebo HTTPS), keďže sa s týmto protokolom stretávate každý deň vo svojom prehliadači. Prehliadač sa neustále pýta servera, či má nové správy a prijíma ich.

Možno tiež viete, že HTTP umožňuje rôzne typy požiadaviek, ako sú POST, GET alebo PUT, pričom každá má iný účel.

Ako fungujú webové zásuvky?

Schéma výmeny správ pri používaní webových soketov

Webové sokety nepotrebujú vaše opakované požiadavky na odpoveď. Stačí vykonať jednu požiadavku a čakať na odpoveď. Môžete jednoducho počúvať server, ktorý vám pošle správy hneď, ako budú pripravené.

Webové sokety možno použiť, ak vyvíjate:

  • aplikácie v reálnom čase;
  • chatovacie aplikácie;
  • aplikácie internetu vecí;
  • hry pre viacerých hráčov.

Kedy by ste sa mali vyhnúť používaniu webových zásuviek?

Takmer nikdy. Jediným negatívom je nekompatibilita s niektorými prehliadačmi, no už 95 % prehliadačov podporuje webové zásuvky.

V niektorých prípadoch stále nepotrebujete webové zásuvky. Ak vytvárate jednoduchý CMS, pravdepodobne nebudete potrebovať funkčnosť v reálnom čase. Taktiež nepoužívajte webové zásuvky v REST API, pretože postačia HTTP požiadavky ako GET, POST, DELETE a PUT.

Praktické príklady

Nižšie uvedené príklady používajú JavaScript pre klienta a Node.js pre server. Príklady sú veľmi jednoduché a je nepravdepodobné, že budú užitočné v praxi, ale pomôžu vám pochopiť podstatu.

Webové zásuvky

Príklad chatu WebSocket

Const WebSocket = require("ws"); // vytvorenie nového servera websocket const wss = new WebSocket.Server(( port: 8080 )); // odoslaná klientom, keď funkcia clientValidator vráti hodnotu true. toto je wss. wss.broadcast = function(data, clientValidator = () => true) (​this.clients.forEach(client => ( if (clientValidator(client)) ( client.send(data); ) )); ) wss .on ("spojenie", ws => ( // udalosť sa spustí, keď klient odošle správu ws.on("správa", správa => // rozošle správu všetkým okrem autora wss.broadcast( správa, klient => klient ! == ws); )); ));

Tu je ilustrácia toho, ako fungujú webové zásuvky:

Ukážka fungovania webových soketov

Ekvivalent v HTTP

Keďže HTTP musí neustále kontrolovať kanál na nové správy, môžete použiť "špinavú" kontrolu (špinavú kontrolu) - prístup, pri ktorom klient pri danej frekvencii (povedzme každých 200 ms) kontroluje nové správy na serveri.

Webové zásuvky(WebSockets) je možno najzaujímavejšou inováciou vo webovej technológii od nástupu „Asynchrónneho JavaScriptu a XML“ (AJAX). Stali sa populárnymi s vydaním HTML5 a sú podporované mnohými webovými rámcami.

Trvalo však dlho, kým sa vytvorila stabilná a interoperabilná špecifikácia webových soketov.

Model protokolu HTTP (Hypertext Transfer Protocol) bol navrhnutý dávno predtým, ako sa internet stal populárnym, a je založený na jednoduchej špecifikácii a dizajne. V tradičnom modeli HTTP klient otvorí pripojenie k serveru typu back-end, odošle požiadavku HTTP, ako napríklad GET, POST, PUT alebo DELETE, a server HTTP vráti príslušnú odpoveď.

Tradičný model HTTP bol zaťažujúci pre takmer akúkoľvek aplikáciu nad rámec jednoduchého dátového modelu." prijímať a odosielať obsah Predstavte si klienta aplikácie okamžitých správ, kde môžu účastníci posielať správy v ľubovoľnom poradí a stovky účastníkov môžu chatovať súčasne.

Na tieto účely sa používa štandardný prístup „ žiadosť-odpoveď" ukladá príliš silné obmedzenia. Prvými pokusmi obísť tieto obmedzenia boli AJAX a Comet. Obidva boli založené na takzvaných dlhých prieskumoch: otvorenie pripojenia HTTP a jeho udržanie aktívne (udržanie otvoreného pripojenia) tým, že nedokončili odpoveď.

Pomocou webových soketov môže klient vytvoriť „ surové" soket pre server a implementovať plne duplexnú komunikáciu. Podpora webových soketov bola zavedená v r JSR-356.

Balík javax.websocket a jeho podbalík servera obsahujú všetky triedy, rozhrania a anotácie súvisiace s webovým soketom.

Ak chcete implementovať websockets na platforme Java EE, musíte vytvoriť triedu koncového bodu s metódami životného cyklu websocket, ako je uvedené nižšie:

// Vzorový balík koncového bodu com.devchronicles.websockets; verejná trieda HelloEndpoint rozširuje koncový bod ( @Override public void onOpen(final Session session, EndpointConfig config) ( session.addMessageHandler(new MessageHandler.Whole) () ( @Override public void onMessage(String msg) ( try ( session.getBasicRemote().sendText("Ahoj " + msg); ) catch (IOException e) ( ) ) )); ))

// Príklad koncového bodu

verejná trieda HelloEndpoint rozširuje Endpoint(

@Prepísať

public void onOpen(záverečná relácia relácie, konfigurácia EndpointConfig) (

relácia. addMessageHandler(nové MessageHandler . Celý () {

@Prepísať

public void onMessage(String msg )(

skús (

) catch (IOException e ) ( )

} ) ;

Trieda koncového bodu poskytuje tri metódy životného cyklu: onOpen, onClose a onError. Trieda, ktorá ju rozširuje, musí implementovať aspoň metódu onOpen.

Koncový bod môžete nasadiť dvoma spôsobmi: konfiguráciou alebo programovo.

Ak chcete vykonať nasadenie kódu, vaša aplikácia musí volať nasledovné:

ServerEndpointConfig.Builder.create(HelloEndpoint.class, "/ahoj").build();

ServerEndpointConfig . staviteľ. vytvoriť (HelloEndpoint . class , "/ahoj" ) . build();

Nasadený websocket je dostupný na adrese ws:// ://Ahoj. Je však lepšie použiť konfiguráciu cez anotáciu. Pritom sa rovnaký koncový bod stane kódom uvedeným nižšie:

// Príklad balíka anotovaného koncového bodu com.devchronicles.websockets; @ServerEndpoint("/hello") verejná trieda HelloEndpoint ( @OnMessage public void onMessage(relácia relácie, správa reťazca) ( try ( session.getBasicRemote().sendText("Ahoj " + msg); ) catch (IOException e) ( ) ))

// Príklad koncového bodu s anotáciami

package.com. devkroniky. webové zásuvky;

@ServerEndpoint("/ahoj" )

verejná trieda HelloEndpoint(

@OnMessage

public void onMessage (relácia relácie , reťazec msg ) (

skús (

relácia. getBasicRemote(). sendText("Ahoj " + msg) ;

) catch (IOException e ) ( )

Tento prístup vám umožňuje používať anotácie, pričom sa budete držať starého prístupu jednoduchého objektu Java ( POJO), pretože nerozširujete základnú triedu. Komentovaný koncový bod má rovnaké metódy životného cyklu ako v prvom príklade kódu, ale zavádza ďalšie metóda životného cyklu onMessage.

Namiesto implementácie Zapnuté a pridanie obsluhy onMessage v prístupe založenom na anotáciách stačí implementovať anotovanú metódu životného cyklu onMessage. Môžete anotovať pomocou @OnMessage niekoľko metód na získanie rôznych typov údajov, napr Reťazec alebo ByteBuffer pre binárne dáta.

Implementácia webového soketu na strane klienta závisí od používaného webového rámca. Každopádne, nasledujúci úryvok ukazuje jednoduchú jazykovú verziu JavaScript:

var webSocket = new WebSocket("ws://127.0.0.1:8080/websockets/hello"); webSocket.send("svet");