“今天面试又被问TCP了，而且一上来就是‘三次握手为什么不是两次’。”如果你刚参加过几场技术面试，多半对这类问题不陌生。计算机网络是程序员面试绕不开的硬骨头——无论你是校招刚起步、社招要进阶，还是考研复试准备机试和综合面试，这部分考点几乎场场出现。我这些年帮人改简历、做模拟面试，发现一个规律：绝大多数候选人对“三次握手、四次挥手、TCP和UDP区别”这类基础题能倒背如流，但一旦面试官往下追问“Keep-Alive是什么原理”“为什么会出现大量TIME_WAIT”“从输入URL到页面展示发生了什么”，就开始卡壳。
这篇文章就是围绕“计算机网络面试题”这个主题整理的一份实战型复习路线图。我会先把高频面试考点按出题频率分层拆解，再针对每一类核心题目给出能直接拿来用的答题框架和细节补充，最后附上我这几年在真实面试现场听到的经典追问和应对方式。适合正在备战后端、前端、运维、测试、考研复试的读者参考，建议收藏后按章节逐块消化，而不是临阵磨枪。
1. 内容整体设计与思路拆解
计算机网络面试题之所以让人觉得“背不完”，是因为这个领域的知识面太宽。只看《计算机网络》教材，从物理层到应用层，从路由协议到网络安全，每一章都能出题。但如果你把历年面试真题拆开看，会发现真正被反复敲打的考点其实高度集中。
1.1 高频考点的分层策略
面试官问网络题，通常分三层。
第一层叫“概念层”，考查你能不能把抽象机制讲清楚。典型题目包括：TCP三次握手为什么不能改成两次、四次挥手为什么需要TIME_WAIT、TCP和UDP的本质区别、HTTP和HTTPS的差异、Cookie和Session的区别。这些问题并不复杂，但面试官会通过追问来判断你是背了结论还是懂了原理。
第二层叫“机制层”，考查你对协议运行过程的掌握。比如TCP的拥塞控制（慢启动、拥塞避免、快重传、快恢复）、滑动窗口如何做到可靠传输和流量控制、ARP解析流程、DNS解析完整过程。这里如果只背概念、不知细节，很容易被一个“如果某个包丢了会怎样”的追问击穿。
第三层叫“场景层”，这类题最考验综合能力。比如“从浏览器地址栏输入URL到页面展示，中间发生了什么”“如何定位一台服务器网络延迟高的原因”“系统日志显示网络中存在异常流量，你会怎么排查”。这类问题没有标准答案，面试官想听的是你的排查思路、分层分析能力、以及对协议栈的整体理解。
我这篇文章的结构就按这三个层次来组织，每一层都结合高频面试题展开。你会发现，很多看似独立的题目，其实共用同一套底层逻辑——分层模型、可靠传输、连接管理。把这几个核心机制吃透，比背二十道单独的题都管用。
1.2 为什么很多人背了题还是挂
我见过不少候选人在面试前猛刷“面经”，把答案背得滚瓜烂熟，结果还是挂在追问上。原因很简单：面试题本质上是“原理考试”，不是“记忆考试”。
举个例子，“TCP三次握手为什么不是两次”这道题，背答案的人会说“因为要防止旧连接请求突然到达导致资源浪费”。这个说法对不对？对，但对了一半。面试官真正想听到的是两个层面：一是两次握手无法确认双方的收发能力都正常，二是客户端发出的SYN可能因为网络延迟滞留，在连接释放后又被服务端收到，从而建立一条早已过期的连接。能主动把“半连接队列”“SYN Flood”“序列号可预测性”这几个延伸点讲出来的候选人，才算是真正理解了三次握手的设计意图。
这就是为什么我不建议直接背面经。每道题你都得能回答三层：是什么、为什么这么设计、如果改动会带来什么后果。这篇文章后面的每个题目模块，我都按这个思路来拆。
2. 核心高频面试题：原理与答题要点拆解
这一节挑最常考的十几道题目，逐题给出完整的答题路径。每道题我尽量覆盖“答题主线+细节补充+面试官追问方向”，你可以拿它当模拟面试的参考答案。
2.1 TCP三次握手：为什么必须三次
这是所有网络面试中的“题王”，几乎逢面必问。标准回答是：三次握手的目的是确认双方的发送能力和接收能力都正常，并同步初始序列号。
第一次握手，客户端发送SYN报文，服务端收到后，能证明什么？能证明客户端的发送能力正常，服务端的接收能力正常。服务端此时回应SYN+ACK，客户端收到后，能证明客户端的接收能力正常、服务端的发送能力正常。但你注意，到这一步，服务端实际上只知道客户端能发、自己能收，并不知道客户端能不能收。所以还需要最后一次ACK——客户端收到SYN+ACK后，再回一个ACK给服务端，服务端收到后才知道自己的发送能力客户端能正常接收到。
把“两次”和“三次”的区别在这里说清楚，面试官通常会点头。接着他会问：“那两次握手存在什么具体风险？”这时你再抛出旧SYN报文延迟到达的场景：客户端发了一个SYN，因为网络拥堵迟迟没到，客户端等不及重发了新的SYN，旧SYN过了很久才到达服务端。如果是两次握手，服务端收到旧SYN后直接进入ESTABLISHED状态，并分配连接资源，但这个连接早已失效，客户端根本不会理它，服务端资源就被白白占用了。三次握手因为需要客户端回最后的ACK，旧连接请求的SYN即使到达服务端，服务端发出SYN+ACK后收不到客户端的确认，就不会建立起一条可用的连接。
我习惯把这张图在脑子里过一遍：客户端SYN→服务端SYN+ACK→客户端ACK，中间任何一个包丢失，双方都能通过超时重传机制恢复。这才是“三次”在设计上的完整价值。答到这里，后面的追问空间就很大了——为什么要随机初始化序列号、SYN Flood攻击是怎么利用这个机制的，你都能顺势接上。
2.2 TCP四次挥手：TIME_WAIT为什么不能省
挥手次数为什么是四？因为TCP连接是全双工的，每一方的关闭都必须独立完成。主动关闭方发送FIN，表示“我没有数据要发了”，但这只是关闭了主动方到被动方这个方向的数据传输。被动方收到FIN后可能还有数据没发完，所以它不能立刻回FIN，只能先回ACK，等自己数据发完了再发FIN。一来一回，就是四个报文。
很多面试官会追问：“TIME_WAIT为什么需要等待2MSL？”这个问题要分两层答。第一层，保证最后一个ACK能到达被动关闭方。如果最后的ACK丢失，被动方会重发FIN，主动方需要有时间重新发送ACK来结束连接。所以主动方不能立刻进入CLOSED状态，必须留出足够的时间容错。第二层，让旧连接的报文在网络中自然消失。如果立即关闭并立刻用相同的四元组（源IP、源端口、目的IP、目的端口）建立新连接，旧连接中延迟到达的报文就可能被新连接误收。2MSL是报文在网络中最大存活时间的两倍，过了这个时间，网络中不会再残留旧连接的报文。
顺带分享一个很多人踩过的坑：服务器上大量TIME_WAIT连接堆积，会占用系统端口和内存。线上高并发场景下常见“Cannot assign requested address”报错，就是因为客户端端口被TIME_WAIT占满。面试官非常爱拿这个场景考你：怎么处理？调整net.ipv4.tcp_tw_reuse、net.ipv4.tcp_timestamps开启时间戳选项、或者tcp_fin_timeout调小，都是常见方案。但注意，tcp_tw_recycle因为存在NAT场景下的兼容性问题，Linux较新内核已经弃用了，这一点能主动提出来，会显得你有实践积累。
2.3 TCP与UDP：别只答“一个可靠一个不可靠”
这道题看着简单，翻车率却高。常规答案：TCP面向连接、可靠、有拥塞控制、面向字节流；UDP无连接、不可靠、开销小、面向报文。如果只答到这里，面试官会觉得你只是背了教材。
要让答案有区分度，我建议从三个维度展开。
第一个维度是可靠性实现的本质。TCP的可靠不是网络提供的，而是自己通过序号、确认、重传、校验和四个机制拼出来的。UDP不保证不丢包，丢不丢交给上层应用决定。
第二个维度是你对“为什么需要两种协议”的理解。视频通话、游戏实时对战、DNS查询这类场景，延迟比可靠更敏感，丢一帧画面可以重发，但等TCP重传回到正轨时，对话早就不同步了。所以UDP的存在不是“劣于TCP”，而是“设计目标不同”。能举出实际业务场景，比背结论强得多。
第三个维度是面试官常挖的坑：“那现在很多直播用的是什么协议？”大部分直播场景会选RTMP（基于TCP）或WebRTC（基于UDP），不能一概而论。你可以补充一个新的趋势：QUIC协议基于UDP实现了类TCP的可靠传输，融合了两者优点。这个话题一抛出来，面试官会对你印象深刻，因为你能把“教材知识”和“工程前沿”连起来。
2.4 HTTP与HTTPS：握手过程必须能完整讲出来
HTTP的考点集中在：请求方法（GET/POST区别，尤其POST幂等性）、状态码（404、502、301和302的区别）、HTTP1.0/1.1/2.0的核心差异、以及HTTPS的握手过程。
最容易被深挖的是HTTPS握手。面试官常问：“HTTPS多了哪几步？为什么不能直接用非对称加密传输所有数据？”标准答题路径是：客户端先发ClientHello，携带支持的TLS版本、加密套件列表、随机数；服务端回ServerHello，选定加密套件并携带证书和随机数；客户端验证证书合法后，生成预主密钥，用服务端公钥加密后发送；服务端用私钥解密得到预主密钥，双方各自基于随机数+预主密钥计算出会话密钥，之后用对称加密通信。
为什么要混合两种加密？因为非对称加密性能开销大，不适合大量数据传输；对称加密速度快，但密钥不能明文暴露在网络中。所以设计上用非对称加密安全地传递对称密钥，再用对称加密高速传输业务数据。这个“安全传递密钥”的思路，和生活里“先打电话确认门口保险箱密码，再用保险箱传文件”是一个逻辑，面试时用类比辅助讲解，效果很好。
很多人漏掉的细节是证书验证。证书是CA私钥签名的，客户端用CA的公钥验证证书签名，再确认证书域名和当前访问域名一致，还要校验证书有效期和吊销状态。只答“验证证书合法性”而说不出验证内容，容易被追问到底。
2.5 滑动窗口与拥塞控制：把“速度控制”的逻辑讲透
滑动窗口这道题，本质是在问“TCP如何实现可靠传输和高吞吐的平衡”。你要讲清楚三层：发送窗口、接收窗口、拥塞窗口。其中接收窗口（rwnd）是接收方根据自身缓冲区大小通告的，用于流量控制；拥塞窗口（cwnd）是发送方根据网络拥塞程度自行调整的，用于拥塞控制。实际发送窗口大小取决于min(rwnd, cwnd)。
拥塞控制的四条算法流程必须能默写：慢启动、拥塞避免、快重传、快恢复。
慢启动：cwnd从1开始，每个RTT翻倍，呈指数增长，直到达到慢启动阈值ssthresh。
拥塞避免：超过阈值后，每经过一个RTT，cwnd线性加1，呈加法增长，避免过快填满网络缓冲。
快重传：当发送方收到三个重复ACK时，立即重传丢失报文段，不等待超时。原因是连续三个重复ACK说明后续报文已经到达，只是中间某段丢了，这时网络未必拥塞，没必要进入慢启动。
快恢复：收到三个重复ACK后，将ssthresh减半，cwnd设为新的ssthresh（而不是回到1），然后进入拥塞避免阶段。这样可以兼顾丢包恢复和吞吐。
这里有个容易答偏的点：超时重传和快重传触发的处理不同。超时重传意味着网络可能真拥塞了，cwnd直接降为1，重新慢启动；快重传则相对温和，降一半就行。能说清不同丢包场景下的差异化处理，说明你真的理解拥塞控制的工程取舍。
2.6 DNS解析与ARP：流程题怎么答才完整
DNS解析题几乎必考“你访问一个域名，系统是怎么找到IP的”。完整的解析过程是：浏览器缓存→操作系统缓存（hosts文件）→本地DNS服务器（递归查询）→根域名服务器→顶级域名服务器→权威域名服务器。每层的返回结果都可能是IP地址，也可能是下一级服务器的地址。
很多面试官追问的点是“递归查询和迭代查询的区别”。你要能说清楚：客户端对本地DNS服务器通常是递归查询，本地DNS服务器帮我找最终结果就行；本地DNS服务器对其他NS服务器是迭代查询，每次只得到一个“去问谁”的指引，然后自己再去问。一个比喻很好记：递归是“你说我干，干完给你”，迭代是“你问路，交警给你指到下一个路口”。
ARP考的频率不如DNS高，但一旦考就是问“同一网段和跨网段的MAC地址寻址”。同一网段内：发送方查ARP缓存，没有就广播ARP请求，目标主机单播回复，发送方缓存映射后发送数据帧。跨网段的情况容易出错：发送方知道目标IP不在本网段，会把数据帧的目的MAC填成默认网关的MAC，而IP包的目的IP仍是目标主机IP。这个“IP不变、MAC逐跳变化”的细节，是面试官最爱的陷阱。
2.7 Cookie、Session与Token
这道题是Web开发面试和网络面试的交界题。核心要讲清两个维度：身份认证机制的演进，和无状态HTTP协议之间的配合逻辑。
Cookie是服务器下发并存在客户端的小数据块，后续每次请求自动携带在Cookie头里，用于识别用户身份。Session是服务端保存的用户状态，通常通过Session ID关联cookie实现。传统单体应用下，Session存在本机内存，问题在于多实例部署时用户请求可能落在不同实例上，Session不一致，所以有了Session粘滞、Session共享、以及干脆把状态外置到Redis的方案。
Token方案（典型的是JWT）把用户信息加密后存到客户端，服务端无状态验证签名即可。理解JWT的签名机制（Header.Payload.Signature）和验证流程，是答好这道题的关键。面试官会追问优缺点：JWT天然适合分布式、跨端场景，但难以主动失效，泄露后风险高，Payload里别放敏感数据。这道题能答到“无状态和可扩展性的取舍”层面，基本就过关了。
3. 实战场景：从URL输入到页面展示的完整链路
“在浏览器输入www.example.com并回车，到页面显示出来，中间发生了什么”——这是所有网络场景题里的“母题”。答好这道题，等于把整个协议栈串了一遍。我建议按以下顺序逐步拆解，每一步都带上对应的协议和可能被追问的细节。
3.1 输入、解析与本地查找
用户在地址栏输入URL并回车。第一步是解析URL，确定协议类型（HTTP还是HTTPS）、域名、端口号和路径。如果端口没有显式写出，HTTP默认80，HTTPS默认443。
然后浏览器会先查本地缓存。查找顺序大体是：浏览器缓存→系统缓存→hosts文件。如果本地没有记录，就会发起DNS解析。这里可以顺带提一句DNS缓存污染和DNS劫持的防护（比如DNSSEC、加密DNS），会显得你有安全意识。
3.2 TCP连接与HTTP请求发起
拿到目标IP后，浏览器发起TCP连接。如果是HTTPS站点，还需要先完成TLS握手，在TCP连接之上建立安全通道。接着浏览器构造HTTP请求报文（方法、URL、协议版本、头部字段），交给TCP层。
注意，TCP层会根据MSS（最大报文段长度）把HTTP报文拆分成分段，每个分段加上TCP头，再交给IP层封装成数据报。数据链路层再封装成以太网帧，加上源MAC和目的MAC（目的MAC通常是网关的MAC）。这一段的完整链路能说出来，面试官能直观看到你对分层模型的理解。
3.3 服务端处理与响应返回
请求包经过交换机、路由器层层转发到达服务端。服务端先解析HTTP请求，由Web服务器（Nginx、Apache等）处理或转发给应用容器。应用生成响应内容，同样按TCP/IP协议栈逐层封装后发送回客户端。
返回过程中，如果响应体积很大，HTTP1.1版可以选择Keep-Alive复用连接减少握手开销，HTTP/2则可以在同一条连接上并行多路复用。这些关联考点如果由你主动引出，会有加分效果。
3.4 浏览器渲染
浏览器收到响应后，按HTML、CSS、JavaScript顺序解析并渲染页面。同时，浏览器会为页面引用的图片、样式、脚本等资源再次发起HTTP请求——如果使用了HTTP/2的服务器推送或预加载，部分资源可以提前送到，这也是一个值得谈的优化点。
很多人在这道题上止步于“DNS解析+TCP连接+发送HTTP请求”，显然深度不够。如果你把每一步的缓存、失败重试机制、以及密码学细节都补上，整道题大概能口述十分钟，面试官对你的评价会提升一个档次。
4. 经典问题排查：真实面试里的“异常场景题”
从热搜词里可以看到不少人都搜过“系统检测到您的计算机网络中存在异常流量，请稍后重新发送请求”这句话。这类提示听起来像是网关或风控系统的策略拦截，但放到面试里，它对应的其实是另一大类问题：网络故障排查和攻击应急响应。这里我整理几个高频的异常排查场景。
4.1 网络延迟高、丢包怎么定位
面试官可能会给你一个假设场景：线上服务调用另一个服务的接口，耗时从10ms涨到500ms，你怎么定位？
标准的排查路径是分层定位。先确认是网络问题还是应用问题：直接ping目标IP，看RTT和丢包率；再用telnet或nc测试目标端口连通性，排除防火墙拦截。如果ping正常但业务耗时高，就要看应用层是否有慢SQL、锁竞争、GC停顿。
再进一步，可以用traceroute逐跳检查路由链路，看哪一跳延迟异常。如果跨地域调用延迟高，对端是否有丢包重传？怀疑到TCP层时，ss或netstat命令查看连接状态、重传计数，配合tcpdump抓包看是否有大量TCP重传。这套“从物理层到应用层逐层排查”的思维方式，比直接给结论重要得多。
4.2 大量TIME_WAIT、CLOSE_WAIT意味着什么
短连接高并发场景下，服务器上出现大量TIME_WAIT是正常现象，但数量过多会导致端口耗尽。你先用ss -s或netstat查看连接状态统计。TIME_WAIT多在主动关闭方，调优方向是缩短FIN_WAIT超时、开启tcp_tw_reuse。
更值得警惕的是CLOSE_WAIT堆积。CLOSE_WAIT是被动关闭方发出的ACK之后、尚未调用close()时的状态，如果数量一直在涨，通常意味着应用代码里忘了关闭连接——比如HTTP客户端连接池释放逻辑有bug、文件流未关闭。遇到这种问题，别急着调内核参数，先从代码里找连接泄漏。这个解答思路能把“考官”从运维视角带到开发视角，很有实战说服力。
4.3 “系统检测到异常流量”对应的网络攻击类型
面试中谈到安全话题，常会问“你遇到过网络异常流量吗？如何分析和防护”。常见的攻击类型包括SYN Flood、UDP Flood、DNS放大攻击等。
SYN Flood是典型的DDoS方式：攻击者发送大量SYN请求但不完成第三次握手，服务端半连接队列被塞满，正常用户的连接请求无法处理。防护手段一般是启用SYN Cookie——当半连接队列满时，不再分配连接资源，而是通过计算和编码方式生成一个特殊的初始序号放在SYN+ACK里，客户端在ACK中带回该序号，服务端验证通过后才分配资源。这个机制把“资源消耗”从握手期间延迟到确认之后，有效缓解了虚假连接请求。
遇到这类问题，如果还能补充一下自己在业务侧的容灾经验——比如限流、熔断、降级，以及多层网关清洗流量——安全能力就立体起来了。
5. 工具选型与备考资源怎么选
这部分给正在复习的人一点资源参考。市面上常用教材有三类：谢希仁版《计算机网络》、电子工业出版社的《计算机网络：自顶向下方法》（就是大家常说的“第八版”）、以及王道考研系列。经常有人把谢希仁版本的第七版、第八版搞混，其实第八版是谢希仁老师更新过的版本，添加了部分新技术内容；而“自顶向下”第八版更侧重应用层出发的理解路径，适合编程基础较好的人。
5.1 教材搭配建议
如果你目标是考研408，王道系列配合谢希仁教材是主流路线。王道计算机网络偏向考点归纳和习题训练，能够快速抓重点，但原理铺垫较少；谢希仁教材语言通俗、适合第一遍建立整体认知。时间有限的情况下，我建议以王道为主、谢希仁为辅，把课后题刷透。
如果你目标是互联网大厂面试，我反而更推荐《计算机网络：自顶向下方法》。它从应用层往下讲，每个协议都会结合Socket编程等实例，读起来更像“工程师视角”。面试其实不怎么考OSI七层每一层的功能背诵，而更关注TCP/IP实际工作过程，这恰恰是自顶向下教材的长项。
5.2 在线资源和刷题方法
B站上“湖科大教书匠”的计算机网络课程对408考生来说口碑很好，讲解细致、配套动画直观，适合二轮复习查漏补缺。很多人会纠结“湖科大教书匠适合考408吗”——我的看法是：适合用来做知识点理解性补充，但不建议当作唯一课程。它的内容覆盖面很贴近考纲，可408真题的出题风格和深度还是需要回到王道、历年真题上去适应。
刷题方面，牛客网、力扣的计算机网络题区以及历年408真题都是很好的素材。有一个技巧是“刷题时按场景归类”：把题目分成连接管理、可靠性、HTTP、安全、场景排查五大类，每类整理出自己的答题模板。这样面试时不管题目怎么变，你都能迅速定位到对应的知识模块。
5.3 模拟面试的重要性
准备网络面试题，只看不练效果很有限。我强烈建议你找朋友或同伴互相提问，一次只问一个知识点，但必须追问到底。比如对方答完三次握手，你接着问“如果SYN丢了呢”“如果第三次握手ACK丢了呢”“如果客户端故意不回呢”“如果网络中有中间人篡改呢”，这种连环追问才能暴露理解漏洞。
如果找不到人练习，可以自己对着录音设备讲。讲完回放一遍，你会惊讶地发现自己很多地方“以为会了，其实讲不顺”。每次把卡壳的地方标记出来，就是下一轮复习清单。
6. 面试作答技巧：怎么把“会”变成“得分”
很多候选人技术理解不差，但面试表达不行。这一节分享几个我在模拟面试中总结的高分表达习惯。
6.1 STAR法则怎么用到技术题上
STAR法则本来用于行为面试，但技术题同样有效。S（背景）先说明场景，比如“线上服务端出现大量TIME_WAIT”；T（任务）说明目标，比如“要避免端口耗尽，同时不破坏连接可靠性”；A（行动）讲清楚你的操作，比如“先通过netstat统计TIME_WAIT数量，再用tcp_tw_reuse配置”；R（结果）收束到效果，比如“端口占用率下降92%，业务重试报错消失”。
这样答题信息完整，面试官听一层就能判断你的实践深度。背结论只回答了A，逃避了背景和验证过程，落在纸面上就是“没有实证思维”。
6.2 回答问题的“三层递进法”
我建议技术题按照“定义→原理→工程实践”三层组织答案。比如被问到HTTPS，先一句话定义“在HTTP和TCP之间加入了TLS/SSL层”；然后讲握手流程和非对称/对称加密配合原理；最后补一个工程细节，比如“证书失效如何快速发现、TLS1.3相比1.2优化了什么”。三层答完，即使中间说错一个细节，面试官对你的整体判断也已经拉高了。
6.3 “不知道”的正确回答方式
面试中一定会遇到不会的题。最关键的应对原则是：不要硬编，也不要立刻说“不知道”。先复述问题，确认自己的理解对不对——如果能拆出两三成线索，就先讲自己确定的部分。比如面试官问“QUIC协议的连接迁移是怎么实现的”，如果你只知道QUIC基于UDP，你可以说：“QUIC的设计目标之一是通过Connection ID来标识连接，这样即使客户端IP变化也不需要重新握手，具体细节这块我还没有在工程中深入实践过，但我理解它解决的是移动端网络切换的重连成本问题。”
这种回答展示了你已知的边界、逻辑推理能力和坦诚态度，比硬编一个“答案”好得多。
7. 高频题速查表与备战清单
最后给你一份可以直接打印的速查表。这是我在模拟面试过程中反复迭代整理出来的核心提纲，覆盖面试中出现频率最高的知识点，适合面试前一小时快速过一遍。
7.1 协议与机制速查
| 知识点 | 必答要点 | 延伸加分点 |
|---|---|---|
| 三次握手 | 确认双方收发能力、同步序列号 | 半连接队列、SYN Cookie |
| 四次挥手 | 半关闭机制、TIME_WAIT时长2MSL | 端口耗尽、tcp_tw_reuse |
| TCP可靠传输 | 序号、确认、重传、校验 | 累积确认、选择性确认SACK |
| 流量控制 | 接收窗口rwnd限制发送速度 | 窗口缩放因子、零窗口死锁 |
| 拥塞控制 | 慢启动、拥塞避免、快重传、快恢复 | 丢包类型与cwnd调整差异 |
| HTTP状态码 | 1xx/2xx/3xx/4xx/5xx大类 | 301与302、503与504区别 |
| HTTPS握手 | 证书验证、非对称传密钥 | 中间人攻击、TLS1.3特性 |
| DNS解析 | 递归与迭代、缓存分级 | DNS污染、HTTPDNS |
7.2 高频场景题答题模板
- 建连失败：先确认本地网络→ping目标IP→测试端口→检查防火墙策略→抓包分析SYN/ACK响应情况。
- 请求响应慢：应用层耗时监控→DNS解析耗时→TCP握手日志→traceroute逐跳检查→带宽占用分析。
- 连接被重置：排查是否有安全设备RST丢包、应用代码异常关闭、TCP Keep-Alive探测超时。
- 接口偶发超时：重点看TCP重传、丢包率、服务端背压（backpressure）、GC暂停。
- 系统检测到异常流量：先看防火墙/网关流量日志，区分外网攻击还是内网扫描，再联动限流和清洗策略。
7.3 复习节奏建议
准备周期我建议拆成三周：第一周打通“原理层”，把你薄弱章节的教材内容过一遍；第二周集中刷题，把高频题整理成自己的“答题稿”，每道题能做到脱稿口述三分钟；第三周做模拟面试和场景题复盘，重点练追问和排查思路。
前面提到的“湖科大教书匠”、王道、谢希仁教材、自顶向下第八版，各有定位，不必贪多。取其中一到两套作为主干，把核心协议栈吃透，比扫过五本书却一问三不知要有效得多。我见过太多人把时间花在“收集资料”而不是“消化内容”上，资料越存越多，能力却原地踏步。
我在实际做模拟面试时还有一个体会：网络题特别讲究“边说边画”。不管是三次握手还是拥塞控制，你在纸上画出状态图和时序图，边说边指，表达会流畅很多，考官也更容易跟住你的思路。准备面试时养成动手画图的习惯，面试现场不会慌。这套复习框架我自己用过、也帮人用过，实操下来对面试表现的提升非常明显。接下来就是你的事了——打开一份真题集，从第一道TCP题开始，不止背结论，把原理和场景打通，面试场上你就赢了大多数竞争者。
