mars 是微信官方使用 C++ 編寫的業務性無關、平臺性無關的終端基礎組件，目前在微信 Android、iOS、Windows、Mac、Windows Phone 等多個平臺中使用，并正在籌備開源，它主要包含以下幾個獨立的部分：
本篇文章將為大家介紹 STN（信令傳輸網絡模塊），由于 STN 的復雜性，該模塊將被分解為多個篇章進行介紹，本文主要內容為微信中關于讀寫超時的思考與設計。
微信信令通信主要使用 TCP/IP 協議，數據經過應用層、傳輸層、網絡層、鏈路層（見圖1）。其中，鏈路層與傳輸層，協議提供了超時重傳的機制。
在鏈路層，一般使用混合自動重傳請求（即 HARQ）。HARQ 是一種結合 FEC（前饋式錯誤修正）與 ARQ（自動重傳請求）的技術，原理如圖2所示。
通過使用確認和超時這兩個機制，鏈路層在不可靠物理設備的基礎上實現可靠的信息傳輸。這個方案需要手機和 RNC 都支持，目前在 EDGE、HSDPA、HSUPA、UMTS和 LTE 上都已實現支持。
傳輸層（即 TCP 層）提供可靠的傳輸，然而，TCP 層依賴的鏈路本身是不可靠的，TCP 是如何在不可靠的環境中提供可靠服務的呢？答案是超時和重傳。TCP 在發送數據時設置一個定時器，當定時器溢出還沒有收到 ACK，則重傳該數據。因此，超時與重傳的關鍵之處在于如何決定定時器間隔與重傳頻率。
傳統 Unix 實現中，定時器的間隔取決于數據的往返時間（即 RTT），根據 RTT 進行一定的計算得到重傳超時間隔（即 RTO）。由于網絡路由、流量等的變化，RTT 是經常發生變化的，RTT 的測量也極為復雜（平滑算法、Karn 算法、Jacbson 算法等）。在《TCP/IP詳解》中，實際測量的重傳機制如圖3所示，重傳的時間間隔，取整后分別為1、3、6、12、24、48和多個64秒。這個倍乘的關系被稱為“指數退避”。
在移動終端中，RTO 的設計以及重試頻率的設計是否與傳統實現一致呢？對此我們進行了實測，實測數據如下：
圖4所示為OPPO手機TCP超時重傳的間隔，依次為[ 0.25s，0.5s，1s，2s，4s，8s，16s，32s，64s，64s，64s …]：
而 SamSung 中 TCP 超時重傳的間隔依次為[0.42s, 0.9s, 1.8s, 3.7s, 7.5s, 15s, 30s, 60s, 120s, 120s …]，見圖5。
經過多次實際測試我們可以看出雖然由于不同廠商的 Android 系統實現，RTO 的值可能會有不同的設定，但都基本符合“指數退避”原則。
接下來再看 iOS 系統中，TCP RTO 的實驗數據，圖6所示為實驗中次的數據[ 1s，1s，1s，2s，4.5s，9s，13.5s，26s，26s … ]。
上面的數據看起來并不完全符合指數退避，開始階段的重試會較為頻繁且 RTO 終固定在 26s 這一較小的值上。
進行第二次測試后發現數據有了新的變化[1s，1s，1s，2s，3.5s，8.5s，12.5s，24s，24s …]，如圖7所示。
RTO 終值由26秒縮減至24秒，終經過多次測試并未發現 iOS 中 TCP RTO 的規律，但可以看出 iOS 確實采用了較為激進的超時時間設定，對重試更為積極。
通過上述的調研與實驗，可以發現在 TCP/IP 中，協議棧已經幫助我們進行了超時與重傳的控制。并且在 Android、iOS 的移動操作系統中進行了優化，使用了更為積極的策略，以適應移動網絡不穩定的特征。
那是否意味著我們的應用層已經不需要超時與重傳的控制了呢？其實不然。在鏈路層，HARQ 提供的是節點之間每一數據幀的可靠傳輸；在傳輸層，TCP 超時重傳機制提供的是端與端之間每個 TCP 數據包的可靠傳輸；同理，在微信所處的應用層中，我們仍然需要提供以“請求”為粒度的可靠傳輸。
那么，應用層的超時重傳機制應該提供怎樣的服務呢？
首先，我們來看一下應用層重傳的做法。在應用層中，重傳的做法是：斷掉當前連接，重新建立連接并發送請求。這種重傳方式能帶來怎樣的作用呢？回顧 TCP 層的超時重傳機制可以發現，當發生超時重傳時，重傳的間隔以“指數退避”的規律急劇上升。在 Android 系統中，直到16分鐘，TCP 才確認失??；在 iOS 系統中，直到1分半到3分半之間，TCP 才確認失敗。這些數值在大部分應用中都是不為“用戶體驗”所接受的。因此，應用層的超時重傳的目標首先應是：
盡可能地增加成功率，是否意味著在有限的時間內，做盡可能多的重試呢？其實不然。當網絡為高延遲/低速率的網絡時，較快的應用層重傳會導致“請求”在這種網絡下很難成功。因此，應用層超時重傳的目標二：
TCP連接是有固定物理線路的連接，當已 Connect 的線路中，如果中間設備出現較大波動或嚴重擁塞，即使在限定時間內該請求能成功，但帶來的卻是性能低下，反應遲鈍的用戶體驗。通過應用層重連，期待的目標三是：
我們總結應用層超時重傳，可以帶來以下作用：
在TCP層的超時重傳設計中，超時間隔取決于RTT，RTT即TCP包往返的時間。同理，在微信的早期設計中，我們分析應用層“請求”的往返時間，將其RTT分解為：
因此，我們提出了應用層的總讀寫超時如圖8所示，低網速根據不同的網絡取不同的值。
在實際的使用過程中，我們發現這僅僅是一個可用的方案，并不是一個高性能的解決方案：超時時長的設置使用了差網絡下、完整的完成單次信令交互的時間估值。這使得超時時間過長，在網絡波動或擁塞時，無法敏感地發現問題并重試。進一步分析可以發現，我們無法預知服務器回包的大小，因此使用了大的回包進行估算（微信中目前大回包可到 128KB）。然而，TCP 傳輸中當發送數據大于 MSS 時，數據將被分段傳輸，分段到達接收端后重新組合。如果服務器的回包較大，客戶端可能會收到多個數據段。因此，我們可以對首個數據分段的到達時間進行預期，從而提出首包超時，如圖9所示。
首包超時縮短了發現問題的周期，但是我們發現如果首個數據分段按時到達，而后續數據包丟失的情況下，仍然要等待整個讀寫超時才能發現問題。為此我們引入了包包超時，即兩個數據分段之間的超時時間。因為包包超時在首包超時之后，這個階段已經確認服務器收到了請求，且完成了請求的處理，因此不需要計算等待耗時、請求傳輸耗時、服務器處理耗時，只需要估算網絡的 RTT。
在目前方案中，使用了不同網絡下的固定 RTT。由于有了“首包已收到”的上下文，使得包包超時的間隔大大縮短，從而提高了對網絡突然波動、擁塞、突發故障的敏感性，使得應用獲得較高的性能。
在上述的方案中，總讀寫超時、首包超時都使用了一些估值，使得這兩個超時是較大的值。假如我們能獲得實時的動態網速等，我們能獲得更好的超時機制，如圖10所示。
但是，理想是豐滿的，現實是殘酷的：
上述的三種途徑對客戶端和服務器都是巨大的流量、性能的消耗，所以動態化這些變量看起來并不可行。
因此，這里需要換個角度思考動態優化，手機的網絡狀況可以大概地歸為優質、正常、差三種情況，針對三種網絡狀況進行不同程度的調整，也是動態優化的一種手段。這里選擇優質網絡狀況進行分析：
根據對網絡狀況好的分析，我們可以做出這樣的優化（如圖11所示）：
進入Exc狀態后，就縮短信令收發的預期，即減小首包超時時間，這樣做的原因是我們認為用戶的網絡狀況好，可以設置較短的超時時間，當遇到網絡波動時預期它能夠快速恢復，所以可以盡快超時然后進行重試，從而改善用戶體驗。
雖然 TCP/IP 協議棧中的鏈路層、傳輸層都已經提供了超時重傳，保障了傳輸的可靠性。但應用層有著不同的可靠性需求，從而需要額外的應用層超時重傳機制來保障應用的高性能、高可用。應用層超時重傳的設計目標，筆者從自身經驗出發，總結為：
依從這些目標，mars STN 的超時重傳機制在使用中不斷的精細化演進，使用了包含總讀寫超時、首包超時、包包超時、動態超時等多種方案的綜合。即使如此，STN 的超時重傳機制也有著不少的缺點與局限性，例如相對適用于小數據傳輸的信令通道、局限于一來一回的通信模式等。mars STN 也會不斷發現新的問題持續演進，并且所有的演進都將在微信的海量用戶中進行驗證。同時也期待隨著 mars STN 的開源，能收獲更多、更廣的經驗交流、問題反饋、新想法的碰撞等。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
