一篇把 TCP 和 UDP 讲明白

为什么打游戏宁可偶尔丢一帧也不愿多等 100 毫秒一篇把 TCP 和 UDP 讲明白很多人第一次学计算机网络时看到TCP和UDP脑子里往往只剩下两句话TCP可靠UDP不可靠然后就没有然后了。可一旦开始做项目、写后端、学网络编程问题就会一口气冒出来为什么浏览器打开网页、下载文件几乎总是绕不开TCP为什么语音通话、直播、游戏同步很多时候反而更喜欢UDP为什么TCP发数据之前要“三次握手”UDP却像抬手就发为什么都叫“传输协议”它们在实际体验上却像两个完全不同的世界真正难住我们的从来不是“背不下来定义”而是我们没有真正看见数据在网络里到底是怎么被送出去、确认、重传、排序和到达的。这篇文章不打算只告诉你“TCP面向连接UDP无连接”这几个字就结束。我们会从生活类比、图示、核心机制、典型场景一路讲到“什么时候该选谁”。如果你能顺着读完至少会收获三件事真正理解TCP和UDP的底层区别而不是只会背八个字看懂为什么TCP更稳为什么UDP更轻遇到下载、聊天、直播、游戏这些场景时知道该优先想到谁一句话先讲透本质如果只用一句话概括TCP先建立连接再提供可靠、按序的字节流传输UDP不建立连接直接发数据报尽力而为开销更小很多人第一次看到这句话还是会有点抽象。没关系你可以先把它们想成两个画面TCP像寄“挂号信”或“顺丰保价件”要登记、要确认、要保证尽量完整送达UDP像对讲机喊话不先建复杂流程先把消息尽快发出去至于有没有漏一句要看场景自己权衡这两个画面一旦立住了后面很多细节都会顺下来。先别急着分谁好谁坏它们根本不是同一种思路TCP和UDP都属于传输层协议它们都运行在IP之上但做事风格完全不同。如果平台支持 Mermaid可以先看这张图应用层HTTP / DNS / 视频通话 / 游戏传输层TCP 或 UDP网络层IP链路层以太网 / Wi-Fi如果平台不支持 Mermaid也可以直接看这个版本应用层HTTP / DNS / 视频通话 / 游戏 | 传输层TCP 或 UDP | 网络层IP | 链路层以太网 / Wi-Fi你可以把它理解成应用层关心“我要传什么”传输层关心“我怎么传”TCP和UDP就是两种不同的“传法”一图先看懂TCP 和 UDP 到底差在哪对比项TCPUDP是否建立连接是否可靠性提供可靠传输机制不保证可靠送达是否保证顺序保证按序不保证按序是否重传会默认不会是否有流量控制有没有内建机制是否有拥塞控制有没有内建机制数据形式字节流数据报传输开销较大较小典型场景网页、文件、登录、数据库直播、语音、游戏、DNS如果你现在只能先记住一句话那就记这个TCP 追求“稳稳送到”UDP 追求“尽快送出”。注意是“追求重点不同”不是简单的谁高级、谁落后。TCP为什么它更稳1. TCP 不是一上来就发它先“确认关系”TCP的第一步不是传业务数据而是先建立连接这就是很多人熟悉的“三次握手”。服务器客户端服务器客户端SYNSYN ACKACK如果平台不支持 Mermaid可以把三次握手理解成客户端 - 服务器SYN 服务器 - 客户端SYN ACK 客户端 - 服务器ACK你可以把它理解成下面这段对话客户端我想跟你建立连接你能听到我吗服务器我能听到你我也愿意建立连接你能听到我吗客户端我也能听到你那我们正式开始三次握手的核心目的不是“走流程”而是为了确认双方都具备发送能力双方都具备接收能力双方都同意建立这条逻辑连接所以这里的“连接”不是拉了一根实体网线而是客户端和服务器都进入了一种彼此认可的通信状态。2. 为什么不是两次握手这是初学者特别爱问的问题。如果只有两次客户端发出请求服务器回复“可以”那服务器并不能百分百确认客户端已经收到自己的回复也就不能很好地确认“双方都准备好了”。第三次握手本质上是在告诉服务器你的回复我收到了我们这边也准备好了。它让双方的状态更完整也能避免一些历史旧报文带来的混乱。你不需要一开始就死磕特别底层的状态机细节但一定要先理解三次握手不是为了复杂而是为了把“双方都准备好”这件事讲清楚。3. TCP 的“可靠”到底可靠在哪很多人以为TCP可靠是因为它“不会丢包”。这其实不准确。真实情况是底层网络依然可能丢包但TCP会通过一整套机制尽量把数据可靠地交付给对方应用层它主要靠这几件事序号给数据编号确认应答告诉对方“哪些我收到了”超时重传没确认就重新发按序重组乱了也要重新排好流量控制别把对方接收缓存撑爆拥塞控制别把网络本身堵死你可以把TCP想成一个非常认真负责的快递系统每个包裹都有编号对方签收后会回执没收到回执会补发到了顺序不对要重新整理对方仓库满了要慢一点路上堵车了也要降速这才是TCP真正“可靠”的含义。4. 一张图看懂 TCP 怎么确认和重传客户端 服务器 | ---- 数据包1(seq1) ------------- | | ----------- ACK2 --------------- | | ---- 数据包2(seq2) --X 丢失 | | ---- 数据包3(seq3) ------------- | | ----------- ACK2 --------------- | | ---- 重传数据包2(seq2) --------- | | ----------- ACK4 --------------- |这里最关键的感觉是seq表示“这是第几个数据段”ACK2可以理解成“我下一个想收到的是 2”如果 2 丢了就算 3 提前到了对方也不会假装没问题发送方发现迟迟没等到确认会把 2 重发所以TCP不是简单地“发出去就完了”而是一边发一边确认一边修正。5. TCP 为什么通常能保证按序因为它在接收端会根据序号重组数据。比如发送顺序是1 - 2 - 3 - 4但网络里实际到达顺序可能是1 - 3 - 2 - 4对于应用层来说TCP不会直接把乱掉的顺序原样丢给你而是尽量整理成正确顺序后再交付。这也是为什么很多基于TCP的应用天然更容易得到“完整、有序”的数据流。6. TCP 还有一个特别容易被忽略的点它是“字节流”这点非常关键尤其对网络编程初学者来说。TCP传输的是字节流不是“你发一次我就一定按一次收”。比如你连续发送两次send(Hello) send(World)接收端有可能看到的是HelloWorldHello和WorldHel、loWo、rld也就是说TCP只保证字节可靠、有序地到达不帮你保留消息边界。这就是为什么实际开发里基于TCP传协议时经常要自己设计固定长度协议分隔符协议长度字段 消息体很多人第一次碰到“粘包/拆包”本质上就是没真正理解TCP的字节流特性。UDP为什么它更轻、更快、更直接1. UDP 没有握手上来就能发如果说TCP的风格是“先确认再通信”那UDP就是不先建复杂关系直接把数据报发出去。它的感觉更像这样发送方 ---- 数据报 ---- 接收方没有三次握手没有确认应答没有超时重传这一整套内建流程。所以UDP的优势首先不是“带宽一定更大”而是机制更少头部更轻延迟负担更小应用层可以更自由地决定要不要补偿可靠性2. UDP 为什么常被说“不可靠”因为它默认不保证这些事数据一定送达数据一定只送一次数据一定按顺序到达对方一定来得及处理注意这里的“不可靠”不是说UDP不能用而是说这些可靠性工作传输层默认不替你做。如果你的业务真的需要也可以在应用层自己补自己编号自己确认自己重传自己做纠错所以UDP不是“低级协议”而是“把控制权更多留给应用层”。3. UDP 还有个非常舒服的特性它保留消息边界和TCP不同UDP是面向数据报的。你发两次sendto(Hello) sendto(World)接收端看到的也是两个独立的数据报不会像TCP一样天然发生“粘在一起”的字节流效果。所以从编程体验上说TCP更像一条稳定水流UDP更像一封一封独立的小信件这也是为什么一些追求“单条消息完整性”的轻量场景会觉得UDP非常顺手。一图看懂为什么直播、语音、游戏更偏爱 UDP你想象两个场景。场景一下载一个安装包你最关心的是一字不差顺序正确少一个字节都不行哪怕慢一点也不能错。这时候更像TCP。场景二打一局实时游戏或进行语音通话你最关心的是尽快收到最新状态偶尔丢一帧问题不大如果为了补旧数据而卡住当前画面反而体验更差比如你在游戏里每 50ms 上报一次位置位置1 - 位置2 - 位置3 - 位置4如果“位置2”丢了你未必想停下来苦等它重传。因为等它回来的时候玩家可能已经到“位置6”了。这时候更重要的往往是最新状态赶紧到而不是旧状态必须补齐。这就是UDP特别适合实时场景的原因。TCP 和 UDP 最容易搞混的 5 个点1. TCP 可靠不等于底层永远不会丢包真实网络里依然可能丢。只是TCP会尽量发现、修复、补发让应用层感受到更可靠的结果。2. UDP 不可靠不等于“它很差”如果场景核心是低延迟、实时性、轻量开销那UDP可能比TCP更合适。3. TCP 更慢不等于所有情况下吞吐量都差在网页、文件传输、长连接通信这类场景里TCP依然非常强而且是主力方案。所谓“慢”很多时候指的是建连要成本可靠机制要成本出现丢包时恢复逻辑更重不是说它天生就跑不快。4. 建立连接不等于真的拉了一根专线这里的连接是协议层状态不是物理层拉线。它的意思是双方记住彼此维护序号和窗口等状态后续按一套规则稳定通信5. UDP 也不是完全没有“高阶玩法”很多现代协议会跑在UDP之上再自己补上更灵活的可靠性和拥塞处理机制。一个非常经典的例子就是QUIC跑在UDP之上HTTP/3基于QUIC这也说明真正重要的不是死记“谁可靠谁不可靠”而是理解这些机制放在哪一层实现、为什么这么设计。那我到底什么时候该选 TCP什么时候该选 UDP看到下面这些需求优先想到TCP网页访问文件下载与上传登录、支付、订单数据库连接聊天消息记录必须完整一致任何“不能错、不能乱、不能少”的场景看到下面这些需求优先想到UDP实时语音视频会议直播推拉流中的实时数据传递在线游戏状态同步DNS 这类短小、快速的请求响应更关心时延而不是绝对完整性的场景如果你只想记一句判断口诀怕丢就先想 TCP怕等就认真考虑 UDP。当然真实系统里还会结合很多业务细节但这个判断足够帮你先建立第一层直觉。再送你一个最实用的记忆法把TCP和UDP分别记成两句话TCP我不仅要发我还要确认你收到了而且顺序不能乱UDP我先尽快发出去至于怎么补强由场景自己决定如果你把这两句话记牢再去看三次握手、重传、窗口、实时音视频你会发现所有知识点都能挂上去。最后总结别只背定义要看见它们背后的“通信哲学”很多人学不会TCP和UDP不是因为术语太多而是因为脑子里没有真正跑起来的画面。所以最后请你只记住下面这两个场景TCP像一个认真负责的快递系统登记、确认、补发、排序一个环节都不想丢UDP像一套追求实时反应的喊话系统先把消息尽快送出去少做额外动作然后把所有知识再挂回去为什么TCP稳因为它有连接、确认、重传、排序、流量控制、拥塞控制为什么UDP轻因为它少做很多内建保证开销更小时延负担更低为什么网页和文件常选TCP因为它们容不得错为什么直播、语音、游戏常选UDP因为它们更怕慢真正学会计算机网络不是会背出一句“TCP面向连接、UDP无连接”而是看到一个业务场景时你能立刻判断这个场景更怕“丢”还是更怕“等”当你会用这个角度看问题时TCP和UDP就不再是两个枯燥名词而会变成你理解网络世界最重要的一把钥匙。如果你愿意继续往下学下一步很适合接着看这些内容TCP的四次挥手到底在挥什么为什么会出现粘包和拆包滑动窗口到底在“滑”什么拥塞控制为什么会影响网络速度HTTP、WebSocket、QUIC和TCP/UDP到底是什么关系