Pourquoi ne pas l'actuel websocket de l'implémentation du client de support proxy?

Un Web Socket détecte la présence d'un serveur proxy et établit automatiquement un tunnel pour passer à travers le proxy. Le tunnel est établi par l'émission de un HTTP déclaration de connexion au serveur proxy, qui demande pour le serveur proxy pour ouvrir une connexion TCP/IP à un hôte spécifique et le port. Une fois que le tunnel est mis en place, la communication peut circuler librement à travers le proxy. Depuis HTTP/S fonctionne de manière similaire, secure Sockets Web sur SSL peuvent tirer parti de la même connexion HTTP technique. [1]

OK, des sons utiles! Mais, dans l'implémentation du client que j'ai vu jusqu'à présent (Aller à [2], Java [3]), je ne vois pas tout ce qui est lié à la détection des proxy.

Suis-je raté quelque chose ou sont ces implémentations seulement les jeunes? Je sais que les WebSockets est extrêmement nouveau et de l'implémentation du client peut être tout aussi jeune et immature. Je veux juste savoir si je suis absent quelque chose à propos de proxy détection et le traitement.

[1] http://www.kaazing.org/confluence/display/KAAZING/What+est+un+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

  • Ils ne le font pas? Aaargghh! et je me demandais pourquoi mon code n'a pas fonctionné! Perdu toute la matinée, mais maintenant il semble que cela fonctionne parce que j'ai enlevé le proxy. Merci de poser cette question!
  • la preuve que les questions sont tout aussi importantes que les réponses
InformationsquelleAutor z8000 | 2010-02-04
  1. 43

    Laissez-moi vous expliquer les différents taux de réussite que vous avez rencontrés. Alors que le Web HTML5 Socket protocole en lui-même n'est au courant de serveurs proxy et pare-feu, il dispose d'un HTTP-compatible poignée de main, de sorte que les serveurs HTTP peuvent partager par défaut des ports HTTP et HTTPS (80 et 443), avec un les Web Sockets de passerelle ou de serveur.

    Le Web Socket protocole définit un ws://et wss://préfixe pour indiquer un WebSocket et un WebSocket connexion Sécurisée, respectivement. Les deux régimes d'utiliser un HTTP mécanisme de mise à niveau pour mettre à niveau vers le Web Socket protocole. Certains serveurs proxy sont inoffensifs et fonctionne bien avec les Web Sockets, d'autres seront à éviter les Web Sockets de fonctionner correctement, provoquant l'échec de la connexion. Dans certains cas, d'autres de configuration du serveur proxy peut être nécessaire, et certains serveurs proxy peuvent avoir besoin d'être mis à niveau pour soutenir les Web Sockets.

    Si non chiffrés WebSocket des flux de trafic par le biais d'un explicite ou transparent proxy server sur son chemin le serveur WebSocket, alors, de savoir si ou non le serveur proxy se comporte comme il se doit, la connexion est presque certainement vouée à l'échec aujourd'hui (dans le futur, les serveurs proxy peuvent devenir Web Socket au courant). Donc, en clair WebSocket les connexions doivent être utilisés uniquement dans le plus simple des topologies.

    Si chiffré connexion WebSocket est utilisé, l'utilisation de TLS (Transport Layer Security) dans les Web Sockets Sécurisée connexion assure que une connexion HTTP commande est émise lorsque le navigateur est configuré pour utiliser un proxy explicite serveur. Cela met en place un tunnel, qui fournit à faible niveau de bout en bout, de la communication TCP à travers le proxy HTTP, entre les Web Sockets Sécurisés client et le serveur WebSocket. Dans le cas de transparence des serveurs proxy, le navigateur n'est pas au courant du serveur proxy, donc pas de connexion HTTP est envoyée. Cependant, depuis le fil de trafic est chiffré, intermédiaire transparent proxy serveurs permettent peut-être simplement le trafic chiffré, donc il y a une bien meilleure chance que la connexion WebSocket ne sera possible que si les Web Sockets Sécurisée est utilisée. À l'aide de cryptage, bien sûr, n'est pas libre, mais souvent fournit le plus haut taux de réussite.

    Un moyen de le voir en action, c'est de télécharger et d'installer le Kaazing WebSocket Passerelle--un très optimisé, proxy-conscient WebSocket gateway, qui fournit WebSocket natif de soutien ainsi qu'une émulation de la norme pour les anciens navigateurs.

    • Pierre, merci pour votre commentaire. Mais ce genre de jupes autour de la question. Vous sorte de répondre: les navigateurs de manière explicite les configurations de proxy sera question de la connexion HTTP. La question est sur WS clients en général et pas seulement les navigateurs. Les quelques clients que j'ai échantillonnées n'ont pas explicite support de proxy. Je peux déduire de votre réponse, que c'est à de tels clients d'avoir un tel soutien (comme un navigateur) et qu'ils sont tout simplement pas mis en œuvre (encore?).
    • Désolé j'ai mal compris votre question--vous avez raison, ces clients ne prennent pas en charge les procurations.
    • 75% de votre poste est de copier-collé de l'article de Wikipédia. S'il vous plaît apprendre comment utiliser le bloc de citations et de citer vos sources.
    • OUPS! J'ai regardé l'historique de la version de l'article de Wikipédia et vu que vous êtes la personne qui a contribué de ces paragraphes. Je suis tellement gênée. Toutes mes excuses. 🙁 Je suis de la restauration de mon montage. (Ici je suis, la flagellation vous pour ne pas en citant votre propre travail, lol)
    • Re", d'autres vont empêcher les Web Sockets de fonctionner correctement, provoquant l'échec de la connexion"; mais pourquoi?
    • Re "vouée à l'échec aujourd'hui", mais pourquoi serait-il un échec?

    InformationsquelleAutor Peter Lubbers
  2. 1

    Le canal de communication est déjà établie au moment où le protocole WebSocket rentre en scène. Le WebSocket est construit au-dessus de TCP et HTTP sorte que vous n'avez pas à vous préoccuper des choses déjà fait par ces protocoles, y compris les procurations.

    Lorsqu'une connexion WebSocket est établie, il commence toujours par HTTP/TCP connexion qui est plus tard "mis à jour" lors de la "poignée de main" phase de WebSocket. À cette époque, le tunnel est établi de sorte que les procurations sont transparentes, il n'y a pas besoin de se soucier d'eux.

    • Donc, quelle est la connexion http, alors?
    • Le HTTP CONNECT établit une connexion HTTP. Il est normal d'OBTENIR la demande qui, si le serveur prend en charge la WebSochet protocole, est mis à jour plus tard. Le protocole WebSocket utilise le protocole HTTP pour négocier la connexion et, comme vous l'avez suggéré, à contourner les proxys.
    • CE le HTTP CONNECTER? Pas de quoi EST HTTP CONNECTER? Selon Wikipedia: "un Autre HTTP tunneling méthode utilise le mode de connexion HTTP/commande. Un des problèmes du client HTTP commande de se CONNECTER à un proxy HTTP. Le proxy puis établit une connexion TCP vers un serveur particulier:port, et de relais de données entre le serveur:port et de la connexion du client." Je ne vois rien dans le WebSocket clients que d'en parler à un proxy via la connexion HTTP. Envisager CURLOPT_PROXY dans libcurl de l'API par exemple.
    InformationsquelleAutor Tihauan
  3. 1

    La réponse est que ces clients ne peuvent tout simplement pas en charge les serveurs proxy.
    -Occam

    • Eh bien la réponse est que d'une connexion HTTP est chargé. Une connexion HTTP chargé de connexion ressemble à une base connexion TCP vers le client afin qu'il envoie les Websocket poignée de main par la SUITE. Il envoie deux requêtes HTTP pour un Websocket poignée de main. Un pour le proxy, un pour le serveur websocket.
    InformationsquelleAutor z8000
  4. 0

    Concernant websocket clients et transparent proxy,
    Je pense que websocket client connexions échouent la plupart du temps pour les raisons suivantes (pas testé):

    • Si la connexion est évidente, car le client ne sait pas, il est en communication avec un serveur proxy http, il ne sera pas envoyer le "se CONNECTER À" l'instruction qui transforme le proxy http sur tcp proxy (nécessaires pour que le client après le websocket poignée de main). Il pourrait fonctionner si le proxy prend en charge nativement les websocket et gère l'URL avec le ws régime différemment http.

    • Si la connexion est en SSL, le proxy transparent ne peut pas savoir à quel serveur il doit se connecter depuis qu'il a déchiffrer le nom d'hôte dans la requête https. Il pourrait en générer un certificat auto-signé à la volée (comme pour SSLStrip) ou de fournir son propre statique de certificat et de décrypter la communication, mais si le client valide le certificat du serveur, ce sera un échec (voir https://serverfault.com/questions/369829/setting-up-a-transparent-ssl-proxy).

    InformationsquelleAutor user23724
  5. 0

    Vous avez mentionné les proxies Java, et pour répondre à ce que je voulais mentionner que Java-Websocket prend désormais en charge les procurations.

    Vous pouvez voir les informations à ce sujet ici: http://github.com/TooTallNate/Java-WebSocket/issues/88

    InformationsquelleAutor netdragon
  6. 0

    websocket-client, un paquet Python, supporte les proxys, à tout le moins plus sécurisé régime wss:// que dans ce cas de procuration doivent pas être conscient de la circulation vers l'avant.

    https://github.com/liris/websocket-client/commit/9f4cdb9ec982bfedb9270e883adab2e028bbd8e9

    InformationsquelleAutor Dima Tisnek