Configuration de la connexion Websocket

Question

J'essaie d'en savoir plus sur websocket et ses implémentations internes. Mais ne peut toujours pas comprendre peu de choses. J'ai essayé de googler pour une explication en profondeur, mais la plupart d'entre eux donne juste la vue d'ensemble de haut niveau. D'après ce que j'ai lu, le serveur socket Web (implémentation C#/C++) utilise par défaut le port 80. Bien que nous puissions utiliser n'importe quel port, il est préférable d'utiliser le port 80 comme nous l'avons gagné. N'avoir aucun problème de pare-feu. Si c'est le cas, comment sommes-nous supposés exécuter le serveur Web et le serveur de socket Web sur le même port (80)?

2. Supposons que le serveur socket Web est en cours d'exécution sur le port 81 et serveur Web est en cours d'exécution sur le port 80.

1. Ainsi, lorsque le navigateur émet la requête HTTP poignée de main initiale (Mise à jour: websocket) , cette demande envoyée au port 81. Pas vrai? Si c'est le cas, cette requête (voir ci-dessous) n'a aucun lien avec un protocole HTTP. Mais nous utilisons toujours les en-têtes de protocole HTTP. Pourquoi?

    GET /mychat HTTP/1.1 
        Host: server.example.com 
        Upgrade: websocket 
        Connection: Upgrade 
        Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== 
        Sec-WebSocket-Protocol: chat 
        Sec-WebSocket-Version: 13 
        Origin: http://example.com 
   

2. Pourquoi force qu'ils utilisent la même interface websocket actuellement mis en œuvre dans la plupart navigateur pour délivrer une connexion TCP/IP directe avec le port donné, sans substance HTTP?

3. est-il une limite de taille des paquets ou des données/limite de mémoire tampon pour les données envoyées/reçues du client/serveur? Si c'est le cas, avons-nous besoin d'encadrer les données et de les gérer nous-mêmes?

4. Le serveur websocket doit-il toujours être un service/processus distinct? À l'avenir, le serveur Web (IIS, apache) inclura-t-il un support pour l'hébergement de serveurs de socket Web dans son espace de traitement?

Answer 1

1. En utilisant une poignée de main compatible HTTP, vous pouvez intégrer un gestionnaire WebSocket dans votre serveur web ou tout simplement avoir le serveur Web avant la connexion websocket à un serveur dédié WebSocket. L'établissement de liaison WebSocket utilise une prise de contact compatible HTTP pour permettre aux deux protocoles d'être traités facilement sur le même port et permet aux configurations de pare-feu existantes de prendre en charge beaucoup plus facilement le trafic WebSocket. De plus, en évitant les attaques par script latéral bien comprises dans le contexte des requêtes HTTP, WebSocket exploite cette connaissance. Même après l'établissement de la connexion, WebSocket est et non une connexion raw. C'est un protocole basé sur un message et nécessite donc un cadrage. De plus, le cadrage est masqué lorsqu'il est envoyé du client (navigateur) au serveur afin de dissiper les craintes d'une vulnérabilité théorique dans les proxies/caches/intermédiaires mal agencés.

2. Il n'y a aucune limite sur la taille des messages dans le protocole lui-même. Un message peut être divisé en plusieurs images. Il y a une limite de protocole à la taille de l'image, mais c'est 2^64 octets. La limite réelle de la taille de l'image sera plus petite en fonction de l'implémentation client/serveur. Si vous souhaitez envoyer des messages uniques à plusieurs mégaoctets, vous pouvez envisager de modifier votre application pour utiliser des messages plus petits afin d'optimiser la prise en charge de plusieurs navigateurs et de plusieurs serveurs.

3. La gestion de WebSocket peut certainement être intégrée dans des serveurs Web et c'était un scénario très envisagé par le groupe de travail.Par exemple, considérons pywebsocket qui est conçu pour exécuter à la fois autonome ou en tant que module mod_python dans Apache. Comme un autre exemple, ASP.NET 4.5 and IIS 8 will have built-in support for WebSockets.