前言

mars 是微信官方使用 C++ 編寫的業(yè)務(wù)性無關(guān)、平臺性無關(guān)的終端基礎(chǔ)組件，目前在微信 Android、iOS、Windows、Mac、Windows Phone 等多個平臺中使用，并正在籌備開源，它主要包含以下幾個獨立的部分：

1. COMM：基礎(chǔ)庫，包括 socket、線程、消息隊列、協(xié)程等基礎(chǔ)工具；
2. XLOG：通用日志模塊，充分考慮移動終端的特點，提供高性能、高可用、安全性、容錯性的日志功能；（詳情點擊：高性能日志模塊xlog ）
3. SDT：網(wǎng)絡(luò)診斷模塊；
4. STN：信令傳輸網(wǎng)絡(luò)模塊，負責(zé)終端與服務(wù)器的小數(shù)據(jù)信令通道。包含了微信終端在移動網(wǎng)絡(luò)上的大量優(yōu)化經(jīng)驗與成果，經(jīng)歷了微信海量用戶的考驗。

本篇文章將為大家介紹 STN（信令傳輸網(wǎng)絡(luò)模塊），由于 STN 的復(fù)雜性，該模塊將被分解為多個篇章進行介紹，本文主要內(nèi)容為微信中關(guān)于讀寫超時的思考與設(shè)計。

讀寫超時與設(shè)計目標

TCP/IP中的超時設(shè)計

微信信令通信主要使用 TCP/IP 協(xié)議，數(shù)據(jù)經(jīng)過應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層（見圖1）。其中，鏈路層與傳輸層，協(xié)議提供了超時重傳的機制。

鏈路層的超時與重傳

在鏈路層，一般使用混合自動重傳請求（即 HARQ）。HARQ 是一種結(jié)合 FEC（前饋式錯誤修正）與 ARQ（自動重傳請求）的技術(shù)，原理如圖2所示。

通過使用確認和超時這兩個機制，鏈路層在不可靠物理設(shè)備的基礎(chǔ)上實現(xiàn)可靠的信息傳輸。這個方案需要手機和 RNC 都支持，目前在 EDGE、HSDPA、HSUPA、UMTS和 LTE 上都已實現(xiàn)支持。

傳輸層的超時與重傳

傳輸層（即 TCP 層）提供可靠的傳輸，然而，TCP 層依賴的鏈路本身是不可靠的，TCP 是如何在不可靠的環(huán)境中提供可靠服務(wù)的呢？答案是超時和重傳。TCP 在發(fā)送數(shù)據(jù)時設(shè)置一個定時器，當定時器溢出還沒有收到 ACK，則重傳該數(shù)據(jù)。因此，超時與重傳的關(guān)鍵之處在于如何決定定時器間隔與重傳頻率。

傳統(tǒng) Unix 實現(xiàn)中，定時器的間隔取決于數(shù)據(jù)的往返時間（即 RTT），根據(jù) RTT 進行一定的計算得到重傳超時間隔（即 RTO）。由于網(wǎng)絡(luò)路由、流量等的變化，RTT 是經(jīng)常發(fā)生變化的，RTT 的測量也極為復(fù)雜（平滑算法、Karn 算法、Jacbson 算法等）。在《TCP/IP詳解》中，實際測量的重傳機制如圖3所示，重傳的時間間隔，取整后分別為1、3、6、12、24、48和多個64秒。這個倍乘的關(guān)系被稱為“指數(shù)退避”。

在移動終端中，RTO 的設(shè)計以及重試頻率的設(shè)計是否與傳統(tǒng)實現(xiàn)一致呢？對此我們進行了實測，實測數(shù)據(jù)如下：

圖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。

經(jīng)過多次實際測試我們可以看出雖然由于不同廠商的 Android 系統(tǒng)實現(xiàn)，RTO 的值可能會有不同的設(shè)定，但都基本符合“指數(shù)退避”原則。

接下來再看 iOS 系統(tǒng)中，TCP RTO 的實驗數(shù)據(jù)，圖6所示為實驗中第一次的數(shù)據(jù)[ 1s，1s，1s，2s，4.5s，9s，13.5s，26s，26s … ]。

上面的數(shù)據(jù)看起來并不完全符合指數(shù)退避，開始階段的重試會較為頻繁且 RTO 最終固定在 26s 這一較小的值上。

進行第二次測試后發(fā)現(xiàn)數(shù)據(jù)有了新的變化[1s，1s，1s，2s，3.5s，8.5s，12.5s，24s，24s …]，如圖7所示。

RTO 終值由26秒縮減至24秒，最終經(jīng)過多次測試并未發(fā)現(xiàn) iOS 中 TCP RTO 的規(guī)律，但可以看出 iOS 確實采用了較為激進的超時時間設(shè)定，對重試更為積極。

讀寫超時的目標

通過上述的調(diào)研與實驗，可以發(fā)現(xiàn)在 TCP/IP 中，協(xié)議棧已經(jīng)幫助我們進行了超時與重傳的控制。并且在 Android、iOS 的移動操作系統(tǒng)中進行了優(yōu)化，使用了更為積極的策略，以適應(yīng)移動網(wǎng)絡(luò)不穩(wěn)定的特征。

那是否意味著我們的應(yīng)用層已經(jīng)不需要超時與重傳的控制了呢？其實不然。在鏈路層，HARQ 提供的是節(jié)點之間每一數(shù)據(jù)幀的可靠傳輸；在傳輸層，TCP 超時重傳機制提供的是端與端之間每個 TCP 數(shù)據(jù)包的可靠傳輸；同理，在微信所處的應(yīng)用層中，我們?nèi)匀恍枰峁┮浴罢埱蟆睘榱６鹊目煽總鬏敗?/p>

那么，應(yīng)用層的超時重傳機制應(yīng)該提供怎樣的服務(wù)呢？

首先，我們來看一下應(yīng)用層重傳的做法。在應(yīng)用層中，重傳的做法是：斷掉當前連接，重新建立連接并發(fā)送請求。這種重傳方式能帶來怎樣的作用呢？回顧 TCP 層的超時重傳機制可以發(fā)現(xiàn)，當發(fā)生超時重傳時，重傳的間隔以“指數(shù)退避”的規(guī)律急劇上升。在 Android 系統(tǒng)中，直到16分鐘，TCP 才確認失?。辉?iOS 系統(tǒng)中，直到1分半到3分半之間，TCP 才確認失敗。這些數(shù)值在大部分應(yīng)用中都是不為“用戶體驗”所接受的。因此，應(yīng)用層的超時重傳的目標首先應(yīng)是：

• 在用戶體驗的接受范圍內(nèi)，盡可能地提高成功率

盡可能地增加成功率，是否意味著在有限的時間內(nèi)，做盡可能多的重試呢？其實不然。當網(wǎng)絡(luò)為高延遲/低速率的網(wǎng)絡(luò)時，較快的應(yīng)用層重傳會導(dǎo)致“請求”在這種網(wǎng)絡(luò)下很難成功。因此，應(yīng)用層超時重傳的目標二：

• 保障弱網(wǎng)絡(luò)下的可用性

TCP連接是有固定物理線路的連接，當已 Connect 的線路中，如果中間設(shè)備出現(xiàn)較大波動或嚴重擁塞，即使在限定時間內(nèi)該請求能成功，但帶來的卻是性能低下，反應(yīng)遲鈍的用戶體驗。通過應(yīng)用層重連，期待的目標三是：

• 具有網(wǎng)絡(luò)敏感性，快速的發(fā)現(xiàn)新的鏈路

我們總結(jié)應(yīng)用層超時重傳，可以帶來以下作用：

1. 減少無效等待時間，增加重試次數(shù)：當 TCP 層的重傳間隔已經(jīng)太大的時候，斷連重連，使得 TCP 層保持積極的重連間隔，提高成功率；
2. 切換鏈路：當鏈路存在較大波動或嚴重擁塞時，通過更換連接（一般會順帶更換IP&Port）獲得更好的性能。

微信讀寫超時

方案一：總讀寫超時

在TCP層的超時重傳設(shè)計中，超時間隔取決于RTT，RTT即TCP包往返的時間。同理，在微信的早期設(shè)計中，我們分析應(yīng)用層“請求”的往返時間，將其RTT分解為：

• 請求發(fā)送耗時 - 類比TCP包傳輸耗時；
• 響應(yīng)信令接收耗時 - 類比ACK傳輸耗時；
• 服務(wù)器處理請求耗時 - TCP接收端接收和處理數(shù)據(jù)包的時間相對固定，而微信服務(wù)器由于信令所屬業(yè)務(wù)的不同，邏輯處理的耗時會差異明顯，所以無法類比；
• 等待耗時 - 受應(yīng)用中請求并發(fā)數(shù)影響。

因此，我們提出了應(yīng)用層的總讀寫超時如圖8所示，最低網(wǎng)速根據(jù)不同的網(wǎng)絡(luò)取不同的值。

方案二：分步的讀寫超時

在實際的使用過程中，我們發(fā)現(xiàn)這僅僅是一個可用的方案，并不是一個高性能的解決方案：超時時長的設(shè)置使用了差網(wǎng)絡(luò)下、完整的完成單次信令交互的時間估值。這使得超時時間過長，在網(wǎng)絡(luò)波動或擁塞時，無法敏感地發(fā)現(xiàn)問題并重試。進一步分析可以發(fā)現(xiàn)，我們無法預(yù)知服務(wù)器回包的大小，因此使用了最大的回包進行估算（微信中目前最大回包可到 128KB）。然而，TCP 傳輸中當發(fā)送數(shù)據(jù)大于 MSS 時，數(shù)據(jù)將被分段傳輸，分段到達接收端后重新組合。如果服務(wù)器的回包較大，客戶端可能會收到多個數(shù)據(jù)段。因此，我們可以對首個數(shù)據(jù)分段的到達時間進行預(yù)期，從而提出首包超時，如圖9所示。

首包超時縮短了發(fā)現(xiàn)問題的周期，但是我們發(fā)現(xiàn)如果首個數(shù)據(jù)分段按時到達，而后續(xù)數(shù)據(jù)包丟失的情況下，仍然要等待整個讀寫超時才能發(fā)現(xiàn)問題。為此我們引入了包包超時，即兩個數(shù)據(jù)分段之間的超時時間。因為包包超時在首包超時之后，這個階段已經(jīng)確認服務(wù)器收到了請求，且完成了請求的處理，因此不需要計算等待耗時、請求傳輸耗時、服務(wù)器處理耗時，只需要估算網(wǎng)絡(luò)的 RTT。

在目前方案中，使用了不同網(wǎng)絡(luò)下的固定 RTT。由于有了“首包已收到”的上下文，使得包包超時的間隔大大縮短，從而提高了對網(wǎng)絡(luò)突然波動、擁塞、突發(fā)故障的敏感性，使得應(yīng)用獲得較高的性能。

方案三：動態(tài)的讀寫超時

在上述的方案中，總讀寫超時、首包超時都使用了一些估值，使得這兩個超時是較大的值。假如我們能獲得實時的動態(tài)網(wǎng)速等，我們能獲得更好的超時機制，如圖10所示。

但是，理想是豐滿的，現(xiàn)實是殘酷的：

• 動態(tài)網(wǎng)速需要通過工具方法測定，實時性要求高，并且要考慮網(wǎng)絡(luò)波動的影響；
• 服務(wù)器動態(tài)耗時需要服務(wù)器下發(fā)不同業(yè)務(wù)信令的處理耗時；
• 真實回包大小則只能靠服務(wù)器通知。

上述的三種途徑對客戶端和服務(wù)器都是巨大的流量、性能的消耗，所以動態(tài)化這些變量看起來并不可行。

因此，這里需要換個角度思考動態(tài)優(yōu)化，手機的網(wǎng)絡(luò)狀況可以大概地歸為優(yōu)質(zhì)、正常、差三種情況，針對三種網(wǎng)絡(luò)狀況進行不同程度的調(diào)整，也是動態(tài)優(yōu)化的一種手段。這里選擇優(yōu)質(zhì)網(wǎng)絡(luò)狀況進行分析：

• 如何判定網(wǎng)絡(luò)狀況好？網(wǎng)速快、穩(wěn)定，網(wǎng)絡(luò)模塊中與之等價的是能夠短時間完成信令收發(fā)，并且能夠連續(xù)長時間地完成短時間內(nèi)信令收發(fā)。
• 即使出現(xiàn)網(wǎng)絡(luò)波動，也可以預(yù)期會很快恢復(fù)。

根據(jù)對網(wǎng)絡(luò)狀況好的分析，我們可以做出這樣的優(yōu)化（如圖11所示）：

• 將客戶端網(wǎng)絡(luò)環(huán)境區(qū)分為優(yōu)良（Excellent）、評估（Evaluating）兩種狀態(tài)；
• 網(wǎng)速快、穩(wěn)定就是條件1，信令失敗或網(wǎng)絡(luò)類型切換是條件2。

進入Exc狀態(tài)后，就縮短信令收發(fā)的預(yù)期，即減小首包超時時間，這樣做的原因是我們認為用戶的網(wǎng)絡(luò)狀況好，可以設(shè)置較短的超時時間，當遇到網(wǎng)絡(luò)波動時預(yù)期它能夠快速恢復(fù)，所以可以盡快超時然后進行重試，從而改善用戶體驗。

總結(jié)

雖然 TCP/IP 協(xié)議棧中的鏈路層、傳輸層都已經(jīng)提供了超時重傳，保障了傳輸?shù)目煽啃浴５珣?yīng)用層有著不同的可靠性需求，從而需要額外的應(yīng)用層超時重傳機制來保障應(yīng)用的高性能、高可用。應(yīng)用層超時重傳的設(shè)計目標，筆者從自身經(jīng)驗出發(fā)，總結(jié)為：

• 在用戶體驗的接受范圍內(nèi)，盡可能地提高成功率；
• 保障弱網(wǎng)絡(luò)下的可用性；
• 具有網(wǎng)絡(luò)敏感性，快速地發(fā)現(xiàn)新的鏈路。

依從這些目標，mars STN 的超時重傳機制在使用中不斷的精細化演進，使用了包含總讀寫超時、首包超時、包包超時、動態(tài)超時等多種方案的綜合。即使如此，STN 的超時重傳機制也有著不少的缺點與局限性，例如相對適用于小數(shù)據(jù)傳輸?shù)男帕钔ǖ?、局限于一來一回的通信模式等。mars STN 也會不斷發(fā)現(xiàn)新的問題持續(xù)演進，并且所有的演進都將在微信的海量用戶中進行驗證。同時也期待隨著 mars STN 的開源，能收獲更多、更廣的經(jīng)驗交流、問題反饋、新想法的碰撞等。