文章分享

webSocket協(xié)議,而且是在微信小程序中用到了webSocket,微信小程序中使用wss協(xié)議的時(shí)候不能設(shè)置端口,只能使用默認(rèn)的443端口。我擦，我的https已經(jīng)監(jiān)聽了443端口，webSocket再去監(jiān)聽443，肯定不行啊。要想辦法解決，老大把這個(gè)問題交給我了，我愉快（手動(dòng)懵逼）的接收了這個(gè)任務(wù)。想到了兩種辦法解決。一種解決辦法是把webSocket部署到另一臺(tái)服務(wù)器上，這樣成本也太高了。另一種辦法，就是使用nginx反向代理。

因?yàn)閣ebSocket協(xié)議是基于http協(xié)議升級(jí)的（見下圖），所以可以使用nginx反向代理webSocket.

webSocket

從這張圖片上可以看出，webSocket連接的建立是在http協(xié)議的基礎(chǔ)上。

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的童鞋可能發(fā)現(xiàn)了，這段類似HTTP協(xié)議的握手請(qǐng)求中，只是多了幾個(gè)東西。

Upgrade: websocket
Connection: Upgrade
這個(gè)就是Websocket的核心了，告訴Apache、Nginx等服務(wù)器：我發(fā)起的是Websocket協(xié)議。
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

首先，Sec-WebSocket-Key 是一個(gè)Base64 encode的值，這個(gè)是瀏覽器隨機(jī)生成的，告訴服務(wù)器：泥煤，不要忽悠窩，我要驗(yàn)證尼是不是真的是Websocket助理。
最后，Sec-WebSocket-Version 是告訴服務(wù)器所使用的Websocket Draft（協(xié)議版本），在最初的時(shí)候，Websocket協(xié)議還在 Draft 階段，各種奇奇怪怪的協(xié)議都有，而且還有很多期奇奇怪怪不同的東西，什么Firefox和Chrome用的不是一個(gè)版本之類的，當(dāng)初Websocket協(xié)議太多可是一個(gè)大難題。。不過現(xiàn)在還好，已經(jīng)定下來啦大家都使用的一個(gè)東西

然后服務(wù)器會(huì)返回下列東西，表示已經(jīng)接受到請(qǐng)求， 成功建立Websocket啦！

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

這里開始就是HTTP最后負(fù)責(zé)的區(qū)域了，告訴客戶，我已經(jīng)成功切換協(xié)議啦~

Upgrade: websocket
Connection: Upgrade

依然是固定的，告訴客戶端即將升級(jí)的是Websocket協(xié)議。至此，HTTP已經(jīng)完成它所有工作了，接下來就是完全按照Websocket協(xié)議進(jìn)行了。

明白協(xié)議的原理了就可以下一步了

首先nginx先配置好https的證書

服務(wù)器的證書是老大配置好的，我就直接用了。需要的傳送門
在nginx配置文件的service節(jié)點(diǎn)中添加如下配置

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;
         }

解釋一下參數(shù)
/wss這個(gè)是隨便起的,告訴Nginx要代理的url,現(xiàn)在我的設(shè)置為wss,當(dāng)我訪問的我的服務(wù)器https://abc.com/wss時(shí),Nginx會(huì)把我的請(qǐng)求映射到本機(jī)的8888端口。
proxy_pass 要代理到的url,我的代理到本機(jī)的8888端口。
proxy_http_version 代理時(shí)使用的 http版本。
重點(diǎn)來了:
代理webSocket的關(guān)鍵參數(shù)
proxy_set_header Upgrade 把代理時(shí)http請(qǐng)求頭的Upgrade 設(shè)置為原來http請(qǐng)求的請(qǐng)求頭,wss協(xié)議的請(qǐng)求頭為websocket
proxy_set_header Connection 因?yàn)榇淼膚ss協(xié)議,所以http請(qǐng)求頭的Connection設(shè)置為Upgrade
proxy_set_header X-Real-IP 給代理設(shè)置原h(huán)ttp請(qǐng)求的ip,填寫$remote_addr 即可
至于websocket協(xié)議的response的參數(shù)，在反向代理的時(shí)候不用管。
到這里,Nginx反向代理webSocket的配置就完成了,重啟Nginx,用websocket連接試試，在原來wss地址的地方填寫wss://abc.com/wss。如果websocket成功連接,說明Nginx反向代理websocket已經(jīng)成功了。

總結(jié)

現(xiàn)在的配置只是反向代理到本機(jī)時(shí)的配置,如果要反向代理到別的主機(jī),在代理時(shí)可能會(huì)跨域問題,需要在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的配置文件,我擦,怎么這么眼熟,這個(gè)配置清單跟剛才的websocket的反向代理這么像。通過上網(wǎng)查資料才知道，原來Nginx在處理php類型的請(qǐng)求時(shí)，把請(qǐng)求發(fā)fastcgi管理進(jìn)程處理，fascgi管理進(jìn)程選擇cgi子進(jìn)程處理結(jié)果并返回被nginx,而php-fpm是一個(gè)PHP FastCGI管理器,nginx本身不能處理PHP，它只是個(gè)web服務(wù)器，當(dāng)接收到請(qǐng)求后，如果是php請(qǐng)求,則發(fā)給php解釋器處理，并把結(jié)果返回給客戶端。所以說Nginx在處理php類型的請(qǐng)求時(shí),本質(zhì)上也是通過反向代理功能實(shí)現(xiàn)的。
我們可以把思維展開，用Nginx反向代理可以實(shí)現(xiàn)更多的功能，比如代理Tomcat

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

當(dāng)然，也可以用Nginx反向代理實(shí)現(xiàn)負(fù)載均衡,這個(gè)我還沒有試過,等以后用到了,再來補(bǔ)充