iOS端移动网络调优的8条建议

作者：项望烽，毕业于浙江大学，目前是网易云信 iOS 端研发负责人。

前言

App发布后收到了很多关于网络传输慢和连接有问题的反馈，吓得本吊直接从广州跑到杭州救急，针对各方面的问题都做了不同程度的调整和改进，效果还不错。顺带自己最近也在看《Professional iOS Network Programming》，理论结合实践，可以好好地总结一把App在移动网络下的调优的那些事。

相对于有线网络，移动网络有如下的特性：带宽低，延迟高，丢包率高，稳定性差。3G网络的带宽一般为下行100-200KB/S，上行10-100KB/S，延迟0-400ms，带宽方面基本逼近2M有线网络，但延迟较高，稳定性不够。而2G更是惨不忍睹：一般只有10KB/S下行和1KB/S左右的上行速度，延迟基本不低于400ms，网络环境不好时甚至有数秒的延迟。下面针对这些情况给出个人总结的八条网络优化的小贴士。

建议1：尽量使用IP而非域名进行连接

对于有线网络来说DNS查询可能是一件不费吹灰之力的事，但是对于移动网络来说却不是这样，一次DNS查询的耗时甚至都能赶得上一次连接的耗时。于是在有条件的情况下，缓存服务器IP地址和端口，并尽量使用IP进行连接是个好的选择。另一个原因是中国移动的DNS服务相当不靠谱，错误率极高(传闻出错率在60%以上)。我们就碰到过几次某个地段的童鞋使用移动2G总是无法解析域名的情况。

有关移动端网络的DNS各种杂症，你还可以读一读：《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》。

建议2：减少不必要的网络连接

大多数的移动网络(3G)并不允许一个给定IP地址超过两个的并发HTTP请求，既当你有两个针对同一个地址的连接时，再发起的第三个连接总是会超时。而2G网络下这个限定为1个。同一时间发起过多的网络请求不仅不会起到加速的效果，反而有副作用。

另一方面，由于网络连接很是费时，保持和共享某一条连接就是一个不错的选择：比如短时间内多次的HTTP请求。像ASIHttpRequest就提供setShouldAttemptPersistentConnection的方法：

By default, ASIHTTPRequest will attempt to keep connections to a server open so that they can be reused by other requests to the same server (this generally results in significant speed boost, especially if you have many small requests). Persistent connections will be used automatically when connecting to an HTTP 1.1 server, or when the server sends a keep-alive header. Persistent connections are not used if the server explicitly sends a ‘Connection: close’ header.

建议3：设置合理的超时时间

过短的超时容易导致连接超时的事情频频发生，甚至一直无法连接，而过长的超时则会带来等待时间过长，体验差的问题。就目前来看，对于普通的TCP连接30秒是个不错的超时值，而Http请求可以按照重要性和当前网络情况动态调整超时，尽量将超时控制在一个合理的数值内，以提高单位时间内网络的利用率。

建议4：减少网络请求

使用一种有效的传输格式和压缩网络请求/反馈是两种行之有效的方法。前者主要应用于使用自定义协议的场景：用protobuf明显会比json/xml更省流量；而后者多出现在Http相关的场景，比如使用gzip对Http请求和反馈进行压缩。

建议5：使用缓存

其实这也算是对好地方4的补充：在本地有有效数据的情况下直接不发起网络请求。配置文件，资源文件，描述文件，几乎所有的文件都可以成为我们缓存的对象，而大部分涉及到网络相关的iOS第三方库都提供了极其方便的缓存方法，程序员唯一需要考虑的就只有缓存容量和过期时间的问题。

建议6：使用断点上传和分段上传

一方面可以在重新传输时省去已传输数据的流量，而另一方面将文件分成几个请求上传可以尽量减少传输中的包大小，避免高丢包率环境导致TCP包丢包重传甚至失败，保证传输的成功率(当然也减低了效率)。

建议7：平衡网络延迟和带宽的影响

对于移动网络这种高延迟低带宽的情况，需要综合考虑进行平衡配置：在一个固定网络下，当包大小小于1500字节时(一个TCP的Payload)，网络延迟的影响基本是一个常数，此时网络延迟的影响主要体现在请求次数上，所以合并多个小请求到一个包内是一个合理且有效的做法。而在包大小超过1500字节后，随着包大小的增加，延迟的影响会越来越小，但相应的带宽的影响会越来越大。

建议8：合理地选择加密

对于信息安全来说，最理想的状态是所有的请求都是通过加密的。这对于PC来说并不是一个问题，但是对于电量资源有限的移动端来说却是一个需要好好权衡的问题：网络传输中加密的使用增加了CPU的负担同时也激活了其他资源，这将导致电量更快地被损耗。对于非机密的信息比如图片资源，描述资源就完全可以不进行任何加密。

全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

（原文链接：点此进入）

第1条和第3条深有体会，但第6条就不认同了