Les websockets html5 seront-ils paralysés par les pare-feu?

Question

Je suis très enthousiaste à l'html5 websockets spec mais j'ai un soucis.

Ces jours-ci tout le monde est en exploitation hors d'un réseau, avec des routeurs (filaire/sans fil) qui ont construit en pare-feu, windows dispose d'un pare-feu intégré aussi.

Avec cela à l'esprit lorsque le serveur tente de se connecter au navigateur qui a commencé le protocole de transfert websocket il va échouer pour la grande majorité des utilisateurs? (la plupart des gens n'ont aucune idée de comment mettre en place la redirection de port sur leurs routeurs)

Ou est ma façon de penser erronée et il faudra passer par le bien?

Answer 1

Je ne suis pas un expert (veuillez vérifier pour confirmer) mais je pense qu'il y aura un mécanisme de MISE À NIVEAU où une connexion HTTP régulière peut être établie, puis mise à niveau vers un WebSocket, donc aucune règle de pare-feu existante n'interfère à moins qu'elles ne fassent un niveau d'application agressif inspection des paquets. Les connexions sont toujours initiées par le navigateur.

Answer 2

Les WebSockets HTML 5 ne nécessitent pas de redirection de port. Les connexions continuent d'être établies à partir du client, mais les rôles d'échange client et serveur une fois la connexion établie (TCP est un protocole symétrique après établissement). Les WebSockets perforent également les proxys en utilisant le même modèle CONNECT que HTTPS utilise aujourd'hui.

Answer 3

Depuis pare-feu généralement simplement appliquer les règles de trafic entrant rejet et de la circulation à la sortie de routage (généralement via le serveur proxy), il n'y a généralement pas de WebSocket liés au trafic de pare-feu préoccupations.

Serveurs Proxy (et dans une certaine mesure, certains d'équilibrage de la charge des routeurs ainsi) sont une autre affaire cependant (Voir http://stackoverflow.com/questions/2201317/why-dont-current-websocket-client-implementations-support-proxies/2291377#2291377)