由于項目中需要服務(wù)端向移動設(shè)備主動推送信令，于是引入websocket協(xié)議進行移動設(shè)備和服務(wù)端之間的通信。Demo程序很正常，服務(wù)端使用nodejs ws類庫起一個websocket服務(wù)器，android設(shè)備中使用Okhttp3-ws對接，一切都比較正常。但是集成到生產(chǎn)環(huán)境kong api gateway后出現(xiàn)了連接一段時間android設(shè)備出現(xiàn)java.io.EOFException錯誤，服務(wù)端ws服務(wù)器出現(xiàn)1006錯誤，websocket連接斷開的問題。
1.確定問題范圍
由于demo程序運行正常，生產(chǎn)環(huán)境與demo環(huán)境區(qū)別在于android設(shè)備和服務(wù)端之間使用kong api gateway工具進行了proxy，kong是基于Nginx的api管理工具，于是問題分析重點鎖定gateway轉(zhuǎn)發(fā)的過程。
2.分析過程
首先抓包比對一下demo環(huán)境和生產(chǎn)環(huán)境區(qū)別。
demo環(huán)境wireshark包：
可以看到，GET請求包和協(xié)議切換響應(yīng)包間隔很短。
kong 環(huán)境包:
這里可以看出經(jīng)過Nginx轉(zhuǎn)發(fā)后的環(huán)境，協(xié)議轉(zhuǎn)換包返回時間距離GET請求包發(fā)出間隔了62秒。
這個http 101包回來時，就導(dǎo)致了okhttp觸發(fā)Java.IO.EOLException異常。
這個時間很有趣，我在客戶端是在websocket連接收延時兩秒發(fā)出信息的，所以Latency時間恰好是60秒，而且每次都很穩(wěn)定，這個現(xiàn)象很像配置問題。
果然查了下資料，Nginx的官網(wǎng)文檔對websocket協(xié)議有說明:
By default, the connection will be closed if the proxied server does not transmit any data within 60 seconds. This timeout can be increased with the proxy_read_timeout directive. Alternatively, the proxied server can be configured to periodically send WebSocket ping frames to reset the timeout and check if the connection is still alive.
嘗試修改了read timeout的時間，果然出現(xiàn)斷連的時間隨著timeout而變化，應(yīng)該就是Nginx這個機制導(dǎo)致的。文檔中也明確說明了解決方法，在時間間隔小于read timeout的輪詢中不斷和服務(wù)器進行ping包發(fā)送來刷新timeout時間。
實際測試，用20秒的間隔不斷給服務(wù)器發(fā)送心跳，可以保持websocket連接不斷。
但是還有一個問題，http upgarde包發(fā)出去后應(yīng)該要等http code 101 Switching Protocols這個包回來才算握手完成，才可以建立tcp長連接，但是在nginx環(huán)境下這個包60秒后才回來，但是中間數(shù)據(jù)交互都是正常的，讓人匪夷所思。
再仔細看下nginx轉(zhuǎn)發(fā)wireshark包，發(fā)現(xiàn)http code 101 Switching Protocols包是由3片TCP包組裝而成的：
第一幀序號23，找到后發(fā)現(xiàn)內(nèi)容就是服務(wù)器響應(yīng)握手的http報文內(nèi)容
所以在25幀時實際已經(jīng)握手完成了，并非在62秒才傳包回來。
第二幀：
傳遞的數(shù)據(jù)是connected.
這樣就和協(xié)議描述一致，先完成handshake再transfer data。但是經(jīng)過nginx抓發(fā)的包一直沒有結(jié)束符，所以導(dǎo)致wireshark在斷連得時候才顯示該http報完成，此處不知是不是nginx websocket proxy的bug? 如果有大神知道還請指導(dǎo)。
