TCP 如何提供可靠的有序传输？
- TCP: 面向连接的字节流协议，建立连接后双方都可以收发数据;
- 可靠性: 通过序号、确认和重传等机制恢复丢失数据，并向应用按序交付;
- 流控制: 发送方需要考虑接收方处理能力，避免持续压垮接收缓冲区;
- 代价: 建连、维护连接和丢包恢复增加状态与延迟，后续数据可能等待前面的缺口补齐;
- 保证边界: 网络永久中断时 TCP 会失败；字节已交付也不代表业务已经提交;
- 适用条件: 文件、网页、邮件等通常更重视完整性，而不是丢掉过时片段;
UDP 如何支持低开销的数据报传输？
- UDP: 无连接的数据报协议，应用提交一份数据报，协议不先建立 TCP 那样的连接;
- 协议边界: 不内建重传、按序交付或端到端流量控制，丢包和乱序由上层按需处理;
- 错误检测: UDP 有校验和机制，不能把“不提供可靠重传”理解成“完全没有错误检测”;
- 适用条件: 语音、实时互动或组播中，迟到数据可能不如直接丢弃，应用可选择恢复策略;
- 应用责任: 如果仍需可靠性或拥塞控制，应用协议必须另行实现，因此实际系统未必更简单;
怎样依据业务需求选择传输协议？
| 维度 | TCP | UDP |
|---|
| 数据单位 | 字节流，不保留消息边界 | 数据报，保留边界 |
| 连接 | 维护连接状态 | 协议本身无连接 |
| 交付 | 有序可靠或报告失败 | 可能丢失、重复、乱序 |
| 重传 | 协议内建 | 上层按需实现 |
| 广播与组播 | 不提供 | 可承载，取决于网络和 IP 版本 |
| 示例 | HTTP/1.1、HTTP/2、SMTP、FTP | 传统 DNS 查询、实时媒体等 |
- 性能判断: UDP 头部和连接开销较小，但“永远比 TCP 快”不成立，实际效果取决于丢包、恢复策略与负载;
- 设计顺序: 先决定能否丢失、是否需要顺序及延迟目标，再选择协议及上层补偿机制;
- 拆分边界: DNS 也可以使用 TCP，视频也可以通过可靠 HTTP 传输，业务名称不能唯一决定底层协议;