网络编程入门如此简单(五)：UDP跟TCP相比，到底差了什么？

本文由悟空聊架构分享，有修订和排版优化。

1、引言

本文将通俗易懂地为你类比解释UDP与TCP的核心差异，包括如何基于UDP实现TCP的可靠传输：通过模拟三次握手、添加序列号与确认机制解决顺序和丢包问题，利用滑动窗口控制流量，并引入拥塞控制算法来动态调整发送速率等。

2、系列文章

本文是该系列文章中的第 5 篇：

3、写在前面

本题是我在面试中，技术总监问我的一道真题，当时答得不太好，所以把它揪出来总结了下。后来问了下总监，总监说这是阿里的面试题。。

其实面试官主要是想让我说出 UDP 和 TCP 的原理上的区别，怎么给 UDP 加些功能实现 TCP。

看好去很容易就能说出一两个 TCP 和 UDP 的区别，但如果能用女朋友都能听懂的方式该怎么说呢？

女朋友：我不想听课本上讲的！我听不懂呀~

下面我会以大白话的方式来解答上面的问题。

4、UDP协议的主要特点

UDP 让我想起了刚毕业参加工作那会，一名毕业菜鸟。

1）沟通简单：

领导安排的任务，直接干就完了。

UDP 也是，相信网络世界永远是美好的，我发送的包是很容易送到的，接收方也是很容易组装的。数据结构也很简单，不需要大量的数据结构、处理逻辑、包头字段。

2）轻信他人：

测试人员报的 bug 我也不会和她争论什么，永远相信测试人员是对的，测试人员说啥就是啥，我改就是。

UDP 也是，不会建立连接，有个端口号，谁都可以监听这个端口号往上面发数据。也可以从这个端口号传给任何人数据。反正我只管发就是。

3）不会讨价还价：

产品经理昨天说手机壳需要根据心情变色，测试人员说这个 bug 要把关联的两个 bug 一起修掉。那就按照他们说的做吧！

UDP 也是，不懂坚持和退让。也就是根据网络情况进行拥塞控制。无论网络丢包多严重，我还是照样发~

5、UDP协议的使用场景

针对像我那时候毕业菜鸟的情况，领导给我安排了三种工作环境让我选。

1）内部系统，任务简单，模块单一，不需要考虑代码的关联影响，即使失败了也没有关系。

UDP 也是，需要资源少，网络情况比较好的内网，或者对于丢包不敏感的应用。

2）有一个强力的团队支持，都是中高级开发、测试人员，团队成员打过很多年交道，互相信任。有什么问题，吼一嗓子就可以了！

UDP 也是，不需要一对一沟通来建立连接，可以广播的应用。

3）一个新项目，需要有激情，对于刚毕业的菜鸟，都是有很强的自主能动性的，也不会耍滑头，躲在厕所玩手机，带薪拉shi ？即使项目不忙，我也抓紧时间干。项目忙，还是一样干！

UDP 也是，猛着发包就是，主要应用在需要处理速度快，时延低，可以容忍少数丢包的情况。即使网络情况不佳，发包就是~

针对上面的三大场景，UDP 常用在实时竞技游戏，IoT 物联网，移动通信领域。

6、TCP协议的主要特点

6.1 面向连接

TCP 和 UDP 是传输层里面比较重要的两个协议。大部分面试的时候都会问到两者的区别。而大部分都会两句，比如 TCP 是面向连接的，UDP 是面向无连接。

那什么是面向连接？

TCP 三次握手是我们常常念叨和背诵的。而在这三次握手成功后，就是建立连接成功。

那什么又叫面向呢？

我们也常听到面向对象编程、面向切面编程、面向服务编程。那到底什么是面向？

在我看来面向就是遵循一定的协议、规范、数据结构等来做一系列事情。

比如面向连接，就是为了在客户端和服务端维护连接，而建立一定的数据结构来维护双方交互的状态，用这样的数据来保证所谓的面向连接的特性。

知道了 TCP 的是用三次握手来建立连接，那我们是否可以让 UDP 也发三个包来模拟 TCP 建立连接？可以是可以，但是如果只是建立，而不是面向连接，其实意义不大。

那 TCP 面向连接做了哪些事情？

TCP 提供可靠交付，通过 TCP 连接传输的数据，可以无差错、不丢失、不重复、并且按序到达。而 UDP 继承了 IP 包的特性，不保证不丢失，不保证按顺序到达。

6.2 面向字节流

TCP 是面向字节流，所谓字节流，就是发的是一个流，没头没尾。TCP 自己维护流状态。

UDP 基于 IP 数据报，一个一个地发，一个一个地收。

6.3 拥塞控制

TCP 拥有拥塞控制，如果包丢弃了或者网络环境不好了，就会根据网络情况自行控制自己的行为，看下是发快点还是发慢点。

UDP 则没有这么智能了，你让我发，我就发呗，反正是你让我发的，其他的一概不管~

6.4 有状态服务

TCP 是一个有状态的服务，有状态可以理解为：我记录了哪些发送了，哪些没有发送，哪些接收到了，哪些没接收到，应该接收哪个了，一点差错都不行。TCP 干的事情可真多！

而 UDP 则不是有状态的服务，我只管发，其他的就交给接收端吧，有点任性是吧？

7、如何让UDP追上TCP的能力？

建立连接上面已经讲到了，三次握手和四次握手，UDP 也可以模拟去做。

那下面还有几个问题：

1）顺序问题；
2）丢包问题；
3）流量控制；
4）拥塞控制。

TCP 的数据结构长这样：

其实如果你能把这些结构讲清楚，就已经理解了 TCP 的核心功能。下面我还是用大白话的方式来讲解上面的四个问题。

顺序问题和丢包问题可以利用确认与重发的机制。假如包收到了，可以做一个确认，发送一个 ACK 给发送端，告诉他我收到了。假如有的包提前到了，就缓存着。假如有包丢失了，就可以超时重试。超时重试不宜过短，时间必须大于往返时间 RTT，否则会引起不必要的重传。也不宜过长，如果超时时间过长，访问就变慢了。那怎么确定这个时间，可以通过采样 RTT 的时间，进行加权平均。还需要根据网络状况，动态变化。可以了解下自适应重传算法。

流量控制就是根据网络情况调整发包的速率。利用的是滑动窗口。在对于包的确认中，同时会携带一个窗口的大小，只要利用好这个窗口大小，就能很好地调整发包速率，发的报文段不要超过窗口的大小就 OK。

拥塞控制主要用来避免包丢失和超时重传，如果出现了这两种现象，就说明发的速率太快了。那最开始怎么知道发送速率呢？其实开始时只发送一个报文段数据，如果收到一个确认，则倍增报文段，依次类推。当发现超时重传时，就又回到只发送一个报文段的情况，这个就是慢启动，这种方式不合适。其实还有一种快速重传算法，简单来说就是拥塞窗口减半，后续线性增速。针对于算法怎么实现的，这里就不展开讲述了。

至此，我用大白话的方式讲解了 UDP 和 TCP 的区别，以及 UDP 缺什么功能，需要怎么去弥补才能实现 TCP 的功能。相信这样回答的思路可以让面试官觉得还是有点东西的。

8、参考资料

[1] TCP/IP详解 - 第11章·UDP：用户数据报协议

[2] TCP/IP详解 - 第17章·TCP：传输控制协议

[3] 通俗易懂-深入理解TCP协议（上）：理论基础

[4] 通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理

[5] 快速理解TCP协议一篇就够

[6] 快速理解TCP和UDP的差异

[7] 快速理解为什么说UDP有时比TCP更有优势

[8] 一泡尿的时间，快速搞懂TCP和UDP的区别

[9] 跟着动画来学TCP三次握手和四次挥手

[10] 假如你来设计网络，会怎么做？

[11] 假如你来设计TCP协议，会怎么做？

[12] 深入地理解UDP协议并用好它

[13] 如何让不可靠的UDP变的可靠？

[14] UDP比TCP高效？还真不一定！

[15] 可靠传输的TCP协议send成功就意味着数据一定发出去了？

[16] 为何基于TCP协议的移动端IM仍然需要心跳保活机制？

[17] 技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解

即时通讯技术学习：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

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

posted @ 2026-03-17 15:35 Jack Jiang 阅读(15) | 评论 (0) | 编辑收藏

基于WebSocket的IM即时通信方案在H5游戏场景下的技术实践

摘要: 本文由网易云音乐技术团队入云分享，有修订和排版优化。1、引言说起 IM，大家应该都或多或少了解过一些，一般被熟知是在一些聊天场景里应用的比较多；而一般情况下我们常接触的业务中大多是做一些接口的查询提交之类的操作，用正常的 Ajax 请求就足以满足需求，比较难接触到 IM 这种方案。但如果涉及到一些需要频繁更新数据的业务场景，使用常规接口查询难免会给服务端造成比较大的性能开销，并且数据更新的延迟也会... 阅读全文

posted @ 2026-03-02 21:56 Jack Jiang 阅读(39) | 评论 (0) | 编辑收藏

鸿蒙Next原生IM即时通讯RainbowTalk，纯ArkTS编写，基于开源MobileIMSDK框架

1、基本介绍

RainbowTalk 是一套基于 MobileIMSDK 开源通信框架的产品级纯血鸿蒙NEXT端IM系统。RainbowTalk与姊妹产品 RainbowChat技术同源，不同于市面上某些开源或售卖的demo级代码，RainbowChat已被成千上万真实的客户使用过，解决了大量的产品逻辑、代码逻辑、细节优化等问题。
RainbowTalk 由纯ArkTS编写、全新开发，没有套壳、也没走捷径，原生“纯血”（详见：《RainbowTalk详细介绍》）。
RainbowTalk 无闭源代码（包括核心通信层），这与市面上知识产权来路不明、无核心技术、无售后的“三无”产品，或打着开源名义实则闪烁其词不开源核心的产品有本质区别。
RainbowTalk 是 RainbowChat 和 RainbowChat-Web 的姊妹产品。
☞ 详细介绍：http://www.52im.net/thread-4822-1-1.html
☞ 运行截图：http://www.52im.net/thread-4824-1-1.html （运行视频）
☞ 下载体验：http://www.52im.net/thread-4825-1-1.html

2、关于MobileIMSDK开源框架

MobileIMSDK 是一套全平台开源IM即时通讯聊天框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，客户端支持iOS、Android、H5、小程序、Uniapp、标准Java、纯血鸿蒙等，服务端基于Netty编写，性能卓越、易于扩展。
工程同步开源地址：
❶ GitHub：https://github.com/JackJiang2011/MobileIMSDK
❷ 码云gitee： https://gitee.com/jackjiang/MobileIMSDK
❸ Gitcode：https://gitcode.com/hellojackjiang2011/MobileIMSDK

3、功能情况

1）支持文本消息、语音留言消息、图片消息、大文件消息（支持断点上传）、短视频消息、个人名片、群名片、Emoji表情、消息撤回、消息转发、消息引用、“@”功能、“扫一扫”功能等；
2）支持一对一陌生人聊天模式；
3）支持一对一正式好友聊天模式；
4）支持多对多群聊聊天模式；
5）完善的群组信息管理：建群、退群、解散、转让、邀请、踢人、群公告等；
6）完整的注册、登陆（同时支持手机验证码登录和密码登录）、密码找回等功能闭环；
7）个人中心功能：改基本信息、改个性签名、改头像、改密码等；
8）支持个人相册查看；
9）完整的离线消息/指令拉取机制；
10）完整的本地消息/指令缓存机制，节省网络流量；
11）完整的富媒体文件（语音、大文件、图片、短视频）缓存机制，节省网络流量；
12）完整的好友关系管理：查找好友、发出请求、处理请求、删除好友、好友备注等；
13）其它未提及的功能和特性请自行下载体验。
RainbowTalk线上版本目前仅作演示和研究之用，运行环境配置最小化（仅1核1G和1MB带宽），请客观评估。

4、技术亮点

1）与姊妹产品RainbowChat 技术同源（算法和功能逻辑历经时间考验和大量客户面辐射，可靠性一定优于短时间内堆砌功能的产品）；
2）从通信底层到上层功能，完全自主开发——版权清晰、技术资产可控；
3）超轻量级——纯ArkTS编写且无任何重依赖；
4）通讯核心层基于MobileIMSDK 工程，保证了业务代码与通信核心的高度分层（经验不足的IM产品是做不到这一点的）；
5）支持完整的消息送达保证（QoS）机制，保证送达率，理论丢包率约为0.0001%；
6）基于 MobileIMSDK 工程的自有协议，未来的流量压缩对于APP端的节电控制和流量控制、服务端的网络吞吐等都有完全的控制能力；
7）完善的网络状况自动检测、断网重连等服务自动治愈能力；
8）核心通信算法和实现均为自主原创（历经10年，并非开源拼凑），保证了技术的持续改进、升级、扩展；
9）聊天协议兼容和互通：实现了与姊妹产品RainbowChat、RainbowChat-Web的完全兼容和消息互通；

5、技术原则

为了更易学习、研究、2次开发，RainbowTalk始终遵从：
1）界面与通信解偶：UI界面与网络通信层和数据处理层代码解耦，UI界面的重构、维护、改版都非常容易和优雅；
3）核心内聚和收敛：得益于长期的提炼和经验积累，网络通信核心层高度封装，开发者无需理解复杂网络算法。
4）纯 ArkTS 实现：纯ArkTS编写，无重量级框架和库依赖（更无Native代码），可干净利落地对接各种既有系统；
5）跨平台运行能力：受益于鸿蒙系统的跨端特性，理论上本应用的客户端可运行于任何支持鸿蒙Next的平台上；
6）架构设计简洁：简单直接，易于学习，能少一个分层则绝不强行炫技；
7）简单地就是最好的：始终贯彻简单直接的互联网产品技术理念。

6、主要功能运行截图

（☞ 更多运行截图、更多运行视频、详细介绍 ☜)
（本文内容引用自：http://www.52im.net/thread-4822-1-1.html）

posted @ 2026-02-25 17:47 Jack Jiang 阅读(32) | 评论 (0) | 编辑收藏

如何保障分布式IM聊天系统的消息可靠性（即消息不丢）

本文引用了45岁老架构师尼恩的技术分享，有修订和重新排版。

1、引言

接上篇《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》，本文主要聚焦分布式IM聊天系统消息可靠性问题，即如何保证消息不丢失。

2、系列文章

为了更好以进行内容呈现，本文拆分两了上下两篇。

本文是2篇文章中的第 1 篇：

《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》
《如何保障分布式IM聊天系统的消息可靠性（即消息不丢）》（☜ 本文）

本篇主要聚焦的是分布式IM聊天系统消息可靠性问题。

3、痛点拆解：聊天消息总是丢？不是网络差，是设计没兜底

产品做着做着，用户开始投诉：“我明明发了消息，对方怎么没收到？”。你查日志发现——消息真丢了。但更可怕的是：你也不知道它什么时候丢的。

这背后，其实是移动场景下的经典三连击：

1）地铁进隧道，网络闪断；
2）App 被系统杀掉，进程没了；
3）对方服务器刚好在发布，接口500……

你以为只是“发一下”，其实要穿越重重险境才能抵达。

结果就是：

- 消息发不出去 → 用户以为被无视；
- 或者重试太多 → 对方收到一堆重复“在吗？”；
- 最后用户体验崩了，客服工单爆了。

所以问题本质不是“快不快”，而是：

“宁可慢点，也不能丢；就算重发，也不能重复。”

这就是我们常说的可靠消息投递 ——一个看似简单的需求，却是高可用系统的分水岭。

4、解决方案：三层兜底，像保险一样层层防

光靠“发一次”肯定不行。

我们要学保险公司，给关键消息上三重保险：

1）自己先复印一份存档 → 客户端本地存
2）邮局签收后锁进保险柜，并异地备份 → 服务端落盘 + 副本
3）如果没收到回执，隔段时间再寄，但对方只认一次 → 超时重试 + 幂等去重

每一层都不贵，合起来却能扛住99%的异常。下面看每层怎么落地。

5、第一层：客户端兜底 —— 消息先存本地，解决网络不稳定问题

记住一句话：只要没收到 ACK，就当没发成功。

所以第一步不是联网，而是先把消息塞进手机本地数据库（比如 SQLite）。

就像下面这样：

db.saveLocalMsg(msg); // 先落库，保命
boolean sendOk = network.send(msg);
if (!sendOk) {
scheduleRetry(msg, 1000); // 发失败？排队重试
}

再加上客户端scheduleRetry 采用阶梯式重试策略：

1）第1次失败 → 1秒后重试
2）第2次失败 → 3秒后重试
3）第3次失败 → 5秒后重试

避免雪崩式刷屏，既保障可靠性，又不压垮服务。只有等到服务端明确说“我收到了”，才把这条消息从本地删掉。

就像快递发货单：客户签收了，你才能撕票。

这样哪怕 App 崩溃、手机重启，下次打开照样继续发——用户体验无缝衔接。而如果不做这一步？一旦断网或崩溃，消息直接蒸发，用户永远不知道。

6、第二层：服务端兜底 —— 实现服务端持久化的高可靠

客户端发来了，服务端能不能直接处理完就返回？绝对不行！

如果此时机器宕机，消息还在内存里没来得及持久化，那就真的丢了。

正确做法是两步走：

1）收到消息立刻写入 RocketMQ（支持刷盘、集群同步）；
2）同步复制到至少3个副本节点，确保单点故障不丢数据。

伪代码如下：

rocketMQ.send(msg); // 必须落盘，断电也不怕
replicaService.syncTo3Replicas(msg); // 多副本容灾
response.sendAck(msg.getUniqueKey()); // 此时才能回 ACK

这一步的关键是：ACK 必须在落盘之后发！否则就是“虚假确认”，等于骗客户端“我收到了”，其实自己也没保住。

这一层扛住了服务端单机崩溃的风险，是整个链路的数据基石。

7、第三层：幂等性设计 —— 保障exact one

前面两层解决了“存得住”的问题，但这还不够。现实是：网络可能超时、包可能丢失、ACK 可能没传回来。

于是客户端必须重试。但重试带来新问题：

“我已经处理过了，再来一遍怎么办？”

解决办法是：用唯一键 + 幂等控制。

每个消息生成全局唯一的 key（如 sessionID:msgID），服务端通过 Redis 的原子操作判断是否已处理。

就像下面的代码这样：

String uniqueKey = msg.getUniqueKey();
if (redis.setNx(uniqueKey, "processed", 86400)) {
processMsg(msg); // 第一次来，正常处理
} else {
log.info("重复消息，忽略：{}", uniqueKey);
}

setNx 是关键：只有 key 不存在时才设置成功，保证多实例并发下也不会重复消费。