TCP 与 UDP 有什么区别，如何根据场景选择？

核心回答

TCP 提供面向连接、可靠有序的字节流；UDP 提供无连接的数据报传输，保留报文边界，但自身不保证送达、顺序和去重。 选择时主要看应用需要完整有序的数据，还是需要按时处理独立消息，以及上层已经采用什么协议。

• **TCP**通过序号、确认、重传等机制处理丢包和乱序，并提供流量控制与拥塞控制。适合文件传输、数据库连接、常见业务请求等需要可靠传输的场景；应用仍要定义消息边界、超时和业务响应。
• **UDP**没有 TCP 那样的连接建立与重传机制，报文可以独立发送。适合需要自行决定丢弃、补偿和重传策略的实时交互，以及使用 UDP 的查询或媒体协议；需要的可靠性、速率控制和安全能力由上层补足。

协议开销和等待策略会影响时延，但不能仅凭 TCP／UDP 名称判断实际性能。QUIC 就是在 UDP 之上实现可靠传输、连接管理和拥塞控制的协议，HTTP/3 使用 QUIC，不能因此被归为“不可靠 HTTP”。

字节流与数据报，对应用有什么影响？

TCP 交付的是连续字节，不保留每次应用写入的消息边界。比如先写入“ABC”，再写入“DEF”，接收方可能分两次读到“AB”和“CDEF”，也可能一次读到全部内容。接收方要通过长度字段、分隔符或既有协议格式识别一条完整消息，这就是常说的处理“粘包、拆包”。

UDP 则按数据报交付，一次发送的报文和下一次发送的报文有边界。但报文仍可能丢失、重复或乱序，太大的报文还会增加 IP 分片等问题的风险。因此，报文边界只解决消息怎样划分，不等于消息一定成功到达。

TCP 的可靠，保证到哪一层？

TCP 给字节编号，接收方确认已收到的数据，发送方根据超时和反馈重传；接收方重排、去重后向应用交付有序字节流。接收窗口限制对端接收缓冲区能够承受的量，拥塞控制则根据网络状况约束发送，二者关注的对象不同。

这些机制也有代价：连接需要维护状态；当一段字节丢失时，后续已到达的数据可能等待缺失部分恢复后才能按序交付。应用需要在完整性和等待时间之间作出选择。

传输可靠不代表业务成功。连接中断、持续网络故障时，TCP 也可能最终报错；即使数据已到对端，发送方也不能仅凭传输层确认认定对方完成了落库或扣款。业务仍需要响应、超时与必要的幂等处理，避免重试重复执行。

怎样按场景选择？

需要完整有序地接收内容，且没有特殊传输要求时，通常优先使用基于 TCP 的成熟协议与库。例如数据库访问、文件传输和已有的业务 RPC，能复用其可靠流传输能力，减少自行实现的工作。

消息有很强时效、过期后价值很低时，可以考虑基于 UDP 的成熟实时协议。例如互动音视频或游戏状态同步，应用可能宁愿跳过已经过时的内容，继续处理新消息。但仍要控制发送速率，处理抖动、乱序和必要的补偿；UDP 自身不提供拥塞控制，并不意味着应用可以不考虑网络容量。

需要可靠传输，又希望使用 UDP 上层的新传输能力时，可以选择 QUIC 等已有协议。QUIC 为应用提供有序的流，并实现丢包恢复与流量、拥塞控制。它是在 UDP 之上补足这些能力，工程上还要考虑客户端支持和网络可达性，而不是只把 Socket 类型改成 UDP。

常见追问

UDP 能实现可靠传输吗？ 能在上层实现序号、确认、重传、去重等机制，但还需处理拥塞控制、超时和资源限制。QUIC 是成熟例子；可靠性来自上层协议，并非 UDP 自身增加了承诺。

使用 TCP 就不需要应用层校验和重试了吗？ 仍需按业务设计。TCP 负责字节传输，不能确认业务处理结果，也不提供加密认证；敏感通信通常还要结合 TLS 等安全协议，业务重试则要考虑幂等。

音视频或直播一定选 UDP 吗？ 要看低时延互动还是允许缓冲播放，以及实际采用的媒体协议。不能仅凭业务名称决定传输协议，也不能把“UDP 无重传”直接当成完整的低时延方案。

参考资料