Dois-je utiliser WebSocket sur des ports autres que 80?
Dois-je utiliser WebSocket sur des ports non-80? Cela gâche-t-il l'utilisation des infrastructures Web/HTTP existantes? Et je pense que cela ne correspond plus au nom Web Socket sur des ports non-80.
Si j'utilise WebSocket sur d'autres ports, pourquoi ne pas simplement utiliser TCP directement? Ou y a-t-il des avantages particuliers dans le protocole WebSocket lui-même?
Et puisque la poignée de main WebSocket actuelle se présente sous la forme d’une demande HTTP UPGRADE, est-ce que cela signifie que je dois activer le protocole HTTP sur le port afin que la poignée de main WebSocket puisse être accomplie?
Dois-je utiliser WebSocket sur des ports non-80? Cela gâche-t-il l'utilisation des infrastructures Web/HTTP existantes? Et je pense que cela ne correspond plus au nom WebSocket sur des ports non-80.
Vous pouvez exécuter un serveur WebSocket sur n’importe quel port autorisé par votre SE hôte et auquel votre client sera autorisé à se connecter.
Toutefois, l’exécution sur le port 80 (ou 443) présente un certain nombre d’avantages.
L'infrastructure de réseau est généralement déjà déployée et ouverte sur le port 80 pour les connexions sortantes depuis les lieux de vie des clients (ordinateurs de bureau, appareils mobiles, etc.) jusqu'aux lieux de vie des serveurs (centres de données, par exemple). Ainsi, de nouveaux trous dans les configurations de pare-feu ou de routeur, etc., ne sont généralement pas nécessaires pour déployer une application webSocket sur le port 80. Des modifications de configuration peuvent être nécessaires pour s'exécuter sur différents ports. Par exemple, de nombreux réseaux d'entreprise de grande taille sont très pointilleux sur les ports sur lesquels les connexions sortantes peuvent être effectuées et sont configurés uniquement pour certains comportements standard et attendus. La sélection d'un port non standard pour une connexion webSocket peut ne pas être autorisée à partir de certains réseaux d'entreprise. C'est la GRANDE raison d'utiliser le port 80 (interopérabilité maximale des réseaux privés disposant de configurations verrouillées).
De nombreuses applications webSocket exécutées à partir du navigateur souhaitent exploiter l'infrastructure de sécurité/connexion/autorisation existante déjà utilisée sur le port 80 pour la page Web de l'hôte. L'utilisation de cette même infrastructure pour vérifier l'authentification d'une connexion webSocket peut s'avérer plus simple si tout se trouve sur le même port.
Certaines infrastructures de serveur pour webSockets (telles que socket.io dans node.js) utilisent une infrastructure de serveur combinée (processus unique, un écouteur) pour prendre en charge les requêtes HTTP et webSockets. Ceci est plus simple si les deux sont sur le même port.
Si j'utilise WebSocket sur d'autres ports, pourquoi ne pas simplement utiliser TCP directement? Ou y a-t-il des avantages particuliers dans le protocole WebSocket lui-même?
Le protocole webSocket a été défini à l'origine pour fonctionner d'un navigateur à un serveur. Il n’existe pas d’accès générique TCP à partir d’un navigateur. Par conséquent, si vous voulez un socket persistant sans add-ons de navigateur personnalisés, un webSocket est ce qui vous est proposé. Par rapport à un simple TCP connexion, le protocole webSocket offre la possibilité de tirer parti de l’authentification HTTP et des cookies, moyen standard de réaliser des ping/pong Keep-Alive au niveau des applications et de bout en bout (TCP offre une fonction Keep-Alive au niveau saut, mais pas de bout en bout), un protocole de trame intégré (vous devez concevoir vos propres formats de paquet en TCP) et un grand nombre de bibliothèques prenant en charge ces fonctionnalités de niveau supérieur. En gros, webSocket fonctionne à un niveau supérieur à = TCP (en utilisant TCP sous la couverture)) et offre davantage de fonctionnalités intégrées que la plupart des gens trouvent utiles. Par exemple, si vous utilisez TCP, l'une des premières choses vous devez obtenir ou concevoir un protocole (un moyen d’exprimer vos données), qui est déjà intégré à webSocket.
Et puisque la poignée de main WebSocket actuelle se présente sous la forme d’une demande HTTP UPGRADE, est-ce que cela signifie que je dois activer le protocole HTTP sur le port afin que la poignée de main WebSocket puisse être accomplie?
Vous DEVEZ disposer d'un serveur HTTP s'exécutant sur le port sur lequel vous souhaitez utiliser webSocket car toutes les requêtes webSocket commencent par une requête HTTP. Il ne serait pas nécessaire que ce soit un serveur HTTP lourd de fonctionnalités, mais il devait gérer la requête HTTP initiale.
À mon avis, oui, vous le pouvez. 80 est le port par défaut, mais vous pouvez le modifier à votre guise.