nginx代理socket.io服務的坑怎么解決

這篇文章主要介紹“nginx代理socket.io服務的坑怎么解決”，在日常操作中，相信很多人在nginx代理socket.io服務的坑怎么解決問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”nginx代理socket.io服務的坑怎么解決”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

nginx代理了兩臺socket.io服務器。socket.io的工作模式是polling升級到websocket

現象

通過nginx請求服務時，出現了大量的400錯誤，有時候能升級到websocket，有時候會一直報錯。但是直接通過 ip+端口 訪問時，100%能成功。

分析

sid

sid是我們這個問題的關鍵。在初始創建連接時（polling模式就是在模擬一個長連接），客戶端會發起這樣的請求：

https://***/?eio=3&transport=polling&t=1540820717277-0

服務端收到后會創建一個對象，綁定在這個連接上，同時返回一個sid（session id），來標記這個會話。會話指什么呢，會話是一連串的交互，這些交互之間是有聯系的，在我們這個場景下就是，下一次的http請求到來，我需要找到之前綁定在理論上的長連接（這里還沒有websocket，所以是理論上的）上的那個對象。我們知道http請求是無狀態的，每個請求之間獨立，所以socket.io引入了sid來做這件事。服務端收到請求后會生成一個sid，看下response：

復制代碼 代碼如下:

{"sid":"eogal3frqlptoalp5est","upgrades":["websocket"],"pinginterval":8000,"pingtimeout":10000}

之后每次請求都需要帶上這個sid，建立websocket請求的連接也不例外。所以說，sid是polling，以及polling升級到websocket的關鍵。這之后的請求類似于：

https://***/?eio=3&transport=polling&t=1540820717314-1&sid=eogal3frqlptoalp5est

or

wss://***/?eio=3&transport=websocket&t=1540820717314-1&sid=eogal3frqlptoalp5est

那么問題來了，如果請求是帶上的sid不是服務端生成的會怎樣呢？服務端會不認識，給你返回一個400，并告訴你

invalid sid

我們遇到的便是這個問題，nginx默認的負載均衡策略是輪詢，所以請求有可能會打到不是生成這個sid的機器上去，這時候我們就會收到一個400，如果運氣好，可能也會打到原來的機器上，運氣更好一點，甚至能堅持到websocket連接建立。

解決

這里提出兩種方案

1. nginx的負載均衡采用ip_hash，這樣能保證一個客戶端的請求都走到一臺服務器上

2. 不使用polling模式，只使用websocket

這兩種方案各有利弊。第二種顯而易見，不支持websocket的古老瀏覽器和客戶端將沒法工作。第一種的問題隱藏得比較深，試想，如果你增減了機器會怎樣，這時候ip_hash策略的模將變化，之前的連接將全部失效，而對于微服務，擴縮容是很頻繁的操作（特別是產品處于發展期），這種有損的擴縮容很大概率是不能接受的。

到此，關于“nginx代理socket.io服務的坑怎么解決”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！