简介《计算机基础》PDF是一份面向程序员求职面试的计算机网络知识点整理内容整合自代码随想录知识星球“最强八股文”第五版计算机基础篇集中讲解TCP三次握手与四次挥手、HTTP/HTTPS区别、HTTP缓存机制、DNS域名解析过程以及浏览器输入URL后的完整工作流程等高频考点。资源为1个PDF文件压缩包大小37.83MB便于离线阅读和反复查阅。目前已吸引777人学习适合正在准备后端/前端开发岗位面试、需要系统梳理计算机网络核心知识的开发者。PDF中不仅给出结论还配有过程拆解与问答式讲解如三次握手为什么不是两次、DNS解析如何逐级查询、递归查询与迭代查询有何区别等能帮助读者快速抓住回答重点建立从输入URL到断开连接的完整知识链路。1. 计算机基础八股文一份能直接背诵的知识地图计算机网络是后端和前端面试都绕不开的硬骨头。梳理这份计算机基础篇最强八股文你会发现它的主线非常清晰以“浏览器输入URL按下回车后发生了什么”为总入口一路串起DNS解析、TCP三次握手、HTTP请求响应、浏览器渲染、TCP四次挥手这五大环节。高频题其实就是这条主线上每个节点的追问比如为什么握手要三次、HTTP各版本改了什么、缓存怎么生效。这份笔记适合两类人系统学习的人可以按这条链路把计算机网络的基础框架一次搭全正在复习的人可以拿它当背诵底稿高频重点区负责把题讲透一问一答区负责补碎知识点。下面按模块把整份笔记的地图和重难点拆开。2. URL回车全流程从输入地址到页面渲染的七个环节2.1 七个环节按顺序串起来“在浏览器中输入URL并按下回车后会发生什么”是一道超高频面试题它的价值在于可以延伸到计算机网络的大部分问题。完整链路分七步URL解析、DNS域名解析、TCP三次握手、发送HTTP/HTTPS请求、服务器处理并返回HTTP报文、浏览器渲染页面、TCP四次挥手断开连接。第一步是URL解析。浏览器会从URL中解析出协议、主机、端口、路径等信息并构造一个HTTP请求。这里有个容易忽略的动作浏览器会根据请求头判断是否有HTTP缓存如果有缓存且未过期就直接用缓存资源不再发请求到服务器。换句话说不是所有回车都会真的产生一次网络请求。第二步是DNS域名解析把域名解析成对应的IP地址。第三步是TCP三次握手建立可靠的传输连接。第四步是发送HTTP或HTTPS请求这一步可以往HTTP与HTTPS的区别、请求方式、状态码等方向展开。第五步是服务器处理请求并返回HTTP报文响应报文中通常包含网页内容、状态码、压缩类型、缓存策略和设置的Cookie。第六步是浏览器渲染页面前端同学会被追问DOM树构建、回流与重绘。第七步是四次挥手断开TCP连接。七个环节把OSI模型的应用层、传输层、网络层都串起来了答好这道题等于向面试官展示了你对整条网络链路的掌握程度还能把话题引导到你更熟悉的方向。2.2 DNS集中式为什么会挂层级化怎么解决DNSDomain Name System的作用是把人类易记的域名比如 www.example.com转换成计算机可识别的IP地址。面试里常问一个反直觉的问题为什么DNS不设计成集中式的单台服务器集中式设计会带来四个致命问题单点故障DNS服务器一崩整个网络跟着瘫通信容量单台服务器要处理上百万甚至上千万级查询根本扛不住远距离延迟一个集中式数据库不可能邻近所有用户远端查询必然经过低速拥堵链路维护成本高域名映射需要频繁更新。所以DNS必须做成分布式层级结构。域名用句点分隔越靠右的位置层级越高。拿 www.example.com 来说com 是顶级域example 是二级域www 是主机名。对应的DNS服务器层级是根DNS服务器、顶级域DNS服务器.com/.net/.org、权威DNS服务器。这里梳理下来会发现一个高频考点根DNS服务器和顶级域DNS服务器都不负责具体域名的解析它们只负责“指路”真正存储域名与IP映射关系的是权威DNS服务器。2.3 递归查询与迭代查询别再把两者搞反DNS解析过程中有两种查询方式递归查询和迭代查询。递归查询的特点是客户端只管发一次请求然后等完整结果中间过程全由上层DNS服务器代劳。迭代查询则是客户端每次只得到一个“下一站地址”然后自己再去问下一台服务器直到拿到完整解析结果。用一张表区分最直观查询方式谁发起谁干活典型场景递归查询DNS客户端本地DNS解析器上层DNS服务器代为逐级查询最终返回完整结果用户主机向本地DNS服务器发起查询迭代查询本地DNS服务器根DNS、顶级域DNS只返回下一级地址由本地DNS自行逐级追问本地DNS服务器向根DNS、顶级域、权威DNS逐级查询完整的DNS解析顺序是八步先查浏览器缓存再查本机Host文件都没有就向本地DNS服务器通常由ISP提供发查询请求本地DNS有缓存就直接返回没有则向根DNS服务器查询根DNS告诉本地DNS去问哪个顶级域服务器顶级域服务器告诉它去问哪个权威DNS服务器权威DNS服务器返回域名对应的IP最后本地DNS把IP返回给浏览器并在本地缓存一份方便下次快速响应。2.4 解析链路里最容易忽略的细节实际答题时很多人背了八步却漏掉关键认知浏览器缓存和Host文件是客户端本地行为而递归与迭代的分界点发生在本地DNS服务器之后。用户主机到本地DNS服务器这一段是递归查询本地DNS服务器到根、顶级域、权威DNS这一段是迭代查询。理解了这个分界才能回答“递归查询和迭代查询的区别”而不会背串。另一个容易忽略的细节是缓存的分层。浏览器缓存失效不代表Host文件也失效Host文件没命中也不代表本地DNS服务器没缓存。面试官常会追问“DNS缓存什么时候更新”这时要答出TTL生存时间每条DNS记录都有TTL过期后本地DNS服务器会重新向上游查询。如果答不上TTL至少要把“缓存是分层逐级生效的”这个意识表现出来。3. HTTP版本演进从/1.0到/3.0每一版改了什么3.1 HTTP的三条底层特性简单、无状态、不安全HTTP超文本传输协议是Web通信的基础客户端发起HTTP请求服务器处理后返回HTTP响应报文。它最初的设计理念是借助多文档之间相互关联形成的超文本连成可相互参阅的万维网。支撑它的三项技术是HTML页面文本标记语言、HTTP文档传递协议、URL文档地址。HTTP的特性可以总结成“简单、灵活、可扩展、无状态、明文传输、不安全”。简单是指基本报文格式就是headerbody头部信息是key-value文本形式。灵活是指请求方法、URI/URL、状态码、头字段都可以自定义和扩充下层传输层也可以随意变化HTTPS就是在HTTP与TCP之间加了SSL/TLS层HTTP/3则把TCP换成了基于UDP的QUIC。无状态是HTTP最核心的面试点服务器不会记忆HTTP的状态所以不需要额外资源记录状态信息减轻了服务器负担但做关联性操作时就会很麻烦。解决方案是Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端状态。明文传输意味着F12控制台或Wireshark抓包都能直接看到内容调试方便但信息容易被窃取。不安全体现在三方面通信明文不加密可能被窃听不验证通信方身份可能遭遇伪装无法证明报文完整性可能已被篡改。回答“为什么需要HTTPS”时对着这三条不安全点逐个说就是完整的逻辑链。3.2 HTTP/1.1 的贡献与历史包袱HTTP/0.9是1991年的最早期版本只支持GET方法没有请求头服务器只能返回HTML格式内容。HTTP/1.0是第一个正式版本引入了请求头和响应头支持多种请求方法和状态码但不支持持久连接每次请求都要新建TCP连接。HTTP/1.1解决了两个大问题也留下一个著名包袱。贡献一是长连接持久连接只要客户端和服务器任何一端没有明确提出断开连接就保持TCP连接状态避免每次请求都重新握手。贡献二是管道网络传输同一个TCP连接里客户端可以连续发多个请求不用等第一个响应回来再发第二个。但管道机制有个致命限制服务器必须按照接收请求的顺序发送响应。如果服务端处理A请求耗时较长后续请求的响应全都被阻塞这就是队头阻塞。注意措辞HTTP/1.1管道解决了“请求”的队头阻塞但没有解决“响应”的队头阻塞。而且管道化技术不是默认开启的浏览器基本都没有支持。HTTP/1.1还存在几个老问题头部冗余每个请求和响应都携带大量重复首部服务器按请求顺序响应慢请求会导致后续请求一直等不到数据没有请求优先级控制请求只能由客户端发起服务器只能被动响应。这些就是HTTP/2要解决的目标。3.3 HTTP/2头部压缩、二进制帧与Stream并发HTTP/2基于HTTPS所以安全性有保障。它的第一个改进是头部压缩采用HPACK压缩算法。HPACK由三部分组成静态字典、动态字典、Huffman编码。客户端和服务器各自维护一份字典用长度较小的索引号表示重复字符串再用Huffman编码压缩数据。静态表有61组高频字段写死在HTTP/2框架里不会变化动态表则依赖同一个连接上重复传输完全相同的HTTP头部动态表越占内存会影响服务器性能所以Web服务器会提供类似 http2_max_requests 的配置限制一个连接上能传输的请求数达到上限就关闭连接释放内存避免动态表无限增大。第二个改进是二进制帧。HTTP/1是文本格式HTTP/2改成二进制格式传输用位运算就能高效解析。HTTP/2共定义了10种帧分为数据帧和控制帧帧头里有流标识符Stream ID用于标识帧属于哪个Stream接收方据此从乱序帧中按相同Stream ID有序组装信息。第三个改进是并发传输。HTTP/1.1基于请求-响应模型同一连接中完成一个事务才能处理下一个造成队头阻塞。HTTP/2引入Stream概念多个Stream复用同一条TCP连接不同Stream的帧可以乱序发送接收端通过Stream ID组装实现并行交错地发送请求和响应。HTTP消息可以由多个Frame构成一个Frame可以由多个TCP报文构成。第四个改进是服务器推送。HTTP/1.1中服务器只能被动响应HTTP/2里客户端访问HTML时服务器可以直接主动推送CSS文件减少消息传递次数。这个特性常被单独拎出来问“HTTP/2的服务器推送和WebSocket有什么区别”答题时强调“服务器无需客户端明确请求即可额外推送资源”即可。但这些改进没有彻底解决队头阻塞HTTP/2的队头阻塞从应用层转移到了传输层。TCP是字节流协议必须保证收到的字节数据完整且连续内核才会把缓冲区数据返回给HTTP应用。只要前一个字节没到后面已经收到的数据也只能堆在内核缓冲区里。3.4 HTTP/3把TCP换成UDP后解决了什么HTTP/3的思路很干脆既然队头阻塞的根因是TCP那就把TCP换掉改用基于UDP的QUIC协议。QUIC在用户态实现可靠传输解决了HTTP/2在TCP层的队头阻塞同时保留了头部压缩、二进制帧、Stream并发这些能力。答题逻辑链是HTTP/1.1的队头阻塞在应用层→HTTP/2用Stream并发解决但TCP字节流特性又引入传输层队头阻塞→HTTP/3换UDPQUIC彻底绕开。这条演进线是计算机网络面试的高频主线建议按“每版解决了什么、遗留了什么”对比记忆。版本核心改进遗留问题HTTP/1.0引入请求头/响应头、多种方法、状态码每次请求新建连接HTTP/1.1长连接、管道传输响应队头阻塞、头部冗余HTTP/2头部压缩、二进制帧、Stream并发、服务器推送TCP层的队头阻塞HTTP/3基于UDP的QUIC生态与部署仍在演进3.5 HTTP缓存强缓存与协商缓存怎么配合URL回车第一步就涉及HTTP缓存判断这里单独梳理。HTTP缓存分为强缓存和协商缓存两种机制。强缓存直接使用本地副本不发请求到服务器协商缓存是本地副本可能过期需要向服务器验证能不能继续用。强缓存由 Expires 和 Cache-Control 控制。Expires是HTTP/1.0的字段给一个绝对过期时间缺点是客户端时间不准就会失效。Cache-Control是HTTP/1.1的字段用相对时间 max-age 控制优先级别更高。常用取值包括max-age多少秒内强缓存生效、no-cache可以缓存但每次要协商验证、no-store完全不缓存、public客户端和代理都能缓存、private只有客户端能缓存。协商缓存由两组字段配合。第一组是 Last-Modified响应头和 If-Modified-Since请求头用文件最后修改时间比对。第二组是 ETag响应头和 If-None-Match请求头用资源唯一标识比对。ETag的优先级高于Last-Modified因为修改时间精确到秒同一秒内多次修改会误判。协商缓存判定的标准是命中返回304 Not Modified未命中返回200和最新资源。用实际请求来演示缓存生效过程# 第一次请求资源观察响应头中的缓存控制字段 curl -I https://example.com/assets/app.css # 重点关注两个字段 # cache-control: max-age3600 → 1小时内强缓存生效浏览器不发请求 # etag: abc123 → 协商缓存标识强缓存过期后使用 # 强缓存过期后带上服务端返回的ETag再请求 curl -I https://example.com/assets/app.css -H If-None-Match: abc123 # 若返回 304 Not Modified说明资源未变化浏览器继续使用本地副本 # 若返回 200 和新ETag说明资源已更新浏览器重新下载并更新本地缓存理解强缓存和协商缓存的配合关系有个关键顺序浏览器先判断强缓存是否生效生效直接用本地资源完全不发请求强缓存失效后才发起请求走协商缓存带着上次的ETag或Last-Modified去问服务器服务器返回304就用本地副本返回200就用新资源并更新缓存。这个先后顺序是面试常考分支后面易错点章节还会再强调。4. TCP连接管理三次握手与四次挥手的完整答案4.1 三次握手为什么要三次不能两次也不能四次TCP是面向连接的可靠传输协议HTTP请求响应前必须建立连接。三次握手发生在URL全流程的第三步过程可以用一份状态表精确记忆握手次数发送方向报文内容客户端状态服务端状态第一次客户端 → 服务器SYN1, seqxSYN_SENTLISTEN第二次服务器 → 客户端SYN1, ACK1, seqy, ackx1ESTABLISHEDSYN_RCVD第三次客户端 → 服务器ACK1, seqx1, acky1ESTABLISHEDESTABLISHED面试官最常问的是“为什么是三次不是两次、四次”。回答逻辑分两层。从能力确认角度三次握手能确认双方的收发能力都正常。第一次握手让服务器知道客户端有发送能力第二次握手让客户端知道服务器有接收和发送能力第三次握手让服务器知道客户端的接收能力也正常。两次握手只能确认客户端发送能力、服务器接收和发送能力无法确认客户端能否正常接收这时客户端如果接收能力有问题服务器还继续发数据就会丢包。从历史连接角度两次握手无法防止已失效的连接请求突然到达服务器。客户端发送的第一个连接请求在网络中滞留超时后客户端重发请求并成功建立连接、关闭连接此时滞留的旧请求到达服务器服务器不知道这是个过期请求就会建立一条无效连接浪费资源。三次握手时客户端收到服务器对旧请求的确认后可以通过第三次握手带回的序号判断这不是本机期望的新请求从而发送RST复位避免服务器白白维护一条废连接。四次则没有必要因为三次已经确认了双方收发能力多一次只会增加一次往返时延。4.2 握手过程中的边界问题第二个高频追问是“第一次握手丢失会发生什么”。客户端发送SYN后若迟迟收不到SYNACK会触发超时重传重传次数达到阈值后放弃连接并返回错误。这里的答案要包含“超时重传”和“重传次数上限”两个关键词。第三个高频追问是“三次握手可以携带数据吗”。答案分情况第一次和第二次握手不能携带数据因为此时连接尚未建立服务器还没确认客户端的接收能力贸然携带数据可能丢失第三次握手时可以携带数据因为第三次握手发出时客户端已经收到服务器的SYNACK确认了双方收发能力都正常。能答出这个边界会明显加分。还有一个常被追问的异常场景SYN泛洪攻击。攻击者只发第一次握手的SYN不回应服务器的SYNACK大量半连接占满服务器的SYN_RCVD队列导致正常连接无法建立。对策一般是限制SYN_RCVD队列长度、SYN Cookie等回答时点出“半连接队列被占满”即可。4.3 四次挥手为什么断开连接要多一次TCP断开连接需要四次挥手状态变化比握手更复杂挥手次数发送方向报文内容发送方状态接收方状态第一次客户端 → 服务器FIN1FIN_WAIT_1ESTABLISHED第二次服务器 → 客户端ACK1FIN_WAIT_2CLOSE_WAIT第三次服务器 → 客户端FIN1LAST_ACKCLOSE_WAIT第四次客户端 → 服务器ACK1TIME_WAITCLOSED为什么断开需要四次而不是三次因为TCP是全双工通信两个方向各自独立关闭。客户端发送FIN表示“我的数据发完了不再发送”但此时仍然可以接收数据服务器收到FIN后先回ACK表示“我收到你的关闭请求”然后继续发送自己还没发完的数据等服务器数据也发完了再发送FIN表示“我这边也关闭”客户端收到FIN后回最后一个ACK连接才真正关闭。核心点是服务器收到FIN时可能还有数据要发所以ACK和FIN必须分两次发送。4.4 TIME_WAIT 的作用最后一个常见面试分支四次挥手后主动关闭方会进入TIME_WAIT状态等待2MSL报文最大生存时间的两倍后才彻底关闭。这里有两个作用。第一保证最后一次ACK能到达服务器。如果最后一个ACK丢失服务器会超时重传FIN客户端需要留在TIME_WAIT状态才能重新回复ACK否则服务器永远收不到确认无法正常关闭。第二让本连接内所有迟到的报文在网络中自然消失避免干扰后续使用相同四元组的新连接。实际面试中TIME_WAIT经常被追问实际意义。如果主动关闭方的TIME_WAIT连接过多会占用大量本地端口和内存高并发短连接场景下尤其明显。优化思路通常是调整TIME_WAIT复用或减少主动关闭方但答题时先讲清楚2MSL的设计原因比直接背优化方案更稳妥。5. 高频易错点五处背了也容易翻车的细节5.1 易漏点一SYN和ACK的标志位状态易漏点三次握手第二次报文的标志位是SYNACK两个同时为1很多人只写ACK导致逻辑断裂。为什么漏背诵时按“握手三次”记流程忽略了TCP报文是允许同时携带多个标志位的第二次握手既要确认第一次握手的SYN又要同步自己的初始序号所以必须两个标志位都置1。怎么补每次默写三次握手时强制自己写出“SYN1, ACK1, seqy, ackx1”完整四要素把第二次握手当作一个“既确认又同步”的复合报文来记而不是单独记一个ACK。5.2 易漏点二HTTP版本特性张冠李戴易漏点把管道传输安在HTTP/1.0头上或者把服务器推送安在HTTP/1.1头上。为什么漏版本迭代的每一项改进都有明确的“为了解决什么”脱离问题背景记特性时间一长就会混淆。怎么补按“问题→方案”成对记忆HTTP/1.0的问题是不能复用连接所以HTTP/1.1出长连接长连接上串行请求慢所以出管道管道导致响应队头阻塞所以HTTP/2用Stream并发TCP层还有队头阻塞所以HTTP/3换QUIC。答任何版本题都先说它解决了什么特性自然就能挂上号。5.3 易漏点三DNS的递归与迭代角色易漏点把用户主机到本地DNS服务器的查询说成迭代查询。为什么漏只背了“递归和迭代的定义”没有理解分界点。用户主机到本地DNS服务器是典型的递归查询用户只发一次请求等结果本地DNS服务器向上级逐级追问才是迭代查询。怎么补记一条主轴——递归是“客户端只问一次”迭代是“服务器逐级指路”。答题时说清楚“用户→本地DNS是递归本地DNS→根/顶级/权威DNS是迭代”就不会丢分。5.4 易漏点四强缓存与协商缓存的判断顺序易漏点先走协商缓存再判断强缓存。为什么漏直觉上以为“过期了就要问服务器”忽略了强缓存命中时根本不发请求。实际上请求都还没发出协商缓存无从谈起。怎么补记“强缓存命中不发请求协商缓存命中发了请求但服务器返回304”。判断顺序是先本地看Cache-Control/Expires强缓存有效直接返回200 from cache失效后才发出请求带If-None-Match/If-Modified-Since去验证。可以结合上一章的curl示例在复习时亲手跑一遍逻辑会清晰很多。5.5 易漏点五四次挥手过程中还能不能发数据易漏点认为客户端发出FIN后连接就彻底关闭了实际上客户端还能继续接收数据。为什么漏把TCP当成单通道理解忽略了全双工语义。客户端发FIN只表示“我不再发送数据”接收通道依然开放直到收到服务器的FIN并回复ACK后才完全关闭。怎么补每次画四次挥手图时在旁边标注“客户端发FIN后仍可recv服务器发FIN前仍可send”。答出这一点说明你真正理解了全双工关闭和三次握手的差别。6. 复习清单三十分钟自查一轮查漏补缺最后给一份可以直接拿来做的自查清单把高频题按“主问题→追问→参考要点”列出来。复习时不要对着答案背先闭卷答答不上来再回看对应章节。考点必答要点常见追问URL回车全流程七步完整链路每步可展开一个模块HTTP缓存判断发生在哪一步DNS解析浏览器缓存→Host→本地DNS→根→顶级→权威递归和迭代的分界点在哪HTTP/1.1长连接、管道、队头阻塞管道为什么没被浏览器启用HTTP/2HPACK、二进制帧、Stream、服务器推送队头阻塞为什么还在HTTP/3QUIC基于UDP绕开TCP队头阻塞为什么不用TCP改进三次握手SYN/ACK、状态变化、能力确认为什么不是两次、能否携带数据四次挥手FIN/ACK、CLOSE_WAIT、TIME_WAIT为什么断开要四次HTTP缓存强缓存Cache-Control、协商缓存ETag返回304和200分别代表什么复习技巧上推荐“错题显式化”每轮自测后不直接翻答案把卡壳的题记到一张纸上写上卡壳原因比如“分不清TIME_WAIT和CLOSE_WAIT谁先进入”。整理完会发现反复出错的往往是易错点章节里那五类而不是新知识。讲解题节奏时先用一句话答结论再用两句话补过程最后用一句点出边界条件这套节奏在面试里通常比事无巨细的背诵更受用。这份笔记梳理下来计算机网络八股的核心就一条主线加四块硬骨头主线程是URL回车七步四块硬骨头是DNS、HTTP版本演进、TCP连接管理、缓存机制。以前我复习时总想面面俱到后来发现先把主线背熟再沿主线往分支深挖效率比零散背题高得多。从那以后我每次复习计算机网络都强制自己走一遍“默写七步流程→针对每步自问三个追问→只看易错点清单查漏”的流程几轮下来基本能覆盖面试官的绝大多数问题。希望这份整理也能帮到你复习时少走弯路把时间花在真正容易丢分的地方。本文还有配套的精品资源点击获取