TCP 和 UDP 有什么区别？实时通信为什么不总是选择 TCP？

🧑‍💻 面试官：TCP 可靠，UDP 不可靠，所以业务都该用 TCP 吗？

🙋‍♂️ 我：要保证数据完整，当然优先 TCP。

🧑‍💻 面试官：视频里一秒前的画面丢了，现在补回来还有价值吗？

🙋‍♂️ 我：实时场景可能宁可丢，也不想等。

🧑‍💻 面试官：那支付接口用 TCP，收到传输确认就等于支付成功了？

先问应用需要什么：完整有序，还是及时到达。传输层可靠交付，也不能替代业务完成确认。

面试速答（60 秒版）

TCP 提供面向连接、可靠有序的字节流。应用要自己定义消息边界，不能假设一次 write 就对应对方一次 read。

UDP 发送数据报，保留数据报边界，但不提供 TCP 那样的顺序、重传与连接级可靠交付保证。应用可以在上面实现自己需要的机制，例如 QUIC 的可靠流。

普通接口和文件传输通常需要完整性，TCP 是常见基础。实时音视频则要按数据价值处理迟到和丢失，可能选择 UDP 上的专用协议，不能把所有数据都等旧包重传。

但 UDP 并非永远更快，TCP 确认也不是业务成功。选型还要考虑拥塞控制、安全、网络兼容性、开发复杂度和应用级确认。

TCP 提供有序字节流，UDP 保留数据报边界但不保证交付，二者都不代替业务确认

知识点详解：字节流与数据报，怎样改变应用的处理方式

TCP 交给应用的是连续字节，不是一条条业务消息

假设客户端连续发送两条 JSON。TCP 接收端可能一次读到两条的一部分，也可能把一条分几次交给程序，这取决于缓冲和读取行为。

所以应用需要长度前缀、分隔符或成熟协议来识别消息边界。HTTP 等协议已经定义相应规则；自行写 TCP 服务时，就不能把每次 read 当成完整消息。

常说的粘包、拆包，本质上是应用误把字节流当成消息列表，不是 TCP 随机破坏了数据。

UDP 的一份数据报有边界，但交付不被保证

接收时能区分数据报，却可能丢失、重复或乱序。应用还要考虑报文大小、路径 MTU 和分片风险，不能把任意大对象塞进一包就期待成功。

UDP 本身不负责完整重传、流量控制和拥塞控制的整套 TCP 能力。有需要就由上层协议设计，但做这些不是加一行“失败再发”那么简单。

QUIC 就说明，上层可以在 UDP 上提供可靠有序流，不能只看底层名字判断最终应用能力。

实时任务里的旧数据，可能已经没有价值

例如语音的一小段迟到很久，硬等补齐可能让后面每段都跟着延迟。接收端可以利用序号、抖动缓冲和适当丢弃处理，具体由音视频协议负责。

不过关键控制消息、会话协商或文件片段也可能要求可靠。实时应用不是“全部数据一律丢了就算”。

要先定义允许丢失和允许迟到的范围，再决定重传、纠错或丢弃。否则所谓低延迟只是把错误藏起来。

传输到达，不等于业务完成

假设支付请求已到服务端 TCP 缓冲，连接随后断开。客户端没拿到业务响应，无法仅凭传输 ACK 判断支付逻辑成功或失败。

需要业务响应、请求 ID、幂等和状态查询来处理这种不确定性。TCP 保证其范围内的字节传输，不会自动撤销重复支付或跨服务副作用。

UDP 上也要具备适当拥塞与安全设计。不能为了追求少握手，把网络公平性、认证和故障处理都省略。

本题机制参考：TCP、UDP、QUIC、UDP 应用指导。

面试官继续追问

TCP 可靠就绝不会失败吗？

不是。连接可以超时或断开，应用会得到错误；可靠性不是保证网络永远可用，也不是永久保存业务数据。

UDP 没有连接，能调用 connect 吗？

一些 socket API 允许 UDP connect 来设置默认对端及相关行为，但不会因此出现 TCP 的握手与可靠流语义。

如何选择实时应用的传输？

看延迟预算、数据过期价值、丢失容忍和上层协议，再评估网络路径与实现，不只比较包头大小。

面试速记卡

TCP：可靠有序字节流，消息边界由应用协议规定。

UDP：数据报有边界，交付和顺序不被它保证。

实时：过期数据可能不值得等，但关键消息另定规则。

上层：QUIC 可在 UDP 上实现可靠流。

业务：传输 ACK 不等于操作成功或幂等。