大三后端方向的暑期实习面试，计算机网络基本是必考项，几乎没有一家后端团队能跳过这块。哪怕你简历写的是业务开发、中间件、甚至偏向数据方向，面试官也会在前二十分钟里抽一两个计网问题探你的底。我去年从三月份开始密集投递，陆陆续续面了十来场，踩过不少坑，也总结出一套自己的复习方法。这篇只聊计算机网络，把我真实遇到的高频题、追问方式、以及我答崩之后补回来的思路全部写出来，给正在准备实习面试的同学做个参考。
先说清楚这篇面经的定位。它不是什么“三十天精通计网”的教程，而是贴近面试现场的经验复盘：哪些知识点必须背到反射级，哪些地方面试官喜欢打断追问，哪些话术能体现你真的懂而不是在背八股，以及最后怎么用一次面试暴露出的盲区反向补全自己的知识体系。适合正在准备后端实习面试的大三同学，也适合刚接触计网、想少走弯路的低年级同学。
1. 为什么后端实习面试绕不开计算机网络
1.1 面试官在考察什么
后端开发的本质是处理请求、读写数据、返回结果，这个链路横跨浏览器、网关、应用服务器、数据库，每一跳都依赖网络协议来约定行为。面试官问计网，表面上是考知识点，实际上是在判断你能否把“一次HTTP请求从发出到响应的全过程”讲清楚，以及遇到超时、重试、乱序、拥塞这类真实问题时，你有没有基本的定位思路。
我印象很深的一次，面试官问的不是常规的“HTTP状态码有哪些”，而是直接扔给我一个场景：线上服务偶尔出现耗时毛刺，从客户端看是TTFB很高，问怎么排查。这个问题背后串联了TCP握手、连接复用、DNS解析、代理转发、服务端线程模型一堆东西。当时我还没系统总结全链路知识点，回答得很散，面试官就笑着说“计网不只是背书，你得能把它当工具用”。从那之后我改变策略，不再按章节刷题，而是围绕“一次请求的生命周期”重写自己的笔记。
1.2 计网考点地图与备考节奏
我把自己面试中和身边同学反馈中遇到的高频考点整理成了一张地图，按优先级分了四层。
第一层是绝对核心：TCP三次握手与四次挥手、TCP与UDP区别、TCP可靠传输、流量控制与拥塞控制、HTTP与HTTPS工作流程、HTTP常见状态码、GET与POST区别。这层几乎每场必问，而且面试官会层层追问，务必做到能不看资料徒手画流程、能举例说明。
第二层是高频进阶：DNS解析过程、HTTPS握手细节、对称与非对称加密、Cookie/Session/Token区别、TCP粘包与拆包、HTTP/1.1与HTTP/2核心差异、TIME_WAIT相关问题。
第三层是加分项：TCP SYN Flood原理与防御、滑动窗口机制细节、快重传与快恢复、HTTP/3与QUIC、长短连接与连接池设计。
第四层是工具类：ping/Traceroute原理、netstat/ss抓连接状态、tcpdump抓包分析、dig查DNS。这层不一定会直接考，但能体现工程感。
备考节奏上我建议至少预留三周，第一周过基础层，第二周做进阶层和刷题，第三周做模拟追问和复盘。如果时间紧，也至少要保证第一二层能脱口而出。
2. TCP与UDP：从三次握手到拥塞控制的底层逻辑
2.1 三次握手不是背流程，而是确认能力
三次握手是计网面试的送分题，但也是翻车重灾区。很多同学能把“SYN、SYN+ACK、ACK”背出来，但被问一句“为什么不是两次”就卡壳。
面试官想听到的答案里，至少要有这层理解：三次握手本质是让通信双方确认彼此的收发能力都正常，并同步初始序列号。第一次握手客户端发SYN，服务端收到后能确认客户端的发送能力和自己的接收能力正常；第二次握手服务端回SYN+ACK，客户端收到后能确认自己的发送和接收都正常，同时确认服务端的发送和接收正常；第三次握手客户端再回ACK，是为了让服务端确认客户端的接收能力正常。也就是说，只有到第三次握手完成，服务端才能确认“客户端能收到我发的包”。
还有一个答两点能加分的点：如果是两次握手，可能发生历史重复SYN导致服务端建立无效连接的问题。比如某个旧连接请求在网络中滞留很久，客户端已经超时重传了新SYN，如果服务端收到旧SYN就建立连接并等待数据，客户端却认为连接不存在，资源就白白浪费了。三次握手可以让客户端在收到SYN+ACK时判断这个ACK对应的序列号是不是自己当前期望的，如果不是就发RST撤销连接。
我建议在纸上把三次握手画出来，同时标注每步之后各方的“已知信息”，这样被追问的时候才不容易乱。好的回答状态是：边画边说，让对方看出来你是理解着记忆的。
2.2 四次挥手与TIME_WAIT：面试官最爱的追问点
四次挥手的问题比三次握手更细，追问也更深。基本流程是：主动关闭方发FIN，对端回ACK，然后对端发FIN，主动方回ACK。要答清楚的点是“为什么是四次”，原因是TCP是全双工的，每一方向的关闭都需要单独进行一次FIN和ACK确认，被动关闭方在收到FIN时可能还有数据要发，所以ACK和FIN不能合并。
真正拉开差距的是TIME_WAIT。主动关闭方在发送最后一个ACK后会进入TIME_WAIT状态，持续2MSL（最大报文段生存时间的两倍）。面试官通常会连环问三件事：为什么需要TIME_WAIT、为什么是2MSL、TIME_WAIT太多怎么办。
为什么需要：第一，保证最后一个ACK能到达对端，如果ACK丢失，对端会重发FIN，主动方需要有时间再回ACK；第二，让旧连接的延迟报文在网络中自然消失，避免影响使用相同四元组的新连接。
为什么是2MSL：一个MSL是报文段在网络中的最长生存时间，ACK到达对端最多需要1个MSL，对端重发的FIN回来也最多需要1个MSL，2MSL可以覆盖“最后一次ACK+对端可能的重传”这个完整生命周期。
TIME_WAIT太多怎么办，这个问题我答崩过一次，后来整理了完整的回答框架。要从两方面说：一是调内核参数，比如tcp_max_tw_buckets限制数量、tcp_tw_reuse允许复用TIME_WAIT连接（前提是开启tcp_timestamps），但要注意内核版本差异和安全风险，生产环境要谨慎；二是从应用层减少主动关闭方的TIME_WAIT积累，比如用长连接而不是频繁短连接，让客户端作为主动关闭方去承担TIME_WAIT，服务端尽量做被动关闭方。面试官一般听到这里就会点头，因为说明你有线上经验意识。
2.3 可靠传输与“双控”：流量控制和拥塞控制
TCP的可靠传输靠的是序号、确认号、超时重传和滑动窗口这套机制。面试中常考的是“如果发送方发出去一个包迟迟没等到ACK，会怎么样”，以及“快速重传是怎么触发的”。
快速重传这个点很容易被问细节。它不依赖超时，而是当接收方收到乱序包时，会重复ACK期望的序号，发送方连续收到三个相同ACK就立即重传对应数据，不用等超时。注意，是连续三个重复ACK，不是收到一个就重传，面试官可能在这里设坑。
流量控制和拥塞控制经常被混在一起问，先说区别。流量控制是端到端的，解决“接收方来不及收”的问题，靠滑动窗口，窗口大小由接收方通告（rwnd）；拥塞控制是全局的，解决“网络中间设备来不及转发”的问题，靠拥塞窗口（cwnd），由发送方自己控制。面试时一定要先把这个区别点出来，再展开讲拥塞控制的四个算法。
慢开始与拥塞避免、快重传与快恢复，这四个阶段要能画出示意图。慢开始时cwnd从1开始指数增长，达到慢开始门限ssthresh后进入拥塞避免，线性增长；发生超时，ssthresh降为当前cwnd的一半，cwnd重置为1重新慢开始；发生快速重传时，不重启慢开始，而是ssthresh减半、cwnd设为ssthresh然后快恢复。回答时用具体的数字举个例子，比如“假设初始ssthresh是16，慢开始阶段cwnd从1到2到4到8，到16后每次RTT加1...”，面试官能从细节判断你是不是真的懂。
3. HTTP/HTTPS全链路：从1.0到3.0的演进与高频追问
3.1 HTTP版本演进：管线化到多路复用
后端实习面试里HTTP是必考，但很多同学只准备了状态码和GET/POST区别，版本演进这块讲不出体系。我建议把HTTP/1.0、1.1、2.0、3.0的核心变化串成一条线来讲。
HTTP/1.0每个请求都新建TCP连接，请求完就断开，效率很低。HTTP/1.1引入了持久连接，默认Connection: keep-alive，一个TCP连接可以顺序处理多个请求；同时支持管道化，理论上可以并发发送多个请求，但因为响应必须按序返回，队头阻塞问题没解决。这里面试官常追问“什么是队头阻塞”，答案是：如果第一个请求响应很慢，即使后面的请求已经到了服务端，响应也要排队等着，前面的被阻塞，后面的全部跟着等。
HTTP/2的核心是二进制分帧和多路复用。同一条TCP连接上可以同时交错传输多个请求的帧，接收方根据流ID重新组装，彻底解决了应用层的队头阻塞。另外HTTP/2有头部压缩（HPACK），通过静态表和动态表减少重复头部字段的传输。但要注意，HTTP/2仍然存在TCP层的队头阻塞，因为TCP本身要求有序交付，底层丢一个包，后续所有数据都得等重传，这也是HTTP/3改用QUIC、基于UDP实现的直接原因。
回答HTTP/3时能说出两个关键点就够了：一是基于UDP实现可靠传输，把连接建立和TLS握手合并，减少连接建立时间；二是引入Stream级别的独立流量控制，单一连接中某个流丢包不影响其他流的传输。这块属于加分项，但说出来会很亮眼。
3.2 HTTPS握手流程，别只记得证书
面过我的几次，几乎没有不追问HTTPS的。基础的答案是：HTTPS是在HTTP和TCP之间加了一层TLS/SSL，保障机密性、完整性和身份认证。
但你如果只答到这里，面试官一定会追问“握手过程是怎样的”。我建议按以下顺序答，逻辑最顺：
- 客户端发起ClientHello，携带支持的TLS版本、加密套件列表和一个随机数。
- 服务端返回ServerHello，选择加密套件，携带服务端随机数，并把证书发给客户端。
- 客户端验证证书链，确认服务端身份可信。
- 客户端用证书中的公钥加密一个预主密钥（Pre-Master Secret）发给服务端。
- 双方用两个随机数加预主密钥，通过约定算法生成相同的会话密钥。
- 客户端发送ChangeCipherSpec并加密Finish消息，服务端也做同样操作，握手完成。 说明：在实际的TLS 1.2/1.3中密钥协商可能使用ECDHE算法，步骤上略有不同，但先把这个“形成密钥”的框架讲清楚，再补充ECDHE的临时密钥特性（前向保密），面试官通常会满意。
容易被追问的点包括：为什么既要非对称加密又要对称加密，答案是性能考虑，非对称用于安全地协商密钥，对称用于后续数据加密，速度快；证书的作用是防止中间人冒充，前提是客户端信任的根证书机构签发；如果证书过期或域名不匹配，浏览器会告警，你还要说明这里存在身份验证失败。
3.3 Cookie、Session与Token，怎么聊才算有体系
这个点看起来简单，但面试官很看重系统性。我见过不少同学能分别说出三者是什么，却讲不清为什么需要它们以及怎么选。
先说HTTP是无状态的，服务器默认记不住你之前是谁，所以需要会话技术。最传统的是Cookie+Session：客户端把Session ID放在Cookie里，每次请求带过去，服务端根据Session ID查内存或Redis中的会话数据。这个方案的优点是服务端可以随时让会话失效，缺点是如果多台服务器部署，Session数据需要共享或做会话粘滞。
Token方案（常见的有JWT）则把用户信息签成一段字符串，服务端不保存状态，每次请求只验签即可。优点是天然适合分布式和无状态服务，缺点是单个Token很难主动失效，只能等过期时间。比较实用的说法是：登录态该用Session还是Token，得看业务场景，内部后台管理系统用Session更可控，对外提供API或无状态服务用Token更合适。
面试官如果继续追问，可能会让你说说Cookie的安全属性：HttpOnly防止JS读取、Secure只允许HTTPS传输、SameSite防止CSRF。这些都要能说清楚，属于后端工程必备的常识。
4. 高频追问现场还原：DNS、粘包、心跳与半连接队列
4.1 DNS解析的完整链路与反问式追问
DNS的问题是“背了就会，不背就崩”，而且一旦崩了整场节奏都会受影响。标准答案要按流程说清楚：输入域名后，先查浏览器缓存，再查操作系统hosts文件和本地DNS缓存，然后向本地DNS服务器发起递归查询，本地DNS服务器再以迭代方式依次询问根域名服务器、顶级域名服务器、权威域名服务器，拿到最终的IP地址并缓存。
面试官常在这里追问：“递归和迭代的区别是什么”，你要能快速回答：递归是“你给我一个结果”，我等着就行；迭代是“我给你一个线索，你再去找下一个”。本地DNS服务器对客户端提供的是递归服务，它自己面对根服务器和各层服务器时用的是迭代查询。
我遇到的进阶追问还有：为什么DNS用UDP而不是TCP。答案是：UDP快，DNS报文通常很小，一个UDP包就能装下，查询失败可以重试；TCP有连接建立开销，只在区域传送、响应过大需要分片或UDP查询被截断时才启用。面试官会补充问“DNS劫持是什么”，这就是个开放问题了，可以谈缓存污染、运营商劫持、以及安全应对，比如HTTPDNS和DNSSEC。这块只要能说出“客户端绕过本地DNS直接向HTTPDNS服务器查询IP，避免中间环节污染”，就已经很有区分度了。
4.2 TCP粘包与项目里的拆包方案
“TCP粘包”几乎是后端开发面试必问的一个点，尤其是有过实习或项目经验的同学，面试官喜欢直接问“你项目里处理过粘包吗”“怎么解决”。
先说理论：TCP是面向字节流的协议，不保证消息边界，应用层写入的数据会被TCP拆成报文段发送，接收方只能拿到连续的字节流，不知道哪一段是一个完整消息，所以可能出现一个包里有多个消息（粘包），也可能一个消息被拆到多个包（拆包）。UDP不会出现粘包，因为它保留消息边界，每报一个完整消息。
解决方案常用三种：一是消息定长，比如固定100字节，不足补位，简单但浪费；二是在消息间加分隔符，比如按行分隔，适合文本协议，但要防止正文里出现分隔符；三是在消息头部加长度字段，这是最通用的方案，接收方先读固定长度的头，解析出payload长度，再读对应字节。回答时最好结合自己项目里的实际协议设计，比如我做过的一个通信模块，用的是4字节魔数+4字节长度+payload的结构，面试官听到这种细节明显会更有兴趣。
需要提醒的是：粘包不是TCP本身可以避免的，必须在应用层处理，这个点的表述很关键，说明你懂协议分层。
4.3 心跳机制与断线重连设计
心跳相关的题通常从“服务端怎么判断客户端是否在线”切入。如果不做心跳，TCP连接断开不会立刻被发现，因为TCP本身不主动探测对端状态（除非开启KeepAlive）。这里要先讲清楚：网络通信里的心跳是应用层的定期探测机制，客户端或服务端每隔一段时间发送固定心跳包，对方如果在超时时间内没回应，就认为连接失效。
面试官可能会追一个很实际的问题：“如果网络闪断几秒，连接还能用吗”。这个问题要区分场景。如果只是短暂网络抖动，TCP会自动重传，不一定会断开；如果是网线被拔掉或者对端宕机，没有应用层心跳，可能要等TCP超时重传很多轮才能感知。设计上的最优做法是：应用层心跳周期+超时重试+正常的TCP重传机制互相配合，同时建议用连接空闲状态的检测（比如服务端的读超时机制）来回收坏连接。
断线重连还有一个细节很容易漏：重启连接时要把旧的资源清理干净，比如清掉旧Socket、释放关联的缓冲区、取消未完成的写队列，否则会出现内存泄漏或者消息乱序重发。回答时主动提起这个点，能体现你写代码时考虑过边界情况。
4.4 SYN Flood与半连接队列
这个是安全向的进阶点，很多后端团队尤其看重。SYN Flood的攻击原理是：攻击者伪造大量源IP向服务端发SYN包，服务端收到后需回复SYN+ACK，并把这些半连接放入半连接队列（sync queue），等待第三次握手ACK。如果攻击者不回复ACK，半连接队列很快被占满，新的正常连接请求无法被处理，服务端就瘫痪了。
回答时要能说出至少两种缓解手段：一是调大半连接队列长度（比如tcp_max_syn_backlog）；二是开启SYN Cookie，服务端不把半连接信息存到队列里，而是通过一个Cookie随SYN+ACK发回去，客户端回ACK时携带Cookie，服务端验证后直接建立连接；三是配合防火墙限制单位时间内SYN包速率、过滤可疑源。SYN Cookie这段能讲清楚，面试官会认为你不仅仅在背书，而是对DoS攻击和防御有工程意识。
但这里有一个度的问题，不要为了炫技把所有安全概念全都倒出来，挑最有代表性的两点讲透，留出余地给面试官追问，会比一口气讲十分钟好得多。
5. 算法之外的突击清单：安全基础与Linux网络排查
5.1 后端面试里常见网络安全问题
除了DDoS，还会遇到几个基础安全问题。CSRF的核心是“利用用户浏览器中已有的Cookie发起跨站请求”，防御思路是校验请求来源（检查Referer/Origin）、加CSRF Token、设置SameSite属性。XSS的核心是“把不可信的用户输入当成代码执行”，防御思路是输出转义、输入校验、CSP。SQL注入则是“把用户输入拼进SQL语句”，核心防御是参数化查询。这三个问题我建议每个准备一个“一句话原理+一个典型例子+三句防御”的模板，面试遇到直接按模板展开。
另外要准备一个高频问题：“HTTPS能防住所有攻击吗”。答案是不能，HTTPS只解决传输层的机密性和完整性，防不住应用层的问题、DNS劫持、客户端被植入恶意代码等。这个开放题很能检验你是不是真的理解安全边界。
5.2 实用Linux网络排查命令复盘
后端实习面试不一定考命令，但如果面试官感觉你有些系统基础，会顺手问“线上出现连接超时你会怎么做”。我的回答思路是：先用ping看基本连通性，如果有ICMP限制就换tcping或nc检测端口连通性；再用ss -antlp看监听状态和大量连接停留在什么状态，比如大量TIME_WAIT、SYN_RECV、CLOSE_WAIT分别说明什么问题；再用tcpdump抓包看是否收到SYN/ACK、是否有重传；最后用dig看域名解析是否正常。
这里面试官可能追问“大量CLOSE_WAIT说明什么”。答案是：被动关闭方收到了对端的FIN，但应用层迟迟没有关闭Socket，通常是因为代码里没有正确读取完所有数据就关连接，或者线程阻塞导致不能及时执行close。线上排查时可以直接用lsof或ss定位到具体进程和文件描述符，然后去查资源泄漏。
这个问题的回答一定要结合自己的实际经验来说，比如“上次我们服务突然大量CLOSE_WAIT，最后定位到是HTTP响应体没读完就进入下一次循环，导致连接没被归还到连接池”。真实案例比背命令更能打动人。
6. 面经之外的避坑经验与复盘方法
6.1 我在备战时踩过的坑
第一个坑是不做模拟追问，只看面经答案。计网里的知识点几乎都有“再往下追问一层”的空间，如果只是背了大纲而不去想“为什么”，面试现场一紧张就露馅。我第三次面试时被问“为什么TIME_WAIT是2MSL而不是MSL”，直接愣住，因为之前只觉得记住结论就够了。从那以后我就把准备好的每个问题都自己追问至少两轮，写在小卡片上反复过。
第二个坑是只看不动手。TCP状态机、握手挥手这些内容，光看不画的话记忆留存率很低。我的办法是在白板上反复默画状态流转，甚至自己用本机回环地址和Python起一个简单的Socket服务，抓包看三次握手和四次挥手的真实过程。这个实际操作只花了一个下午，但对理解的提升是巨大的。
第三个坑是答非所问，急着把所有东西都倒出来。有一次面试官问我“HTTP的Keep-Alive是什么”，我直接从头开始讲TCP长连接，讲了十分钟还没到HTTP。后来我才意识到，面试官问的是“HTTP层面的连接复用”，应该先说清楚HTTP/1.1默认多个请求复用一个TCP连接，再展开连接池和超时时间的权衡。学会先精准回答问题、再适度扩展，是很重要的面试能力。
6.2 怎么把一次面试变成能力增量
我的做法是每次面试结束后二十分钟内，趁记忆新鲜，把面试官问过的所有问题记录下来，标注三类：完全答上来的、答得不完整的、完全不会的。针对答不完整的，去查资料补全一个“更好的回答模板”；针对不会的，单独记到待办清单里。这个方法坚持了一个半月之后，我的薄弱项从最初的二十多个缩到了三四个。
还有一个很有用的复盘技巧：把自己当时的回答写下来，以面试官视角重新审视有没有逻辑断层。很多时候我们“以为答对了”，实际上是因为面试官没有打断，礼貌性放过。用这种第三视角去重读自己的回答，会发现很多地方的论证顺序其实很乱。比如我复盘HTTPS握手的回答时，就发现自己把“证书验证”和“密钥协商”混在一起讲，让人很难跟。调整为先说整体目标，再分阶段描述，效果立刻不一样。
最后说一个个人经验：计网面试准备上限很高、下限也低，你不需要把OSI七层的每一个细节都背下来，但你必须能把一条HTTP请求从浏览器地址栏输入开始，到DNS、TCP、TLS、服务端接收、响应返回的每一层讲得清清楚楚。做到这一点，大部分后端实习岗的计网环节就稳了。剩下的就是多练、多复盘，把“背出来的知识”变成“长在身上的理解”。
