后端面试里计算机网络这块儿的地位很特殊。它不像算法那样刷题就能速成也不像中间件那样会个API就能应付——网络知识考察的是你对“数据从一台机器到另一台机器”这条完整链路到底有没有底层认知。前端同学可能只需要懂到浏览器发请求就够了但后端不行线上连接超时、数据库连接池被打满、消息堆积、跨机房调用变慢这些问题的根因十有八九都藏在网络协议里。所以我在准备这份《最详细的后端面试系列内容—计算机网络》时给自己定的标准是不求知识点覆盖到RFC里每个字节但凡是后端面试真题里反复出现的、面试官喜欢追问的、以及线上排查真正会用到的必须讲透、讲到能落地。这份内容会持续更新第一篇先把后端面试网络考察的整体版图拆开再从HTTP协议族这个应用层大头开始切入。阅读下面的内容不需要你提前背下多少协议号从零开始跟下来就行。但如果你是带着一两年的后端研发经验来看我建议重点看每节最后的追问视角——那是面试官真正想区分“背过八股文”和“真懂网络”的地方。1. HTTP协议族后端面试的考察纵深与版本演进陷阱后端面试里HTTP是绝对的重头戏。哪个后端业务不是跑在HTTP接口之上的RESTful API、网关转发、鉴权中间件、调用链追踪全是围绕HTTP展开的。所以面试官问HTTP不是问“你知道有这东西”而是想确认你对“线上每天亿级调用的底层协议”有没有刨根问底的兴趣。1.1 HTTP/1.1的核心机制keep-alive、流水线与队头阻塞的代价先聊HTTP/1.1。很多同学只知道“1.1支持长连接比1.0好”但面试官一旦追问“长连接解决了什么问题、带来了什么问题”场面就冷下来了。HTTP/1.0时代每个请求都要新建一次TCP连接HTTP/1.1引入了keep-alive机制允许同一个TCP连接上串行发送多个请求。这是质的飞跃因为TCP连接的建立要经历三次握手每减少一次握手就省下了一个RTT往返时间。但keep-alive只是解决了“复用连接”的问题并没有解决“同一个连接上的请求只能一个一个来”的问题——这就是HTTP/1.1的队头阻塞。用生活化的方式理解HTTP/1.1的连接就像一条单车道后面的车想走必须等前面的车先通过。浏览器为了解决这个问题只能开多个TCP连接一般6到8个每个连接各走各的车道但这也带来了服务器端连接数翻倍的压力。面试官在这个节点最常见的追问有两类。一类是“为什么HTTP/1.1不能多路复用”这属于协议设计层面的问题答案在于HTTP/1.1的报文格式没有帧边界的概念响应必须按请求顺序返回否则客户端无法把响应和请求对应起来。另一类是“线上遇到过队头阻塞怎么处理”这就需要往实践上引比如前端做域名分片、静态资源走CDN等。1.2 HTTP/2的多路复用是虚火还是真有用的关键分水岭HTTP/2的核心改进是引入了二进制分帧层把请求和响应拆分成一个个帧多个帧可以在同一条TCP连接上无序交错传输最后按stream id重组。这就解决了HTTP/1.1的队头阻塞——应用层的队头阻塞没了。但注意面试官如果问到这里真正的杀招在后面HTTP/2解决了应用层队头阻塞但没有解决TCP层队头阻塞。TCP是有序字节流协议如果某个TCP报文段丢了后续所有到达的报文段都要等在缓冲区里直到丢失的报文段重传成功。所以HTTP/2在弱网环境下的表现并不总是优于HTTP/1.1这一点很多只背概念的同学说不出来。另外HTTP/2还有一个常被忽略的细节HPACK首部压缩。它的核心思路是维护一份静态表和动态表用整数索引代替重复的头部字段。比如cookie这种高频重复的头部第一次传输完整值后续只需要传一个索引引用空间节省非常可观。面试官问“HTTP/2为什么比HTTP/1.1快”时如果能答出“二进制分帧消除应用层队头阻塞 首部压缩减体积 多路复用一个连接”就已经超过了大部分候选人。1.3 HTTP/3为何重写传输层从TCP到QUIC的底层动机HTTP/3是个很好的加分项面试官不见得每场都问但主动提出来会显得你的技术视野是持续更新的。HTTP/3的核心变化是传输层从TCP换成了QUIC协议而QUIC是基于UDP实现的。为什么不继续在TCP上做改进因为TCP的协议栈太老、操作系统内核里改起来太慢而且TCP不支持连接迁移——比如手机从WiFi切到4G网络TCP连接就断了必须重新握手。QUIC则通过连接IDConnection ID实现了连接迁移切换网络后对端仍然可以识别这条连接。这是很典型的面试表达素材HTTP/3并不是“UDP比TCP好所以换了”而是TCP在设计之初就没考虑过移动互联网这种网络随时切换的场景而UDP足够轻量可以在用户态重造一个具备可靠性的传输协议。能够讲清楚这层设计动机说明你不是在背“HTTP/3用QUIC”这个结论而是理解了它为什么存在。2. TCP三次握手与四次挥手不能只会背过程要看懂设计动机TCP题是后端面试的保留项目。但有一个现象很普遍几乎所有人都会背“三次握手、四次挥手”但一被追问“为什么是三次不是两次”、“为什么挥手要四次”就开始含糊。这是因为大多数人都只背了状态转移图没有理解过程中每个包的设计意图。2.1 三次握手的本质全双工同步序列号的过程三次握手不是为了“确认双方在线”而是为了同步双方的初始序列号ISN。TCP的可靠性建立在序列号机制上——接收方需要按序重组数据也需要通过确认号告诉发送方“我收到了哪些字节”。如果序列号没有同步好后续所有数据传输都会错乱。握手过程我们重新捋一遍客户端发送SYN报文携带自己的初始序列号x假设x1000表示“我准备好了我的起始序号是1000你能收到吗”。服务端收到SYN后回复SYNACK报文携带两个信息确认号ackx1表示“我收到你的序列号了下一条请发1001号字节给我”同时带上服务端自己的初始序列号y假设y2000表示“我也准备好了我的起始序号是2000”。客户端收到后回复ACK报文确认号acky1告诉服务端“我收到你的序列号了下次你从2001号字节开始发”。看到这里为什么是三次而不是两次就很好解释了如果只有两次握手那么客户端能确认“我能发我能收”服务端能确认“我能收”但服务端没法确认“我发的客户端能不能收到”。路径是两个方向的每个方向都要验证互通性所以至少需要第三个报文让服务端确认自己的发送能力。面试官还爱追问一个变体问题为什么握手之后的“老SYN报文”可以被识别出来答案指向实习期连接列表半连接队列的历史残留。比如客户端发送的SYN在网络里绕了一圈才到达服务端服务端回复SYNACK后客户端发现这个连接自己已经不想要了就发一个RST中断——这个过程其实是靠序列号同步来防旧的重复SYN的。2.2 四次挥手的核心为什么主动关闭方需要TIME_WAIT状态四次挥手的过程本身很容易背但值得深挖的有两个点第一个是为什么要四次——因为TCP是全双工的每个方向需要独立关闭。客户端不再发送数据了服务端可能还有数据要发所以“关闭连接”这个动作要分成两个方向分别完成。客户端发FIN表示“我不发了”服务端回ACK表示“知道了”等服务端也把数据发完再发FIN给客户端客户端再回ACK。这就是四次的由来本质是两次“两次握手”的叠加。第二个点是TIME_WAIT状态。主动关闭方第一次发FIN的一方在收到对方的FIN并回复ACK之后会进入TIME_WAIT状态持续2MSL最长报文段生命周期通常为2分钟之后才真正关闭。为什么要等这么久两个原因。一是为了保证最后一个ACK能到达对端。如果这个ACK丢了对端会超时重发FIN如果此时主动关闭方已经关闭了连接就会返回RST而不是ACK导致对端异常关闭。等一个2MSL足够让重发的FIN和新的ACK顺利完成交接。二是为了让旧连接中的所有报文在网络中消失掉避免“新连接收到了旧连接残留报文”的混乱——因为端口号可能被复用2MSL恰好是报文在网络中存活的最大时间的两倍足以清空残留。后端的同学这里一定要和线上场景联系起来。服务端Echo服务、频繁重启的服务节点经常出现大量TIME_WAIT状态的连接就是因为每次主动关闭都留下了2MSL的残影。处理方案有调整TCP参数允许TIME_WAIT复用和快速回收现在Linux中快速回收基本废弃有条件的话更推荐升级到HTTP/2降低连接数从根上减少TIME_WAIT的数量。面试官问TIME_WAIT如果只背出“2MSL”而没有这个工程视角大概率会继续追问到哑口无言。2.3 SYN Flood与半连接队列面试官最爱的攻击场景变体TCP握手的三次交互也是DDoS攻击最经典的发力点之一。SYN Flood的原理是攻击者伪造大量不存在的源IP地址向服务端发送SYN报文。服务端每次收到SYN都要分配内核结构体、进入半连接队列并回复SYNACK但回复永远等不到应答——因为源IP是伪造的。半连接队列很快就会被打满后续正常用户的SYN请求直接被丢弃表现为目标服务对外“拒绝服务”。围绕这个场景的追问通常有两条线。一条是内核层面的防御机制SYN Cookie就是完全不给半连接队列分配资源而是通过加密计算将连接状态编码到SYNACK的序号里等客户端回ACK时再解码恢复。另一条是工程设计上的思考为什么半连接队列和全连接队列要分开半连接是“还没建立完整会话”的请求资源占用更少全连接是“握完手了可以开始传业务数据”的请求资源权重更高。分开才能做到分级保护阻断恶意流量又不影响正常流量。3. TCP可靠性机制一定要懂的滑动窗口、拥塞控制与粘包拆包确认号ACK、超时重传这些基础概念大多数人都能答出来但后端面试真正拉开差距的是滑动窗口和拥塞控制——因为这两个机制直接决定了网络吞吐和业务性能线上性能排查绕不开。当然还要加上面试考察频率极高的粘包拆包问题这几乎是每个后端开发都在Netty或长连接业务中踩过的坑。3.1 滑动窗口一次能发多少个包取决于谁的承受能力TCP的流量控制是靠接收方通告一个接收窗口rwnd来实现的接收方在ACK报文里带上“自己还剩多少缓冲区”发送方只能发不超过这个窗口大小的数据量——慢接收方的缓冲区不会被打爆。这个机制叫做流量控制它的作用范围是端到端也就是“对端的承受能力”。滑动窗口的实际含义是允许发送方连续发送多个未被确认的报文段。想象窗口是一个调度队列队列里的数据包发出去后左边的边界会随着ACK到达向后滑动右边边界也相应推进窗口内始终有空间装新数据。面试一个高频追问是“如果接收窗口是0怎么办”。答案是发送方进入零窗口探测状态周期性地发送一小段探测报文问“窗口现在空出来了吗”。这属于T CP的边缘机制能答上来说明你真的看过协议实操细节而不是只背了层状模型。3.2 慢启动与拥塞避免瓶颈在网络路径上而非对端流量控制管的是“对端能吃多少”但路径上还有一堆路由器和交换机它们的缓冲也有限。TCP引入拥塞窗口cwnd由发送方自己根据丢包和往返时延来推测“网络路径能承受多少”。真正的发送窗口大小 min(rwnd, cwnd)。慢启动阶段cwnd从一个很小的初始值初始窗口通常是十个左右MSS现代Linux已是10而不是1开始每次收到ACK指数增长1、2、4、8……直到达到一个慢启动阈值ssthresh然后切换成拥塞避免变为线性加性增每次RTT只加一个MSS。传统的拥塞判定标准是超时重传那么快重传和快恢复呢如果收到三个重复的ACK说明有单个报文丢了但后续报文还活着发送方不必等超时立即进入快速重传——重发丢失的数据并把ssthresh降为当前cwnd的一半cwnd也减半这就是快速恢复。这套AIMD加性增、乘性减机制保证了网络接近拥塞点时会退让而拥塞缓解后又稳步试探。后端的同学一定要把拥塞控制和业务场景挂钩跨机房跨地域的调用的RTT和丢包率高拥塞窗口总是被压低吞吐上不去SD-WAN专线常通过定制协议栈解决这个问题本质上就是在绕开TCP的过度保守假设。面试问到“为什么跨地域传输性能差且容易超时”能从拥塞窗口切入的答案明显比背“物理距离远”更有层次。3.3 粘包拆包TCP是字节流不是消息流这个知识点太典型了。TCP是流式协议它只保证字节的顺序不关心包里装的是不是一条完整的业务消息。发送方写了两条业务消息接收方可能一次性把两条都读到粘包也可能读到一条半拆包。原因很简单应用层发送的数据会被分割成大小不等的TCP段而接收方每次read能取到的字节数取决于内核缓冲区和用户态缓冲区的状态。面试问“怎么解决粘包拆包”时要按方案分层回答。最经典的是定长消息每条消息固定长度不足补零长度不可变但简单可靠其次是分隔符协议像HTTP的头部结束用\r\n\r\n读到分隔符就认为一个包结束了最通用的是在每个消息前加上长度字段比如4字节的int接收方先读长度再读对应字节数的数据这是大部分RPC框架采用的方案。Netty里面的LengthFieldBasedFrameDecoder就是干这件事的GitHub上面能看到大量基于软负载均衡的私人框架都直接抄了这一手。提示面试中如果聊到Netty的粘包拆包可以补一句“所以用Netty写tcp服务端第一件事就是配置pipeline里的拆包解码器再写自己的Handler”这句话会让面 试官确认你不是只读过八股文。4. HTTPS与TLS握手后端排查线上加密链路的关键线索互联网已经全面进入HTTPS时代后端开发每天都会被TLS证书过期、混合内容告警、SSL握手超时折磨。所以面试官问HTTPS并不是纯粹考密码学而是在探你有没有处理过线上真实TLS问题的工程能力。4.1 非对称加密解决密钥分发对称加密解决性能HTTPS的本质是HTTP跑在TLS安全传输层协议之上。TLS干了两件核心的事一是加密——保证第三方看不到内容二是认证——保证通信对象是真的。性能上对称加密远优于非对称加密所以TLS实际的数据传输用的是对称加密算法如AES但对称加密的密钥不能直接传输否则中间人截获后就全裸奔了。所以握手阶段使用非对称加密如RSA或ECDHE来安全地协商出一个会话密钥后续数据加密全部用对称加密做的。这里牵扯出一个非常经典的安全概念叫前向保密Forward Secrecy。用RSA密钥交换时如果服务器私钥泄露攻击者可以回溯解密所有历史流量。而ECDHE这种临时密钥交换方式每次握手产生临时私钥且用完即弃即使服务器长期私钥泄露历史流量也无法被解密。所以现代TLS部署都会禁用RSA密钥交换只看这一条可以判断一个后端是不是真的懂HTTPS而不是只会说“用了加密”。4.2 TLS 1.2握手过程中的四个关键步骤为了便于排查线上问题把TLS 1.2的握手过程压缩成四个步骤理解ClientHello客户端发送支持的TLS版本、支持的密码套件列表和一个随机数。ServerHello 证书服务端选择一个密码套件发证书证书链和一个随机数。客户端验证证书是否可信包括证书是否过期、域名是否匹配、颁发者是否在信任链上。密钥交换根据密码套件客户端生成或计算出预备主密钥比如用ECDHE选择临时公钥然后用服务端公钥加密或进行ECDHE参数交换发回ChangeCipherSpec通知开始加密通信紧接着发Finished消息这条消息以后的数据全部加密。服务端收到后同样发送自己的ChangeCipherSpec和Finished握手完成后续应用数据全部走对称加密。线上最常见的HTTPS问题就能和这个流程对上了证书过期发生在第2步——客户端校验证书链时发现失效时间已经过了当前时刻TLS版本不匹配发生在第1步——服务端只支持TLS 1.3、客户端只能TLS 1.2两边版本重合不起来直接把连接断掉而“握手超时”通常不是TLS本身的问题而是TCP建立都慢想定位需要先分清楚连接卡在TCP层还是TLS层。4.3 TLS 1.3简化了什么两个RTT到一RTT的变化TLS 1.3是现在部署的趋势它的核心优化是把握手从2-RTT压缩到1-RTT。怎么做呢主要是简化了密码套件列表废弃了一堆不安全的算法同时允许客户端在ClientHello里直接带上自己支持的公钥key_share服务端回复时直接确认RTT就省掉了一半。再加上0-RTT模式的会话恢复客户端可以把上一次会话协商的结果缓存起来新连接直接在第一个包里发加密数据。面试如果问到这里最好能补一个工程维度TLS 1.3对握手延迟的优化是量级的但0-RTT模式有重放攻击风险后端幂等设计要做好才有资格开启。这种回答能把一个加分项变成两个加分项。5. DNS到IP寻址再到CDN从输入URL到页面背后的全网遍历后端面试特别喜欢“从输入URL到页面展示”这种综合分析题它把浏览器、DNS、HTTP、TCP、负载均衡、后端处理全部串在一条链路上。能流畅地把这条链路讲清楚本身就是网络基本功扎实的证明。5.1 DNS解析的两种查询方式别名、TTL与缓存失效DNS解析的第一步是查浏览器缓存Cache没命中就去查操作系统缓存hosts文件、系统解析器缓存然后才是本地DNS服务器通常由运营商提供。本地DNS服务器会先查自己的缓存如果没有就发起迭代查询逐级去问根DNS服务器、顶级域服务器、权威DNS服务器。这里有两个概念很容易混淆递归查询和迭代查询的区别。递归查询是“你帮我查完再告诉我结果”一般是客户端与本地DNS服务器之间迭代查询是“你告诉我下一级去哪问”一般是本地DNS服务器与各级域名服务器之间。简单理解递归是一条龙服务迭代是带你指路。高频追问是“为什么刚改完DNS配置不生效”。这里要讲到三个原因一是终端和本地DNS服务器都有缓存TTL没到就不会重新查询二是一些公共DNS服务为了性能可能忽略短TTL强制缓存更长时间三是HTTP连接长连接保持中浏览器根本不会为已有连接重新发起DNS查询。面试时如果能分点答出“浏览器缓存、系统缓存、DNS服务器缓存、连接重用”这四个层级就不会只说一句“是缓存问题”了。5.2 四层与七层负载均衡的选择逻辑DNS拿到的是一个VIP地址虚拟IP这个IP背后挂着一堆真实业务服务器。后端面试几乎必问“四层和七层负载均衡的区别和应用场景”。四层负载均衡工作在传输层能感知到TCP/UDP四元组源IP、源端口、目的IP、目的端口转发时候不用去看协议内容直接按策略派发到后端RSReal Server性能高很多。七层负载均衡像nginx工作在应用层能感知HTTP协议头里的路径、Host、Cookie可以做更精细的路由规则比如按URL前缀转发到不同的微服务集群。选择逻辑很容易说清吞吐量大、转发要求极致性能往上四层走业务路由复杂、需要按内容分发必须上七层。很多大型系统是两层配合LVS四层扛流量入口Nginx七层做业务路由。能把这个层次结构讲出来面试官会觉得你对架构选型有整体把握。5.3 CDN是如何通过DNS智能调度实现就近访问的最后一步的关键技术是CDN内容分发网络。它的核心思想是“内容离用户越近访问越快”。实现方式值得展开说用户查询某个域名时域名不是直接指向源站IP而是指向CDN厂商的GSLB全局负载均衡设备。GSLB会拿到用户的local DNS出口IP然后根据IP的地理位置、运营商归属、各边缘节点的负载状态返回一个离用户最近的边缘节点IP。用户随后直接请求这个边缘节点如果节点上有缓存就直接返回缓存没有就去源站回源取内容再缓存。这里的“智能调度”依赖于DNS但这是CDN的一部分本质上是把服务发现能力显式地嵌入到了域名解析过程里。所以DNS被戏称为分布式系统的第一层负载均衡是有一点道理在的。面试追问“为什么刷新CDN缓存后访问还是旧资源”答案通常指向CDN节点边缘到客户端之间还有一层浏览器缓存或者回源策略里的“回源时校验Last-Modified/ETag”没有生效。能答出边缘缓存与浏览器缓存的层级关系又是个加分点。6. 高频追问复盘与这份内容的后续规划这份《最详细的后端面试系列内容—计算机网络持续更新中》的第一篇到这里算是把后端面试网络考察的主干链路完整过了一遍HTTP协议族的演进、TCP握手与断开的底层逻辑、可靠性与流量控制的机制、HTTPS加密链路的工作流程、DNS/CDN全链路寻址。但这只是个开头。下面这几个问题在后续的内容里会单独成篇展开抓包分析如何用Wireshark抓包看懂TCP重传与乱序这个技能对于后端排查线上慢接口非常有用TIME_WAIT和CLOSE_WAIT大量出现时的系统级排查思路不要看到状态多就慌先用ss命令统计状态分布Nginx反向代理中的HTTP参数调优proxy_buffering、keepalive_timeout、gzip等参数的组合策略高性能网络框架I/O模型拆解epoll的核心机制和Reactor多线程模型的应用以及Netty这种框架干的问题。我个人的建议是看任何一章都主动追问自己一遍“这个机制如果在线上出问题我该怎么定位”。比如看了TIME_WAIT就去想线上大量TIME_WAIT说明什么、怎么用netstat确认、什么业务场景会触发。这个试图从死的知识联想到活的场景的习惯远比背下所有协议状态机更能帮你通过面试——也是后端开发这条路上真正拉开差距的地方。这份内容我会持续更新下次先把问卷调查中大家最感兴趣的I/O多路复用select/poll/epoll完整拆透然后逐步补充实战案例。想第一时间看到后续内容的同学可以保持关注或者直接带着你面试中遇到的计算机网络相关真题来评论区——下一批文章中可能就会把这个问题拿出来做深度拆解。