nginx代理了兩臺socket.io服務(wù)器。socket.io的工作模式是polling升級到websocket
現(xiàn)象
通過nginx請求服務(wù)時(shí)，出現(xiàn)了大量的400錯(cuò)誤，有時(shí)候能升級到websocket，有時(shí)候會一直報(bào)錯(cuò)。但是直接通過 ip+端口 訪問時(shí)，100%能成功。
分析
sid
sid是我們這個(gè)問題的關(guān)鍵。在初始創(chuàng)建連接時(shí)（polling模式就是在模擬一個(gè)長連接），客戶端會發(fā)起這樣的請求：
https://***/?EIO=3&transport=polling&t=1540820717277-0
服務(wù)端收到后會創(chuàng)建一個(gè)對象，綁定在這個(gè)連接上，同時(shí)返回一個(gè)sid（session id），來標(biāo)記這個(gè)會話。會話指什么呢，會話是一連串的交互，這些交互之間是有聯(lián)系的，在我們這個(gè)場景下就是，下一次的http請求到來，我需要找到之前綁定在理論上的長連接（這里還沒有websocket，所以是理論上的）上的那個(gè)對象。我們知道http請求是無狀態(tài)的，每個(gè)請求之間獨(dú)立，所以socket.io引入了sid來做這件事。服務(wù)端收到請求后會生成一個(gè)sid，看下response：
之后每次請求都需要帶上這個(gè)sid，建立websocket請求的連接也不例外。所以說，sid是polling，以及polling升級到websocket的關(guān)鍵。這之后的請求類似于：
|
1
2
3
4
5
|
https://***/?EIO=3&transport=polling&t=1540820717314-1&sid=EoGaL3fRQlpTOaLp5eSTorwss://***/?EIO=3&transport=websocket&t=1540820717314-1&sid=EoGaL3fRQlpTOaLp5eST |
那么問題來了，如果請求是帶上的sid不是服務(wù)端生成的會怎樣呢？服務(wù)端會不認(rèn)識，給你返回一個(gè)400，并告訴你
|
1
|
invalid sid |
我們遇到的便是這個(gè)問題，nginx默認(rèn)的負(fù)載均衡策略是輪詢，所以請求有可能會打到不是生成這個(gè)sid的機(jī)器上去，這時(shí)候我們就會收到一個(gè)400，如果運(yùn)氣好，可能也會打到原來的機(jī)器上，運(yùn)氣更好一點(diǎn)，甚至能堅(jiān)持到websocket連接建立。
解決
這里提出兩種方案
-
nginx的負(fù)載均衡采用ip_hash，這樣能保證一個(gè)客戶端的請求都走到一臺服務(wù)器上
-
不使用polling模式，只使用websocket
這兩種方案各有利弊。第二種顯而易見，不支持websocket的古老瀏覽器和客戶端將沒法工作。第一種的問題隱藏得比較深，試想，如果你增減了機(jī)器會怎樣，這時(shí)候ip_hash策略的模將變化，之前的連接將全部失效，而對于微服務(wù)，擴(kuò)縮容是很頻繁的操作（特別是產(chǎn)品處于發(fā)展期），這種有損的擴(kuò)縮容很大概率是不能接受的。
綜上，建議直接使用websocket，畢竟不支持websocket的老版本占比很少，而且相對于先polling，耗時(shí)也會減少。
以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持服務(wù)器之家。
原文鏈接：http://michaelyou.github.io/2018/10/29/nginx代理socket-io服務(wù)踩坑/
