编者按：
在4月23日~25日举行的QCon全球软件开发大会（北京站）上，携程无线开发总监陈浩然分享了《移动开发网络性能优化实践》，总结了携程在App网络性能优化方面的一些实践经验。在2014年接手携程无线App的框架和基础研发工作之后，陈浩然面对的首要工作就是App客户端性能优化，尤其是网络服务性能，这是所有App优化工作的重中之重。以下为正文。
首先介绍一下携程App的网络服务架构。由于携程业务众多，开发资源导致无法全部使用Native来实现业务逻辑，因此有相当一部分频道基于Hybrid实现。网络通讯属于基础&业务框架层中基础设施的一部分，为App提供统一的网络服务：
Native端的网络服务
本文节选自号称麻省理工技术先驱以及有三个成功企业领导经验的
KeNative模块是携程的核心业务模块（酒店、机票、火车票、攻略等），Native模块的网络服务主要通过TCP连接实现，而非常见的Restful HTTP API那种HTTP连接，只有少数轻量级服务使用HTTP接口作为补充。
TCP连接网络服务模块使用了长连接+短连接机制，即有一个长连接池保持一定数目长连接，用于减少每次服务额外的连接，服务完成后会将该连接Socket放回长连接池，继续保持连接状态（一段时间空闲后会被回收）；短连接作为补充，每次服务完成后便会主动关闭接。
TCP网络服务的Payload使用的是自定义的数据及序列化协议；HTTP服务的Payload比较简单，即常见的JSON数据格式。
Hybrid端的网络服务
Hybrid模块由于是在WebView中展示本地或者直连的H5页面，页面逻辑发起的网络服务都是通过系统WebView的HTTP请求实现的。少量业务场景（需要加密和支付等）以Hybrid桥接接口形式的Native TCP通道来完成网络服务。
网络服务的部署架构图
携程App所有网络服务，无论是TCP还是HTTP都会先连接到一个API Gateway服务器。如果是TCP服务，会先连接上TCP Gateway，TCP Gateway会负责将请求通过HTTP转发到后端的SOA服务接口。HTTP Gateway的原理与之类似。TCP Gateway和HTTP Gateway的区别仅仅在客户端到服务端的连接方式不同而已。Gateway的作用除了业务请求还有流量控制和熔断。
要发现常见网络性能问题，先来看看一个网络服务做了哪些事情：
1.DNS Lookup
2.TCP Handshake
3.TLS Handshake
4.TCP/HTTP Request/Response
首先会是DNS解析，然后TCP连接握手，TLS连接握手（如果有的话），连接成功后再发送TCP或HTTP请求以及收到响应。如果能够将这些过程逐一梳理并确保不会存在明显的性能问题，那么基本可以确保获得不错的网络性能。网络服务里有一个重要的性能标准，即RTT(Round-Trip Time)，往返时延，它表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认）所间隔的时间。理想情况下可以假设4G网络RTT为100ms，3G网络RTT为200ms，很容易就能计算出我们的App网络服务耗时的下限，当然还要加上服务器处理时间。
常见的网络性能问题有如下几种：
问题一：DNS问题
DNS出问题的概率其实比大家感觉的要大，首先是DNS被劫持或者失效，2015年初业内比较知名的就有Apple内部DNS问题导致App Store、iTunes Connect账户无法登录；京东因为CDN域名付费问题导致服务停摆。携程在去年11月也遇到过DNS问题，主域名被国外服务商误列入黑名单，导致主站和H5等所有站点无法访问，但是App客户端的Native服务都正常，原因后面介绍。
另一个常见问题就是DNS解析慢或者失败，例如国内中国运营商网络的DNS就很慢，一次DNS查询的耗时甚至都能赶上一次连接的耗时，尤其2G网络情况下，DNS解析失败是很常见的。因此如果直接使用DNS，对于首次网络服务请求耗时和整体服务成功率都有非常大的影响。
问题二：TCP连接问题
DNS成功后拿到IP，便可以发起TCP连接。HTTP协议的网络层也是TCP连接，因此TCP连接的成功和耗时也成为网络性能的一个因素。我们发现常见的问题有TCP端口被封（例如上海长宽对非HTTP常见端口80、8080、443的封锁），以及TCP连接超时时长问题。端口被封，直接导致无法连接；连接超时时长过短，在低速网络上可能总是无法连接成果；连接超时过长，又有可能导致用户长时间等待，用户体验差。很多时候尽快失败重新发起一次连接会很快，这也是移动网络带宽不稳定情况下的一个常见情况。
问题三：Write/Read问题
DNS Lookup和TCP连接成功后，就会开始发送Request，服务端处理后返回Response，如果是HTTP连接，业内大部分App是使用第三方SDK或者系统提供的API来实现，那么只能设置些缓存策略和超时时间。iOS上的NSURLConnection超时时间在不同版本上还有不同的定义，很多时候需要自己设置Timer来实现；如果是直接使用TCP连接实现网络服务，就要自己对读写超时时间负责，与网络连接超时时长参数类似，太小了在低速网络很容易读写失败，太大了又可能影响用户体验，因此需要非常小心地处理。
我们还遇到另一类问题，某些酒店Wi-Fi对使用非80、8080和443等常见HTTP端口的服务进行了限制，即使发送Request是正常的，服务端能够正常收到，但是Response却被酒店网络proxy或防火墙拦截，客户端最终会等待读取超时。
移动网络和传统网络另一个很大的区别是Connection Migration问题。定义一个Socket连接是四元组（客户端IP，客户端Port，服务端IP，服务端Port），当用户的网络在WIFI/4G/3G/2G类型中切换时，其客户端IP会发生变化，如果此时正在进行网络服务通讯，那么Socket连接自身已经失效，最终也会导致网络服务失败。
问题四：传输Payload过大
传的多就传的慢，如果没做过特别优化，传输Payload可能会比实际所需要的大很多，那么对于整体网络服务耗时影响非常大。
问题五：复杂的国内外网络情况
国内运营商互联和海外访问国内带宽低传输慢的问题也令人难非常头疼。
携程App用户的网络类型分布
Wi-Fi用户占比已超过60%，4G用户量正接近3G用户量，2G用户在逐步减少，用户的网络越来越好。4G/3G/2G网络的带宽和延迟差别很大，而带宽和延迟是网络性能的重要指标：
针对携程App用户的网络带宽和延迟，我们采样了海内外各8个城市的数据：
注意网络带宽和延迟并没有直接相关性，带宽高不意味着延迟低，延迟再低也不可能快过光速。从上图我们可以看到海内外带宽相差很大，但是延迟基本一致。
