即时通讯开发移动端弱网络优化方法总结

本篇的目的，就是希望以通俗易懂的语言，帮助移动端IM开发者更好地针对性优化移动网络的各种特性，使得开发出的功能给用户带来更好的使用体验。

本文乃全网同类文章中，唯一内容最全、“粪”量最重者，请做好心理准备耐心读下去，不要辜负作者已打上石膏的双手和用废的键盘。

 

优化方法一：“快链路”

我们需要有一条（相对）快速、（相对）顺畅、（相对）稳定的网络通道承载业务数据的传输，这条路的最好是传输快、不拥堵、带宽大、收费少。生活中做个类比，我们计划驱车从深圳到广州，如果想当然走广深高速十之八九要杯具，首先这个高速略显破败更像省道，路况不佳不敢提速；其次这条路上的车时常如过江之鲫，如果身材不好操控不便，根本就快不起来；最后双向六车道虽然勉强可以接受，但收费居然比广深沿江高速双向八车道还贵；正确的选路方案目前看是走沿江高速，虽然可能要多跑一段里程，但是通行更畅快。

① 控制传输包大小

控制传输包的大小在1400字节以下。暂时不讲为什么这样建议，先举个例子来类比一下，比如一辆大卡车满载肥猪正在高速上赶路，猪笼高高层叠好不壮观，这时前方突然出现一个隧道限高标识，司机发现卡车超限了，这下咋整。方案一，停车调头重新找路，而且十之八九找不到，最后只能哪来回哪；方案二，把其中一群猪卸下来放本地找人代养，到达目的地卸完货回来再取，你别说，这个机制在TCP/IP协议栈中也有，学名“IP分片”，后面会专门介绍。这个故事侧面证实美国计算机科学家也曾经蹲在高速路边观察生猪超载运输的过程，并饱受启发。且慢，每次遇到问题，想到一些方案后我们都应该再扪心自问：“还有没有更好的办法呢？”。当然有，参照最近流行的说法，找个台风眼，把猪都赶过去，飞一会就到了，此情此景想想也是醉了。

回归正题，概括的说，我们设定1400这个阈值，目的是减少往复，提高效能。因为TCP/IP网络中也有类似高速限高的规定，如果在超限时想要继续顺畅传输，要么做IP分片要么把应用数据拆分为多个数据报文（意指因为应用层客户端或服务器向对端发送的请求或响应数据太大时，TCP/IP协议栈控制机制自动将其拆分为若干独立数据报文发送的情况，后面为简化讨论，都以IP分片这个分支为代表，相关过程分析和结论归纳对二者均适用）。而一旦一个数据报文发生了IP分片，便会在数据链路层引入多次的传输和确认，加上报文的拆分和拼接开销，令得整个数据包的发送时延大大增加，并且，IP分片机制中，任何一个分片出现丢失时还会带来整个IP数据报文从最初的发起端重传的消耗。

我们可以得出如下结论，TCP/IP数据报文大小超过物理网络层的限制时，会引发IP分片，从而增加时空开销。

因此，设定合理的MSS至关重要，对于以太网MSS值建议是1400字节。什么，你的数学是体育老师教的吗？前面说以太网最大的传输数据大小是1500字节，IP数据报文包头