TCP 和 UDP 的区别：可靠传输和实时传输怎么选

学完 HTTP、HTTPS，很自然会往下一层看。HTTP 请求报文最终要交给传输层，常见选择就是 TCP 或 UDP。文中说，TCP 和 UDP 是两种常见的传输层协议，用于在计算机网络中传输数据。

它们不是谁高级谁低级的关系，而是取舍不同。TCP 把可靠性、顺序、重传、流量控制这些事情放进协议里，使用者用起来更稳。UDP 则更轻，发送前不需要建连接，也不保证一定送达，适合更看重实时性的场景。

所以不要只背“TCP 可靠，UDP 不可靠”。更好的问题是：这次业务更怕数据错、乱、丢，还是更怕延迟高、等待久、连接开销大？答案不同，协议选择就不同。

TCP 是面向连接的协议。通信前，发送方和接收方要先建立连接，常说的三次握手就是这个过程。通信结束后，还要关闭连接，也就是四次挥手。文中把这点放在 TCP 定义里：TCP 在通信之前需要建立连接，通信完成后关闭连接。

UDP 是无连接的。它不需要提前和对方建立连接，想发数据就直接把数据报发出去。这样做少了建连和关连的步骤，开销更小，也更快。

这个区别会影响体验。一次网页浏览、文件下载、接口调用，通常更适合 TCP，因为你希望数据完整到达。实时游戏、直播、音视频通话可能更适合 UDP，因为晚到的数据有时已经没价值了。

TCP 提供可靠传输。文中提到，它通过序列号和确认机制保证数据包的有序性和完整性。如果数据包丢失或损坏，TCP 会重新发送，直到接收方正确接收为止。

这里有几个关键词。序列号让接收方知道数据原本的顺序；ACK 确认告诉发送方哪些数据已经到了；超时重传用来处理丢包；接收端按序重组，避免应用层拿到乱序数据。

UDP 不做这些保证。它是尽力交付，发出去之后不关心是否到达，也不提供确认和重传机制。数据可能丢，可能乱序，也可能重复。听起来粗糙，但正是因为它少做事，才有了轻和快。

TCP 不只关心数据有没有到，还会控制发送速度。文中说，TCP 使用流量控制和拥塞控制算法，确保发送速率不超过接收方处理能力，并防止网络拥塞。

流量控制更像是看接收方吃不吃得下。接收方缓冲区不够，发送方就不能一直猛发。拥塞控制看的是网络本身的拥堵程度，网络状态不好时，TCP 会降低发送速度，避免把拥塞继续放大。

UDP 默认没有这些机制。它不会因为接收方处理慢或网络拥堵，就在传输层主动调速。应用如果需要类似能力，就要自己设计限速、丢包处理、重传或降级策略。

文中列了头部大小：TCP 头部通常是 20 字节，如果使用选项字段，可能更大。TCP 头里有源端口、目标端口、序列号、确认号、窗口大小、校验和等字段，这些字段正是可靠传输需要的基础。

UDP 头部固定 8 字节，只包含源端口、目标端口、长度和校验和。字段少，开销就低，处理也简单。

这不是单纯的优缺点。TCP 的头部更大，是因为它承担了更多协议责任；UDP 的头部更小，是因为它把很多事情留给应用层。选协议时，不要只看头部大小，要看业务需不需要那些能力。

TCP 基于字节流，没有天然消息边界。发送方写入几次，接收方不一定按同样次数读到。上一篇前面 同时讲过 TCP 粘包和拆包，本质上就和字节流有关。TCP 保证顺序和可靠，但不保证应用层的一条消息刚好对应一次读取。

UDP 是基于数据报的，有消息边界。应用发出一个 UDP 包，接收方通常按一个数据报接收。它继承了 IP 层的一些特点，可能乱序、可能丢包，但边界感更明确。

这会影响协议设计。用 TCP 自定义应用协议时，通常要设计长度字段、分隔符或固定格式，告诉接收方一条完整消息从哪里开始、到哪里结束。UDP 省掉了这类边界处理，但要面对丢包和乱序。

文中还比较了分片方式。TCP 数据大于 MSS 时，会在 TCP 层进行分片传输，到达目的地后同样在传输层合并。如果某个分片丢了，只需要重传丢失的分片。

UDP 数据大于 MTU 时，会在 IP 层分片，并在 IP 层重组。如果某个 IP 分片丢失，整个 UDP 数据报就可能不可用。对于大 UDP 包，这会放大丢包影响。

所以实际使用 UDP 时，常会尽量控制单个数据报大小，避免 IP 分片。实时系统宁可把数据拆小、允许部分丢失，也不希望一个大包因为某个分片丢失而整体失败。

TCP 适合可靠性要求高的场景。文中给的例子包括文件传输、电子邮件、网页浏览。数据库连接、API 请求、后台管理系统，也通常更适合 TCP，因为这些场景不能随便丢数据、乱序或重复。

UDP 适合实时性要求高、能接受少量丢包的场景。文中提到实时游戏、流媒体。音视频通话也是典型例子：一帧音频晚到太久，哪怕它最终到了，也没有播放价值。相比等待重传，直接跳过可能更自然。

所以“UDP 更快”要加限定。它少了连接和确认流程，延迟可以更低，但不代表业务体验一定更好。如果业务自己又补了复杂可靠性机制，UDP 的开发成本也会上来。

资料 把 TCP 可靠性归纳为校验和、序列号、确认应答、超时重传、连接管理、流量控制和拥塞控制。可以把它理解成一组互相配合的机制，而不是一个神奇开关。

序列号和 ACK 让发送方知道数据到了哪里；超时重传处理没等到确认的情况；连接管理确保双方在传输前后有明确状态；滑动窗口控制发送方不要超过接收方处理能力；拥塞控制让发送速率适应网络状态。

这些能力让 TCP 更稳，也让它更重。对使用者来说，好处是很多可靠性细节不用自己写；代价是协议层会做等待、重传和调速，实时性可能不如 UDP 灵活。

资料 最后还提到一个问题：怎么用 UDP 实现可靠传输。思路是把本来由 TCP 做的一部分事情，转移到应用层。比如在 UDP 数据报里自定义头部，加入确认序列号、时间戳等字段。

发送方可以根据时间戳计算 RTT，再估算 RTO，也就是重传超时时间。收到 ACK 后再继续发送，或者在超时后重传未确认的数据。接收方则根据序列号排序，丢弃重复数据报。

这类做法适合一些特殊场景，比如弱网、实时通信、游戏同步、音视频传输。它不是简单地“UDP 变 TCP”，而是按业务需要补一部分可靠性：该重传的重传，该丢的丢，该降级的降级。

可以这样答：TCP 是面向连接、可靠、有序、基于字节流的传输层协议，传输前要建立连接，依靠序列号、ACK、重传、流量控制和拥塞控制保证可靠性，适合网页、文件传输、邮件和普通接口请求。UDP 是无连接、尽力交付、基于数据报的协议，不保证可靠和有序，头部更小，适合实时游戏、音视频和流媒体等更关注实时性的场景。

然后补充几个容易加分的点：TCP 没有天然消息边界，所以应用层要处理粘包拆包；UDP 有数据报边界，但可能丢包乱序；TCP 头部通常 20 字节起，UDP 头部固定 8 字节；如果 UDP 想要可靠，需要在应用层补 ACK、序列号、重传、排序等机制。

这样回答不会只停在“一个可靠一个不可靠”。你能说清楚可靠性从哪里来，也能说清楚为什么有些场景宁愿不用内置可靠性的 TCP。