1. 为什么“网络常见面试题”值得单独拎出来聊“网络常见面试题”这六个字看起来像是一份题库的标题但真正在一线做过技术面试官、也做过候选人的朋友都清楚它背后其实是一整套关于知识体系、表达逻辑和工程直觉的考察框架。我这些年参与过不少后端、运维、客户端方向的面试也帮朋友做过模拟面发现一个很普遍的现象很多人把网络题当成八股文来背背得滚瓜烂熟可一旦面试官追问一句“为什么”立刻就卡壳了。问题不在于他们不努力而在于没有把零散的知识点串成一条能自洽的链路。这篇文章想做的事情不是再给你堆一份“100道网络面试题及答案”那种东西网上已经太多了。我更想从一个面试官和候选人的双重视角把网络面试里真正高频、真正能拉开差距的那几类问题拆开讲清楚它们在考什么、标准答案背后的原理是什么、以及怎么回答才能让面试官觉得你是真的懂。关键词会围绕TCP/IP、HTTP、DNS、HTTPS、TCP三次握手、拥塞控制、状态码、跨域这些核心概念展开但重点永远放在“为什么”和“怎么用”上。适合谁来读如果你是准备跳槽的后端、运维、测试或者客户端开发这份内容可以直接当作复习主线如果你是刚入行的新人它能帮你建立一张网络知识的骨架图避免东一榔头西一棒子如果你已经工作几年它也能帮你把那些“好像知道但说不清楚”的模糊地带补上。我尽量用大白话加实际场景来讲不堆术语但该严谨的地方绝不含糊。2. TCP三次握手面试官真正想听的不是“三次”这个数字2.1 从“为什么不是两次”切入比背流程更有杀伤力几乎每场网络面试都会问到三次握手但绝大多数候选人的回答停留在“客户端发SYN服务端回SYNACK客户端再回ACK”这个层面。这个回答没错但它只证明了你看过书没证明你理解设计意图。面试官如果接着问“为什么不能是两次”很多人就开始含糊了。正确的切入角度是三次握手的本质目的是让通信双方都确认“自己的发送能力”和“对方的接收能力”同时正常。我们拆开看。第一次握手客户端发SYN服务端收到后能确认“客户端的发送能力正常、我的接收能力正常”但服务端此时还不知道客户端能不能收到自己的消息。第二次握手服务端回SYNACK客户端收到后能确认“服务端的发送能力正常、我的接收能力正常”同时因为自己之前发的SYN被回应了也确认了“我的发送能力正常”。但服务端此时仍然不确定客户端是否收到了自己的SYNACK。第三次握手客户端再发一个ACK服务端收到后才最终确认“客户端的接收能力正常、我的发送能力正常”。所以两次握手的问题在于服务端无法确认客户端是否收到了自己的同步报文。如果只用两次一个历史遗留的、延迟到达的SYN请求可能让服务端单方面建立连接并分配资源而客户端根本不认这个连接这就造成了资源浪费也给了攻击者可乘之机。这个“历史连接”的坑是面试官很喜欢的追问点你能主动提出来印象分直接拉满。2.2 序列号与半连接队列那些容易被忽略的工程细节聊完三次握手的逻辑面试官往往会往工程实现上引。这里有两个高频追问初始序列号是怎么来的以及半连接队列和全连接队列是什么。初始序列号ISN不是随便取的也不是从0开始。现代操作系统通常用基于时钟的算法生成比如每4微秒加1这样做的目的是让旧连接的延迟报文尽可能不会和新连接的序列号撞上。如果你回答“随机生成”虽然不算全错但不够准确面试官可能会觉得你只停留在概念层。半连接队列和全连接队列则是服务端处理握手时的两个关键结构。服务端收到SYN后会把这个连接放进半连接队列也叫SYN队列此时连接处于SYN_RCVD状态。等收到客户端的ACK后再把它移到全连接队列Accept队列等待应用层调用accept取走。这里有个很经典的线上问题当半连接队列满了新的SYN会被丢弃客户端会超时重传当全连接队列满了服务端通常会根据tcp_abort_on_overflow参数决定是丢弃ACK还是直接发RST。很多“服务端莫名其妙连不上”的故障根因就在这两个队列的溢出上。面试时能把这个讲清楚说明你是有实战经验的。提示如果你在简历里写了“熟悉TCP”那半连接队列溢出导致的现象比如客户端频繁超时、服务端CPU不高但连接建立失败最好能说出一二这是区分背书党和实战派的分水岭。2.3 四次挥手为什么比握手多一次TIME_WAIT不是“浪费时间”和握手对应的是挥手。四次挥手比三次握手多一次核心原因是TCP是全双工的每个方向都需要单独关闭。客户端发FIN表示“我没数据要发了”服务端回ACK表示“知道了”但此时服务端可能还有数据要发所以不能立刻发FIN得等自己的数据发完再发FIN客户端再回ACK。这就多了一次。面试官紧接着会问TIME_WAIT。主动关闭方在发完最后一个ACK后会进入TIME_WAIT状态等待2MSL报文最大生存时间的两倍才真正关闭。为什么要等两个原因一是确保最后一个ACK能到达对方如果这个ACK丢了对方会重传FIN此时主动关闭方还在TIME_WAIT就能重新发ACK二是让本次连接产生的所有延迟报文在网络中消散避免它们被后续的新连接误收。实际工作中高并发短连接的服务端如果主动关闭连接会积累大量TIME_WAIT占用端口资源。解决办法通常是让客户端主动关闭或者调整内核参数复用TIME_WAIT连接。但要注意tcp_tw_reuse这类参数不是随便开的在NAT环境下可能引发问题。面试时如果你能说出“TIME_WAIT是主动关闭方才有服务端被动关闭一般不产生”就已经比很多人强了。3. HTTP与HTTPS从状态码到加密链路的完整追问路径3.1 状态码不是背数字而是理解“谁的责任”HTTP状态码是网络面试的必考项但很多人只会背“200成功、404找不到、500服务器错误”。面试官真正想考的是你能不能根据状态码快速定位问题归属。我习惯把状态码按“责任方”来分类记这样既好记又好用。状态码区间含义责任方典型场景1xx信息性协议层101切换协议WebSocket升级2xx成功正常200、201创建成功、204无内容3xx重定向客户端需跟进301永久、302临时、304缓存有效4xx客户端错误请求方400参数错、401未认证、403无权限、404不存在5xx服务端错误服务方500内部错误、502网关错、504超时这里面有几个高频追问点。301和302的区别301是永久重定向浏览器会缓存下次直接跳新地址302是临时重定向每次都会先请求原地址。做SEO或者域名迁移时用错后果很严重。304是怎么来的客户端发请求时带上If-Modified-Since或If-None-Match服务端判断资源没变就回304不传body省带宽。502和504的区别502是网关从上游收到了无效响应504是网关等上游超时。这两个在排查微服务问题时特别有用502往往意味着上游服务挂了或返回了非法内容504则通常是上游处理太慢。3.2 HTTPS握手对称加密和非对称加密到底怎么配合HTTPS是面试的重灾区因为它是“网络安全”的交叉点。很多人知道HTTPS用非对称加密交换密钥、用对称加密传数据但说不清为什么不能全程用非对称。答案很简单非对称加密的计算开销远大于对称加密如果每个数据包都用非对称加解密性能根本扛不住。所以实际做法是握手阶段用非对称加密安全地协商出一个对称密钥会话密钥之后所有应用数据都用这个对称密钥加密传输。TLS握手的大致流程是客户端发ClientHello支持的协议版本、加密套件、随机数服务端回ServerHello选定的套件、随机数和证书客户端验证证书有效性是否可信、是否过期、域名是否匹配然后生成一个预主密钥用服务端公钥加密发过去双方用三个随机数算出会话密钥最后互相发Finished确认。这里有个容易被忽略的点证书验证失败时浏览器会报警告但有些客户端库默认不校验证书这是很危险的做法面试时如果被问到“怎么保证HTTPS安全”一定要提到证书校验这一环。3.3 从HTTP/1.1到HTTP/2队头阻塞到底解决了没有HTTP/1.1的经典问题是队头阻塞一个TCP连接上前一个请求没响应完后面的请求就得等着。虽然有了管道化pipelining但因为响应必须按顺序返回实际效果很差所以浏览器干脆用多开连接通常6个来缓解。HTTP/2的解决思路是多路复用把请求和响应拆成帧每个帧带流ID不同流的帧可以交错传输接收方按流ID重组。这样理论上一个连接就能并发处理多个请求。但要注意HTTP/2解决的是应用层的队头阻塞TCP层的队头阻塞依然存在——如果某个TCP段丢了后面的段即使到了也得等重传。这也是为什么后来有了基于UDP的HTTP/3。面试时如果你能指出“HTTP/2的多路复用是在一个TCP连接上所以TCP层丢包仍会阻塞所有流”面试官会觉得你理解得很透。4. DNS与跨域那些“看起来简单却总答不全”的问题4.1 DNS解析的全链路从浏览器缓存到根域名服务器DNS题看起来简单但能完整说清解析链路的人并不多。一次完整的DNS解析大致经过这些步骤浏览器缓存 → 操作系统缓存 → 本地hosts文件 → 本地DNS服务器通常是运营商或公司内网→ 根域名服务器 → 顶级域名服务器 → 权威域名服务器。本地DNS服务器拿到结果后会缓存一段时间由TTL决定下次再问就直接返回。面试官常问的追问是DNS用TCP还是UDP。标准答案是查询通常用UDP因为快、开销小但当响应超过512字节或者做区域传送时会用TCP。另一个高频问题是DNS劫持和污染怎么防这就引到DoHDNS over HTTPS和DoTDNS over TLS它们把DNS查询加密防止中间人篡改。不过要注意加密DNS解决的是传输安全不解决域名本身被伪造的问题那需要DNSSEC。4.2 跨域的本质同源策略到底在防什么跨域是前端面试的常客但很多后端同学也躲不开。同源策略的核心是协议、域名、端口三者完全相同才算同源。浏览器限制的是“读”跨域响应而不是“发”请求。也就是说你发一个跨域的POST请求请求是能到达服务端的服务端也可能处理了但浏览器不让你的JS读响应。解决跨域的常见方案有CORS服务端设置Access-Control-Allow-Origin等响应头、JSONP利用script标签不受同源限制但只支持GET、代理同源服务器转发请求。CORS里又分简单请求和预检请求简单请求直接发非简单请求比如带自定义头、用PUT/DELETE会先发一个OPTIONS预检服务端同意后才发真实请求。这里有个坑预检请求的结果会被缓存由Access-Control-Max-Age控制如果设得太短每个请求都预检性能会很差设得太长权限变更又不及时。实际项目里通常设几分钟到几小时不等。注意很多人以为跨域是服务端的问题其实服务端只是配合真正的限制方是浏览器。用curl或Postman发同样的请求不会遇到跨域因为它们没有同源策略。面试时点出这一点能体现你对问题本质的理解。4.3 Cookie、Session、Token状态保持的三代方案HTTP是无状态的所以需要额外机制来保持登录状态。Cookie是存储在浏览器端的小段数据每次请求自动带上Session是服务端存储的会话数据通常用SessionID关联SessionID放在Cookie里Token如JWT是把状态编码成一个自包含的字符串服务端不用存验签即可。三者的取舍很能体现工程思维。Session的问题是服务端要存分布式环境下需要共享存储比如Redis或者做会话粘滞Token的好处是无状态、易扩展但缺点是无法主动失效除非维护黑名单那就又变成有状态了。面试时如果被问“你们项目用哪种”不要只说“我们用JWT”要说出为什么选它、以及怎么处理它带来的问题比如刷新令牌、过期时间设置、如何防重放。5. 拥塞控制与性能优化从理论到线上调优的落地5.1 慢启动、拥塞避免、快重传、快恢复四个阶段怎么串TCP拥塞控制是网络面试里最能区分层次的部分。四个核心阶段慢启动时拥塞窗口指数增长直到达到慢启动阈值拥塞避免时改为线性增长避免增长过快快重传是收到三个重复ACK就立刻重传丢失的段不等超时快恢复是快重传后不回到慢启动而是把窗口减半后继续拥塞避免。面试官常问为什么慢启动是指数增长还叫“慢”。这里的“慢”是相对于“一次性把窗口开到最大”而言的指数增长在初期确实很快但起点低通常从1个MSS开始所以整体是渐进式的。另一个追问是BBR和传统拥塞控制的区别传统算法如CUBIC基于丢包判断拥塞BBR基于带宽和延迟建模在高丢包但实际带宽充足的环境下表现更好。如果你在项目里调过tcp_congestion_control参数这段可以结合实测数据讲非常有说服力。5.2 从TCP参数调优看“面试题”和“真实故障”的距离很多人背了一堆拥塞控制理论但一到线上就不知道怎么用。我举几个实际调优的场景。高并发短连接的服务如果TIME_WAIT太多可以开tcp_tw_reuse让新连接复用TIME_WAIT状态的端口但前提是时间戳选项开启。长连接但吞吐上不去可能是接收窗口太小可以调大tcp_rmem和tcp_wmem。跨机房传输慢可能是默认的拥塞控制算法不适合长肥管道换成BBR往往有明显提升。这些参数不是背出来的是结合业务场景试出来的。面试时如果你能说“我们之前遇到XX现象排查后发现是XX参数的问题调整后XX指标从A降到B”这比背一百道题都管用。面试官要的不是百科全书而是一个能解决问题的人。5.3 一次完整的线上网络问题排查链路我拿一个虚构但典型的场景来串一遍某服务高峰期偶发超时客户端报504。排查思路是先看监控确认是全局还是个别实例再看服务端指标发现CPU不高但连接数很高查netstat发现大量SYN_RECV怀疑半连接队列溢出检查somaxconn和tcp_max_syn_backlog发现默认值偏小调大后观察SYN_RECV下降超时缓解。但根因可能是上游突发流量或遭受了SYN Flood所以还要加限流和防护。这个链路里用到的知识点包括状态码含义、TCP握手队列、内核参数、监控指标。面试时如果你能把“现象→假设→验证→修复→复盘”这条线讲清楚面试官基本会认定你有独立排查能力。这恰恰是“网络常见面试题”背后真正想筛选的东西——不是你知道多少而是你能用多少。6. 面试表达怎么把知识讲成“你的”知识6.1 用“场景取舍结果”的结构回答问题同样一个知识点不同的表达方式给人的感觉完全不同。比如问“TCP和UDP的区别”背答案是“TCP可靠、面向连接、字节流UDP不可靠、无连接、数据报”。这个答案没错但很平。如果你换成“我们做实时音视频的时候选了UDP因为TCP的重传和拥塞控制会导致延迟抖动而音视频宁可丢几帧也不能卡但做文件传输就必须用TCP丢一个字节文件就坏了。所以选哪个取决于业务对可靠性和延迟的取舍。”——这就叫把知识讲成了自己的。我建议所有网络题都用这个结构先说场景再说为什么这么选最后说结果或代价。这样既展示了知识又展示了判断力还顺带体现了沟通能力。6.2 遇到不会的题诚实推理比瞎编强十倍面试中遇到完全不会的网络题很正常比如问你某个冷门协议或某个内核参数的默认值。这时候最忌讳的是硬编。更好的做法是先承认“这个具体细节我不确定”然后说“但根据我对XX的理解它可能是这样工作的因为……”。面试官往往更看重你的推理过程而不是那个标准答案。网络领域很多设计都是相通的你能从已知推导未知本身就是一种能力。6.3 反问环节问什么能体现你的水平面试最后的反问环节很多人问“团队用什么技术栈”“加班多不多”。这些问题不是不能问但如果你能问出“你们线上网络这块遇到过比较棘手的问题是什么”“服务间的通信是走HTTP还是RPC有没有做链路层的优化”面试官会立刻觉得你是同道中人。因为这表明你关心的不是福利而是技术本身而且你有能力参与到这类问题的讨论中。7. 我整理这套内容时的一些个人体会网络知识有个特点入门容易精通难但一旦通了很多问题会突然变得清晰。我早期也是靠背题过来的后来真正做线上排查、做性能优化才发现那些面试题其实都是真实问题的抽象。三次握手对应连接建立失败TIME_WAIT对应端口耗尽拥塞控制对应传输慢DNS对应解析异常跨域对应前后端联调。你把每个知识点都挂到一个真实场景上记忆会牢固得多面试时也能自然地说出细节。另外不要追求把所有题都背完。网络领域太广你不可能全知。更有效的策略是把最高频的那二三十个问题吃透每个都能从原理讲到实践再准备两三个自己亲手排查过的案例。这样无论面试官怎么追问你都有话可说而且说的是自己的话。我见过太多人背了一堆题结果一追问就露馅反而扣分。真实、有逻辑、能落地这三点比题海战术管用得多。最后分享一个小技巧每次复习完一个网络知识点试着用大白话给一个非技术的朋友讲一遍。如果你能让他听懂“为什么需要三次握手”那你就真的懂了。面试本质上也是一次讲解只不过听众换成了懂行的人。