什么是微信的Mars
Mars是微信在2017年開源的一套跨平臺跨業(yè)務的基礎組件。在這里可以給出github上的官方架構圖
從上面的架構圖中我們可以看到，Mars主要包含了一下幾個部分：
STN：STN是微信的網(wǎng)絡傳輸信令模塊，是mars組件中終端和服務端進行通訊的小數(shù)據(jù)信令通道。STN模塊包含了微信在海量用戶使用上作出的一系列優(yōu)化和嘗試，特別是在弱網(wǎng)絡情況下有非常不錯的效果
SDT：Mars的網(wǎng)絡診斷工具，這里包含了Mars對當前網(wǎng)絡狀態(tài)的定義，包括：優(yōu)質網(wǎng)、正常網(wǎng)和弱網(wǎng)絡等的界定。這對于下面我們要進行分析的智能心跳和STN超時機制有非常密切的關系。
XLOG：基于mmap讀寫的一套日志框架，具體的分析可以看我之前的一篇文章
騰訊Xlog接入指南與踩過的坑
Comm:主要包含了消息隊列，鎖，時鐘還有線程管理等，基礎Comm不在本次的分析介紹之內
為什么要使用Mars
通過研究和學習，為什么要使用Mars我這里做了幾點小結
1 如果你的應用只是一個普通的APP，并不涉及到即時通訊，或者你們的APP對于消息的即時性沒有很強的要求，那么我比較推薦你只單獨使用Mars的Xlog組件就可以了。這對你們app的日志管理，線上問題追蹤和定位具有非常好的幫助。在接入了Xlog后，出現(xiàn)線上問題我們上家公司幾乎可以做到5分鐘內定位問題，10分鐘給出解決方案。
2 STN組件的設計邏輯非常的貼合移動互聯(lián)網(wǎng)的網(wǎng)絡使用環(huán)境，是一套非常成功的解決方案，尤其是弱網(wǎng)環(huán)境和平臺特性具有非常多的優(yōu)化策略
3 Mars 是基于socket的解決方案，在網(wǎng)絡調優(yōu)方面具有跟強的主動性和可控性。
Mars 的超時機制
TCP的超時重傳
熟悉TCP傳輸協(xié)議的同學都知道，TCP在建立連接的情況下，如果當前的請求方?jīng)]有在規(guī)定的時間內得到接收方的相應，那么就會發(fā)生重傳的機制，這個也是TCP保證可靠性傳輸?shù)囊粋€重要的原則。我們在了解超時和重傳是需要了解的兩個指標
RTT：數(shù)據(jù)往返的時間；
RTO：超時重傳的時間間隔
這里盜一張mars的官方圖，我們來看下Android手機的tcp超時重傳的時間間隔表現(xiàn)
從途中我們可以看到，超時重傳的間隔，依次為[ 0.25s，0.5s，1s，2s，4s，8s，16s，32s，64s，64s，64s …]
我們可以看到，前面的重傳時間還有一定的時間間隔，但后面是幾個連續(xù)的64s。這個算法其實就是指數(shù)退避的算法。
Mars的超時重傳機制
是不是傳輸層已經(jīng)有了超時重傳機制，應用層就不需要了呢？其實不是的，我們可以知道tcp在經(jīng)過一定的超時重傳后才會確定當前的tcp不可用，返回timeout標示。但是這個時間非常的就，一般來說Android手機大概要6min才會確定當前的TCP連接不可用。但是對于移動端來說6min的時間是非常影響用戶體驗的，因此應用層的超時重傳機制需要更加的敏捷。
但是需要注意，敏捷并不等于密集。在很多的場景下，密集的心跳機制并不能取到重新建連的效果，反而會是網(wǎng)絡通道更加的惡劣。因此在經(jīng)過多個嘗試后，Mars采用了一下的幾個超時方案
總讀寫超時
總讀寫時間這個比較好理解，就是一次完成的RTT所需要的時間，這里總結起來包括：
請求發(fā)送耗時 - 類比TCP包傳輸耗時；
響應信令接收耗時 - 類比ACK傳輸耗時；
服務器處理請求耗時 - TCP接收端接收和處理數(shù)據(jù)包的時間相對固定，而服務器由于信令所屬業(yè)務的不同，邏輯處理的耗時會差異明顯，所以無法類比；
等待耗時 - 受應用中請求并發(fā)數(shù)影響。
因此，我們提出了應用層的總讀寫超時如右圖所示，最低網(wǎng)速根據(jù)不同的網(wǎng)絡取不同的值。
首包超時
總讀寫超時有一個弊端是無法確定服務端的處理請求時間，最致命的一點是相應信令的時間處理較長，這導致了在網(wǎng)絡狀態(tài)很差的情況下，同樣需要較長的時間才可以進行重試。首包超時是指在tcp的第一次回包的情況就去確定這個信令的接受耗時。調整后的首包超時方案如下
包包超時
首包超時有一個弊端，就是在網(wǎng)絡堵塞的情況下，由于tcp的擁塞窗口和流量控制，一個tcp包會被切割成幾個部分進行傳輸，也就是發(fā)生了tcp的拆包和粘包的現(xiàn)象。加入后續(xù)的包又丟失了，仍然需要整個完整的讀寫超時才能發(fā)生問題。這就引入了包包超時的機制：兩個數(shù)據(jù)段之間的超時時間。因為包包超時在首包超時之后，這個階段已經(jīng)確認服務器收到了請求，且完成了請求的處理，因此不需要計算等待耗時、請求傳輸耗時、服務器處理耗時，只需要估算網(wǎng)絡的 RTT。
動態(tài)超時
動態(tài)讀寫超級更多的是依賴于當前的網(wǎng)絡狀況，這個網(wǎng)絡狀態(tài)評估就跟之前提到的SDT模塊有著莫大的關系。Mars在動態(tài)超時的設計中，把當前的網(wǎng)絡分為excellent和evaluate兩種狀態(tài)，分別在這兩種狀態(tài)中不停的調整當前的動態(tài)耗時。
Mars 的連接方案-復合連接
我們先總結一下串行連接和并行的優(yōu)缺點
串行連接：
1 資源占用小，服務端沒有負載的壓力
2 超時選擇困難，連接最慢可用
并行連接
1 資源占用較大，服務端負債壓力大
2 連接最快可用
復合連接
先看一下官方給的圖
初始階段，應用發(fā)起對 IP1 &Port1 的 connect 調用。在第4秒的時候，如果第一個 connect 還沒有返回，則發(fā)起對 IP2 &Port2 的 connect 調用。以此類推，直至發(fā)起了5組 IP&Port 的 connect 調用。
對比串行連接與并行連接，復合連接有以下特點：
常規(guī)情況下，服務器負載與串行連接策略相同，實現(xiàn)了低負載的目標；
異常情況下，每4s發(fā)起新（IP，Port）組合的 connect 調用，使得應用可以快速的查找可用 IP&Port，實現(xiàn)高性能的目標；
在超時時間的選擇上，復合方式的“并發(fā)”已經(jīng)實現(xiàn)了高性能、低負載的目標，因此在超時時間的選擇上可以相對寬松，以保障高可用為重。
綜合對比，復合連接能夠維持低資源消耗的情況下，能同時實現(xiàn)低負載、高性能、高可用的目標。
Mars的智能心跳
智能心跳指的是長連接過程中，應用層維護的自己和服務端的心跳連接?？蛻舳嗽谶m當?shù)臅r間周期內，向服務端發(fā)送一個心跳請求，判斷當前的連接是否可用。一般的app處理是用一個定時的任務（45s）連續(xù)的向服務端發(fā)送ping請求，等待服務端的返回。如果心痛不同，則認為當前的長連接不可用，需要重新進行長連接的建聯(lián)。
微信的智能心跳如下
心跳時間區(qū)間：最小4分30秒，最大9分50秒；
心跳增加步長：60秒；心跳穩(wěn)定后，探測步長：20秒；
當前APP為活躍狀態(tài)，長連剛連接前3個成功心跳，和沒有網(wǎng)絡，這3種情況使用固定最小心跳：4分30秒；其他情況使用自適應智能心跳，基本算法如下；
連續(xù)3個心跳成功后，每心跳增加60秒心跳步長，一直到最大9分50秒，設為固定狀態(tài)；
連續(xù)3個心跳失敗后，減少60+20秒，第4個心跳失敗，直接設最小心跳4分30秒；
