一文读懂TCP – wiki基地

---

一文读懂TCP：互联网基石的深度剖析

互联网，这个连接世界的庞大网络，每时每刻都在传输着海量的数据。从您浏览网页、发送邮件，到观看在线视频、进行语音通话，数据的可靠、有序传输是这一切的基础。而在这背后默默工作的关键协议之一，就是传输控制协议（Transmission Control Protocol，TCP）。

TCP是TCP/IP协议族中至关重要的一环，它位于传输层，为应用层提供了一种可靠的、面向连接的、基于字节流的传输服务。尽管互联网上也有其他传输协议（如UDP），但TCP以其强大的可靠性保障，成为了绝大多数需要精确无误数据传输的应用首选。

本文将深入探讨TCP协议的方方面面，从它的基本概念、在网络中的位置，到其核心机制（连接管理、可靠性、流量控制、拥塞控制），以及它的报文结构和生命周期，力求让您“一文读懂”这个复杂的但又极其重要的协议。

1. TCP在网络协议栈中的位置

要理解TCP，首先需要将其放在整个网络协议栈中来看。我们常说的TCP/IP协议族，通常可以粗略分为四层（或五层，如OSI模型）：

1. 应用层 (Application Layer): 与用户直接交互的协议层，如HTTP（网页浏览）、FTP（文件传输）、SMTP（电子邮件）、SSH（安全远程登录）等。这些协议需要依赖下层协议来传输它们的数据。
2. 传输层 (Transport Layer): 负责在应用层进程之间提供端到端的通信服务。TCP和UDP（User Datagram Protocol）是这一层最主要的两个协议。它们将应用层数据分段，并加上端口号等信息，然后交给下层。
3. 网络层 (Internet Layer): 负责在不同的网络之间（主机到主机）传输数据包（IP数据报）。最核心的协议是IP（Internet Protocol）。IP只负责将数据包尽力而为地从源地址路由到目的地址，不保证可靠性、顺序或无重复。
4. 网络接口层 (Network Interface Layer): 也称为链路层，负责在直接相连的物理网络（如以太网、Wi-Fi）中传输数据帧。它处理与物理介质相关的细节。

TCP正位于传输层。 它的任务是接收应用层的数据，将其分割成适当大小的报文段（Segments），并加上TCP头部信息，然后将这些报文段向下传递给网络层（IP）。同时，它从网络层接收IP数据报，从中提取出TCP报文段，并根据报文段的信息，将数据有序、可靠地提交给相应的应用进程。

相比于同一层的UDP，TCP提供了以下核心特性，这也是它“可靠”的由来：

• 面向连接 (Connection-Oriented): 在数据传输之前，TCP需要通过“三次握手”建立一个连接；数据传输完成后，通过“四次挥手”终止连接。
• 可靠传输 (Reliable Transmission): 保证数据无丢失、无重复、按序到达。
• 字节流服务 (Byte-Stream Service): TCP不关心应用层数据的报文边界，它看作是一个无结构的字节流。发送方将字节流交给TCP发送，接收方TCP将收到的字节流按序交给应用进程，应用进程再自行解析字节流中的信息。
• 流量控制 (Flow Control): 协调发送方和接收方的数据发送速率，防止发送方发送过快导致接收方来不及处理而丢弃数据。
• 拥塞控制 (Congestion Control): 防止过多的数据注入网络，导致网络拥堵甚至崩溃。TCP会根据网络的拥塞状况动态调整发送速率。

2. TCP的核心机制

TCP之所以能提供可靠的服务，得益于其设计精巧的各种机制。

2.1 面向连接：三次握手建立连接

在TCP进行数据传输之前，通信双方（客户端和服务器）必须先建立一个逻辑连接。这个过程通常被称为“三次握手”（Three-Way Handshake）。

1. 第一次握手 (SYN): 客户端向服务器发送一个TCP报文段，其头部中的SYN（Synchronize Sequence Numbers）标志位设置为1，并携带一个初始序列号（Initial Sequence Number，ISN_c）。这个报文段表示客户端请求建立连接。

   • 报文：SYN=1, seq=ISN_c
   • 状态：客户端进入 SYN-SENT 状态。

2. 第二次握手 (SYN-ACK): 服务器收到客户端的SYN报文后，如果同意建立连接，会发送一个确认报文段。这个报文段的SYN和ACK（Acknowledgement）标志位都设置为1，携带服务器的初始序列号（ISN_s），并将确认号（Acknowledgment Number）设置为客户端发送的序列号加1（ISN_c + 1），表示已收到客户端的SYN。

   • 报文：SYN=1, ACK=1, seq=ISN_s, ack_num=ISN_c + 1
   • 状态：服务器进入 SYN-RECEIVED 状态。

3. 第三次握手 (ACK): 客户端收到服务器的SYN-ACK报文后，再次发送一个确认报文段。这个报文段的ACK标志位设置为1，将确认号设置为服务器发送的序列号加1（ISN_s + 1），表示已收到服务器的SYN-ACK。这个报文段可以携带数据（虽然通常不带）。

   • 报文：ACK=1, seq=ISN_c + 1, ack_num=ISN_s + 1 (这里的seq是基于客户端发送的数据量累积的，如果第三次握手不带数据，seq通常是ISN_c + 1，ACK报文本身不消耗序列号)
   • 状态：客户端进入 ESTABLISHED 状态。服务器收到这个ACK报文后，也进入 ESTABLISHED 状态。

至此，TCP连接建立成功，双方可以开始传输数据了。

为什么需要三次握手？

• 同步序列号: 双方都需要知道对方的初始序列号（ISN），以便后续进行可靠性控制（确认和重传）。第一次握手是客户端告诉服务器它的ISN，第二次握手是服务器告诉客户端它的ISN并确认收到客户端的ISN，第三次握手是客户端确认收到服务器的ISN。只有通过三次交互，双方才能完全同步彼此的ISN。
• 避免历史连接: 想象一下，如果只有两次握手。客户端发送SYN请求连接，由于网络延迟，这个SYN报文长时间滞留在网络中。客户端可能超时后重新发送SYN并成功建立了新的连接。过了一段时间，那个滞留的SYN报文到达服务器，服务器误认为这是一个新的连接请求，发送ACK确认。如果只有两次握手，连接就建立了。但客户端根本没有发送第二次SYN，它也不知道这个连接，会导致服务器白白维持一个无效的连接，并发送数据给一个不存在的连接。三次握手通过要求客户端对服务器的SYN-ACK进行确认（第三次握手），确保服务器知道客户端确实收到了第二次握手的信息，避免了“已失效的连接请求报文段”突然出现而建立连接的问题。

2.2 可靠传输：序列号、确认号与重传

TCP通过以下机制保证数据的可靠性：

• 序列号 (Sequence Number): TCP将发送的字节流看作一个序列，每个字节都有一个唯一的序列号。TCP报文段的seq字段指的是该报文段中数据部分的第一个字节在整个字节流中的序列号。这用于接收方对数据进行排序和检测丢失。
• 确认号 (Acknowledgment Number): TCP是全双工的，发送方和接收方都可以同时发送和接收数据。确认号表示接收方已经成功接收到数据流中按序的最后一个字节的序列号的下一个序列号。例如，如果确认号是 N，则表示接收方已经收到了序列号为 N-1 及其之前的所有数据。TCP使用累积确认（Cumulative Acknowledgment），一个确认号可以确认其之前所有已按序收到的数据。
• 定时器 (Timers): TCP为每个已发送但尚未确认的报文段设置一个重传定时器（Retransmission Timer）。
• 重传 (Retransmission): 如果在定时器到期之前没有收到对应报文段的确认，TCP就认为该报文段丢失了，会重新发送该报文段。

如何工作？

发送方发送数据时，给每个报文段分配序列号。接收方收到报文段后，如果数据是按序到达的，就发送一个确认报文段，将确认号设置为它期望收到的下一个字节的序列号。如果收到的数据不是按序的（乱序），接收方会先缓存这些乱序数据，并继续发送对已按序收到的数据的确认。当乱序数据之间的空隙被填补后，接收方会发送一个新的确认号，确认更大范围的数据。

如果发送方在设定的时间内没有收到确认，就会启动重传机制。TCP会动态调整重传定时器的超时时间（Retransmission Timeout，RTO），使其根据网络的往返时间（Round Trip Time，RTT）变化而变化，以提高效率。

除了基于超时的重传，TCP还有“快速重传”（Fast Retransmit）机制：当发送方收到同一报文段的三个或更多重复确认（Duplicate ACK）时，就认为该报文段很可能丢失了（而不是等待超时），立即重传丢失的报文段。这可以减少重传延迟，尤其是在网络拥塞不严重的情况下。

2.3 流量控制：滑动窗口协议

流量控制是为了防止发送方发送数据过快，导致接收方缓冲区溢出而丢弃数据。TCP通过滑动窗口协议实现流量控制。

• 接收窗口 (Receive Window): 接收方在其TCP报文段头部有一个Window Size字段，表示接收方当前还有多少空闲的接收缓冲区空间，也就是它还能接收多少字节的数据。这个值被称为接收窗口（rwnd）。
• 滑动窗口 (Sliding Window): 发送方维护一个发送窗口，它的大小取决于两个因素：接收方 advertised 的接收窗口大小（rwnd）和网络的拥塞状况（由拥塞窗口 cwnd 决定）。发送方被允许发送的数据范围由发送窗口决定。随着数据的发送和确认，发送窗口会在数据流上“滑动”。

如何工作？

接收方接收到数据后，会更新其接收缓冲区的使用情况，并在发送的确认报文段中告知发送方当前的接收窗口大小（rwnd）。发送方收到这个信息后，就调整自己的发送窗口大小，确保发送的数据量不超过接收方的处理能力。如果接收方缓冲区满了，它会通告一个零窗口（Window Size = 0），发送方收到后会停止发送数据，只发送小的探查报文段（Window Probe）以了解接收方窗口是否已恢复。

2.4 拥塞控制：避免网络崩溃

拥塞控制是为了防止过多的数据注入到网络中，导致路由器和链路拥堵，进而引发丢包、延迟增加，甚至网络崩溃。拥塞控制是一个全局性的问题，涉及网络中的所有主机。TCP通过调节发送方的发送速率来间接影响网络拥塞。

TCP主要通过以下几个阶段来实现拥塞控制：

• 慢启动 (Slow Start): 连接建立初期或发生超时重传后，TCP的发送速率会非常保守。拥塞窗口（Congestion Window，cwnd）从一个很小的值（通常1或2个MSS，Maximum Segment Size）开始，每收到一个确认，cwnd就指数级增长（通常是 cwnd = cwnd + MSS）。这使得发送速率快速提升，探测网络的承载能力。
• 拥塞避免 (Congestion Avoidance): 当cwnd达到慢启动阈值（ssthresh，初始值通常较大，或由上次发生拥塞时的cwnd决定）后，拥塞窗口的增长方式变为线性增长（每收到一个确认，cwnd通常只增加 MSS/cwnd 的大小，或者说，每经过一个RTT，cwnd增加一个MSS）。这个阶段相对温和，试图在不引起拥塞的前提下逐步提升速率。
• 快速重传 (Fast Retransmit): 前面已经提到，收到三个重复ACK时，立即重传丢失报文段。
• 快速恢复 (Fast Recovery): 快速重传发生后，TCP认为丢失的报文段可能是由于网络拥塞造成的。进入快速恢复阶段后，TCP不会像超时那样直接将cwnd降到很小，而是根据重复ACK的数量调整cwnd（通常将cwnd设置为 ssthresh + 3*MSS），然后线性增长，直到收到对所有已发送数据的确认。这样可以在不进入慢启动的情况下恢复数据传输，提高效率。

不同的TCP拥塞控制算法（如TCP Reno, TCP NewReno, TCP Cubic, BBR等）在这些阶段的具体行为和参数调整上有所不同，但基本思想都是根据网络反馈（丢包、延迟）动态调整发送速率，在网络容量和公平性之间取得平衡。

3. TCP报文头部结构

理解TCP的报文头部（Header）有助于理解其工作机制。一个TCP报文段由TCP头部和数据部分组成。TCP头部通常为20字节（不包含选项字段）。

0 16 31
+-------------------+-------------------+
| 源端口号 (Source Port) | 目的端口号 (Destination Port)|
+-------------------+-------------------+
| 序列号 (Sequence Number) |
+---------------------------------------------------+
| 确认号 (Acknowledgment Number) |
+-------------------+---+---+---+---+---+---+---+---+---+---+---+
| 数据偏移 (Data | | N | C | E | U | A | P | R | S | F | |
| Offset) | | S | W | C | R | C | S | S | Y | I | 窗口大小 |
| (4 bits) | R | R | R | E | G | K | H | T | N | N | (Window Size) |
| | | | | | | | | | | | |
+-------------------+---+---+---+---+---+---+---+---+---+---+---+
| 校验和 (Checksum) | 紧急指针 (Urgent Pointer) |
+---------------------------------------------------+
| 选项 (Options) (Variable) |
+---------------------------------------------------+
| 数据 (Data) (Variable) |
+---------------------------------------------------+

主要字段解释：

• 源端口号 (Source Port) 和 目的端口号 (Destination Port): 各占16位。用于标识发送方和接收方的应用进程。结合IP地址，可以唯一确定互联网上的一个TCP连接（一个socket通常由 (IP地址:端口号) 组成，一个连接由 (源IP:源端口) - (目的IP:目的端口) 唯一标识）。
• 序列号 (Sequence Number): 32位。如果SYN标志位是0，表示该报文段的数据部分的第一个字节的序列号。如果SYN标志位是1，则这是连接建立时的初始序列号（ISN），而数据部分的第一个字节的序列号是ISN+1。
• 确认号 (Acknowledgment Number): 32位。只有当ACK标志位为1时有效。它是期望接收到的下一个字节的序列号。
• 数据偏移 (Data Offset): 4位。表示TCP报文头部长度，以32位字（4字节）为单位。用于确定数据部分的起始位置。因为选项字段长度不固定，所以需要这个字段。最小值为5（即20字节头部），最大值为15（即60字节头部）。
• 保留字段 (Reserved): 6位，保留用于将来使用，目前必须为0。
• 标志位 (Flags): 9位（图中列出了常用的6个，RFC新增了NS, CWR, ECE）。
  • URG (Urgent): 紧急指针有效。
  • ACK (Acknowledgement): 确认号有效。
  • PSH (Push): 请求立即将数据推送到应用层，而不是等待缓冲区满。
  • RST (Reset): 重置连接。通常用于异常终止连接。
  • SYN (Synchronize): 同步序列号，用于建立连接。
  • FIN (Finish): 发送方已完成数据发送，请求终止连接。
• 窗口大小 (Window Size): 16位。用于流量控制，表示从确认号开始，接收方当前还能接收的字节数。
• 校验和 (Checksum): 16位。对整个TCP报文段（头部+数据）和部分伪头部（Pseudo Header，包含源IP、目的IP、协议号、TCP长度）进行校验，用于检测报文段在传输过程中是否发生错误。
• 紧急指针 (Urgent Pointer): 16位。当URG标志位为1时有效，表示紧急数据在数据部分中的偏移量。允许接收方优先处理紧急数据。
• 选项 (Options): 可变长度。常见的选项有最大报文段大小（MSS）、窗口扩大因子（Window Scale，用于支持大于65535字节的窗口）、时间戳（Timestamp，用于计算RTT和防止序号回绕）等。
• 数据 (Data): 应用层数据。

4. TCP连接的生命周期：从建立到终止

TCP连接的状态机是理解其生命周期的关键。一个连接从无到有，经历数据传输，最终到终止，会经过一系列的状态变迁。

4.1 连接建立 (三次握手状态)：

1. CLOSED: 初始状态，表示连接未激活。
2. LISTEN: 服务器端等待来自远程TCP端口的连接请求。
3. SYN-SENT: 客户端发出连接请求（SYN），等待服务器确认。
4. SYN-RECEIVED: 服务器收到并发送了连接确认（SYN-ACK），等待客户端的确认。
5. ESTABLISHED: 连接已建立，可以进行数据传输。

4.2 数据传输状态：

连接在ESTABLISHED状态下进行数据传输。双方可以发送和接收数据报文段。

4.3 连接终止 (四次挥手状态)：

当一方（无论是客户端还是服务器）完成数据发送后，可以请求关闭连接。这个过程通常需要“四次挥手”（Four-Way Handshake），因为TCP是全双工的，一端的关闭发送流并不影响另一端的发送流。

1. 第一次挥手 (FIN): 发送方（假设是客户端）完成数据发送，向对方发送一个报文段，其FIN（Finish）标志位设置为1，表示它已经没有数据要发送了，但仍然可以接收数据。

   • 报文：FIN=1, seq=u (u是FIN报文段之前最后一个字节的序列号+1)
   • 状态：客户端进入 FIN-WAIT-1 状态。

2. 第二次挥手 (ACK): 接收方（服务器）收到FIN报文后，发送一个确认报文段。其ACK标志位设置为1，确认号设置为接收到的FIN报文段的序列号加1 (u + 1)。这表示服务器已经收到了客户端的关闭请求，但服务器可能还有数据要发送。

   • 报文：ACK=1, seq=v, ack_num=u + 1 (v是服务器已发送的最后一个字节序列号+1)
   • 状态：服务器进入 CLOSE-WAIT 状态。此时，客户端到服务器的连接已经关闭，服务器不再接收客户端发送的数据（除了可能的ACK），但服务器仍然可以向客户端发送数据。客户端进入 FIN-WAIT-2 状态，等待服务器发送最后的FIN报文。

3. 第三次挥手 (FIN): 服务器完成数据发送后，向客户端发送一个FIN报文段，表示它也没有数据要发送了，准备关闭连接。

   • 报文：FIN=1, seq=w, ack_num=u + 1 (w是服务器这边发送的FIN报文段的序列号)
   • 状态：服务器进入 LAST-ACK 状态，等待客户端对服务器的FIN进行确认。

4. 第四次挥手 (ACK): 客户端收到服务器的FIN报文后，发送一个确认报文段。其ACK标志位设置为1，确认号设置为接收到的服务器FIN报文段的序列号加1 (w + 1)。

   • 报文：ACK=1, seq=u + 1, ack_num=w + 1
   • 状态：客户端收到服务器的FIN并发送ACK后，进入 TIME-WAIT 状态。服务器收到客户端的ACK后，进入 CLOSED 状态。

为什么需要TIME-WAIT状态？

客户端在发送完最后一个ACK后，进入TIME-WAIT状态，而不是立即进入CLOSED状态。TIME-WAIT状态会持续一段固定的时间（通常是2*MSL，Maximum Segment Lifetime，最大报文段生存时间），MSL是指报文段在网络中的最大生存时间。

TIME-WAIT状态存在的两个主要原因：

1. 保证最后一个ACK报文能够到达服务器: 如果客户端发送的最后一个ACK报文丢失，服务器将停留在LAST-ACK状态，并超时重传其FIN报文。客户端处于TIME-WAIT状态时，如果收到服务器重传的FIN报文，会重新发送ACK报文，并重置TIME-WAIT定时器。这样确保服务器最终能够收到ACK，正常关闭连接。
2. 防止“已失效的连接请求报文段”干扰新的连接: 如果不经过TIME-WAIT直接关闭，很快又有一个新的连接建立起来，而这个新连接使用了与之前连接相同的源IP、目的IP、源端口、目的端口。如果在网络中仍然存在前一个连接的延迟报文段，这些报文段到达后可能会被新的连接错误接收。TIME-WAIT状态持续2*MSL，确保在一个连接关闭后，该连接持续期间产生的所有报文段都已经在网络中消失，不会对后续使用相同四元组的新连接造成干扰。

4.4 异常终止：RST

如果发送方或接收方检测到异常情况（如端口不可达、收到无效的报文段），或者希望立即终止连接而不进行正常的四次挥手，可以发送一个RST（Reset）标志位为1的报文段。收到RST报文的一方会立即终止连接，不进行任何清理或等待。RST连接是非正常的，可能导致数据丢失。

5. TCP与UDP的比较

作为传输层的两个主要协议，TCP和UDP服务于不同的应用场景。

特性	TCP	UDP
连接性	面向连接（需三次握手建立）	无连接（直接发送数据）
可靠性	可靠传输（保证数据不丢、不重、有序）	不可靠传输（尽力而为，不保证）
顺序性	有序	无序
传输方式	字节流	数据报文（保留报文边界）
速度	相对较慢（有连接建立、确认、重传等开销）	相对较快（开销小）
头部大小	20字节 + 选项	8字节
流量控制	有	无
拥塞控制	有	无（或由应用层实现）
适用场景	需要可靠传输的应用（文件传输、网页浏览、邮件）	对实时性要求高，允许少量丢包的应用（语音通话、视频直播、在线游戏、DNS）

TCP的可靠性和控制机制使其适用于对数据完整性和顺序性要求高的应用，但会引入额外的延迟和开销。UDP则提供了更快的传输速度和更低的开销，适用于对实时性要求高但允许一定丢包的应用。

6. TCP的典型应用

TCP广泛应用于各种互联网协议中，因为它们需要可靠的数据传输：

• HTTP/HTTPS: 网页浏览，需要可靠获取页面内容。
• FTP: 文件传输，需要文件内容完整无误。
• SSH: 安全远程登录，需要命令和数据准确传输。
• SMTP/POP3/IMAP: 电子邮件，需要邮件内容不丢失。
• Telnet: 远程终端，需要字符准确传输。

7. 总结

TCP作为互联网传输层最核心的协议之一，以其可靠性、面向连接、流量控制和拥塞控制等特性，为上层应用提供了稳定、可靠的数据传输服务。通过三次握手建立连接、四次挥手终止连接，利用序列号、确认号和重传机制保证数据可靠性，借助滑动窗口进行流量控制，并通过慢启动、拥塞避免等算法进行拥塞控制，TCP在复杂且不可靠的互联网环境中构建了一个可靠的通信信道。

理解TCP的工作原理，不仅是网络工程师的基础，对于任何涉及网络编程或系统优化的开发者也至关重要。尽管现代网络环境和应用需求也在催生新的传输协议（如QUIC），但TCP作为互联网近三十年的基石，其设计思想和实现机制仍然具有极其重要的价值和影响力。

希望通过本文，您对TCP有了更深入、更全面的认识。

---