网络基础回顾：TCP与UDP协议的区别，为什么直播常用UDP？

做流媒体这行，天天跟网络打交道。你推流卡顿、花屏、延迟高，根子往往不在编码器，而在传输层。今天咱们把TCP和UDP这两个老朋友拉出来，好好盘一盘。

我个人习惯，遇到网络问题先问一句：这路流走的是TCP还是UDP？答案能帮你快速定位一半的故障。

TCP：可靠但“笨重”的传输方式

TCP全称传输控制协议。它的核心设计目标就四个字：绝对可靠。

怎么保证可靠？它搞了一套“三次握手”建立连接，数据发出去后，接收方必须回ACK确认。如果没收到ACK，发送方就重传。数据包到达的顺序乱了，TCP还能帮你重新排好。

听起来很完美对吧？但代价也很大。

我记得有一次帮客户排查推流卡顿，他们用的RTMP over TCP。网络抖动了一下，丢了一个关键帧的包，结果整个画面卡了3秒才恢复。为什么？因为后续的包都在排队等那个丢掉的包重传过来。这就是典型的队头阻塞。

UDP：简单但“粗暴”的传输方式

UDP全称用户数据报协议。它跟TCP完全是两个极端。

UDP没有握手，没有ACK，没有重传，没有顺序保证。发出去就完了，收不收得到，收的顺序对不对，它不管。

你可能会问：这也能用？

能。而且对于直播来说，这正是它最迷人的地方。

特性	TCP	UDP
连接建立	三次握手	无连接
可靠性	可靠（重传+确认）	不可靠（尽力而为）
顺序保证	保证	不保证
队头阻塞	有	无
拥塞控制	有（慢启动、拥塞避免）	无（应用层自行控制）
头部开销	20字节	8字节
适用场景	文件传输、网页浏览	直播、实时通信、游戏

为什么直播常用UDP？

说白了，直播对延迟敏感，对丢包相对宽容。

你想想看，一个视频帧丢了，如果走TCP，它要等重传。等重传到了，这帧本该播放的时间点早就过了。结果就是画面卡住，然后突然跳帧。用户体验极差。

走UDP呢？丢了就丢了。解码器可以用前一帧的数据做错误掩盖，画面可能闪一下，但不会卡死。用户感知到的，是“稍微花了点”，而不是“卡住了”。

我做过一个对比测试：同样的网络环境，5%的丢包率。TCP推流延迟飙升到8秒，画面频繁卡顿。UDP推流配合前向纠错（FEC），延迟控制在500ms以内，画面偶尔有马赛克，但整体流畅。

结果很明显——直播场景下，流畅比完美更重要。

TCP与UDP在直播中的典型应用

• RTMP：基于TCP，延迟高（3-10秒），适合传统直播。
• WebRTC：基于UDP，延迟低（200-500ms），适合互动直播。
• SRT：基于UDP，加入了ARQ和FEC，延迟可控（1-3秒），适合公网传输。
• QUIC：基于UDP，但实现了类似TCP的可靠性，Google力推的新一代传输协议。

核心知识图谱

下面这张图帮你理清TCP和UDP在直播场景下的选择逻辑。