Les websockets html5 seront-ils paralysés par les pare-feu?
Je suis extrêmement enthousiasmé par les spécifications Websockets de html5 mais j'ai une préoccupation.
De nos jours, tout le monde fonctionne à partir d'un réseau, avec des routeurs (câblés/sans fil) qui ont des pare-feu intégrés, Windows a également un pare-feu intégré.
Dans cet esprit, lorsque le serveur tente de se reconnecter au navigateur qui a démarré la prise de contact Websocket, échouera-t-il pour la grande majorité des utilisateurs? (la plupart des gens ne savent pas comment configurer la redirection de port sur leurs routeurs)
Ou ma pensée est-elle incorrecte et cela se passera bien?
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.
Les WebSockets HTML 5 ne nécessitent pas de redirection de port. Les connexions continuent d'être établies à partir du client, mais l'asymétrie client et serveur disparaît une fois la connexion établie. Les WebSockets perforent également les proxys en utilisant le même mécanisme CONNECT que HTTPS utilise aujourd'hui.
Étant donné que les pare-feu appliquent généralement simplement les règles de rejet du trafic entrant et de routage du trafic sortant (généralement via le serveur proxy), il n'y a généralement aucun problème de pare-feu lié au trafic WebSocket spécifique.
Les serveurs proxy (et dans une certaine mesure, certains routeurs d'équilibrage de charge) sont une autre affaire (Voir Pourquoi les implémentations actuelles du client websocket ne prennent-elles pas en charge les proxys? )