简介面向IT求职者和后端/前端开发者的计算机基础核心知识点PDF资料聚焦计算机网络高频面试题源自代码随想录知识星球“最强八股文”第五版计算机基础篇。内容覆盖TCP三次握手与四次挥手、HTTP与HTTPS区别、DNS域名系统的层级结构与递归/迭代查询过程、HTTP强缓存与验证缓存机制等核心考点并以“浏览器输入URL到页面渲染”为主线串联各知识点每个主题均采用“高频重点一问一答”结构辅以过程图解帮助读者理解为什么需要三次握手而非两次、HTTP缓存何时生效等深层逻辑避免死记硬背。资源包内共1个PDF文件大小约37.83MB适合离线阅读与反复查阅。目前已有777人学习下载可作为面试前系统梳理计算机网络重点、查漏补缺和快速复盘的首选资料。1. 知识地图一条URL主线串起整个计算机网络在浏览器里输入一串URL再按下回车这几乎是每个人每天都会做的动作但它其实是计算机基础里考点密度最高的一道题。从URL解析、DNS域名解析、TCP三次握手到HTTP请求、服务器处理、浏览器渲染再到TCP四次挥手一条链路上覆盖了计算机网络面试的高频区。真正系统地复习计算机网络不需要按教材章节线性硬啃。更有效的做法是顺着这条主线把每个环节拆开再把环节之间的衔接关系补上——每一个环节都可以往深处追问每一个追问都会牵出下一章的知识点。这份复习笔记适合正在系统梳理网络基础、准备面试或者想把HTTP和TCP重新理清的人第2章先从这条链路的起点讲起域名是怎么变成IP的。2. DNS与URL解析从域名到IP的完整寻址链路2.1 DNS是什么为什么分布式是必然选择DNSDomain Name System的作用一句话就能说清把域名比如 www.example.com翻译成IP地址比如 203.0.113.10。网络设备之间通信靠的是IP但数字不方便人记忆所以用域名替代。这里最容易被一笔带过的问题是为什么DNS一定要设计成分布式的如果采用一台集中的DNS服务器来扛所有查询会出现四个问题。单点故障这一台DNS服务器一旦崩溃整个网络跟着瘫痪通信容量所有设备的查询请求都打向一台服务器上百万上千万级别的请求量根本扛不住远距离时延集中式服务器不可能同时邻近所有用户跨地域查询会经过低速拥堵链路产生严重延迟维护成本域名映射需要频繁更新集中式维护的代价极大。这四个问题决定了DNS必须采用层级化、分布式的结构。梳理下来会发现面试时如果只背“DNS是域名转IP的系统”是不够的追问一句“为什么不用集中式”就会暴露理解深度。把这四个问题记住本质上也就理解了整个DNS设计的前提。2.2 域名层级与完整解析过程域名的层级关系用句点分隔越靠右的位置层级越高。例如 www.example.com 中com 是顶级域example 是二级域www 是主机名。这个层级关系对应着DNS服务器的查询路径根DNS服务器 → 顶级域DNS服务器 → 权威DNS服务器。完整解析过程可以拆成八步按“从近到远”的顺序记忆查询浏览器缓存看是否有该域名对应的IP浏览器缓存没有查本机 Hosts 文件Hosts 也没有向本地DNS服务器通常由网络运营商提供发查询请求本地DNS有缓存就直接返回没有缓存就向根DNS服务器发查询根DNS服务器不负责解析只告诉本地DNS该去哪个顶级域.com / .net / .org继续查顶级域DNS服务器也不直接返回IP而是告诉本地DNS去哪个权威DNS服务器本地DNS向权威DNS服务器发起查询拿到真正的域名-IP映射本地DNS把IP返回给浏览器并在本地缓存一份下次访问更快。实际开发中最容易忽略的是第2步Hosts文件。联调环境、本地改域名指向都靠它但很多人排查DNS问题的时候把它忘了。Windows在 C:\Windows\System32\drivers\etc\hostsLinux/macOS在 /etc/hosts这个文件可以手动指定域名对应的IP配置后优先于DNS解析生效。# /etc/hosts 示例 127.0.0.1 localhost 203.0.113.10 api.example.com排查“为什么域名解析不对”时先看Hosts文件有没有被改过这是成本最低的一步。整个解析过程本身不难背难的是每一步的触发条件缓存、Hosts、本地DNS、根、顶级、权威这个顺序不能乱漏掉Hosts是常见错误。2.3 递归查询与迭代查询两种查询模式的本质区别递归查询和迭代查询是DNS解析中容易混淆的一对概念。区别不在于“问了几次”而在于“谁帮你查完”。递归查询中DNS客户端向某个DNS服务器发一个查询请求要求对方直接给出完整解析结果。收到请求的服务器会自行逐级查询下一级服务器拿到最终结果后返回给客户端。客户端全程只发一次请求、等一次结果。迭代查询中DNS客户端向某一层DNS服务器查询时对方不直接给最终结果而是返回“下一站该找谁”的地址客户端再自己去查下一站一层层迭代下去直到拿到完整结果。对比项递归查询迭代查询谁来完成后续查询上层DNS服务器代劳客户端自己逐级查询客户端请求次数1次多次返回内容最终IP地址下一级服务器地址典型场景普通用户向本地DNS发起DNS服务器之间的逐级指引一个容易踩坑的地方回答“DNS解析过程”时用户到本地DNS这一段是递归查询本地DNS到根、顶级、权威这一段是迭代查询。面试官如果追问“本地DNS到底怎么工作”能区分出这两个模式就不会乱。面向用户的是递归服务器之间是迭代。3. TCP连接管理三次握手与四次挥手的核心考点3.1 三次握手建立可靠连接的最小代价TCP连接建立的三次握手是计算机网络面试中重复率最高的内容没有之一。流程本身不难记客户端先发SYN序列号设为x服务器收到后回复SYNACK自己的序列号设为y确认号为x1客户端再回一个ACK确认号为y1。但为什么必须是三次不是两次、四次这是区分“背过”和“理解”的分水岭。核心原因是三次握手能让双方都确认“自己的发送能力”和“对方的接收能力”是正常的。第一次握手后服务器确认客户端的发送能力正常第二次握手后客户端确认自己的发送和接收都正常、服务器的发送和接收也正常第三次握手后服务器确认客户端的接收能力正常。两次握手无法让服务器确认客户端的接收能力而四次握手是冗余的——第三次客户端确认完双方能力后连接就可以建立了。另一个高频追问是“第一次握手丢失会发生什么”。客户端发出SYN后启动重传定时器超时未收到SYNACK就会重传SYN。重传次数由系统参数控制超过最大重传次数后放弃连接此时客户端会报连接超时。这里要顺带记住第二次握手丢失也一样——客户端收不到SYNACK会重传SYN服务器收到重复的SYN会重新回复SYNACK。前两次握手丢包都是客户端侧重传不会有数据丢失风险。关于“三次握手过程中可以携带数据吗”标准回答是前两次握手不能携带数据第三次可以。原因在于前两次握手中服务器还没有确认客户端的接收能力此时携带数据可能造成数据在不可靠的连接上被发送第三次握手时客户端已经确认双方收发能力正常可以捎带数据能减少一次RTT的开销。3.2 四次挥手为什么断开比建立更复杂断开连接的流程比建立连接多一次因为TCP连接是全双工的两个方向必须分别关闭客户端发送FIN表示“我的数据发完了不再发送数据”服务器回复ACK表示“收到你的FIN但我还有数据要发”服务器数据全部发完后也发送FIN表示“我也没数据了”客户端回复ACK双方完全断开。为什么不能合并成三次因为第2步和第3步之间服务器可能还有数据要发送。如果服务器收到FIN后立即回复FINACK那数据就来不及传完。只有等服务器把自己的数据全部发完才能发FIN。这个“等待数据发完”的时间就是第2、3步之间必须隔开的原因。四次挥手还有一个隐藏考点TIME_WAIT状态。主动关闭方通常是客户端在发送最后一个ACK后不会立刻关闭连接而是进入TIME_WAIT状态等待2MSL最大报文段生存时间后才真正关闭。原因有两个一是确保最后一个ACK能到达对方如果ACK丢失对方会重发FIN主动方需要能重新响应二是让本连接中所有还在网络中游荡的迟到报文段自然消失避免污染后续使用同一端口的新连接。很多人背了TIME_WAIT这个词但说不清为什么是主动关闭方等待、为什么是2MSL这两点要一起记。3.3 易错边界握手与挥手中的状态与丢包TCP这一块知识不难背但很容易在小细节上翻车。梳理下来发现最高频的易错点集中在几个地方握手是3次、挥手是4次原因是“全双工关闭需要两个方向各完成一次FIN/ACK交换”而不是“多一次更保险”挥手第2步的ACK和第3步的FIN不能合并的前提是服务器还有数据要发如果服务器收到FIN时已经没有数据也完全可以合并为FINACK此时实际是三次挥手建立连接时服务端收到SYN后处于SYN_RCVD状态客户端收到SYNACK后进入ESTABLISHED挥手过程中主动关闭方会经历FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT被动方经历CLOSE_WAIT、LAST_ACK。状态变迁建议自己画一遍面试官经常从状态切入追问。阶段方向报文关键状态第一次握手客户端 → 服务器SYNSYN_SENT / LISTEN第二次握手服务器 → 客户端SYN ACKSYN_RCVD第三次握手客户端 → 服务器ACKESTABLISHED第一次挥手客户端 → 服务器FINFIN_WAIT_1第二次挥手服务器 → 客户端ACKCLOSE_WAIT / FIN_WAIT_2第三次挥手服务器 → 客户端FINLAST_ACK第四次挥手客户端 → 服务器ACKTIME_WAIT提示回答“四次挥手过程”时按表里的顺序讲完报文再补状态名基本就不会被追问卡住。状态名是很多人背诵时漏掉的一环但面试官往往就靠这个区分度判断是否真懂TCP。4. HTTP协议家族从1.0到3.0的演进与性能对比4.1 HTTP基础特性简单、灵活、无状态、明文和不安全HTTP是Web通信的基石。它的特性可以概括为“简单、灵活、易于扩展、应用广泛和跨平台”但面试官通常更想听的是它的问题面无状态、明文传输、不安全。无状态意味着服务器不会主动记住客户端的状态每次请求都是独立的。好处是服务器不用额外资源维护状态坏处是完成有关联性的操作很麻烦。解法是Cookie——在请求和响应报文中写入Cookie信息来控制客户端状态。这个知识点常和Session一起考记住Cookie是放在客户端的状态凭证即可。明文传输带来的是便利和危险并存。便利在于用抓包工具就能直接看到请求内容调试方便危险在于信息透明内容可能被窃听。不安全主要体现在三点通信明文不加密、内容可能被窃听不验证通信方身份、可能遭遇伪装无法证明报文完整性、可能已遭篡改。解法就是HTTPS——在HTTP与TCP之间加一层SSL/TLS安全传输层。回答“HTTP和HTTPS的区别”时就从这三个不安全点出发逐个说SSL/TLS怎么解决比背字段名更有逻辑。另外建议记一下HTTP的三项构建技术HTML作为页面文本标记语言、HTTP作为文档传递协议、URL作为指定文档所在地址这个点很小但“描述一下HTTP”这种开放题里可以用来开局。4.2 HTTP/1.0到HTTP/1.1长连接、管道与队头阻塞HTTP/0.9是最早的版本只支持GET方法、没有请求头、服务器只能返回HTML格式内容现在几乎见不到了。到HTTP/1.0才是第一个正式版本引入了请求头和响应头支持多种请求方法和状态码但不支持持久连接——每次请求都要重新建立TCP连接。这个设计在现代网页场景下性能很差所以HTTP/1.1重点做了两件事长连接和管道网络传输。长连接持久连接解决了反复建连的开销只要客户端和服务器任意一端没有明确提出断开TCP连接就一直保持。管道网络传输则更进一步同一条TCP连接里客户端可以连续发出多个请求不必等第一个响应回来就发第二个。注意这里的关键限制——服务器必须按照接收请求的顺序发送响应。如果前一个请求处理很慢后面所有响应都要排队等这就是响应队头阻塞。HTTP/1.1还遗留了几个问题头部冗余每次请求都重复传输相同的头部字段、没有请求优先级控制、请求只能由客户端发起、服务器只能被动响应。后续HTTP/2基本都是奔着这几个问题去的。这里容易记混的是管道技术理论上解决了请求的队头阻塞但没有解决响应的队头阻塞而且它不是默认开启的浏览器基本都没有支持。回答时不要夸大管道的作用。4.3 HTTP/2头部压缩、二进制帧与Stream并发HTTP/2的改进可以归纳为四点头部压缩、二进制帧、并发传输、服务器推送。HTTP/2基于HTTPS安全性也有保障。这四点在面试中每一点都可以深挖。头部压缩用的是HPACK算法包含三个组成部分静态字典、动态字典、Huffman编码。静态表是HTTP/2框架内置的61组高频头部字段和字符串编码时用短索引号代替完整字符串动态表则依赖同一连接上重复传输完全相同的头部配合Huffman编码进一步压缩。一个容易忽略的细节动态表越大占内存越多Web服务器会提供类似 http2_max_requests 的配置来限制一个连接上能传输的请求数达到上限后关闭连接以释放内存。# Web服务器 HTTP/2 连接请求数限制示例 http2_max_requests 10000;这个配置控制单条HTTP/2连接上允许传输的最大请求数超过后连接会被关闭新请求走新连接。压测或调优时如果看到连接频繁建立可以检查这个值。二进制帧是HTTP/2把文本格式改成二进制格式传输极大提高了解析效率。HTTP/2总共定义了10种类型的帧分成数据帧和控制帧两类。每帧包含流标识符Stream ID接收方根据Stream ID从乱序到达的帧里找到属于同一个Stream的帧再有序组装。并发传输依赖Stream概念多条Stream复用同一条TCP连接不同Stream的帧可以乱序发送所以能做到并行交错地发送请求和响应。这里有三个概念要理清一个HTTP消息Message可以由多个帧Frame构成一个帧可以由多个TCP报文构成多个Stream复用在一条TCP连接上用Stream ID区分。HTTP/1.1是“一个事务做完才能做下一个”HTTP/2是“多个Stream同时进行”这就是吞吐量提升的核心。此外HTTP/2还有流控制、流状态、依赖关系等机制面试中先讲清Stream、Message、Frame三者的关系就够用了。服务器推送是另一个亮点客户端请求HTML时服务器可以主动把CSS、JS等资源直接推给客户端减少消息往返次数。它和WebSocket没有关系是HTTP/2同一条连接上的主动推送。但要注意HTTP/2并没有消灭队头阻塞——它解决的是HTTP层的队头阻塞TCP层的队头阻塞还在。TCP是字节流协议必须保证字节数据完整且连续内核才会把缓冲区的数据交给应用层。如果前1个字节没到后面收到的字节只能在内核缓冲区等着。所以HTTP/2基于TCP就注定逃不掉这个限制这直接催生了HTTP/3。4.4 HTTP/3为什么最终把TCP换成了UDPHTTP/3的核心决策是把下层的TCP换成基于UDP的QUIC协议。要理解这个选择关键是想清楚TCP队头阻塞的本质TCP按序交付一旦某个包丢失后续已到达的包必须排队等待重传即使这些包本身是完整的。对HTTP/2这种多路复用场景一个Stream丢包会影响同一连接上的所有Stream。改用UDP之后QUIC在用户空间实现了自己的可靠传输、拥塞控制和连接迁移并从根上消除了传输层队头阻塞——每条Stream的数据可以独立交付不需要等前面的数据补上。另外QUIC把握手过程也优化了TLS握手和传输握手可以合并减少了建连延迟。回答“HTTP/3解决了什么”时抓住“传输层队头阻塞”和“连接建立延迟”两个点就够了。这章最后值得做一张版本对比总表复习时只看表就能回忆起差异版本连接模型队头阻塞头部压缩传输层HTTP/1.0短连接高无TCPHTTP/1.1长连接管道响应队头阻塞无TCPHTTP/2多Stream复用传输层队头阻塞HPACKTCPHTTP/3QUIC多路复用基本消除HPACK思路演进UDP5. 易漏与易错计算机网络复习中容易失分的细节5.1 高频但容易答不完整的四个点整理这份笔记的过程中最深的感受是高频题大家都会背但追问一层就分化了。以下四个点是失分重灾区按照“易漏点 → 为什么漏 → 怎么补”的方式整理如下。易漏点1三次握手中第一次和第二次握手不能携带数据第三次可以。为什么漏大部分复习资料只画了三次握手的箭头没有标注数据携带规则有人默认成了“握手的每一步都能发数据”。怎么补用因果逻辑记——前两次握手时服务器还没确认客户端的接收能力此时发送数据没有可靠性保障第三次握手时能力确认完毕可以捎带数据节省一个RTT。易漏点2HTTP/2仍然存在队头阻塞只是从HTTP层转移到了TCP层。为什么漏资料里写“HTTP/2解决了队头阻塞”很多人就理解成彻底解决。怎么补队头阻塞有两个层面HTTP/2解决的是应用层请求级的队头阻塞通过Stream并发但TCP按序交付的机制仍然会导致丢包时后续数据排队。面试时主动区分“应用层队头阻塞”和“传输层队头阻塞”反而能加分。易漏点3DNS解析顺序中Hosts文件排在本地DNS之前很多人排查时跳过它。为什么漏平时开发访问的都是公网域名没有改过Hosts所以对这个步骤无感。怎么补在 /etc/hosts 里加一条域名映射再访问亲身体验一下“优先于DNS”的效果以后排查域名异常时自然想到它。易漏点4HTTP/1.1管道网络传输默认不开启浏览器基本没支持。为什么漏教材按理论讲管道但实际环境中几乎没有启用导致很多人以为它是默认行为。怎么补记一个判断口诀——“管道技术解决了请求队头阻塞没解决响应队头阻塞且默认关闭”。5.2 面试追问中容易翻车的三个场景除了上面四个知识点还有三个场景是面试中常见的翻车点。翻车点1被追问“为什么挥手是四次而不是三次”时回答成“因为TCP更可靠”。正确思路是全双工关闭需要两个方向分别关闭被动关闭方可能在收到FIN后还有数据要发所以ACK和FIN必须分开。但特殊情况也要知道如果被动关闭方收到FIN时已经没有数据要发ACK和FIN可以合并实际会出现“三次挥手”。翻车点2被追问“HTTP和HTTPS的区别”时只答“HTTPS加密了”讲不出加密解决的是哪三个问题。正确的答法是把HTTP的三个不安全点窃听、伪装、篡改逐一列出然后说SSL/TLS分别用什么手段解决——加密解决窃听、证书验证解决伪装、报文完整性校验解决篡改。这三个“解决对应关系”比笼统说“更安全”有说服力得多。翻车点3被追问“在浏览器输入URL后发生了什么”时把顺序讲成“先建立TCP连接再做DNS解析”。正确顺序是解析URL → DNS域名解析 → TCP三次握手 → 发送HTTP请求 → 服务器处理并返回响应 → 浏览器渲染页面 → TCP四次挥手。DNS解析在TCP连接之前因为不知道IP地址就无法建立连接。这道题是一个“引导型”题答题时故意把细节讲得慢一点比如展开DNS的八步解析过程会把面试官引到你最熟悉的区域。5.3 浏览器渲染与HTTP缓存里容易忽略的关联浏览器渲染页面这块很多人只知道“构建DOM树、布局、绘制”容易忽略的是回流重排和重绘的区别以及它们和性能的关系。回流是布局阶段重新计算元素几何属性位置、尺寸重绘是绘制阶段重新画元素外观颜色、阴影。回流一定会触发重绘重绘不一定触发回流。回答“前端性能优化”时减少回流是高频手段常见的做法包括批量修改DOM、避免频繁读取布局属性、使用 transform 代替 top/left 动画等。HTTP缓存这个点高频回答方式是按“是否需要发请求”来分强缓存命中时不发请求直接用本地缓存关键字段是Cache-Control优先级高于Expires和Expires协商缓存命中时发请求但服务器返回304浏览器用本地缓存关键字段是Etag/If-None-Match和Last-Modified/If-Modified-Since。容易忽略的是两条优先级规则Cache-Control和Expires同时存在时Cache-Control优先Etag和Last-Modified同时存在时Etag优先。不用死记用“更精确的验证优先于更粗略的时间验证”来理解就顺了。另一个容易漏的点是304是协商缓存命中的响应状态码但很多人在回答“HTTP状态码有哪些”时只会说200和404忘了304、301、302也是高频考点。6. 复习清单与查漏补缺把计算机网络真正装进脑子6.1 一条URL主线自查清单复习到这个阶段只剩最后一件事把知识从“看懂”变成“能脱口而出”。推荐方法是顺着“输入URL回车”这条主线以节点为单位自查每个节点回答三个问题这一阶段发生了什么、为什么需要这一步、通常会被追问什么。可以照着下面这张表过一遍链路节点必须能答出常见追问URL解析解析出协议、主机、端口、路径URL由哪几部分组成DNS解析八步解析过程、递归vs迭代Hosts在哪查、根DNS的作用TCP三次握手报文类型、状态、为什么三次第一次丢失怎么办、能带数据吗HTTP请求请求方式、状态码GET/POST区别、幂等性服务器响应状态码、响应头字段、Cookie304是怎么产生的浏览器渲染DOM树、CSS布局、回流重绘如何减少回流TCP四次挥手FIN/ACK顺序、TIME_WAIT为什么四次、为什么2MSL这张表的前两列是及格线第三列是区分度。能不看资料把第三列的追问也答完这个节点才算真的过了。这份笔记的知识点分布本质上就是在回答这张表的第三列。6.2 查漏补缺的三步法具体操作上建议用“三日反向抽查法”。第一天按表格正向过一遍把卡壳的区域标记出来第二天从底部“四次挥手”反向过到顶部“URL解析”打乱顺序防止顺着背形成路径依赖第三天只复习标记过的区域并且用“自己追问自己”的方式补出原因层逻辑而不是只背结论。说一个我自己的教训有一阵子我按顺序背得很顺从URL一路讲到四次挥手但面试官从“第三次握手能不能带数据”切入就卡住了——因为我的记忆是顺着链路走的没有在每个节点上建立“追问分支”。从那以后我每次复习都强制走一遍“原因层追问”把每个易漏点当作独立问题来回答而不是当成链路中的一环。这个方法帮我避开了很多复习盲区希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 9:56:12 · 阅读 1.2k 从URL输入到TCP与HTTP：计算机网络核心链路复习指南
简介面向IT求职者和后端/前端开发者的计算机基础核心知识点PDF资料聚焦计算机网络高频面试题源自代码随想录知识星球“最强八股文”第五版计算机基础篇。内容覆盖TCP三次握手与四次挥手、HTTP与HTTPS区别、DNS域名系统的层级结构与递归/迭代查询过程、HTTP强缓存与验证缓存机制等核心考点并以“浏览器输入URL到页面渲染”为主线串联各知识点每个主题均采用“高频重点一问一答”结构辅以过程图解帮助读者理解为什么需要三次握手而非两次、HTTP缓存何时生效等深层逻辑避免死记硬背。资源包内共1个PDF文件大小约37.83MB适合离线阅读与反复查阅。目前已有777人学习下载可作为面试前系统梳理计算机网络重点、查漏补缺和快速复盘的首选资料。1. 知识地图一条URL主线串起整个计算机网络在浏览器里输入一串URL再按下回车这几乎是每个人每天都会做的动作但它其实是计算机基础里考点密度最高的一道题。从URL解析、DNS域名解析、TCP三次握手到HTTP请求、服务器处理、浏览器渲染再到TCP四次挥手一条链路上覆盖了计算机网络面试的高频区。真正系统地复习计算机网络不需要按教材章节线性硬啃。更有效的做法是顺着这条主线把每个环节拆开再把环节之间的衔接关系补上——每一个环节都可以往深处追问每一个追问都会牵出下一章的知识点。这份复习笔记适合正在系统梳理网络基础、准备面试或者想把HTTP和TCP重新理清的人第2章先从这条链路的起点讲起域名是怎么变成IP的。2. DNS与URL解析从域名到IP的完整寻址链路2.1 DNS是什么为什么分布式是必然选择DNSDomain Name System的作用一句话就能说清把域名比如 www.example.com翻译成IP地址比如 203.0.113.10。网络设备之间通信靠的是IP但数字不方便人记忆所以用域名替代。这里最容易被一笔带过的问题是为什么DNS一定要设计成分布式的如果采用一台集中的DNS服务器来扛所有查询会出现四个问题。单点故障这一台DNS服务器一旦崩溃整个网络跟着瘫痪通信容量所有设备的查询请求都打向一台服务器上百万上千万级别的请求量根本扛不住远距离时延集中式服务器不可能同时邻近所有用户跨地域查询会经过低速拥堵链路产生严重延迟维护成本域名映射需要频繁更新集中式维护的代价极大。这四个问题决定了DNS必须采用层级化、分布式的结构。梳理下来会发现面试时如果只背“DNS是域名转IP的系统”是不够的追问一句“为什么不用集中式”就会暴露理解深度。把这四个问题记住本质上也就理解了整个DNS设计的前提。2.2 域名层级与完整解析过程域名的层级关系用句点分隔越靠右的位置层级越高。例如 www.example.com 中com 是顶级域example 是二级域www 是主机名。这个层级关系对应着DNS服务器的查询路径根DNS服务器 → 顶级域DNS服务器 → 权威DNS服务器。完整解析过程可以拆成八步按“从近到远”的顺序记忆查询浏览器缓存看是否有该域名对应的IP浏览器缓存没有查本机 Hosts 文件Hosts 也没有向本地DNS服务器通常由网络运营商提供发查询请求本地DNS有缓存就直接返回没有缓存就向根DNS服务器发查询根DNS服务器不负责解析只告诉本地DNS该去哪个顶级域.com / .net / .org继续查顶级域DNS服务器也不直接返回IP而是告诉本地DNS去哪个权威DNS服务器本地DNS向权威DNS服务器发起查询拿到真正的域名-IP映射本地DNS把IP返回给浏览器并在本地缓存一份下次访问更快。实际开发中最容易忽略的是第2步Hosts文件。联调环境、本地改域名指向都靠它但很多人排查DNS问题的时候把它忘了。Windows在 C:\Windows\System32\drivers\etc\hostsLinux/macOS在 /etc/hosts这个文件可以手动指定域名对应的IP配置后优先于DNS解析生效。# /etc/hosts 示例 127.0.0.1 localhost 203.0.113.10 api.example.com排查“为什么域名解析不对”时先看Hosts文件有没有被改过这是成本最低的一步。整个解析过程本身不难背难的是每一步的触发条件缓存、Hosts、本地DNS、根、顶级、权威这个顺序不能乱漏掉Hosts是常见错误。2.3 递归查询与迭代查询两种查询模式的本质区别递归查询和迭代查询是DNS解析中容易混淆的一对概念。区别不在于“问了几次”而在于“谁帮你查完”。递归查询中DNS客户端向某个DNS服务器发一个查询请求要求对方直接给出完整解析结果。收到请求的服务器会自行逐级查询下一级服务器拿到最终结果后返回给客户端。客户端全程只发一次请求、等一次结果。迭代查询中DNS客户端向某一层DNS服务器查询时对方不直接给最终结果而是返回“下一站该找谁”的地址客户端再自己去查下一站一层层迭代下去直到拿到完整结果。对比项递归查询迭代查询谁来完成后续查询上层DNS服务器代劳客户端自己逐级查询客户端请求次数1次多次返回内容最终IP地址下一级服务器地址典型场景普通用户向本地DNS发起DNS服务器之间的逐级指引一个容易踩坑的地方回答“DNS解析过程”时用户到本地DNS这一段是递归查询本地DNS到根、顶级、权威这一段是迭代查询。面试官如果追问“本地DNS到底怎么工作”能区分出这两个模式就不会乱。面向用户的是递归服务器之间是迭代。3. TCP连接管理三次握手与四次挥手的核心考点3.1 三次握手建立可靠连接的最小代价TCP连接建立的三次握手是计算机网络面试中重复率最高的内容没有之一。流程本身不难记客户端先发SYN序列号设为x服务器收到后回复SYNACK自己的序列号设为y确认号为x1客户端再回一个ACK确认号为y1。但为什么必须是三次不是两次、四次这是区分“背过”和“理解”的分水岭。核心原因是三次握手能让双方都确认“自己的发送能力”和“对方的接收能力”是正常的。第一次握手后服务器确认客户端的发送能力正常第二次握手后客户端确认自己的发送和接收都正常、服务器的发送和接收也正常第三次握手后服务器确认客户端的接收能力正常。两次握手无法让服务器确认客户端的接收能力而四次握手是冗余的——第三次客户端确认完双方能力后连接就可以建立了。另一个高频追问是“第一次握手丢失会发生什么”。客户端发出SYN后启动重传定时器超时未收到SYNACK就会重传SYN。重传次数由系统参数控制超过最大重传次数后放弃连接此时客户端会报连接超时。这里要顺带记住第二次握手丢失也一样——客户端收不到SYNACK会重传SYN服务器收到重复的SYN会重新回复SYNACK。前两次握手丢包都是客户端侧重传不会有数据丢失风险。关于“三次握手过程中可以携带数据吗”标准回答是前两次握手不能携带数据第三次可以。原因在于前两次握手中服务器还没有确认客户端的接收能力此时携带数据可能造成数据在不可靠的连接上被发送第三次握手时客户端已经确认双方收发能力正常可以捎带数据能减少一次RTT的开销。3.2 四次挥手为什么断开比建立更复杂断开连接的流程比建立连接多一次因为TCP连接是全双工的两个方向必须分别关闭客户端发送FIN表示“我的数据发完了不再发送数据”服务器回复ACK表示“收到你的FIN但我还有数据要发”服务器数据全部发完后也发送FIN表示“我也没数据了”客户端回复ACK双方完全断开。为什么不能合并成三次因为第2步和第3步之间服务器可能还有数据要发送。如果服务器收到FIN后立即回复FINACK那数据就来不及传完。只有等服务器把自己的数据全部发完才能发FIN。这个“等待数据发完”的时间就是第2、3步之间必须隔开的原因。四次挥手还有一个隐藏考点TIME_WAIT状态。主动关闭方通常是客户端在发送最后一个ACK后不会立刻关闭连接而是进入TIME_WAIT状态等待2MSL最大报文段生存时间后才真正关闭。原因有两个一是确保最后一个ACK能到达对方如果ACK丢失对方会重发FIN主动方需要能重新响应二是让本连接中所有还在网络中游荡的迟到报文段自然消失避免污染后续使用同一端口的新连接。很多人背了TIME_WAIT这个词但说不清为什么是主动关闭方等待、为什么是2MSL这两点要一起记。3.3 易错边界握手与挥手中的状态与丢包TCP这一块知识不难背但很容易在小细节上翻车。梳理下来发现最高频的易错点集中在几个地方握手是3次、挥手是4次原因是“全双工关闭需要两个方向各完成一次FIN/ACK交换”而不是“多一次更保险”挥手第2步的ACK和第3步的FIN不能合并的前提是服务器还有数据要发如果服务器收到FIN时已经没有数据也完全可以合并为FINACK此时实际是三次挥手建立连接时服务端收到SYN后处于SYN_RCVD状态客户端收到SYNACK后进入ESTABLISHED挥手过程中主动关闭方会经历FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT被动方经历CLOSE_WAIT、LAST_ACK。状态变迁建议自己画一遍面试官经常从状态切入追问。阶段方向报文关键状态第一次握手客户端 → 服务器SYNSYN_SENT / LISTEN第二次握手服务器 → 客户端SYN ACKSYN_RCVD第三次握手客户端 → 服务器ACKESTABLISHED第一次挥手客户端 → 服务器FINFIN_WAIT_1第二次挥手服务器 → 客户端ACKCLOSE_WAIT / FIN_WAIT_2第三次挥手服务器 → 客户端FINLAST_ACK第四次挥手客户端 → 服务器ACKTIME_WAIT提示回答“四次挥手过程”时按表里的顺序讲完报文再补状态名基本就不会被追问卡住。状态名是很多人背诵时漏掉的一环但面试官往往就靠这个区分度判断是否真懂TCP。4. HTTP协议家族从1.0到3.0的演进与性能对比4.1 HTTP基础特性简单、灵活、无状态、明文和不安全HTTP是Web通信的基石。它的特性可以概括为“简单、灵活、易于扩展、应用广泛和跨平台”但面试官通常更想听的是它的问题面无状态、明文传输、不安全。无状态意味着服务器不会主动记住客户端的状态每次请求都是独立的。好处是服务器不用额外资源维护状态坏处是完成有关联性的操作很麻烦。解法是Cookie——在请求和响应报文中写入Cookie信息来控制客户端状态。这个知识点常和Session一起考记住Cookie是放在客户端的状态凭证即可。明文传输带来的是便利和危险并存。便利在于用抓包工具就能直接看到请求内容调试方便危险在于信息透明内容可能被窃听。不安全主要体现在三点通信明文不加密、内容可能被窃听不验证通信方身份、可能遭遇伪装无法证明报文完整性、可能已遭篡改。解法就是HTTPS——在HTTP与TCP之间加一层SSL/TLS安全传输层。回答“HTTP和HTTPS的区别”时就从这三个不安全点出发逐个说SSL/TLS怎么解决比背字段名更有逻辑。另外建议记一下HTTP的三项构建技术HTML作为页面文本标记语言、HTTP作为文档传递协议、URL作为指定文档所在地址这个点很小但“描述一下HTTP”这种开放题里可以用来开局。4.2 HTTP/1.0到HTTP/1.1长连接、管道与队头阻塞HTTP/0.9是最早的版本只支持GET方法、没有请求头、服务器只能返回HTML格式内容现在几乎见不到了。到HTTP/1.0才是第一个正式版本引入了请求头和响应头支持多种请求方法和状态码但不支持持久连接——每次请求都要重新建立TCP连接。这个设计在现代网页场景下性能很差所以HTTP/1.1重点做了两件事长连接和管道网络传输。长连接持久连接解决了反复建连的开销只要客户端和服务器任意一端没有明确提出断开TCP连接就一直保持。管道网络传输则更进一步同一条TCP连接里客户端可以连续发出多个请求不必等第一个响应回来就发第二个。注意这里的关键限制——服务器必须按照接收请求的顺序发送响应。如果前一个请求处理很慢后面所有响应都要排队等这就是响应队头阻塞。HTTP/1.1还遗留了几个问题头部冗余每次请求都重复传输相同的头部字段、没有请求优先级控制、请求只能由客户端发起、服务器只能被动响应。后续HTTP/2基本都是奔着这几个问题去的。这里容易记混的是管道技术理论上解决了请求的队头阻塞但没有解决响应的队头阻塞而且它不是默认开启的浏览器基本都没有支持。回答时不要夸大管道的作用。4.3 HTTP/2头部压缩、二进制帧与Stream并发HTTP/2的改进可以归纳为四点头部压缩、二进制帧、并发传输、服务器推送。HTTP/2基于HTTPS安全性也有保障。这四点在面试中每一点都可以深挖。头部压缩用的是HPACK算法包含三个组成部分静态字典、动态字典、Huffman编码。静态表是HTTP/2框架内置的61组高频头部字段和字符串编码时用短索引号代替完整字符串动态表则依赖同一连接上重复传输完全相同的头部配合Huffman编码进一步压缩。一个容易忽略的细节动态表越大占内存越多Web服务器会提供类似 http2_max_requests 的配置来限制一个连接上能传输的请求数达到上限后关闭连接以释放内存。# Web服务器 HTTP/2 连接请求数限制示例 http2_max_requests 10000;这个配置控制单条HTTP/2连接上允许传输的最大请求数超过后连接会被关闭新请求走新连接。压测或调优时如果看到连接频繁建立可以检查这个值。二进制帧是HTTP/2把文本格式改成二进制格式传输极大提高了解析效率。HTTP/2总共定义了10种类型的帧分成数据帧和控制帧两类。每帧包含流标识符Stream ID接收方根据Stream ID从乱序到达的帧里找到属于同一个Stream的帧再有序组装。并发传输依赖Stream概念多条Stream复用同一条TCP连接不同Stream的帧可以乱序发送所以能做到并行交错地发送请求和响应。这里有三个概念要理清一个HTTP消息Message可以由多个帧Frame构成一个帧可以由多个TCP报文构成多个Stream复用在一条TCP连接上用Stream ID区分。HTTP/1.1是“一个事务做完才能做下一个”HTTP/2是“多个Stream同时进行”这就是吞吐量提升的核心。此外HTTP/2还有流控制、流状态、依赖关系等机制面试中先讲清Stream、Message、Frame三者的关系就够用了。服务器推送是另一个亮点客户端请求HTML时服务器可以主动把CSS、JS等资源直接推给客户端减少消息往返次数。它和WebSocket没有关系是HTTP/2同一条连接上的主动推送。但要注意HTTP/2并没有消灭队头阻塞——它解决的是HTTP层的队头阻塞TCP层的队头阻塞还在。TCP是字节流协议必须保证字节数据完整且连续内核才会把缓冲区的数据交给应用层。如果前1个字节没到后面收到的字节只能在内核缓冲区等着。所以HTTP/2基于TCP就注定逃不掉这个限制这直接催生了HTTP/3。4.4 HTTP/3为什么最终把TCP换成了UDPHTTP/3的核心决策是把下层的TCP换成基于UDP的QUIC协议。要理解这个选择关键是想清楚TCP队头阻塞的本质TCP按序交付一旦某个包丢失后续已到达的包必须排队等待重传即使这些包本身是完整的。对HTTP/2这种多路复用场景一个Stream丢包会影响同一连接上的所有Stream。改用UDP之后QUIC在用户空间实现了自己的可靠传输、拥塞控制和连接迁移并从根上消除了传输层队头阻塞——每条Stream的数据可以独立交付不需要等前面的数据补上。另外QUIC把握手过程也优化了TLS握手和传输握手可以合并减少了建连延迟。回答“HTTP/3解决了什么”时抓住“传输层队头阻塞”和“连接建立延迟”两个点就够了。这章最后值得做一张版本对比总表复习时只看表就能回忆起差异版本连接模型队头阻塞头部压缩传输层HTTP/1.0短连接高无TCPHTTP/1.1长连接管道响应队头阻塞无TCPHTTP/2多Stream复用传输层队头阻塞HPACKTCPHTTP/3QUIC多路复用基本消除HPACK思路演进UDP5. 易漏与易错计算机网络复习中容易失分的细节5.1 高频但容易答不完整的四个点整理这份笔记的过程中最深的感受是高频题大家都会背但追问一层就分化了。以下四个点是失分重灾区按照“易漏点 → 为什么漏 → 怎么补”的方式整理如下。易漏点1三次握手中第一次和第二次握手不能携带数据第三次可以。为什么漏大部分复习资料只画了三次握手的箭头没有标注数据携带规则有人默认成了“握手的每一步都能发数据”。怎么补用因果逻辑记——前两次握手时服务器还没确认客户端的接收能力此时发送数据没有可靠性保障第三次握手时能力确认完毕可以捎带数据节省一个RTT。易漏点2HTTP/2仍然存在队头阻塞只是从HTTP层转移到了TCP层。为什么漏资料里写“HTTP/2解决了队头阻塞”很多人就理解成彻底解决。怎么补队头阻塞有两个层面HTTP/2解决的是应用层请求级的队头阻塞通过Stream并发但TCP按序交付的机制仍然会导致丢包时后续数据排队。面试时主动区分“应用层队头阻塞”和“传输层队头阻塞”反而能加分。易漏点3DNS解析顺序中Hosts文件排在本地DNS之前很多人排查时跳过它。为什么漏平时开发访问的都是公网域名没有改过Hosts所以对这个步骤无感。怎么补在 /etc/hosts 里加一条域名映射再访问亲身体验一下“优先于DNS”的效果以后排查域名异常时自然想到它。易漏点4HTTP/1.1管道网络传输默认不开启浏览器基本没支持。为什么漏教材按理论讲管道但实际环境中几乎没有启用导致很多人以为它是默认行为。怎么补记一个判断口诀——“管道技术解决了请求队头阻塞没解决响应队头阻塞且默认关闭”。5.2 面试追问中容易翻车的三个场景除了上面四个知识点还有三个场景是面试中常见的翻车点。翻车点1被追问“为什么挥手是四次而不是三次”时回答成“因为TCP更可靠”。正确思路是全双工关闭需要两个方向分别关闭被动关闭方可能在收到FIN后还有数据要发所以ACK和FIN必须分开。但特殊情况也要知道如果被动关闭方收到FIN时已经没有数据要发ACK和FIN可以合并实际会出现“三次挥手”。翻车点2被追问“HTTP和HTTPS的区别”时只答“HTTPS加密了”讲不出加密解决的是哪三个问题。正确的答法是把HTTP的三个不安全点窃听、伪装、篡改逐一列出然后说SSL/TLS分别用什么手段解决——加密解决窃听、证书验证解决伪装、报文完整性校验解决篡改。这三个“解决对应关系”比笼统说“更安全”有说服力得多。翻车点3被追问“在浏览器输入URL后发生了什么”时把顺序讲成“先建立TCP连接再做DNS解析”。正确顺序是解析URL → DNS域名解析 → TCP三次握手 → 发送HTTP请求 → 服务器处理并返回响应 → 浏览器渲染页面 → TCP四次挥手。DNS解析在TCP连接之前因为不知道IP地址就无法建立连接。这道题是一个“引导型”题答题时故意把细节讲得慢一点比如展开DNS的八步解析过程会把面试官引到你最熟悉的区域。5.3 浏览器渲染与HTTP缓存里容易忽略的关联浏览器渲染页面这块很多人只知道“构建DOM树、布局、绘制”容易忽略的是回流重排和重绘的区别以及它们和性能的关系。回流是布局阶段重新计算元素几何属性位置、尺寸重绘是绘制阶段重新画元素外观颜色、阴影。回流一定会触发重绘重绘不一定触发回流。回答“前端性能优化”时减少回流是高频手段常见的做法包括批量修改DOM、避免频繁读取布局属性、使用 transform 代替 top/left 动画等。HTTP缓存这个点高频回答方式是按“是否需要发请求”来分强缓存命中时不发请求直接用本地缓存关键字段是Cache-Control优先级高于Expires和Expires协商缓存命中时发请求但服务器返回304浏览器用本地缓存关键字段是Etag/If-None-Match和Last-Modified/If-Modified-Since。容易忽略的是两条优先级规则Cache-Control和Expires同时存在时Cache-Control优先Etag和Last-Modified同时存在时Etag优先。不用死记用“更精确的验证优先于更粗略的时间验证”来理解就顺了。另一个容易漏的点是304是协商缓存命中的响应状态码但很多人在回答“HTTP状态码有哪些”时只会说200和404忘了304、301、302也是高频考点。6. 复习清单与查漏补缺把计算机网络真正装进脑子6.1 一条URL主线自查清单复习到这个阶段只剩最后一件事把知识从“看懂”变成“能脱口而出”。推荐方法是顺着“输入URL回车”这条主线以节点为单位自查每个节点回答三个问题这一阶段发生了什么、为什么需要这一步、通常会被追问什么。可以照着下面这张表过一遍链路节点必须能答出常见追问URL解析解析出协议、主机、端口、路径URL由哪几部分组成DNS解析八步解析过程、递归vs迭代Hosts在哪查、根DNS的作用TCP三次握手报文类型、状态、为什么三次第一次丢失怎么办、能带数据吗HTTP请求请求方式、状态码GET/POST区别、幂等性服务器响应状态码、响应头字段、Cookie304是怎么产生的浏览器渲染DOM树、CSS布局、回流重绘如何减少回流TCP四次挥手FIN/ACK顺序、TIME_WAIT为什么四次、为什么2MSL这张表的前两列是及格线第三列是区分度。能不看资料把第三列的追问也答完这个节点才算真的过了。这份笔记的知识点分布本质上就是在回答这张表的第三列。6.2 查漏补缺的三步法具体操作上建议用“三日反向抽查法”。第一天按表格正向过一遍把卡壳的区域标记出来第二天从底部“四次挥手”反向过到顶部“URL解析”打乱顺序防止顺着背形成路径依赖第三天只复习标记过的区域并且用“自己追问自己”的方式补出原因层逻辑而不是只背结论。说一个我自己的教训有一阵子我按顺序背得很顺从URL一路讲到四次挥手但面试官从“第三次握手能不能带数据”切入就卡住了——因为我的记忆是顺着链路走的没有在每个节点上建立“追问分支”。从那以后我每次复习都强制走一遍“原因层追问”把每个易漏点当作独立问题来回答而不是当成链路中的一环。这个方法帮我避开了很多复习盲区希望帮到你。本文还有配套的精品资源点击获取