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)驗(yàn)教訓(xùn)，為以后的工作打下基礎(chǔ)。
　　一、攜程App無線網(wǎng)絡(luò)服務(wù)架構(gòu)
　　2014年攜程為無線服務(wù)開發(fā)了Mobile Gateway，有兩種類型：TCP Gateway和HTTP Gateway。 TCP Gateway設(shè)計(jì)用于App中Native業(yè)務(wù)網(wǎng)絡(luò)服務(wù)，基于TCP協(xié)議之上設(shè)計(jì)了應(yīng)用層協(xié)議，類似于RPC機(jī)制。TCP Gateway兼具了接入層和服務(wù)動態(tài)路由的功能，接入層的功能基于Netty實(shí)現(xiàn)，管理客戶端的TCP長連接或者短連接；動態(tài)路由的功能基于Netfix開源的Zuul實(shí)現(xiàn)（Zuul is a gateway service that provides dynamic routing， monitoring， resiliency， security， and more. ），可以在TCP Gateway上實(shí)現(xiàn)服務(wù)路由、監(jiān)控、反爬和用戶鑒權(quán)等功能。
　　
　　每個TCP服務(wù)請求到達(dá)TCP Gateway之后，會根據(jù)報(bào)文頭中的服務(wù)號，轉(zhuǎn)發(fā)到后端對應(yīng)的業(yè)務(wù)服務(wù)集群上，從而實(shí)現(xiàn)后端服務(wù)的解耦。TCP Gateway到后端業(yè)務(wù)服務(wù)集群之間的轉(zhuǎn)發(fā)使用HTTP協(xié)議的接口形式實(shí)現(xiàn)，一個TCP服務(wù)請求的完整報(bào)文會作為HTTP請求的Payload轉(zhuǎn)發(fā)到后端業(yè)務(wù)服務(wù)集群，接收到HTTP響應(yīng)后，會將其Payload完整的返回到對應(yīng)的TCP連接中。
　　HTTP Gateway用于App中Hybrid和H5 Web站點(diǎn)的網(wǎng)絡(luò)服務(wù)，采用HTTP Restful接口形式提供服務(wù)，其邏輯相對簡單，核心是HTTP服務(wù)動態(tài)轉(zhuǎn)發(fā)的功能。
　　
　　Mobile Gateway的更多設(shè)計(jì)實(shí)現(xiàn)細(xì)節(jié)可以參考王興朝同學(xué)在2015上海QCon的演講《攜程無線Gateway》。
　　二、基于TCP協(xié)議實(shí)現(xiàn)App網(wǎng)絡(luò)服務(wù)
　　帶寬和延遲是影響網(wǎng)絡(luò)服務(wù)性能的兩個因素，帶寬受網(wǎng)絡(luò)通道上最小帶寬的網(wǎng)段限制，延遲是網(wǎng)絡(luò)包在客戶端和服務(wù)端之間的來回傳輸時長，不同網(wǎng)絡(luò)類型上的帶寬和延遲差別非常大（見下圖）。
　　
　　我們要實(shí)現(xiàn)更好性能的網(wǎng)絡(luò)服務(wù)，對于網(wǎng)絡(luò)自身的帶寬和延遲這兩點(diǎn)而言，能做只是盡可能選擇最合適的網(wǎng)絡(luò)通道，其他只能在如何使用網(wǎng)絡(luò)通道上進(jìn)行優(yōu)化。
　　傳統(tǒng)的非IM即時消息類App通常都是使用HTTP協(xié)議來實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)的（Restful API形式），攜程使用TCP協(xié)議來實(shí)現(xiàn)，確實(shí)會增加很多開發(fā)成本，例如需要設(shè)計(jì)應(yīng)用層協(xié)議、管理網(wǎng)絡(luò)連接、處理異常等，但下面幾點(diǎn)原因還是讓我們最終選擇基于TCP協(xié)議來實(shí)現(xiàn)App網(wǎng)絡(luò)服務(wù)：
　　攜程用戶有時會在網(wǎng)絡(luò)環(huán)境非常差的景區(qū)使用，需要針對弱網(wǎng)進(jìn)行特別的優(yōu)化，單純HTTP應(yīng)用層協(xié)議很難實(shí)現(xiàn)；
　　HTTP請求首次需要進(jìn)行DNS域名解析，我們發(fā)現(xiàn)國內(nèi)環(huán)境下針對攜程域名的失敗率在2-3%（包含域名劫持和解析失敗的情況），嚴(yán)重影響用戶體驗(yàn)；
　　HTTP雖然是基于TCP協(xié)議實(shí)現(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ù)端實(shí)現(xiàn)，很難充分發(fā)揮作用。
　　基于TCP協(xié)議實(shí)現(xiàn)可以讓我們能夠完整控制整個網(wǎng)絡(luò)服務(wù)生命周期的各個階段，包括如下幾個階段：
　　獲取服務(wù)端IP地址建立連接序列化網(wǎng)絡(luò)請求報(bào)文發(fā)送網(wǎng)絡(luò)請求接受網(wǎng)絡(luò)響應(yīng)反序列化網(wǎng)絡(luò)響應(yīng)報(bào)文
　　我們的網(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)計(jì)過DNS解析成功率只有98%，剩下2%是解析失敗或者運(yùn)營商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值的延遲時間來計(jì)算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三次握手連接需要耗費(fèi)客戶端和服務(wù)端各一個RTT（Round trip time）時間才能完成，就意味著100-300毫秒的延遲；TCP協(xié)議自身應(yīng)對網(wǎng)絡(luò)擁塞的Slow Start機(jī)制也會影響新連接的傳輸性能。
　　攜程App使用了長連接池的方式來使用長連接，長連接池中維護(hù)了多個保持和服務(wù)端的TCP連接，每次網(wǎng)絡(luò)服務(wù)發(fā)起后會從長連接池中獲取一個空閑長連接，完成網(wǎng)絡(luò)服務(wù)后再將該TCP連接放回長連接池。我們沒有在單個TCP連接上實(shí)現(xiàn)Pipeline和Multiplexing機(jī)制，而是采用最簡單的FIFO機(jī)制，原因有二：1. 簡化Mobile Gateway的服務(wù)處理邏輯，減少開發(fā)成本；2. 在服務(wù)端同時返回多個響應(yīng)時，如果某個響應(yīng)報(bào)文非常大，使用多個長連接方式可以加快接收服務(wù)響應(yīng)報(bào)文速度。
　　如果發(fā)起網(wǎng)絡(luò)服務(wù)時長連接池中的TCP連接都正在被占用，或者TCP長連接的網(wǎng)絡(luò)服務(wù)失敗，則會發(fā)起一個TCP短連接實(shí)現(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)報(bào)文的亂序返回，發(fā)送請求和接收響應(yīng)互不干擾，因此避免了HTTP/1.1 Pipeline也沒能完全解決的Head of line blocking問題。參考資料：1， 2。參考資歷2中提到HTTP/1.1的Pipeline特性只是部分解決了Head of line blocking問題，因?yàn)閍 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ì)算，根據(jù)不同的網(wǎng)絡(luò)質(zhì)量改變網(wǎng)絡(luò)服務(wù)策略：
　　1） 調(diào)整長連接池個數(shù)：例如在2G/2.5G Egde網(wǎng)絡(luò)下，會減少長連接池個數(shù)為1（運(yùn)營商會限制單個目標(biāo)IP的TCP連接個數(shù)）；WIFI網(wǎng)絡(luò)下可以增加長連接池個數(shù)等機(jī)制；
　　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è)計(jì)的一套數(shù)據(jù)格式，后來和Google ProtocolBuffer對比后發(fā)現(xiàn)，特定數(shù)據(jù)類型下數(shù)據(jù)包大小會降低20-30%，序列化和反序列化時間可以降低10-20%，因此目前核心服務(wù)都在逐步遷移到到ProtocolBuffer格式。另外Facebook曾分享過他們使用FlatBuffer數(shù)據(jù)格式提高性能的實(shí)踐，我們分析后不太適合攜程的業(yè)務(wù)場景因而沒有使用。
　　5. 引入重試機(jī)制，提升網(wǎng)絡(luò)服務(wù)成功率
　　受TCP協(xié)議重傳機(jī)制來保證可靠傳輸?shù)臋C(jī)制啟發(fā)，我們在應(yīng)用層面也引入了重試機(jī)制來提高網(wǎng)絡(luò)服務(wù)成功率。我們發(fā)現(xiàn)90%以上的的網(wǎng)絡(luò)服務(wù)失敗都是由于網(wǎng)絡(luò)連接失敗，此時再次重試是有機(jī)會連接成功并完成服務(wù)的；同時我們發(fā)現(xiàn)前面提到的網(wǎng)絡(luò)服務(wù)生命周期處于1建立連接、序列化網(wǎng)絡(luò)請求報(bào)文、發(fā)送網(wǎng)絡(luò)請求這三個階段失敗時，都是可以自動重試的，因?yàn)槲覀兛梢源_信請求還沒有達(dá)到服務(wù)端進(jìn)行處理，不會產(chǎn)生冪等性問題（如果存在冪等性問題，會出現(xiàn)重復(fù)訂單等情況）。當(dāng)網(wǎng)絡(luò)服務(wù)需要重試時，會使用短連接進(jìn)行補(bǔ)償，而不再使用長連接。
　　實(shí)現(xiàn)了上述機(jī)制后，攜程App網(wǎng)絡(luò)服務(wù)成功率由原先的95.3%+提升為如今的99.5%+（這里的服務(wù)成功率是指端到端服務(wù)成功率，即客戶端采集的服務(wù)成功數(shù)除以請求總量計(jì)算的，并且不區(qū)分當(dāng)前網(wǎng)絡(luò)狀況），效果顯著。
　　6. 其他網(wǎng)絡(luò)服務(wù)機(jī)制 & Tricks
　　攜程App也實(shí)現(xiàn)了其他一些網(wǎng)絡(luò)服務(wù)機(jī)制方便業(yè)務(wù)開發(fā)，如網(wǎng)絡(luò)服務(wù)優(yōu)先級機(jī)制，高優(yōu)先級服務(wù)優(yōu)先使用長連接，低優(yōu)先級服務(wù)默認(rèn)使用短連接；網(wǎng)絡(luò)服務(wù)依賴機(jī)制，根據(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長連接可用性的心跳機(jī)制：對于非IM類應(yīng)用而言，心跳機(jī)制的作用不大，因?yàn)橛脩魰粩嘤|發(fā)請求去使用TCP連接，尤其在攜程業(yè)務(wù)場景下，通過數(shù)據(jù)統(tǒng)計(jì)發(fā)現(xiàn)使用心跳與否對服務(wù)耗時和成功率影響極小，因此目前已經(jīng)關(guān)閉心跳機(jī)制。原先的心跳機(jī)制是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ù)實(shí)現(xiàn)的，運(yù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)行自動切換。