Quelle est la différence entre les WebSocket et la plaine de communication par socket?
Selon la Wikipédia, la seule relation entre HTTP et WebSocket est un supplémentaire de poignée de main sous la forme d'un Upgrade HTTP request. Et après cela, il semble que le navigateur et le serveur HTTP permettra de communiquer dans un vieux C/S paradigme sur une simple prise.
Donc mes questions sont:
- WebSocket est juste une simple communication par socket?
- Il est appelé
WebPrise parce que les destinataires de la communication du serveur port 80? c'est à direport 80est juste synonyme de laweb. - Le port 80 est sur le côté serveur, quels sont les ports utilisés dans la client?
- Si c'est juste comme la plaine de la socket de communication entre un navigateur et un serveur, pourquoi WebSocket n'est pas implémentée dans les navigateurs jusqu'à récemment? Il semble que rien mais un peu de C/S d'extension pour le B/S paradigme.
AJOUTER 1 (9:46 AM 5/23/2017)
Aujourd'hui, j'ai repensé à @jfriend00 excellente réponse. Let me résumer ma compréhension.
- Socket est juste une fin-2-fin de la communication canal. Il n'impose pas de restriction sur ce que la communication protocole peut être utilisé sur elle.
- webSocket, comme HTTP, est juste un autre autonome protocole de communication. Bien que le mot socket dans le nom qui me confond au premier abord.
- webSocket s'appuie sur le même numéro de port HTTP pour que, si nous pouvons communiquer via HTTP, on peut être sûr webSocket la communication peut être faite. Parce que depuis le canal est à travers, nous pouvons choisir la façon la plus appropriée, nous parle le long du canal.
- A votre question, obtenir une réponse? Si oui, veuillez cliquez sur la coche verte à gauche de l'une des réponses à indiquer à la communauté ce qu'elle pensait être la meilleure réponse. Si votre question n'a pas reçu de réponse, s'il vous plaît répondre à l'une des personnes qui n'ont de réponse et de poser quelques questions de clarification sur ce qui est absent de leur réponse.
- Merci pour le rappel. Désolé pour le retard. 🙂
Vous devez vous connecter pour publier un commentaire.
webSockets et régulière sockets ne sont pas la même chose. Un webSocket fonctionne sur une prise régulière, mais exécute son propre schéma de connexion, dispositif de sécurité et le cadrage protocole sur la partie supérieure de la normale socket et les deux points de terminaison doit suivre ces étapes supplémentaires pour une connexion à être fait même. Vous pouvez voir le protocole webSocket ici: http://tools.ietf.org/html/rfc6455
La plus grande différence est que TOUS les webSocket connexions avec une requête HTTP du client vers le serveur. Le client envoie une requête HTTP à l'exact le même serveur et le port qui est ouvert pour le mode normal de communication web (par défaut le port 80, mais si le serveur web est en cours d'exécution sur un port différent, alors le webSocket de la communication suivez la sur que l'autre port). Le client définit un quelques en-têtes personnalisés, dont la plus importante est un en-tête qui indique que le client souhaite "mise à niveau" pour le protocole webSocket. En plus, les deux côtés d'échanger des clés de sécurité. Si le serveur accepte la "mise à niveau", alors à la fois le client et le serveur basculer le protocole parlé au cours de cette socket d'origine à partir de l'adresse HTTP de webSocket et maintenant le webSocket cadrage protocole est utilisé.
En outre, la première requête HTTP peut avoir une demande path pour indiquer un "sous-destination" pour les webSocket demande. Cela permet toutes sortes de différents webSocket les demandes de tous les être mis en œuvre avec le serveur et le port.
Il y a aussi une option de sous-protocole spécifié avec la
Sec-WebSocket-Protocolen-tête qui permet de demander à identifier les sous-protocoles (une commune peut être "chat"), de sorte que les deux parties peuvent s'entendre sur un ensemble spécifique d'identificateurs de message et de leur signification qui peut être utilisé.Le fait qu'une connexion webSocket commence avec une connexion HTTP est extrêmement important parce que si vous pouvez atteindre le serveur web normal de la communication sur le web, vous pouvez atteindre pour un webSocket demande sans aucune infrastructure de réseau de n'importe où entre le client et le serveur avoir à ouvrir de nouveaux trous dans le pare-feu ou d'ouvrir de nouveaux ports ou quelque chose comme ça.
Vous pouvez voir un excellent résumé de la façon dont une connexion webSocket est commencé ici: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers.
Le protocole webSocket définit également ping et pong paquets aider les deux parties à savoir si inactif webSocket est toujours connecté.
On peut seulement supposer que la raison pour laquelle il a fallu un certain temps pour obtenir les webSockets dans tous les navigateurs les plus courants est la même raison que beaucoup de capacités utiles a pris du temps. D'abord un groupe de motivé les gens ont d'identifier et de convenir d'un besoin, alors que le groupe doit prendre l'initiative dans l'élaboration d'une approche pour résoudre le problème, l'idée reçoit des coups de pied autour pendant un certain temps, soit rassemblement de soutien et de traiter les objections ou en concurrence avec d'autres moyens de résoudre un tel problème, et puis il semble avoir assez d'élan pour être réellement quelque chose qui pourrait devenir un standard, alors que quelqu'un décide de faire un test/mise à l'essai dans un navigateur et un correspondant de mise en œuvre de serveur (parfois, cette étape est beaucoup plus tôt). Puis, si c'est encore à trouver l'élan et semble être sur un suivi des normes, de navigateur et d'autres fabricants de ramasser l'idée et le début de leur mise en œuvre. Une fois que tous les éditeurs de navigateurs ont un travail décent de mise en œuvre (généralement il y a des séries de normes d'amélioration de la que les différentes implémentations de trouver des trous dans le cahier des charges ou aux développeurs d'identifier les problèmes ou les capacités manquantes ou les problèmes de sécurité surviennent). Puis, il en arrive au point où au moins deux grands navigateurs ont la fonctionnalité dans leurs dernières versions, la standard est considéré comme relativement solide et les consommateurs commencent à adopter les navigateurs et certains sites commencent à améliorer leur expérience de l'utilisateur à l'aide de la nouvelle fonctionnalité. À ce stade, la fuite des navigateurs commencent à ressentir la pression pour la mettre en œuvre. Et puis, parfois, des années plus tard, tous les principaux navigateurs ont la particularité et les navigateurs ont assez globale de l'adoption de l'utilisateur pour les sites web pouvez compter sur la fonction (sans avoir à disposer d'une seconde majeure de secours, un design qui fonctionne lorsqu'un navigateur ne prend pas en charge la fonctionnalité). L'ensemble de ce processus peut prendre de très nombreuses années.
Voici un exemple de la première requête HTTP pour initier une connexion webSocket:
Et, la réponse du serveur:
Et, d'un bloc de données exemple:
Non, les WebSockets sont plus que de simples supports. Ils utilisent un protocole de tramage qui nécessite une poignée de main et les échanges de messages masqués par XORint avec un 32 bits nombre aléatoire. Pour plus d'informations, lire la RFC qui uniformise leur.
La raison supplémentaire de codage de la couche est qu'en permettant à un navigateur web pour créer arbitraire des connexions socket permettrait d'ouvrir de divers problèmes de sécurité. Vous pourriez, par exemple, que les visiteurs de votre site web se connecter à l'arbitraire serveurs d'email via SMTP et de les faire envoyer du spam sans que l'utilisateur s'en rendre compte. C'est pourquoi le protocole a été conçu de manière à ce que tout du côté du serveur d'applications ont besoin pour mettre en œuvre intentionnellement avant de pouvoir être utilisé à partir de navigateurs web.
Concernant les ports: Par défaut, WebSocket se connecte sur le Port 80, mais l'API peut recevoir n'importe quel port. Le client-face port est aléatoire, comme dans la plupart basées sur TCP/IP protocoles.
Pourquoi n'était-il pas mis en œuvre plus tôt? Parce que jusqu'à récemment le WhatWG et W3C n'ont pas le support unifié par tous les principaux développeurs de navigateurs pour obtenir de l'autorité dont ils ont besoin pour introduire de nouvelles normes. C'est pourquoi il ya un tel flot de nouvelles fonctionnalités du navigateur sous le label HTML5 récemment.