Compréhension approfondie des principes de Websocket

Cet article vous présente une compréhension approfondie des principes de Websocket. Il a une bonne valeur de référence. J'espère qu'il pourra aider les amis dans le besoin. 

1. Websocket et http

WebSocket est une chose (protocole) introduite par HTML5, ce qui signifie que le protocole HTTP n'a pas changé, ou cela n'a pas d'importance, mais HTTP ne prend pas en charge connexions persistantes (les connexions longues, les connexions circulaires ne sont pas comptées)

Tout d'abord, HTTP a 1.1 et 1.0 , qui sont ce qu'on appelle keep-alive , qui fusionne plusieurs requêtes HTTP en une seule, mais Websocket est en fait Un nouveau protocole n'a fondamentalement rien à voir avec le protocole HTTP. Il s'agit simplement d'être compatible avec les spécifications de poignée de main des navigateurs existants. à travers une telle image

Il y a des carrefours, mais pas tous.

De plus, Html5 fait référence à une série de nouvelles API, ou de nouvelles spécifications et de nouvelles technologies. Le protocole HTTP lui-même n'a que 1.0 et 1.1 et n'a aucune relation directe avec HTML lui-même. . En termes simples, vous pouvez utiliser le protocole HTTP pour transmettre des données non HTML, c'est tout =. =

Pour faire simple, les niveaux sont différents.

2. Quel type de protocole est Websocket et quels sont ses avantages spécifiques

Tout d'abord, Websocket est un protocole persistant, comparé aux protocoles non persistants comme HTTP. Donnons un exemple simple et utilisons le cycle de vie PHP actuellement largement utilisé pour l'expliquer.

Le cycle de vie de HTTP est défini par Request, c'est-à-dire un Request et un Response Puis en HTTP1.0, cette requête HTTP se termine.

Des améliorations ont été apportées à HTTP 1.1 afin qu'il y ait un maintien en vie, c'est-à-dire que dans une seule connexion HTTP, plusieurs requêtes peuvent être envoyées et plusieurs réponses peuvent être reçues. Mais rappelez-vous Request = Response, c'est toujours le cas en HTTP, ce qui signifie qu'une requête ne peut avoir qu'une seule réponse. De plus, cette réponse est également passive et ne peut être initiée activement.

Coach, vous avez tant fait, qu'est-ce que cela a à voir avec Websocket ? _(:з　∠)_D'accord, j'étais sur le point de parler de Websocket. .

Tout d'abord, Websocket est basé sur le protocole HTTP, ou il emprunte le protocole HTTP pour compléter une partie de la poignée de main.

Regardons d'abord une Websocket poignée de main typique (empruntée à Wikipédia...)

GET /chat HTTP/1.1Host: server.example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13Origin: http://example.com

Les enfants qui sont familiers avec HTTP ont peut-être remarqué que cette demande de poignée de main est similaire à la Protocole HTTP, quelques autres choses. Je vais d'ailleurs vous expliquer la fonction.

Upgrade: websocketConnection: Upgrade

C'est le cœur de Websocket. Dites à Apache, Nginx et aux autres serveurs : Attention, j'ai initié le protocole Websocket S'il vous plaît, aidez-moi à trouver l'assistant correspondant pour le gérer ~ pas si ancien. HTTP terreux.

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13

Tout d'abord, Sec-WebSocket-Key est une valeur de Base64 encode, qui est générée aléatoirement par le navigateur et dit au serveur : Peat, ne me trompe pas, je veux vérifier si c'est le cas. est vraiment un assistant Websocket.

Ensuite, Sec_WebSocket-Protocol est une chaîne définie par l'utilisateur utilisée pour distinguer les protocoles requis par différents services sous la même URL. Compréhension simple : je veux servir A ce soir, ne vous trompez pas~

Enfin, Sec-WebSocket-Version indique au serveur le Websocket Draft (version du protocole) utilisé au début, le protocole Websocket était encore. Draft À ce stade, il y a toutes sortes de protocoles étranges, et il y a aussi beaucoup de choses étranges et différentes. Firefox et Chrome utilisent des versions différentes. Au début, il y avait trop de protocoles Websocket, ce qui était un gros problème. . Mais c'est bon maintenant, c'est réglé ~ Quelque chose que tout le monde utilise ~ Déshydratation : Serveur, je veux un enfant de 13 ans →_→

Ensuite, le serveur renverra les choses suivantes, indiquant que la demande a été acceptée et que le Websocket a été établi avec succès !

HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=Sec-WebSocket-Protocol: chat

C'est la dernière zone responsable de HTTP. Dites au client que j'ai changé de protocole avec succès ~

Upgrade: websocketConnection: Upgrade

Il est toujours corrigé. Dites au client que la mise à niveau à venir. est Websocket Protocole, pas mozillasocket, lurnarsocket ou shitsocket.

Ensuite, Sec-WebSocket-Accept Ceci est confirmé par le serveur et crypté Sec-WebSocket-Key . Serveur : D'accord, d'accord, je comprends. Laissez-moi vous montrer ma CARTE D'IDENTITÉ pour le prouver. . Après

, Sec-WebSocket-Protocol représente le protocole final utilisé.

À ce stade, HTTP a terminé tout son travail et la prochaine étape consiste à procéder entièrement conformément au protocole Websocket. L’accord spécifique n’est pas expliqué ici.

————Partie analyse technique terminée——————

Vous faites du BBB depuis si longtemps, alors à quoi sert Websocket http long poll ou ajax轮询 ne peut pas réaliser la transmission d'informations en temps réel ?

Bon les jeunes, parlons de l'utilisation de Websocket. Laisse-moi te donner quelques carottes (rouges)

3. Le rôle de Websocket

Avant de parler de Websocket, je vais d'ailleurs parler de les principes de long poll et ajax轮询.

sondage ajax

Le principe du sondage ajax est très simple. Laissez le navigateur envoyer une requête toutes les quelques secondes pour demander au serveur s'il y a de nouvelles informations.

Reproduction de la scène :

Client : La la la, y a-t-il de nouvelles informations (Demande)

Serveur : Non (Réponse)

Client : La la la, y a-t-il de nouvelles informations (Demande)

Serveur : Non. . (Réponse)

Client : La la la, y a-t-il de nouvelles informations (Demande)

Serveur : Vous êtes tellement ennuyé, il n'y en a pas. . (Réponse)

Client : La la la, y a-t-il un nouveau message ? (Demande)

Serveur : D'accord, d'accord, je l'ai pour vous. (Réponse)

Client : La la la, y a-t-il de nouveaux messages (Demande)

Serveur :. . . . . sans. . . . sans. . . Non (Réponse) —- boucle

sondage long

long poll En fait, le principe est similaire à ajax轮询, les deux adoptent une méthode de sondage, mais adoptent un modèle de blocage (continuez à appeler, ne raccrochez pas le téléphone s'il n'est pas reçu), c'est-à-dire qu'une fois que le client a initialisé la connexion, s'il n'y a pas de message, la réponse ne sera pas renvoyée au client. Il ne revient que lorsqu'il y a un message. Après le retour, le client établit à nouveau la connexion et le cycle recommence.

Reproduction de la scène :

Client : La la la, y a-t-il de nouvelles informations ? Sinon, attendez qu'elles soient disponibles avant de me les retourner (Demande)

Serveur : Front. . Attendez qu'il y ait des nouvelles. . Venez à vous (Réponse)

Client : La la la, y a-t-il une nouvelle information ? Sinon, attendez simplement qu'elle soit disponible avant de me la retourner (Demande) -loop

Vous on le voit d'en haut En fait, ces deux méthodes établissent constamment des connexions HTTP et attendent ensuite que le serveur les traite, ce qui peut refléter une autre caractéristique du protocole HTTP, la passivité.

Qu'est-ce que la passivité ? En fait, le serveur ne peut pas contacter activement le client, il ne peut être initié que par le client.

Pour faire simple, le serveur est un réfrigérateur très paresseux (c'est une blague) (il ne peut pas et ne peut pas initier activement une connexion), mais le patron a une commande. Si un client vient, il doit recevoir. bien, peu importe à quel point il est fatigué.

Après avoir parlé de cela, parlons des défauts ci-dessus (pardonnez-moi de parler autant d'OAQ)

Il est facile de voir de ce qui précède, quoi qu'il arrive, les deux ci-dessus sont très consommatrice de ressources.

Le sondage ajax nécessite que le serveur ait une vitesse de traitement et des ressources rapides. (Vitesse) Un sondage long nécessite une concurrence élevée, ce qui signifie la possibilité de recevoir des clients en même temps. (Taille du lieu)

Cela peut donc arriver à la fois à ajax轮询 et à long poll.

Client : La la la la, y a-t-il de nouvelles informations ?

Serveur : La ligne mensuelle est occupée, veuillez réessayer plus tard (503 Serveur indisponible)

Client :. . . . Bon, la la la, des nouvelles informations ?

Serveur : La ligne mensuelle est occupée, merci de réessayer plus tard (Serveur 503 indisponible)

Client : Ensuite le serveur est très occupé du côté : réfrigérateur, je veux plus de réfrigérateurs ! Plus. . Plus. . (J'avais tort... C'est une autre blague...)

Revenons au sujet, parlons de Websocket

A travers l'exemple ci-dessus, on peut voir qu'aucun de ces deux méthodes sont la meilleure méthode nécessite beaucoup de ressources.

Il faut des vitesses plus rapides, il faut plus de « téléphones ». Ces deux éléments entraîneront une demande croissante de « téléphones ».

Oh, au fait, j'ai oublié de mentionner que HTTP est toujours un protocole avec état.

En termes simples, le serveur doit traiter avec trop de clients chaque jour et est une personne oublieuse Dès que vous raccrochez le téléphone, il oubliera toutes vos affaires et jettera toutes vos affaires. Vous devez le répéter au serveur une deuxième fois.

Donc dans ce cas, Websocket est apparu. Il a résolu ces problèmes de HTTP. Premièrement, la passivité. Une fois que le serveur a terminé la mise à niveau du protocole (HTTP->Websocket), le serveur peut activement transmettre des informations au client. Le scénario ci-dessus peut donc être modifié comme suit.

Client : la la la, je souhaite établir le protocole Websocket, services requis : chat, version du protocole Websocket : 17 (Requête HTTP)

Serveur : ok, confirmé, mis à niveau vers le protocole Websocket ( Protocoles HTTP commutés)

Client : veuillez me le transmettre lorsque vous avez des informations. .

Serveur : ok, je vous le dirai parfois.

Serveur : balabalabalabala

Serveur : balabalabalabala

Côté serveur : Hahahahahahahahahahahahahahahaha

Côté serveur : j'ai tellement ri hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha hahahahahahahahaha

Cela devient comme ça, une seule requête HTTP est requise. Un flux constant d'informations est transmis. (En programmation, ce type de conception s'appelle callback, c'est-à-dire : prévenez-moi lorsque vous avez des informations, au lieu que je cours bêtement pour vous le demander à chaque fois)

Ce type de protocole résout le délai de synchronisation ci-dessus. est également très consommateur de ressources. Alors pourquoi résout-il le problème de consommation des ressources sur le serveur ?

En fait, le programme que nous utilisons passe par deux couches de proxys, c'est-à-dire que le protocole HTTP est analysé par des serveurs tels que Nginx, puis transmis au gestionnaire correspondant (PHP, etc.) pour traitement. En termes simples, nous avons un 接线员（Nginx） très rapide qui se charge de transmettre les problèmes au 客服（Handler） correspondant.

L'opérateur lui-même est fondamentalement assez rapide, mais chaque fois que je suis coincé dans le service client (Handler), la vitesse de traitement du service client est toujours trop lente. , ce qui entraîne un service client insuffisant. Websocket résout un tel problème.Une fois établi, vous pouvez établir directement une connexion persistante avec l'opérateur. Lorsqu'il y a des informations, le service client trouvera un moyen d'informer l'opérateur, puis celui-ci les transférera au client.

Cela peut résoudre le problème de la lenteur de traitement du service client.

En même temps, de manière traditionnelle, vous devez constamment établir et fermer le protocole HTTP. Puisque HTTP n'est pas avec état, vous devez retransmettre des identity info (informations d'identification) à chaque fois pour informer le serveur que vous êtes qui.

Bien que l'opérateur soit très rapide, l'efficacité sera réduite s'il doit écouter autant à chaque fois, en même temps, il doit constamment transférer ces informations au service client, ce qui non seulement gaspille de l'argent. le temps de traitement du service client, mais entraîne également une consommation excessive de trafic/de temps dans la transmission réseau.

Mais Websocket ne nécessite qu'une seule prise de contact HTTP, donc l'ensemble du processus de communication est établi dans une seule connexion/état, ce qui évite l'apatridie du HTTP. Le serveur connaîtra toujours vos informations jusqu'à ce que vous la fermiez, cela résout. le problème est que l'opérateur doit analyser à plusieurs reprises le protocole HTTP et vérifier les informations d'identité.

En même temps, le client prend l'initiative de demander, et le serveur (push) l'envoie quand il y a des informations (bien sûr, le client attend toujours l'initiative d'envoyer des informations...), et quand il n'y a pas d'information, elle est remise à l'opérateur (Nginx), pas besoin d'occuper le service client (Handler) qui est intrinsèquement lent

Quant à comment utiliser Websocket sur un client qui n'en a pas prend en charge Websocket. . La réponse est : ne peut pas

mais vous pouvez simuler des effets similaires grâce aux long poll et ajax 轮询 mentionnés ci-dessus

Recommandations associées :

Imitation HTML de la page d'accueil de Baidu

Le rôle des méta dans la page html et l'analyse des paramètres de cache et de non-caching de la page

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!