Názory k článku Komunikace webové aplikace se serverem pomocí WebSocket

> jsme omezeni tím, že kvůli bezpečnosti můžeme komunikovat pouze se serverem, ze kterého byla stránka stažena
Toto som tam videl niekolko krat spomenute. fetch() podporuje spojenie s lubovolnym serverom a portom.

Všechny relevantní komunikační technologie (XHR, fetch i WebSocket) podporují spojení s libovolným serverem/portem (až na pár vyjmenovaných blokovaných portů). Rozdíl je ve výchozí politice (SOP - Same Origin Policy):

• HTTP spojení (XHR, fetch) jsou povolena, jen pokud to server explicitně odsouhlastí (block by default)
• WebSocket spojení jsou povolena, dokud je server explicitně nezakáže (allow by default)

Server se rozhoduje na základě hlavičky Origin. Celé je to docela komplikované a nelze to bezvadně shrnout v krátkém komentáři; zájemci si mohou více přečíst např. na https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS či https://blog.securityevaluators.com/websockets-not-bound-by-cors-does-this-mean-2e7819374acc

Ja CORS bez problemov ovladam a CORS je tam od toho aby sa spravne nastavil. Cize ak vasa aplikacia potrebuje pristupovat cross domenovo tak si spravne nastavte CORS na servri. Vymyslat koli tomu nejake aplikacne obkluky lebo neviem nastavit CORS sa mi zda nezmyselne.

Websocket v kazdem pripade neni jen zpusob, jak obejit CORS, to je jen vedlejsi efekt. Websocket je tady kvuli tomu, aby se dala prenaset data obema smery bez toho, aby se musel delat kazdy smer jinym zpusobem a aby to bylo efektivni.
Websocket se hodi zejmena na aplikace typu emulator terminalu ve web strance = zmacknes tlacitko a to se posle na server, naopak kdyz server dostane nejaka data, posle ti je v realnem case do webove stranky.
Presne pro takovou aplikaci jsem ho potreboval. Driv jsem jednou delal podobnou aplikaci pres ajax, byl to porod.

Ved to ja vsetko chapem, ja to denne pouzivam len by som sa rad vratil na zaciatok diskusie. Vase tvrdenie z clanku nie je pravdive. CORS je bezpecnostny mechanizmus ktory je tu od toho aby sa nastavoval. CORS nicomu nebrani iba je by default bezpecny a da sa nastavit podla potreby.

Na webhostingu s tim muze byt problem, tj. websockets na vyhrazenem portu nemusi povolit.

WebSocket (wss://) může běžet třeba i na portu 443 a pak to projde téměř všude. Častější problém je, že běžné webshostingy nepovolí běh aplikací, které neustále naslouchají a odbavují WS komunikaci.

Díky moc za skvělý článek.

> Web server totiž bude komunikovat s tímto démonem přes rozhraní loopback. > To ovšem není pouze adresa 127.0.0.1, loopback je celá síť 127.0.0.0/8, takže i adresy 127.0.0.2, 127.0.0.3 až do 127.255.255.254.

U IPv6 je to pouze jedna localhost IP ::1/128 = ::1 = 0:0:0:0:0:0:0:1.

To je pravda. To byl v pripade ipv6 krok dozadu. Nezbude, nez v takovem extremnim pripade nahodit loopback pres ipv4 a pouzivat ten.
On je to tedy priklad dost pritazeny za vlasy, i v pripade velkeho serveru obsluhujiciho tisice domen by melo bohate stacit tech 64k portu na jedinem loopbacku. Maloktera domena bude pouzivat vic jak 1 websocket, spis bude vetsina takovych, ktere nebudou pouzivat zadny websocket. 10000 volnych portu se na loopbacku najde.

Jeden localhost je možná málo, naproti tomu 16 777 214 localhostů je zase druhý extrém.
Dodnes nechápu, proč 1/255 celého adresního prostoru vyhradili pro localhost.

To bych jeste dokazal pochopit. V dobe, kdy se to standardizovalo, bylo k dispozici 4G adres, coz bylo v te dobe srovnatelne s poctem lidi na Zemi. Naopak, pokud si v te dobe predstavovali, ze by mohli potrebovat pro kazde spojeni jeden virtualni server (at uz si pod tim predstavovali co chteli), ktery by potreboval jednu adresu loopbacku, 256 loopbacku by rozhodne bylo malo. 64k sice vypada jako dost vysoke cislo ale dokazu si snadno predstavit 100000 soucasnych spojeni. Dalsi step uz je tech 16M loopbacku.
Praxe ukazala, ze 256 loopbacku by nejspis stacilo na cokoliv. Ovsem to, ze ipv6 ma jen jeden loopback, to si myslim, ze byla chyba. S loopbackem na jine, nez klasicke adrese 127.0.0.1 se setkavame casteji, nez si mnoho lidi predstavuje. Napriklad nameserver v Ubuntu (a mnoha jinych distribucich) posloucha na 127.0.0.53 port 53.

A nebo neřešit nesmysly s IPv4 a použít buď další porty (pokud se budete pokoušet spustit na počítači 60 tisíc serverů, budete mít jiné problémy, než počet portů), nebo další link-local adresy, nebo ULA adresy.

Alebo proste obist sietovu vrstvu a pouzit unix domain socket, kedze je to na localhoste...

10. 11. 2022, 21:26 editováno autorem komentáře

Pri použití IPv6 ale tie ďalšie loopbacky nepotrebujem - mám dostatok normálnych adries a tak keď mi nebudú stačiť voľné porty, tak si assignujem inú IP. Má to ešte aj výhodu, že v prípade nárastu služby to jednoducho môžem presunúť na iný server. Či mi niečo uniká?

Pri použití IPv6 ale tie ďalšie loopbacky nepotrebujem - mám dostatok normálnych adries a tak keď mi nebudú stačiť voľné porty, tak si assignujem inú IP.
Zbytocne komplikacie naviac (sietovanie, firewall, etc.)
Má to ešte aj výhodu, že v prípade nárastu služby to jednoducho môžem presunúť na iný server. Či mi niečo uniká?
Za ProxyPass moze byt cesta k socketu, ip, uri... ten presun na iny server s pouzitim ipv6 nijak nesuvisi...

Moc pekne oba clanky.
Stavim ted aplikaci, co bude prijimat aktualizace dat a premyslim, zda neustale tukat do serveru treba z tisicovky aplikaci, nebo to mit pres websocket.
Zas nechci aby to upeklo server, potazmo VPSku.
Ty data se muzou menit co 1-5 sekundy.
Aktulne je to reseno Getem. Data se tak daji hodit do cache.

WebSocket riesi komunikaciu zo servera do browsera. Ak potrebujete komunikovat z browsera do servera tak to mozete robit aj cez normalne GETy. Pouzite fetch() a nastavte na nom keepalive.

WebSocket neřeší jen, nebo primárně, komunikaci ze serveru do klienta. WS je full-duplex, tzn. může přijímat i odesílat data současně (v obou směrech, klient-server i server-klient). AJAX, fetch() atp. nejsou full-duplex.

Pomocí AJAXu, fetch() a pod. nevyřešíte elegantně (bez dostatečného výkonu) třeba problematiku chatu, kdy u fetch() a současně připojených 1000+ klientech pořádně zahřejete server. Při WebSocketu se klienti připojí a jen čekají na zprávu, nenavazují co pár sekund nové spojení, které je oproti udržení otevřeného spojení mnohonásobně náročnější na výkon.

Další malý příklad, který pomocí AJAXu, fetche a pod. nelze elegantně realizovat, je přáce s GPS mnoha klientů v reálném čase. Sledují se třeba body a rádius kolem nich, zda se do daného prostoru nedostal další klient. V okamžiku, kdy to nastane, odesílají se v reálném čase zprávy ostatním klientům, kteří jsou v dané zóně (rádiusu kolem bodu).

Je hodně řešení, která díky WebSocketům neupečou server a mohou fungovat s mnoha tisíci klienty v reálném čase. AJAX a pod. bude vždy náročnější na výkon serveru, nebo podstatně pomalejší, nez WS.

11. 11. 2022, 10:52 editováno autorem komentáře

Proc by mel byt long polling radove narocnejsi nez websickety? Jedno spojeni na klienta jako jedno spojeni na klienta.

Ono v případě jednoho spojení a jedné zprávy rozdíly mezi long polling a WS v podstatě nebudou. Obojí proběhne navázáním spojení, odesláním dat, čekáním a přijetím odpovědi, když je.

Rozdíl ve výkonu přijde v okamžiku, kdy se musí posílat více zpráv, resp. v okamžiku, kdy se musí ukončit stávající a navázat nové spojení.

WebSocket díky jednomu spojení dovede odbourat opakovaná připojování, která jsou na celé komunikaci nejnáročnější. V případě posílání bajtových (stavových a pod.) hodnot dělá obsluha spojení 99% přenesených dat a spotřebovaného výkonu.

Tyhle zátěže se samozřejmě neprojeví na malém počtu připojených klientů, s pár požadavky za hodinu, ale až v řádech vyšších stovek, tisíců atp.. Je pak i otázka, co naslouchá a zpracovává data na serveru, ale to už je jiný příběh.

Budu na to muset udelat nejaky test zateze. Komunikace z 99% bude server->client. Server bude posilat aktualizovana data.
Clientu muze byt najednou 1000-10000.
Aktualne si to client aktualizuje co 5 sekund Getem. Server to moc nezere, ale je tam zatim slaby 10% provoz.

Clovece ja som pisal asynchronne aplikacie ktore online updatovali stav na burze cez Tibco rendezvous pred 20 rokmi. Dakujem za vase rady :-D.

Omlouvám se, ale nebylo to z příspěvků vůbec poznat, ba naopak. :)

Jak souvisí použití specializované messaging technologie s možnostmi Websocket vs. Ajax? Mně ten komentář přijde zcela relevantní.

Záleží na směru. Pokud ta data posíláte jen z klienta na server, tam vám WebSocket asi moc nepomůže (leda byste měřil i počet přenesených bajtů, ale je otázka, zda se s HTTP/2 nedostanete na stejná čísla). Pokud jde o opačný směr (ze serveru na klienta), k takovému typu komunikace je právě WebSocket určen – místo aby se klient co pět vteřin nebo dokonce vteřinu ptal serveru, zda je něco nového, server mu přes WebSocket pošle zprávu pokaždé, když se něco změní. Záleží ale také na frekvenci změn, pokud prakticky při každém požadavku klienta dostane nějaký seznam změn, pak může dávat smysl se jenom pravidelně ptát, protože pak dostáváte data po dávkách, což obvykle bude efektivnější.

Na tohle by se nejlepe hodilo SSE. Neni slozite ho nastavit a bude delat presne co potrebujes. WS by se na to sice hodil take, ale pokud potrebujes data predevsim ve smeru server->browser, nestalo by za to setupovat cely cirkus kolem WS.

Diky, ono to ted vypada, ze zkusim SSE. Celkem se mi zalibila moznost, ze client si vyzada vysledky a relace zustane otevrena a bude dostavat aktualizace, ktere uz nebudou nijak velke.
Kdyz se spojeni rozpoji, tak holt si klient zavola znova.

rad bych se dozvedel, jak to u WebSocketu udelat podobne, jako u servru, ktery je rizen pres xinetd - na serveru tedy posloucha na jedinem portu 'nejaky' xinetd a skutecny demon, ktery odpovida na dotazy je bezny server , ktery pres descriptor (kanal) 0 cte a pres kanal 1 odpovida.
Takovy 'websocket-xinetd' sice existuje (= websocketd) napsany v go, ale vubec nikd neni popsano jak to skutecne udelat a napsat podobne napr. v C.
Stale cekam, kdy ten xinetd nekdo rozsiri i o tu websocket komunikaci, protoze ten websocketd posila za kazdou zpravou '\n' , coz se musi u stavajiciho softwaru odfiltrovat :-(

Jenom poznamka, Spring podporuje Websocket primo jako modul, pak netreba vyrabet selmostroje s apache proxy odkazujici na Python udelator, vsecko sedi v jednom JARu

Tady je exampl s vyuzitim STOMP message protokolu

https://spring.io/guides/gs/messaging-stomp-websocket/