TCP vs UDP对比：彻底搞懂传输层协议 – wiki基地

TCP vs UDP 对比：彻底搞懂传输层协议

在浩瀚的网络世界中，数据包如同信息快递员，在错综复杂的线缆和无线电波中穿梭，将数字信息从世界的这一端送往另一端。而在这些快递员的旅程中，有一个至关重要的中转站和调度中心，那就是传输层。它是网络协议栈中连接应用层和网络层的桥梁，负责将应用进程的报文分割成合适的报文段，并交给网络层进行传输；同时，它也将网络层传来的报文段组装起来，交付给相应的应用进程。

在传输层，有两种最主要的协议主导着网络的脉搏：传输控制协议（TCP, Transmission Control Protocol）和用户数据报协议（UDP, User Datagram Protocol）。它们就像一对性格迥异的兄弟，一个严谨可靠，一个奔放自由。理解它们的区别与联系，对于理解网络如何工作至关重要，也是构建高性能、可靠或实时网络应用的基础。

本文将深入剖析 TCP 和 UDP 这两个传输层巨头，从它们的特性、工作原理、优缺点到适用场景，带你彻底搞懂这对“欢喜冤家”。

一、传输层：连接进程的桥梁

在开始深入 TCP 和 UDP 之前，我们先简要回顾一下传输层在网络协议栈中的位置和作用。互联网协议栈通常分为五层：应用层、传输层、网络层、数据链路层和物理层。

应用层： 直接与用户应用交互，提供特定的网络服务（如 HTTP、FTP、SMTP、DNS 等）。
传输层： 位于应用层之下，网络层之上。它负责为不同主机上的应用进程提供端到端（进程到进程）的逻辑通信。它将应用层的数据分割或合并，封装成传输层报文段，并提供端口号来标识目标主机的具体应用进程。
网络层： 负责将数据报从源主机路由到目的主机（主机到主机），但不关心是哪个进程。它处理的是IP地址。
数据链路层： 负责将数据报从一个节点传输到相邻的下一个节点，处理的是MAC地址。
物理层： 负责比特流的传输。

传输层的核心任务可以概括为两点：

进程到进程的交付 (Process-to-Process Delivery)： 网络层提供的是主机到主机的交付，而传输层通过使用端口号，将数据准确地交付给目标主机上的目标进程。这被称为多路复用 (Multiplexing) 和多路分用 (Demultiplexing)。源主机的传输层从多个应用进程接收数据，并将它们通过网络层发送出去（多路复用）；目的主机的传输层接收来自网络层的数据，根据报文段中的端口号将数据分发给相应的应用进程（多路分用）。
提供不同类型的服务： 传输层协议为应用层提供不同等级的服务质量。TCP 提供可靠的、面向连接的服务，而 UDP 提供不可靠的、无连接的服务。

理解了传输层的基本职能，我们就可以更好地理解 TCP 和 UDP 各自的设计理念和用途。

二、 TCP：可靠的承诺者 (Transmission Control Protocol)

TCP 是一个面向连接（Connection-Oriented）、可靠（Reliable）、基于字节流（Byte Stream）的传输层协议。它的设计目标是在不可靠的网络层之上构建一个可靠的数据传输通道，确保数据按发送顺序无差错地到达目的地。

2.1 TCP 的核心特性

面向连接 (Connection-Oriented)： 在数据传输之前，TCP 需要建立一个连接。这涉及到著名的“三次握手”。连接建立后，通信双方会维护一个连接状态。数据传输完成后，需要进行“四次挥手”来终止连接。这种连接状态的管理增加了开销，但也为可靠性奠定了基础。
可靠传输 (Reliable Transfer)： TCP 通过以下机制确保数据可靠传输：
- 序号 (Sequence Numbers)： TCP 为每个发送的字节流分配一个序号，报文段中包含该报文段第一个字节的序号。这使得接收方能够识别丢失的报文段，并按正确顺序重组接收到的数据。
- 确认应答 (Acknowledgments, ACK)： 接收方在收到报文段后，会发送一个确认应答，包含它期望接收的下一个字节的序号。这告诉发送方之前的数据已经成功接收。
- 超时重传 (Timeout and Retransmission)： 发送方为每个发送的报文段设置一个定时器。如果在定时器超时之前没有收到对应的确认应答，发送方就会认为报文段丢失，并重新发送该报文段。
按序交付 (Ordered Delivery)： 由于使用了序号，即使报文段到达时顺序错乱，接收方也能够根据序号对数据进行排序，然后按正确的顺序向上层应用交付。
流量控制 (Flow Control)： TCP 通过流量控制机制，防止发送方发送数据过快而导致接收方无法及时处理。接收方会告知发送方自己当前的接收窗口大小（Receive Window），即接收方还有多少缓冲区空间可以接收数据。发送方根据接收窗口大小来限制发送速率，确保不会“淹没”接收方。
拥塞控制 (Congestion Control)： 与流量控制不同，拥塞控制关注的是整个网络的负载情况。当网络中的路由器或链路过载时，会发生拥塞，导致报文段丢失和传输延迟增加。TCP 的拥塞控制算法（如慢启动、拥塞避免、快速重传、快速恢复等）会根据网络状况动态调整发送速率，以避免和减轻网络拥塞，公平地利用网络资源。
全双工通信 (Full-Duplex)： TCP 连接允许数据在同一时间双向传输。
基于字节流 (Byte Stream)： 虽然 TCP 将应用数据分割成报文段发送，但从应用层的角度看，TCP 提供的是一个连续的、无结构的字节流接口。应用层写入的字节会按顺序发送，接收方也会按顺序接收字节流，而无需关心报文段的边界。

2.2 TCP 的三次握手 (Three-Way Handshake)

建立 TCP 连接的过程通常被称为三次握手：

第一次握手 (SYN)： 客户端发送一个 SYN (Synchronize) 报文段到服务器，其中包含客户端的初始序号 (ISN_c)。客户端进入 SYN-SENT 状态。
第二次握手 (SYN-ACK)： 服务器收到 SYN 报文段后，如果同意建立连接，会发送一个 SYN-ACK 报文段。其中包含服务器的初始序号 (ISN_s) 和对客户端 SYN 的确认 (ACK)，确认号是 ISN_c + 1。服务器进入 SYN-RECEIVED 状态。
第三次握手 (ACK)： 客户端收到 SYN-ACK 报文段后，发送一个 ACK 报文段。其中包含对服务器 SYN 的确认，确认号是 ISN_s + 1。客户端进入 ESTABLISHED 状态。服务器收到 ACK 后也进入 ESTABLISHED 状态。

至此，TCP 连接建立成功，双方可以开始传输数据。三次握手的主要目的是同步通信双方的初始序号，并确认双方都能正常收发数据。

2.3 TCP 的四次挥手 (Four-Way Handshake)

终止 TCP 连接的过程通常被称为四次挥手：

第一次挥手 (FIN)： 某个通信方（假设是客户端）发送一个 FIN (Finish) 报文段，表示它已经没有数据要发送了，但仍然可以接收数据。客户端进入 FIN-WAIT-1 状态。
第二次挥手 (ACK)： 另一方（服务器）收到 FIN 报文段后，发送一个 ACK 报文段，确认收到 FIN。服务器进入 CLOSE-WAIT 状态。此时，客户端到服务器的单向连接已关闭，但服务器仍然可以向客户端发送数据。
第三次挥手 (FIN)： 服务器在完成数据发送后，也发送一个 FIN 报文段，表示它也没有数据要发送了。服务器进入 LAST-ACK 状态。
第四次挥手 (ACK)： 客户端收到服务器的 FIN 报文段后，发送一个 ACK 报文段进行确认。客户端进入 TIME-WAIT 状态（需要等待一段时间以确保服务器收到 ACK 并处理完毕）。服务器收到 ACK 后进入 CLOSED 状态。客户端在 TIME-WAIT 结束后也进入 CLOSED 状态。

连接彻底关闭。之所以需要四次，是因为 TCP 是全双工的，一端的关闭（FIN）只代表该端不再发送数据，但仍然可以接收，直到另一端也发送 FIN 并得到确认，整个连接才完全关闭。

2.4 TCP 的优点与缺点

优点：

可靠性高： 确保数据无丢失、无差错、按序到达。
流量控制： 防止接收方缓冲区溢出。
拥塞控制： 避免网络拥塞，公平利用带宽。
全双工通信： 支持双向数据传输。

缺点：

开销大： 连接建立、维护和终止都需要额外的报文段和状态信息；报文段头部较大（通常 20 字节，带选项时更大）。
传输延迟高： 为了保证可靠性，可能需要重传、排序、等待确认等，引入额外的延迟。三次握手也增加了连接建立的延迟。
不适用于广播或多播： TCP 是点对点通信。

2.5 TCP 的典型应用场景

任何需要高度可靠性，对数据完整性和顺序有严格要求的应用都适合使用 TCP，例如：

网页浏览 (HTTP/HTTPS)： 确保网页内容完整、正确地加载。
文件传输 (FTP)： 确保文件内容不丢失。
电子邮件 (SMTP/POP3/IMAP)： 确保邮件内容完整。
远程登录 (SSH)： 确保命令和输出准确无误。
数据库连接： 确保数据查询和操作的正确性。

三、 UDP：简单的传递者 (User Datagram Protocol)

UDP 是一个无连接（Connectionless）、不可靠（Unreliable）、基于数据报（Datagram-based）的传输层协议。它的设计理念是提供最简单的传输服务，尽可能地减少开销和延迟。

3.1 UDP 的核心特性

无连接 (Connectionless)： UDP 在发送数据之前，不需要建立连接。发送方直接将数据封装成 UDP 数据报发送出去，接收方也直接接收。这省去了三次握手和四次挥手的开销。
不可靠传输 (Unreliable Transfer)： UDP 不保证数据一定能够到达目的地，也不保证数据到达的顺序与发送顺序一致。它不做任何可靠性保证，报文段可能丢失、重复或乱序。它只负责将数据报尽力（best-effort）地从源主机的某个进程发送到目的主机的某个进程。
无序交付 (Unordered Delivery)： 发送方发送的 UDP 数据报可能经过网络中的不同路径，因此到达接收方的顺序可能与发送顺序不同。
无流量控制 (No Flow Control)： UDP 不提供流量控制机制。发送方可以以任意速率发送数据，即使接收方无法处理。
无拥塞控制 (No Congestion Control)： UDP 本身也不提供拥塞控制。如果 UDP 应用发送速率过快，很容易导致网络拥塞，进而加剧丢包。这要求基于 UDP 的应用层协议自己来处理拥塞问题。
基于数据报 (Datagram-based)： UDP 将应用层的数据视为一个独立的数据报。发送方写入多少数据，UDP 就发送一个包含这些数据的数据报。接收方也是接收一个完整的数据报。应用程序需要自己处理数据报的边界。
头部开销小： UDP 报文段头部非常简单，只有固定的 8 个字节（源端口号、目的端口号、长度、校验和）。

3.2 UDP 的简单性

UDP 的简单性体现在它几乎没有额外的机制。它只是对应用层数据进行简单的封装（加上 8 字节头部，包含源端口、目的端口、数据报长度和可选的校验和），然后交给网络层。接收方收到 UDP 数据报后，也只是检查一下校验和（如果启用），然后根据目的端口号将数据报的内容直接提交给相应的应用进程。

没有连接状态、没有序号、没有确认、没有重传、没有流量控制、没有拥塞控制。所有这些可靠性和控制功能如果需要，必须由应用层自己实现。

3.3 UDP 的优点与缺点

优点：

开销小： 无需建立和维护连接，头部开销小，适合传输小数据包。
传输延迟低： 无需等待确认、无需重传、无需排序，传输速度快，适合对实时性要求高的应用。
支持广播和多播： UDP 支持一对多、多对多通信。
应用层控制： 将可靠性、流量控制、拥塞控制等功能交给应用层实现，使得应用可以根据自身需求进行灵活控制。

缺点：

不可靠： 数据可能丢失、重复、乱序。
无流量/拥塞控制： 应用需要自己处理，否则可能导致网络拥塞。

3.4 UDP 的典型应用场景

对实时性要求高，能够容忍少量数据丢失，或者应用层自己实现了可靠性机制的场景适合使用 UDP，例如：

在线游戏： 快速响应是关键，短暂的丢包可能导致画面瞬间不连贯，但重传旧数据只会加剧延迟，不如直接丢弃。
流媒体传输 (视频会议、直播)： 允许一定的丢包以保证流畅性。现代流媒体协议（如 RTP/RTCP）通常运行在 UDP 之上，并在应用层进行一定的缓冲、 jitter control (抗抖动) 等处理。
域名系统 (DNS)： 简单的请求-响应模式，通常一个 UDP 数据报就能完成，效率高。
语音通话 (VoIP)： 类似流媒体，对延迟非常敏感。
TFTP (Simple File Transfer Protocol)： 一个简单的文件传输协议，虽然叫文件传输，但它运行在 UDP 上，并由应用层实现可靠性。
NFS (Network File System)： 早期版本运行在 UDP 上。
一些物联网 (IoT) 应用： 资源受限设备可能倾向于使用开销更小的 UDP。

四、 TCP 与 UDP 的关键对比总结

通过前面的深入分析，我们可以将 TCP 和 UDP 的关键区别总结如下表：

特性	TCP (传输控制协议)	UDP (用户数据报协议)
连接性	面向连接 (Connection-Oriented)	无连接 (Connectionless)
可靠性	可靠传输，保证数据无丢失、无差错	不可靠传输，尽力交付 (Best-Effort)
数据顺序	按序交付	无序交付 (乱序到达是可能的)
传输单位	字节流 (Byte Stream)	数据报 (Datagram)
头部大小	较大 (通常 20 字节，带选项时更大)	较小 (固定 8 字节)
传输速度	相对较慢 (需建立/维护连接、重传、排序等)	相对较快 (直接发送，无额外机制)
开销	高 (连接管理、状态维护、各种控制机制)	低 (简单封装，无状态)
流量控制	有 (通过滑动窗口)	无
拥塞控制	有 (多种算法)	无 (应用层需自己处理，否则可能导致拥塞)
一对一	支持	支持
一对多	不支持	支持 (广播、多播)
适用场景	对可靠性要求高、数据量大、不追求极致实时性	对实时性要求高、可容忍丢包、小数据量、广播
典型应用	HTTP/HTTPS, FTP, SMTP, SSH, 数据库连接	DNS, VoIP, 在线游戏, 流媒体, TFTP

五、何时选择 TCP，何时选择 UDP？

选择 TCP 还是 UDP 取决于应用的具体需求。这是一个权衡的过程：

如果你需要高度可靠的数据传输，不能容忍任何数据丢失或错误，且对传输延迟不是极端敏感： 选择 TCP。TCP 提供的可靠性、流量控制和拥塞控制机制为你省去了大量的底层工作。你无需担心数据是否到达、是否重复、是否乱序、网络是否拥塞等问题，专注于应用逻辑即可。
如果你对传输延迟非常敏感，能够容忍一定的数据丢失或错误，或者打算在应用层实现自己的可靠性、流量或拥塞控制机制： 选择 UDP。UDP 的简单和高效为你提供了最大的灵活性和最低的开销。你可以根据应用的特点（如实时音视频，允许丢失少量帧但必须快速传输）定制自己的传输策略。

需要注意的是，即使是使用 UDP，现代的应用层协议也往往会在其之上构建一些机制来弥补 UDP 的不足，例如：

RTP/RTCP (Real-time Transport Protocol/Control Protocol)： 用于流媒体，RTP 提供时间戳和序列号帮助接收方重组和同步数据，RTCP 用于传输控制信息和 QoS 反馈。
QUIC (Quick UDP Internet Connections)： 一种新的传输层协议，运行在 UDP 之上，但增加了连接多路复用、加密传输、连接迁移以及丢包恢复和拥塞控制等特性，旨在结合 TCP 的可靠性和 UDP 的低延迟优势。它被用于 HTTP/3。

这表明，虽然 TCP 和 UDP 本身特性固定，但基于它们的上层协议却可以通过创新的设计来满足多样化的网络应用需求。

六、结论

TCP 和 UDP 作为传输层最核心的协议，各自扮演着不可或缺的角色。TCP 以其可靠性、有序性和丰富的控制机制，成为大多数传统网络应用的基石，适用于那些数据不容有失的场景。UDP 则以其简洁、高效和低延迟的特点，在实时应用、广播/多播等领域大放异彩，适用于那些速度优先、可容忍少量损失或需要应用层灵活控制的场景。

理解 TCP 和 UDP 的本质区别，不仅仅是记忆它们的特性列表，更重要的是理解这些特性背后的设计哲学以及它们对应用性能和行为的影响。通过深入学习它们的工作原理，特别是 TCP 的三次握手、四次挥手、流量控制和拥塞控制，以及 UDP 的无连接和极简特性，我们能够更好地选择合适的协议来构建高效、健壮的网络应用。

在快速发展的网络技术中，虽然新的协议（如 QUIC）正在涌现，但 TCP 和 UDP 的基本原理和权衡思想仍然是理解现代网络通信的基石。彻底搞懂它们，你就掌握了网络传输层最核心的秘密。