TCP 与 UDP：传输协议比较

TCP 通过确认、重传和流量控制，提供有序字节流。UDP 提供相互独立的数据报，内置机制较少。应根据应用对延迟、可靠性和兼容性的要求选择。

TCP 与 UDP 服务于不同的应用需求

TCP 面向连接：SYN、SYN-ACK 和 ACK 构成三次握手，随后建立的连接才承载数据。它会发现丢失、重传缺失的报文段，并按顺序提供字节。如果恢复失败，应用收到的是失败，而不是虚假的成功。SMTP、IMAP 等邮件协议以及文件传输，需要完整数据。

UDP 没有传输层握手，也不保证重传或有序到达。其报文头为八字节，而 TCP 基础报文头为二十字节。当应用能够容忍丢失或自行处理丢失时，可以用它承载对延迟敏感的流量。入门的流媒体示例说明的是这种取舍，并不意味着所有视频都必须使用 UDP。

序列号用于排列字节，确认和重传用于处理丢失。接收窗口保护接收端，拥塞控制则对疑似网络过载作出反应。应用看到的是连续数据流，而不是原始 IP 包的边界。

可靠性并不自动意味着低延迟。丢包后，重传和队头阻塞可能使应用等待。应用仍需要超时机制、断开连接处理，以及自己的消息分帧方式。

较低的协议开销适合短请求或时间敏感数据。普通 DNS 查询通常使用 UDP，但根据消息大小和操作，也会使用 TCP。如果需要可靠性，必须由应用或 UDP 上层协议提供。

现代协议让选择更加细致。QUIC 在用户空间基于 UDP 提供可靠、加密的数据流。延迟、丢失容忍度、顺序和网络兼容性，仍是应用层面的决策标准。带缓冲的流媒体可以受益于通过 TCP 或 QUIC 获得的可靠传输与防火墙兼容性。

一个流由协议、源和目标地址，以及源和目标端口描述。服务器通常监听已知端口，客户端则使用临时端口。防火墙和 NAT 利用这些属性跟踪状态。

检查握手、往返时间、重传、重置和接收窗口。没有收到 SYN-ACK，可能指向路径、过滤器或监听服务问题。传输连接已建立但结果不正确时，应继续检查 TLS 和应用协议。

UDP 总比 TCP 快吗？

UDP 内置机制较少，但应用性能还取决于网络、实现方式和所需可靠性。基于 UDP 的应用也可能自行实现类似机制。

为什么流媒体常使用 TCP 或 QUIC？

许多服务会缓冲内容，因此可受益于可靠传输和网络兼容性。QUIC 将可靠数据流与基于 UDP 的传输结合起来。