你打视频通话流畅无延迟，下载文件却得等进度条走完。背后是两套完全不同的"邮递哲学"——TCP和UDP。本文用通俗的比喻，带你看懂这两个协议的本质区别，以及在真实架构设计中如何做出正确选择。

为什么你打视频电话不需要缓冲，而传文件必须等进度条走完？

你打视频通话，画面流畅、音画同步，延迟200毫秒以内——这叫"实时通信"。

你下载一个文件，打开进度条，安心等着百分比一点点爬升——这叫"可靠传输"。

背后是两套完全不同的"邮递哲学"，TCP和UDP。这两个协议的区别，是系统架构设计师考试里的经典送分题，也是无数架构师在设计系统时必须做的选择题。

TCP：那个必须确认收到才放心的"较真"快递

TCP的全称是Transmission Control Protocol，翻译过来是"传输控制协议"。

它的核心逻辑是：发出去的东西，对方必须确认收到了，我才认为这笔交易完成了。

怎么确认？靠"三次握手"。建立连接时，客户端和服务器要来回确认三次，才能正式开始传输数据。传完之后，还要再"四次挥手"断开连接。

这听起来很繁琐，但背后有它的道理。

想象你寄一封重要的合同文件。TCP的做法是：快递员必须让你签字确认签收，而且必须把文件交到收件人手里，不能扔在门口就走。如果中途快递盒破了，还要重新补发一份。

这就是TCP的特性：

HTTP、FTP、SMTP（邮件协议）都是TCP的应用。所以你传文件时，进度条是准确的——因为底层知道你每一比特数据有没有传到位。

UDP的全称是User Datagram Protocol，翻译过来是"用户数据报协议"。

UDP的做法是：我把数据包扔出去，管你收到没收到，我只管发。

没有握手，没有确认，没有重传。发送方完全不知道接收方有没有在线、有没有收到、数据有没有损坏。

再想象寄一封信。UDP的做法是：把信扔进邮筒就不管了。对方有没有收到、邮件有没有被雨水泡烂、是不是被误投到隔壁楼——发送方一无所知，也不在乎。

这就是UDP的特性：

DNS查询、视频直播、在线游戏、VoIP（网络电话）都用UDP。

你打视频通话时，画面偶尔会花屏、声音偶尔会断断续续——但整体是流畅的。这是因为UDP容忍少量丢包，用"宁可播过去也不卡着"的方式保证实时性。如果等TCP那种确认机制，等确认完再播放，延迟就会高到你根本无法忍受。

很多架构师会有一个误解：既然UDP这么快，是不是所有场景都应该用UDP？

不是。选协议本质上是选业务需求。

场景	用什么	为什么
文件传输、邮件