nginx反向代理webSocket配置

WebSocket Nginx 反向代理 · 發表 2018-10-21 17:52:40

摘要：最近在做專案的時候用到了webSocket協議,而且是在微信小程式中用到了webSocket,微信小程式中使用wss協議的時候不能設定埠,只能使用預設的443埠。我擦，我的https已經監聽了443埠，webSocket再去監聽443，肯定不行啊。要想辦法解決，老大把這個問題交給我了，我愉快（...

最近在做專案的時候用到了webSocket協議,而且是在微信小程式中用到了webSocket,微信小程式中使用wss協議的時候不能設定埠,只能使用預設的443埠。我擦，我的https已經監聽了443埠，webSocket再去監聽443，肯定不行啊。要想辦法解決，老大把這個問題交給我了，我愉快（手動懵逼）的接收了這個任務。想到了兩種辦法解決。一種解決辦法是把webSocket部署到另一臺伺服器上，這樣成本也太高了。另一種辦法，就是使用nginx反向代理。

因為webSocket協議是基於http協議升級的（見下圖），所以可以使用nginx反向代理webSocket.

webSocket

從這張圖片上可以看出，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 encode的值，這個是瀏覽器隨機生成的，告訴伺服器：泥煤，不要忽悠窩，我要驗證尼是不是真的是Websocket助理。

最後，Sec-WebSocket-Version 是告訴伺服器所使用的Websocket Draft（協議版本），在最初的時候，Websocket協議還在 Draft 階段，各種奇奇怪怪的協議都有，而且還有很多期奇奇怪怪不同的東西，什麼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的證書

伺服器的證書是老大配置好的，我就直接用了。需要的自己查一下吧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

proxy_set_header X-Real-IP 給代理設定原http請求的ip,填寫 $remote_addr 即可

至於websocket協議的response的引數，在反向代理的時候不用管。

到這裡,Nginx反向代理webSocket的配置就完成了,重啟Nginx,用websocket連線試試，在原來wss地址的地方填寫 wss://abc.com/wss 。如果websocket成功連線,說明Nginx反向代理websocket已經成功了。

總結

現在的配置只是反向代理到本機時的配置,如果要反向代理到別的主機,在代理時可能會跨域問題,需要在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反向代理實現負載均衡,這個我還沒有試過,等以後用到了,再來補充

nginx反向代理webSocket配置

首先nginx先配置好https的證書

總結

思考

您可能也會喜歡…