1. 为什么TCP/IP面试题总在重复考那几个点面过网络岗的人大概都有这种体会一轮技术面下来TCP三次握手、四次挥手、TIME_WAIT、拥塞控制这几个词几乎必然出现。有人觉得这是面试官偷懒题库十年不换。但真正带过项目、排过线上故障的人心里清楚这些点之所以反复被问不是因为它们经典而是因为它们直接对应生产环境里最容易出事的环节。我做过几年后端服务也参与过招聘慢慢发现一个规律能把TCP/IP这几个核心机制讲明白的人往往在排查连接超时、端口耗尽、服务雪崩这类问题时思路更清晰。反过来只会背“三次握手是为了确认双方收发能力”这种标准答案一到真实场景就抓瞎。这篇内容我打算按面试官真正想听的逻辑来拆不是罗列知识点而是把每个机制背后的设计动机、参数计算、线上表现、排查手段串起来。适合准备面试的初中级工程师也适合工作几年但网络基础一直没系统补过的朋友。看完你至少能做到两件事面试时能答出深度工作时遇到连接类问题知道从哪下手。2. 三次握手不只是确认收发能力那么简单2.1 握手过程的状态流转与报文细节先把流程过一遍但我不打算停留在“SYN、SYN-ACK、ACK”这种层面。真正值得关注的是每个报文里带了什么、内核状态怎么变。客户端调用connect()内核发送SYN报文此时客户端进入SYN_SENT状态。这个SYN报文里有两个关键字段序列号seqx随机生成以及选项字段里的MSS最大报文段长度、窗口缩放因子、SACK permitted等。服务端收到后如果对应端口有监听内核回复SYN-ACKseqy另一个随机数ackx1同时自己也带上MSS等选项服务端进入SYN_RCVD。客户端收到SYN-ACK后回复ACKacky1进入ESTABLISHED服务端收到这个ACK后也进入ESTABLISHED。这里有个容易被忽略的点第三次握手是可以携带数据的。客户端在发送ACK的同时就能把第一个数据包捎上这在某些低延迟场景下能省一个RTT。但服务端在收到第三次握手之前不能发送数据只能发SYN-ACK。序列号为什么必须随机早期实现用固定或可预测的初始序列号结果被利用来伪造连接、注入数据。随机化ISNInitial Sequence Number是为了让攻击者难以猜测这是安全设计的一部分。面试时如果只答“确认双方收发能力”深度是不够的。2.2 为什么是三次而不是两次或四次两次握手的问题在于服务端无法确认客户端是否收到了自己的SYN-ACK。如果客户端没收到服务端却已经认为连接建立就会白白维护一个连接资源。更严重的是历史上有过因为旧连接延迟的SYN到达服务端服务端直接建立连接导致资源被无效占用的情况。四次握手理论上可行但没必要。服务端的SYN和ACK可以合并成一个报文发送因为这两个动作没有先后依赖合并不影响正确性。所以三次是信息完整性和效率之间的最优解。我个人的理解是三次握手的本质是双方各自确认“我发的对方收到了对方发的我也收到了”。客户端在收到SYN-ACK时确认了自己的发送能力和对方的接收能力服务端在收到ACK时确认了自己的发送能力和对方的接收能力。两次做不到这个双向确认四次是冗余。2.3 SYN Flood攻击与半连接队列这是面试高频延伸点。攻击者伪造大量源IP发送SYN服务端回复SYN-ACK后进入SYN_RCVD等待第三次握手。如果攻击者不回复ACK这些半连接就会占满服务端的半连接队列syn queue导致正常用户无法建立连接。防御手段有几个方向。一是增大半连接队列通过调整内核参数net.ipv4.tcp_max_syn_backlog。二是启用SYN Cookies服务端在收到SYN时不立即分配资源而是根据源IP、端口等信息计算一个cookie作为序列号收到ACK时验证cookie有效性再分配资源。三是缩短SYN-ACK重传次数让半连接更快超时释放。注意SYN Cookies在极端情况下会导致部分TCP选项如窗口缩放无法协商因为cookie空间有限。生产环境开启前要评估。实测中我遇到过一次半连接队列打满的情况表现是服务端CPU不高、带宽不高但新连接就是建不上。用netstat -s | grep -i syn能看到大量SYN丢弃计数。后来调大了backlog并开启了syncookies才缓解。这个排查思路面试时讲出来比背概念有说服力得多。3. 四次挥手与TIME_WAIT面试重灾区3.1 挥手为什么比握手多一次挥手需要四次核心原因是TCP是全双工的两个方向需要分别关闭。客户端发送FIN表示“我没数据要发了”但这不代表它不能再接收数据。服务端收到FIN后回复ACK此时连接处于半关闭状态服务端可能还有数据要发给客户端。等服务端也发完数据了再发送自己的FIN客户端回复ACK连接才完全关闭。所以FIN和ACK不能像握手那样合并因为服务端收到FIN时自己的数据不一定发完了。如果强行合并就意味着服务端收到FIN后立即关闭发送通道可能丢数据。状态流转上主动关闭方经历FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT被动关闭方经历CLOSE_WAIT、LAST_ACK、CLOSED。这里CLOSE_WAIT是个重点后面单独说。3.2 TIME_WAIT为什么必须等2MSLTIME_WAIT状态持续2倍MSLMaximum Segment Lifetime报文最大生存时间。Linux下MSL默认30秒所以TIME_WAIT持续60秒。为什么必须等第一个原因确保最后一个ACK能到达对端。如果客户端发送的最后一个ACK丢失服务端会重传FIN。如果客户端已经关闭收到重传的FIN会回复RST服务端会认为连接异常。有了TIME_WAIT客户端还能重新发送ACK。第二个原因让本次连接的旧报文在网络中消散。如果立即用相同的四元组建立新连接旧连接的延迟报文可能被新连接误收造成数据错乱。等2MSL后旧报文基本都超时消失了。这两个原因面试时最好都答出来只答一个会被认为理解不完整。3.3 大量TIME_WAIT的成因与处理线上常见问题某台服务器作为主动关闭方短连接量大TIME_WAIT堆积到几万个端口被占满新连接建不上。成因很明确主动关闭方才会进入TIME_WAIT。如果服务端主动关闭连接且QPS高、连接短就会大量堆积。处理手段分几个层次。应用层优先考虑用长连接替代短连接或者让客户端主动关闭把TIME_WAIT转移到客户端。内核层可以调整net.ipv4.tcp_tw_reuse允许将TIME_WAIT状态的socket用于新的出站连接。注意这个参数只对出站连接有效且需要时间戳选项开启。net.ipv4.tcp_tw_recycle在较新内核中已被移除不要再用。还可以调小net.ipv4.tcp_fin_timeout但这影响的是FIN_WAIT_2的超时不是TIME_WAIT。提示tcp_tw_reuse在NAT环境下要谨慎因为时间戳可能被中间设备改写导致连接被错误复用。我踩过的坑是早期为了快速解决TIME_WAIT问题直接调了tcp_tw_recycle结果在负载均衡后面出现大量连接失败。后来才知道这个参数在NAT场景下会因为时间戳不一致丢弃报文。现在我的建议是优先从架构上解决内核参数只是辅助。3.4 CLOSE_WAIT堆积说明什么CLOSE_WAIT是被动关闭方收到FIN并回复ACK后进入的状态等待应用层调用close()。如果CLOSE_WAIT大量堆积说明应用层没有正确关闭socket。常见原因代码里忘记调用close()或者异常分支没有释放连接或者线程池阻塞导致关闭逻辑没执行。这不是内核参数能解决的必须查应用代码。排查方法用lsof -i :端口或ss -tan state close-wait找到对应进程再看代码里哪里漏了关闭。我遇到过一次是HTTP客户端没有正确关闭响应体导致连接一直挂着。这种问题面试时如果能结合排查过程讲非常加分。4. 拥塞控制从理论到线上表现4.1 慢启动、拥塞避免、快重传、快恢复拥塞控制是TCP保证网络稳定的核心机制。四个阶段要能讲清楚触发条件和转换关系。慢启动连接刚建立时拥塞窗口cwnd从1个MSS开始每收到一个ACK就翻倍指数增长。目的是快速探测网络容量。但指数增长很快会撞到阈值ssthresh。拥塞避免当cwnd达到ssthresh后改为线性增长每个RTT增加1个MSS。目的是缓慢逼近网络极限避免剧烈波动。快重传接收方收到乱序报文时立即发送重复ACK。发送方连续收到3个重复ACK就认为该报文丢失立即重传不等超时。这大大加快了恢复速度。快恢复快重传后不回到慢启动而是把ssthresh设为当前cwnd的一半cwnd设为ssthresh然后进入拥塞避免。因为能收到重复ACK说明网络还没完全瘫痪没必要从头慢启动。超时重传则是更严重的情况cwnd直接回到1重新慢启动。4.2 拥塞控制算法的演进与选择传统算法是Reno后来有NewReno、CUBIC、BBR等。Linux默认现在是CUBIC它用三次函数替代线性增长在高带宽长距离网络上表现更好。BBR是Google提出的不依赖丢包判断拥塞而是基于带宽和RTT建模在有一定丢包但带宽充足的网络上优势明显。面试时如果问“你们线上用什么拥塞控制算法”可以答CUBIC是默认如果业务对延迟敏感且网络有轻微丢包可以评估BBR。查看和设置命令# 查看当前算法 sysctl net.ipv4.tcp_congestion_control # 查看可用算法 sysctl net.ipv4.tcp_available_congestion_control # 临时设置为bbr sysctl -w net.ipv4.tcp_congestion_controlbbr注意切换拥塞控制算法影响全局生产环境要灰度验证。BBR在某些场景下可能对丢包敏感的业务不友好因为它的发送速率不完全依赖丢包信号。4.3 滑动窗口与流量控制的区别很多人把拥塞控制和流量控制搞混。流量控制是接收方通过窗口字段告诉发送方“我还能收多少”防止接收方缓冲区溢出。拥塞控制是发送方根据网络状况调整发送速率防止网络过载。两者共同决定实际发送窗口实际窗口 min(接收窗口, 拥塞窗口)。零窗口是个特殊场景接收方缓冲区满通告窗口为0发送方停止发送启动持续计时器定期发送窗口探测报文。如果接收方恢复会发送窗口更新通知。这个机制保证了不会因为窗口为0而永久死锁。5. 高频面试题实战拆解与排查技巧5.1 常见问题速查表问题现象可能原因排查命令处理方向连接建不上超时半连接队列满、SYN Floodnetstat -s | grep -i syn调大backlog、开syncookies大量TIME_WAIT主动关闭短连接多ss -tan state time-wait | wc -l长连接、tcp_tw_reuse大量CLOSE_WAIT应用未关闭socketss -tan state close-wait查应用代码传输慢、吞吐低拥塞窗口小、丢包ss -ti看cwnd和retrans调拥塞算法、查网络质量连接被RST端口未监听、防火墙tcpdump抓包查服务状态和规则5.2 抓包分析的基本功面试时如果能说出用tcpdump抓包分析印象分很高。常用命令# 抓取指定端口的所有报文 tcpdump -i eth0 -nn port 8080 -w capture.pcap # 只看SYN和FIN报文 tcpdump -i eth0 -nn tcp[tcpflags] (tcp-syn|tcp-fin) ! 0 # 读取抓包文件并用wireshark分析分析时重点看三次握手是否完成、有没有重传、窗口大小变化、RST出现的位置。我排查过一次连接偶发失败抓包发现是服务端在SYN-ACK后直接发了RST原因是半连接队列满。这种问题不看抓包根本定位不到。5.3 面试答题的层次感同样一个问题答出不同层次效果差别很大。以“TIME_WAIT作用”为例初级等2MSL确保ACK到达、旧报文消散。中级补充主动关闭方才有TIME_WAIT高并发短连接会堆积可用tcp_tw_reuse缓解。高级结合业务场景说明为什么优先改架构而非调内核NAT环境下tcp_tw_reuse的风险以及如何用ss和netstat量化问题。面试官想听的是你有没有真实处理过而不是背了多少。所以准备时每个知识点都问自己一句线上出问题是什么表现我怎么查怎么解决。6. 我整理这套内容时的几点体会网络协议这东西光看书很容易陷入“每个字都认识连起来不知道在说什么”的状态。我的经验是结合抓包和内核参数一起看把抽象的状态机对应到具体的报文和系统调用上理解会快很多。另外面试前不要只背答案试着把每个机制讲给一个完全不懂的人听。如果你能用“打电话”这种类比把三次握手讲清楚说明你是真懂了。比如三次握手就像打电话你拨号SYN对方接起来说“喂”SYN-ACK你说“是我”ACK然后才开始正式聊天。四次挥手就像挂电话你说“我先不说了”FIN对方说“好”ACK对方说完最后一句“再见”FIN你说“收到”ACK然后等一会儿确认对方真挂了再放下话筒TIME_WAIT。最后分享一个我常用的复习方法拿一张白纸画出TCP状态转换图标出每个状态的进入条件、退出条件和超时时间。画不出来就说明还没掌握。这个图能画清楚面试里关于连接管理的问题基本都能应付。