看了Joy一篇關(guān)于網(wǎng)絡(luò)部分優(yōu)化的文章，總結(jié)一下般又，方便以后查閱使用

目前客戶端存在的網(wǎng)絡(luò)問題主要有下面幾方面：

1.網(wǎng)絡(luò)成功率低碰酝，經(jīng)常請(qǐng)求失敗
2.用戶反饋 DNS 劫持，數(shù)據(jù)被篡改澎迎，出現(xiàn)廣告和請(qǐng)求超時(shí)等情況
3.網(wǎng)絡(luò)延遲較長，且存在較多的長尾數(shù)據(jù)
4.經(jīng)過數(shù)據(jù)分析选调，發(fā)現(xiàn)長連的時(shí)間明顯比短連的時(shí)間少 100ms 左右（短連指的是夹供，經(jīng)過DNS解析、 TCP 握手仁堪、 SSL 握手等一系列的過程建立連接哮洽，長連指的是直接復(fù)用前者的連接通道）
5.網(wǎng)絡(luò)經(jīng)常出現(xiàn)抖動(dòng)，本來大部分請(qǐng)求都是 100ms 左右弦聂，突然冒出來一兩千毫秒的鸟辅，甚至有10、20秒的延遲情況
6.HTTP 1.1的head of blocking 情況存在莺葫，一個(gè)網(wǎng)絡(luò)抖動(dòng)匪凉，很容易影響后續(xù)的請(qǐng)求，導(dǎo)致一連串的延遲較高請(qǐng)求（head of blocking：指的是在 HTTP 1.1 中捺檬，如果你發(fā)出1再层、2、3 三個(gè)網(wǎng)絡(luò)請(qǐng)求堡纬，那么 Response 的順序 2聂受、3 要在第一個(gè)網(wǎng)絡(luò)請(qǐng)求之后）
7.傳輸?shù)?Payload 太大，延遲高隐轩，易超時(shí)
8.蘋果要求HTTPS 饺饭，此時(shí)加入的 SSL 握手較耗時(shí)

下面分別針對(duì)上面的幾個(gè)問題，看各個(gè)大廠是如何解決的：

網(wǎng)絡(luò)成功率低职车，經(jīng)常請(qǐng)求失敗######

1.攜程:
??受TCP協(xié)議重傳機(jī)制來保證可靠傳輸?shù)臋C(jī)制啟發(fā)，我們?cè)趹?yīng)用層面也引入了重試機(jī)制來提高網(wǎng)絡(luò)服務(wù)成功率。我們發(fā)現(xiàn)90%以上的的網(wǎng)絡(luò)服務(wù)失敗都是由于網(wǎng)絡(luò)連接失敗悴灵，此時(shí)再次重試是有機(jī)會(huì)連接成功并完成服務(wù)的扛芽；同時(shí)我們發(fā)現(xiàn)前面提到的網(wǎng)絡(luò)服務(wù)生命周期處于1建立連接、序列化網(wǎng)絡(luò)請(qǐng)求報(bào)文积瞒、發(fā)送網(wǎng)絡(luò)請(qǐng)求這三個(gè)階段失敗時(shí)川尖，都是可以自動(dòng)重試的，因?yàn)槲覀兛梢源_信請(qǐng)求還沒有達(dá)到服務(wù)端進(jìn)行處理茫孔，不會(huì)產(chǎn)生冪等性問題（如果存在冪等性問題叮喳，會(huì)出現(xiàn)重復(fù)訂單等情況）。當(dāng)網(wǎng)絡(luò)服務(wù)需要重試時(shí)缰贝，會(huì)使用短連接進(jìn)行補(bǔ)償馍悟，而不再使用長連接。
??實(shí)現(xiàn)了上述機(jī)制后剩晴，攜程App網(wǎng)絡(luò)服務(wù)成功率由原先的95.3%+提升為如今的99.5%+（這里的服務(wù)成功率是指端到端服務(wù)成功率锣咒，即客戶端采集的服務(wù)成功數(shù)除以請(qǐng)求總量計(jì)算的，并且不區(qū)分當(dāng)前網(wǎng)絡(luò)狀況）赞弥，效果顯著毅整。

2.Peak老師的解決方案（非常完善了）
??可靠性保障也是個(gè)容易被忽視的方面，在深入探討之前绽左，可以先將Request按業(yè)務(wù)屬性分類悼嫉。
??1.第一類：關(guān)鍵核心的業(yè)務(wù)數(shù)據(jù)，期望能100%送達(dá)服務(wù)器拼窥。
??2.第二類：重要內(nèi)容請(qǐng)求承粤，需要較高的請(qǐng)求成功率.
??3.第三類：一般性內(nèi)容請(qǐng)求，對(duì)成功率無要求闯团。
??之所以要將請(qǐng)求分為三類辛臊，是要在可靠性保障上做區(qū)分。理論上我們應(yīng)該盡可能讓所有的請(qǐng)求成功率達(dá)到最高房交，但客戶端的流量彻舰，帶寬，手機(jī)電量候味，服務(wù)器的壓力等都是有限的資源刃唤，所以我們采取的策略是只對(duì)關(guān)鍵性的網(wǎng)絡(luò)請(qǐng)求做高強(qiáng)度的可靠性保障。
??第一類請(qǐng)求類似大家用微信時(shí)發(fā)送的消息白群，消息數(shù)據(jù)一旦從輸入框發(fā)出尚胞，從用戶來的角度感知這個(gè)消息數(shù)據(jù)是一定會(huì)到達(dá)對(duì)方的。如果網(wǎng)絡(luò)環(huán)境差帜慢，網(wǎng)絡(luò)模塊會(huì)自動(dòng)在后頭悄悄重試笼裳，一段時(shí)間后仍無法成功就通過產(chǎn)品交互的方式告知用戶發(fā)送失敗了唯卖，即使失敗，請(qǐng)求的數(shù)據(jù)（消息本身）一直存在客戶端躬柬。
??對(duì)于這類請(qǐng)求的處理方式第一步不是通過網(wǎng)絡(luò)發(fā)送拜轨，而是持久化到Database當(dāng)中。一旦入了DB允青，即使斷網(wǎng)橄碾，斷電，重啟颠锉，請(qǐng)求數(shù)據(jù)依然還在法牲，只需在App重啟的時(shí)候還原請(qǐng)求數(shù)據(jù)，再次發(fā)送即可琼掠。我們用代碼來進(jìn)一步闡釋

//定義請(qǐng)求可靠性類型
typedef enum : NSUInteger {
    PPRequestReliability_PersistentToDB,
    PPRequestReliability_Retry,
    PPRequestReliability_Normal,
} PPRequestReliability;

//增加持久化接口
@interface PPRequest : NSObject

@property (nonatomic, assign) PPRequestReliability    reliability;
@property (nonatomic, strong) NSNumber*               rowID;
@property (nonatomic, strong) NSNumber*               reliabilityStatus;

- (PPRequestRecord*)serializeToRecord;
- (PPRequest*)deserializeFromRecord:(PPRequestRecord*)record;

@end

??第一類請(qǐng)求是PPRequestReliability_PersistentToDB拒垃，新增了rowID用作存儲(chǔ)DB時(shí)的唯一標(biāo)識(shí)，reliabilityStatus表示請(qǐng)求的當(dāng)前狀態(tài)（成功 or 失敗 or 取消 or 進(jìn)行中）眉枕，我們?cè)倏聪掳l(fā)送請(qǐng)求的流程恶复。

@implementation PPRequestManager

- (void)sendRequest:(PPRequest*)req withDelegate:(id)delegate
{
    if (req.reliability == PPRequestReliability_PersistentToDB) {
        PPRequestRecord* record = [req serializeToRecord];
        //save record to database
    }
    
    //send request
}

- (void)onRequestSucceed:(PPRequest*)req
{
    //add to resend queue
    [_resendQueue addObject:req];
    
    //remove from db
}

- (void)onRequestFail:(PPRequest*)req
{
    //add to resend queue
    [_resendQueue addObject:req];
}

@end

??如果判斷為第一類請(qǐng)求，第一步我們先將請(qǐng)求持久化到DB當(dāng)中速挑。第二步發(fā)送請(qǐng)求谤牡，如果請(qǐng)求失敗則將請(qǐng)求加入重試隊(duì)列，成功則從重試隊(duì)列中移除姥宝。重試隊(duì)列背后也需要一套通用機(jī)制翅萤，比如多久重試一次，重試幾次之后放棄腊满。遇到最惡劣的場(chǎng)景套么，請(qǐng)求發(fā)送失敗之后，App被kill碳蛋。我們需要在App重啟之后從DB當(dāng)中重新load所有失敗的請(qǐng)求再次重試胚泌。

- (void)resendPreviousFailedRequest
{
    //load from db
    
    //send requests
}

??通過上述幾步基本上可以使請(qǐng)求的可靠性得到極大的保障。但100%是無法實(shí)現(xiàn)的理想肃弟，失敗的時(shí)候用戶重裝App玷室，所有持久化的數(shù)據(jù)丟失，請(qǐng)求數(shù)據(jù)也就丟了笤受，不過這種極端的場(chǎng)景非常少穷缤。
??第二類請(qǐng)求的可靠性為PPRequestReliability_Retry，這類請(qǐng)求的例子可以是我們App啟動(dòng)時(shí)用戶看到的首頁箩兽，首頁的內(nèi)容從服務(wù)器獲取津肛，如果第一次請(qǐng)求就失敗體驗(yàn)較差，這種場(chǎng)景下我們應(yīng)該允許請(qǐng)求有機(jī)會(huì)多試幾次汗贫，增加一個(gè)retryCount即可身坐。

//PPRequest.h
@property (nonatomic, assign) int                     retryCount;

??一般3次的重試基本可以排除網(wǎng)絡(luò)抖動(dòng)的情況秸脱。三次失敗之后即可認(rèn)為請(qǐng)求失敗，通過產(chǎn)品交互告知用戶掀亥。
??第三類請(qǐng)求的重要性最低撞反，比如進(jìn)入Controller的UV采集打點(diǎn)妥色。這類請(qǐng)求只需要做一次搪花，即使失敗也不會(huì)對(duì)產(chǎn)品體驗(yàn)產(chǎn)生什么負(fù)面影響。

用戶反饋 DNS 劫持嘹害，數(shù)據(jù)被篡改撮竿，出現(xiàn)廣告和請(qǐng)求超時(shí)等情況

1.攜程
??如果是首次發(fā)送基于HTTP協(xié)議的網(wǎng)路服務(wù)，第一件事就是進(jìn)行DNS域名解析笔呀，我們統(tǒng)計(jì)過DNS解析成功率只有98%幢踏，剩下2%是解析失敗或者運(yùn)營商DNS劫持（Local DNS返回了非源站IP地址），同時(shí)DNS解析在3G下耗時(shí)200毫秒左右许师，4G也有100毫秒左右房蝉，延遲明顯。我們基于TCP連接微渠，直接跳過了DNS解析階段搭幻，使用內(nèi)置IP列表的方式進(jìn)行網(wǎng)絡(luò)連接。
??攜程App內(nèi)置了一組Server IP列表逞盆，同時(shí)每個(gè)IP具備權(quán)重檀蹋。每次建立新連接，會(huì)選擇權(quán)重最高的IP地址進(jìn)行連接云芦。App啟動(dòng)時(shí)俯逾，IP列表的所有權(quán)重是相同的，此時(shí)會(huì)啟動(dòng)一組Ping的操作舅逸，根據(jù)Ping值的延遲時(shí)間來計(jì)算IP的權(quán)重桌肴，這么做的原理是Ping值越小的IP地址，連接后的網(wǎng)絡(luò)傳輸延遲也應(yīng)該相對(duì)更小琉历。業(yè)界也有使用HTTP DNS方式來解決DNS劫持問題坠七，同時(shí)返回最合適用戶網(wǎng)絡(luò)的Server IP。然而HTTP DNS的開發(fā)和部署需要不小的開發(fā)成本善已，我們目前沒有使用灼捂。
??內(nèi)置Server IP列表也會(huì)被更新，每次App啟動(dòng)后會(huì)有個(gè)Mobile Config服務(wù)（支持TCP和HTTP兩種網(wǎng)絡(luò)類型服務(wù)）更新Server IP列表换团，同時(shí)支持不同產(chǎn)品線的Server IP列表更新悉稠。因此，傳統(tǒng)DNS解析能夠解決多IDC導(dǎo)流的功能也可以通過此方法解決艘包。

2.老司機(jī)Peak老師的解決方法：
??一個(gè)打包到app包里面的默認(rèn)映射文件的猛，這樣可以避免第一次去服務(wù)器取配置文件帶來的延遲耀盗。
??有一個(gè)定時(shí)器能每隔一段時(shí)間從服務(wù)器獲取最新的映射，并覆蓋本地卦尊。
??每次取到最新的映射文件之后叛拷，同時(shí)把上一次的映射文件保存起來作為替補(bǔ)，一旦出現(xiàn)線上配置失誤不至于導(dǎo)致請(qǐng)求無法處理岂却。
??如果映射文件不能處理域名忿薇，要能回滾使用默認(rèn)的DNS解析服務(wù)。
??如果一個(gè)映射過后的ip持續(xù)導(dǎo)致請(qǐng)求失敗躏哩，應(yīng)該能從機(jī)制上保證這個(gè)ip地址不再使用署浩。也就是需要一個(gè)無效映射淘汰機(jī)制。
??無效的ip地址能及時(shí)上報(bào)到服務(wù)器扫尺，及時(shí)發(fā)現(xiàn)問題更新映射文件筋栋。
3.美團(tuán)（IP直連方案）
??程序啟動(dòng)的時(shí)候拉取"api.dianping.com"對(duì)應(yīng)的所有的IP列表；對(duì)所有IP進(jìn)行跑馬測(cè)試正驻，找到速度最快的IP弊攘。后續(xù)所有的HTTPS請(qǐng)求都將域名更換為跑馬最快的IP即可。

Paste_Image.png

• 摒棄了系統(tǒng)DNS，減少外界干擾渣磷，擺脫DNS劫持困擾婿着。
• 自建DNS更新時(shí)機(jī)可以控制。
• IP列表更換方便醋界。

此外竟宋，如果你的App域名沒有經(jīng)過合并，域名比較多形纺，也建議可以嘗試使用HttpDNS方案丘侠。參考：http://www.tuicool.com/articles/7nAJBb 對(duì)HTTPS中的證書處理：
HTTPS由于要求證書綁定域名，如果做IP直連方案可能會(huì)遇到一些麻煩逐样，這時(shí)我們需要對(duì)客戶端的HTTPS的域名校驗(yàn)部分進(jìn)行改造蜗字，參見：http://blog.csdn.net/github_34613936/article/details/51490032 。

經(jīng)過域名合并加上IP直連方案改造后脂新，HTTP短連的端到端成功率從95%提升到97.5%挪捕，網(wǎng)絡(luò)延時(shí)從1500毫秒降低到了1000毫秒，可謂小投入大產(chǎn)出争便。

4.騰訊(HTTPDns)

Paste_Image.png

HttpDNS的原理非常簡(jiǎn)單级零，主要有兩步：
A、客戶端直接訪問HttpDNS接口滞乙，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問延遲最優(yōu)的IP奏纪。（基于容災(zāi)考慮鉴嗤，還是保留次選使用運(yùn)營商LocalDNS解析域名的方式）
B、客戶端向獲取到的IP后就向直接往此IP發(fā)送業(yè)務(wù)協(xié)議請(qǐng)求序调。以Http請(qǐng)求為例醉锅，通過在header中指定host字段，向HttpDNS返回的IP發(fā)送標(biāo)準(zhǔn)的Http請(qǐng)求即可发绢。
（2）HttpDNS優(yōu)勢(shì)：
從原理上來講硬耍，HttpDNS只是將域名解析的協(xié)議由DNS協(xié)議換成了Http協(xié)議，并不復(fù)雜朴摊。但是這一微小的轉(zhuǎn)換默垄，卻帶來了無數(shù)的收益：
A此虑、根治域名解析異常：由于繞過了運(yùn)營商的LocalDNS甚纲，用戶解析域名的請(qǐng)求通過Http協(xié)議直接透?jìng)鞯搅蓑v訊的HttpDNS服務(wù)器IP上，用戶在客戶端的域名解析請(qǐng)求將不會(huì)遭受到域名解析異常的困擾朦前。
B介杆、調(diào)度精準(zhǔn)：HttpDNS能直接獲取到用戶IP，通過結(jié)合騰訊自有專利技術(shù)生成的IP地址庫以及測(cè)速系統(tǒng)韭寸，可以保證將用戶引導(dǎo)的訪問最快的IDC節(jié)點(diǎn)上春哨。
C、實(shí)現(xiàn)成本低廉：接入HttpDNS的業(yè)務(wù)僅需要對(duì)客戶端接入層做少量改造恩伺，無需用戶手機(jī)進(jìn)行root或越獄赴背；而且由于Http協(xié)議請(qǐng)求構(gòu)造非常簡(jiǎn)單，兼容各版本的移動(dòng)操作系統(tǒng)更不成問題晶渠；另外HttpDNS的后端配置完全復(fù)用現(xiàn)有權(quán)威DNS配置凰荚，管理成本也非常低“總而言之便瑟，就是以最小的改造成本，解決了業(yè)務(wù)遭受域名解析異常的問題番川，并滿足業(yè)務(wù)精確流量調(diào)度的需求到涂。
D、擴(kuò)展性強(qiáng)：HttpDNS提供可靠的域名解析服務(wù)颁督，業(yè)務(wù)可將自有調(diào)度邏輯與HttpDNS返回結(jié)果結(jié)合践啄，實(shí)現(xiàn)更精細(xì)化的流量調(diào)度。比如指定版本的客戶端連接請(qǐng)求的IP地址沉御，指定網(wǎng)絡(luò)類型的用戶連接指定的IP地址等屿讽。
當(dāng)然各位可能會(huì)問：用戶將首選的域名解析方式切換到了HttpDNS，那么HttpDNS的高可用又是如何保證的呢嚷节？另外不同運(yùn)營商的用戶訪問到同一個(gè)HttpDNS的服務(wù)IP聂儒，用戶的訪問延遲如何保證虎锚？
為了保證高可用及提升用戶體驗(yàn)，HttpDNS通過接入了騰訊公網(wǎng)交換平臺(tái)的BGP Anycast網(wǎng)絡(luò)衩婚，與全國多個(gè)主流運(yùn)營商建立了BGP互聯(lián)窜护，保證了這些運(yùn)營商的用戶能夠快速地訪問到HttpDNS服務(wù)；另外HttpDNS在多個(gè)數(shù)據(jù)中心進(jìn)行了部署非春，任意一個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)均能無縫切換到備份節(jié)點(diǎn)柱徙，保證用戶解析正常。

網(wǎng)絡(luò)延遲較長奇昙，且存在較多的長尾數(shù)據(jù)

1.攜程
??和HTTP協(xié)議中的Keepalive特性一樣护侮，最直接減少網(wǎng)絡(luò)服務(wù)時(shí)間的優(yōu)化手段就是保持長連接。每次TCP三次握手連接需要耗費(fèi)客戶端和服務(wù)端各一個(gè)RTT（Round trip time）時(shí)間才能完成储耐，就意味著100-300毫秒的延遲羊初；TCP協(xié)議自身應(yīng)對(duì)網(wǎng)絡(luò)擁塞的Slow Start機(jī)制也會(huì)影響新連接的傳輸性能。
攜程App使用了長連接池的方式來使用長連接什湘，長連接池中維護(hù)了多個(gè)保持和服務(wù)端的TCP連接长赞，每次網(wǎng)絡(luò)服務(wù)發(fā)起后會(huì)從長連接池中獲取一個(gè)空閑長連接，完成網(wǎng)絡(luò)服務(wù)后再將該TCP連接放回長連接池闽撤。我們沒有在單個(gè)TCP連接上實(shí)現(xiàn)Pipeline和Multiplexing機(jī)制得哆，而是采用最簡(jiǎn)單的FIFO機(jī)制，原因有二：
簡(jiǎn)化Mobile Gateway的服務(wù)處理邏輯哟旗，減少開發(fā)成本贩据；
??在服務(wù)端同時(shí)返回多個(gè)響應(yīng)時(shí)，如果某個(gè)響應(yīng)報(bào)文非常大闸餐，使用多個(gè)長連接方式可以加快接收服務(wù)響應(yīng)報(bào)文速度饱亮。
??如果發(fā)起網(wǎng)絡(luò)服務(wù)時(shí)長連接池中的TCP連接都正在被占用，或者TCP長連接的網(wǎng)絡(luò)服務(wù)失敗绎巨，則會(huì)發(fā)起一個(gè)TCP短連接實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)近尚。這里長連接和短連接的區(qū)別僅僅是服務(wù)完成后是否直接關(guān)閉這個(gè)TCP連接。
2.美團(tuán)（域名合并方案）
??隨著開發(fā)規(guī)模逐漸擴(kuò)大场勤，各業(yè)務(wù)團(tuán)隊(duì)出于獨(dú)立性和穩(wěn)定性的考慮戈锻，紛紛申請(qǐng)了自己的三級(jí)域名。App中的API域名越來越多和媳。如下所示：
search.api.dianping.com
ad.api.dianping.com
tuangou.api.dianping.com
waimai.api.dianping.com
movie.api.dianping.com
…

App中域名多了之后格遭，將面臨下面幾個(gè)問題：

• HTTP請(qǐng)求需要跟不同服務(wù)器建立連接。增加了網(wǎng)絡(luò)的并發(fā)連接數(shù)量留瞳。
• 每條域名都需要經(jīng)過DNS服務(wù)來解析服務(wù)器IP拒迅。

??如果想將所有的三級(jí)域名都合并為一個(gè)域名，又會(huì)面臨巨大的項(xiàng)目推進(jìn)難題。因?yàn)椴煌瑯I(yè)務(wù)團(tuán)隊(duì)當(dāng)初正是出于獨(dú)立性和穩(wěn)定性的考慮才把域名進(jìn)行拆分璧微，現(xiàn)在再想把域名合并起來作箍，勢(shì)必會(huì)遭遇巨大的阻力。
??所以我們面臨的是：既要將域名合并前硫，提升網(wǎng)絡(luò)連接效率胞得，又不能改造后端業(yè)務(wù)服務(wù)器。經(jīng)過討論屹电，我們想到了一個(gè)折中的方案阶剑。

Paste_Image.png

• 域名得到了收編，減少了DNS調(diào)用次數(shù)熊响，降低了DNS劫持風(fēng)險(xiǎn)旨别。
• 針對(duì)同一域名，可以利用Keep-Alive來復(fù)用Http的連接汗茄。
• 客戶端業(yè)務(wù)層不需要修改代碼，后端業(yè)務(wù)服務(wù)也不需要進(jìn)行任何修改。

網(wǎng)絡(luò)抖動(dòng)

攜程：
??攜程App引入了網(wǎng)絡(luò)質(zhì)量參數(shù)灰追，通過網(wǎng)絡(luò)類型和端到端Ping值進(jìn)行計(jì)算，根據(jù)不同的網(wǎng)絡(luò)質(zhì)量改變網(wǎng)絡(luò)服務(wù)策略：

• 調(diào)整長連接池個(gè)數(shù)：例如在2G/2.5G Egde網(wǎng)絡(luò)下叼屠，會(huì)減少長連接池個(gè)數(shù)為1（運(yùn)營商會(huì)限制單個(gè)目標(biāo)IP的TCP連接個(gè)數(shù)）；WIFI網(wǎng)絡(luò)下可以增加長連接池個(gè)數(shù)等機(jī)制绞铃。
• 動(dòng)態(tài)調(diào)整TCP connection环鲤、write、read的超時(shí)時(shí)間憎兽。
• 網(wǎng)絡(luò)類型切換時(shí)冷离，例如WIFI和移動(dòng)網(wǎng)絡(luò)、4G/3G切換至2G時(shí)纯命，客戶端IP地址會(huì)發(fā)生變化西剥，已經(jīng)連接上的TCP Socket注定已經(jīng)失效（每個(gè)Socket對(duì)應(yīng)一個(gè)四元組：源IP、源Port亿汞、目標(biāo)IP瞭空、目標(biāo)Port），此時(shí)會(huì)自動(dòng)關(guān)閉所有空閑長連接疗我，現(xiàn)有網(wǎng)絡(luò)服務(wù)也會(huì)根據(jù)狀態(tài)自動(dòng)重試咆畏。

其他優(yōu)化途徑

數(shù)據(jù)格式優(yōu)化，減少數(shù)據(jù)傳輸量和序列化時(shí)間
??傳輸數(shù)據(jù)量越小吴裤，在相同TCP連接上的傳輸時(shí)間越短旧找。攜程App曾經(jīng)使用自行設(shè)計(jì)的一套數(shù)據(jù)格式，后來和Google ProtocolBuffer對(duì)比后發(fā)現(xiàn)麦牺，特定數(shù)據(jù)類型下數(shù)據(jù)包大小會(huì)降低20-30%钮蛛，序列化和反序列化時(shí)間可以降低10-20%，因此目前核心服務(wù)都在逐步遷移到到ProtocolBuffer格式剖膳。另外Facebook曾分享過他們使用FlatBuffer數(shù)據(jù)格式提高性能的實(shí)踐魏颓，我們分析后不太適合攜程的業(yè)務(wù)場(chǎng)景因而沒有使用。