后端面试里，计算机网络几乎是绕不开的一块硬骨头。我自己备考那会儿就发现，不管面初级还是高级岗位，面试官只要想快速验证候选人是不是具备合格的工程思维，第一个切入点往往就是网络问题：小到“输入网址后发生了什么”，大到“服务间调用超时、连接池报错怎么排查”。网络协议不是孤立的面试题，它直接决定了你理解 RPC、消息队列、分布式事务这些后端主线知识的深浅。所以我把这个“后端面试系列”的第一大块给了计算机网络，并且会持续更新，争取把每个高频考点拆到让基础薄弱的读者也能照着复述、照着实战。
这个系列不是写给网络工程岗的教材，而是专门面向后端开发的面试知识图谱与实践心得。我会沿着“面试官最常问、生产环境最常用”两条主线展开，覆盖 TCP/UDP、HTTP/HTTPS、DNS、WebSocket、网络排查工具和答题套路。每讲一个知识点，我会补上它在真实业务中对应的问题场景，以及我已经打磨过的“面试话术”。适合谁看？准备校招的应届生、想跳槽的初中级后端，以及带团队想给成员做网络基础梳理的资深开发，应该都能从里面拿走一些东西。
1. 先画考点地图：计算机网络在后端面试里究竟考什么
1.1 面试官考察网络知识的三个深层动机
很多人以为面试官问网络题只是“八股文考背功”，这个想法会害了你。我后来作为面试官参与过几次招聘，发现大家问网络题的真实动机其实很集中。
第一个动机是想判断你能不能理解“服务间通信的本质”。后端开发每天都在写接口、调数据库、连缓存，这些动作背后都是一次次网络传输。如果你只懂 API 层面的参数和返回值，却不理解 TCP 连接如何建立、HTTP 请求为什么失败，遇到线上问题就只能靠重启和试，定位效率极低。
第二个动机是考察你的知识是否成体系。网络知识不是一条条孤立结论，而是一层叠一层的协议栈。面试官从“TCP 三次握手”问到“HTTP 为什么基于 TCP 而不是 UDP”，再问到“WebSocket 和 HTTP 什么关系”，其实是在验证你脑子里有没有一张完整的分层地图。
第三个动机最容易被忽略：网络题是压力测试的绝佳素材。因为网络协议细节多、边界多，面试官可以一层层追问下去，看你在被连续追问时是慌乱瞎编，还是能坦诚边界。很多人挂在最后不是因为不会，而是因为被问急了开始胡诌。
1.2 考点优先级与复习路线表
后端岗位的计算机网络考点非常多，但出题频率差异巨大。我根据自己和身边朋友的面经，整理了一张优先级表格，你也可以按这个顺序安排复习时间。
| 优先级 | 考点 | 出现频率 | 典型问法 |
|---|---|---|---|
| P0 | TCP 三次握手、四次挥手、可靠性机制 | 几乎必问 | 为什么是三次不是两次 |
| P0 | HTTP/HTTPS 核心机制与状态码 | 几乎必问 | 502 和 504 有什么区别 |
| P0 | 输入 URL 到页面展示的完整过程 | 高频 | 从输入网址到看到页面经历了什么 |
| P1 | TCP 拥塞控制、流量控制 | 高频 | 慢启动和拥塞避免有什么区别 |
| P1 | TCP 与 UDP 对比 | 高频 | 直播场景为什么用 UDP |
| P1 | Cookie、Session、Token 对比 | 高频 | 分布式下 Session 怎么共享 |
| P2 | DNS 解析过程 | 中频 | 浏览器怎么找到服务器 IP |
| P2 | WebSocket 握手与场景 | 中频 | WebSocket 和 HTTP 有什么关系 |
| P2 | HTTP 版本演进（1.1/2.0/3.0） | 中频 | HTTP/2 解决了什么问题 |
| P3 | 网络排查命令与工具 | 低频但在简历里很加分 | 线上接口超时你怎么查 |
这张表不是让你按顺序从 P0 背到 P3，而是提示你优先级高的部分要能扛住追问。P0 的内容至少要能流畅讲五分钟以上，P1 要能讲清楚原理和场景，P2 要能说出关键流程，P3 要有真实操作经验。下面我从 P0 的 TCP 开始，一节一节拆。
2. 必考基石：TCP/IP 从三次握手到拥塞控制
2.1 三次握手：少一次都不行，多一次也尴尬
TCP 三次握手是面试中出镜率最高的问题，几乎没有任何一场后端面试会放过它。标准流程大家都能背：客户端先发 SYN，服务端回 SYN+ACK，客户端再回 ACK。但如果面试官继续追问“为什么偏偏是三次，能不能两次”，很多人的回答就开始含糊了。
要答好这个问题，得从两个角度理解。第一个角度是“能力确认”：第一次握手，服务端确认了客户端的发送能力和自己的接收能力；第二次握手，客户端确认了自己的发送接收能力和服务端的发送能力；第三次握手，服务端确认了客户端能正常接收。只有三次才能让双方都确认“我能发你也能收”这个事实。第二个角度是“防止历史连接”：如果只有两次握手，一个在网络里滞留的旧 SYN 请求可能被服务端当成新连接建立起来，导致资源浪费。第三次握手让客户端有机会告诉服务端“我根本没想连这个旧的”，服务端收到确认后才会放弃。
我建议大家准备一个直观类比：两个人打电话，A 说“喂能听到吗”，B 说“听到听到，你能听到我吗”，A 再说“能听到，开始说正事”。这三次交互不只是礼貌，而是为了确认双向通道都是通的。
面试中还经常连带着问 SYN Flood。原理很好理解：攻击者只发第一次 SYN 握手包，不回第三次 ACK，服务端会一直维持半连接队列等待确认，内存和连接资源被耗尽。常见缓解手段有 SYN Cookie，服务端在收到 SYN 后不直接分配资源，而是把状态编码进响应包的序号里，等收到 ACK 再真正建立连接。这个细节在面试里讲出来，会明显拉开和只会背三步流程的人的差距。
握手成功率还会受全连接队列影响，这里有个容易踩的坑：如果应用层的 accept 处理慢，全连接队列被打满，就算三次握手流程走完了，内核也会丢包或者延迟握手，客户端表现就是“连接超时但 ping 得通”。后文排查部分我会再展开。
2.2 四次挥手：TIME_WAIT 为什么值得单独追问
四次挥手也是必背题，但这块面试官通常不只是问“谁先关闭”，而是会追问 TIME_WAIT 状态。先记住标准流程：主动关闭方发 FIN，被动方回 ACK；被动方继续发数据，发完再发 FIN；主动方回 ACK 后进入 TIME_WAIT，等待 2MSL（报文最大生存时间的两倍）后连接才彻底消失。
为什么 TIME_WAIT 要等 2MSL？两个核心原因。一是保证最后一个 ACK 能到达被动关闭方：如果 ACK 丢了，被动方会重发 FIN，主动方要靠 TIME_WAIT 状态里的残留信息再回一次 ACK，否则被动方会一直等。二是让本连接中所有延迟的报文在网络里自然消亡，避免它们混入相同四元组的新连接，造成数据错乱。
TIME_WAIT 的“坏名声”在于大量短连接场景下会出现几万个 TIME_WAIT 连接堆在主动关闭方。有人会直接去改内核参数 tcp_tw_reuse 或 tcp_tw_recycle，我的建议是谨慎。tcp_tw_recycle 开启后对 NAT 环境很不友好，容易导致部分用户连不上，Linux 新版本也把它移除了。tcp_tw_reuse 配合时间戳选项可以在新连接上用，但依赖对端也开启时间戳。最稳妥的做法是先从应用层改：用连接池复用连接、降低请求频次、避免频繁创建销毁连接。我见过很多“TIME_WAIT 一堆”的告警，最后查下来根本不是内核参数问题，而是调用方每次请求都 new 一个 HTTP Client。
与之对应的 CLOSE_WAIT 也是后端排查重灾区。CLOSE_WAIT 是被动关闭方收到 FIN 后没有调用 close 导致的状态，本质是代码里连接没释放。如果 ss 看到大量 CLOSE_WAIT，正确答案不是调内核参数，而是去查哪个线程没执行 close、任务队列是不是堆积了。这条经验在面试中说出来，会让人知道你真正处理过线上问题。
2.3 可靠传输与流量控制：滑动窗口在实战中的存在感
TCP 的可靠性建立在序号、确认号、超时重传和滑动窗口这几个机制上。面试官常问的是“TCP 怎么保证数据不丢”，你要能完整回答：发送方会给每个字节编号，接收方收到后返回确认号表示期望的下一个字节；发送方维护一个滑动窗口，在不等待单个确认的情况下连续发送窗口内的数据，同时启动重传计时器；如果超时或者收到三次重复确认，就重新发送。
滑动窗口的另一个名字是流量控制。接收方会在 TCP 头部里告诉发送方自己的接收窗口 rwnd 还有多大，发送方的发送窗口不能超过这个值。这个机制解决的是“发送太快把接收方缓冲区塞爆”的问题。实际开发中，如果你写个程序往对端狂塞数据，对端处理不过来，TCP 会自动帮你降速，应用层根本感知不到，这就是流量控制在背后的作用。
面试里容易被追问的是“累计确认”的概念：接收方不需要对每个包单独确认，而是确认到某个连续序列为止，比这个序号小的所有字节都认为已收到。这样实现简单、开销小，代价是如果中间的包丢了，后面的包即使到了也只能等重传，这又引出了 TCP 的队头阻塞问题。这里可以顺带提一句：正因为 TCP 有这种按序交付的强约束，HTTP/2 在 TCP 之上做多路复用仍然无法彻底解决队头阻塞，才会有人推动基于 UDP 的 QUIC。
2.4 拥塞控制四算法：背结论更要懂行为差异
拥塞控制和流量控制经常被搞混，面试时你先说清楚区别就能加分：流量控制是考虑接收方承受能力，拥塞控制是考虑网络链路承受能力。TCP 发送方维护一个拥塞窗口 cwnd，和接收方通告的 rwnd 取较小值作为实际发送窗口。
四个算法需要按顺序记忆。慢启动：连接刚建立时 cwnd 很小，每收到一个确认 cwnd 翻倍，所以叫“指数增长”，直到达到慢启动阈值 ssthresh。拥塞避免：超过 ssthresh 后 cwnd 每轮只加 1，线性增长，避免快速塞爆网络。快重传：发送方收到三个重复 ACK 时就立即重传，不用等超时。快恢复：发生快重传后，把 ssthresh 减半、cwnd 减半，然后进入拥塞避免阶段。
面试官最爱问“慢启动为什么慢”，你回答时不要只说“它增长慢”。慢启动的增长在一开始其实是很快的，1、2、4、8 这样翻倍，它的“慢”是相对于直接以一大块数据冲入网络而言。目的是探测链路容量，避免一开始就造成拥塞。还有一个容易被追问的细节是 TCP 的 AIMD 原则：加法增大、乘法减小。平时 cwnd 线性增，遇到拥塞就减半甚至降到 1，这种“和善地探测、激烈地退避”的设计是 TCP 能在复杂互联网环境下存活的关键。
2.5 UDP 这边也要会答：实时场景和 QUIC
面试不会只考 TCP，UDP 的对比题出现频率也很高。最经典的问法是“视频直播延迟高，为什么不用 TCP 而用 UDP”。答案主干有三点：TCP 的可靠重传和按序交付在丢包时会引入延迟和卡顿；实时媒体可以容忍少量丢包但不能容忍延迟；UDP 头部开销小、无连接，能快速传输。还要补充一句：现在很多直播和实时通信做了应用层补偿，比如 FEC 前向纠错、插帧、客户端缓冲，这些都是为了在 UDP 之上缓解丢包。
现在面试越来越喜欢追问 QUIC，因为它就是“用 UDP 实现可靠传输”的代表。你可以说 QUIC 在用户态实现了类似 TCP 的可靠性、流量控制、拥塞控制，并且解决了一个关键痛点：连接迁移。TCP 连接由四元组标识，手机切换 WiFi 时 IP 变了连接就断了；QUIC 用连接 ID 标识连接，网络切换后连接依然可以继续，这也是 HTTP/3 选择它的重要原因。
3. HTTP/HTTPS 高频题：从状态码到 TLS 握手
3.1 状态码别只背 404，后端要能讲清 5xx 的排查方向
HTTP 状态码数量很多，我不建议死背。面试官真正想听到的是你看到一个状态码，能说清楚业务侧该往哪个方向排查。
按类区分：2xx 表示成功，注意 201 表示创建成功、204 表示无内容，很多同学只认识 200。3xx 是重定向，301 是永久重定向，302 是临时重定向，304 Not Modified 表示资源未修改可以使用缓存。4xx 是客户端问题，400 请求参数错误、401 未认证、403 已认证但没权限、404 资源不存在、429 请求太频繁触发限流。5xx 是服务端问题，500 服务器内部异常、501 未实现、502 Bad Gateway 一般是网关拿不到上游有效响应、503 服务暂时不可用（通常和过载、熔断有关）、504 网关等待上游超时。
面试中区分度最高的问答是“502 和 504 的区别”。502 的本质是上游没有返回可用的响应，比如上游进程直接崩了、连接被拒绝、响应格式不对；504 的本质是请求发出去了但上游在设定时间内没处理完，比如后端线程池满了、慢 SQL 拖垮了接口。解答方向完全不同：502 优先查进程存活、端口监听、部署发布状态；504 优先查超时配置、接口耗时、数据库慢日志。
我自己的面试话术是：先说状态码属于哪个类别，再给一个生产环境场景，最后补一句“我会先看网关日志和后端日志的时间差，再决定是查网络还是查应用”。这句话虽然简单，但能让面试官觉得你真在线上处理过问题。
3.2 HTTP 版本演进：从短连接到多路复用
HTTP 版本演进是近几年的热门考点，核心是理解每个版本解决了什么问题。
HTTP/1.0 默认短连接，每次请求都要新建 TCP 连接，请求结束后立即断开，开销大。HTTP/1.1 引入了持久连接（Connection: keep-alive），多个请求可以复用同一条 TCP 连接；还增加了 Host 头，让一台服务器可以托管多个域名。但 HTTP/1.1 有个致命缺陷：同一连接上的多个请求必须排队，前一个没响应完，后一个就不能发，这就是队头阻塞。实际缓解手段是浏览器开多个 TCP 连接、域名分片，但这些都是绕过问题而不是解决问题。
HTTP/2 的做法是把请求和响应拆成更小的二进制帧，在一条 TCP 连接里交错传输，这就是多路复用。它还做了头部压缩（HPACK），避免每次请求都重复携带大量 Cookie 和 User-Agent。HTTP/2 解决了应用层的队头阻塞，但没有解决 TCP 层的队头阻塞：底层 TCP 一旦丢包，所有帧都要等重传，多路复用的优势被拉平。这也是 HTTP/3 转向基于 UDP 的 QUIC 的直接原因。
面试时如果你能说出“HTTP/2 的多路复用是在一条 TCP 连接内，字节层面交错；HTTP/3 则是在无连接的 UDP 上自己实现连接管理”，基本已经超过大多数候选人了。还可以补一句实际经验：升级 HTTP/2 后，如果遇到浏览器证书告警、不兼容的老环境，需要做好降级方案，我的做法是边缘网关根据客户端握手能力动态协商版本。
3.3 HTTPS 握手到底怎么完成密钥协商
HTTPS 等于 HTTP 加 TLS，核心是加密和身份验证。面试高频问法是“HTTPS 的握手过程是什么”，我建议你按“非对称交换密钥、对称加密传输数据”这个主线来讲。
简化版流程：客户端发送 ClientHello，携带支持的 TLS 版本和加密套件；服务端回复 ServerHello，选定加密套件，同时下发自己的数字证书；客户端验证证书的合法性，包括证书是否过期、域名是否匹配、签发链是否可信；验证通过后，客户端生成一个随机预主密钥（Pre-Master Secret），用服务端证书里的公钥加密发送过去；服务端用私钥解密得到预主密钥；双方用预主密钥和各自随机数派生出对称会话密钥；之后应用数据都用对称加密传输。
这里要能回答“为什么不用非对称加密所有数据”。非对称加密虽然安全，但性能开销比对称加密高几个数量级，不适合大量业务数据。所以方案的实质是“用非对称加密安全地交换对称密钥”，之后用对称加密保证性能。
另一个常问问题是“证书怎么防伪造”。证书里有域名、公钥、签发者、有效期和签名。浏览器验证时用内置的根证书公钥去验证签发者签名，形成一条信任链。如果某个中间证书泄露或被恶意签发，浏览器会拒绝信任。我遇到过不少服务端证书过期导致客户端大面积报错的事故，教训就是给证书加上监控和提前续期提醒，最好做成自动轮转。
3.4 Cookie、Session、Token：登录态设计的基础
这个题目几乎每次面试都会出现，但很多人的回答停在“Cookie 存客户端、Session 存服务端”这个层面。要拔高，需要从“状态放在哪”这个本质去讲。
HTTP 是无状态协议，它不认识“谁是谁”。为了标识用户，服务端可以生成一个 Session ID，存到服务端内存或 Redis 里，然后让客户端通过 Cookie 带上这个 ID，这叫做服务端会话。优点是可控性强、能主动失效；缺点是分布式环境下多个服务节点必须共享 Session 存储，否则请求被负载均衡到另一台机器就找不到会话了。常见解法是把 Session 集中到 Redis，或者做粘性会话，但粘性会话会给负载均衡带来压力和隐患。
Token 方式的思路是“不存服务端”，把用户信息、过期时间用签名封装成一个字符串发给客户端，服务端验签通过就信任。JWT 就是这种无状态方案的代表。优点是好扩展、天然适合移动端和跨域；缺点是难以主动失效，除非引入黑名单或缩短过期时间，还有泄露后风险非常大。我做过一次对账系统改造，就是因为担心 Token 续期和过期的边界问题，最终选择了“短期 Token 加刷新 Token”的双 Token 方案。
面试时你可以给出一个选型观点：如果业务纯在浏览器环境下、设备少，先用 Session 加 Redis 最简单；如果要做多端、跨域、开放接口平台，再考虑 Token。不要只说“都差不多”，面试官想听的正是你做过的取舍。
4. 应用层补充考点：DNS、WebSocket 与完整访问链路
4.1 一次 DNS 解析的完整路径
很多人觉得 DNS 简单，但其实它能撑起一轮完整的技术面试。经典问法是“浏览器输入域名后，是怎么找到 IP 的”。
解析路径大致是：浏览器先查本地 DNS 缓存，再查操作系统 hosts 文件；没有命中就发给本地 DNS 服务器（运营商或公司内网 DNS）；本地 DNS 会先问根域名服务器“com 域名在哪里管”，根服务器指向顶级域名服务器；顶级域名服务器再指向这个域名的权威服务器；权威服务器给出最终的 A 记录或 CNAME 记录。实际过程中，本地 DNS 通常替客户端完成了完整的递归查询，把最终结果缓存起来并按 TTL 控制有效期。
能加分的点有三个。第一是“递归查询和迭代查询的区别”：客户端到本地 DNS 是递归（给我最终答案），本地 DNS 到根/顶级/权威服务器是迭代（不断被指点去下一级问）。第二是 DNS 缓存和 TTL 的实际影响：发布域名切换后，如果老记录 TTL 设置得很大，上次修改要等很久才全部生效，最好的做法是提前把 TTL 调小，切换完再调回去。第三是负载均衡：权威服务器可以针对同一域名返回多个 IP，或者返回 CNAME 指向 CDN，CDN 再根据用户地理位置返回最近的边缘节点 IP。CDN 能加速的核心就是这一层。
4.2 WebSocket 建立连接的过程与心跳重连
WebSocket 也是高频考点，但考察点集中在“和 HTTP 的关系”以及“为什么不用轮询”。你可以从需求出发：HTTP 是请求-响应模式，服务器不能主动给客户端推送消息，只能靠客户端不断轮询，延迟和开销都很大。WebSocket 在一条 TCP 连接上建立全双工通道，服务器随时可以把数据推给客户端，适合聊天、实时通知、游戏对战、行情推送。
建立连接的关键是利用了 HTTP 的升级机制：客户端发一个包含Upgrade: websocket和Sec-WebSocket-Key的 GET 请求；服务端验证通过后，计算一个 Sec-WebSocket-Accept 值返回 101 Switching Protocols；之后这条 TCP 连接就切换到 WebSocket 协议，双方可以双向发帧。
面试中值得说的实践细节是“心跳与重连”：因为 WebSocket 是长连接，中间任何一层网络设备都可能因为空闲把连接断了。所以客户端要定时发 ping 帧，服务端回 pong 帧，超过阈值没收到就主动断开重连，重连还要配合指数退避和随机抖动，避免服务端在断网恢复时被瞬时连接风暴打垮。这些细节是我做推送网关时的真实经验，面试里讲出来比“前端会用 WebSocket 对象”有价值得多。
4.3 面试经典综合题：浏览器输入 URL 后发生了什么
这道题几乎是后端面试的“送分题”和“送命题”结合体，说送分是因为每个人都能说两步，说送命题是因为追问起来没底。完整链路建议按时间顺序分七个环节回答：URL 解析、DNS 查找、TCP 连接、HTTP 请求发送、服务器处理与响应、浏览器解析渲染、资源加载与页面展示。
每个环节都可以被拆开追问。URL 解析要说明协议、域名、端口、路径；DNS 查找要说明缓存层级和递归过程；TCP 连接要回到三次握手；HTTP 请求要说明请求头、Cookie、缓存协商；服务器处理要讲负载均衡、后端服务、数据库；响应阶段要讲状态码和响应头；渲染阶段要区分首字节时间、白屏时间、DOM 构建和资源加载。面试官的几个常见追问点我都遇到过，“Cookie 在哪个阶段带上”、“DNS 解析失败会看到什么错”、“如果服务器返回 304 代表什么”，这些问题都能在本系列其他章节里找到对应答案。
我自己的经验是回答这道题时不要背成流水账，要主动说出“我会先看有没有本地缓存，再讲网络通信，再讲服务端处理，如果面试官想看深度我再展开某一部分”。这样既展示全局观，又给了自己主动权。
5. 生产环境排查：网络工具与典型故障定位
5.1 四个命令走天下：ping、curl、nc、ss
后端面试中有一个隐形考点：你平时怎么排查网络问题。哪怕面试官不直接问，聊项目时提到“接口超时”也一定会追问具体排查动作。我常用的四个命令在这里一次性列出来。
ping 用来判断主机是否可达、链路延迟多大，基于 ICMP 协议。注意 ping 通不代表 TCP 端口可用，因为目标主机可能禁 ping 或无 ICMP 响应，实际通信却正常，所以要配合第二件工具。curl 是 HTTP 接口排查神器，常用参数-v显示详细握手和请求头、-I只拿响应头、-d带 POST 数据、-x走代理。排查 HTTP 问题时，我通常先curl -v看 TLS 握手日志和响应耗时，再决定往下走网络层还是应用层。nc 用来测试端口连通性，nc -vz host port比 telnet 更常见，许多服务器没装 telnet，nc 基本都在。ss 是看本机 TCP 连接状态的利器，ss -antp能列出所有连接、状态和进程，比 netstat 更快更方便。
排查顺序我总结成了口诀：先 ping 通不通，再 nc 端口连不连，然后 curl 看 HTTP 状态，最后 ss 看连接状态。很多问题到不了抓包那一步，用这四个工具就能解决八成。
5.2 抓包工具的基本用法与过滤思路
如果四个命令还定位不了，就需要抓包了。服务端最常用的是 tcpdump，它的核心不是看着一大堆报文，而是用过滤表达式快速缩小范围。常见过滤有几种：按主机过滤用host，按端口过滤用port，按协议过滤用tcp或udp，组合条件用and、or。例如tcpdump -i eth0 -nn tcp port 8080 and host 10.0.0.8能只看指定网卡上目标端口为 8080 的 TCP 报文。-nn参数不要省略，否则会做反向解析主机名，又慢又乱。
抓到包之后，我会先看 TCP 握手是否完成、有没有大量重传、RST 从哪来的。比如客户端报连接超时，抓包发现所有 SYN 发出去没有回应，说明服务端根本没有响应这个来源 IP，可能是防火墙拦截、源地址策略丢弃或者服务器负载已满；如果三次握手都完成了但应用层没数据，问题基本就在应用代码。
Wireshark 适合在测试环境做深分析，有图形界面、能自动分析重传、可以按流过滤。但生产环境很多情况不适合直接抓包，我一般用 tcpdump 抓完后把 pcap 文件下载到本地再用 Wireshark 打开。抓包是核武器，不要一上来就抓，先用轻量工具定位到大致范围。
5.3 高频故障场景排查速查表
我把后端实际遇到的网络故障整理成一张速查表，面试和实战都直接可用。
| 故障表现 | 可能原因 | 首选排查手段 |
|---|---|---|
| 连接超时，ping 不通 | 防火墙拦截、路由不可达、对端宕机 | 分段 ping 网关和目标；查防火墙规则 |
| 连接超时，ping 通 | 端口未监听、全连接队列满、负载高 | nc 测端口；ss 看队列；查应用日志 |
| 大量 TIME_WAIT | 短连接频繁创建、连接未复用 | ss 统计状态；检查客户端连接池 |
| 大量 CLOSE_WAIT | 服务端收到 FIN 没 close | jstack 查线程栈；定位未释放连接代码 |
| 间歇性连接失败 | 连接池耗尽、半连接队列满 | 看线程池和连接池监控；ss 看 SYN 队列 |
| 接口偶发 502 | 上游进程挂、发布重启、响应格式错 | 查网关日志和后端日志时间戳 |
| 接口偶发 504 | 上游超时、慢 SQL、线程池阻塞 | 查接口耗时；看数据库慢日志 |
| 首字节时间很长 | 跨机房公网不稳、DNS 解析慢 | curl -w 分阶段计时；检查 DNS 耗时 |
这张表的重点是“原因”和“手段”必须配套。很多人只会说“查日志”，但在网络问题上，先确认是网络层、传输层还是应用层，再决定看什么日志，效率会高很多。我经常举的一个例子：线上偶发超时，看业务日志全是网络异常，但应用日志没报错，结果一抓包发现跨区域公网链路丢包率高达 2%。这种问题不用调代码，靠发布链路优化解决。
5.4 一个跨环境调用的排查案例
分享一个我做过的真实定位过程，所有敏感信息都替换掉了。某服务 A 调用服务 B 的接口，业务方反馈经常超时，但偶尔又能成功。一开始我以为是代码问题，先加了耗时日志、连接池参数调优，结果毫无改善。后来换了一个思路：用 curl 直接打 B 的接口，从 A 所在机器上测，发现平均耗时要 800ms；但在另一台机器上测只要 20ms。差异立刻锁定了网络链路。
继续排查发现，这两台机器处在不同的网段，请求走了不同的出口网关，问题大概率在某个交换机或防火墙。我用 ping 测延迟也正常，但用大包测延迟时发现跨网段的链路延迟明显偏高，最终定位是某条链路的 MTU 配置不一致，导致大包被分片重传，性能骤降。调整 MTU 后问题彻底消失。
这个案例说明一个关键方法论：遇到网络问题，不要把目光一开始就锁死在应用代码里，先做好二分法——同一请求从不同节点发起，对比结果就能快速划分出是代码问题、网络链路问题还是对端服务问题。这就是资深开发和初级的核心区别。
6. 面试答题框架与持续更新计划
6.1 万能答题框架：结论、原理、场景三步走
技术面试和笔试最大不同是：你说什么、怎么说，面试官都在观察你的思维过程。我练习后总结出一套“三步答题法”，几乎适用于所有网络题。
第一步，先给结论，一句话说清楚“是什么”或“为什么”。比如问“TCP 和 UDP 区别”，第一句就说：“TCP 是面向连接、可靠、按序的字节流传输协议；UDP 是无连接、尽力而为、面向报文的数据报协议。”结论要简短有力，不要一开始就铺背景。第二步，讲原理，拆开核心机制，按顺序描述，可以加一点协议流程。第三步，落到场景，说“这个特性在 XX 场景下选择它是因为……”，如果自己排查过，就补一句真实案例。
这个方法的意义在于控制回答节奏。先给结论，即使后面展开得不够好，面试官也能抓到你的主线；场景收尾能把理论拉到工程实践，让面试官知道你不仅看书，还真的干活。我建议每一个 P0 考点都按照这个框架写一遍逐字稿，背熟节奏而不是背整段内容。
6.2 被追问时的三个错误示范
面试中大概率会被连续追问，而追问恰恰是区分“背题”和“理解”的时间。这里我总结三个最常见的错误说话方式，都是我踩过的坑。
错误一是直接否定问题：“这个没什么用、一般不这么用。”哪怕问题冷门，它也是面试官想确认你知识边界的窗口。正确的做法是承认不足，但尽量接住：“这一块我了解不深，我理解它大概是……如果能给我一点提示，我可以继续往下分析。”错误二是假装懂，现场编细节。网络协议细节容不得编，一旦后续追问对不上，信誉会大打折扣，比直接说不会严重得多。错误三是只讲结论不讲推导过程，比如被问“为什么 TIME_WAIT 要 2MSL”，只回答“为了确保安全”等于没说，必须把两个原因拆开讲，最好带着逻辑推演。
被追问到底的底线策略是：向上抽象一层，把问题引导到自己熟悉的范围里。比如面试官往加密算法数学细节上追问，你不熟悉，可以说“我研究更多是应用层面的对称与非对称密钥交换流程，困扰我更多的时候是证书链的问题，有没有兴趣听听我线上遇到的一个证书告警”。主动引导话题不是狡辩，是把对话拉回自己的优势区间。
6.3 本系列的更新节奏与建议的复习方法
这篇是“计算机网络”主题的开篇框架，后续我会按负责拆解每个大考点：TCP 的每个机制做独立专题、HTTP 全线版本对比、HTTPS 的证书体系、分布式会话与 Token 实战、网络排查案例合集，以及专门的高频面试问答题库。每篇会保持同样的风格：原理讲透、场景落到工程、面试话术可直接背。
复习建议方面，我给自己的要求是“先建地图、再填砖块”：先看懂这篇文章的考点优先级表，填空一样的复习；每复习一个考点就问自己三个问题——它解决什么问题、它的代价是什么、它在我做过的哪个项目里出现过。如果第三个问题答不上来，说明这个知识点还没有内化成你的经验，那就去找一个真实场景做一次实验。
这套方法陪我走过了从“死背八股文”到“能现场推理网络问题”的转变。说句实在话，我做现在这个系列最大的动力，就是看见太多候选人明明基础不错，却因为没有系统的复习框架，在“三次握手为什么不能两次”这类问题上栽跟头。网络协议值得你花时间，因为你往后遇到的所有后端问题，最终都会绕回这些看似基础的细节上。
