WebSocket: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti. |
Nessun oggetto della modifica Etichette: Modifica da mobile Modifica da web per mobile |
||
| (2 versioni intermedie di 2 utenti non mostrate) | |||
Riga 1:
'''WebSocket''' è
WebSocket è progettato per essere implementato sia lato [[browser]] che [[lato server]], ma può essere utilizzato anche da qualsiasi applicazione client-server. Il protocollo è un'implementazione basata sul protocollo TCP. La sua unica correlazione con l'HTTP è nel modo in cui fa l'[[handshake]] durante una Upgrade request tra server. Il protocollo WebSocket permette maggiore interazione tra un browser e un server, facilitando la realizzazione di applicazioni che forniscono contenuti e giochi in tempo reale. Questo è reso possibile fornendo un modo standard per il server di mandare contenuti al browser senza dover essere sollecitato dal client e permettendo ai messaggi di andare e venire tenendo la connessione aperta.
Riga 18:
|-
![https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 hixie-75]
|4
|
|
Riga 28:
|-
![https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 hixie-76][https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00 hybi-00]
|6
2010
23
|
|4.0 (disabilitato)
Riga 40:
|-
![https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07 hybi-07], v7
|22
|
|6<ref>{{Cita web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003|titolo=Bug 640003 - WebSockets - upgrade to ietf-06|editore=Mozilla Foundation|data=8 marzo 2011|accesso=10 dicembre 2011}}</ref>
Riga 50:
|-
![https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 hybi-10], v8
|11
|
|7<ref>{{Cita web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003#c91|titolo=Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)|editore=Mozilla Foundation|data=22 luglio 2011}}</ref>
Riga 113:
== Implementazione del server web ==
[[Nginx]] supporta WebSocket dal 2013, implementato nella versione 1.3.13 inclusa la funzione di proxy inverso e bilanciamento del carico delle applicazioni WebSocket<ref>{{Cita web|url=https://www.nginx.com/blog/websocket-nginx/|titolo=Using NGINX as a WebSocket Proxy|data=17 maggio 2014|sito=NGINX}}</ref>.
[[Apache HTTP Server]] supporta WebSocket da luglio 2013, implementato nella versione 2.4.5<ref>{{Cita web|url=http://httpd.apache.org/docs/trunk/new_features_2_4.html|titolo=Overview of new features in Apache HTTP Server 2.4|sito=Apache}}</ref><ref>{{Cita web|url=https://www.apachelounge.com/Changelog-2.4.html|titolo=Changelog Apache 2.4|sito=Apache Lounge}}</ref>.
[[Internet Information Services]] ha aggiunto il supporto per WebSocket nella versione 8 che è stata rilasciata con [[Windows Server]] 2012<ref>{{Cita web|url=https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support|titolo=IIS 8.0 WebSocket Protocol Support|data=28 novembre 2012|opera=Microsoft Docs|accesso=18 febbraio 2020}}</ref>.
[[Lighttpd]] supporta WebSocket dal 2017, implementato nella versione 1.4.46.<ref>[https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_46]</ref> lighttpd mod_proxy può fungere da proxy inverso e bilanciatore del carico delle applicazioni WebSocket. lighttpd mod_wstunnel può facilitare un tunnel WebSocket, consentendo a un client di utilizzare WebSocket per eseguire il tunneling di un protocollo più semplice, come [[JavaScript Object Notation|JSON,]] a un'applicazione di backend.
Riga 129:
Sebbene il protocollo WebSocket stesso non sia a conoscenza dei server proxy e dei firewall, presenta un handshake compatibile con HTTP che consente ai server HTTP di condividere le loro porte HTTP e HTTPS predefinite (443 e 80) con un gateway o un server WebSocket. Il protocollo WebSocket definisce un prefisso ws: // e wss: // per indicare rispettivamente una connessione WebSocket e WebSocket Secure. Entrambi gli schemi utilizzano un meccanismo di aggiornamento HTTP per eseguire l'aggiornamento al protocollo WebSocket. Alcuni server proxy sono trasparenti e funzionano bene con WebSocket; altri impediranno a WebSocket di funzionare correttamente, causando il fallimento della connessione. In alcuni casi, potrebbe essere necessaria una configurazione aggiuntiva del server proxy e alcuni server proxy potrebbero dover essere aggiornati per supportare WebSocket.
Se il traffico WebSocket non crittografato passa attraverso un server proxy esplicito o trasparente senza il supporto di WebSocket, è probabile che la connessione non riesca<ref>{{Cita web|url=http://www.infoq.com/articles/Web-Sockets-Proxy-Servers|titolo=How HTML5 Web Sockets Interact With Proxy Servers|sito=Infoq.com|data=16 marzo 2010|editore=C4Media Inc.|autore=Peter Lubbers|accesso=10 dicembre 2011}}</ref>.
Se viene utilizzata una connessione WebSocket crittografata, l'utilizzo di [[Transport Layer Security]] (TLS) nella connessione WebSocket Secure garantisce che un comando HTTP CONNECT venga emesso quando il browser è configurato per utilizzare un server proxy esplicito. Questo imposta un tunnel, che fornisce comunicazioni TCP end-to-end di basso livello attraverso il proxy HTTP, tra il client WebSocket Secure e il server WebSocket. Nel caso di server proxy trasparenti, il browser non è a conoscenza del server proxy, quindi non viene inviato alcun CONNECT HTTP. Tuttavia, poiché il traffico cablato è crittografato, i server proxy trasparenti intermedi possono semplicemente consentire il passaggio del traffico crittografato, quindi è molto più probabile che la connessione WebSocket riesca se viene utilizzato WebSocket Secure. L'utilizzo della crittografia non è privo di costi in termini di risorse, ma spesso fornisce la più alta percentuale di successo poiché viaggerebbe attraverso un tunnel sicuro.
Riga 145:
{{Browser Internet}}
{{Interfacce web}}
{{Portale|internet|telematica}}
| |||