后端面试里，计算机网络这块儿的地位很特殊。它不像算法那样刷题就能速成，也不像中间件那样会个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则通过连接ID（Connection ID）实现了连接迁移，切换网络后对端仍然可以识别这条连接。这是很典型的面试表达素材：HTTP/3并不是“UDP比TCP好所以换了”，而是TCP在设计之初就没考虑过移动互联网这种网络随时切换的场景，而UDP足够轻量，可以在用户态重造一个具备可靠性的传输协议。能够讲清楚这层设计动机，说明你不是在背“HTTP/3用QUIC”这个结论，而是理解了它为什么存在。2. TCP三次握手与四次挥手：不能只会背过程，要看懂设计动机TCP题是后端面试的保留项目。但有一个现象很普遍：几乎所有人都会背“三次握手、四次挥手”，但一被追问“为什么是三次不是两次”、“为什么挥手要四次”就开始含糊。这是因为大多数人都只背了状态转移图，没有理解过程中每个包的设计意图。2.1 三次握手的本质：全双工同步序列号的过程三次握手不是为了“确认双方在线”，而是为了同步双方的初始序列号（ISN）。TCP的可靠性建立在序列号机制上——接收方需要按序重组数据，也需要通过确认号告诉发送方“我收到了哪些字节”。如果序列号没有同步好，后续所有数据传输都会错乱。握手过程我们重新捋一遍：客户端发送SYN报文，携带自己的初始序列号x（假设x=1000），表示“我准备好了，我的起始序号是1000，你能收到吗”。服务端收到SYN后，回复SYN+ACK报文，携带两个信息：确认号ack=x+1表示“我收到你的序列号了，下一条请发1001号字节给我”；同时带上服务端自己的初始序列号y（假设y=2000），表示“我也准备好了，我的起始序号是2000”。客户端收到后，回复ACK报文，确认号ack=y+1，告诉服务端“我收到你的序列号了，下次你从2001号字节开始发”。看到这里，为什么是三次而不是两次就很好解释了：如果只有两次握手，那么客户端能确认“我能发，我能收”，服务端能确认“我能收”，但服务端没法确认“我发的客户端能不能收到”。路径是两个方向的，每个方向都要验证互通性，所以至少需要第三个报文让服务端确认自己的发送能力。面试官还爱追问一个变体问题：为什么握手之后的“老SYN报文”可以被识别出来？答案指向实习期连接列表（半连接队列）的历史残留。比如客户端发送的SYN在网络里绕了一圈才到达服务端，服务端回复SYN+ACK后，客户端发现这个连接自己已经不想要了，就发一个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都要分配内核结构体、进入半连接队列并回复SYN+ACK，但回复永远等不到应答——因为源IP是伪造的。半连接队列很快就会被打满，后续正常用户的SYN请求直接被丢弃，表现为目标服务对外“拒绝服务”。围绕这个场景的追问通常有两条线。一条是内核层面的防御机制：SYN Cookie就是完全不给半连接队列分配资源，而是通过加密计算将连接状态编码到SYN+ACK的序号里，等客户端回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、目的端口），转发时候不用去看协议内容，直接按策略派发到后端RS（Real 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）完整拆透，然后逐步补充实战案例。想第一时间看到后续内容的同学，可以保持关注，或者直接带着你面试中遇到的计算机网络相关真题来评论区——下一批文章中可能就会把这个问题拿出来做深度拆解。
后端面试里，计算机网络这块儿的地位很特殊。它不像算法那样刷题就能速成，也不像中间件那样会个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则通过连接ID（Connection ID）实现了连接迁移，切换网络后对端仍然可以识别这条连接。这是很典型的面试表达素材：HTTP/3并不是“UDP比TCP好所以换了”，而是TCP在设计之初就没考虑过移动互联网这种网络随时切换的场景，而UDP足够轻量，可以在用户态重造一个具备可靠性的传输协议。能够讲清楚这层设计动机，说明你不是在背“HTTP/3用QUIC”这个结论，而是理解了它为什么存在。2. TCP三次握手与四次挥手：不能只会背过程，要看懂设计动机TCP题是后端面试的保留项目。但有一个现象很普遍：几乎所有人都会背“三次握手、四次挥手”，但一被追问“为什么是三次不是两次”、“为什么挥手要四次”就开始含糊。这是因为大多数人都只背了状态转移图，没有理解过程中每个包的设计意图。2.1 三次握手的本质：全双工同步序列号的过程三次握手不是为了“确认双方在线”，而是为了同步双方的初始序列号（ISN）。TCP的可靠性建立在序列号机制上——接收方需要按序重组数据，也需要通过确认号告诉发送方“我收到了哪些字节”。如果序列号没有同步好，后续所有数据传输都会错乱。握手过程我们重新捋一遍：客户端发送SYN报文，携带自己的初始序列号x（假设x=1000），表示“我准备好了，我的起始序号是1000，你能收到吗”。服务端收到SYN后，回复SYN+ACK报文，携带两个信息：确认号ack=x+1表示“我收到你的序列号了，下一条请发1001号字节给我”；同时带上服务端自己的初始序列号y（假设y=2000），表示“我也准备好了，我的起始序号是2000”。客户端收到后，回复ACK报文，确认号ack=y+1，告诉服务端“我收到你的序列号了，下次你从2001号字节开始发”。看到这里，为什么是三次而不是两次就很好解释了：如果只有两次握手，那么客户端能确认“我能发，我能收”，服务端能确认“我能收”，但服务端没法确认“我发的客户端能不能收到”。路径是两个方向的，每个方向都要验证互通性，所以至少需要第三个报文让服务端确认自己的发送能力。面试官还爱追问一个变体问题：为什么握手之后的“老SYN报文”可以被识别出来？答案指向实习期连接列表（半连接队列）的历史残留。比如客户端发送的SYN在网络里绕了一圈才到达服务端，服务端回复SYN+ACK后，客户端发现这个连接自己已经不想要了，就发一个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都要分配内核结构体、进入半连接队列并回复SYN+ACK，但回复永远等不到应答——因为源IP是伪造的。半连接队列很快就会被打满，后续正常用户的SYN请求直接被丢弃，表现为目标服务对外“拒绝服务”。围绕这个场景的追问通常有两条线。一条是内核层面的防御机制：SYN Cookie就是完全不给半连接队列分配资源，而是通过加密计算将连接状态编码到SYN+ACK的序号里，等客户端回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、目的端口），转发时候不用去看协议内容，直接按策略派发到后端RS（Real 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）完整拆透，然后逐步补充实战案例。想第一时间看到后续内容的同学，可以保持关注，或者直接带着你面试中遇到的计算机网络相关真题来评论区——下一批文章中可能就会把这个问题拿出来做深度拆解。