TCP和UDP：可靠传输 vs 无连接快速传输 – wiki基地

TCP 与 UDP：网络世界的双生子——可靠传输 vs. 无连接快速传输

在构建互联网这座信息高速公路的地基时，数据如何安全、高效地从一端传输到另一端是一个核心问题。在网络协议栈的传输层，有两个协议承担着这一重要职责：传输控制协议（TCP, Transmission Control Protocol）和用户数据报协议（UDP, User Datagram Protocol）。它们就像是网络世界的双生子，各自拥有截然不同的性格和适用场景。TCP 追求的是数据的可靠性与顺序性，不惜为此付出额外的开销和时间；而 UDP 则崇尚简单与速度，牺牲了可靠性以换取效率。理解 TCP 和 UDP 的本质区别，是理解现代网络应用如何工作的基础。

本文将深入探讨 TCP 和 UDP 的工作原理、特性、优缺点及其典型应用场景，详细解析为何一个被称为“可靠的信使”，而另一个被比作“高效的邮递员”。

一、传输层在网络协议栈中的位置与作用

在深入了解 TCP 和 UDP 之前，有必要先回顾一下网络协议栈。国际标准化组织（ISO）提出的开放系统互连（OSI）模型将网络通信过程划分为七个层次，而 TCP/IP 协议族（互联网事实上的标准）通常简化为四层或五层。无论哪种模型，传输层（Transport Layer）都位于应用层之下，网络层之上。

传输层的主要职责是为应用程序提供端到端（End-to-End）的通信服务。这意味着它负责将来自应用层的数据分割成适当大小的段（Segment，TCP中称为报文段，UDP中称为用户数据报），并将这些段交给网络层，同时接收网络层的数据报（Datagram），并将其中的数据交付给相应的应用进程。

传输层提供了两种基本的服务模型：

面向连接的可靠服务： 提供全双工、可靠的数据流传输。数据按发送顺序交付，丢失的数据会被重传，重复的数据会被丢弃。TCP 就属于这一类。
无连接的不可靠服务： 尽最大努力交付，但不保证数据的可靠到达、顺序或不重复。UDP 就属于这一类。

此外，传输层还通过端口号（Port Number）来区分同一主机上不同应用进程的数据，实现进程到进程（Process-to-Process）的通信，而非仅仅是主机到主机（Host-to-Host）的通信（这是网络层 IP 协议的职责）。

二、TCP：可靠传输的基石 (Transmission Control Protocol)

TCP 是一种面向连接的、可靠的、基于字节流的传输层协议。它的设计目标是确保数据能够准确无误地、按顺序地从发送端传输到接收端。为了实现这一目标，TCP 付出了相当大的复杂性和开销。

2.1 TCP 的核心特性与工作原理

TCP 的“可靠性”和“面向连接”是其最突出的特点。这些特性是通过一系列精妙的机制来实现的：

面向连接 (Connection-Oriented)：
- TCP 在数据传输之前必须建立一条逻辑连接。这个过程通常通过著名的三次握手（Three-Way Handshake）完成。
- 三次握手过程：
  - 第一次握手 (SYN)： 客户端发送一个 SYN（同步）报文段到服务器，请求建立连接。报文段中包含一个初始序列号 (Initial Sequence Number, ISN)。
  - 第二次握手 (SYN-ACK)： 服务器收到 SYN 后，如果同意建立连接，会发送一个 SYN-ACK（同步-确认）报文段作为响应。报文段中包含服务器自己的 ISN，同时确认客户端的 SYN（确认号 ACK = 客户端 ISN + 1）。
  - 第三次握手 (ACK)： 客户端收到 SYN-ACK 后，发送一个 ACK（确认）报文段进行确认（确认号 ACK = 服务器 ISN + 1）。连接至此正式建立，客户端和服务器都可以开始发送数据。
- 建立连接的目的是为了初始化双方的状态信息（如序列号、窗口大小等），为后续的可靠传输做好准备。
- 数据传输完成后，连接还需要通过四次挥手（Four-Way Handshake）来终止，确保双方都已完成数据的发送和接收。
可靠传输 (Reliable Transfer)：
- TCP 确保发送的数据能够无差错、不丢失、不重复地按序到达。这依赖于以下机制：
  - 序列号 (Sequence Numbers)： TCP 为每个发送的字节都赋予一个序列号。报文段头部包含其第一个字节的序列号。这使得接收端能够按正确顺序重组乱序到达的报文段，并检测丢失或重复的报文段。
  - 确认应答 (Acknowledgments, ACK)： 接收端在成功接收到数据后，会发送确认报文段给发送端，告知已收到的数据的下一个期望收到的字节的序列号（即累计确认）。
  - 超时重传 (Timeout and Retransmission)： 发送端为每个发送的报文段设置一个定时器。如果在定时器超时之前没有收到该报文段的确认，发送端就认为数据丢失，并会重传该报文段。重传时间间隔（RTO, Retransmission Timeout）是动态调整的，以适应不同的网络条件。
  - 快速重传 (Fast Retransmit)： 当接收端收到一个失序的报文段时，它会立即发送一个重复的 ACK（Duplicate ACK），包含最后一个按序接收到的数据的序列号。如果发送端收到三个或更多重复的 ACK，它就会认为相应的报文段已经丢失，不等定时器超时就立即重传该报文段。这可以有效减少等待超时导致的时间延迟。
  - 校验和 (Checksum)： TCP 报文段包含一个校验和字段，用于检测报文头和数据在传输过程中是否发生了错误。如果校验和不匹配，接收端会丢弃该报文段，并且不会发送确认，从而触发发送端的重传。
流量控制 (Flow Control)：
- TCP 通过滑动窗口机制 (Sliding Window)实现流量控制。接收端告知发送端其当前可以接收多少字节的数据（即接收窗口 rwnd）。发送端根据接收窗口的大小来限制自己发送数据的速率，确保不会因为发送过快而压垮接收端的缓冲区，导致数据丢失。接收窗口的大小是动态变化的。
拥塞控制 (Congestion Control)：
- 与流量控制关注的是点对点（发送端到接收端）的能力匹配不同，拥塞控制关注的是整个网络的负载状况。如果网络拥塞，发送方应该降低发送速率，以避免网络性能进一步恶化甚至崩溃。
- TCP 采用多种算法来实现拥塞控制，典型的包括：
  - 慢启动 (Slow Start)： 连接建立初期，发送窗口（拥塞窗口 cwnd）从一个小值开始，每收到一个 ACK，窗口大小呈指数级增长，快速探测网络的可用带宽。
  - 拥塞避免 (Congestion Avoidance)： 当拥塞窗口达到慢启动阈值 (ssthresh) 后，进入拥塞避免阶段。此时窗口大小线性增长，每经过一个往返时间 (RTT)，窗口增加一个报文段大小。
  - 快速重传与快速恢复 (Fast Retransmit and Fast Recovery)： 前面提到的快速重传触发后，如果采用快速恢复算法，发送端不是回到慢启动阶段，而是将慢启动阈值减半，并将拥塞窗口设置为新的慢启动阈值，然后进行线性增长，从而更快地恢复传输速率。
全双工通信 (Full-Duplex Communication)：
- TCP 连接一旦建立，数据可以在两个方向上同时传输。
基于字节流 (Byte Stream-Oriented)：
- TCP 不关心应用层一次交付多少数据，它将应用层数据视为一个无结构的字节流。发送端将字节流分割成合适的报文段进行发送，接收端将收到的报文段数据按序重新组装成字节流交付给应用层。应用层看到的是一个连续的字节序列，而不关心底层是如何分段和传输的。

2.2 TCP 报文段头部格式 (TCP Segment Header)

TCP 报文段头部包含了实现上述机制所需的控制信息，其长度通常为 20 字节（不含可选字段和填充）：

源端口号 (Source Port): 16 位，发送方应用进程的端口号。
目的端口号 (Destination Port): 16 位，接收方应用进程的端口号。
序列号 (Sequence Number): 32 位，当前报文段第一个数据字节在整个字节流中的序列号。
确认号 (Acknowledgment Number): 32 位，期望收到的对方下一个数据字节的序列号。用于确认对方已收到的数据。
数据偏移/头部长度 (Data Offset / Header Length): 4 位，表示 TCP 头部长度，以 32 位字为单位。用于指示数据部分的起始位置。
保留 (Reserved): 6 位，保留字段，必须置为 0。
标志位 (Flags): 6 位，用于控制连接状态和数据传输：
- URG (Urgent): 紧急指针字段是否有效。
- ACK (Acknowledgement): 确认号字段是否有效。
- PSH (Push): 立即将数据推送给应用层。
- RST (Reset): 重置连接。
- SYN (Synchronize): 同步序列号，用于建立连接。
- FIN (Finish): 发送方已完成数据发送，用于终止连接。
窗口大小 (Window Size): 16 位，接收窗口大小，告诉发送方还可以接收多少字节的数据。用于流量控制。
校验和 (Checksum): 16 位，用于检测头部和数据的错误。
紧急指针 (Urgent Pointer): 16 位，当 URG 标志位有效时，指向紧急数据在报文段中的最后一个字节。
选项 (Options): 长度可变，如最大报文段大小 (MSS)、窗口扩大因子、时间戳等。
填充 (Padding): 用于确保头部长度是 32 位字的整数倍。

2.3 TCP 的优缺点与典型应用

优点：

可靠性高： 保证数据不丢失、不重复、按序到达。
流量控制： 防止发送方发送速度过快，导致接收方缓冲区溢出。
拥塞控制： 根据网络状况调整发送速率，避免网络拥塞。
面向连接： 有状态的管理，适合需要稳定会话的应用。

缺点：

延迟高： 连接建立（三次握手）、连接终止（四次挥手）、确认、重传等机制增加了通信的延迟。
开销大： 头部信息比 UDP 大，且需要维护连接状态（缓冲区、序列号、计时器等），占用较多系统资源。
效率相对较低： 为了保证可靠性，可能会进行不必要的重传（例如，网络只是短暂拥塞导致少量丢包），影响实时性。
不适合广播或多播： TCP 是点对点通信，不原生支持一对多或多对多的数据传输。

典型应用：

任何需要高度可靠性、对数据顺序要求严格的应用：

Web 浏览 (HTTP/HTTPS): 确保网页内容完整准确地加载。
文件传输 (FTP): 确保文件内容完整无损。
电子邮件 (SMTP/POP3/IMAP): 确保邮件内容不丢失、不错乱。
安全外壳 (SSH): 确保远程登录的命令和数据安全可靠。
数据库连接: 确保数据事务的完整性。

三、UDP：无连接的疾速信使 (User Datagram Protocol)

UDP 是一种无连接的、不可靠的传输层协议。与 TCP 的重量级和严谨不同，UDP 更加轻量级和灵活。它不做任何可靠性保证，仅仅是将应用层数据加上一个简单的头部，然后发送出去。它不关心数据是否到达、是否按序、是否重复。

3.1 UDP 的核心特性与工作原理

UDP 的核心哲学是“尽力而为”，将可靠性等问题留给应用层去处理（如果需要的话）。

无连接 (Connectionless)：
- UDP 在数据传输之前不需要建立连接。发送方直接将数据封装成用户数据报发送出去，接收方也直接接收。
- 没有连接建立和终止的开销，通信速度快。
- 每个 UDP 数据报都是一个独立的单元，相互之间没有关联。
不可靠传输 (Unreliable Transfer)：
- UDP 不提供任何可靠性保证：
  - 不保证数据到达： 发送后不关心接收方是否收到。
  - 不保证按序到达： 数据报在网络中可能经过不同的路径，先发送的数据报可能晚于后发送的数据报到达。
  - 不保证不重复： 数据报可能被网络设备重复发送（尽管不常见）。
  - 不提供差错纠正： 虽然有校验和，但通常只用于检测错误，检测到错误的数据报会被直接丢弃，而不是请求重传。
- 可靠性、顺序性等问题需要应用层协议自行解决。
无流量控制和拥塞控制：
- UDP 没有流量控制机制，发送方可以以任何速率发送数据，可能导致接收方缓冲区溢出而丢弃数据。
- UDP 没有拥塞控制机制，发送方不会根据网络拥塞状况调整发送速率。如果大量 UDP 数据涌入网络，可能会加剧拥塞，甚至影响其他使用 TCP 的应用的性能。应用层需要自己负责控制发送速率，以避免压垮网络或接收方。
报文导向 (Message/Datagram-Oriented)：
- UDP 将应用层交付的每一块数据视为一个独立的消息（用户数据报），一次发送一个。接收端接收到的也是一个个独立的数据报，而不是一个连续的字节流。应用层发送和接收的数据块边界是保留的。
支持广播和多播：
- UDP 天生支持向多个目的地发送相同的数据（广播和多播）。

3.2 UDP 用户数据报头部格式 (UDP Header)

UDP 头部非常简单，固定为 8 字节：

源端口号 (Source Port): 16 位，发送方应用进程的端口号（可选，如果不用，则为 0）。
目的端口号 (Destination Port): 16 位，接收方应用进程的端口号。
长度 (Length): 16 位，整个 UDP 用户数据报的长度（头部 + 数据），最小为 8 字节（只有头部）。
校验和 (Checksum): 16 位，用于检测头部和数据的错误（可选，IPv4 中是可选的，置为 0 表示不计算；IPv6 中是强制的）。

可以看到，UDP 头部远比 TCP 头部简洁，这是其低开销和高速传输的根源之一。

3.3 UDP 的优缺点与典型应用

优点：

速度快： 没有连接建立/终止、确认、重传等开销，延迟极低。
开销小： 头部信息简单，不需要维护连接状态，对系统资源要求低。
灵活： 可以用于广播和多播。
报文导向： 保留应用层数据的边界。

缺点：

不可靠： 不保证数据到达、顺序或不重复。
无流量控制： 发送方可能发送过快导致接收方溢出。
无拥塞控制： 发送方可能加剧网络拥塞。

典型应用：

任何对实时性要求高、可以容忍少量数据丢失或乱序，或应用层自己实现可靠性机制的应用：

域名系统 (DNS): 快速查询 IP 地址。一次查询通常只需要一个请求和响应，简单快速比可靠性更重要（如果丢包，客户端可以重试）。
动态主机配置协议 (DHCP): 获取 IP 地址和其他网络配置信息。通常在本地网络中进行，网络条件较好，丢包率低。
流媒体 (Streaming Media): 如在线视频、音频。丢失一两个数据包可能只会导致画面或声音短暂卡顿，但TCP的重传延迟会导致更严重的卡顿。新到达的数据往往比重传旧数据更有价值。
实时多人在线游戏: 对延迟要求极高。丢失一两个表示玩家位置的数据包影响不大，但等待重传旧位置信息会严重影响游戏体验。
语音电话 (VoIP): 类似流媒体，实时性至关重要，可以容忍少量语音数据丢失。
网络时间协议 (NTP): 同步网络设备的时间。
简单网络管理协议 (SNMP): 查询和配置网络设备信息。
Trivial File Transfer Protocol (TFTP): 简单文件传输协议，通常用于启动设备或传输小文件，基于 UDP 实现，但它在应用层提供了简单的确认和重传机制。
QUIC (Quick UDP Internet Connections): 由 Google 开发，运行在 UDP 之上，但在应用层实现了类似 TCP 的可靠性、流量控制、拥塞控制以及连接管理等功能，并针对 HTTP/3 等应用进行了优化，提供了更低的连接延迟和更好的多路复用性能。这是一个典型的在 UDP 上构建可靠传输的例子。

四、TCP 与 UDP 的直接比较

特性	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
连接性	面向连接 (需要三次握手建立连接，四次挥手终止连接)	无连接 (直接发送数据报)
可靠性	可靠传输 (保证数据不丢失、不重复、按序到达)	不可靠传输 (尽力而为，不保证可靠性、顺序、不重复)
顺序性	保证数据按发送顺序交付	不保证数据按发送顺序交付 (可能乱序)
头部开销	较大 (通常 20 字节 + 可选字段)	较小 (固定 8 字节)
速度/延迟	较慢 (有连接建立/终止、确认、重传等开销，延迟相对高)	很快 (无连接开销，延迟极低)
状态	有状态 (需要维护连接状态、序列号、窗口大小等)	无状态 (不维护连接状态)
流量控制	有 (通过滑动窗口机制)	无 (可能导致接收方溢出)
拥塞控制	有 (通过慢启动、拥塞避免等算法)	无 (可能加剧网络拥塞)
数据单位	字节流 (将应用层数据视为无结构字节流，分段发送)	用户数据报 (保留应用层数据边界，每个数据报独立)
适用场景	对数据完整性、顺序要求高，允许一定延迟的应用	对实时性要求高，可容忍少量数据丢失或乱序的应用，或需要广播/多播的应用
复杂度	复杂 (协议逻辑复杂，需要实现多种控制机制)	简单 (协议逻辑简单)
应用举例	HTTP/HTTPS, FTP, SSH, SMTP, POP3, IMAP	DNS, DHCP, VoIP, 在线游戏, 流媒体 (部分), NTP, SNMP

五、如何选择 TCP 还是 UDP？

选择使用 TCP 还是 UDP 取决于应用的需求。这不是一个哪个协议更好的问题，而是哪个协议更适合特定任务的问题。

当应用需要可靠地传输数据，并且对数据顺序有严格要求时，应优先选择 TCP。 例如，传输文件、网页、邮件等，确保每一个字节都准确无误地到达至关重要。在这种情况下，即使为了可靠性而引入一些延迟和开销也是可以接受的。
当应用对传输速度和实时性要求极高，可以容忍少量数据丢失或乱序，或者需要进行广播/多播时，应优先选择 UDP。 例如，实时音视频通话、在线游戏、直播等。在这些场景下，快速到达的新数据往往比重传丢失的旧数据更有价值。丢失少量数据对用户体验的影响可能小于因等待重传而导致的严重延迟或卡顿。此外，一些应用（如 DNS）通过在应用层实现简单的重试机制来弥补 UDP 的不可靠性，利用 UDP 的低延迟特性。

值得注意的是，有些应用层协议（如前面提到的 QUIC）选择在 UDP 的基础上构建自己的可靠性、流控制和拥塞控制机制。这样做的原因可能是为了绕过操作系统的 TCP 实现的一些限制（如队头阻塞），或者为了更灵活地控制这些机制以适应特定的应用需求（如 HTTP/3）。这表明，即使在使用 UDP 时，如果应用需要可靠性，这部分逻辑就必须由应用层或其上的协议自行实现。

六、总结

TCP 和 UDP 作为传输层的核心协议，各自在互联网中扮演着不可或缺的角色。TCP 以其强大的可靠性保证，为Web、文件传输等奠定了坚实的数据传输基础；而 UDP 则以其极致的简洁和速度，为实时通信、在线游戏等提供了高效的传输通道。

理解 TCP 和 UDP 的根本区别——可靠传输 vs. 无连接快速传输——以及它们各自的工作原理、优缺点，对于网络应用的设计、开发和故障排除至关重要。它们并非竞争者，而是根据不同的应用需求相互补充的网络基石，共同支撑起丰富多彩的互联网世界。选择合适的协议，就是为应用选择了最适合它的“传输工具”。