1. casa
  2. Domanda e risposta
  3. Perché le attuali implementazioni del client Websocket non supportano i proxy?

Perché le attuali implementazioni del client Websocket non supportano i proxy?

2010-02-04 9 views
27

Un Web Socket rileva la presenza di un server proxy e imposta automaticamente un tunnel per il passaggio attraverso il proxy. Il tunnel viene stabilito emettendo un'istruzione HTTP CONNECT sul server proxy, che richiede al server proxy di aprire una connessione TCP/IP a un host e una porta specifici. Una volta impostato il tunnel, la comunicazione può scorrere senza impedimenti attraverso il proxy. Poiché HTTP/S funziona in modo simile, i Web Socket protetti via SSL possono sfruttare la stessa tecnica HTTP CONNECT. [1]Perché le attuali implementazioni del client Websocket non supportano i proxy?

OK, sembra utile! Ma, nelle implementazioni client che ho visto finora (Go [2], Java [3]) non vedo nulla relativo al rilevamento dei proxy.

Mi manca qualcosa o queste implementazioni sono solo giovani? So che WebSockets è estremamente nuovo e le implementazioni client potrebbero essere ugualmente giovani e immature. Voglio solo sapere se mi manca qualcosa sul rilevamento e la gestione dei proxy.

[1] http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

[2] http://golang.org/src/pkg/websocket/client.go

[3] http://github.com/adamac/Java-WebSocket-client/raw/master/src/com/sixfire/websocket/WebSocket.java

fonte

2010-02-04 z8000

+2

Non lo fanno? Aaargghh! e ho continuato a chiedermi perché il mio codice non ha funzionato! Ho perso un'intera mattinata ma ora sembra funzionare perché ho rimosso il proxy. Grazie per aver chiesto questa domanda! – Tieme

+0

@Tieme dimostra che le domande sono altrettanto importanti delle risposte –

+0

In effetti lo fanno! – Tieme

risposta

1

La risposta è che questi client semplicemente non supportano i proxy. -Occam

fonte

2010-02-19 04:36:33 z8000

+1

Beh, la risposta è che viene richiesto un CONNECT HTTP Una connessione con istruzione HTTP CONNECT assomiglia a una connessione TCP di base al client quindi invia l'handshake Websocket AFTERWARDS, che invia due richieste HTTP per un handshake Websocket: uno per il proxy, uno per il server websocket. – sinni800

0

Il canale di comunicazione è già stabilito dal momento in cui il protocollo WebSocket entra in scena. Il WebSocket è costruito su TCP e HTTP, quindi non devi preoccuparti delle cose già fatte da questi protocolli, inclusi i proxy.

Quando viene stabilita una connessione WebSocket, inizia sempre con una connessione HTTP/TCP che viene successivamente "aggiornata" durante la fase di "handshake" di WebSocket. In questo momento il tunnel è stabilito in modo che i proxy siano trasparenti, non è necessario preoccuparsene.

fonte

2010-02-04 21:35:53 Tihauan

+0

Quindi cosa si connette quindi all'Http? – z8000

+2

@ z8000 HTTP CONNECT stabilisce una connessione HTTP. È una normale richiesta GET che, se il server supporta il protocollo WebSochet, viene aggiornata in seguito. Il protocollo WebSocket utilizza HTTP per negoziare la connessione e, come suggerito, per evitare i proxy. – Tihauan

+1

_WHAT_ HTTP CONNECT? Non ciò che _IS_ un CONNECT HTTP? Secondo Wikipedia: "Un altro metodo di tunneling basato su HTTP utilizza il metodo/comando HTTP CONNECT. Un client invia il comando HTTP CONNECT a un proxy HTTP. Il proxy crea quindi una connessione TCP a un server particolare: porta e trasmette i dati tra quel server: porta e la connessione client. " Non vedo nulla nei client WebSocket che comunicano con un proxy tramite HTTP CONNECT. Considerare CURLOPT_PROXY nell'API libcurl, ad esempio. – z8000

41

Lasciami provare a spiegare le diverse percentuali di successo che potresti aver riscontrato. Sebbene il protocollo HTML5 Web Socket non sia consapevole dei server proxy e dei firewall, presenta un handshake compatibile con HTTP in modo che i server HTTP possano condividere le porte HTTP e HTTPS predefinite (80 e 443) con un gateway o server Web Sockets.

Il protocollo Web Socket definisce un prefisso ws: // e wss: // per indicare rispettivamente una connessione WebSocket e una connessione WebSocket Secure. Entrambi gli schemi utilizzano un meccanismo di aggiornamento HTTP per l'aggiornamento al protocollo Web Socket. Alcuni server proxy sono innocui e funzionano bene con Web Sockets; altri impediranno il corretto funzionamento dei Web Sockets, 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 Web Sockets.

Se il traffico WebSocket in chiaro scorre attraverso un esplicito o un server proxy trasparente sulla sua strada il server WebSocket, quindi, se il server proxy si comporta come dovrebbe, il collegamento è quasi certamente destinato a fallire oggi (in futuro , i server proxy possono diventare consapevoli di Web Socket). Pertanto, le connessioni WebSocket non crittografate devono essere utilizzate solo nelle topologie più semplici.

Se viene utilizzata la connessione WebSocket crittografata, l'utilizzo di Transport Layer Security (TLS) nella connessione Web Sockets Secure assicura che venga emesso un comando HTTP CONNECT quando il browser è configurato per utilizzare un server proxy esplicito. Questo imposta un tunnel che fornisce comunicazione TCP end-to-end di basso livello attraverso il proxy HTTP, tra il client Web Sockets Secure e il server WebSocket. Nel caso di server proxy trasparenti, il browser non è al corrente del server proxy, quindi non viene inviato alcun CONNECT HTTP.Tuttavia, poiché il traffico del wire è crittografato, i server proxy trasparenti intermedi possono semplicemente consentire il traffico crittografato, quindi ci sono molte più possibilità che la connessione WebSocket abbia successo se si utilizza Web Sockets Secure. L'uso della crittografia, ovviamente, non è gratuito, ma spesso offre il più alto tasso di successo.

Un modo per vederlo in azione è scaricare e installare Kaazing WebSocket Gateway - un gateway WebSocket ottimizzato per proxy, che fornisce supporto WebSocket nativo e un'emulazione completa dello standard per i browser meno recenti.

fonte

2010-02-18 19:03:25

+0

Peter, grazie per il tuo commento.Ma è una specie di gonne intorno alla domanda. In un certo senso rispondi: i browser con configurazioni proxy esplicite emetteranno il CONNECT HTTP. La domanda riguarda i client WS in generale, non solo i browser. I pochi client che ho campionato non hanno alcun supporto proxy esplicito. Posso dedurre dalla tua risposta che spetta a tali clienti avere tale supporto (come farebbe un browser) e che semplicemente non sono implementati (ancora?). – z8000

+2

Mi dispiace aver frainteso la tua domanda - hai ragione, quei client non supportano i proxy. –

+1

Il 75% del tuo post è stato incollato sulla copia dall'articolo di Wikipedia. Si prega di imparare come usare le citazioni dei blocchi e citare le fonti. –

0

Per quanto riguarda i clienti websocket e proxy trasparenti, penso connessioni client websocket falliranno il più delle volte per i seguenti motivi (non testato):

  • Se la connessione è in chiaro, dal momento che il client non sa che sta comunicando con un server proxy http, non invierà l'istruzione "CONNECT TO" che trasforma il proxy http in un proxy tcp (necessario per il client dopo l'handshake websocket). Potrebbe funzionare se il proxy supporta nativamente websocket e gestisce l'URL con lo schema ws in modo diverso da http.

  • Se la connessione è in SSL, il proxy trasparente non può sapere a quale server deve connettersi poiché ha decrittografato il nome host nella richiesta https. Potrebbe generare un certificato autofirmato al volo (come per SSLStrip) o fornire il proprio certificato statico e decrittografare la comunicazione, ma se il client convalida il certificato del server fallirà (vedi https://serverfault.com/questions/369829/setting-up-a-transparent-ssl-proxy).

fonte

2013-04-04 02:30:26 user23724

 Problemi correlati

  • Nessun problema correlato^_^