移动端IM系统的协议选型:UDP还是TCP?

1、前言

对于有过网络编程经验的开发者来说,使用何种数据传输层协议来实现数据的通信,是个非常基础的问题,它涉及到你的第一行代码该如何编写。

从PC时代的IM开始,IM开发者就在为数据传输协议的选型争论不休(比如:《为什么QQ用的是UDP协议而不是TCP协议?》这样的问题,隔一段时间就能在社区里看到)。到了移动互联网时代,鉴于移动网络的不可靠性等特点,再加上手机的省电策略、流量压缩等,为这个问题的回答增了更多的不确定因素。

对于有选择困难证的人来说,基于以上因素,加上UDP和TCP协议的本质差异,这样的选择确实很纠结。本文将从作者的实践总结,给出自已的观点,如有异议还请理性回复,不为找喷,仅供参考。

说明:本文引用了DDPush的技术资料,感谢原作者。

2、学习交流

- 即时通讯开发交流群: 215891622 [推荐]

- 移动端IM开发推荐文章:《新手入门一篇就够:从零开发移动端IM

3、UDP vs TCP

TCP还是UDP?长连接如何实现?如何实现心跳机制?心跳的间隔如何确定?这些问题都是讨论移动端IM、消息推送等类似话题时,几乎一定被问到的问题。这里尝试正本清源一下。

4、互联网、移动互联网网络环境

在分析到底应该使用UDP还是TCP之前,有必要先讨论一下互联网与移动互联网的网络环境特点。

互联网的网络基础建设,经过十几年长期的发展,已经较为稳定和成熟,PC终端、操作系统的能力也达到了较高的水平。

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

所以,在互联网的环境里面,网络应用程序由于网络设施、操作系统的成熟,开发使用起来比较容易,资源也较为充足。而移动互联网还是要“斤斤计较”。

5、智能终端电池续航能力,系统休眠

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

6、IPv4资源、端口资源

这个话题往往被很多人忽略,但它有着至关重要的影响。虽然大部分人都很清楚IP地址的紧缺导致的动态IP分配的必然,却忽略了由于IP地址不足引起的端口资源不足。

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

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

7、端口映射老化时间

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

端口映射老化时间,比很多人想象中的要短很多。一般的家用宽带路由器,老化时间一般是两三分钟;在有线宽带运营商接入部分,老化时间可能少于两分钟。在无线电话网络运营商接入部分(例如GPRS连接),老化时间甚至不超过一分钟!

也就是说,任何一个网络通讯(不管是TCP或UDP),如果几分钟之内没有网络报文传输,其占用的IP地址端口将被路由器回收。这个时候该次通信必将终止,不管TCP还是UDP,神马都是浮云。

更残酷的事实是,互联网可认为是由无数个路由器连接而成的,一个网络通信往往需要通过n个路由器,每个路由器都会为一次通信建立自己的端口映射。只要其中一个路由器回收其端口,则整个通讯中断。

这也是很多人疑惑为什么TCP的KeepAlive参数无法保证长连接的原因。TCP的KeepAlive默认是两个小时(而且该参数还是TCP的可选实现,不是必然实现),在路由器端口映射老化时间的影响下,必然无法发挥其作用。实际上,该参数在单一的局域网内才可能被使用上,还要依赖具体的操作系统。

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

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

8、服务端承载能力

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

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

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

而UDP编程,与上百万个终端通讯的难度与成本则低很多。如果提供的网络服务不是基于流的服务,也允许一定的失败机率(例如P2P),则UDP往往是更适合的方式。

9、高级应用网络通讯要求

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

10、结论

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

现在的移动端IM、推送系统,既面对移动互联网的不确定性,又面对智能终端频繁的系统休眠、网络切换,还要考虑服务端的承载成本,对于在线服务而言UDP是比TCP更适合的方式。但是由于数据完整性、安全性的需要,又不应完全放弃TCP的可靠与安全。

所以,个人认为,更恰当的方式应该是:两种通信协议同时使用,各有侧重。UDP用于保持大量终端的在线与控制,应用与业务则通过TCP去实现。这个和FTP服务控制与数据分离,采取不同的连接,有异曲同工之处。

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

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

11、参考资料

为什么QQ用的是UDP协议而不是TCP协议?
UDP中一个包的大小最大能多大
基于TCP协议的移动端IM仍然需要心跳保活机制
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
计算机网络通讯协议关系图(中文珍藏版)
理论经典:TCP协议的3次握手与4次挥手过程详解
微信对网络影响的技术试验及分析(论文全文)

(本文同步发布于:http://www.52im.net/thread-33-1-1.html

附录:更多IM技术文章

[1] 网络编程基础资料:

TCP/IP详解 - 第11章·UDP:用户数据报协议

TCP/IP详解 - 第17章·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:压力测试报告

>> 更多同类文章 ……

[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

时间: 2024-10-01 02:41:30

移动端IM系统的协议选型:UDP还是TCP?的相关文章

【转帖】计算机网络协议(三)——UDP、TCP、Socket

计算机网络协议(三)——UDP.TCP.Socket 2019年09月04日 11:09:41 to_be_better_one 阅读数 28794 文章标签: 计算机网络UDPTCPSocket 更多 分类专栏: 计算机网络协议 版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/ghw15221836342/article/details/100531810 底层网络知识详解:最重要的传输

网络协议(UDP与TCP协议总结)

一.知识储备: 1.网络通讯三要素: IP地址:InetAddress 网络中设备的标识 不易记忆,可用主机名 本地回环地址:127.0.0.1  主机名:localhost 端口号 用于标识进程的逻辑地址,不同进程的标识 有效端口:0~65535,其中0~1024系统使用或保留端口. 备注:不是所谓的物理端口! 传输协议 通讯的规则 常见协议:TCP,UDP 2.UDP与TCP协议的特点: UDP: 1.将数据源和目的地封装到数据包中,不需要建立连接 2.每个数据包的大小限制在64k以内 3.

JAVA基础学习day24--Socket基础一UDP与TCP的基本使用

一.网络模型 1.1.OIS参考模型 1.2.TCP/IP参考模型 1.3.网络通讯要素 IP地址:IPV4/IPV6 端口号:0-65535,一般0-1024,都被系统占用,mysql:3306,oracle:1521 传输协议:TCP/UDP 二.类 InetAddress 2.1.InetAddress 主机对象 IP 地址是 IP 使用的 32 位或 128 位无符号数字,它是一种低级协议,UDP 和 TCP 协议都是在它的基础上构建的 2.2.示例 import java.net.*;

第五章 运输层(UDP和TCP三次握手,四次挥手分析)

序言   通过这章,可以知道其实三次握手和四次挥手其实真的好简单,通过这章的学习,我相信你也会同样的认为,以后在也不需要听到别人问三次握手的过程而自己一脸懵逼了,觉得人家好屌,其实也就是他懂你不懂,仅此而已,不懂就去学.学了你就会觉得其实也就那样,没有什么厉害的,这让我回想以前刚学习编程的时候,那时候刚学C,别人就说会写java的helloworld,真TM觉得屌啊,我连helloworld是什么度不知道.一直羡慕人家,怎么这么厉害,然后自己心里很虚,自己这么菜啊,其实不然,不懂的就去学习,学懂

TCP协议,UDP协议,Utp,双绞线,DHCP协议,子网掩码,LAN,VLAN,网口,服务器,UI设计,Linux系统,Unix系统,名词解释

TCP协议: TCP:Transmission Control Protocol 传输控制协议TCP是一种面向连接(连接导向)的.可靠的.基于字节流的运输层(Transport layer)通信协议,由IETF的RFC 793说明(specified).在简化的计算机网络OSI模型中,它完成第四层传输层所指定的功能,UDP是同一层内另一个重要的传输协议. UDP协议: UDP 是User Datagram Protocol的简称, 中文名是用户数据报协议,是OSI(Open System Int

TCP协议与UDP协议的区别

TCP协议与UDP协议的区别 首先咱们弄清楚,TCP协议和UCP协议与TCP/IP协议的联系,很多人犯糊涂了,一直都是说TCP/IP协议与UDP协议的区别,我觉得这是没有从本质上弄清楚网络通信! TCP/IP协议是一个协议簇.里面包括很多协议的.UDP只是其中的一个.之所以命名为TCP/IP协议,因为TCP,IP协议是两个很重要的协议,就用他两命名了.   常用的网络协议 -UDP:概念来自于"电报"     -只管发送,不确认对方是否收到     -以数据包的形式发送,每个数据包不能

《网络协议》UDP 协议

概述 UDP 是无连接.不可靠的数据报传输层协议,为应用程序发送和接收数据报,只是将数据报的分组从一台主机发送到另一台主机,但并不保证数据报能够到达另一端,任何必须的可靠性都由应用程序提供.在 UDP 情况下,虽然可以确保发送消息的大小,却不能保证消息一定会达到目的端.没有超时和重传功能,当 UDP 数据封装到 IP 数据报传输时,如果丢失,会发送一个 ICMP 差错报文给源主机. 即使出现网络阻塞情况,UDP 也无法进行流量控制.此外,传输途中即使出现丢包,UDP 也不负责重发,甚至当出现包的

【网络协议】UDP协议

UDP是一个简单的面向数据报的运输层协议:进程的每个输出操作都会产生一个UDP数据报,并组装成一份待发送的IP数据报,这与面向字符流的协议不同,如TCP,应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系(主要是在传输层就进行分段了,因此不会受IP分片的影响). UDP的首部一共8个字节,很简单,可以参考书上,这里也不再详说. UDP的校验和 至于UDP的校验和,这里注意下区别就好了,UDP对首部和数据部分都进行校验,而IP首部的校验和仅对IP的首部进行校验,顺带提下TCP,TCP

在网络7层协议中,如果想使用UDP协议达到TCP协议的效果,可以在哪层做文章?(QQ 为什么采用 UDP 协议,而不采用 TCP 协议实现?)

为了解决这题,可以具体看看下面这个讨论. 解灵运工程师 185 人赞同 某次架构师大会上那个58同城做即时通信的人说:原因是因为当时没有epoll这种可以支持成千上万tcp并发连接的技术,所以他们使用了udp,然后在udp上面封装了一下,模拟了一下tcp,解决了大并发的问题,之后因为做的很nb了,虽然epoll这种技术出现了,还是没有改回使用tcp了.现在再做类似的东西就不需要使用udp了.这个说法应该比较可信的. 发布于 2014-04-16 18 条评论 感谢 分享 收藏 • 没有帮助 •