深入理解 TCP 连接终止：为什么需要四次握手？

2026-02-13 22:04:20 0条评论 1次阅读 0人点赞

在日常的网络编程和运维工作中，我们经常需要与 TCP/IP 协议族打交道。作为互联网通信的基石，TCP（传输控制协议）为我们提供了可靠、面向连接的字节流传输服务。无论你是开发一个高性能的 Web 服务器，还是调试一个复杂的微服务调用链，深入理解 TCP 的连接建立与终止机制都是至关重要的。

在这篇文章中，我们将重点探讨一个经典且经常被问到的问题：为什么 TCP 连接的终止需要“四次握手”，而建立连接只需要“三次握手”？ 我们将不仅从协议层面分析原因，还会通过实际的代码示例和抓包结果，帮助你彻底搞懂这一机制背后的设计哲学。

TCP 连接建立的三次握手：简短回顾

为了理解连接的终止，我们首先需要快速回顾一下 TCP 是如何建立连接的。TCP 是一种面向连接的、全双工的协议。这意味着数据可以在客户端和服务器之间同时双向传输。为了确保这种双向通信的可靠性，连接建立阶段必须协商双方的初始序列号。

我们可以通过以下三个步骤来完成这一过程（即经典的三次握手）：

SYN（同步）：客户端向服务器发送一个 SYN 数据包，表明客户端希望建立连接，并包含客户端的初始序列号。此时客户端进入 SYN_SENT 状态。
SYN + ACK（同步与确认）：服务器收到 SYN 包后，需要确认收到（ACK），同时也发送自己的 SYN 请求（包含服务器的初始序列号）。这是通过一个数据包完成的（SYN+ACK）。服务器进入 SYN_RCVD 状态。
ACK（确认）：客户端收到服务器的 SYN+ACK 包后，向服务器发送一个 ACK 包进行确认。此包发送后，客户端进入 INLINECODE26b44cd3 状态；服务器收到此包后也进入 INLINECODE532b8d8a 状态。此时，双向连接正式建立。

让我们通过一个简单的 Python Socket 编程示例来看看这个过程在实际代码中是如何体现的，以及序列号是如何协商的。

#### 代码示例 1：理解三次握手中的序列号协商

在底层，TCP 的实现细节（如 Wireshark 抓包所示）会处理具体的 ISN（初始序列号），但在应用层，我们主要关注连接的建立。

# 这是一个简化的 TCP 客户端连接逻辑演示
import socket

# 创建一个 TCP/IP 套接字
# 注意：在内核底层，socket() 调用只是准备了数据结构，并未发送数据
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# 定义服务器地址
server_address = (‘localhost‘, 8080)

print(f"正在尝试连接到 {server_address}...")

# ---- 这一步触发了三次握手 ----
# 1. 客户端发送 SYN
# 2. 客户端接收 SYN+ACK，发送 ACK
sock.connect(server_address)

print("连接已建立 (TCP ESTABLISHED)")

try:
    # 发送数据
    message = b"Hello, TCP Server!"
    sock.sendall(message)
    print(f"已发送数据: {message}")

    # 接收响应
    data = sock.recv(1024)
    print(f"收到响应: {data.decode(‘utf-8‘)}")

finally:
    print("准备关闭连接...")
    sock.close()

在这个例子中，当你调用 sock.connect() 时，操作系统内核会自动处理底层的三次握手。如果你的网络环境较慢（比如高延迟网络），你会发现这行代码会有明显的阻塞时间，这实际上就是在等待握手完成。

TCP 连接终止的核心：为什么需要四次握手？

现在，让我们进入本文的核心。当数据传输完成后，我们需要关闭连接。由于 TCP 是全双工（Full-Duplex）的协议，这意味着数据可以在两个方向上独立地传输。因此，连接的终止也需要分两个方向分别处理。

这就是为什么我们需要四次握手的根本原因：“连接终止”实际上是两个独立方向的“数据流关闭”过程的组合。

我们可以把这看作是两个互不相干的过程：

客户端到服务器的数据流关闭。
服务器到客户端的数据流关闭。

当一方（比如客户端）决定不再发送数据时，它会发送一个 FIN（Finish）包。但这并不意味着客户端不能接收数据了。此时，客户端进入 FIN_WAIT_1 状态。这就好比你打了一个电话给朋友，你说：“我说完了（FIN）”，但朋友可能还有话要对你说，所以你仍然需要听他说。

让我们详细拆解这四个步骤：

#### 第一次握手：主机 A → 主机 B（FIN）

动作：主机 A（通常是客户端）向主机 B 发送一个 TCP 报文段，其中 FIN 标志位被置为 1。
含义：这表示主机 A 没有数据要发送了，请求关闭本方向的连接。
状态变化：主机 A 进入 FIN_WAIT_1 状态。

#### 第二次握手：主机 B → 主机 A（ACK）

动作：主机 B 收到 FIN 报文段后，必须立即确认。它发送一个 ACK 报文段，确认序号是收到的 FIN 序号加 1。
含义：主机 B 告诉主机 A：“我收到了你关闭连接的请求，我知道你不会再给我发数据了。” 此时，主机 A 到主机 B 的连接关闭。
状态变化：主机 A 收到这个 ACK 后，进入 INLINECODE6ada340e 状态。主机 B 进入 INLINECODEa0635e81 状态。

> 关键技术点：这里之所以是两次（FIN 和 ACK），是因为主机 B 可能还有数据要发送给主机 A。TCP 协议的设计允许这种半关闭状态。主机 B 在发送 ACK 后，依然可以向主机 A 发送剩余数据，直到主机 B 也准备好关闭连接为止。

#### 第三次握手：主机 B → 主机 A（FIN）

动作：当主机 B 也发送完了所有剩余数据，它也想关闭连接时，它会发送一个 FIN 报文段给主机 A。
含义：“我现在也没话说了，我也要关了。”
状态变化：主机 B 进入 LAST_ACK 状态。

#### 第四次握手：主机 A → 主机 B（ACK）

动作：主机 A 收到主机 B 的 FIN 报文段后，发送一个 ACK 报文段进行确认，确认序号是收到的 FIN 序号加 1。
含义：“好的，收到，再见。”
状态变化：主机 A 收到这个 ACK 后（或者更准确地说，在发送完 ACK 后），进入 INLINECODEf91424cb 状态。主机 B 收到 ACK 后，进入 INLINECODEb795e8ab 状态。主机 A 需要等待 2MSL（最大报文生存时间）后，才最终关闭连接，确保最后的 ACK 能到达对方。

#### 为什么不是三次？

你可能会问，为什么不能像建立连接时那样，把中间的 ACK 和 FIN 合并成一个包呢？

建立连接时：当服务器收到客户端的 SYN 时，服务器既可以发送 SYN（建立服务器到客户端的连接），也可以发送 ACK（确认客户端的 SYN）。这两种状态可以立即在同一个数据包（SYN+ACK）中完成，因为服务器通常一建立连接就准备好了发送数据。
终止连接时：当主机 A 发送 FIN 时，主机 B 回复 ACK 只是确认了“我不指望你给我发数据了”。但是，主机 B 可能还有未发完的应用层数据。因此，主机 B 必须先发送 ACK 告诉 A “我知道了”，然后继续发送数据，等数据处理完毕后，才能发送自己的 FIN。这就导致了 ACK 和 FIN 通常分开发送，因此变成了四次。

实战代码：理解半关闭状态

为了验证这种机制，我们编写一段代码，模拟服务端在收到客户端的 FIN 后，继续发送数据的过程。这是理解四次握手的关键。

#### 服务端代码：被动关闭并坚持发送数据

import socket
import time

server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind((‘localhost‘, 65432))
server_socket.listen(1)
print("服务器正在监听端口 65432...")

conn, addr = server_socket.accept()
print(f"连接来自: {addr}")

try:
    while True:
        data = conn.recv(1024)
        if not data:
            print("客户端发送了 FIN (连接关闭请求)")
            # 注意：这里的 recv 会返回空，通常意味着对方发送了 FIN 或关闭了套接字
            # 在底层，TCP 栈已经自动发送了 ACK 给客户端
            break
        print(f"收到: {data.decode()}")
        
except Exception as e:
    print(f"错误: {e}")
finally:
    # 这里的代码模拟服务器在客户端关闭连接后，继续处理并发送剩余数据
    # 此时处于 CLOSE_WAIT 状态
    print("服务器收到客户端关闭请求，正在准备发送剩余数据...")
    time.sleep(1)
    # 在这里尝试发送数据可能会失败，取决于 Socket 配置和操作系统实现
    # 但在协议层面，这是允许的。如果 Socket 设置为 SHUT_RD，仍可发送。
    # 正常的 socket.close() 会发送 FIN
    print("服务器关闭连接 (发送 FIN)")
    conn.close() # 发送 FIN
    server_socket.close()

#### 客户端代码：主动发起关闭

import socket
import time

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((‘localhost‘, 65432))

# 发送一条数据
sock.sendall(b"Hello Server")

# 主动关闭连接的写方向
# 这一步会导致发送一个 FIN 包给服务器
sock.shutdown(socket.SHUT_WR)
print("客户端: 已发送 FIN (SHUT_WR)")

# 此时客户端仍然可以接收数据
print("客户端: 等待服务器的剩余消息...")

# 注意：由于上面的服务器代码在 recv 到空数据后立即 break 了，
# 所以它不会回发数据。如果服务器没有 break，而是继续 send，
# 客户端仍可在这里接收。
try:
    data = sock.recv(1024)
    if data:
        print(f"收到数据: {data.decode()}")
except:
    pass

sock.close()
print("客户端: 连接完全关闭")

状态机详解与常见问题

理解四次握手后，我们在实际开发和排查故障时，经常会遇到与状态转换相关的问题。让我们看看两个最常见的现象。

#### 1. CLOSE_WAIT 状态过多

作为开发者，你一定遇到过这种情况：服务器监控报警显示大量 TCP 连接处于 CLOSE_WAIT 状态。这是为什么呢？

原因：CLOSE_WAIT 状态意味着“对方已经发送了 FIN，我已经回复了 ACK，但我自己还没准备好发送我的 FIN”。

换句话说，是你的应用程序没有正确关闭连接。通常是代码中忘记了调用 INLINECODE31014e8b 或 INLINECODEd68808af，或者在处理完请求后没有释放资源。这导致连接一直悬在这个状态，直到操作系统超时回收。

解决代码示例：确保在所有代码路径（包括异常处理）中关闭连接。

# 最佳实践：使用 try...finally 或 with 语句
def handle_client(client_socket):
    try:
        # 处理业务逻辑
        data = client_socket.recv(1024)
        # ... 逻辑 ...
    except Exception as e:
        print(f"Error: {e}")
    finally:
        # 无论如何都要调用 close，发送 FIN
        client_socket.close()

#### 2. TIME_WAIT 状态与 2MSL 等待

你可能注意到，在四次握手的最后，主动关闭连接的一方（通常是客户端）会进入 TIME_WAIT 状态，并持续 2MSL（大约 1 到 4 分钟）。

为什么需要这个状态？

确保最后一个 ACK 能到达：如果服务器没有收到最后的 ACK，它会重发 FIN。如果客户端直接关闭了，就无法再次回复 ACK 了，导致服务器无法正常关闭。
让旧的数据包消失：网络中可能残留有延迟的数据包。等待 2MSL 可以确保网络中旧的连接的所有数据包都失效了，防止新的连接收到旧连接的数据包（造成数据混乱）。

实战建议：在高并发的服务器中（例如 Nginx），大量的 INLINECODEb42126c7 可能会消耗系统资源。通常通过调整内核参数（如 INLINECODEbb512843）来优化，允许将处于 TIME_WAIT 的连接复用于新的连接，而不是强制等待。

总结与优化建议

通过这篇文章，我们深入探讨了 TCP 连接终止的机制。记住，TCP 的可靠性是建立在复杂的握手和状态管理之上的。四次握手的核心在于 TCP 的全双工特性，它要求双方分别关闭自己的发送通道。

#### 关键要点回顾

四次握手 = 两次独立的关闭：一次是客户端告诉服务器“我不发了”，另一次是服务器告诉客户端“我也不发了”。中间可能有数据传输。
FIN 是代表“没有数据发送了”，这并不代表不能接收数据，这就是“半关闭”状态。
代码层面要重视状态管理：避免 INLINECODE112685bf 漏洞，合理配置 INLINECODEc51c42a0 参数。

#### 实战后续步骤

抓包实践：建议你使用 Wireshark 亲自抓取一次 HTTP 请求的结束过程，观察 FIN 和 ACK 包的序列号变化，这比看任何文章都直观。
压力测试：观察你的服务器在处理大量连接时，TIME_WAIT 占用情况，并根据需要进行内核调优。

理解这些底层原理，将帮助你在面对网络延迟、连接泄露等棘手问题时，能够从容地分析并找到根本原因。希望这篇文章能让你对 TCP 的四次挥手有更清晰的认知！

投稿给我们	如何建站？
vps是什么？	如何安装宝塔？
如何通过博客赚钱？	便宜wordpress托管方案
免费wordpress主题	这些都是免费方案

豆丁博客