优化清单

DNS映射

无论是HTTP还是Socket长连接，第一步都是DNS解析。域名根据层级「主机名.次级域名.顶级域名.根域名」去解析，每一级缓存生命周期不同。在iOS设备上几乎每次断网重连，重启设备都会使DNS缓存失效，触发重新查询。这一步的优化对请求的延迟来说至关重要，具体优化手段可参考我之前一篇关于DNS映射的文章，配有可用的demo代码，这里就不复述了。

请求压缩

DNS查询之后是TCP握手建立连接，并发送请求数据。对于TCP来说，单个IP包大小受限于MSS值，大部分用户所处网络环境下每个包的大小约在1.5KB，新建立的HTTP连接由于TCP的slow start特性，会导致本地的部分IP包本临时缓存，从而增加了整体request的延迟。所以我们应该尽可能尝试去压缩我们的网络请求业务数据，减少一个Request的IP包数量，或许可以让用户少经历一个RTT，降低请求延迟的用户感知。

请求合并

对于非关键性的业务数据，或者对实时性要求不高的请求来说，通过合并请求的方式可以减少和服务器交互的次数，一则降低服务器压力，二则合并之后再压缩能节约客户端的流量。这类请求一般见于打点SDK，crash日志收集等非业务型请求。

请求的安全性

请求的网络安全是个容易被忽视的话题，关于安全我之前也写过一篇比较详细的文章，建议细读再配合使用HTTPS来做到基本的网络安全，这里也不再细述了。

合理的并发数

有些业务场景会出现多个Request集中产生的情况，此时我们需要设置一个合理的并发数。并发数如果太小，会导致“劣质”的请求block住“优质”的请求。如果并发数太大，带宽有限的场景下，会增加请求的整体延迟，请求数量对于HTTP的影响我在之前的文章中也详细的介绍过了。

可靠性保障

可靠性保障也是个容易被忽视的方面，在深入探讨之前，可以先将Request按业务属性分类。

  • 第一类：关键核心的业务数据，期望能100%送达服务器。
  • 第二类：重要内容请求，需要较高的请求成功率。
  • 第三类：一般性内容请求，对成功率无要求。

之所以要将请求分为三类，是要在可靠性保障上做区分。理论上我们应该尽可能让所有的请求成功率达到最高，但客户端的流量，带宽，手机电量，服务器的压力等都是有限的资源，所以我们采取的策略是只对关键性的网络请求做高强度的可靠性保障。

第一类请求类似大家用微信时发送的消息，消息数据一旦从输入框发出，从用户来的角度感知这个消息数据是一定会到达对方的。如果网络环境差，网络模块会自动在后头悄悄重试，一段时间后仍无法成功就通过产品交互的方式告知用户发送失败了，即使失败，请求的数据（消息本身）一直存在客户端。

对于这类请求的处理方式第一步不是通过网络发送，而是持久化到Database当中。一旦入了DB，即使断网，断电，重启，请求数据依然还在，只需在App重启的时候还原请求数据，再次发送即可。说白了，第一步我们先将请求持久化到DB当中；

第二步发送请求，如果请求失败则将请求加入重试队列，成功则从重试队列中移除。重试队列背后也需要一套通用机制，比如多久重试一次，重试几次之后放弃。

遇到最恶劣的场景，请求发送失败之后，App被kill。我们需要在App重启之后从DB当中重新load所有失败的请求再次重试。

通过上述几步基本上可以使请求的可靠性得到极大的保障。但100%是无法实现的理想，失败的时候用户重装App，所有持久化的数据丢失，请求数据也就丢了，不过这种极端的场景非常少。（这种就不用考虑了）

如果第一次请求就失败体验较差，这种场景下我们应该允许请求有机会多试几次，增加一个retryCount即可。

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

一般3次的重试基本可以排除网络抖动的情况。三次失败之后即可认为请求失败，通过产品交互告知用户。

多通道

现在不少有技术条件的团队都有自己的tcp长连接通道，技术再硬点的甚至配有UDP通道，UDP在丢包率高的网络环境下能极大的提高请求成功的概率。如果能同时具备HTTP，TCP，UDP三条网络通道，在某些场景下，如果不考虑流量（比如wifi），可以针对某个网络请求，两通道或者三通道齐发，对请求成功的速度和可靠性有明显的疗效，不过客户端和服务器都需要针对业务场景做去重。我工作过的一个IM App在发送消息的时候，就是Socket配合HTTP双通道工作。UDP在VOIP服务当中使用较多，不过据说淘宝这类大厂也部分启用了UDP。

网络环境监控

现在网络环境虽然越来越好，Wifi，4G，3G在一二线城市都有很好的普及，但还是有不少场景会导致网络状态突然变差，比如进电梯，做火车，人多的集会场所，从公司回家4G切Wifi等等，这些场景在生活当中并不少见，健壮的网络模块需要仔细的检测网络的变化，针对性的做请求重试。