App網(wǎng)絡(luò)服務(wù)的高可靠和低延遲對于無線業(yè)務(wù)穩(wěn)定發(fā)展至關(guān)重要，過去兩年來我們一直在持續(xù)優(yōu)化App網(wǎng)絡(luò)服務(wù)的性能，到今年Q2結(jié)束時基本完成了App網(wǎng)絡(luò)服務(wù)通道治理和性能優(yōu)化的階段性目標(biāo)，特此撰文總結(jié)其中的經(jīng)驗教訓(xùn)，為以后的工作打下基礎(chǔ)。

一、攜程App無線網(wǎng)絡(luò)服務(wù)架構(gòu)

2014年攜程為無線服務(wù)開發(fā)了Mobile Gateway，有兩種類型：TCP Gateway和HTTP Gateway。 TCP Gateway設(shè)計用于App中Native業(yè)務(wù)網(wǎng)絡(luò)服務(wù)，基于TCP協(xié)議之上設(shè)計了應(yīng)用層協(xié)議，類似于RPC機制。TCP Gateway兼具了接入層和服務(wù)動態(tài)路由的功能，接入層的功能基于Netty實現(xiàn)，管理客戶端的TCP長連接或者短連接；動態(tài)路由的功能基于Netfix開源的Zuul實現(xiàn)（Zuul is a gateway service that provides dynamic routing, monitoring, resiliency, security, and more. ），可以在TCP Gateway上實現(xiàn)服務(wù)路由、監(jiān)控、反爬和用戶鑒權(quán)等功能。

每個TCP服務(wù)請求到達(dá)TCP Gateway之后，會根據(jù)報文頭中的服務(wù)號，轉(zhuǎn)發(fā)到后端對應(yīng)的業(yè)務(wù)服務(wù)集群上，從而實現(xiàn)后端服務(wù)的解耦。TCP Gateway到后端業(yè)務(wù)服務(wù)集群之間的轉(zhuǎn)發(fā)使用HTTP協(xié)議的接口形式實現(xiàn)，一個TCP服務(wù)請求的完整報文會作為HTTP請求的Payload轉(zhuǎn)發(fā)到后端業(yè)務(wù)服務(wù)集群，接收到HTTP響應(yīng)后，會將其Payload完整的返回到對應(yīng)的TCP連接中。

HTTP Gateway用于App中Hybrid和H5 Web站點的網(wǎng)絡(luò)服務(wù)，采用HTTP Restful接口形式提供服務(wù)，其邏輯相對簡單，核心是HTTP服務(wù)動態(tài)轉(zhuǎn)發(fā)的功能。

Mobile Gateway的更多設(shè)計實現(xiàn)細(xì)節(jié)可以參考王興朝同學(xué)在2015上海QCon的演講《攜程無線Gateway》。

二、基于TCP協(xié)議實現(xiàn)App網(wǎng)絡(luò)服務(wù)

帶寬和延遲是影響網(wǎng)絡(luò)服務(wù)性能的兩個因素，帶寬受網(wǎng)絡(luò)通道上最小帶寬的網(wǎng)段限制，延遲是網(wǎng)絡(luò)包在客戶端和服務(wù)端之間的來回傳輸時長，不同網(wǎng)絡(luò)類型上的帶寬和延遲差別非常大（見下圖）。

我們要實現(xiàn)更好性能的網(wǎng)絡(luò)服務(wù)，對于網(wǎng)絡(luò)自身的帶寬和延遲這兩點而言，能做只是盡可能選擇最合適的網(wǎng)絡(luò)通道，其他只能在如何使用網(wǎng)絡(luò)通道上進(jìn)行優(yōu)化。

傳統(tǒng)的非IM即時消息類App通常都是使用HTTP協(xié)議來實現(xiàn)網(wǎng)絡(luò)服務(wù)的（Restful API形式），攜程使用TCP協(xié)議來實現(xiàn)，確實會增加很多開發(fā)成本，例如需要設(shè)計應(yīng)用層協(xié)議、管理網(wǎng)絡(luò)連接、處理異常等，但下面幾點原因還是讓我們最終選擇基于TCP協(xié)議來實現(xiàn)App網(wǎng)絡(luò)服務(wù)：

攜程用戶有時會在網(wǎng)絡(luò)環(huán)境非常差的景區(qū)使用，需要針對弱網(wǎng)進(jìn)行特別的優(yōu)化，單純HTTP應(yīng)用層協(xié)議很難實現(xiàn)；

HTTP請求首次需要進(jìn)行DNS域名解析，我們發(fā)現(xiàn)國內(nèi)環(huán)境下針對攜程域名的失敗率在2-3%（包含域名劫持和解析失敗的情況），嚴(yán)重影響用戶體驗；

HTTP雖然是基于TCP協(xié)議實現(xiàn)的應(yīng)用層協(xié)議，優(yōu)勢是封裝性好，客戶端和服務(wù)端解決方案成熟。劣勢是可控性小，無法針對網(wǎng)絡(luò)連接、發(fā)送請求和接收響應(yīng)做定制性的優(yōu)化，即使是HTTP的特性如保持長連接KeepAlive或者管道Pipeline等都會受制于網(wǎng)絡(luò)環(huán)境中的Proxy或者服務(wù)端實現(xiàn)，很難充分發(fā)揮作用。

基于TCP協(xié)議實現(xiàn)可以讓我們能夠完整控制整個網(wǎng)絡(luò)服務(wù)生命周期的各個階段，包括如下幾個階段：

獲取服務(wù)端IP地址

建立連接

序列化網(wǎng)絡(luò)請求報文

發(fā)送網(wǎng)絡(luò)請求

接受網(wǎng)絡(luò)響應(yīng)

反序列化網(wǎng)絡(luò)響應(yīng)報文

我們的網(wǎng)絡(luò)服務(wù)通道治理和優(yōu)化工作就是從這幾個方面展開的。

三、TCP網(wǎng)絡(luò)服務(wù)通道治理和性能優(yōu)化

1. 告別DNS，直接使用IP地址

如果是首次發(fā)送基于HTTP協(xié)議的網(wǎng)路服務(wù)，第一件事就是進(jìn)行DNS域名解析，我們統(tǒng)計過DNS解析成功率只有98%，剩下2%是解析失敗或者運營商DNS劫持（Local DNS返回了非源站IP地址），同時DNS解析在3G下耗時200毫秒左右，4G也有100毫秒左右，延遲明顯。我們基于TCP連接，直接跳過了DNS解析階段，使用內(nèi)置IP列表的方式進(jìn)行網(wǎng)絡(luò)連接。

攜程App內(nèi)置了一組Server IP列表，同時每個IP具備權(quán)重。每次建立新連接，會選擇權(quán)重最高的IP地址進(jìn)行連接。App啟動時，IP列表的所有權(quán)重是相同的，此時會啟動一組Ping的操作，根據(jù)Ping值的延遲時間來計算IP的權(quán)重，這么做的原理是Ping值越小的IP地址，連接后的網(wǎng)絡(luò)傳輸延遲也應(yīng)該相對更小。業(yè)界也有使用HTTP DNS方式來解決DNS劫持問題，同時返回最合適用戶網(wǎng)絡(luò)的Server IP。然而HTTP DNS的開發(fā)和部署需要不小的開發(fā)成本，我們目前沒有使用。

內(nèi)置Server IP列表也會被更新，每次App啟動后會有個Mobile Config服務(wù)（支持TCP和HTTP兩種網(wǎng)絡(luò)類型服務(wù)）更新Server IP列表，同時支持不同產(chǎn)品線的Server IP列表更新。因此，傳統(tǒng)DNS解析能夠解決多IDC導(dǎo)流的功能也可以通過此方法解決。

2. Socket連接優(yōu)化，減少連接時間

和HTTP協(xié)議中的Keepalive特性一樣，最直接減少網(wǎng)絡(luò)服務(wù)時間的優(yōu)化手段就是保持長連接。每次TCP三次握手連接需要耗費客戶端和服務(wù)端各一個RTT（Round trip time）時間才能完成，就意味著100-300毫秒的延遲；TCP協(xié)議自身應(yīng)對網(wǎng)絡(luò)擁塞的Slow Start機制也會影響新連接的傳輸性能。

攜程App使用了長連接池的方式來使用長連接，長連接池中維護(hù)了多個保持和服務(wù)端的TCP連接，每次網(wǎng)絡(luò)服務(wù)發(fā)起后會從長連接池中獲取一個空閑長連接，完成網(wǎng)絡(luò)服務(wù)后再將該TCP連接放回長連接池。我們沒有在單個TCP連接上實現(xiàn)Pipeline和Multiplexing機制，而是采用最簡單的FIFO機制，原因有二：1. 簡化Mobile Gateway的服務(wù)處理邏輯，減少開發(fā)成本；2. 在服務(wù)端同時返回多個響應(yīng)時，如果某個響應(yīng)報文非常大，使用多個長連接方式可以加快接收服務(wù)響應(yīng)報文速度。

如果發(fā)起網(wǎng)絡(luò)服務(wù)時長連接池中的TCP連接都正在被占用，或者TCP長連接的網(wǎng)絡(luò)服務(wù)失敗，則會發(fā)起一個TCP短連接實現(xiàn)網(wǎng)絡(luò)服務(wù)。這里長連接和短連接的區(qū)別僅僅是服務(wù)完成后是否直接關(guān)閉這個TCP連接。

附：Pipeline和Multiplexing是有區(qū)別的，如HTTP/1.1支持Pipeline，客戶端能否同時發(fā)送多個請求，但是服務(wù)端返回響應(yīng)時也要按照請求的發(fā)送次序來返回響應(yīng)；SPDY和HTTP/2協(xié)議支持Multiplexing，即支持響應(yīng)報文的亂序返回，發(fā)送請求和接收響應(yīng)互不干擾，因此避免了HTTP/1.1 Pipeline也沒能完全解決的Head of line blocking問題。參考資料：1, 2。參考資歷2中提到HTTP/1.1的Pipeline特性只是部分解決了Head of line blocking問題，因為a large or slow response can still block others behind it。

3. 弱網(wǎng)和網(wǎng)絡(luò)抖動優(yōu)化

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

1) 調(diào)整長連接池個數(shù)：例如在2G/2.5G Egde網(wǎng)絡(luò)下，會減少長連接池個數(shù)為1（運營商會限制單個目標(biāo)IP的TCP連接個數(shù)）；WIFI網(wǎng)絡(luò)下可以增加長連接池個數(shù)等機制；

2) 動態(tài)調(diào)整TCP connection、write、read的超時時間；

3) 網(wǎng)絡(luò)類型切換時，例如WIFI和移動網(wǎng)絡(luò)、4G/3G切換至2G時，客戶端IP地址會發(fā)生變化，已經(jīng)連接上的TCP Socket注定已經(jīng)失效（每個Socket對應(yīng)一個四元組：源IP、源Port、目標(biāo)IP、目標(biāo)Port），此時會自動關(guān)閉所有空閑長連接，現(xiàn)有網(wǎng)絡(luò)服務(wù)也會根據(jù)狀態(tài)自動重試。

4. 數(shù)據(jù)格式優(yōu)化，減少數(shù)據(jù)傳輸量和序列化時間

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

5. 引入重試機制，提升網(wǎng)絡(luò)服務(wù)成功率

受TCP協(xié)議重傳機制來保證可靠傳輸?shù)臋C制啟發(fā)，我們在應(yīng)用層面也引入了重試機制來提高網(wǎng)絡(luò)服務(wù)成功率。我們發(fā)現(xiàn)90%以上的的網(wǎng)絡(luò)服務(wù)失敗都是由于網(wǎng)絡(luò)連接失敗，此時再次重試是有機會連接成功并完成服務(wù)的；同時我們發(fā)現(xiàn)前面提到的網(wǎng)絡(luò)服務(wù)生命周期處于1建立連接、序列化網(wǎng)絡(luò)請求報文、發(fā)送網(wǎng)絡(luò)請求這三個階段失敗時，都是可以自動重試的，因為我們可以確信請求還沒有達(dá)到服務(wù)端進(jìn)行處理，不會產(chǎn)生冪等性問題（如果存在冪等性問題，會出現(xiàn)重復(fù)訂單等情況）。當(dāng)網(wǎng)絡(luò)服務(wù)需要重試時，會使用短連接進(jìn)行補償，而不再使用長連接。

實現(xiàn)了上述機制后，攜程App網(wǎng)絡(luò)服務(wù)成功率由原先的95.3%+提升為如今的99.5%+（這里的服務(wù)成功率是指端到端服務(wù)成功率，即客戶端采集的服務(wù)成功數(shù)除以請求總量計算的，并且不區(qū)分當(dāng)前網(wǎng)絡(luò)狀況），效果顯著。

6. 其他網(wǎng)絡(luò)服務(wù)機制 & Tricks

攜程App也實現(xiàn)了其他一些網(wǎng)絡(luò)服務(wù)機制方便業(yè)務(wù)開發(fā)，如網(wǎng)絡(luò)服務(wù)優(yōu)先級機制，高優(yōu)先級服務(wù)優(yōu)先使用長連接，低優(yōu)先級服務(wù)默認(rèn)使用短連接；網(wǎng)絡(luò)服務(wù)依賴機制，根據(jù)依賴關(guān)系自動發(fā)起或取消網(wǎng)絡(luò)服務(wù)，例如主服務(wù)失敗時，子服務(wù)自動取消。

開發(fā)過程中我們也發(fā)現(xiàn)一些移動平臺上的TCP Socket開發(fā)tricks：

1) iOS平臺上的原生Socket接口創(chuàng)建連接并不會激活移動網(wǎng)絡(luò)，這里原生Socket接口是指POSIX Socket接口，必須使用CFSocket或者再上層的網(wǎng)絡(luò)接口嘗試網(wǎng)絡(luò)連接時才會激活網(wǎng)絡(luò)。因此攜程App啟動時會優(yōu)先激活注冊一些第三方SDK以及發(fā)送HTTP請求來激活移動網(wǎng)絡(luò)；

2) 合理設(shè)置Socket的幾個參數(shù)：SOKEEPALIVE參數(shù)確保TCP連接保持（注：此KeepAlive是TCP中的屬性，和HTTP的KeepAlive是兩個場景概念），SONOSIGPIPE參數(shù)關(guān)閉SIGPIPE事件，TCP_NODELAY參數(shù)關(guān)閉TCP Nagle算法的影響；

3) 由于iOS要求支持IPv6-Only網(wǎng)絡(luò)，因此使用原生Socket必須支持IPv6；

4) 如果使用select來處理nonblocking IO操作，確保正確處理不同的返回值和超時參數(shù)；

5) 保持TCP長連接可用性的心跳機制：對于非IM類應(yīng)用而言，心跳機制的作用不大，因為用戶會不斷觸發(fā)請求去使用TCP連接，尤其在攜程業(yè)務(wù)場景下，通過數(shù)據(jù)統(tǒng)計發(fā)現(xiàn)使用心跳與否對服務(wù)耗時和成功率影響極小，因此目前已經(jīng)關(guān)閉心跳機制。原先的心跳機制是TCP長連接池中的空閑TCP連接每60秒發(fā)送一個心跳包到Gateway，Gateway返回一個心跳響應(yīng)包，從而讓雙方確認(rèn)TCP連接有效。

四、Hybrid網(wǎng)絡(luò)服務(wù)優(yōu)化

攜程App中有相當(dāng)比例的業(yè)務(wù)是使用Hybrid技術(shù)實現(xiàn)的，運行在WebView環(huán)境中，其中的所有網(wǎng)絡(luò)服務(wù)（HTTP請求）都是由系統(tǒng)控制的，我們無法掌控，也就無法進(jìn)行優(yōu)化，其端到端服務(wù)成功率也僅有97%左右（注：這里指頁面中業(yè)務(wù)邏輯發(fā)送的網(wǎng)絡(luò)服務(wù)請求，而非靜態(tài)資源請求）。

我們采用了名為『TCP Tunnel for Hybrid』的技術(shù)方案來優(yōu)化Hybrid網(wǎng)絡(luò)服務(wù)，和傳統(tǒng)HTTP加速產(chǎn)品的方法不同，我們沒有采用攔截HTTP請求再轉(zhuǎn)發(fā)的方式，而是在攜程Hybrid框架中的網(wǎng)絡(luò)服務(wù)層進(jìn)行自動切換。

如圖所示，該技術(shù)方案的流程如下：

如果App支持TCP Tunnel for Hybrid，Hybrid業(yè)務(wù)在發(fā)網(wǎng)絡(luò)服務(wù)時，會通過Hybrid接口轉(zhuǎn)發(fā)至App Native層的TCP網(wǎng)絡(luò)通訊層，該模塊會封裝這個HTTP請求，作為TCP網(wǎng)絡(luò)服務(wù)的Payload轉(zhuǎn)發(fā)到TCP Gateway；

TCP Gateway會根據(jù)服務(wù)號判斷出是Hybrid轉(zhuǎn)發(fā)服務(wù)，解包后將Payload直接轉(zhuǎn)發(fā)至HTTP Gateway，此HTTP請求對HTTP Gateway是透明的，HTTP Gateway無需區(qū)分是App直接發(fā)來的還是TCP Gateway轉(zhuǎn)發(fā)來的HTTP請求；

后端業(yè)務(wù)服務(wù)處理完成后，HTTP響應(yīng)會經(jīng)HTTP Gateway返回給TCP Gateway，TCP Gateway將此HTTP響應(yīng)作為Payload返回給App的TCP網(wǎng)絡(luò)通訊層；

TCP網(wǎng)絡(luò)通訊層會再將該Payload反序列化后返回給Hybrid框架，最終異步回調(diào)給Hybrid業(yè)務(wù)調(diào)用方。整個過程對于Hybrid業(yè)務(wù)調(diào)用方也是透明的，它并不知道TCP Tunnel的存在。

采用該技術(shù)方案后，攜程App中Hybrid業(yè)務(wù)的網(wǎng)絡(luò)服務(wù)成功率提升至99%以上，平均耗時下降了30%。

五、海外網(wǎng)絡(luò)服務(wù)優(yōu)化

攜程目前沒有部署海外IDC，海外用戶在使用App時需要訪問位于國內(nèi)的IDC，服務(wù)平均耗時明顯高于國內(nèi)用戶。我們采用了名為『TCP Bypass for Oversea』的技術(shù)方案來優(yōu)化海外網(wǎng)絡(luò)服務(wù)性能，主要是使用了Akaima的海外專屬網(wǎng)絡(luò)通道，同時在攜程國內(nèi)IDC部署了局端設(shè)備，使用專用加速通道的方式來提升海外用戶體驗。

海外用戶啟動App后先通過Akaima定制域名獲取Server IP，所有網(wǎng)絡(luò)服務(wù)優(yōu)先走Akaima通道；如果Akaima通道的網(wǎng)絡(luò)服務(wù)失敗并且重試機制生效時，會改走傳統(tǒng)Internet通道進(jìn)行重試。相比只用傳統(tǒng)Internet通道，在保持網(wǎng)絡(luò)服務(wù)成功率不變的情況下，使用Akaima通道Bypass技術(shù)后平均服務(wù)耗時下降了33%。

六、其他網(wǎng)絡(luò)協(xié)議探討

過去兩年我們的網(wǎng)絡(luò)服務(wù)優(yōu)化工作都是基于TCP協(xié)議實現(xiàn)的，基本達(dá)到了優(yōu)化目標(biāo)。不過這兩年來新的應(yīng)用層網(wǎng)絡(luò)協(xié)議SPDY和HTTP/2逐步邁入主流，基于UDP的QUIC協(xié)議看起來也非常有趣，值得跟進(jìn)調(diào)研。

SPDY & HTTP/2

SPDY是Google基于TCP開發(fā)的網(wǎng)絡(luò)應(yīng)用層協(xié)議，目前已經(jīng)停止開發(fā)，轉(zhuǎn)向支持基于SPDY成果設(shè)計的HTTP/2協(xié)議，HTTP/2協(xié)議的核心改進(jìn)其實就是針對HTTP/1.x中影響延遲性能的痛點進(jìn)行優(yōu)化：

Header壓縮：壓縮冗余的HTTP請求和響應(yīng)Header;

支持Multiplexing：支持一個TCP連接上同時實現(xiàn)多個請求和響應(yīng)。

保持長連接（比HTTP/1.x更徹底）：減少網(wǎng)絡(luò)連接時間。

支持推送：可以由服務(wù)端主動推送數(shù)據(jù)到客戶端。

官方性能測試結(jié)果顯示使用SPDY或者HTTP/2的頁面加載時間減少30%左右，不過這是針對網(wǎng)頁的測試結(jié)果，對于App中的網(wǎng)絡(luò)服務(wù)，具體優(yōu)化效果我們還在進(jìn)行內(nèi)部測試，不過其優(yōu)化手段看和目前我們使用TCP協(xié)議的優(yōu)化手段類似，因此性能優(yōu)化效果可能不會很顯著。

QUIC

QUIC是Google基于UDP開發(fā)的應(yīng)用層協(xié)議，UDP協(xié)議無需連接，不存在重傳機制，因此應(yīng)用層需要保證服務(wù)的可靠性。目前國內(nèi)騰訊有針對弱網(wǎng)絡(luò)嘗試過QUIC協(xié)議，我們也在進(jìn)行測試，最終是否會采用還需要看測試的結(jié)果。

七、綜述

技術(shù)只是手段，最終還是要反映在業(yè)務(wù)效果上。我們已經(jīng)實現(xiàn)除靜態(tài)資源等需要訪問CDN的網(wǎng)絡(luò)請求外，其他App網(wǎng)絡(luò)服務(wù)使用統(tǒng)一的TCP通道，從而具備更好的性能調(diào)優(yōu)和業(yè)務(wù)監(jiān)控能力。

攜程目前基于TCP協(xié)議的各種App網(wǎng)絡(luò)服務(wù)優(yōu)化，也是各種技術(shù)方案的平衡，雖然目前HTTP/2等新協(xié)議逐步成熟，但是TCP協(xié)議自身的靈活性支持有針對性的性能優(yōu)化，還是具備其特別的優(yōu)勢，希望我們的實踐總結(jié)能對國內(nèi)無線技術(shù)從業(yè)者有一些借鑒價值。

作者：陳浩然，攜程無線開發(fā)總監(jiān)，計算機博士，2008年iOS SDK發(fā)布后，投身移動互聯(lián)網(wǎng)。先后在外企、創(chuàng)業(yè)型和國內(nèi)一線旅游公司從事無線App的開發(fā)工作，從企業(yè)級App、獨立App到億級用戶量級的App都有全程參與。
責(zé)編：錢曙光，關(guān)注架構(gòu)和算法領(lǐng)域，尋求報道或者投稿請發(fā)郵件qianshg@csdn.net，另有「CSDN 高級架構(gòu)師群」，內(nèi)有諸多知名互聯(lián)網(wǎng)公司的大牛架構(gòu)師，歡迎架構(gòu)師加微信qshuguang2008申請入群，備注姓名+公司+職位。

總結(jié)

以上是生活随笔為你收集整理的携程App网络服务通道治理和性能优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。