WebSocket: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Correggo wikilink secondo Aiuto:Wikilink#Specificità dei collegamenti, replaced: lato server → lato server using AWB |
Aggiornamento della voce |
||
Riga 5:
WebSocket è disegnato 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.
In aggiunta, le comunicazioni sono fatte attraverso la porta TCP 80, che è un vantaggio per gli ambienti che bloccano porte non standard utilizzando dei [[firewall]]. Il protocollo WebSocket è supportato
== Implementazione del browser ==
{| class="wikitable"
!Protocollo, versione
!Data del progetto
!Internet Explorer
!Firefox<ref>{{cite web|url=https://developer.mozilla.org/en/WebSockets|title=WebSockets (support in Firefox)|publisher=Mozilla Foundation|website=developer.mozilla.org|date=2011-09-30|access-date=2011-12-10}}</ref> (PC)
!Firefox (Android)
!Chrome (PC, Mobile)
!Safari (Mac, iOS)
!Opera (PC, Mobile)
!Android Browser
|-
![https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 hixie-75]
|4 Febbraio, 2010
|
|
|
|4
|5.0.0
|
|
|-
![https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 hixie-76][https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00 hybi-00]
|6 Maggio
2010
23 Maggio 2010
|
|4.0 (disabilitato)
|
|6
|5.0.1
|11.00 (disabilitato)
|
|-
![https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07 hybi-07], v7
|22 Aprile 2011
|
|6<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003|title=Bug 640003 - WebSockets - upgrade to ietf-06|publisher=Mozilla Foundation|date=2011-03-08|access-date=2011-12-10}}</ref>{{Efn|Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",<ref>{{cite web|url=https://developer.mozilla.org/en/WebSockets |title=WebSockets - MDN |website=developer.mozilla.org |publisher=Mozilla Foundation |date=2011-09-30 |access-date=2011-12-10}}</ref> requiring extra code to integrate with existing WebSocket-enabled code.|name="mozwebsocket"}}
|
|
|
|
|
|-
![https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 hybi-10], v8
|11 Luglio 2011
|
|7<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=640003#c91|title=Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)|publisher=Mozilla Foundation|date=2011-07-22}}</ref>{{Efn|name="mozwebsocket"}}
|7
|14<ref>{{cite web|url=https://code.google.com/p/chromium/issues/detail?id=64470|title=Chromium bug 64470|website=code.google.com|date=2010-11-25|access-date=2011-12-10}}</ref>
|
|
|
|-
!{{IETF RFC|6455}}, v13
|Dicembre
2011
|10<ref>{{cite web|url=https://blogs.msdn.com/b/ie/archive/2012/03/19/websockets-in-windows-consumer-preview.aspx|title=WebSockets in Windows Consumer Preview|publisher=Microsoft|work=IE Engineering Team|date=2012-03-19|access-date=2012-07-23}}</ref>
|11
|11
|16<ref>{{cite web|url=https://trac.webkit.org/changeset/97249|title=WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17|website=trac.webkit.org|access-date=2011-12-10}}</ref>
|6
|12.10<ref>{{cite web|url=http://my.opera.com/ODIN/blog/2012/08/03/a-hot-opera-12-50-summer-time-snapshot|title=A hot Opera 12.50 summer-time snapshot|publisher=Opera Developer News|date=2012-08-03|access-date=2012-08-03|archive-url=https://web.archive.org/web/20120805234006/http://my.opera.com/ODIN/blog/2012/08/03/a-hot-opera-12-50-summer-time-snapshot|archive-date=2012-08-05}}</ref>
|4.4
|}
== Handshake del protocollo ==
Per stabilire una connessione Websocket, il client invia una richiesta di [[handshake]] ed il server invia una risposta come indicato nell'esempio<ref>{{Cite IETF|title=RFC 6455 The WebSocket Protocol|publisher=[[Internet Engineering Task Force|IETF]]|section=1.2|sectionname=Protocol Overview|rfc=6455|date=December 2011|author1=Ian Fette|author2=Alexey Melnikov}}</ref>.
Richiesta del client:
Line 41 ⟶ 107:
* <code>x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code> codificata con SHA-1 restituisce il valore esadecimale <code>0x1d29ab734b0c9585240069a6e4e3e91b61da1969</code>.
* Codificando questa stringa con base64 si ottiene il codice <code>HSmrc0sMlYUkAGmm5OPpG2HaGWk=</code>, che è il valore inserito nella risposta.
Quando viene stabilita la connessione, il client ed il server possono inviare dati tramite il Websocket in entrambe le direzioni<ref>{{cite web|url=https://trac.tools.ietf.org/wg/hybi/trac/wiki/FAQ|title=Main Goal of WebSocket protocol|publisher=IETF|access-date=25 July 2015|quote=The computation [...] is meant to prevent a caching intermediary from providing a WS-client with a cached WS-server reply without actual interaction with the WS-server.}}</ref><ref>{{Cite IETF|title=RFC 6455 The WebSocket Protocol|page=8|publisher=[[Internet Engineering Task Force|IETF]]|section=1.3|sectionname=Opening Handshake|rfc=6455|date=December 2011|author1=Ian Fette|author2=Alexey Melnikov}}</ref><ref>{{Cite IETF|title=RFC 6455 The WebSocket Protocol|publisher=[[Internet Engineering Task Force|IETF]]|section=5.2|sectionname=Base Framing Protocol|rfc=6455|date=December 2011|author1=Ian Fette|author2=Alexey Melnikov}}</ref><ref>{{cite IETF|draft=draft-ietf-hybi-websocket-multiplexing|title=A Multiplexing Extension for WebSockets|author1=John A. Tamplin|author2=Takeshi Yoshino|publisher=[[Internet Engineering Task Force|IETF]]|year=2013}}</ref>.
== Estensioni sperimentali ==
Line 48 ⟶ 114:
== Sviluppo ==
Utilizzando il Google Chrome Developer Tools, lo sviluppatore può controllare l'handshake ed i pacchetti che vengono scambiati nel canale.<ref>{{Cita libro |cognome=Wang |nome=Vanessa |cognome2=Salim |nome2=Frank |cognome3=Moskovits |nome3=Peter |titolo=The Definitive Guide to HTML5 WebSocket |url=http://my.safaribooksonline.com/book/-/9781430247401/appendix-a-inspecting-websocket-traffic/sec1_xhtml |datadiaccesso=7 aprile 2013 |anno=2013 |mese=febbraio |editore=Apress |capitolo=APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools |isbn=978-1-4302-4740-1 |urlmorto=sì |accesso=19 luglio 2013 |urlarchivio=https://web.archive.org/web/20151231184436/http://my.safaribooksonline.com/book/-/9781430247401/appendix-a-inspecting-websocket-traffic/sec1_xhtml |dataarchivio=31 dicembre 2015 }}</ref>
== 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>{{Cite web|url=https://www.nginx.com/blog/websocket-nginx/|title=Using NGINX as a WebSocket Proxy|date=May 17, 2014|website=NGINX}}</ref>.
[[Apache HTTP Server]] supporta WebSocket da luglio 2013, implementato nella versione 2.4.5<ref>{{Cite web|url=http://httpd.apache.org/docs/trunk/new_features_2_4.html|title=Overview of new features in Apache HTTP Server 2.4|website=Apache}}</ref><ref>{{Cite web|url=https://www.apachelounge.com/Changelog-2.4.html|title=Changelog Apache 2.4|website=Apache Lounge}}</ref>.
[[Internet Information Services]] ha aggiunto il supporto per WebSocket nella versione 8 che è stata rilasciata con Windows Server 2012<ref>{{cite web|url=https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support|title=IIS 8.0 WebSocket Protocol Support|date=28 November 2012|work=Microsoft Docs|access-date=2020-02-18}}</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.
== Considerazioni sulla sicurezza ==
A differenza delle normali richieste HTTP tra domini, le richieste WebSocket non sono limitate dalla politica della stessa origine. Pertanto i server WebSocket devono convalidare l'intestazione "Origin" rispetto alle origini previste durante la creazione della connessione, per evitare attacchi di dirottamento WebSocket tra siti (simili alla contraffazione di richieste tra siti ), che potrebbero essere possibili quando la connessione è autenticata con cookie o autenticazione [[Hypertext Transfer Protocol|HTTP]]. È preferibile utilizzare token o meccanismi di protezione simili per autenticare la connessione WebSocket quando vengono trasferiti dati sensibili (privati) su WebSocket<ref>{{cite web|url=https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html#main|title=Cross-Site WebSocket Hijacking (CSWSH)|author=Christian Schneider|work=Web Application Security Blog|date=August 31, 2013}}</ref>. Un esempio dal vivo di vulnerabilità è stato visto nel 2020 sotto forma di Cable Haunt.
== Attraversamento proxy ==
Le implementazioni del client del protocollo WebSocket tentano di rilevare se l' agente utente è configurato per utilizzare un proxy durante la connessione all'host e alla porta di destinazione e, in tal caso, utilizza il metodo HTTP CONNECT per impostare un tunnel persistente.
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>{{cite web|url=http://www.infoq.com/articles/Web-Sockets-Proxy-Servers|title=How HTML5 Web Sockets Interact With Proxy Servers|website=Infoq.com|date=March 16, 2010|publisher=C4Media Inc.|author=Peter Lubbers|access-date=2011-12-10}}</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.
Una bozza di metà 2010 (versione hixie-76) ha rotto la compatibilità con proxy inversi e gateway includendo otto byte di dati chiave dopo le intestazioni, ma non pubblicizzando tali dati in un'intestazione<code>Content-Length: 8</code><ref>{{cite web|url=https://www.ietf.org/mail-archive/web/hybi/current/msg02149.html|title=WebSocket -76 is incompatible with HTTP reverse proxies|website=ietf.org|publisher=Internet Engineering Task Force|date=2010-07-06|access-date=2011-12-10|author=Willy Tarreau|type=email}}</ref>. Questi dati non sono stati inoltrati da tutti gli intermedi, il che potrebbe portare al fallimento del protocollo. Le bozze più recenti (ad esempio, hybi-09<ref>{{cite IETF|url=https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.4|title=The WebSocket protocol, draft hybi-09|sectionname=Sec-WebSocket-Key|section=11.4|date=June 13, 2011|access-date=June 15, 2011|author=Ian Fette}}</ref>) inseriscono i dati chiave in <code>Sec-WebSocket-Key</code>un'intestazione, risolvendo questo problema.
== Voci correlate ==
| |||