移动端IM系统的协议选型：UDP仍是TCP？

而移动互联网，因为涉及到无线电话网络基站、2G、3G和4G技术的不断发展，其稳定性、带宽、资源分配等各方面虽日趋完善，但当前终究还有很多问题的存在。另外，因为移动互联网其“移动”的本质，加上智能终端设备（智能手机、平板电脑）的发展较晚，目前还在不断演变的状况，与互联网相比，移动互联网仍是低速、不稳定、终端能力稍弱的状况。并且因为其“移动”本质，短期内很难达到互联网的质量。

因此，在互联网的环境里面，网络应用程序因为网络设施、操做系统的成熟，开发使用起来比较容易，资源也较为充足。而移动互联网仍是要“斤斤计较”。

六、智能终端电池续航能力，系统休眠

智能终端设备的电池续航能力始终是技术瓶颈。在连续使用的状况下，绝大部分智能设备电池没法支持两个小时以上。因此在没有外部电源的状况，智能终端设备必须频繁、长时间休眠，这将极大地影响两种网络环境下的网络应用场景。

七、IPv4资源、端口资源

这个话题每每被不少人忽略，但它有着相当重要的影响。虽然大部分人都很清楚IP地址的紧缺致使的动态IP分配的必然，却忽略了因为IP地址不足引发的端口资源不足。

因为须要动态分配IP地址（这里不只仅指互联网入口的IP，还包括局域网内部的IP），路由器的工做原理都是通过端口映射，把内部网络（包括PC、手机、平板、Wifi、2G、3G、4G）IP与端口映射成外部IP（一般是公网IP）和对应的端口，并维持这个映射关系，才能正常地修改、转发报文信息，保证内部各个ip、端口与外部的各个ip、端口的通讯。

然而，单个IP地址的端口资源是有限的，理论上限是65535个端口。对于普通宽带路由器来讲，这个已经很充足了。可是！对于大型的网络服务、网络主干接入点等来讲，若是IP资源不足，每一个IP几万个端口的资源很快会耗尽，从而影响正常通信。（有关NAT技术原理，请参见《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》）

八、端口映射老化时间

正由于如此，全部的路由器都会为每一个端口映射关系设置老化时间，若是老化时间倒数到0，则端口映射关系失效，该端口被释放给其余链接使用。若是端口所有耗尽，则没法再新建内部与外部的网络链接。

端口映射老化时间，比不少人想象中的要短不少。通常的家用宽带路由器，老化时间通常是两三分钟；在有线宽带运营商接入部分，老化时间可能少于两分钟。在无线电话网络运营商接入部分（例如GPRS链接），老化时间甚至不超过一分钟！

也就是说，任何一个网络通信（无论是TCP或UDP），若是几分钟以内没有网络报文传输，其占用的IP地址端口将被路由器回收。这个时候该次通讯必将终止，无论TCP仍是UDP，神马都是浮云。

更残酷的事实是，互联网可认为是由无数个路由器链接而成的，一个网络通讯每每须要经过n个路由器，每一个路由器都会为一次通讯创建本身的端口映射。只要其中一个路由器回收其端口，则整个通信中断。

这也是不少人疑惑为何TCP的KeepAlive参数没法保证长链接的缘由。TCP的KeepAlive默认是两个小时（并且该参数仍是TCP的可选实现，不是必然实现），在路由器端口映射老化时间的影响下，必然没法发挥其做用。实际上，该参数在单一的局域网内才可能被使用上，还要依赖具体的操做系统。

因为路由器端口映射的存在，加上智能终端频繁、长时间的休眠，TCP长链接的实用性在移动互联网状况下极大地打了折扣。

也由于如此，移动端IM、推送系统必须实现所谓的心跳包机制，以保持端口映射关系的老化时间不会减小到0而被回收，从而避免链接中断。（有关TCP协议下的心跳问题，请参见：《基于TCP协议的移动端IM仍然须要心跳保活机制》）

九、服务端承载能力

无论是UDP仍是TCP，最终都是应用服务端的设备去提供服务的。而TCP因为提供了安全可靠的流服务，其对计算机、网络资源的消耗是远远大于UDP协议的。对于配置较好的主流服务器，配备大量的内存（数十G至上百G内存），与高速的磁盘、网卡，是能同时支持数百万个TCP链接的。不过这里须要较专业的服务器设置，须要调整很多系统参数，再加上服务程序的配合。另外，TCP链接的创建、维持与释放，都是须要较昂贵的计算、网络资源的。

终端在线服务，如果一个较为简单的服务，未必使用上TCP众多的高级功能，但承受TCP的昂贵成本，未必值得。若是能用UDP来提供服务，单服务器的承载能力，是能够去到TCP服务的数十倍，甚至上百倍的增加。这也是为何DNS这种并发数巨大的服务器提供UDP接口的缘由。

另外，上百万TCP链接的网络服务，其编程的难度、程序复杂度、调试难度、服务器运维成本、网络成本等都远远高于UDP。

而UDP编程，与上百万个终端通信的难度与成本则低不少。若是提供的网络服务不是基于流的服务，也容许必定的失败机率（例如P2P），则UDP每每是更适合的方式。

十、高级应用网络通信要求

不过，移动端IM系统、推送系统一方面提供终端在线服务，另一方面也须要考虑内容信息的完整性和安全性。毕竟信息的丢失，或者通信的被窃听，都是难以接受的。而TCP无论在网络层的可靠性控制，仍是在应用层的安全支持（例如HTTPS），都为应用提供没法替代的强大功能和便利。

十一、结论

综合以上所述，其实答案也呼之欲出。

如今的移动端IM、推送系统，既面对移动互联网的不肯定性，又面对智能终端频繁的系统休眠、网络切换，还要考虑服务端的承载成本，对于在线服务而言UDP是比TCP更适合的方式。可是因为数据完整性、安全性的须要，又不该彻底放弃TCP的可靠与安全。

因此，我的认为，更恰当的方式应该是：两种通讯协议同时使用，各有侧重。UDP用于保持大量终端的在线与控制，应用与业务则经过TCP去实现。这个和FTP服务控制与数据分离，采起不一样的链接，有殊途同归之处。

事实上，这个也是即时通信巨头QQ所采用的方式。早期的时候，QQ仍是主要使用TCP协议，然后来就转向了采用UDP的方式来保持在线，TCP的方式来上传和下载数据。如今，UDP是QQ的默认工做方式，表现良好。相信这个也被沿用到了微信上。

简单的考证：登陆PC版QQ，关闭多余的QQ窗口只留下主窗口，并将其最小化。几分钟事后，查看系统网络链接，会发现QQ进程已不保有任何TCP链接，但有UDP网络活动。这时在发送聊天信息，或者打开其余窗口和功能，将发现QQ进程会启用TCP链接。

（本文同步发布于：http://www.52im.net/thread-33...）

做者：Jack Jiang(点击做者姓名进入Github)

出处：http://www.52im.net/space-uid...

交流：欢迎加入即时通信开发交流群215891622

讨论：http://www.52im.net/

Jack Jiang同时是【原创Java Swing外观工程BeautyEye】和【轻量级移动端即时通信框架MobileIMSDK】的做者，可前往下载交流。