Python socket TCP连接关闭时客户端未正确响应FIN ACK问题

你观测到的3报文关闭序列不是程序错误，是TCP协议栈的*捎带确认（Piggybacking ACK）*优化导致的：
当服务端发送的FIN+ACK到达客户端内核后，内核会受延迟ACK机制影响，不会立刻回传ACK；当你的代码调用recv()读到0长度返回值时，才感知到服务端已经关闭了发送方向，此时你直接跳出循环，没有做任何显式的关闭操作，Python解释器会在后续回收socket对象时隐式调用close()，触发客户端发送自己的FIN包。这时候内核发现自己还有一个待发送的对服务端FIN的ACK，就直接把ACK标识位挂到了要发的FIN包上，合并成一个FIN+ACK报文发送，最终就形成了你看到的3包交互。
这个交互完全符合TCP协议规范，不会造成数据丢失、连接异常，和标准四次挥手的可靠性完全一致。

如果你的场景（比如协议测试、特殊网络设备适配）必须严格匹配四次挥手的报文序列，需要拆分TCP半关闭流程，不要让内核把ACK和FIN合并发送，调整后的代码如下：

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((ip_address, port))
# 开启快速确认模式，禁用延迟ACK，减少报文合并概率
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_QUICKACK, 1)
# 建议设置关闭阶段超时，避免异常网络下永久阻塞
s.settimeout(10)

# ... 原有接收业务数据包的逻辑 ...

# 等待服务端主动发起关闭
while True:
    new_msg = s.recv(1024)
    if len(new_msg) == 0:
        # 第一步：收到服务端FIN，先关闭读方向，触发内核立即发送对应ACK
        s.shutdown(socket.SHUT_RD)
        # 极短等待确保ACK已经从网卡发出，可根据实际系统调优
        time.sleep(0.001)
        # 第二步：关闭写方向，触发客户端发送自身的FIN包
        s.shutdown(socket.SHUT_WR)
        break

# 等待服务端返回最后一个ACK，完成全双工关闭
try:
    while s.recv(1024):
        pass
except:
    # 超时或者连接报错直接退出即可
    pass
# 显式关闭socket释放文件描述符
s.close()

调整后再抓包就能看到标准的四次挥手序列：服务端FIN+ACK -> 客户端单独ACK -> 客户端FIN+ACK -> 服务端ACK。

• 非必要不要强制修改为四次挥手：捎带确认是TCP的标准优化，能减少网络中的空报文数量，降低双方网络开销，生产环境下完全可以直接使用你最初的代码逻辑，不会有任何稳定性问题。
• 永远不要依赖隐式回收关闭socket：不管用什么关闭逻辑，最后一定要显式调用close()，避免出现文件描述符泄漏、TIME_WAIT状态异常堆积的问题。
• 关闭阶段一定要设置超时：网络抖动、服务端异常宕机都可能导致FIN报文丢失，没有超时的话recv()会永久阻塞，造成业务线程卡死。
• 不要在应用层尝试“模拟”TCP握手、挥手逻辑：所有可靠性保证由内核协议栈完成，应用层只需要处理好数据收发、资源释放即可。

内容的提问来源于stack exchange，提问作者Alex