本文作者網易智慧企業web前端開發工程師馬瑩瑩。為了提升內容質量，收錄時有修訂和改動。
1、引言
在一個完善的即時通訊IM應用中，WebSocket是極其關鍵的一環，它為基於Web的即時通訊應用提供了一種全雙工的通信機制。但為了提升IM等實際應用場景下的消息即時性和可靠性，我們需要克服WebSocket及其底層依賴的TCP連接對於複雜網絡情況下的不穩定性，即時通訊的開發者們通常都需要為其設計一套完整的連接保活、驗活以及斷片網重連方案。
就斷網重連而言，其重連響應速度將嚴重影響了上層應用的「即時性」和用戶體驗。試想打開網絡一分鐘後，微信的網絡不能即時感知到socket連接的恢復，無法即時收發聊天消息的話，是不是很崩潰？
因此，如何在複雜網絡場景下，更即時快速地感知網絡變動，並快速恢復WebSocket的可用性，就變得尤為重要。本文將基於筆者的開發實踐，分享WebSocket在不同狀態下、不同的網絡狀態下，應該如何實現快速斷網重連。
* 閱讀對象：本文適合有過IM底層網絡實際開發經驗，或者對底層網絡實現有較深了解的開發者閱讀。如果對底層網絡了解甚少，建議跳過本文，直接閱讀網絡本文末尾附錄部分的基礎後再回頭來看。
* 內容點評：本文內容沒有高大上，但比較乾貨，實用性較高，內容也很通俗，建議可詳細閱讀。文中雖講的是WebSocket，但思想可以延伸應用到基於TCP協議的同類技術中。
本文已同步發布於「即時通訊技術圈」公眾號。
2、預備知識
本文中將要分享的內容是基於實踐總結，如果你對Web端的即時通訊知識還一頭霧水，務必先讀：《新手入門貼：史上最全Web端即時通訊技術原理詳解》、《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》。
限於篇幅，本文不會深究WebSocket技術細節，如有興趣請系統學習：
《新手快速入門：WebSocket簡明教程》《WebSocket詳解（一）：初步認識WebSocket技術》《WebSocket詳解（二）：技術原理、代碼演示和應用案例》《WebSocket詳解（三）：深入WebSocket通信協議細節》《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關係(上篇)》《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關係(下篇)》《WebSocket詳解（六）：刨根問底WebSocket與Socket的關係》3、快速了解WebSocket
Websocket誕生於2008年，在2011年成為國際標準，現在所有的瀏覽器都已支持（詳見《新手快速入門：WebSocket簡明教程》）。它是一種全新的應用層協議，是專門為web客戶端和服務端設計的真正的全雙工通信協議，可以類比HTTP協議來了解websocket協議。
（圖片引用自《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關係(上篇)》）
它們的不同點：
1）HTTP的協議標識符是http，WebSocket的是ws；2）HTTP請求只能由客戶端發起，伺服器無法主動向客戶端推送消息，而WebSocket可以；3）HTTP請求有同源限制，不同源之間通信需要跨域，而WebSocket沒有同源限制。它們的相同點：
1）都是應用層的通信協議；2）默認埠一樣，都是80或443；3）都可以用於瀏覽器和伺服器間的通信；4）都基於TCP協議。兩者和TCP的關係圖：
（圖片引用自《新手快速入門：WebSocket簡明教程》）
有關Http和WebSocket的關係，可以詳讀：
《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關係(上篇)》《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關係(下篇)》有關WebSocket和Socket的關係，可以詳讀：《WebSocket詳解（六）：刨根問底WebSocket與Socket的關係》.
4、WebSocket重連過程拆解
首先考慮一個問題，何時需要重連？
最容易想到的是WebSocket連接斷了，為了接下來能收發消息，我們需要再發起一次連接。
但在很多場景下，即便WebSocket連接沒有斷開，實際上也不可用了。
比如以下場景：
1）設備切換網絡；2）鏈路中間路由崩潰（常識是一條socket連接對應的網絡通路上，會存在很多路由設備）；3）鏈路的前端出口不可用（比如家庭WiFi中，網絡連接正常，但實際運營商的寬帶已經欠費被停機）；4）伺服器負載持續過高無法響應等。這些場景下的WebSocket都沒有斷開，但對上層來說，都沒辦法正常的收發數據了。
因此在重連前，我們需要一種機制來感知連接是否可用、服務是否可用，而且要能快速感知，以便能夠快速從不可用狀態中恢復。
一旦感知到了連接不可用，那便可以棄舊圖新了，棄用並斷開舊連接，然後發起一次新連接。這兩個步驟看似簡單，但若想達到快，且不是那麼容易的。
首先：是斷開舊連接，對客戶端來說，如何快速斷開？協議規定客戶端必須要和伺服器協商後才能斷開WebSocket連接，但是當客戶端已經聯繫不上伺服器、無法協商時，如何斷開並快速恢復？
其次：是快速發起新連接。此快非彼快，這裡的快並非是立即發起連接，立即發起連接會對伺服器帶來不可預估的影響。重連時通常會採用一些退避算法，延遲一段時間後再發起重連。但如何在重連間隔和性能消耗間做出權衡？如何在「恰當的時間點」快速發起連接？
帶著這些疑問，我們來細看下這三個過程：
5、快速重連關鍵1：快速感知何時需要重連
5.1 場景
需要重連的場景可以細分為三種：
1）連接明確斷開了；2）連接沒斷但是不可用了；3）連接對端的服務不可用了。對於第一種場景：這很簡單，連接直接斷開了，肯定需要重連了。
對於後兩者：無論是連接不可用，還是服務不可用，對上層應用的影響都是不能再收發即時消息了。
5.2 心跳包主動探測網絡可用性
所以從上面這個角度出發，感知何時需要重連的一種簡單粗暴的方法就是通過心跳包超時：發送一個心跳包，如果超過特定的時間後還沒有收到伺服器回包，則認為服務不可用，如下圖中左側的方案（這種方法最直接）。
那如果想要快速感知呢，就只能多發心跳包，加快心跳頻率。但是心跳太快對移動端流量、電量的消耗又會太多，所以使用這種方法沒辦法做到快速感知，可以作為檢測連接和服務可用的兜底機制。
5.3 被動監聽網絡狀態改變
如果要檢測連接不可用，除了用心跳檢測，還可以通過判斷網絡狀態來實現，因為斷網、切換wifi、切換網絡是導致連接不可用的最直接原因，所以在網絡狀態由offline變為online時，大多數情況下需要重連下，但也不一定，因為webscoket底層是基於TCP的，TCP連接不能敏銳的感知到應用層的網絡變化，所以有時候即便網絡斷開了一小會，對WebSocket連接是不會有影響的，網絡恢復後，仍然能夠正常地進行通信。
因此在網絡由斷開到連接上時，立即判斷下連接是否可用，可以通過發一個心跳包判斷，如果能夠正常收到伺服器的心跳回包，則說明連接仍是可用的，如果等待超時後仍沒有收到心跳回包，則需要重連，如上圖中的右側。這種方法的優點是速度快，在網絡恢復後能夠第一時間感知連接是否可用，不可用的話可以快速執行恢復，但它只能覆蓋應用層網絡變化導致WebSocket不可用的情況。
5.4 小結
綜上所述：
1）定時發送心跳包檢測的方案貴在穩定，能夠覆蓋所有場景，但速度不即時（心跳間隔是固定的）；2）判斷網絡狀態的方案速度快，無需等待心跳間隔，較為靈敏，但覆蓋場景較為局限。因此，我們可以結合兩種方案：
1）定時以不太快的頻率發送心跳包，比如40s/次、60s/次等，具體可以根據應用場景來定；2）然後在網絡狀態由offline變為online時立即發送一次心跳，檢測當前連接是否可用，不可用的話立即進行恢復處理。這樣在大多數情況下，上層的應用通信都能較快從不可用狀態中恢復，對於少部分場景，有定時心跳作為兜底，在一個心跳周期內也能夠恢復。
6、快速重連關鍵2：快速斷開舊連接
通常情況下，在發起下一次連接前，如果舊連接還存在的話，應該先把舊連接斷開。
這樣做的目的：
1）一來可以釋放客戶端和伺服器的資源；2）二來可以避免之後誤從舊連接收發數據。我們知道WebSocket底層是基於TCP協議傳輸數據的，連接兩端分別是伺服器和客戶端，而TCP的TIME_WAIT狀態是由伺服器端維持的，因此在大多數正常情況下，應該由伺服器發起斷開底層TCP連接，而不是客戶端。
也就是說：
1）要斷開WebSocket連接時，如果是伺服器收到指示要斷開WebSocket，那它應該立即發起斷開TCP連接；2）如果是客戶端收到指示要斷開WebSocket，那它應該發信號給伺服器，然後等待底層TCP連接被伺服器斷開或直至超時。那如果客戶端想要斷開舊的WebSocket，可以分為WebSocket連接可用和不可用兩種情況來討論。
具體如下：
1）當舊連接可用時，客戶端可以直接給伺服器發送斷開信號，然後伺服器發起斷開連接即可；2）當舊連接不可用時，比如客戶端切換了wifi，客戶端發送了斷開信號，但是伺服器收不到，客戶端只能遲遲等待，直至超時才能被允許斷開。超時斷開的過程相對來說是比較久的，那有沒有辦法可以快點斷開？
上層應用無法改變只能由伺服器發起斷開連接這種協議層面的規則，所以只能從應用邏輯入手，比如在上層通過業務邏輯保證舊連接完全失效，模擬連接斷開，然後在發起新連接，恢復通訊。
這種方法相當於嘗試斷開舊連接不行時，直接棄之，然後就能快速進入下一流程，所以在使用時一定要確保在業務邏輯上舊連接已完全失效。
比如：
1）保證丟掉從舊連接收到所有數據；2）舊連接不能阻礙新連接的建立3）舊連接超時斷開後不能影響新連接和上層業務邏輯等等。7、快速重連關鍵3：快速發起新連接
有IM開發經驗的同學應該有所了解，遇到因網絡原因導致的重連時，是萬萬不能立即發起一次新連接的，否則當出現網絡抖動時，所有的設備都會立即同時向伺服器發起連接，這無異於黑客通過發起大量請求消耗網絡帶寬引起的拒絕服務攻擊，這對伺服器來說簡直是災難（即：服務端雪崩效應）。
所以在重連時通常採用一些退避算法，延遲一段時間再發起重連，如下圖中左側的流程。
如果要快速連上呢？最直接的做法就是縮短重試間隔，重試間隔越短，在網絡恢復後就能越快的恢復通訊。但是太頻繁的重試對性能、帶寬、電量的消耗就比較嚴重。
如何在這之間做一個較好的權衡呢？
1）一種比較合理的方式是隨著重試次數增多，逐漸增大重試間隔；2）另一方面監聽網絡變化，在網絡狀態由offline變為online這種比較可能重連上的時刻，適當地減小重連間隔。上述第2）種方案，如上圖中的右側所示，隨重試次數的增多，重連間隔也會變大。這兩種方式配合使用，更為合理。
除此之外，還可以結合業務邏輯，根據成功重連上的可能性適當的調整間隔，如網絡未連接時或應用在後臺時重連間隔可以調大一些，網絡正常的狀態下可以適當調小一些等等，加快重連上的速度。
8、本文小結
最後總結一下。
本文將WebSocket斷網重連邏輯細分為三個步驟：
1）確定何時需要重連；2）斷開舊連接；3）發起新連接。然後分別分析了在WebSocket的不同狀態下、不同的網絡狀態下，如何快速完成這個三個步驟。
過程具體總結就是：
1）首先：通過定時發送心跳包的方式檢測當前連接是否可用，同時監測網絡恢復事件，在恢復後立即發送一次心跳，快速感知當前狀態，判斷是否需要重連；2）其次：正常情況下由伺服器斷開舊連接，與伺服器失去聯繫時直接棄用舊連接，上層模擬斷開，來實現快速斷開；3）最後：發起新連接時使用退避算法延遲一段時間再發起連接，同時考慮到資源浪費和重連速度，可以在網絡離線時調大重連間隔，在網絡正常或網絡由offline變為online時縮小重連間隔，使之儘可能快地重連上。以上就是我關於如何實現WebSocket快速重連的技術分享，歡迎留言與我探討。
9、參考資料
[1] RFC 6455 文檔
[2] 新手快速入門：WebSocket簡明教程
[3] WebSocket詳解（四）：刨根問底HTTP與WebSocket的關係(上篇)
[4] WebSocket詳解（五）：刨根問底HTTP與WebSocket的關係(下篇)
[5] WebSocket詳解（六）：刨根問底WebSocket與Socket的關係
附錄：更多Web端即時通訊資料
《新手入門貼：史上最全Web端即時通訊技術原理詳解》《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》《SSE技術詳解：一種全新的HTML5伺服器推送事件技術》《Comet技術詳解：基於HTTP長連接的Web端實時通信技術》《socket.io實現消息推送的一點實踐及思路》《LinkedIn的Web端即時通訊實踐：實現單機幾十萬條長連接》《Web端即時通訊技術的發展與WebSocket、Socket.io的技術實踐》《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》《開源框架Pomelo實踐：搭建Web端高性能分布式IM聊天伺服器》《使用WebSocket和SSE技術實現Web端消息推送》《詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket》《MobileIMSDK-Web的網絡層框架為何使用的是Socket.io而不是Netty？》《理論聯繫實際：從零理解WebSocket的通信原理、協議格式、安全性》《微信小程序中如何使用WebSocket實現長連接(含完整源碼)》《八問WebSocket協議：為你快速解答WebSocket熱門疑問》《快速了解Electron：新一代基於Web的跨平臺桌面技術》《一文讀懂前端技術演進：盤點Web前端20年的技術變遷史》《Web端即時通訊基礎知識補課：一文搞懂跨域的所有問題！》《Web端即時通訊實踐乾貨：如何讓你的WebSocket斷網重連更快速？》>> 更多同類文章 ……
（本文同步發布於：http://www.52im.net/thread-3098-1-1.html）