嘿，作为刚入门网络领域的同学，你问的这个问题刚好戳中了实时系统与传输协议之间的核心矛盾点，我结合实际场景给你拆解清楚～

TCP的核心目标是可靠传输，但这个目标恰恰和实时系统最看重的低延迟、即时性背道而驰，具体原因有这几点：

• 连接建立的额外开销：TCP是面向连接的协议，每次通信前必须完成三次握手建立连接，结束还要四次挥手断开。对于实时场景比如实时语音通话、在线竞技游戏来说，等连接建立完成的那几百毫秒，可能已经错过了关键的交互时机，而且频繁的连接断开也会浪费资源。
• 重传与顺序交付带来的延迟累积：TCP会保证数据包按顺序交付，如果中间某个包丢了，它会触发重传，并且后面的所有包都要等这个丢失的包重传成功后，才会交给应用层。这就会导致“延迟雪崩”——比如视频通话中，一个帧丢了，后面的帧都得等着，用户就会看到画面卡住好几秒，这在实时场景里完全无法接受。
• 内置的拥塞/流量控制限制：TCP为了避免网络拥塞，会自动调整发送速率（比如慢启动、滑动窗口机制）。当网络出现波动时，TCP会立刻降速，优先保证传输可靠，而实时系统需要的是稳定的低延迟，哪怕丢几个包，也比让用户等半秒才收到数据强。比如实时游戏里，玩家的操作指令晚到几百毫秒，可能就直接输掉了。
• 更大的头部开销：TCP头部最小是20字节，而UDP只有8字节。在实时系统中，我们通常会发送大量小数据包（比如游戏里的每帧操作、语音的采样片段），TCP的额外头部会占用更多带宽，降低传输效率。

UDP的设计目标就是快速、轻量，刚好匹配实时系统的需求，核心特性包括：

• 无连接，启动即传输：UDP不需要提前建立连接，应用层想发数据直接封装成UDP包就可以发送，省去了握手的时间成本。比如打开视频通话的瞬间，就能立刻开始传输音视频数据，不用等连接建立。
• 无重传、无顺序保证：UDP不负责重传丢失的数据包，也不保证数据包的交付顺序。这听起来像是缺点，但在实时场景里却是优点——丢了一个语音采样帧，直接跳过就行，用户最多听到一瞬间的卡顿，不会因为等重传而导致整个语音流延迟。应用层还可以自己实现轻量的容错机制（比如视频的帧内预测、语音的冗余编码），比TCP的重传更灵活。
• 轻量级头部：8字节的头部极大减少了额外开销，在小数据包高频传输的场景下，能节省更多带宽，让更多的有效数据能快速传输。
• 拥塞控制完全自主：UDP本身没有内置的拥塞控制策略，开发者可以根据实时场景的需求，在应用层实现定制化的控制逻辑。比如实时游戏可以根据网络延迟动态调整数据包的发送频率，而不是像TCP那样一遇到拥塞就强制降速。

举个实际的例子：我们常用的视频通话工具（比如Zoom、微信通话）底层都是基于UDP的WebRTC协议，而文件下载、网页加载这些需要可靠传输的场景，才会用TCP。

内容的提问来源于stack exchange，提问作者InternetUser