1. 为什么网络知识成了面试的“必答题”
但凡面过几家像样的公司，你大概率会发现一个规律：越是大厂或者基础架构团队，越喜欢在计算机网络这块往深了问。不是他们故意刁难人，而是网络这东西太底层了——你写业务代码可能感觉不到它的存在，可一旦线上出问题，比如接口超时、连接泄漏、吞吐上不去，最后排查下去十有八九会落到 TCP、HTTP 或者 DNS 这些环节上。面试官问网络，本质上是在筛掉那些只会调 API、出了问题只能重启服务的人。
我自己带过几个新人，也当过不少次面试官，慢慢摸出一个门道：网络面试题其实翻来覆去就那么几大块，TCP 三次握手四次挥手、HTTP 与 HTTPS、TCP 与 UDP 的区别、从输入 URL 到页面展示发生了什么、常见状态码、拥塞控制、粘包拆包。这些题年年考、家家考，但真正能答到点子上的人并不多。大部分人背了八股文，一问细节就露馅，比如问他“为什么挥手要四次而不是三次”，他只能背出“因为要等服务端处理完”，再追问“那 TIME_WAIT 为什么是 2MSL”，就卡住了。
这篇内容就是把我这些年复习网络、面试别人、被面试的经验揉在一起，按知识模块拆开讲，每个点都尽量说清楚“为什么”，而不是只给结论。适合正在准备面试的初中级开发，也适合工作几年但网络基础一直没系统补过的朋友。我不会只列知识点，而是会告诉你哪些是高频考点、哪些是加分项、哪些答错了直接减分，以及怎么用生活化的例子把复杂机制讲明白——面试时你能把面试官讲懂，比背标准答案管用得多。
2. 整体复习思路与知识框架拆解
2.1 先搞清楚面试官到底想考什么
很多人复习网络的方式是打开一本《计算机网络》教材从第一章啃起，啃到物理层就放弃了。这方向就错了。面试不是期末考试，它不考你记不记得 OSI 七层每一层的名字，它考的是你能不能把网络知识用到实际工程里。所以复习的第一步，是搞清楚面试官的问题背后想验证什么能力。
我总结下来，网络面试题大致分三类。第一类是概念辨析题，比如 TCP 和 UDP 的区别、HTTP 和 HTTPS 的区别，考的是你基础扎不扎实。第二类是机制原理题，比如三次握手为什么不是两次、拥塞控制怎么工作，考的是你理解得深不深。第三类是场景排查题，比如“线上大量 TIME_WAIT 怎么办”“接口偶发超时怎么定位”，考的是你能不能把知识用起来。前两类靠复习能搞定，第三类才是真正拉开差距的地方，也是我后面会重点展开的。
2.2 一张图理清复习优先级
网络知识点多且杂，如果时间有限，必须按性价比排序。我按“面试出现频率”和“答错扣分程度”两个维度，把核心考点分成三档：
| 优先级 | 知识点 | 出现频率 | 说明 |
|---|---|---|---|
| 第一档 | TCP 三次握手/四次挥手、TCP 与 UDP 区别、HTTP 状态码、HTTP 与 HTTPS | 极高 | 几乎每场必问，必须答得滴水不漏 |
| 第二档 | 拥塞控制、流量控制、粘包拆包、DNS 解析、从 URL 到页面展示 | 高 | 中高级岗位常问，能体现深度 |
| 第三档 | ARP、NAT、子网划分、HTTP/2 与 HTTP/3、QUIC | 中 | 加分项，答好了很出彩 |
我的建议是：第一档必须滚瓜烂熟，第二档要能讲清楚原理，第三档至少知道概念。别一上来就去抠 HTTP/3 的 QUIC 握手细节，那是锦上添花，先把地基打牢。
2.3 复习方法：别背，要“讲”
我试过一个很有效的复习方法，分享给你：每复习一个知识点，就假装面前坐着一个面试官，用嘴把它讲一遍，讲不顺的地方就是你没真懂的地方。比如“三次握手”，你如果能不看资料、用大白话把“为什么是三次、每次发了什么、状态怎么变、少了会怎样”完整讲出来，那这个点就过关了。背下来的东西一紧张就忘，讲明白的东西是长在脑子里的。
另外，复习时一定要带着问题去查。比如你看到 TIME_WAIT，别只记“等 2MSL”，要问自己：为什么是 2MSL 不是 1MSL？如果不等会怎样？服务端出现大量 TIME_WAIT 和客户端出现大量 TIME_WAIT 分别意味着什么？这样一层层问下去，知识就串起来了。
3. TCP 核心机制：面试重灾区逐个击破
3.1 三次握手：为什么偏偏是三次
三次握手是网络面试的“开胃菜”，但也是最容易答砸的题。标准答案大家都背过：客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK。但面试官真正想听的是为什么是三次，两次行不行。
核心原因在于：TCP 是全双工协议，双方都要确认自己和对方的收发能力都正常。两次握手只能确认“客户端能发、服务端能收”和“服务端能发、客户端能收”，但服务端无法确认“客户端能收自己的包”。举个生活化的例子：你打电话给朋友，你说“喂，能听到吗”，朋友说“能听到，你能听到我吗”，你回“能听到”。这三句话缺一不可，少了最后一句，朋友不确定你是不是真能听到他。
还有一个经典问题是为什么不是四次。因为服务端的 SYN 和 ACK 可以合并成一个包发出去，没必要拆成两次，所以三次就够了。这里有个细节很多人忽略：第三次握手时，客户端是可以携带数据的，但前两次不行。因为前两次握手还没建立可靠连接，带数据可能导致混乱。
注意：面试时如果被问到“第三次握手丢了会怎样”，别慌。答案是服务端会超时重传 SYN+ACK，客户端收到重复的 SYN+ACK 后会再发一次 ACK。如果一直收不到，服务端最终会放弃并关闭连接，而客户端此时可能已经认为连接建立了，这就是所谓的“半连接”问题。
3.2 四次挥手：多出来的一次到底在等什么
四次挥手比三次握手多一次，很多人背了但说不清原因。关键在于：TCP 连接是全双工的，关闭需要两个方向分别关。客户端发 FIN 表示“我没数据要发了”，但此时服务端可能还有数据没发完，所以它先回一个 ACK 表示“知道了”，等自己数据发完了再发 FIN 表示“我也发完了”，客户端再回 ACK 确认。这就成了四次。
这里最容易被追问的是TIME_WAIT 状态。主动关闭连接的一方在发完最后一个 ACK 后会进入 TIME_WAIT，等待 2MSL（报文最大生存时间的两倍）才真正关闭。为什么要等？两个原因：一是确保最后一个 ACK 能到达对方，如果对方没收到会重传 FIN，此时自己还在 TIME_WAIT 就能再回一次 ACK；二是让本次连接的所有报文在网络中消散，避免影响下一个用相同四元组的新连接。
实操心得：线上如果发现服务器有大量 TIME_WAIT，通常是服务器主动关闭了大量短连接。解决办法不是简单调小 TIME_WAIT 时间，而是考虑用连接池复用连接，或者让客户端主动关闭。我踩过的坑是：曾经有个服务 QPS 一高就报“Cannot assign requested address”，排查半天发现是客户端端口被 TIME_WAIT 占满了，最后改成连接池才解决。
3.3 TCP 与 UDP：不只是“可靠”和“不可靠”
“TCP 可靠、UDP 不可靠”这个答案只能拿及格分。面试官想听的是它们各自适合什么场景，以及为什么。
TCP 的可靠性是靠一堆机制堆出来的：序列号、确认应答、超时重传、流量控制、拥塞控制。代价就是慢、开销大、有连接状态。UDP 则把这些全砍了，只保留最基本的“发出去”能力，所以快、轻量，但丢包、乱序、重复都得应用层自己处理。
| 对比维度 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接 | 无连接 |
| 可靠性 | 可靠，有重传 | 不可靠，尽力而为 |
| 传输方式 | 字节流 | 数据报 |
| 头部开销 | 20 字节起 | 8 字节 |
| 适用场景 | 文件传输、网页、邮件 | 视频直播、游戏、DNS |
这里有个高频追问：为什么视频直播用 UDP 而不是 TCP。因为直播对实时性要求极高，宁可丢几帧也不能卡顿。如果用 TCP，一旦丢包就会触发重传和拥塞控制，导致画面卡住等重传，体验反而更差。UDP 丢了就丢了，画面花一下但继续播，这才是直播要的。
3.4 拥塞控制：网络世界的“交通疏导”
拥塞控制是 TCP 里最复杂的部分，也是区分“背过”和“真懂”的分水岭。它的核心思想是：发送方不能只顾自己猛发，要根据网络状况动态调整发送速率。四个阶段要记牢：慢启动、拥塞避免、快重传、快恢复。
慢启动不是“慢”，而是“指数增长”。一开始拥塞窗口 cwnd 设为 1 个 MSS，每收到一个 ACK 就翻倍，1、2、4、8……直到达到慢启动阈值 ssthresh，进入拥塞避免阶段，改成线性增长，每个 RTT 加 1。一旦发生超时重传，说明网络严重拥塞，ssthresh 减半，cwnd 重置为 1，重新慢启动。如果是收到三个重复 ACK，说明只是个别丢包，触发快重传和快恢复，ssthresh 和 cwnd 都减半，然后线性增长。
提示：面试时如果能说出“慢启动的‘慢’是指起点低，不是增长速度慢”，面试官会对你刮目相看。这个细节能体现你是真理解而不是背的。
4. HTTP 与 HTTPS：从请求到响应的全链路
4.1 HTTP 状态码：别只记 200 和 404
状态码是面试的送分题，但也是最容易暴露基础不牢的地方。除了 200 和 404，至少要记住这几类：3xx 重定向、4xx 客户端错误、5xx 服务端错误。重点说几个高频的。
301 和 302 的区别：301 是永久重定向，浏览器会缓存，下次直接跳新地址；302 是临时重定向，每次都会先请求原地址。SEO 场景下用错会导致权重转移问题。304 Not Modified是协商缓存命中，服务端告诉浏览器“你缓存的还能用”，不返回 body，省流量。502 Bad Gateway和504 Gateway Timeout是网关类错误，502 是后端返回了无效响应，504 是后端超时没响应，排查方向完全不同。
| 状态码 | 含义 | 常见原因 |
|---|---|---|
| 301 | 永久重定向 | 域名更换、HTTPS 强制跳转 |
| 302 | 临时重定向 | 登录跳转、活动页 |
| 304 | 资源未修改 | 协商缓存命中 |
| 400 | 请求错误 | 参数格式不对 |
| 401 | 未认证 | 没带 token |
| 403 | 禁止访问 | 权限不足 |
| 502 | 网关错误 | 后端服务挂了 |
| 504 | 网关超时 | 后端处理太慢 |
4.2 HTTPS 握手：加密到底怎么加的
HTTPS 是 HTTP 加上 TLS 加密，面试常问“HTTPS 握手过程”。完整过程比较绕，我把它简化成四步：客户端发 ClientHello（支持的加密套件、随机数）→ 服务端回 ServerHello（选定的套件、随机数、证书）→ 客户端验证证书，用公钥加密一个预主密钥发过去 → 双方用三个随机数算出会话密钥，之后用对称加密通信。
这里的关键点是：非对称加密只用来交换密钥，真正传数据用的是对称加密。为什么？因为非对称加密太慢，对称加密快得多。证书的作用是防止中间人攻击，客户端通过 CA 的公钥验证证书签名，确认服务端身份。
注意：面试时如果被问到“HTTPS 一定安全吗”，别答“一定”。HTTPS 保证的是传输过程加密和身份认证，但如果服务端本身有漏洞、或者用户点了钓鱼证书，照样不安全。这个回答能体现你的辩证思维。
4.3 从输入 URL 到页面展示：一道题串起整个网络栈
这道题是网络面试的“终极综合题”，能答好它，基本说明你网络知识成体系了。完整流程我拆成八步：
- DNS 解析：浏览器缓存 → 系统缓存 → hosts 文件 → 本地 DNS 服务器 → 根域名服务器逐级查询，拿到 IP。
- 建立 TCP 连接：三次握手。
- 如果是 HTTPS，进行 TLS 握手。
- 发送 HTTP 请求：请求行、请求头、请求体。
- 服务端处理并返回响应。
- 浏览器解析 HTML，构建 DOM 树。
- 遇到静态资源（CSS、JS、图片）再发请求，可能复用连接。
- 渲染页面，断开连接（四次挥手）。
每一步都能展开问，比如 DNS 用 UDP 还是 TCP（查询用 UDP，区域传送用 TCP）、为什么 DNS 通常用 UDP（快、开销小）。这道题答好了，面试官对你的评价会直接上一个台阶。
5. 高频场景排查：把知识用起来
5.1 粘包拆包：TCP 的“锅”还是应用层的
粘包拆包是面试常问的实操题。首先要澄清一个概念：TCP 是字节流协议，它根本不认识“包”的边界，所以严格说不是 TCP 粘包，而是应用层没处理好消息边界。发送方连发两条消息，接收方可能一次收到两条粘在一起，也可能一条被拆成两次收到。
解决办法有三种：固定长度、特殊分隔符、消息头带长度字段。最常用的是第三种，比如自定义协议头里放一个 4 字节的长度字段，接收方先读长度再读内容。Netty 里用 LengthFieldBasedFrameDecoder 就是干这个的。
实操心得：我曾经写过一个基于 TCP 的 RPC 框架，一开始没处理粘包，本地测试没问题，一上压力测试就各种解析错误。后来加了长度字段才稳定。这个坑很典型，面试时讲出来特别加分。
5.2 大量 TIME_WAIT 和 CLOSE_WAIT 怎么排查
这两个状态是线上排查的高频问题，面试也爱问。TIME_WAIT 多说明本机主动关闭了大量连接，通常是短连接太多。CLOSE_WAIT 多说明本机收到了对方的 FIN 但自己没调 close，通常是代码 bug，比如连接没关闭、异常没处理。
| 状态 | 出现在哪方 | 常见原因 | 解决方向 |
|---|---|---|---|
| TIME_WAIT | 主动关闭方 | 短连接过多 | 连接池、调整内核参数 |
| CLOSE_WAIT | 被动关闭方 | 代码没关连接 | 检查代码、加超时 |
排查命令很简单：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'，一眼就能看出哪个状态多。CLOSE_WAIT 基本就是代码问题，别想着调内核参数糊弄过去。
5.3 接口偶发超时：从网络层怎么定位
接口偶发超时是后端最常见的疑难杂症。我的排查顺序是：先看是不是 DNS 解析慢（换 IP 直连试试）→ 再看是不是 TCP 连接建立慢（抓包看握手耗时）→ 再看是不是 TLS 握手慢 → 最后看是不是服务端处理慢。用curl -w可以打印各阶段耗时，非常直观：
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com如果 DNS 耗时长，考虑加缓存或换 DNS 服务器；如果 TCP 耗时长，可能是网络抖动或服务端 backlog 满了；如果 TTFB 长，那就是服务端处理慢，得去查后端了。
6. 复习节奏与临场应对技巧
6.1 按“天”拆分的复习计划
如果你有一周时间复习网络，我建议这样分配：第 1-2 天攻 TCP（握手挥手、状态机、拥塞控制），第 3 天攻 HTTP/HTTPS（状态码、缓存、握手），第 4 天攻 DNS 和从 URL 到页面展示，第 5 天攻场景排查题，第 6 天自己模拟面试讲一遍，第 7 天查漏补缺。每天复习完，合上资料用嘴讲一遍，讲不顺的记下来第二天重点看。
6.2 面试时不会答怎么办
遇到不会的题，千万别瞎编。我的经验是：先说出你知道的相关知识，再坦诚说明这块没深入过，最后表达学习意愿。比如被问到 QUIC，你可以说“QUIC 是基于 UDP 的传输协议，主要解决 TCP 队头阻塞问题，具体握手细节我还没深入研究，回去会补上”。这样既展示了知识面，又显得诚实。
提示：面试官往往更看重你的思考过程，而不是标准答案。遇到场景题，可以边想边说：“我先确认一下，这个超时是偶发还是必现？偶发的话我倾向于先排查网络抖动……”这种互动式回答比闷头背答案强得多。
6.3 几个容易被忽略的加分细节
最后分享几个我亲测有效的加分技巧。第一，主动画图。面试时如果能说“我画个图解释一下”，然后画出三次握手的状态变化，面试官会觉得你表达能力强。第二，联系实际项目。讲拥塞控制时带一句“我之前做文件传输时遇到过带宽上不去，后来发现是慢启动阶段太短”，瞬间就有说服力了。第三，承认知识的边界。网络领域太深，没人全懂，坦然说“这块我不熟”比硬答更让人信任。
我自己面过不少人，也被人面过很多次，最大的体会是：网络面试考的不是记忆力，而是你理解得有多透、能不能讲清楚。把每个知识点都问自己三个“为什么”，比刷一百道题都管用。复习到后期，你会发现这些知识不再是孤立的点，而是连成了一张网——从你敲下回车到页面出现，中间每一步你都能说出个所以然，那时候面试就稳了。
