★ FEATURED ARTICLE 算下来我前前后后以候选人身份参加过不少头部互联网公司的技术面试也以面试官视角旁听过别人面网络方向。计算机网络原理这一块几乎是必考而且挂人率极高。很多人以为背下三次握手四次挥手、记住几个状态码就万事大吉结果一进二面就被追问得漏洞百出。这篇文章不写教科书式的面经汇总我想以一个偏“杂谈”的角度聊聊计算机网络原理在面试里到底怎么问、怎么答、怎么避坑。内容会覆盖我真实遇到过的题目、当时的回答思路、面试官追问背后的意图以及后来我做面试官时是怎么从这些回答里判断候选人深度的。适合准备一二面、想系统梳理网络知识、或者已经工作几年想补基础的同学读完能直接拿去用。1. 面试中的计算机网络看似考协议实际考思维1.1 从岗位差异看考察侧重点计算机网络原理在不同的岗位面试里考察的侧重是很不一样的。我面后端开发岗的时候网络问题集中在 TCP、HTTP、滑动窗口、拥塞控制这些传输层和应用层的东西。面客户端岗的时候会多一些 DNS 解析、弱网优化、HTTP 2.0 多路复用、WebSocket 长连接这类实际场景。面基础架构或者性能优化方向那就得聊到内核协议栈、零拷贝、DPDK 这些更底层的玩意儿。所以准备面试之前先搞清楚你投的岗位属于哪一类别一门心思只背 TCP。这里有一个人人容易踩的坑不少同学把大量时间花在死磕 TCP 的各种细节上结果面试官问了个“输入 URL 到页面展示中间发生了什么”就答得七零八落。这道题看着简单实际是串起 DNS、HTTP、TCP、IP、ARP 以及后端服务处理的综合题特别能暴露候选人对网络链路整体理解的程度。1.2 面试官真正想从网络题里听到什么我当过几次面试官之后才真正明白一个道理面试官问你网络原理其实不是在乎你能不能背出某个 RFC 文档里的原话而是想看三点。第一你能不能把抽象协议和真实场景对应起来。比如 TCP 的可靠传输面试官期望你不仅知道序号和确认号还要能说出“我写网络库时如果客户端在弱网环境下丢包重传严重该怎么调整参数”这种实际问题。第二你在多方案选型时有没有判断依据。比如缓存为什么用 Redis 而不是直接用 TCP 长连接自己做消息队列选型时为什么关注 Kafka 的网络模型。这些问题都需要你站在原理层面去推演优劣而不是人云亦云。第三你读网络知识的方式是不是系统的。我问过好几个人“TCP 为什么要三次握手”得到的回答是“因为要保证双方收发能力都没问题”。这个没错但太浅。如果你能继续说出“其实是防止旧 SYN 报文在新连接建立后抵达对端造成数据混乱”那么面试官就知道你真正理解序列号机制的历史背景。注意以上三点任何一条都不是靠刷题能刷出来的需要自己把知识点织成网而不是散落一地的珠子。2. TCP 连接管理三次握手、四次挥手背后的技术细节2.1 三次握手为什么不能化成两次三次握手是网络面试的“开胃菜”但几乎所有人的回答都停留在同一个层面客户端发 SYN服务端回 SYNACK客户端再回 ACK然后连接建立。如果面试官追问一句“为什么不是两次”很多人就卡住了。我来拆解一下标准答案的层次。最深入的回答是两次握手只能保证一条方向上的通道可用无法确认服务端发送能力、客户端接收能力这一逆向路径。更重要的是当网络中滞留了旧连接请求时两次握手会让服务端无条件建立连接造成资源浪费和数据混乱。三次握手通过客户端再回一次 ACK本质上是让服务端确认“当前这个连接确实是客户端希望建立的而不是历史残留”。面过某公司的时候面试官进一步追问我三次握手过程中如果客户端的第三次 ACK 丢了会发生什么。这个问题就考验细节了。答案是服务端重发 SYNACK直到超时后释放半连接。而客户端由于已经进入 ESTABLISHED 状态如果此时没有任何数据传输它感知不到异常一旦发送数据就会触发服务端发来 RST连接被强制关闭。这个知识点非常经典我后来做各种网络排查时抓包经常能看到这种重传和 RST。2.2 四次挥手的 TIME_WAIT 到底在等什么四次挥手的问题比三次握手难一个量级因为涉及状态机转移和 TIME_WAIT。面试时几乎必问主动关闭连接的一方为什么要停留在 TIME_WAIT 状态而且是 2MSL我记得有一次面试我答了“为了保证最后一个 ACK 能够送达对方”之后面试官明显不满意追问那句“如果最后一个 ACK 丢了怎么办”。这个时候就必须把话说完整了TIME_WAIT 的第一个作用是确保被动关闭方重发的 FIN 能得到应答不至于因为 ACK 丢失就直接关掉。第二个作用是让本次连接产生的所有报文在网络中自然消失避免相同四元组的新连接接收到旧连接的残留数据这点在连接复用场景下尤其关键。还有一个颇具杀伤力的追问是“TIME_WAIT 为什么要 2MSL不是 1MSL 或者 3MSL”。其实这里的2并没有特别严格的数学推导业内共识是MSL 是报文段最大生存时间主动关闭方发出的最后一个 ACK 如果丢失被动关闭方会在 1MSL 后重发 FIN主动关闭方再回一个 ACK这个 ACK 又需要 1MSL。所以 2MSL 就能覆盖“ACK 丢失后重传 FIN 并再次应答”的最坏情况。回答到这一层面试官一般都会点头。2.3 面试现场加分项把协议动作用抓包验证这里分享一个让我在面试中脱颖而出的经验直接描绘一次真实的抓包经历。我说我在本地用 tcpdump Wireshark 抓过自己写的一个小网络服务的握手过程观察到 SYN、SYNACK、ACK 三条报文之外有的连接里还有 TCP Fast Open 的 TFO cookie 验证以及窗口缩放因子协商。面试官听完之后马上把问题从“背诵”跳到“实用性”问我 TFO 适合什么场景、有没什么坑。我之前在自己项目里也玩过 TFO它能在第一个 SYN 里携带应用数据减少一个 RTT 的延迟。但隐患是服务端需要维护 TFO cookie如果处理不当存在被伪造 cookie 刷的风险而且中间网络设备如果对 SYN 包做特殊处理TFO 就失效了。能把这个上下文说出来比光答原理要强太多。3. 可靠性传输和性能调优滑动窗口、拥塞控制怎么答3.1 滑动窗口机制不是背概念而是画图推演单纯问“什么是滑动窗口”属于入门题。真正拉开差距的是把这个机制里“窗口大小可变”讲清楚让面试官知道你理解流量控制和拥塞控制其实是两套不同的逻辑。流量控制是端到端的行为依赖接收方通告的 rwnd接收窗口防止发送方把接收方缓冲区打满。拥塞控制是整个网络路径上的行为依赖拥塞窗口 cwnd防止过量的数据涌入让中间路由或交换机打爆。这两个窗口的生效值是取两者的最小值。答到这里最好是顺手举个例子一个请求服务服务端处理慢导致接收窗口趋近于零客户端发送窗口也会跟着变成几乎为零此时应用层会观察到发送超时或者阻塞根本不是网络不通而是对端处理不过来。这种候选人少的原因很简单很多人只学了协议栈理论没有把窗口机制和真实业务联系过。我做服务端时遇到过某模块吞吐量上不去排查下来就是接收窗口反复降到 0触发零窗口探测定时器。这时候你去调 TCP_NODELAY、改应用层读取频率效果立刻立竿见影。有这种案例打底面试官很难觉得你只是背书机器。3.2 拥塞控制的完整链路慢启动、拥塞避免、快重传、快恢复拥塞控制是面试中的大块头常见题目包括慢启动的 cwnd 是怎么增长的。什么时候进入拥塞避免阈值 ssthresh 怎么变化。收到 3 个重复 ACK 时是快重传那此时窗口怎么调整。说清楚快恢复和慢启动的区别。我建议候选人把这个过程当成一个故事来记。连接刚建立发送方不知道网络到底能承载多少数据所以从很低的窗口开始试探每收到一个 ACKcwnd 翻倍这就是慢启动阶段增长速度是线性的吗不是是指数级的所以叫慢启动其实不慢。进入拥塞避免之后每经过一个 RTTcwnd 加 1这是线性增长。一旦出现丢包老一点的做法是回到慢启动ssthresh 降为当前窗口一半。后来的改进做法是快恢复既然收到了重复 ACK 说明网络还能传数据只是个别报文丢了所以直接从 ssthresh 开始不至于冷启动。这里有一个高频追问产生重复 ACK 和超时这两种情况拥塞控制的表现为何不一样。答案是超时通常是网络已经非常拥塞了必须狠一点直接降下来而重复 ACK 说明后续报文还能到达对端拥塞程度相对轻所以可以温和一些。3.3 实操心得用两台虚拟机模拟拥塞控制我自己折腾过一个实验环境两台 Linux 虚拟机中间用 tc 命令加延迟和丢包分别测 TCP Cubic 和 BBR 两种拥塞控制算法在不同带宽时延积下的表现。做这个实验之前我一直以为 BBR 是无敌的后来才发现它虽然能显著提升高 RTT 链路下的吞吐但在某些丢包场景下反而会过于激进导致同一条链路上的传统 TCP 流被挤压。面试时讲起这个结论面试官明显来了兴趣这就是“原理实测反思”的完整闭环。如果你没有条件搭环境也至少要在本地跑一次 iperf3 测试看一下不同拥塞控制算法下的曲线变化。这比空背概念靠谱得多。4. HTTP 与 HTTPS从报文结构到加密链路4.1 HTTP 状态码和报文字段的易漏点HTTP 的考察范围广但具体题目往往不难难在平时根本没有在意细节。比如 301 和 302 的区别很多人只记住一个永久一个临时。但面试官如果追一句“浏览器在什么情况下会直接用缓存不重新请求”就要看你知不知道 301 可以被浏览器缓存302 默认不会以及 308 才保留请求方法。还有一种常见问法在跨域场景下简单请求和预检请求OPTIONS的区别。这个跟 CORS 规范有关很多做客户端的人栽在这里因为需要区分 Content-Type 是 application/x-www-form-urlencoded 还是 application/json有没有自定义头。遇到这种问题我建议直接从 HTTP 报文层面回答预检请求是在真实请求之前先发一个 OPTIONS询问服务端允许哪些方法、哪些头服务端返回 Access-Control-Allow-Methods 等响应头之后浏览器才放行真实请求。4.2 HTTPS 证书验证链路的完整逻辑HTTPS 这块多数人能说出“对称加密非对称加密结合”但一问到证书链怎么验证就含糊了。我建议从这几个环节好好梳理服务器返回证书时证书里包含公钥、签名、有效期、域名信息。客户端需要验证证书是否由一个受信任的 CA 签发这就是证书信任链。根 CA 证书是系统内置的但中间 CA 证书需要由上级 CA 签发形成链式验证。验证通过之后客户端用证书里的公钥加密一个随机对称密钥发给服务器完成密钥协商。之后双方都使用这个对称密钥进行加密通信。如果要再往深挖可以补充 TLS 1.3 的变化。它废弃了握手时的 RSA 密钥交换改用 ECDHE 等前向保密算法即使服务器私钥泄露历史通信内容也不会被回溯解密。这个点在现在的面试里属于加分项因为体现你对安全趋势的关注。4.3 常见追问HTTP/1.1、HTTP/2、HTTP/3 怎么选这是一道横跨协议演进的大题。我归纳了一个很清晰的分层答案HTTP/1.1一个连接同一时间只能处理一个请求虽然可以开启多个 TCP 连接但队头阻塞依然明显。HTTP/2引入二进制分帧和多路复用允许一个连接上并发多个流解决了 HTTP 层的队头阻塞。但底层还是 TCPTCP 一旦丢包所有流还是会受影响这就是 TCP 层队头阻塞。HTTP/3把传输层换成 QUIC基于 UDP在用户态实现可靠传输和拥塞控制连接迁移和 0-RTT 让弱网场景提升很大。面试官大概率会追问“既然 HTTP/2 解决了 HTTP 层的队头阻塞为什么还要搞 HTTP/3” 这时候你就要抓住 TCP 层的队头阻塞来解释一个丢包会让后面所有数据都卡住等待重传不管应用层分了多少流在 TCP 这个队列里都是排队的。只有改成 QUIC 才能从根上避免这个问题。5. 高频场景题一条 URL 背后的完整网络链路5.1 从浏览器输入 URL 到页面展示标准答案模板这道题在面试里出现的概率几乎等同于“介绍一下你自己”。但大多数人的回答也就几十秒查 DNS、建 TCP、发 HTTP、渲染页面。如果面试官想深入追问这个回答根本扛不住。我在面头部大厂时总结了一套能撑满十分钟的回答结构按层次递进第一层浏览器对 URL 解析提取协议、域名、端口、路径检查本地是否有该域名的缓存如果没有则进入 DNS 解析流程。第二层DNS 解析顺序是浏览器缓存 → 系统 hosts 文件 → 本地 DNS 解析器 → 本地 DNS 服务器 → 根域名服务器/顶级域服务器/权威域名服务器最终拿到目标 IP。第三层拿到 IP 后浏览器发起 TCP 连接经过三次握手建立可靠通道。如果协议是 HTTPS还会额外进行 TLS 握手里面包括证书验证和密钥协商。第四层TCP 连接建立之后HTTP 请求报文被封装进 TCP 段再交给 IP 层路由和寻址。如果目标 IP 不在同一局域网需要通过 ARP 获取下一跳 MAC 地址然后逐跳转发。第五层服务端收到请求经过负载均衡、应用容器处理生成 HTTP 响应报文返回。浏览器逐步解析 HTML、CSS、JS构建 DOM 树、CSSOM 树合成渲染树最后进行布局和绘制。这个过程如果能够一边讲一边穿插“每一步如果失败会怎么样”的细节就是高分回答。比如 DNS 解析失败就报“无法解析服务器的 DNS 地址”TCP 连接失败可能是目标端口没监听HTTPS 证书不被信任会直接拦下来。5.2 从慢请求反推网络排查的工具和方法这类场景题换了个马甲出现用户反馈页面很慢你从哪里开始查。以前我遇到这个问题容易病急乱投医后来总结出一套相对固定的排查路径。第一步先用浏览器开发者工具看网络面板区分到底是请求排队、DNS 查询、连接建立、TLS 握手、第一个字节时间还是内容下载慢。这个分类极其管用因为它把“慢”精确到了一个阶段。第二步如果是 TTFB首字节时间很长那大概率不在网络传输层而是服务端处理或者反向代理那边慢。这时候要去查服务端访问日志看下游接口耗时、数据库慢查询等。第三步如果是下载阶段慢且文件不大在排除带宽限制后有很大概率是 TCP 层调优问题。比如降低延迟的 Nodelay 没有开或者 MTU 分片导致重传还有可能是运营商路径丢包此时用 traceroute 看看每一跳的延迟和丢包率就知道了。第四步弱网场景还要考虑是不是移动网络基站切换导致 TCP 连接重建、TLS 重新握手那就要评估是否接入 HTTP/3 或者优化心跳机制。这种排查思路一旦在面试中完整讲出来分数的提升不是一星半点因为大多数候选人只会讲“重启一下”“换台电脑试试”完全没有任何方法论。5.3 Cookie、Session、Token 背后的网络语义这题看着是 Web 开发基础但底层网络原理一样能考。比如浏览器对 Cookie 的大小和数量限制是什么Set-Cookie 报文头里的 Domain、Path、HttpOnly、SameSite 都是干嘛的。我面过的一道题目服务端如何识别一个已经登录的用户。常见的回答是“客户端请求里带 SessionID服务端存 Session”。但面试官会追问“如果服务端集群部署Session 在每个节点各存一份用户请求被负载均衡转发到另一个节点怎么办”。这个就牵扯到 Session 粘滞、Session 复制、外部化存储比如集中式缓存三种方案。延伸到 Token 场景无状态鉴权的优势是服务端不需要保存会话状态JWT 本身就是自包含的。但如果深挖到七层网络可以补充一点JWT 放在 Authorization 头里走 HTTPS 是安全的但若出现中间人攻击即便 HTTPS 也挡不住浏览器端植入恶意脚本直接偷 Token。所以老练的面试官更希望你从“网络安全”而不是单纯“网络原理”去思考。6. 模拟现场一场“字节风格”的计算机网络追问实录6.1 面试对话还原虚构代称以下是一场我根据自己和朋友经历综合整理的模拟面试所有人物均为虚构代称场景仅供思路参考。面试官先聊个简单的你访问一个网站地址栏输入域名之后浏览器大概做了哪些事情候选人先解析域名拿到 IP然后建立 TCP 连接发送 HTTP 请求拿回响应后浏览器渲染页面。面试官那 DNS 解析有可能从哪些地方拿结果候选人浏览器缓存、系统缓存、路由器缓存、运营商递归服务器缓存再去查权威服务器。面试官如果权威服务器查询超时了你有哪些排查手段候选人可以用 nslookup 或 dig 指定不同的 DNS 服务器看返回情况再检查本地 hosts 是不是被改了最后确认域名是否已经过期或者 NS 记录配置错误。到这里算及格。但下一问马上就深了面试官TCP 建立连接是三次握手断开是四次挥手。为什么建连少一次断连多一次候选人因为建立连接时服务端可以把 SYN 和 ACK 合并在一起回而断开连接时服务端收到 FIN 后可能还有数据要发给客户端所以 ACK 和 FIN 分开发就多了一次。面试官如果客户端断连时就是在发送完数据后立刻调用 close没有任何数据要等能不能也把 ACK 和 FIN 合发变成三次挥手候选人理论上可以但协议没有这么设计因为它要保证半关闭状态存在。如果服务端还有数据要发必须先发完所以四次是通用模型。如果双方都确认没数据了通过 TCP_NODELAY 结合某些 API 确实可以观察到聚合的报文但这是实现细节不是协议要求。这种回答就能体现“知其然也知其所以然”面试官基本不会卡你。6.2 追问路径背后的真实考察意图模拟到这一步你会发现面试官的追问路径有一个核心意图层层剥开候选人的“安全网”。第一次追问是在验证基础第二次追问是在验证你是否应用过原理第三次追问就开始考察你在异常情况下有没有诊断能力。所以面试前给自己做模拟时不要只准备标准答案。对每一个大知识点可以横向列出来“是什么、为什么需要、缺了它会怎样、实际项目中观察过什么、遇到问题怎么定位”。这五个角度全过一遍基本什么问题都扛得住。6.3 一个压轴方案把知识体系画成自己的排查手册我给很多准备面试的朋友一个建议搞一本自己的“网络排查手册”。不用大而全但要记下自己遇到的问题、排查命令和结论。比如抓包命令组合tcpdump -i eth0 host x.x.x.x and port 443 -w a.cap再去 Wireshark 里分析握手时延和 TLS 版本。延迟数据用 curl -w 输出 time_namelookup、time_connect、time_appconnect、time_starttransfer 几个指标看热点在哪个阶段。调优参数sysctl 里面 net.ipv4.tcp_tw_reuse、net.ipv4.tcp_max_syn_backlog、net.core.rmem_max 这些分别调过什么值当时的场景是什么。这比面试前熬夜刷题有营养得多。面试官问网络不是要求你背网络是希望看到一个真正用网络知识解决过问题的人。你在面试里随便抛出一个真实的排查经历都比空泛地讲十个协议细节更有说服力。7. 面试中的“反直觉”得分技巧7.1 别急着给答案先拆题干我在真实面试里摸索出一个很有用的经验如果面试官问得很宽比如“你觉得 TCP 和 UDP 怎么选”不要一上来就列举区别。先反问或明确上下文是什么样的业务场景实时性要求多高数据量多少连不连得动这一句话就能让面试官感觉你不是在背书而是在做工程判断。7.2 主动暴露知识边界这一点可能很多人想不到。面试遇到自己不熟的领域与其硬答不如坦诚说“这里我只了解 XX 部分底层细节没有深入看过但根据我已有的知识推断可能是……”这种方式反而容易加分。因为网络原理覆盖面实在太广面试官也清楚没有谁全知全能。重点在于你能否用已有知识做合理推断这个能力比死记硬背重要太多。有一次我被问到 QUIC 的连接迁移具体怎么做。我确实没看过详细实现只大概知道用连接 ID 而不是四元组来标识连接。我如实说明之后又补充推断说“ID 应该放在包头的某个固定字段里由端侧管理上下文”。面试官听完说方向是对的之后再没为难我。7.3 末尾反问环节可以展示你的网络视野面试结尾通常会问“你有什么想问我的”这种时候也可以延续网络话题。比如可以问对方团队在弱网优化、长连接治理上有哪些沉淀或者最近在推进 HTTP/3 落地的过程中踩了哪些坑。这种问题既能让你获取有用信息又能在面试官心里留下“这人是真做过网络方向”的印象。8. 最后的建议别把计算机网络当成八股文我在带新人或者帮朋友做模拟面试时最常说的一句话是计算机网络是活知识它描述的是真实发生在每一台设备之间的对话。你能用抓包工具看到每一个握手包、每一个重传、每一个 ACK 延迟这些都不是理论而是肉眼可见的数据。准备面试时先把基础知识点串成独立闭环然后去真实环境里抓一次包模拟一次丢包观察一次窗口降速做一次 DNS 解析耗时分析。这个过程花不了太多时间但比自己闷头刷十道面试题都管用。从我个人的体会来说面试拼的从来不只是一个答案而是“你是如何思考这个答案的”。掌握了这个思维方式不管是面头部大厂还是做日常网络问题排查你都会比别人多一份底气。希望这篇杂谈能帮你在准备计算机网络原理的路上少走一些我当年走过的弯路。
阅读完成 · 觉得有帮助？
