简介：面向技术面试准备的计算机基础知识点 PDF 文档，重点覆盖计算机网络中的高频考点，与“代码随想录知识星球”最强八股文系列的计算机基础篇对应，适合后端、前端开发者跳槽或校招前集中复习。内容系统梳理了TCP三次握手与四次挥手、HTTP与HTTPS的区别、DNS域名解析流程、HTTP缓存机制，以及浏览器输入URL后的完整工作流程；其中DNS部分区分了浏览器缓存、Hosts文件、本地DNS服务器、根服务器逐级查询，并对比递归查询与迭代查询，HTTP缓存部分则拆分强缓存与协商缓存的判定方式。每个知识点均配有分步拆解、图解说明和面试回答要点，便于背诵与查漏补缺。资源包共1个PDF文件，整体约37.83MB，PDF内直接按章节阅读，无需拆分；目前已有777人学习使用，对想深入理解网络底层原理、提升面试表达能力的求职者来说，是一份高性价比的复习素材。
1. 计算机基础面试的考点版图：从“输入URL后发生了什么”串起全部高频题
计算机网络面试题有个规律，看起来零散，其实都挂在一根主线上。考官从“输入URL后回车发生了什么”开局，下一步大概率就顺着DNS解析、TCP三次握手、HTTP缓存、HTTPS、页面渲染一路追问下去。这道连环题的答法，直接决定你在面试官眼里是“背了八股”还是“真有网络体系”。这份计算机基础八股文PDF把计算机网络面试内容分成两套结构：高频重点区负责把常考题目讲透，一问一答区补充零碎考点；同系列的九份PDF里，本篇正是计算机基础篇，适合后端、前端岗位的候选人考前冲刺，也适合把零散网络知识整理成体系。拿分的关键不是多背题，而是把每个高频题答出层次——先给结论、再讲过程、最后留一个能引导追问的口子。
2. 高频考点：三次握手与四次挥手的完整链路与状态机追问
TCP连接管理是计算机网络面试的第一梯队考点。三次握手和四次挥手不但必考，而且几乎必然伴随追问：为什么是三次不是两次、第一次握手丢了怎么办、哪位角色进入TIME_WAIT。要拿稳这部分分数，不能只背流程，要把状态迁移、丢包场景、异常排查全部串起来。
2.1 三次握手的标准流程：从SYN到ESTABLISHED的状态迁移
三次握手的目的不是“建立连接”这四个字，而是同步双方的初始序列号，并确认彼此的收发能力。标准流程按报文走：
第一次，客户端发送SYN报文，初始序列号seq=x，客户端状态从CLOSED变为SYN_SENT，服务器保持LISTEN监听状态。第二次，服务器收到SYN后，回复SYN+ACK报文，携带自己的初始序列号seq=y和确认号ack=x+1，服务器进入SYN_RCVD状态；客户端收到后确认“服务器能收能发”，在发出第三次握手前已经进入ESTABLISHED。第三次，客户端回复ACK报文，确认号ack=y+1，服务器收到后从SYN_RCVD变为ESTABLISHED。
三个状态变化建议背成一条线：客户端CLOSED→SYN_SENT→ESTABLISHED，服务器LISTEN→SYN_RCVD→ESTABLISHED。面试官经常在答完流程后追问“此时客户端处于什么状态”，很多考生只背了报文名称没背状态，当场卡住。状态迁移是判断你是否真正理解握手过程的第一道分水岭。
接着是必问的“为什么是三次，不是两次也不是四次”。这类题按“结论+两点理由”答：三次握手的核心目的是确认双方收发能力正常，同时防止失效的历史连接请求突然到达服务器而建立错误连接。第一次握手证明客户端的发送能力和服务器的接收能力；第二次握手证明服务器的发送能力和客户端的接收能力，让客户端知道自己发的SYN被真正收到；第三次握手是让服务器确认“客户端也收到了我的SYN+ACK”。如果只用两次握手，服务器无法区分当前请求是正常连接还是很久以前在网络中滞留的失效SYN，一旦失效报文到达，服务器会误以为是新连接请求，白白建立一条没人用的连接并分配资源。
2.2 四次挥手与TIME_WAIT：被追问最多的连接断开细节
四次挥手同样按报文推进。客户端先发送FIN报文，表示“我这边数据发完了”，进入FIN_WAIT_1状态；服务器收到后回复ACK，进入CLOSE_WAIT状态，客户端收到ACK后进入FIN_WAIT_2。服务器此时可能还有数据没发完，等应用层把剩余数据处理完，服务器再发送FIN，进入LAST_ACK状态；客户端收到FIN后回复最后一个ACK，进入TIME_WAIT状态，等待2MSL之后彻底关闭。服务器收到这个ACK后直接关闭连接。
为什么是四次而不是三次？因为TCP是全双工通信，两个方向的关闭必须独立完成。客户端发送FIN，只代表“客户端不再向服务器发送数据”，但服务器仍然可以向客户端发送数据，所以服务器不能把ACK和FIN合并成一次，必须先回ACK确认收到关闭请求，等自己的数据全部发完再单独发FIN。两个方向的关闭动作天然无法合并且必须按序进行，所以需要四步。
TIME_WAIT等待2MSL最常被追问。它有两个作用：第一，保证主动关闭方发出的最后一个ACK能送到对方。如果这个ACK在网络中丢失，被动关闭方会因为收不到确认而重发FIN，主动关闭方处于TIME_WAIT期间还可以再补一次ACK，确保对方正常关闭。第二，让本连接中还在网络中滞留的旧报文自然消失，避免端口被复用后旧数据干扰新连接。记一个锚点就够：“等别人把告别信收好，也等旧消息在网络上散场。”
2.3 真题演练：丢包、携带数据、连接异常，三类追问怎么答
真题一：第一次握手丢失了会发生什么？这类题考的是可靠传输机制。客户端发出SYN后，在超时时间内没有收到服务器的SYN+ACK，就会触发超时重传，重新发送SYN。重传间隔通常指数退避，从1秒左右开始逐次翻倍，达到操作系统配置的最大重传次数后放弃连接，报错提示“连接超时”。关键要说出：TCP的重传机制保证了SYN最终要么被可靠送达，要么在失败后及时宣告失败，而不是无限等待。
真题二：三次握手过程中可以携带数据吗？第一、二次握手不能携带数据，第三次可以。原因要答两层：第一，连接尚未建立时如果允许携带数据，攻击者可以在SYN报文中夹带大量数据，服务器在未完成连接建立时就得为这些数据分配缓存并处理，这会放大SYN Flood等攻击的危害；第二，第三次握手时客户端已经确认服务器收发能力正常，连接具备可靠性基础，数据随ACK一起发送不会增加额外往返时间，是安全的。
真题三：线上出现大量TIME_WAIT或CLOSE_WAIT怎么排查？这类题把协议知识和工程经验放在一起考。先分角色再定方案：TIME_WAIT属于主动关闭方，大量出现通常是因为短连接创建太频繁，常见于高并发HTTP请求场景，可以从连接复用、调整TIME_WAIT回收参数入手。CLOSE_WAIT属于被动关闭方，如果服务端大量堆积CLOSE_WAIT，几乎可以断定应用层没有调用close()，出现了socket泄漏，调任何TIME_WAIT参数都没用。答题时先说出状态归属，再说排查方向，才是面试官想听到的工程判断力。
3. 高频考点：DNS解析、HTTP缓存与版本演变的答题素材
离开TCP连接管理，下一组高频考点集中在DNS、HTTP缓存和HTTP版本演进。这三块内容的特点是记忆点多、彼此独立，但面试题一旦追深，很容易暴露“只背了名词”的弱点。下面把三个模块的答题素材按可背、可复述的方式整理出来。
3.1 DNS解析全流程：缓存层级、递归与迭代怎么讲不丢分
DNS这题要答出的深度是：从“为什么不能集中式设计”到“解析过程中每一级谁在回答”，再到“递归和迭代到底是谁对谁”。先答为什么采用分布式：集中式设计有四个致命问题——单点故障，一台DNS服务器挂掉整个网络瘫痪；通信容量，所有查询都由一台机器扛不现实，可能的并发量是千万级；远距离时延，集中式服务器不可能邻近所有用户，跨区域的查询会经过低速链路导致严重延迟；维护困难，域名记录频繁变化，集中式数据库更新成本巨大。
接着答域名层级关系。域名用句点分隔，越靠右层级越高，比如www.server.com中com是顶级域，server.com是二级域，www是主机名。解析过程本质上是“逐级向下找人要答案”。
完整解析流程按8步记忆：第一步查浏览器缓存；第二步查本地Hosts文件；第三步向本地DNS服务器查询，本地DNS通常由运营商提供；第四步如果本地DNS没有缓存，它向根DNS服务器发出查询；第五步根DNS不负责具体域名解析，它告诉本地DNS该去找哪个顶级域服务器，比如.com对应的顶级域DNS；第六步本地DNS向顶级域DNS查询，顶级域DNS同样不直接返回IP，而是告诉它该找哪个权威DNS服务器；第七步本地DNS向权威DNS查询，权威DNS存储着域名和IP的真实映射，返回最终IP地址；第八步本地DNS把IP返回给浏览器，并将解析结果缓存到本地，方便下次访问快速响应。
递归和迭代的区别是追问重点。一句话锚住：客户端与本地DNS服务器之间是递归查询，本地DNS与根、顶级域、权威DNS之间是迭代查询。递归查询的特点是DNS客户端只发一个请求，然后等待完整结果，本地DNS负责替客户端逐级问到底；迭代查询的特点是客户端向每一级服务器只询问“下一步该找谁”，拿着新地址自己再查，不要求直接返回完整解析结果。补充一句“递归查询适合普通用户和客户端，迭代查询适合DNS服务器之间的通信”就完整了。
3.2 HTTP缓存：强缓存与协商缓存的判断顺序与应答模板
HTTP缓存的高频程度不亚于三次握手，而且更容易失分。很多候选人知道Cache-Control和ETag，但说不清两者的触发顺序，一旦面试官画一条时间线问“浏览器到底发没发请求”就露馅。
先把两条缓存线分清楚。强缓存由Cache-Control和Expires控制，命中时浏览器不会发起请求，直接从本地副本读取资源。Cache-Control里的max-age是相对时间，Expires是绝对时间，两者都出现时Cache-Control优先级更高，因为Expires依赖客户端本地时钟，用户改时间就会判断失效。协商缓存由ETag/If-None-Match和Last-Modified/If-Modified-Since控制，强缓存失效后，浏览器会带着验证字段重新请求服务器，服务器比较后返回304表示资源未变、可以继续用缓存，返回200表示资源已更新、需要下载新内容。
判断顺序是这题的核心得分点：先强缓存后协商缓存。强缓存还有效时，请求根本不会发出去；只有强缓存失效，才会带着If-None-Match或If-Modified-Since发请求做协商验证。答题模板可以固定成三步：第一步，看响应头Cache-Control的max-age，在有效期内直接用缓存，不发请求；第二步，max-age过期后，带上If-None-Match、If-Modified-Since重新请求服务器；第三步，服务器返回304就继续用缓存并刷新有效期，返回200就替换资源并更新缓存。最后补一句经验：ETag比Last-Modified更可靠，因为Last-Modified粒度是秒，同一秒内文件被修改多次时它判断不出来，ETag用内容标识能做到精确比较。
3.3 HTTP版本演变：从1.1到3.0，一条演进线串起来
HTTP版本题不要按版本号死背，按“每个版本解决了什么、还留下什么问题”的演进逻辑来答，面试官会顺着你的节奏走。
| 版本 | 引入机制 | 核心解决 | 仍然存在的问题 | | HTTP/1.1 | 长连接、管道传输 | 避免每次请求都新建TCP连接 | 响应队头阻塞、头部冗余 | | HTTP/2 | 二进制帧、Stream并发、HPACK压缩、服务器推送 | 解决HTTP层队头阻塞、降低头部开销 | 传输层TCP队头阻塞仍在 | | HTTP/3 | 基于UDP的QUIC | 解决TCP层队头阻塞、降低握手时延 | 生态与部署仍在演进 |
HTTP/1.1的标志性机制是长连接和管道机制。长连接让TCP连接可以复用，不需要每个请求都重新握手；管道机制允许客户端在同一个连接里连续发出多个请求，不必等第一个响应回来才发第二个。但HTTP/1.1的队头阻塞并未被真正解决：服务器必须按请求到达的先后顺序返回响应，如果第一个请求处理很慢，后面所有响应都排队等待。每次请求都携带重复头部字段，也是一种带宽浪费。
HTTP/2在四个方向上做改进。头部压缩使用HPACK算法，静态表存放高频出现的基础头部字段，动态表记录同一连接内重复出现的完整头部，再叠加Huffman编码，把重复字段用短索引代替。二进制帧把数据拆成头信息帧和数据帧，用位运算高效解析。并发传输引入Stream概念，多个Stream复用一条TCP连接，每个请求用唯一Stream ID区分，不同Stream的帧可以乱序发送，接收端靠Stream ID重新组装，因此HTTP/2能并行交错地收发请求与响应。服务器推送允许服务器对客户端的一个请求额外推送CSS等资源，省去客户端再次请求的往返。但HTTP/2的队头阻塞只是从应用层转移到了传输层。
HTTP/3把底层TCP换成了基于UDP的QUIC，在UDP之上自己实现可靠传输和流级并发，丢包时只影响单个流，不会再让HTTP层拿不到数据。答到这里时，主动说明“HTTP/2的队头阻塞在TCP，HTTP/3换UDP换的正是这条病根”，整个版本演进逻辑就闭环了。
3.4 真题演练：URL全流程的追问链与状态码扩展
“输入URL并回车后发生了什么”是计算机基础面试的题眼，几乎所有网络考点都挂在这条主线上。标准七步：URL解析、DNS解析、TCP三次握手、发送HTTP/HTTPS请求、服务器返回响应、浏览器渲染页面、断开TCP连接。每一步都可以延伸出可追问的内容。
| 步骤 | 关键内容 | 可延伸的追问 | | URL解析 | 拆出协议、主机、端口、路径，检查HTTP缓存 | 强缓存与协商缓存的判断顺序 | | DNS解析 | 浏览器缓存→Hosts→本地DNS→逐级查到权威DNS | 递归与迭代的区别 | | TCP三次握手 | 同步序列号、确认收发能力 | 为什么是三次、第一次丢包怎么办 | | 发送HTTP/HTTPS请求 | 请求方法、状态码、TLS握手 | GET与POST的区别、HTTPS如何加密 | | 服务器返回响应 | 状态码、缓存策略、Set-Cookie | 304代表什么、重定向怎么处理 | | 浏览器渲染 | 构建DOM树、CSSOM树、合成渲染树、布局、绘制 | 回流与重绘的区别 | | 断开连接 | HTTP/1.1长连接下未必立即断开 | 四次挥手、TIME_WAIT |
扩展两个必背细节。第一是状态码：2xx代表成功，200最常用；3xx代表重定向与缓存，301永久重定向、302临时重定向、304协商缓存未修改；4xx代表客户端错误，400请求语法错误、401未认证、403无权限、404资源不存在；5xx代表服务器错误，500内部错误、502网关错误、503服务不可用。回答时不需要背全，把301、302、304、404、500这五个高频状态码说准就行。
第二是GET与POST的区别。GET侧重获取资源，参数拼在URL上，容易被缓存并保留在浏览器历史里；POST侧重提交数据，参数放在请求体中，不会被缓存。语义上GET是幂等操作，POST不保证幂等。曾经有面试官考“POST能不能被缓存”，答案是可以，但大多数实现不会缓存，要区分语义层面和实现层面。对前端候选人，第六步是送分点：DOM树和CSSOM树合成渲染树，再计算布局并绘制；改变元素几何属性触发回流，只改变颜色等视觉属性触发重绘。说出“回流一定引起重绘，重绘不一定引起回流”这句，这道题基本就稳了。
4. 易错点与失分陷阱：计算机网络面试中五个高频翻车点
这章专门整理那些“明明会，却说错”的瞬间。以下五个点是我在大量面试复盘里反复见到的失分位置，每一条都按“错在哪、为什么错、怎么答对”拆开，考前值得单独过一遍。
4.1 把CLOSE_WAIT和TIME_WAIT的归属方记反
错在哪：一看到TIME_WAIT就说是服务端问题，一看到CLOSE_WAIT堆积就说要调TIME_WAIT参数。
为什么错：没有想清楚TIME_WAIT只属于主动断开方。四次挥手中谁先发FIN，谁最后进入TIME_WAIT；被动关闭方收到FIN后回复ACK，进入的是CLOSE_WAIT，它不是TIME_WAIT。实际工程里服务端大量出现CLOSE_WAIT，几乎都是应用层代码没有调用close()导致连接泄漏，调任何TIME_WAIT回收参数都没有用。
怎么答对：先说出状态归属，主动关闭方进入TIME_WAIT，被动关闭方进入CLOSE_WAIT。再给排查方向，TIME_WAIT过多看连接创建释放频率，考虑连接复用和回收参数；CLOSE_WAIT过多则直接检查应用层为什么没关闭socket。这个回答把协议状态和工程排查串在一起，远比报一个结论得分高。
4.2 误答“HTTP/2彻底解决了队头阻塞”
错在哪：把HTTP/2的多路复用等同于完全没有队头阻塞。
为什么错：HTTP/2解决的是应用层HTTP的队头阻塞，底层依然是TCP。TCP是字节流协议，内核必须保证字节流按序完整地向应用层呈现，一旦某个数据段丢失触发重传，后面已经到达的数据也只能待在缓冲区里等待。HTTP/2应用层拿不到缺失的那一段，也就无法处理后续消息，这就是传输层的队头阻塞。
怎么答对：把答案拆成两段。先说应用层，Stream机制让不同请求的帧交错传输，响应不再排队；再说传输层，TCP的字节流有序约束还在，丢包仍然会让后续数据卡在内核缓冲区；最后补一句，HTTP/3把TCP换成基于UDP的QUIC，在流级别解决丢包影响，才是根治。能答出这三层，面试官会认为你理解链路而不只是背特性清单。
4.3 缓存判断顺序颠倒：先协商后强缓存
错在哪：答成“强缓存失效后直接下载新资源”或者“先协商缓存，再强缓存”，把判断次序搞反。
为什么错：强缓存和协商缓存的触发时机不同，强缓存有效期内浏览器根本不发出网络请求，不存在“先走协商”的过程；只有强缓存失效后，浏览器才带着If-None-Match、If-Modified-Since这类验证字段发起协商请求。顺序反了，整个HTTP缓存逻辑就全乱了。
怎么答对：像背口令一样记住三步，先看Cache-Control的max-age是否有效，有效就直接用缓存；失效后带条件字段请求服务器做协商验证；服务器返回304就继续用缓存，返回200就换新资源。补一句“Cache-Control优先级高于Expires，ETag优先级高于Last-Modified”，把两个优先级都点破，这道题就答圆了。
4.4 DNS递归与迭代的职责边界答反
错在哪：回答“根域名服务器做递归查询，本地DNS做迭代查询”，把角色归属完全说反。
为什么错：递归和迭代描述的不是服务器类型，而是查询责任在哪一方。客户端向本地DNS发起的是一次递归查询：客户端把完整解析任务交给本地DNS，自己只等最终结果。本地DNS向根DNS、顶级域DNS、权威DNS发起的才是迭代查询：每一级只返回“下一步该找谁”，不直接给出最终IP。
怎么答对：先用一句话锚定角色：“客户端与本地DNS之间是递归，本地DNS与各级域名服务器之间是迭代。”再补充一句“根DNS和顶级域DNS并不负责把域名解析成具体IP，它们只负责指引下一步去哪查”。这两句到位，追问就追不下去了。
4.5 URL主线答不全：吞掉缓存判断和渲染细节
错在哪：从“解析URL”直接跳到“TCP三次握手”，把HTTP缓存判断这步省略；渲染阶段只说“浏览器把页面画出来”，说不出DOM树、CSSOM树、回流和重绘。
为什么错：这条主线是按浏览器的真实工作顺序设计的，不是考试专用流程。记忆被压缩成“连接、传输、断开”三层，自然会丢掉缓存判断和渲染这两个最容易出追问的环节，而这些位置恰恰是面试官区分前端和后端考察重点的地方。
怎么答对：按七步走并记住每步的关键词：解析URL时顺便判断HTTP缓存，DNS解析出IP，TCP三次握手，发送HTTP/HTTPS请求，服务器返回响应与状态码，浏览器渲染页面，最后再谈断开连接。讲到自己熟悉的节点时放慢节奏，主动展开细节。比如讲到第六步就把构建DOM树、构建CSSOM树、合成渲染树、布局、绘制这五步讲完，并引出回流和重绘这对概念，把考官的追问圈定在你准备好的范围内。
5. 答题节奏与押题思路：把八股背成面试官想听的结构化答案
面试答题不是背诵比赛，一套通用的节奏比背得多更有用。我习惯用“结论、过程、扩展”三层结构处理所有网络八股题。
结论层先给一句话定性。被问“三次握手为什么是三次”，第一句就答“为了确认双方收发能力正常，同时防止失效的历史连接请求建立错误连接”。这句话说完，面试官已经知道你有理解，而不是在背步骤。过程层按时间线或状态机展开，一次只讲一个层次，讲完一个状态停一下，观察面试官是否继续追问。扩展层在收尾时主动抛一个口子，比如答完HTTP缓存后补一句“这里还涉及Cache-Control和Expires的优先级问题”，把话题引向你有准备的区域，让追问落在你的射程内。
押题优先级也要分清主次。第一梯队是三次握手与四次挥手、DNS完整解析、HTTP缓存判断、HTTP与HTTPS区别、状态码与GET/POST区别；第二梯队是TCP与UDP区别、HTTP版本演变、URL全流程、回源与重绘。时间不够时，优先把第一梯队按“结论、过程、扩展”各练一遍，比盲目刷几十道题有效。
我后来每次备考都保留一个习惯：拿“输入URL后发生了什么”当主线，把每个考点挂在对应步骤上，任选一个节点往深钻一步，答不上来就翻资料重新记一遍。练熟之后，不管面试官从哪个点切入，都能顺着主线绕回自己熟悉的区域。这个办法帮我稳住了好几次面试的节奏和心态，希望帮到你。
本文还有配套的精品资源，点击获取
