Configuration du proxy inverse nginx webSocket

J'ai récemment utilisé le protocole webSocket lorsque je travaillais sur un projet, et webSocket a été utilisé dans l'applet WeChat. Lors de l'utilisation du protocole wss dans l'applet WeChat, le port ne peut pas être défini et le port par défaut 443 ne peut être utilisé. Mon https écoute déjà le port 443. Si webSocket écoute le port 443, cela ne fonctionnera certainement pas. Trouvez un moyen de le résoudre. J'ai donc pensé à deux façons de le résoudre. Une solution consiste à déployer webSocket sur un autre serveur, ce qui coûte trop cher. Une autre façon consiste à utiliser le proxy inverse nginx.

Étant donné que le protocole webSocket est mis à niveau sur la base du protocole http (voir l'image ci-dessous), vous pouvez utiliser le proxy inverse nginx webSocket.

À partir d'ici Comme le montre l'image, la connexion webSocket est établie sur la base du protocole http.

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

Les enfants qui sont familiers avec HTTP ont peut-être remarqué qu'il y a juste quelques éléments supplémentaires dans cette demande de prise de contact similaires au protocole HTTP.

Upgrade: websocket
Connection: Upgrade

C'est le cœur de Websocket. Dites à Apache, Nginx et autres serveurs : j'ai initié le protocole Websocket.

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

Tout d'abord, Sec-WebSocket-Key est une valeur d'encodage Base64, qui est générée aléatoirement par le navigateur. Dites au serveur : Peat, ne me trompez pas, je veux vérifier si vous l'êtes vraiment. un assistant Websocket.

Enfin, Sec-WebSocket-Version indique au serveur le Websocket Draft (version du protocole) utilisé. Au début, le protocole Websocket était encore au stade Draft, et il y avait toutes sortes de protocoles étranges, et là. Il y avait aussi beaucoup de choses étranges et différentes, comme Firefox et Chrome utilisant des versions différentes. Au début, il y avait trop de protocoles Websocket, ce qui était un gros problème. . Mais tout va bien maintenant. Il a été réglé sur une chose que tout le monde utilise

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 Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

C'est la dernière zone responsable de HTTP. Elle indique au client que j'ai réussi à changer de protocole ~

Upgrade: websocket
Connection: Upgrade

Il est toujours corrigé et indique au client que le protocole Websocket est sur le point de le faire. être mis à niveau. À ce stade, HTTP a terminé tout son travail et la prochaine étape consiste à procéder entièrement conformément au protocole Websocket.

Une fois que vous avez compris le principe du protocole, vous pouvez passer à l'étape suivante

Tout d'abord, nginx configure le certificat https

Le certificat du serveur a été configuré par le patron, donc je l'ai utilisé directement. Vérifiez-le vous-même si nécessaire. 0.0

Ajoutez la configuration suivante au nœud de service du fichier de configuration nginx

location /wss
        {
                 proxy_pass http://127.0.0.1:8888;
                 proxy_http_version 1.1;
                 proxy_set_header Upgrade $http_upgrade;
                 proxy_set_header Connection "Upgrade";
                proxy_set_header X-Real-IP $remote_addr;
         }

Expliquez les paramètres

/wss. Commencez simplement par indiquer à Nginx l'URL à utiliser par proxy. Maintenant, mon paramètre est wss. Lorsque j'accède à mon serveur https://abc.com/wss, Nginx mappera ma requête sur le port 8888 de cette machine.

proxy_pass L'URL vers laquelle proxy. Mon proxy est le port 8888 de cette machine.

proxy_http_version version http utilisée lors du proxy.

Voici le point clé :

Paramètres clés du proxy webSocket

proxy_set_header Upgrade Définissez la mise à niveau de l'en-tête de la requête http lors du proxy vers la requête de l'en-tête de requête http d'origine, l'en-tête de requête du protocole wss est websocket

proxy_set_header Connection En raison du protocole wss du proxy, la connexion de l'en-tête de requête http est définie sur Upgrade

proxy_set_header X-Real-IP définit la requête http d'origine sur le proxy Pour l'ip, remplissez $remote_addr

Quant aux paramètres de réponse du protocole websocket, vous n'avez pas à vous en soucier lors du reverse procuration.

À ce stade, la configuration du proxy inverse Nginx webSocket est terminée. Redémarrez Nginx, essayez de vous connecter avec websocket et remplissez wss://abc.com/wss à la place de l'adresse wss d'origine. Si le websocket est connecté avec succès, cela signifie que le websocket du proxy inverse Nginx a réussi.

Résumé

La configuration actuelle est uniquement la configuration lors du proxy inverse sur cette machine. Si vous souhaitez inverser le proxy vers d'autres hôtes, cela peut traverser des domaines lors du proxy. Le problème est que la configuration inter-domaines doit être effectuée dans le proxy inverse Nginx.

En pensant

Vous pouvez voir ce paragraphe dans le fichier de configuration de Nginx

location ~ .php$ {
      root html;
      fastcgi_pass 127.0.0.1:9000;
      fastcgi_index index.php;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      include fastcgi_params;
}

C'est le fichier de configuration php dans Nginx, je l'ai effacé, comment ? Cela semble si familier, cette liste de configuration est tellement similaire au proxy inverse Websocket en ce moment. J'ai découvert en recherchant sur Internet que lorsque Nginx gère les requêtes de type PHP, il envoie la requête au processus de gestion fastcgi. Le processus de gestion fascgi sélectionne le résultat du traitement du sous-processus cgi et le renvoie à nginx, et php-fpm est un PHP. Le gestionnaire FastCGI. nginx lui-même ne peut pas gérer PHP. Lorsqu'une requête est reçue, s'il s'agit d'une requête PHP, elle est envoyée à l'interpréteur PHP pour traitement et le résultat est renvoyé au client. Ainsi, lorsque Nginx gère les requêtes de type PHP, cela est essentiellement implémenté via la fonction de proxy inverse.

Nous pouvons élargir notre réflexion et utiliser le proxy inverse Nginx pour réaliser plus de fonctions, telles que le proxy Tomcat

location /Tomcat
        {
                 proxy_pass http://127.0.0.1:8080;
                 proxy_http_version 1.1;
                proxy_set_header X-Real-IP $remote_addr;
         }

Bien sûr, nous pouvons également utiliser le proxy inverse Nginx pour réaliser l'équilibrage de charge, ce que j'ai également Je ne l'ai pas encore essayé, j'en ajouterai plus lorsque je l'utiliserai à l'avenir.

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!