简单理解TCP和UDP协议 – wiki基地

深入浅出：简单理解 TCP 和 UDP 协议

互联网，这个连接全球的巨大网络，每天传输着海量的信息。我们上网浏览网页、发送邮件、观看视频、进行语音通话、玩在线游戏……所有这些活动背后，都离不开一套复杂的规则和协议在默默支持。在这些协议中，传输层协议扮演着至关重要的角色，它们负责管理数据如何从一个应用程序（比如你的浏览器）传输到另一个应用程序（比如网站的服务器）。

在 TCP/IP 协议栈中，传输层主要有两个核心协议：传输控制协议 (TCP) 和 用户数据报协议 (UDP)。它们就像是网络世界里的两种不同的“快递服务”，各有各的特点和适用场景。理解 TCP 和 UDP，是理解互联网工作原理的关键一步。

本文将带你深入浅出地理解这两个协议，用通俗的语言和形象的比喻，揭开它们的面纱。

1. 理解网络协议的分层思想 (简单铺垫)

在我们深入 TCP 和 UDP 之前，有必要简单提一下网络协议的分层思想。我们常用的网络模型是 TCP/IP 模型（或更标准的 OSI 模型）。这个模型将复杂的网络通信过程分成了若干个层次，每一层负责不同的任务。

应用层 (Application Layer): 这是离用户最近的一层，负责处理特定的应用程序细节。比如 HTTP (网页浏览)、FTP (文件传输)、SMTP (邮件发送) 等协议都工作在这一层。当你打开浏览器输入网址时，就是应用层协议在工作。
传输层 (Transport Layer): 这一层是本文的重点！它负责在应用层和网络层之间传递数据，提供端到端的服务。它处理数据在不同应用程序端口之间的分配，以及数据的传输方式（可靠的还是不可靠的）。TCP 和 UDP 就工作在这一层。
网络层 (Network Layer): 负责处理数据包在不同网络之间的路由和寻址。IP (互联网协议) 是这一层的核心，它确保数据包能够找到从源地址到目标地址的最佳路径。
数据链路层 (Data Link Layer) 和物理层 (Physical Layer): 这两层负责处理数据在物理介质（如网线、光纤、Wi-Fi 信号）上的传输，以及局域网内的通信和错误检测。

理解了分层，我们知道 TCP 和 UDP 是位于传输层的协议，它们接收来自应用层的数据，并将其交给网络层的 IP 协议进行传输。IP 协议只管把数据包送到目的地网络，至于到了目的地后是交给哪个程序、数据有没有丢、顺序对不对，这些就是传输层（TCP 或 UDP）的责任了。

2. TCP 协议：可靠的连接使者 (Transmission Control Protocol)

TCP，全称是 Transmission Control Protocol，意为“传输控制协议”。从名字中的“控制”二字，我们就能感受到它是一个功能比较强大、考虑比较周全的协议。TCP 的核心特点是提供可靠的、面向连接的数据传输服务。

想象一下，TCP 就像一个非常负责任的邮政服务，当你寄送重要文件时，你会选择挂号信或快递。这种服务会确保你的信件能够安全、完整、按顺序地送达收件人手中，并且你会收到对方签收的确认。如果信件丢失或损坏，邮局会负责重新寄送。

2.1 面向连接 (Connection-Oriented)

TCP 的“面向连接”意味着在正式传输数据之前，发送方和接收方必须先建立一个虚拟的连接。这个建立连接的过程被称为“三次握手” (Three-Way Handshake)。

TCP 三次握手简述：

第一次握手 (SYN): 客户端（例如你的浏览器）向服务器发送一个特殊的同步序列号（SYN）包，请求建立连接。这个包里包含客户端的初始序列号（比如 ISN_client）。这就像客户端对服务器说：“你好，我想和你通信，这是我开始的序号。”
第二次握手 (SYN-ACK): 服务器收到 SYN 包后，如果同意连接，会回复一个 SYN-ACK 包。这个包里包含服务器的初始序列号（ISN_server）和对客户端 SYN 包的确认号（ACK = ISN_client + 1）。这就像服务器回复：“你好，我也同意通信，这是我开始的序号，并且我收到了你的请求。”
第三次握手 (ACK): 客户端收到 SYN-ACK 包后，再回复一个 ACK 包，包含对服务器 SYN 包的确认号（ACK = ISN_server + 1）。这就像客户端说：“好的，我收到你的回复了，我们可以开始通信了。”

完成这三次通信后，客户端和服务器之间的 TCP 连接就正式建立了，双方就可以开始可靠地传输数据了。建立连接的目的是为了初始化双方的序列号、确认号以及窗口大小等重要参数，为后续的可靠传输打下基础。

通信结束后，TCP 连接也需要优雅地关闭，这通常通过“四次挥手” (Four-Way Handshake) 来完成，以确保双方都同意断开连接，并且所有待发送的数据都已发送完毕。

2.2 可靠传输 (Reliable Transfer)

“可靠”是 TCP 最核心的特性。互联网环境复杂，数据在传输过程中可能会丢失、重复或乱序。TCP 通过一系列机制来克服这些问题，确保数据能够“一个不丢，顺序不错”地到达目的地。

如何实现可靠性呢？TCP 主要依靠以下机制：

序列号 (Sequence Numbers): TCP 给每一个发送的字节数据都编上序号。发送方发送数据时，会带上数据的起始序列号。
确认应答 (Acknowledgements – ACK): 接收方收到数据后，会发送一个确认应答包 (ACK) 给发送方，告诉发送方“我收到了从哪个序号到哪个序号的数据”。例如，如果接收方收到了序号为 1 到 1000 的数据，它会发送一个 ACK 包，确认号是 1001，表示“我期待收到从 1001 开始的数据”。
超时重传 (Retransmission): 发送方在发送数据后会启动一个定时器。如果在定时器超时之前没有收到接收方对该数据的确认应答，发送方就会认为数据丢失，并会自动重新发送该数据。
累计确认 (Cumulative Acknowledgements): TCP 的 ACK 是累计的。如果收到了序号 1-1000 的数据并发送了 ACK 1001，后来又收到了 2001-3000 的数据（中间 1001-2000 的数据可能丢失），即使中间的数据还没到，接收方仍然可以发送 ACK 3001，表示“我期望收到从 3001 开始的数据”，这隐含了对 1-1000 和 2001-3000 这两段数据的确认。
数据排序 (In-order Delivery): 接收方收到数据包后，会根据序列号将乱序到达的数据包重新排序，然后才提交给应用层。这样，应用层总是能收到按发送顺序排列的数据。
校验和 (Checksum): TCP 会计算数据包的校验和，接收方收到数据包后也会计算校验和并进行对比，如果校验和不匹配，说明数据在传输过程中损坏了，接收方会丢弃这个包，并且不会发送 ACK。发送方由于没有收到 ACK，会在超时后重传。

通过这些机制，TCP 确保了发送的数据能够可靠、有序地到达目的地。

2.3 流量控制 (Flow Control)

想象一下，发送方的数据发送得非常快，而接收方的处理能力（比如缓冲区大小或CPU处理速度）跟不上，结果接收方的缓冲区满了，导致后续到达的数据包被丢弃。为了避免这种情况，TCP 提供了流量控制机制。

流量控制通过滑动窗口 (Sliding Window) 机制实现。接收方在发送 ACK 包时，会告诉发送方自己还有多少可用的接收缓冲区空间，这个值就是接收窗口大小 (rwnd)。发送方收到这个信息后，会限制自己发送的数据量，确保发送的数据不会超过接收方当前的处理能力。这就像水龙头可以根据水管的承受能力调节出水量。

2.4 拥塞控制 (Congestion Control)

拥塞控制与流量控制不同。流量控制是为了保护接收方，而拥塞控制是为了保护整个网络。当网络中数据量过大，超过了网络的承受能力时，就会发生拥塞，导致大量数据包丢失，甚至网络瘫痪。TCP 作为一个“负责任”的协议，具备拥塞控制机制。

TCP 的拥塞控制算法有很多（比如慢启动、拥塞避免、快重传、快恢复等），它们的目标是动态地调整发送方的数据发送速率，使其与网络的拥塞程度相匹配。发送方会通过监测网络状况（如丢包率、延迟）来判断网络是否拥塞。如果检测到拥塞，发送方会降低发送速率，以减轻网络负担；如果网络状况良好，发送方会逐步增加发送速率。这就像公路上的车辆会根据交通状况调整车速，避免造成大面积堵塞。

2.5 TCP 的特点总结

面向连接: 数据传输前需要建立连接（三次握手）。
可靠: 提供数据丢失、重复、乱序的保障。
有序: 数据按发送顺序到达。
全双工: 数据可以在同一时间双向传输。
面向字节流: 应用层的数据会被看作是字节流，TCP 会对字节流进行分段，形成 TCP 报文段进行传输。
有流量控制: 根据接收方的能力调节发送速率。
有拥塞控制: 根据网络状况调节发送速率，避免网络拥塞。
报文头较大: 为了实现这些复杂的功能，TCP 报文头部信息较多（至少 20 字节，有选项时更多），开销较大。
传输速度相对较慢: 由于需要进行连接建立、确认、重传等操作，TCP 的传输速度相对 UDP 要慢。

2.6 TCP 的适用场景

由于 TCP 提供了可靠的、有序的数据传输，它非常适合那些对数据完整性和准确性要求极高的应用场景：

网页浏览 (HTTP/HTTPS): 需要确保网页的文本、图片、脚本等所有内容都完整无误地到达。
文件传输 (FTP): 必须保证传输的文件与源文件完全一致，不能有任何差错。
电子邮件 (SMTP/POP3/IMAP): 邮件内容必须准确无误地发送和接收。
远程登录 (SSH): 需要稳定可靠的连接来执行命令。
在线聊天 (部分应用): 确保每条消息都能准确送达。

总之，任何需要“不丢一个字、不少一个字节”的应用，都倾向于使用 TCP。

3. UDP 协议：快速的非连接快递员 (User Datagram Protocol)

UDP，全称是 User Datagram Protocol，意为“用户数据报协议”。与“控制”意味浓厚的 TCP 不同，UDP 名字里的“数据报”和“用户”暗示了它的简洁和面向独立数据单元的特点。UDP 提供的是一种不可靠的、无连接的数据传输服务。

如果说 TCP 是挂号信或快递，那么 UDP 更像是一个普通的明信片或者你对着人群喊话。你写好明信片（或者喊出消息），直接扔进邮筒（或者直接喊），不管对方在不在、听不听得见、明信片会不会丢或者损坏，你都完成了发送。你不会收到对方是否收到的确认，也不会管对方是否能按顺序收到你的多张明信片。

3.1 无连接 (Connectionless)

UDP 的“无连接”意味着在传输数据之前，发送方和接收方之间不需要建立连接。发送方直接将数据封装成 UDP 数据报，然后一股脑地发送出去，不管接收方是否在线、是否准备好接收。接收方也只是被动地接收数据，不需要发送任何确认信息。

这大大简化了传输过程。没有三次握手和四次挥手，节省了建立和关闭连接所需的 RTT (往返时间) 延迟和系统资源。

3.2 不可靠传输 (Unreliable Transfer)

“不可靠”是 UDP 的核心特性。这里的“不可靠”不是说 UDP 完全不能用，而是说 UDP 本身不提供任何数据丢失、重复、乱序的保证。

UDP 为什么不可靠？因为它没有：

序列号: UDP 数据报是独立的单元，没有统一的序列号来标识它们在整个数据流中的位置。
确认应答 (ACK): 发送方发送数据后，不关心接收方是否收到，接收方也不会发送确认。
超时重传: 数据丢失了就是丢失了，UDP 不会检测也不会重传。
数据排序: 数据报到达接收方的顺序可能与发送顺序不同，UDP 不会对其进行排序，而是直接交给应用层。
流量控制: UDP 不会关心接收方的接收能力，只是尽力地发送数据。
拥塞控制: UDP 不会关心网络是否拥塞，它只会一股脑地将数据注入网络。

正因为抛弃了这些复杂的机制，UDP 的处理逻辑非常简单，发送和接收的开销很小。

3.3 UDP 的其他特点

面向数据报: 应用层交给 UDP 的数据，UDP 会原样不动地封装成一个 UDP 数据报发送出去。每个 UDP 数据报都是一个独立的数据单元，有明确的边界。接收方一次接收一个完整的数据报。
传输速度快: 由于省去了建立/关闭连接、确认、重传、流量控制、拥塞控制等机制，UDP 的传输速度非常快，延迟很低。
头部开销小: UDP 报文头部非常简单，只有 8 个字节（源端口、目标端口、长度、校验和），这使得数据传输的有效载荷比例更高。
可能会丢包: 由于没有重传机制，数据在传输过程中遇到网络问题（如拥塞、链路故障）时，很可能发生丢包。
可能会乱序: 数据报通过网络的不同路径到达时，顺序可能发生变化。

3.4 UDP 的适用场景

尽管 UDP 不可靠，但其简洁、高效、低延迟的特性，使其在一些特定场景下比 TCP 更具优势：

实时多媒体应用 (视频会议、IP电话/VoIP): 对实时性要求极高。即使丢失少量语音或视频帧，也能接受，因为重传会引入 unacceptable 的延迟，影响用户体验。流畅性比完整性更重要。
在线游戏: 对延迟非常敏感。游戏中的实时状态信息（如玩家位置、动作）需要尽快到达，即使偶尔丢失几个状态更新包，可以通过后续的包来弥补，或者利用客户端的预测算法来平滑处理。等待重传同样会造成卡顿。
流媒体播放 (直播): 类似实时多媒体，快速传输少量丢包可接受。
域名系统 (DNS): DNS 查询通常很短，而且通常是客户端发一个请求，服务器回一个响应。这种简单的请求-响应模式，使用无连接的 UDP 更高效。如果查询失败（丢包），应用层（DNS客户端）可以很容易地进行重试。
简单网络管理协议 (SNMP): 用于网络设备的管理和监控，通常也是少量数据的快速交换。
广播和多播: UDP 支持一对多、一对所有人的通信模式，而 TCP 只能一对一通信。

在这些应用中，开发者通常会在应用层自己实现一些简单的可靠性机制（如简单的重传），以在效率和可靠性之间取得平衡，或者根本就牺牲一部分可靠性来换取速度。

4. TCP 与 UDP 的核心差异对比

为了更清晰地理解两者的区别，我们可以将它们的关键特性进行对比：

特性	TCP (传输控制协议)	UDP (用户数据报协议)
连接性	面向连接 (Connection-Oriented) – 传输前需建立连接	无连接 (Connectionless) – 直接发送数据
可靠性	可靠 (Reliable) – 保证数据不丢失、不重复	不可靠 (Unreliable) – 不保证数据能否到达
有序性	有序 (Ordered) – 数据按发送顺序到达并提交	无序 (Unordered) – 数据报可能乱序到达
速度	相对较慢 (Less Speed) – 有额外开销和延迟	相对较快 (More Speed) – 开销少，延迟低
头部大小	较大 (Large Header) – 至少 20 字节	较小 (Small Header) – 固定 8 字节
开销	较高 (Higher Overhead) – 连接管理、确认、重传等	较低 (Lower Overhead) – 只负责基本的数据封装
传输方式	面向字节流 (Byte Stream)	面向数据报 (Datagram)
流量控制	有 (Yes) – 基于滑动窗口	无 (No)
拥塞控制	有 (Yes) – 各种算法调节发送速率	无 (No)
适用场景	对数据完整性要求高：网页、文件传输、邮件等	对实时性要求高，少量丢包可接受：视频/语音通话、在线游戏、DNS等

5. 为什么互联网需要两种协议？应用场景的抉择

看到这里，你可能会问：既然 TCP 这么可靠，为什么还需要 UDP 呢？难道所有的应用不都希望数据可靠传输吗？

答案是：不是所有应用都把可靠性放在第一位。有些应用对实时性和低延迟的要求远高于对数据完整性的要求。

对于文件下载、网页浏览这些应用，数据丢失或损坏是绝对不能接受的。丢失一个字节可能导致文件无法打开、网页无法显示。所以它们必须使用 TCP，即使这意味着要花时间建立连接、处理确认、重传，导致一点延迟。
但对于在线语音通话或游戏来说，如果网络发生拥塞导致数据包丢失，TCP 的处理方式是：检测到丢包 -> 暂停发送新数据 -> 等待超时 -> 重传丢失的数据。这个过程会引入明显的延迟，语音就会出现卡顿甚至中断，游戏画面会停顿。而如果使用 UDP，即使丢失了几个表示“当前语音片段”或“玩家位置”的数据包，新的数据包很快就会到来，虽然丢失的那一瞬间信息不完整，但整个流程是连贯的，用户体验更好。宁愿听到一点杂音或看到画面轻微跳跃，也不愿长时间卡死。

所以，TCP 和 UDP 各司其职，共同构建了丰富多彩的互联网应用生态。TCP 适用于那些追求“慢但稳”的场景，而 UDP 适用于那些追求“快第一，丢点也行”的场景。它们不是竞争对手，而是互补的关系。

选择使用 TCP 还是 UDP，完全取决于应用的需求。如果你的应用需要保证数据完整性、顺序性，且可以容忍一定的延迟，那么选择 TCP。如果你的应用对实时性要求极高，可以容忍少量数据丢失或乱序，且希望开销尽可能小，那么选择 UDP。

6. 深入理解 TCP 的可靠性机制 (补充细节)

为了更深入地体会 TCP 的“负责”，我们再详细看看它是如何实现可靠性的：

序列号 (Sequence Number) 和确认号 (Acknowledgement Number):
- 每个 TCP 连接都有两个方向独立的数据流。发送方给发送的每个字节都编上序列号。
- 当发送方发送一个报文段（包含一段数据）时，报文段头部会包含该段数据的起始序列号。
- 接收方收到报文段后，如果数据是完整的（校验和正确），就会发送一个确认报文段。确认报文段的确认号（ACK Number）是接收方期望收到的下一个字节的序列号。例如，如果收到了包含序列号 1001 到 2000 的数据，确认号就是 2001。
- 发送方收到确认后，就知道序号到 2000 的数据已经被接收方成功接收了。
滑动窗口 (Sliding Window) – 流量控制的核心:
- TCP 使用滑动窗口来实现流量控制和提高效率。窗口是指发送方无需等待确认就可以连续发送的数据量。
- 接收方在 ACK 报文段中会告知发送方当前的“接收窗口大小 (rwnd)”，即自己缓冲区还能接收多少字节。
- 发送方维护一个“发送窗口”，其大小受限于接收方的 rwnd 和自身的“拥塞窗口大小 (cwnd)”。发送方只能发送窗口内的数据。
- 随着数据的发送和确认，窗口会向前滑动。这种机制允许发送方连续发送多个数据报文段，而不需要每发送一个就等待确认，大大提高了传输效率（相比于停止-等待协议）。同时，通过 rwnd 又能防止发送方淹没接收方。
拥塞控制简述:
- TCP 拥塞控制是一个复杂的话题，但基本思想是通过调整拥塞窗口 (cwnd) 来控制发送速率。
- 慢启动 (Slow Start): 连接刚建立时，cwnd 从一个较小的值开始（比如 1 个 MSS，最大报文段大小），每收到一个 ACK，cwnd 就指数级增长。这可以快速探测网络的承载能力。
- 拥塞避免 (Congestion Avoidance): 当 cwnd 达到某个阈值后，增长速度变慢，线性增长。
- 检测拥塞: 如果发生丢包（通过超时或收到重复 ACK 检测到），TCP 认为网络可能发生拥塞。
- 处理拥塞: 降低 cwnd（通常减半或降到初始值），重新进入慢启动或拥塞避免阶段，以减轻网络负担。
- 这是一种自我调节机制，使得 TCP 连接能够动态地适应网络状况。

这些机制协同工作，使得 TCP 在复杂的互联网环境中依然能够提供可靠的数据传输。

7. UDP 的简洁之美 (补充细节)

与 TCP 的复杂相比，UDP 的简洁体现在其头部结构和处理逻辑上：

UDP 头部:
- 只有 8 个字节：源端口号 (2 bytes)、目标端口号 (2 bytes)、长度 (2 bytes)、校验和 (2 bytes)。
- 源端口号和目标端口号用于将数据交给特定的应用进程，这是传输层协议的基本功能。
- 长度字段表示整个 UDP 数据报（头部+数据）的长度。
- 校验和是可选的，用于检测数据在传输过程中是否损坏，但 UDP 不提供重传机制。如果校验和错误，接收方可以选择丢弃这个数据报，但发送方并不知道。
面向数据报的特点:
- 应用层的数据被原封不动地打包进 UDP 数据报。如果应用层发送了两个独立的数据块 A 和 B，UDP 会发送两个独立的 UDP 数据报 A’ 和 B’。
- 接收方也是一次接收一个完整的数据报。如果发送的数据报很大，超过了网络层能够处理的最大传输单元 (MTU)，可能会在网络层被分片，但这层分片是 IP 协议完成的，到达目的地后 IP 协议会尽量重组，但如果分片丢失，整个数据报就会丢失。而 UDP 本身不会进行分片或重组的复杂处理。

UDP 的这种简洁性正是其高效的原因所在。它将可靠性等复杂任务留给应用层去处理，自己只专注于快速地发送独立的、无关联的数据报。

8. 总结

TCP 和 UDP 是互联网传输层最重要的两个协议，它们提供不同的服务：

TCP (Transmission Control Protocol): 提供可靠的、面向连接的、有序的字节流传输服务。它通过三次握手建立连接，使用序列号、确认应答、超时重传、滑动窗口、拥塞控制等复杂机制来保证数据的可靠性和流量控制。适用于对数据完整性要求高的场景，如网页、文件传输、邮件。
UDP (User Datagram Protocol): 提供不可靠的、无连接的数据报传输服务。它直接发送数据报，不建立连接，不保证数据的到达、顺序或完整性。头部开销小，传输速度快。适用于对实时性要求高，可以容忍少量丢包或乱序的场景，如实时语音/视频、在线游戏、DNS。

理解 TCP 和 UDP 的区别和各自的优势，有助于我们理解不同的网络应用为何采用特定的协议，以及在设计网络应用时如何选择合适的传输层协议。它们共同构成了互联网高效且多样的传输基础。

无论是追求稳定可靠的 TCP，还是注重快速效率的 UDP，它们都在各自的领域发挥着不可替代的作用，共同支撑着我们丰富多彩的网络生活。