開放、平等、協(xié)作、快速、分享
webSocket協(xié)議,而且是在微信小程序中用到了webSocket,微信小程序中使用wss協(xié)議的時候不能設(shè)置端口,只能使用默認的443端口。我擦,我的https已經(jīng)監(jiān)聽了443端口,webSocket再去監(jiān)聽443,肯定不行啊。要想辦法解決,老大把這個問題交給我了,我愉快(手動懵逼)的接收了這個任務(wù)。想到了兩種辦法解決。一種解決辦法是把webSocket部署到另一臺服務(wù)器上,這樣成本也太高了。另一種辦法,就是使用nginx反向代理。
因為webSocket協(xié)議是基于http協(xié)議升級的(見下圖),所以可以使用nginx反向代理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é)議的握手請求中,只是多了幾個東西。
Upgrade: websocket Connection: Upgrade 這個就是Websocket的核心了,告訴Apache、Nginx等服務(wù)器:我發(fā)起的是Websocket協(xié)議。 Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13
首先,Sec-WebSocket-Key 是一個Base64 encode的值,這個是瀏覽器隨機生成的,告訴服務(wù)器:泥煤,不要忽悠窩,我要驗證尼是不是真的是Websocket助理。
最后,Sec-WebSocket-Version 是告訴服務(wù)器所使用的Websocket Draft(協(xié)議版本),在最初的時候,Websocket協(xié)議還在 Draft 階段,各種奇奇怪怪的協(xié)議都有,而且還有很多期奇奇怪怪不同的東西,什么Firefox和Chrome用的不是一個版本之類的,當初Websocket協(xié)議太多可是一個大難題。。不過現(xiàn)在還好,已經(jīng)定下來啦大家都使用的一個東西
然后服務(wù)器會返回下列東西,表示已經(jīng)接受到請求, 成功建立Websocket啦!
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat
這里開始就是HTTP最后負責(zé)的區(qū)域了,告訴客戶,我已經(jīng)成功切換協(xié)議啦~
Upgrade: websocket Connection: Upgrade
依然是固定的,告訴客戶端即將升級的是Websocket協(xié)議。至此,HTTP已經(jīng)完成它所有工作了,接下來就是完全按照Websocket協(xié)議進行了。
明白協(xié)議的原理了就可以下一步了
服務(wù)器的證書是老大配置好的,我就直接用了。需要的傳送門
在nginx配置文件的service
節(jié)點中添加如下配置
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
這個是隨便起的,告訴Nginx要代理的url,現(xiàn)在我的設(shè)置為wss
,當我訪問的我的服務(wù)器https://abc.com/wss
時,Nginx會把我的請求映射到本機的8888端口。proxy_pass
要代理到的url,我的代理到本機的8888端口。proxy_http_version
代理時使用的 http版本。
重點來了:
代理webSocket的關(guān)鍵參數(shù)proxy_set_header Upgrade
把代理時http請求頭的Upgrade
設(shè)置為原來http請求的請求頭,wss協(xié)議的請求頭為websocket
proxy_set_header Connection
因為代理的wss協(xié)議,所以http請求頭的Connection
設(shè)置為Upgrade
proxy_set_header X-Real-IP
給代理設(shè)置原h(huán)ttp請求的ip,填寫$remote_addr
即可
至于websocket協(xié)議的response的參數(shù),在反向代理的時候不用管。
到這里,Nginx反向代理webSocket的配置就完成了,重啟Nginx,用websocket連接試試,在原來wss地址的地方填寫wss://abc.com/wss
。如果websocket成功連接,說明Nginx反向代理websocket已經(jīng)成功了。
現(xiàn)在的配置只是反向代理到本機時的配置,如果要反向代理到別的主機,在代理時可能會跨域問題,需要在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的反向代理這么像。通過上網(wǎng)查資料才知道,原來Nginx在處理php類型的請求時,把請求發(fā)fastcgi管理進程處理,fascgi管理進程選擇cgi子進程處理結(jié)果并返回被nginx,而php-fpm是一個PHP FastCGI管理器,nginx本身不能處理PHP,它只是個web服務(wù)器,當接收到請求后,如果是php請求,則發(fā)給php解釋器處理,并把結(jié)果返回給客戶端。所以說Nginx在處理php類型的請求時,本質(zhì)上也是通過反向代理功能實現(xiàn)的。
我們可以把思維展開,用Nginx反向代理可以實現(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; }
當然,也可以用Nginx反向代理實現(xiàn)負載均衡,這個我還沒有試過,等以后用到了,再來補充