简介：面向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是什么：为什么分布式是必然选择
DNS（Domain 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\hosts，Linux/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）；服务器收到后回复SYN+ACK（自己的序列号设为y，确认号为x+1）；客户端再回一个ACK（确认号为y+1）。但为什么必须是三次，不是两次、四次？这是区分“背过”和“理解”的分水岭。
核心原因是：三次握手能让双方都确认“自己的发送能力”和“对方的接收能力”是正常的。第一次握手后，服务器确认客户端的发送能力正常；第二次握手后，客户端确认自己的发送和接收都正常、服务器的发送和接收也正常；第三次握手后，服务器确认客户端的接收能力正常。两次握手无法让服务器确认客户端的接收能力，而四次握手是冗余的——第三次客户端确认完双方能力后，连接就可以建立了。
另一个高频追问是“第一次握手丢失会发生什么”。客户端发出SYN后启动重传定时器，超时未收到SYN+ACK就会重传SYN。重传次数由系统参数控制，超过最大重传次数后放弃连接，此时客户端会报连接超时。这里要顺带记住：第二次握手丢失也一样——客户端收不到SYN+ACK会重传SYN，服务器收到重复的SYN会重新回复SYN+ACK。前两次握手丢包都是客户端侧重传，不会有数据丢失风险。
关于“三次握手过程中可以携带数据吗”，标准回答是：前两次握手不能携带数据，第三次可以。原因在于前两次握手中，服务器还没有确认客户端的接收能力，此时携带数据可能造成数据在不可靠的连接上被发送；第三次握手时客户端已经确认双方收发能力正常，可以捎带数据，能减少一次RTT的开销。
3.2 四次挥手：为什么断开比建立更复杂
断开连接的流程比建立连接多一次，因为TCP连接是全双工的，两个方向必须分别关闭：客户端发送FIN，表示“我的数据发完了，不再发送数据”；服务器回复ACK，表示“收到你的FIN，但我还有数据要发”；服务器数据全部发完后，也发送FIN，表示“我也没数据了”；客户端回复ACK，双方完全断开。
为什么不能合并成三次？因为第2步和第3步之间，服务器可能还有数据要发送。如果服务器收到FIN后立即回复FIN+ACK，那数据就来不及传完。只有等服务器把自己的数据全部发完，才能发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时已经没有数据，也完全可以合并为FIN+ACK，此时实际是三次挥手；
- 建立连接时服务端收到SYN后处于SYN_RCVD状态，客户端收到SYN+ACK后进入ESTABLISHED；挥手过程中主动关闭方会经历FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT，被动方经历CLOSE_WAIT、LAST_ACK。状态变迁建议自己画一遍，面试官经常从状态切入追问。
| 阶段 | 方向 | 报文 | 关键状态 |
|---|---|---|---|
| 第一次握手 | 客户端 → 服务器 | SYN | SYN_SENT / LISTEN |
| 第二次握手 | 服务器 → 客户端 | SYN + ACK | SYN_RCVD |
| 第三次握手 | 客户端 → 服务器 | ACK | ESTABLISHED |
| 第一次挥手 | 客户端 → 服务器 | FIN | FIN_WAIT_1 |
| 第二次挥手 | 服务器 → 客户端 | ACK | CLOSE_WAIT / FIN_WAIT_2 |
| 第三次挥手 | 服务器 → 客户端 | FIN | LAST_ACK |
| 第四次挥手 | 客户端 → 服务器 | ACK | TIME_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换成了UDP
HTTP/3的核心决策是把下层的TCP换成基于UDP的QUIC协议。要理解这个选择，关键是想清楚TCP队头阻塞的本质：TCP按序交付，一旦某个包丢失，后续已到达的包必须排队等待重传，即使这些包本身是完整的。对HTTP/2这种多路复用场景，一个Stream丢包会影响同一连接上的所有Stream。
改用UDP之后，QUIC在用户空间实现了自己的可靠传输、拥塞控制和连接迁移，并从根上消除了传输层队头阻塞——每条Stream的数据可以独立交付，不需要等前面的数据补上。另外QUIC把握手过程也优化了：TLS握手和传输握手可以合并，减少了建连延迟。回答“HTTP/3解决了什么”时，抓住“传输层队头阻塞”和“连接建立延迟”两个点就够了。这章最后值得做一张版本对比总表，复习时只看表就能回忆起差异：
| 版本 | 连接模型 | 队头阻塞 | 头部压缩 | 传输层 |
|---|---|---|---|---|
| HTTP/1.0 | 短连接 | 高 | 无 | TCP |
| HTTP/1.1 | 长连接+管道 | 响应队头阻塞 | 无 | TCP |
| HTTP/2 | 多Stream复用 | 传输层队头阻塞 | HPACK | TCP |
| HTTP/3 | QUIC多路复用 | 基本消除 | HPACK思路演进 | UDP |
5. 易漏与易错：计算机网络复习中容易失分的细节
5.1 高频但容易答不完整的四个点
整理这份笔记的过程中，最深的感受是：高频题大家都会背，但追问一层就分化了。以下四个点是失分重灾区，按照“易漏点 → 为什么漏 → 怎么补”的方式整理如下。
易漏点1：三次握手中，第一次和第二次握手不能携带数据，第三次可以。为什么漏：大部分复习资料只画了三次握手的箭头，没有标注数据携带规则，有人默认成了“握手的每一步都能发数据”。怎么补：用因果逻辑记——前两次握手时，服务器还没确认客户端的接收能力，此时发送数据没有可靠性保障；第三次握手时能力确认完毕，可以捎带数据节省一个RTT。
易漏点2：HTTP/2仍然存在队头阻塞，只是从HTTP层转移到了TCP层。为什么漏：资料里写“HTTP/2解决了队头阻塞”，很多人就理解成彻底解决。怎么补：队头阻塞有两个层面，HTTP/2解决的是应用层请求级的队头阻塞（通过Stream并发），但TCP按序交付的机制仍然会导致丢包时后续数据排队。面试时主动区分“应用层队头阻塞”和“传输层队头阻塞”，反而能加分。
易漏点3：DNS解析顺序中Hosts文件排在本地DNS之前，很多人排查时跳过它。为什么漏：平时开发访问的都是公网域名，没有改过Hosts，所以对这个步骤无感。怎么补：在 /etc/hosts 里加一条域名映射再访问，亲身体验一下“优先于DNS”的效果，以后排查域名异常时自然想到它。
易漏点4：HTTP/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区别、幂等性 |
| 服务器响应 | 状态码、响应头字段、Cookie | 304是怎么产生的 |
| 浏览器渲染 | DOM树、CSS布局、回流重绘 | 如何减少回流 |
| TCP四次挥手 | FIN/ACK顺序、TIME_WAIT | 为什么四次、为什么2MSL |
这张表的前两列是及格线，第三列是区分度。能不看资料把第三列的追问也答完，这个节点才算真的过了。这份笔记的知识点分布，本质上就是在回答这张表的第三列。
6.2 查漏补缺的三步法
具体操作上，建议用“三日反向抽查法”。第一天按表格正向过一遍，把卡壳的区域标记出来；第二天从底部“四次挥手”反向过到顶部“URL解析”，打乱顺序，防止顺着背形成路径依赖；第三天只复习标记过的区域，并且用“自己追问自己”的方式补出原因层逻辑，而不是只背结论。
说一个我自己的教训：有一阵子我按顺序背得很顺，从URL一路讲到四次挥手，但面试官从“第三次握手能不能带数据”切入就卡住了——因为我的记忆是顺着链路走的，没有在每个节点上建立“追问分支”。从那以后我每次复习都强制走一遍“原因层追问”，把每个易漏点当作独立问题来回答，而不是当成链路中的一环。这个方法帮我避开了很多复习盲区，希望帮到你。
本文还有配套的精品资源，点击获取
