WebSocket プロトコルは http プロトコルに基づいてアップグレードされるため (次の図を参照)、nginx リバース プロキシ Websocket を使用できます。
websocket
From この図からわかるように、WebSocket 接続は 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
http に詳しいお子様は、このハンドシェイク リクエストに http プロトコルに似たものがさらにいくつかあることに気づいたかもしれません。
upgrade: websocket connection: upgrade 这个就是websocket的核心了,告诉apache、nginx等服务器:我发起的是websocket协议。 sec-websocket-key: x3jjhmbdl1ezlkh9gbhxdw== sec-websocket-protocol: chat, superchat sec-websocket-version: 13
まず第一に、sec-websocket-key はブラウザによってランダムに生成される Base64 エンコード値です。サーバーに次のように伝えます。「ピート、騙さないでください。あなたがそうであるかどうかを確認したいのです」まさに WebSocket アシスタントです。
最後に、sec-websocket-version は、使用されている WebSocket ドラフト (プロトコル バージョン) をサーバーに伝えます。当初、WebSocket プロトコルはまだドラフト段階にあり、あらゆる種類の奇妙なプロトコルがありました。 Firefox と Chrome ではバージョンが異なり、当初は WebSocket プロトコルが多すぎて大きな問題でした。 。みんなが使っているもの
#その後、サーバーはリクエストが受け入れられ、WebSocket が正常に確立されたことを示す次の内容を返します。http/1.1 101 switching protocols upgrade: websocket connection: upgrade sec-websocket-accept: hsmrc0smlyukagmm5oppg2hagwk= sec-websocket-protocol: chatこれは、http が担当する最後の領域です。プロトコルの切り替えに成功したことをクライアントに伝えます~
upgrade: websocket connection: upgradeはまだ修正されており、今後のアップグレードが WebSocket であることをクライアントに伝えますプロトコル。この時点で、http はすべての作業を完了しており、次のステップは WebSocket プロトコルに従って完全に進むことです。 プロトコルの原理を理解したら、次のステップに進むことができます。
まず、nginx は https 証明書を構成します。
サーバー証明書はbossによって設定されているため、私はそれを直接使用しました。 0.0次の設定を nginx 設定ファイルのservice ノードに追加します
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; }
パラメータの説明
/wss これはランダムに設定されます。nginx にプロキシされる URL を伝えます。現在の設定は
wss です。サーバーにアクセスすると
https:/ / abc.com/wss、nginx は私のリクエストをローカル ポート 8888 にマップします。
proxy_pass プロキシ先の URL。私のプロキシはこのマシンのポート 8888 です。
proxy_http_version プロキシ時に使用される http バージョン。
ここが重要なポイントです:
プロキシ Websocket の主要パラメータproxy_set_header upgrade プロキシ時に http リクエスト ヘッダーを変更する
upgrade は元の http リクエストのリクエスト ヘッダーに設定され、wss プロトコルのリクエスト ヘッダーは
websocket
proxy_set_header connection プロキシのためwss プロトコル、http リクエスト ヘッダーは
connection に設定します
upgrade
元の IP を設定しますhttp リクエストをプロキシに送信し、#$remote_addr を入力します。
WebSocket プロトコルの応答パラメータについては、リバース プロキシ中には気にする必要はありません。
wss://abc.com/wss## を入力します。 #。 Web ソケットが正常に接続された場合は、nginx リバース プロキシ Web ソケットが成功したことを意味します。
概要
現在の構成は、このマシンにリバース プロキシ接続する場合の構成のみです。他のホストにリバース プロキシ接続する場合は、プロキシがドメインを越える可能性があります。問題は、クロスドメイン構成を nginx のリバース プロキシで行う必要があることです。
思考この段落は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;
}
これはnginxのphpの設定ファイルなので削除させてくださいそれはどうやって? 見覚えがあるように見えますが、この構成リストは、先ほどの WebSocket リバース プロキシに非常に似ています。ネットで調べたところ、nginxがPHP系のリクエストを処理する際、fastcgi管理プロセスにリクエストを送り、fascgi管理プロセスがcgiサブプロセスの処理結果を選択してnginxに返す、php-fpmというPHPであることが分かりました。 fastcgi マネージャー. nginx 自体は PHP を処理できません。単なる Web サーバーです。リクエストを受信すると、それが PHP リクエストであれば、処理のために PHP インタプリタに送信され、結果がクライアントに返されます。したがって、nginx が PHP タイプのリクエストを処理する場合、基本的にリバース プロキシ機能を通じて実装されます。
考え方を拡張し、nginx リバース プロキシを使用して、プロキシ tomcat
location /tomcat { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header x-real-ip $remote_addr; }などのより多くの機能を実現できます。
以上がnginxリバースプロキシWebSocketを構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。