真实面经题目 · 原创解析

TCP 三次握手和四次挥手的流程是什么?

TCP 三次握手和四次挥手的流程是什么?这道腾讯牛客题的关键是围绕“TCP 建连与关闭状态机”讲清概念、机制、取舍和边界。TCP 三次握手负责建立连接和同步双方初始序列号;四次挥手负责分别关闭两个方向的字节流。建连关注 SYN、SYN+ACK、ACK 和双方收发能力确认;关闭关注 FIN、ACK、半关闭、CLOSE_WAIT 和 TIME_WAIT。

出现于:腾讯 · 客户端

60 秒回答模板

可以这样回答:TCP 三次握手负责建立连接和同步双方初始序列号;四次挥手负责分别关闭两个方向的字节流。建连关注 SYN、SYN+ACK、ACK 和双方收发能力确认;关闭关注 FIN、ACK、半关闭、CLOSE_WAIT 和 TIME_WAIT。 建连时客户端发 SYN,服务端回 SYN+ACK,客户端再 ACK;关闭时主动方发 FIN,对端 ACK 后进入半关闭,对端处理完剩余数据再发 FIN,主动方 ACK 后进入 TIME_WAIT 等待 2MSL。 三次握手多一次 RTT 但能确认双向能力和序列号;四次挥手允许两个方向独立关闭,保证缓冲区数据有机会发完。代价是短连接会增加状态维护和 TIME_WAIT 资源占用。 不要把 CLOSE_WAIT 和 TIME_WAIT 混淆。CLOSE_WAIT 偏应用未及时关闭,TIME_WAIT 偏主动关闭方等待迟到报文和对端 FIN 重传。 验证时重点看:排查时看 SYN-SENT、SYN-RECV、ESTABLISHED、FIN_WAIT、CLOSE_WAIT、TIME_WAIT 状态分布,以及抓包里的 SYN/FIN/ACK 顺序和重传。

考点 考点边界
主线 核心机制
易错点 只背三次握手包名,漏掉四次挥手和半关闭语义。

深入解析

01

考点边界

这题同时问建连和关闭,不能只讲三次握手。回答要把连接建立、数据传输、单向关闭、双方完全关闭和 TIME_WAIT 保护窗口串成一条状态机。 本题对应“TCP 建连与关闭状态机”,核心前提是:TCP 三次握手负责建立连接和同步双方初始序列号;四次挥手负责分别关闭两个方向的字节流。建连关注 SYN、SYN+ACK、ACK 和双方收发能力确认;关闭关注 FIN、ACK、半关闭、CLOSE_WAIT 和 TIME_WAIT。

02

核心机制

建连时客户端发 SYN,服务端回 SYN+ACK,客户端再 ACK;关闭时主动方发 FIN,对端 ACK 后进入半关闭,对端处理完剩余数据再发 FIN,主动方 ACK 后进入 TIME_WAIT 等待 2MSL。 关键证据要落到协议状态、报文边界、连接状态、抓包信号,这样才能说明机制为什么能支撑题目结论。如果继续展开,要对应到连接状态、报文顺序、窗口变化、超时重传、抓包字段或应用层语义,避免把不同协议层混在一起。

03

关键取舍

三次握手多一次 RTT 但能确认双向能力和序列号;四次挥手允许两个方向独立关闭,保证缓冲区数据有机会发完。代价是短连接会增加状态维护和 TIME_WAIT 资源占用。 因此要把协议层职责、握手成本、超时重试、抓包证据和应用兜底放在一起判断。 这些取舍决定了方案在不同输入规模、延迟、内存、并发、泛化或一致性要求下是否仍然成立。

04

边界风险

不要把 CLOSE_WAIT 和 TIME_WAIT 混淆。CLOSE_WAIT 偏应用未及时关闭,TIME_WAIT 偏主动关闭方等待迟到报文和对端 FIN 重传。 排查时优先看抓包、连接状态、握手阶段、重传率、RTT、状态码、超时分布和服务端日志。 需要特别关注极端输入、数据分布变化、资源不足、并发竞争或观测口径错误带来的退化。修复时要按 DNS、连接建立、传输、应用协议和服务端处理分段定位,避免只在客户端或服务端单点猜测。

05

验证抓手

工程验证可以结合抓包、连接状态、重传统计、RTT、丢包率、状态码和服务端日志。协议题如果能落到可观察指标,就能从背诵变成可排查的工程答案。 针对本题,最有价值的验证信号是:排查时看 SYN-SENT、SYN-RECV、ESTABLISHED、FIN_WAIT、CLOSE_WAIT、TIME_WAIT 状态分布,以及抓包里的 SYN/FIN/ACK 顺序和重传。把验证抓手说出来,可以让答案从知识点延伸到网络链路排查和协议行为验证。

易错点

  • 只背三次握手包名,漏掉四次挥手和半关闭语义。
  • 混淆 CLOSE_WAIT、TIME_WAIT、FIN_WAIT,无法定位关闭流程中的真实问题。
  • 把相邻概念混用,没有明确说明这道题真正考察的边界。
  • 没有给出验证方式,导致答案听起来完整但无法判断是否真的生效。

面试官追问

三次握手和四次挥手分别解决什么问题?

三次握手解决连接建立、初始序列号同步和双向收发能力确认;四次挥手解决两个方向的字节流独立关闭,并让双方有机会发送完缓冲区剩余数据。

为什么关闭通常需要四次而建立只要三次?

建立时 SYN 和 ACK 可以合并在服务端第二个包里;关闭时一端收到 FIN 只表示对端不再发送,但自己可能还有数据要发,所以 ACK 和自己的 FIN 往往分开发送。

“TCP 三次握手和四次挥手的流程是什么”继续追问时最该补哪条边界?

应该围绕“TCP 建连与关闭状态机”补适用前提、失败场景和验证证据。先说明哪些条件下这个机制成立,再说明哪些输入规模、并发状态、数据分布或资源限制会让答案需要调整。

“TCP 三次握手和四次挥手的流程是什么”怎样回答才不是只背概念?

看它能否把“TCP 建连与关闭状态机”的机制链路、关键取舍和可观测信号连起来。回答时应落到具体状态变化、数据路径、复杂度、指标或排查工具,而不是只复述定义。

“TCP 三次握手和四次挥手的流程是什么”为什么还要做应用层兜底?

TCP 提供有序可靠字节流,但应用仍要处理超时、半连接、连接复用、服务端异常、重试幂等和业务协议边界。UDP 更需要应用自己处理丢包、乱序和拥塞控制。