1. 为什么前端面试总爱问三次握手和四次挥手1.1 一道题背后的考察逻辑面到一定年限之后你会发现一个规律越是基础的东西越容易被反复问。三次握手和四次挥手就是典型。很多做前端的朋友跟我吐槽说这玩意儿不是网络层的事吗我一个写页面的问它干嘛。我一开始也这么想直到自己带了几轮面试之后才明白面试官问这道题压根不是想听你把那几张状态图背出来。它真正想筛的是三件事。第一你有没有把浏览器当过一个完整的系统去理解而不是只会调 API。你写的每一个 fetch、每一次页面跳转、每一个 WebSocket 连接底层都跑在 TCP 之上你连连接怎么建立、怎么断开都不清楚遇到线上问题就只能干瞪眼。第二你能不能把抽象概念讲清楚。面试本质上是一次沟通能力的测试三次握手这种有明确流程的知识点是检验你表达是否有条理的绝佳素材。第三你对细节的敏感度。SYN、ACK、seq、ack 这些字段半连接队列、TIME_WAIT 这些状态能答到多深直接反映你平时是浮在表面还是真的往下钻过。所以这道题的正确打开方式不是背而是理解。你理解了为什么是三次而不是两次、四次而不是三次剩下的细节都是自然推导出来的。我见过太多候选人背得滚瓜烂熟但面试官追问一句“为什么不能两次握手”就卡壳了这种背诵在面试官眼里反而是减分项。1.2 前端视角下它到底影响什么站在前端工程师的角度这东西不是纯理论。举几个你天天会遇到但可能没意识到的场景。页面加载慢你打开 DevTools 看 Network发现某个请求的 Timing 里有一栏叫 “Initial connection”这一栏的时间就是 TCP 握手消耗的时间。如果你的站点没有开启连接复用每个请求都要重新握手那这个时间会成倍叠加。再比如你用了 HTTP/2 的多路复用为什么它快因为一条 TCP 连接上可以并行跑很多请求省掉了反复握手和慢启动的开销。还有 WebSocket它是在一次 HTTP 握手之后升级协议本质上还是复用了 TCP 连接。再往深一点服务端如果 TIME_WAIT 状态堆积过多会导致端口耗尽新连接建不起来表现出来就是用户侧偶发的连接超时。你排查半天前端代码最后发现是服务端 TCP 参数没调好。这种问题不懂握手挥手的人根本无从下手。所以我的态度很明确这道题值得你花时间真正搞懂而不是应付面试。搞懂之后你对整个 Web 性能优化的理解会上一个台阶。2. 三次握手把连接建立这件事讲透2.1 从生活类比理解握手本质先别急着看状态图。我用一个生活场景帮你建立直觉。假设你要给一个远方的朋友打电话确认一件事。你拨过去朋友接起来说“喂”。你说“是我能听到吗”。朋友说“能听到你说”。这三句话完成双方才确认“这条通话线路是通的而且对方在线”。TCP 三次握手就是这个逻辑。客户端和服务端在正式传数据之前必须先确认两件事我的发送能力对方能收到对方的发送能力我也能收到。注意这是双向的必须两个方向都确认。第一次客户端发一个 SYN 包给服务端意思是“我想跟你建立连接我的初始序号是 X”。这一步服务端能确认客户端的发送能力正常我的接收能力正常。第二次服务端回一个 SYNACK 包意思是“收到你的请求了我同意我的初始序号是 Y我期待你下一个包序号是 X1”。这一步客户端能确认我的发送正常、我的接收正常、对方的发送和接收都正常。第三次客户端再发一个 ACK 包意思是“收到你的同意了我期待你下一个包序号是 Y1”。这一步服务端能确认我的发送正常、对方的接收正常。三次走完双方都确认了双向通道畅通。这就是为什么是三次——因为要确认的是双向而每一次单向通信只能确认一个方向的信息。2.2 为什么两次握手不行这是面试高频追问必须答清楚。假设只有两次握手。客户端发 SYN服务端回 SYNACK然后服务端就认为连接建立了开始准备发数据。问题在于服务端此时并不知道客户端有没有收到自己的 SYNACK。如果这个包在网络中丢了客户端会以为连接没建成功可能重发或者放弃而服务端却傻乎乎地维持着一个连接资源就这么被占着。更严重的是历史连接的问题。网络里可能存在延迟很久的旧 SYN 包。如果只有两次握手服务端收到一个陈旧的 SYN 就建立连接而客户端根本没想连这就造成了一个无效连接白白消耗服务端资源。三次握手的第三次 ACK本质上是让客户端有机会告诉服务端“我确实收到了你的确认这个连接是有效的”从而过滤掉历史无效连接。一句话总结两次握手只能确认单向无法确认客户端的接收能力也无法防止历史连接造成的资源浪费。2.3 握手过程中的关键字段与状态面试时能把字段说清楚档次立刻不一样。核心字段有这么几个。字段含义作用SYN同步标志位表示这是一个连接请求携带初始序号ACK确认标志位表示确认收到对方的包seq序列号本报文段数据的第一个字节的编号ack确认号期望收到对方下一个报文段的第一个字节编号状态变化也要能说。客户端从 CLOSED 到 SYN_SENT收到 SYNACK 后进入 ESTABLISHED。服务端从 CLOSED 到 LISTEN收到 SYN 后进入 SYN_RCVD收到 ACK 后进入 ESTABLISHED。这里有个细节值得注意服务端在 SYN_RCVD 状态下连接还没完全建立会被放进一个叫半连接队列的地方。如果这个队列满了新的 SYN 就会被丢弃客户端会超时重传。这就是所谓的 SYN Flood 攻击的原理也是为什么生产环境要调大半连接队列、开启 SYN Cookie 的原因。前端同学了解这个在排查“为什么高峰期连接建立失败”时就有思路了。2.4 初始序列号为什么不能固定很多人背握手流程时忽略了一个点为什么每次连接的初始序列号ISN都是随机的而不是从 0 开始原因有两个。第一是安全。如果 ISN 可预测攻击者就能伪造包插入到连接中冒充其中一方发送数据。随机化 ISN 让这种攻击变得困难。第二是避免历史连接的序号混淆。网络中的旧包如果序号恰好落在新连接的接收窗口内就会被误认为是新数据。随机 ISN 大大降低了这种概率。现代实现里ISN 不是纯随机而是基于一个时钟计数器加上连接四元组的哈希值生成的这样既保证不可预测又保证在同一个连接上序号单调递增。这个细节面试时说出来面试官基本会对你刮目相看。3. 四次挥手断开连接为什么多一次3.1 挥手流程的完整拆解连接建立是三次断开却是四次这个不对称让很多人困惑。先把流程走一遍。第一次客户端发 FIN 包意思是“我这边没有数据要发了但还能收”。客户端进入 FIN_WAIT_1。第二次服务端回 ACK意思是“知道你没数据发了”。服务端进入 CLOSE_WAIT客户端进入 FIN_WAIT_2。注意此时连接是半关闭状态服务端可能还有数据要发给客户端。第三次服务端数据发完了发 FIN 包意思是“我也没数据要发了”。服务端进入 LAST_ACK。第四次客户端回 ACK意思是“收到”。客户端进入 TIME_WAIT等待 2MSL 后进入 CLOSED。服务端收到 ACK 后进入 CLOSED。关键点在于第二次和第三次之间。TCP 是全双工的两个方向的数据流是独立的。客户端说“我不发了”不代表服务端也“不发了”。服务端可能还有数据在缓冲区里没发完所以它先回一个 ACK 表示“知道了”等自己数据发完了再发 FIN。这个“先 ACK 后 FIN”的分开就是四次挥手比三次握手多一次的根本原因。3.2 半关闭状态的实际意义半关闭是 TCP 一个很优雅的设计。它允许一方停止发送数据但仍然可以接收对方的数据。举个实际场景。客户端向服务端发了一个请求然后关闭了发送方向。服务端收到请求后需要处理一段时间处理完再把响应发回来。如果断开是“一刀切”的客户端一关服务端就没法回数据了。半关闭让客户端可以只关发送方向继续等着收响应。在 HTTP/1.0 时代这种模式很常见。客户端发完请求就半关闭服务端处理完发响应然后服务端再关闭。这也是为什么早期 HTTP 连接管理里服务端关闭连接是一个重要的信号表示响应结束。3.3 TIME_WAIT 状态到底在等什么TIME_WAIT 是面试里最爱追问的点没有之一。客户端发完最后一个 ACK 之后不会立刻关闭而是进入 TIME_WAIT等待 2 倍 MSL报文最大生存时间才真正关闭。为什么要等两个原因。第一确保最后一个 ACK 能到达服务端。如果这个 ACK 丢了服务端会超时重传 FIN。此时客户端如果已经关闭收到重传的 FIN 就会回一个 RST服务端会认为连接异常。而客户端处于 TIME_WAIT 状态时还能重新发 ACK保证服务端正常关闭。第二让本次连接的所有旧包在网络中消散。如果不等待同一个四元组源 IP、源端口、目的 IP、目的端口立刻建立新连接网络中延迟的旧包可能被新连接误收造成数据错乱。2MSL 的时间足够让一个来回的包都消失。MSL 在 Linux 上通常设为 30 秒所以 TIME_WAIT 默认是 60 秒。这个值可以通过内核参数调整但一般不建议乱改改小了会带来上面说的风险。3.4 为什么不能三次挥手既然握手能三次挥手为什么不能合并成三次也就是服务端收到 FIN 后直接回 FINACK。理论上在某些情况下可以比如服务端确实没有数据要发了ACK 和 FIN 可以一起发。但 TCP 协议设计上不能假设这种情况总是成立。因为服务端收到 FIN 时它的应用层可能还没处理完数据缓冲区里可能还有内容。协议必须允许“先确认后关闭”这个中间状态存在。所以标准流程是四次三次只是四次的一个特例优化不能作为通用规则。面试时如果被问到你可以说四次是通用情况三次是服务端恰好无数据可发时的合并优化协议不能依赖这种巧合。4. 把状态机串起来一张图在脑子里4.1 客户端状态流转客户端的状态路径相对简单CLOSED → SYN_SENT → ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED。有几个容易混淆的点。FIN_WAIT_1 是发了 FIN 还没收到 ACK。FIN_WAIT_2 是收到 ACK 了但还没收到对方的 FIN。如果对方一直不发 FIN客户端会一直卡在 FIN_WAIT_2这在实际中是个隐患有些系统会设置超时来强制关闭。TIME_WAIT 前面说过了是等 2MSL。还有一个状态叫 CLOSING出现在双方同时发 FIN 的情况下比较少见但面试时提一句能显示你理解得全面。4.2 服务端状态流转服务端路径CLOSED → LISTEN → SYN_RCVD → ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED。CLOSE_WAIT 是服务端收到 FIN 并回了 ACK 之后的状态。这个状态如果大量堆积说明应用层没有及时调用 close 关闭连接。这是服务端常见的 bug比如代码里忘了关连接或者处理逻辑卡住了。前端同学了解这个在跟后端联调时能快速定位问题方向。LAST_ACK 是服务端发了 FIN 等最后 ACK 的状态。收到 ACK 后就 CLOSED 了。4.3 状态机记忆的实用方法我不建议死记硬背状态名。我的方法是抓住“谁在等谁”这个核心。带 WAIT 的状态都是“我在等对方的某个动作”。FIN_WAIT_1 等对方的 ACKFIN_WAIT_2 等对方的 FIN。CLOSE_WAIT 是“对方关了我还没关”。LAST_ACK 是“我关了等对方确认”。TIME_WAIT 是“我关了但还要守一会儿”。按这个逻辑去理解状态机就不是一堆孤立的单词而是一条有因果的链条。面试时你按这个逻辑讲面试官能听出你是真懂。5. 面试实战怎么答才能拿高分5.1 回答的结构化模板我面过不少人发现答这道题最大的问题是“流水账”。上来就说“客户端发 SYN服务端回 SYNACK”说完就没了。这种答法只能拿及格分。高分答法应该分三层。第一层先讲目的握手是为了确认双向通信能力挥手是为了安全释放双向连接。第二层讲流程但每一步都要说清楚“这一步确认了什么”。第三层讲异常情况和优化比如为什么不能两次、TIME_WAIT 的作用、SYN Flood 的防护。我建议你准备一个 90 秒左右的版本把三层都覆盖到。面试官如果感兴趣会顺着追问你再展开。这样既显得有条理又留了深入的空间。5.2 高频追问清单下面这些是我实际面试中问过、也被问过的追问你可以对照自查。追问考察点回答要点为什么是三次不是两次对双向确认的理解两次无法确认客户端接收能力无法防历史连接为什么是四次不是三次对半关闭的理解服务端可能还有数据要发ACK 和 FIN 不能合并TIME_WAIT 作用对可靠关闭的理解保证最后 ACK 到达让旧包消散TIME_WAIT 过多怎么办工程实践调内核参数、连接复用、SO_REUSEADDRSYN Flood 怎么防安全意识SYN Cookie、调大队列、限速初始序列号为什么随机对安全的理解防伪造、防历史包混淆半连接队列和全连接队列对内核实现的理解SYN 队列和 accept 队列的区别5.3 前端场景的加分回答如果你能在回答里结合前端场景面试官会觉得你不是死读书。比如你可以说我们做性能优化时会关注 Initial connection 时间通过开启 keep-alive 复用连接来减少握手开销。再比如HTTP/2 的多路复用之所以快一部分原因就是省掉了多次握手。还有排查偶发连接超时时会去看服务端是不是 TIME_WAIT 或 CLOSE_WAIT 堆积。这种回答把网络知识和你的日常工作挂上了钩比纯背概念有说服力得多。6. 自己梳理全文的方法与避坑6.1 为什么必须自己动手梳理标题里那句“建议自己梳理全文背诵”我特别认同但我想强调“梳理”比“背诵”重要得多。你直接背别人的总结遇到追问就露馅。自己梳理一遍哪怕梳理得粗糙那个过程会让你真正理解每个环节的因果关系。我的做法是拿一张白纸不看任何资料把三次握手和四次挥手的流程画出来每一步标注状态、字段、确认了什么。画完再对照资料查漏补缺。这个过程通常要重复三到五遍直到你能闭着眼睛讲出来而且能应对各种追问。6.2 梳理时的常见误区第一个误区是只记流程不记状态。流程是“发生了什么”状态是“现在处于什么阶段”两者要对应起来记。第二个误区是忽略异常情况。正常流程谁都会背但面试考的是异常。丢包怎么办、超时怎么办、同时关闭怎么办这些才是区分度所在。第三个误区是把握手和挥手割裂开。它们其实是一套逻辑的两面握手是建立双向确认挥手是解除双向确认。理解了对称性记忆负担会小很多。第四个误区是只学理论不看实际。建议你用抓包工具实际抓一次握手挥手的过程看到真实的 SYN、ACK 包比看十遍图都管用。Wireshark 是免费工具装一个访问一个网站过滤 tcp 流量你就能看到完整的握手过程。6.3 一个可复用的梳理框架我总结了一个框架你可以照着填。目的握手/挥手各自要解决什么问题。流程每一步谁发什么、带什么标志、进入什么状态。确认每一步确认了哪个方向的通信能力。异常丢包、超时、同时操作分别怎么处理。优化有哪些参数可调有哪些攻击要防。前端关联哪些日常场景会用到这些知识。把这六个格子填满你就真的掌握了。填的过程中如果发现某个格子填不出来那就是你的知识盲区重点补。7. 几个容易被忽略的细节7.1 同时打开与同时关闭TCP 协议里还有两个冷门但有意思的场景。同时打开是指双方几乎同时发 SYN这时会变成四次握手而不是三次。同时关闭是指双方几乎同时发 FIN这时会进入 CLOSING 状态。这两个场景在实际中很少见但面试时能提一句说明你读过 RFC不是只看二手资料。7.2 MSS 与窗口缩放握手过程中双方还会协商 MSS最大报文段长度和窗口缩放因子。MSS 决定了每个 TCP 段最大能带多少数据窗口缩放决定了接收窗口能有多大。这两个参数直接影响传输效率。前端做性能优化时如果知道服务端的 MSS 设置就能理解为什么某些大响应会被拆成多个包。7.3 连接复用的实际收益最后说个实用的。开启 keep-alive 之后连接建立的开销被摊薄到多个请求上。假设一次握手耗时 50ms一个页面有 20 个请求不复用就是 1000ms 的握手开销复用之后可能只有 50ms。这个差距在移动网络下更明显因为移动网络的 RTT 更高。所以你在做前端性能优化时确保服务端和客户端都开启了连接复用是最简单也最有效的优化之一。我自己踩过的坑是曾经有个项目为了“干净”每次请求都新建连接结果首屏时间比预期多了将近一秒。后来排查发现就是没复用连接每个请求都在重新握手。改完之后首屏直接降了 800ms。这个教训让我明白网络层的知识不是面试用的是真金白银的性能。把三次握手和四次挥手真正搞懂你会发现它不只是一道面试题而是你理解整个 Web 运行机制的一把钥匙。从浏览器到服务端从 HTTP 到 WebSocket底层都跑在这套机制上。花点时间自己梳理一遍比背十遍标准答案都值。