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

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

1、引言

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

cover-opti

2、系列文章

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

  1. 《网络编程入门如此简单(一):假如你来设计网络,会怎么做?》
  2. 《网络编程入门如此简单(二):假如你来设计TCP协议,会怎么做?》
  3. 《网络编程入门如此简单(三):什么是IPv6?漫画式图文,一篇即懂!》
  4. 《网络编程入门如此简单(四):一文搞懂localhost和127.0.0.1》
  5. 《网络编程入门如此简单(五):UDP跟TCP相比,到底差了什么?》(* 本文)

3、写在前面

1、背景

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

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

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

女朋友:我不想听课本上讲的!我听不懂呀~

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

4、UDP协议的主要特点

2、UDP-的特点

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

1)沟通简单:

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

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

2)轻信他人:

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

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

3)不会讨价还价:

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

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

5、UDP协议的使用场景

3、UDP-使用场景

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

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

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

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

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

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

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

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

6、TCP协议的主要特点  

4、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 的数据结构长这样:

5

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

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

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

6

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

7

至此,我用大白话的方式讲解了 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)

相关推荐

鸿蒙原生即时通讯/IM系统RainbowTalk v2.8版发布,基于MobileIMSDK框架、ArkTS编写

💧 此版本解决了若干bug,以及ui和功能细节优化,同时支持最新鸿蒙7.0系统。

hellojackjiang2011的博客 163

深度剖析IM消息乱序的根本原因及优化方法

本文深度剖析即时通讯IM消息乱序的问题,梳理IM客户端时间戳不可信、多端并发、群消息扇出重试三大核心陷阱,拆解微信、钉钉、企业微信的时序设计方案,并从锚点设计、多端去交错、幂等兜底、可观测性等维度,给出IM项目消息时序性保证的落地优化策略。

hellojackjiang2011的博客 293

IM聊天不掉线?生产级WebSocket断线重连、心跳保活实战

本文将给出一套生产级Web端即时通信方案,包括心跳检测保活 + 指数退避重连,代码直接能跑。

hellojackjiang2011的博客 314

IM全文检索技术(五):vivo敏感词匹配系统的技术实践

本文将从算法选型入手,结合两个实际场景来介绍谛听系统的敏感词匹配算法。包括底层算法选型思路和两种实际场景下提升敏感词精准度、降低漏杀率的方案。

hellojackjiang2011的博客 189

Nginx生产级WebSocket实时长连接负载均衡,一文搞定

本文从基础配置、生产配置、Docker / K8s、安全、排障、性能调优,系统性讲清 WebSocket 在 Nginx 中的正确打开方式。

hellojackjiang2011的博客 308

即时通讯IM离线消息该怎么存?全面盘点主流存储方案

离线消息是IM系统的核心能力,当用户不在线时,消息必须可靠存储,待用户上线后完整推送。本文将对比主流的离线消息存储方案,帮你找到最适合业务场景的架构。

hellojackjiang2011的博客 310

移动端实时音视频聊天框架 RainbowAV v2.2.7发布

1)

hellojackjiang2011的博客 247

都HTML5了,Web端即时通讯技术到底该用什么?一文即懂!

本文分享的是 Web 端最常用即时通讯技术(包括 WebSocket、SSE、WebRTC、轮询等)的原理、优缺点与适用场景等,以及生产环境下的高并发场景下的进阶实践。

hellojackjiang2011的博客 341

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.1发布

此版本新增了短信验证码的注册和登录功能,解决了Android 16手机上发送文件失败等问题。

hellojackjiang2011的博客 209

IM千人群聊该不该用消息写扩散?详细算算成本账!

本文将为你详解 IM 群聊消息的写扩散技术原理以及写扩散过程中的服务端详细性能成本,同时对比了市面上IM大厂的技术方案,给出分规模架构选型与以及性能优化策略等。

hellojackjiang2011的博客 402

直播系统聊天技术(十):基于实时消息总线的活动系统架构设计

本文分享的是网易云音乐技术团队基于实时消息总线技术,解决了直播活动系统的模块灵活组合、消息治理与异步履约等问题,希望能给你带来启发。

hellojackjiang2011的博客 369

轻量级Web端IM即时通讯框架MobileIMSDK-Web,基于Socket.io库

MobileIMSDK-Web是一套Web端即时通讯框架,超轻量级、极少依赖,高度提炼、简单易用。

hellojackjiang2011的博客 286

socket长连接在手游场景下的技术实践

本文介绍了37手游基于B站goim框架自研长连接系统的实践。系统采用分层设计,支持多协议和发布/订阅机制,用于直播弹幕、实时推送等场景,实现了高性能与业务适配。

hellojackjiang2011的博客 403

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.0发布

RainbowChat 是一套基于 MobileIMSDK 开源通信框架的产品级移动端IM系统。可能是市面上开放源码的,唯一一款同时支持TCP、UDP、WebSocket三种网络通信协议的IM产品。

hellojackjiang2011的博客 518

社交场景下的统一即时通讯im消息流交互层模块化技术实践

这些IM场景,在消息流的展示形式上是极为相似的,同时每个业务又有着自己特殊的交互需求。基于此,我们对IM消息流能力做了标准化的构建,来减少IM功能的业务接入成本;同时也是为了统一各个业务的技术方案,减少跨业务开发的理解和维护成本。

hellojackjiang2011的博客 571

现代IM系统中聊天消息的同步和存储方案探讨

本文内容主要涉及IM系统中的消息系统架构,探讨一种适用于大用户量的消息同步以及存储系统的架构实现,能够支持消息系统中的高级特性“多端同步”以及“消息漫游”。在性能和规模上,能够做到全量消息云端存储,百万TPS以及毫秒级延迟的消息同步能力。

hellojackjiang2011的博客 75

即时通讯安全篇(十六):对称加密 vs 非对称加密?一文搞懂

本文将以通俗案例讲解加密本质,介绍对称加密(含 AES、迪菲–赫尔曼密钥交换)与非对称加密(RSA)原理、特点及应用,并阐释其数学基础。

hellojackjiang2011的博客 397

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

本文将从H5游戏场景下的实时信息更新需求切入,探讨下在类似这种高并发、低延迟的业务需求中,如何使用 IM 方案来解决频繁的数据更新问题,也顺便介绍下 WebSocket 的基本运作流程等。

hellojackjiang2011的博客 1069

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

RainbowTalk 是一套基于 MobileIMSDK 开源通信框架的产品级纯血鸿蒙NEXT端IM系统。RainbowTalk 由纯ArkTS编写、全新开发,没有套壳、也没走捷径,原生“纯血”。

hellojackjiang2011的博客 1227

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

本文主要聚焦分布式IM聊天系统消息可靠性问题,即如何保证消息不丢失。

hellojackjiang2011的博客 732

如何保障分布式IM聊天系统的消息有序性(即消息不乱)

本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

hellojackjiang2011的博客 835

B站即时通讯IM消息系统的新架构升级实践

本文要分享的是B站IM消息系统的新架构升级实践总结,内容包括原架构的问题分析,新架构的整体设计以及具体的升级实现等。

hellojackjiang2011的博客 714

AI大模型爆火的SSE技术到底是什么?万字长文,一篇读懂SSE!

本文从SSE(Server-Sent Events)技术的原理到示例代码,为你通俗易懂的讲解SSE技术的方方面面。

hellojackjiang2011的博客 786

腾讯新闻APP的消息推送Push架构技术重构实践

本文主要分享的是腾讯技术团队近年来对腾讯新闻消息推送PUSH系统做的架构优化和技术实践。

hellojackjiang2011的博客 843

移动端弱网优化专题(十五):字节跳动移动端网络HttpDNS优化实践

本文要分享的是字节跳动团队针对火山HTTPDNS Cache2.0通过自研网段库与动态划分算法,将缓存粒度从“城市-运营商”细化为“网段”,解决了传统方案的城市级调度污染问题。配合缓存分级、预取等优化,在提升调度精准度的同时保证了高命中率,最终实现了服务端调度准确性提升和客户端性能优化。

hellojackjiang2011的博客 720

转转客服IM聊天系统背后的技术挑战和实践分享

在当今互联网时代,高效的用户服务是提升用户体验的关键。转转自研的客服IM聊天系统作为用户与客服沟通的桥梁,承担着传递信息、解决问题的关键角色。然而,消息数据的流转并非一帆风顺,本文将深入探讨IM系统在消息传递过程中遇到的问题和挑战,以及相应的技术解决方案。

hellojackjiang2011的博客 1096

ChatGPT如何实现聊天一样的实时交互?快速读懂SSE实时“推”技术

本文将带你快速认识SSE实时通信协议,包括它的技术原理、常见使用场景、与同类技术的对比以及简单的示例代码等。

hellojackjiang2011的博客 124

全面适配iOS 26液态玻璃,基于开源IM即时通讯框架MobileIMSDK:RainbowChat-iOS端v10.2发布

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统。

hellojackjiang2011的博客 1157

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

本篇文章我们以TCP协议的网络编程逻辑,从Socket缓冲区的角度去拆解,为什么号称可靠传输的TCP协议,在代码中调用send并成功发出数据,并不意味着这个数据就一定通过物理网络发出去了。

hellojackjiang2011的博客 125

即时通讯安全篇(三):一文读懂常用加解密算法与网络通讯安全

作为开发者,也会经常遇到用户对数据安全的需求,当我们碰到了这些需求后如何解决,如何何种方式保证数据安全,哪种方式最有效,这些问题经常困惑着我们。52im社区本次着重整理了常见的通讯安全问题和加解密算法知识与即时通讯/IM开发同行们一起分享和学习。

hellojackjiang2011的博客 121
上一篇: 基于WebSocket的IM即时通信方案在H5游戏场景下的技术实践
下一篇: 即时通讯安全篇(十六):对称加密 vs 非对称加密?一文搞懂
jackjiang2025
jackjiang2025 网际时代技术分享账号 网际时代技术分享账号
博客等级 码龄8年 700粉丝 318原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值