TCP 三次握手和四次挥手是网络面试里绕不开的经典题也是很多 Python 开发者在准备后端、爬虫、量化交易这类岗位时容易卡壳的地方。说实话这个东西背答案不难难的是真正理解每一个标志位为什么存在、为什么是这个顺序、缺一步会怎样。这篇就来把三次握手和四次挥手的完整流程、背后的设计逻辑、以及面试官真正想听到的细节全部拆开讲清楚。1. 三次握手与四次挥手整体解读1.1 这道题在 Python 面试中的真实定位很多候选人把三次握手当作“背八股文”来准备背得滚瓜烂熟但一到追问环节就露馅了。作为一个面试过不少 Python 候选人的从业者我明确告诉你面试官问这道题看的不是你背诵的能力而是你对“网络通信为什么被设计成这样”的理解深度。这道题在 Python 岗位面试中出现频率极高几乎每个跟网络沾边的岗位都会问比如爬虫工程师、后端开发、量化交易系统的开发者。为什么因为 Python 的很多核心应用场景都建立在 TCP 之上——requests 库爬网页底层是 TCPasyncio 写异步服务底层是 TCPRedis 客户端、MySQL 驱动这些全部跑在 TCP 上。如果你的程序出现连接超时、频繁断开、端口占用不懂 TCP 协议你连排查的思路都没有。面试官对这道题的考察点通常分三个层次第一层是基础记忆你能不能准确说出三次握手和四次挥手的过程、涉及的状态、标志位第二层是原理理解你能不能说清楚为什么必须是三次而不是两次或四次为什么挥手要四次第三层是工程落地你能不能结合 Python 的 socket 编程或实际项目说明这些机制怎么影响你的代码比如为什么服务端经常出现 TIME_WAIT为什么客户端重连会报“地址已在使用”。你准备面试的时候建议按照这三个层次依次过关。这篇文章会以尽量通俗的方式把三个层次的内容都覆盖到。1.2 一个比喻快速建立直观印象在深入细节之前先给你一个生活化的类比后面所有技术细节你都可以映射回这个比喻。想象你和朋友约好一起徒步。三次握手就是出发前的确认环节第一次你说“喂我准备出发了你能听到吗”SYN同步序列号第二次朋友回答“我听到你了我也准备好出发了”SYNACK同时把自己的状态同步给你第三次你回应“收到你的回复那我们就正式出发”ACK确认建立连接在真正的通信世界里第一句话告诉对方“我的讲话从哪个编号开始”第二句话带着“我听到了你的编号这是我的编号”第三句话表示“我也听到了你的编号”。只有双方都确认“你能听到我我也能听到你”通话才正式开始。四次挥手就是结束时的道别环节你说“我今天聊完了准备挂电话了”FIN朋友回“好的我听到了不过我还有几句话要说”ACK朋友说完所有话后说“我也说完了可以挂了”FIN你回“好的收到我挂了啊”ACK生活中道别要互相确认“你说完了、我说完了”网络里也是一样。半关闭状态的存在是四次挥手最核心的设计意图。2. 三次握手全流程解析2.1 三次握手的完整交互过程与状态变化三次握手是 TCP 建立连接时必须经历的过程。它发生在客户端和服务端之间涉及三种报文SYN、SYNACK、ACK。下面按时间顺序把每一步拆开看。第一步客户端发送 SYN 报文客户端主动调用connect()函数时操作系统会向服务端发送一个 SYN 报文。这个报文的主要作用有两个告诉服务端“我想和你建立连接”以及同步客户端的初始序列号。这个初始序列号不是固定的而是由一个定时器驱动的计数器生成每次连接都不同。在 Linux 系统中这个初始序列号由/proc/sys/net/ipv4/tcp_syncookies相关的机制和内核随机算法共同决定并不是很多人以为的“固定从 0 开始”。发送完成后客户端进入SYN_SENT状态等待服务端的回应。第二步服务端回复 SYNACK服务端收到 SYN 报文后如果接受这个连接请求会同时完成两件事对客户的 SYN 进行确认ACK保证“我收到了你的初始序列号我们以此为基准”同时向客户端发送自己的 SYN同步服务端的初始序列号。为什么这两件事要合并成一个报文而不是分开两个因为这是一个极其常见但常被忽略的面试考点。合并发送可以让整个握手过程少一个报文往返这在网络工程里叫“捎带确认”piggybacking。既然服务端本来就要回复一个 ACK 给客户端又要发送一个 SYN 给客户端完全可以在同一个报文里带上两个标志位这就是 SYNACK 报文的由来。发送完成后服务端进入SYN_RCVD状态。第三步客户端发送 ACK 确认客户端收到 SYNACK 报文后需要再回复一个单纯的 ACK 报文。这个 ACK 的作用是确认服务端的初始序列号让服务端知道“客户端已经把序列号同步好了”。发送完成后客户端进入ESTABLISHED状态此时客户端可以从这个连接上发送和接收应用数据了。服务端收到这个 ACK 后也进入ESTABLISHED状态。到这里一条双向通信的连接才真正建立完毕。等等这里有个细节值得注意客户端在发送第三个 ACK 之后就进入了ESTABLISHED状态但服务端要等到收到这个 ACK 才能进入ESTABLISHED。也就是说严格来说客户端比服务端“早一点点”认为连接建立完成。这个不对称性会影响后面很多东西比如客户端可以在第三次握手的 ACK 里直接捎带应用数据但服务端不行。这个捎带数据的特性叫“TCP Fast Open”TFO的基础变种在 Linux 上可以通过TCP_FASTOPENsocket 选项开启。面试中提到这一点能明显加分但要注意传统三次握手的第三个 ACK 理论上是允许携带数据的而第一个和第二个报文因为还没完成握手不允许携带应用数据。2.2 三次握手中的核心字段与标志位三次握手涉及的关键字段需要准确掌握这是面试最基本的底气。SYN 标志位表示“同步序列号”它在握手时置 1表示这个报文是连接请求或者连接接受报文。FIN 标志位表示“发送方数据已发送完毕希望断开连接”。ACK 标志位表示“确认号有效”。三次握手的核心是序列号与确认号的协作机制。每次通信有自己的序列号Sequence Number和确认号Acknowledgment Number。我举个例子假设客户端选择的初始序列号是 1000服务端的初始序列号是 5000。那么客户端发 SYN(seq1000)表示“我的数据流从 1000 开始编号”服务端回 SYNACK(seq5000, ack1001)表示“我收到了你的 1000下一条我要收 1001我的数据流从 5000 开始编号”客户端回 ACK(seq1001, ack5001)表示“我收到了你的 5000下一条我要收 5001”这里有一个很多新手想不通的问题为什么 ack 是对方的初始序列号 1因为 SYN 报文本身要占用一个序列号所以确认号必须是对手序列号 1。这个“SYN 占一个序号”的细节在计算 seq 和 ack 关系时特别容易出错面试手撕这道题时要注意。另外还有一个必知的基础知识TCP 头部有 20 字节固定长度标志位中 URG、ACK、PSH、RST、SYN、FIN 六个各有各的用途。三次握手用到 SYN 和 ACK四次挥手用到 FIN 和 ACK。数据完整性方面TCP 有校验和机制这里不展开。2.3 结合 Python 观察三次握手的过程如果你准备 Python 相关岗位最好能亲自验证一次三次握手。不需要复杂工具Python 标准库的 socket 模块就能帮你做实验。# 服务端代码 server.py import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((127.0.0.1, 8888)) server.listen(5) conn, addr server.accept() print(f接收到连接: {addr}) data conn.recv(1024) print(f收到数据: {data.decode()}) conn.send(bhello from server) conn.close() server.close()# 客户端代码 client.py import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 8888)) client.send(bhello from client) data client.recv(1024) print(f收到数据: {data.decode()}) client.close()在 Linux 上跑这两段代码然后开一个终端执行tcpdump -i lo port 8888你能清清楚楚地看到三次握手的三个包。这里我提一个实测经验很多人不知道SO_REUSEADDR这个 socket 选项对调试有多重要。如果没有设置它你关掉服务端后再立刻重启大概率会遇到Address already in use。原因在于前一个服务端关闭时连接进入 TIME_WAIT 状态端口还被内核占用。设置SO_REUSEADDR可以让新起进程重用这个端口极大减少本地调试的烦恼。在面试中主动提一句这个选项说明你有实战经验。$ python3 server.py $ python3 client.py $ sudo tcpdump -i lo port 8888 -nn 22:09:15.123456 IP 127.0.0.1.12345 127.0.0.1.8888: Flags [S], seq 1000 22:09:15.123457 IP 127.0.0.1.8888 127.0.0.1.12345: Flags [S.], seq 5000, ack 1001 22:09:15.123458 IP 127.0.0.1.12345 127.0.0.1.8888: Flags [.], ack 5001从这个调试信息里你能看到晦涩的东西变成了活生生的过程Flags [S] 是 SYN[S.] 是 SYNACK[.] 是纯 ACK。这一步可以作为你复习的收尾动作记忆会更加牢固。3. 为什么需要三次而不是两次或四次3.1 两次握手的致命缺陷历史报文段问题面试官最爱问的追问之一就是“为什么不能只握手两次”。这个问题的答案用一句话概括就是两次握手无法避免历史报文段带来的连接混乱。什么叫历史报文段我举一个具体场景。客户端先尝试连接服务端发送了一个 SYN 报文但网络极度拥塞这个 SYN 报文被堵在了路上。客户端等了一段时间没有收到任何回复以为连接失败了于是重新发起连接发了一个新的 SYN这次网络通畅连接很快就建立了双方通信完毕连接正常关闭。但是那个被堵在路上的旧 SYN 报文并没有消失它只是被延缓了。在旧连接关闭之后它终于到达了服务端。此时服务端收到一个看上去合法的 SYN如果只有两次握手服务端会认为客户端想建立新连接于是回复 SYNACK服务端进入 ESTABLISHED开始为这个假连接分配资源、维持状态、等待数据。问题来了客户端根本没有发起这次新连接它收到服务端的 SYNACK 后会判断出“这不是我发起的连接”于是回复 RST 报文拒绝。服务端这才发现出了问题。但在这个过程里服务端已经为了一个假连接白白分配了内核资源和状态。如果恶意攻击、或者网络状况很差导致大量历史报文积压服务端就会被这种无效连接消耗大量的内存和 CPU。三次握手可以彻底解决这个问题。第三次的 ACK 报文就是客户端的最终裁决。客户端在发出第二个 SYN 后如果在合理时间内收到服务端的 SYNACK会检查这个 SYNACK 里的确认号是不是自己最新 SYN 的序列号 1如果不是就说明是历史报文引起的响应客户端直接发 RST这个假连接在服务端进入 ESTABLISHED 之前就被杀掉了。换句话说第三次握手保证了“客户端确认这条连接是我当前想要的那条”而不是一条陈旧的幽灵连接。这是我面试时最爱深挖的角度因为能讲清楚历史报文问题说明你真理解了三次握手不是为了“礼貌”而是为了“防呆”。3.2 两次握手无法同步双方初始序列号再深挖一层。TCP 是一个可靠传输协议可靠性建立在序列号机制上。双方必须知道对方的初始序列号才能正确组装数据、去重、去乱序。三次握手承担了同步双方初始序列号的任务。握手必须完成四件事才能建立可靠的全双工连接客户端确认服务端能收到自己的报文服务端确认客户端能收到自己的报文客户端确认服务端能收到自己的初始序列号服务端确认客户端能收到自己的初始序列号如果用两次握手假设客户端发 SYN(seq1000)服务端回 SYNACK(seq5000, ack1001)。此时服务端确定地知道客户端能收到自己的报文因为客户端只有收到 SYNACK 才会进入下一步但这个前提是服务端能收到客户端的 SYN客户端也知道服务端发来的报文路径是通的。但客户端是否收到了服务端的 SYN服务端并不知道。只有等客户端回第三个 ACK服务端才能确定客户端已经接收到自己的初始序列号。你可以看到三次握手每一步都有明确的功能归属第一次让服务端确认客户端“在线”第二次让客户端确认服务端“在线”并把自己的序列号同步过去第三次让服务端确认客户端已经知道自己“在线”——双方初始序列号双向同步完毕。3.3 为什么不握手四次或更多次理解了为什么不能两次你自然会问那为什么不干脆四次五次原因也很直接三次已经能够达到双向通信确认的目的再来更多次只是在重复确认已经确认过的信息纯属浪费。一次完整的数据往返需要时间每加一次握手就多一个 RTT往返时延的开销对于远距离网络这是巨大的性能损耗。在分布式系统里连接建立的开销是至关重要的成本指标。三次握手已经是兼顾安全性和效率的最优解。4. 四次挥手全流程与状态变化4.1 四次挥手的每一步拆解当通信双方的数据传输完毕连接就需要关闭。TCP 关闭连接采用四次挥手原因是 TCP 连接是双工的两条方向的数据通道必须各自独立关闭。第一次挥手主动方发送 FIN假设客户端是主动关闭方。客户端调用close()之后操作系统向服务端发送一个 FIN 报文表示“我这边没有数据要发给你了”。此时客户端进入FIN_WAIT_1状态。第二次挥手被动方回复 ACK服务端收到 FIN 后回复一个 ACK表示“我收到了你关闭连接的请求”。此时服务端进入CLOSE_WAIT状态。客户端收到这个 ACK 后进入FIN_WAIT_2状态。这里注意服务端回复 ACK 并不意味着整个连接马上关闭因为服务端可能还有数据要发给客户端。这个“还能继续发送数据”的状态叫半关闭half-close是理解四次挥手的核心。第三次挥手被动方发送 FIN服务端的所有数据发送完之后调用close()向客户端发送一个 FIN 报文表示“我这边也没有数据要发给你了”。服务端进入LAST_ACK状态。第四次挥手主动方回复 ACK客户端收到服务端 FIN 后回复一个 ACK表示“收到你的关闭请求”。客户端进入TIME_WAIT状态。服务端收到这个 ACK 后进入CLOSED状态连接完全关闭。客户端在TIME_WAIT状态等待 2MSL最长报文段寿命的两倍后也进入CLOSED。整个过程中四次挥手涉及的四个状态FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、LAST_ACK、TIME_WAIT是面试重点状态转换图值得反复画几遍。4.2 为什么需要四次挥手四次挥手的核心原因在于“被动关闭方可能还有数据要发送”。你想象一个 Web 服务的响应场景。客户端请求数据服务端把大文件传给客户端。客户端可能觉得“我请求发完了不打算再发了”于是发送 FIN 请求关闭。但服务端可能还有 500MB 文件正在传输中它当然不能因为收到 FIN 就立刻关闭连接否则数据全丢了。所以服务端先回复一个 ACK“我收到了你的关闭意愿但请稍等我还有数据要发。”等文件全部传完服务端再发送 FIN“现在我说完了真的可以关了。”如果设计成三次挥手也就是把第二次和第三次合并让服务端收到 FIN 后立刻回 FINACK那就等于强行要求服务端在收到 FIN 的瞬间必须已经没有数据要发送了。这在简单场景下可能成立但在真实网络环境中是极其不合理的假设。数据缓冲里还有未发送的数据、上层应用还没处理完毕、程序还有后续任务——这些都需要时间。所以四次挥手并不是设计者的刻意复杂化而是对“半关闭”这个真实需求的尊重。4.3 TIME_WAIT 状态为什么必须存在整个四次挥手过程里最容易被面试官追问的就是TIME_WAIT状态。客户端发送最后一个 ACK 后进入TIME_WAIT状态等待 2MSL 后才关闭。很多人不理解服务端都收到 ACK 进入 CLOSED 了客户端为什么还要等这么久直接关闭难道不行吗答案是不行原因有两个。第一个原因是最后一个 ACK 报文可能在网络中丢失。如果客户端直接关闭服务端迟迟收不到 ACK会超时后重新发送 FIN第三次挥手的报文此时客户端已经关闭无法回复连接就会卡在 LAST_ACK 状态无法关闭。设计者让客户端在 TIME_WAIT 状态等待一段时间就是为了让这个 ACK 有足够的时间到达服务端如果 ACK 丢失服务端会重发 FIN客户端处于 TIME_WAIT 时还能再回复一个 ACK保证双方能正常进入关闭流程。第二个原因是确保旧连接的报文段在网络中消逝。序列号有回绕的可能如果旧连接的延迟报文到达新连接而新连接恰好使用了相同的四元组就会造成数据错乱。等待 2MSL 可以确保所有属于旧连接的报文都已经在网络中消失不会残害新连接。那么 2MSL 是多长时间MSL 是报文最大生存时间不同操作系统略有不同。Linux 上常见为 30 秒所以 2MSL 一般是 60 秒。这也是为什么你频繁重启一个 TCP 服务端时会看到端口处于 TIME_WAIT 状态无法立即重用端口。Python 调试中Address already in use的错误绝大多数情况就是 TIME_WAIT 造成的。4.4 为什么不是四次挥手中的第二次和第三次合并还有一个高频追问“为什么挥手的第二次和第三次不能合并成一次”这实际上是“为什么要四次”的一个变形。答案前面说了一半核心是被动关闭方收到 FIN 后不能假设自己已经无数据可发。同时TCP 本身是全双工协议两个方向的数据流是独立的关闭也必须独立进行。只有双方都完成了各自的数据发送任务才可能完全关闭连接。要补充的是有一种例外可以缩减挥手次数叫“TCP 半关闭特性”即通过shutdown()函数只关闭一个方向的数据流而不是像close()那样关闭整个 socket。在 Python socket 编程里shutdown(socket.SHUT_WR)可以实现主动方关闭写方向但保留读方向这是实现优雅关闭的基础。5. 面试复盘与高频追问合集5.1 面试中常见的追问与参考话术整理一些真实的面试追问你可以用来自测。追问 1三次握手可以携带数据吗理论上前两次握手SYN 和 SYNACK不能携带数据因为连接还没建立双方还没同步好序列号数据无法被正确理解。第三次握手ACK可以携带数据因为此时客户端已经知道服务端的序列号了。实际上TFOTCP Fast Open机制允许在 SYN 中携带数据以节省 RTT但这是后来的优化标准 TCP 不这么做。追问 2如果第三次握手的 ACK 丢失了怎么办服务端收不到 ACK会认为自己发的 SYNACK 没有被客户端收到于是触发超时重传重新发送 SYNACK。客户端处于 ESTABLISHED 状态收到重复的 SYNACK 后会再次回复 ACK。这个重传过程会持续到达到最大重传次数之后服务端放弃连接进入 CLOSED。这种情况在 Python 网络编程中表现为 connect 成功但在发送数据时出现异常。追问 3SYN Flood 是什么SYN Flood 是一种拒绝服务攻击攻击者发送大量 SYN 报文但不回复第三次握手的 ACK导致服务端留下大量半连接SYN_RCVD 状态消耗内存和 CPU 资源。Linux 内核的 SYN Cookies 机制可以在半连接队列满时通过特殊的序列号编码回复 SYNACK不占用资源直到收到真正的 ACK 才分配资源。追问 4服务端大量 CLOSE_WAIT 状态是什么问题CLOSE_WAIT 意味着服务端收到了客户端的 FIN回复了 ACK但自己的代码迟迟没有调用close()关闭连接。这个状态大量出现基本可以断定是服务端代码的 bug——比如处理请求的线程或协程卡住了或者异常分支忘记关闭连接。用netstat -ant | grep CLOSE_WAIT | wc -l可以统计数量排查时重点检查socket.close()是否在所有路径上都执行了。追问 5客户端大量 TIME_WAIT 状态有什么影响大量 TIME_WAIT 会占用本地端口如果你的服务端程序短连接请求特别多端口可能会被耗尽导致Cannot assign requested address。解决思路包括使用连接池复用长连接、开启net.ipv4.tcp_tw_reuse内核参数、或者调小 TIME_WAIT 等待时间。但要谨慎改内核参数是双刃剑tcp_tw_reuse 只在客户端场景下相对安全。5.2 Python 网络性能诊断时的三板斧不管你是准备面试还是已经在做 Python 后端开发遇到网络连接问题建议按这个顺序排查。先用ss -ant看四元组连接状态。重点关注 SYN_SENT、SYN_RCVD、ESTABLISHED、CLOSE_WAIT、TIME_WAIT 的数量。如果你用 Python 写了并发服务端出现大量 CLOSE_WAIT 基本可以断定是业务代码的问题。出现大量 SYN_SENT 则可能是防火墙拦截或服务端对端不可达。出现大量 TIME_WAIT 要考虑端口耗尽问题。再用netstat -s看 TCP 层统计信息重点留意“retransmit”重传统计和“listen queue overflow”半连接队列溢出的数量。如果半连接队列溢出了说明并发量突增或 SYN 攻击需要调大/proc/sys/net/ipv4/tcp_max_syn_backlog。最后在代码里加日志和埋点。Python 的 socket 异常类型有很多细节比如ConnectionResetError对应 RST 报文ConnectionAbortedError对应对方在建立连接之前主动放弃TimeoutError对应超时。把这些异常类型和 TCP 状态关联起来你排查问题的速度会快一个量级。5.3 自学者的状态机记忆法如果觉得状态机很难记我分享一下我当年备考用的方法把状态分成“主动方视角”和“被动方视角”两组去记。主动方通常是客户端视角SYN_SENT发 SYN 后→ESTABLISHED收 SYNACK 并回 ACK 后→FIN_WAIT_1发 FIN 后→FIN_WAIT_2收 ACK 后→TIME_WAIT发最后一个 ACK 后。被动方通常是服务端视角LISTEN监听中→SYN_RCVD收 SYN 并回 SYNACK 后→ESTABLISHED收 ACK 后→CLOSE_WAIT收 FIN 并回 ACK 后→LAST_ACK发 FIN 后→CLOSED收 ACK 后。把这两条线在纸上各画一遍然后把它们交叉对应起来状态机就牢牢掌握了。6. 我在实践中的经验与建议6.1 面试答题的黄金节奏结合我自己的面试经验建议你答题时遵循“总-分-总”的节奏但一定要控制时间。先一句话概括三次握手是为了建立可靠的连接四次挥手是为了优雅地关闭连接。然后分点讲每个过程每步都带上序号、标志位、状态。最后点题说清楚为什么是三次而不是两次、为什么是四次而不是三次。在回答“为什么需要三次握手”这个问题时优先级最高的答案是“防止历史报文段造成连接错误”其次才是“同步双方初始序列号”。回答“为什么需要四次挥手”时优先说“TCP 是全双工的关闭需要独立关闭两个方向的数据通道”其次再说“被动关闭方可能还有数据未发送完成”。6.2 想在未来提升的话往哪个方向走如果你已经把三次握手四次挥手吃透了可以进一步深入了解 TCP 的拥塞控制慢启动、拥塞避免、快速重传、快速恢复、流量控制滑动窗口、Nagle 算法与延迟 ACK 的交互问题、以及 TCP 与 UDP 的对比细节。在 Python 领域更进阶的方向是使用asyncio编写高并发网络服务时理解 epoll 事件循环和 TCP 协议栈的交互方式以及如何调优内核参数来支撑高并发。比如你用 FastAPI 写一个 WebSocket 服务连接断开重连时为什么偶尔报端口占用、为什么服务端主动断开后客户端还能发数据这套 TCP 底层知识都能给你答案。6.3 最后分享一个小技巧如果你在面试中被问到“TCP 为什么可靠”不要只回答“因为三次握手和四次挥手”。你可以从三个维度展开数据完整性和有序性靠序列号和确认号丢包和超时靠重传机制而三次握手和四次挥手保证了连接的可靠建立与关闭。把这三个层次讲清楚你的答案就比大多数候选人有深度得多。实际准备时强烈建议你亲手做一遍 2.3 小节的 tcpdump 实验。眼见为实看过真实报文的人面试时说话的底气都是不一样的。准备充分了这道题就是稳稳的送分题。