企业官网建设流程全解析

简介：《计算机基础》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：集中式为什么会挂，层级化怎么解决

DNS（Domain 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解析顺序是八步：先查浏览器缓存；再查本机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的特性可以总结成“简单、灵活、可扩展、无状态、明文传输、不安全”。简单是指基本报文格式就是header+body，头部信息是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换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-age=3600 → 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全流程的第三步，过程可以用一份状态表精确记忆：

面试官最常问的是“为什么是三次，不是两次、四次”。回答逻辑分两层。从能力确认角度：三次握手能确认双方的收发能力都正常。第一次握手让服务器知道客户端有发送能力；第二次握手让客户端知道服务器有接收和发送能力；第三次握手让服务器知道客户端的接收能力也正常。两次握手只能确认客户端发送能力、服务器接收和发送能力，无法确认客户端能否正常接收，这时客户端如果接收能力有问题，服务器还继续发数据就会丢包。

从历史连接角度：两次握手无法防止已失效的连接请求突然到达服务器。客户端发送的第一个连接请求在网络中滞留，超时后客户端重发请求并成功建立连接、关闭连接，此时滞留的旧请求到达服务器，服务器不知道这是个过期请求，就会建立一条无效连接浪费资源。三次握手时，客户端收到服务器对旧请求的确认后，可以通过第三次握手带回的序号判断这不是本机期望的新请求，从而发送RST复位，避免服务器白白维护一条废连接。四次则没有必要，因为三次已经确认了双方收发能力，多一次只会增加一次往返时延。

4.2 握手过程中的边界问题

第二个高频追问是“第一次握手丢失会发生什么”。客户端发送SYN后若迟迟收不到SYN+ACK，会触发超时重传，重传次数达到阈值后放弃连接并返回错误。这里的答案要包含“超时重传”和“重传次数上限”两个关键词。

第三个高频追问是“三次握手可以携带数据吗”。答案分情况：第一次和第二次握手不能携带数据，因为此时连接尚未建立，服务器还没确认客户端的接收能力，贸然携带数据可能丢失；第三次握手时可以携带数据，因为第三次握手发出时，客户端已经收到服务器的SYN+ACK，确认了双方收发能力都正常。能答出这个边界，会明显加分。

还有一个常被追问的异常场景：SYN泛洪攻击。攻击者只发第一次握手的SYN，不回应服务器的SYN+ACK，大量半连接占满服务器的SYN_RCVD队列，导致正常连接无法建立。对策一般是限制SYN_RCVD队列长度、SYN Cookie等，回答时点出“半连接队列被占满”即可。

4.3 四次挥手：为什么断开连接要多一次

TCP断开连接需要四次挥手，状态变化比握手更复杂：

为什么断开需要四次而不是三次？因为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的标志位状态

易漏点：三次握手第二次报文的标志位是SYN+ACK两个同时为1，很多人只写ACK导致逻辑断裂。为什么漏：背诵时按“握手三次”记流程，忽略了TCP报文是允许同时携带多个标志位的，第二次握手既要确认第一次握手的SYN，又要同步自己的初始序号，所以必须两个标志位都置1。怎么补：每次默写三次握手时，强制自己写出“SYN=1, ACK=1, seq=y, ack=x+1”完整四要素，把第二次握手当作一个“既确认又同步”的复合报文来记，而不是单独记一个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. 复习清单：三十分钟自查一轮查漏补缺

最后给一份可以直接拿来做的自查清单，把高频题按“主问题→追问→参考要点”列出来。复习时不要对着答案背，先闭卷答，答不上来再回看对应章节。

复习技巧上推荐“错题显式化”：每轮自测后不直接翻答案，把卡壳的题记到一张纸上，写上卡壳原因，比如“分不清TIME_WAIT和CLOSE_WAIT谁先进入”。整理完会发现，反复出错的往往是易错点章节里那五类，而不是新知识。讲解题节奏时，先用一句话答结论，再用两句话补过程，最后用一句点出边界条件，这套节奏在面试里通常比事无巨细的背诵更受用。

这份笔记梳理下来，计算机网络八股的核心就一条主线加四块硬骨头：主线程是URL回车七步，四块硬骨头是DNS、HTTP版本演进、TCP连接管理、缓存机制。以前我复习时总想面面俱到，后来发现先把主线背熟，再沿主线往分支深挖，效率比零散背题高得多。从那以后，我每次复习计算机网络都强制自己走一遍“默写七步流程→针对每步自问三个追问→只看易错点清单查漏”的流程，几轮下来基本能覆盖面试官的绝大多数问题。希望这份整理也能帮到你复习时少走弯路，把时间花在真正容易丢分的地方。

本文还有配套的精品资源，点击获取