计算机基础面试：URL全流程、三次握手与HTTP演进要点

简介：这是一份面向程序员求职与面试准备的计算机网络基础知识点PDF资料，尤其适合准备后端、前端岗位笔试面试的求职者，用于快速补齐高频考点。内容取自代码随想录知识星球精华（最强八股文）第五版计算机基础篇，系统梳理了TCP三次握手与四次挥手、HTTP与HTTPS差异、DNS分层解析与递归/迭代查询、HTTP强缓存与协商缓存机制，并按“输入URL到页面渲染”的完整流程串联各环节，方便按面试链路反复回顾。同时补充了DNS缓存查询顺序、集中式与分布式设计对比、域名层级等细节，帮助读者从原理层面理解。资源包内含1个PDF文件，大小约37.83MB，便于下载后离线阅读和章节检索。目前已有777人学习，对想摸清计算机网络常见面试题、提升应答深度的求职者是一份高密度的复习资料。

1. 计算机基础面试八股PDF：背得下来，还要答得出来

这份《计算机基础.pdf》不是普通的知识点清单，它把计算机网络面试里最高频的考题拆成了"原理讲解＋一问一答"两层：重点题深入拆解过程，零散知识单独给答题要点。适合两类人：一类是刚开始准备面试、面对八股文不知从哪下手的求职者；另一类是已经刷过题、但回答时抓不住重点、总被面试官追问到卡壳的开发。它的思路很直接：先通过"浏览器输入URL回车后发生了什么"这条主线串起DNS、TCP、HTTP、渲染、挥手全过程，再逐个击破高频考点。我拆这份资料时最深的感受是，它的价值不只是告诉你"答案是什么"，更在于告诉你"这道题该答到什么深度，追问往哪扩"。

2. 计算机网络面试核心：三次握手、四次挥手与URL全流程拆解

2.1 浏览器输入URL回车后发生了什么：一条主线串起所有考点

这是面试里的超高频题，也是这份PDF的开篇主线。一次完整的输入、回车，背后是七个环节：URL解析、DNS域名解析、TCP三次握手、发送HTTP/HTTPS请求、服务器处理并返回报文、浏览器渲染页面、TCP四次挥手。面试官问这道题，本质上是考察你对计算机网络全貌的掌握程度；你能从哪一步展开，决定这场面试的走向。

顺着主线往下走，每个环节都能向外延伸。URL解析时分清楚协议、主机、端口、路径这些组成部分；构造HTTP请求前，浏览器会先检查HTTP缓存，判断是直接用本地缓存还是向服务器发起请求；DNS解析把域名转成IP地址，涉及多层缓存和递归、迭代两种查询方式。这些分支单独拿出来都是一道题，但先掌握主线，再逐个击破会轻松很多。

这道题为什么值得花最多时间准备？因为它是整份PDF的总纲。面试官听到你把七个环节说得完整，大概率会顺着某一步往下追问，比如问DNS，问缓存，问渲染。也就是说，主线熟练到条件反射，剩下考点都是"分支"，答起来更有底气。我见过不少候选人把三次握手背得滚瓜烂熟，却说不清这一步发生在DNS解析之后还是之前，这就是缺主线的表现。

我准备这道题的习惯做法是：先按七个步骤把流程讲完，再挑自己最熟的一个环节展开。比如讲完三次握手，主动说"这里我可以展开讲一下为什么是三次而不是两次"，把面试官引导到自己准备充分的区域。这份PDF也是同样的思路，主流程之后，每个环节都配了延伸问题，照这个框架准备，基本不会冷场。

2.2 三次握手与四次挥手：过程、状态与高频追问

三次握手和四次挥手是计算机网络面试的重头戏，几乎没有哪场后端面试会跳过。三次握手建立TCP连接：第一次由客户端发送SYN报文，第二次由服务器回应SYN+ACK，第三次由客户端再发ACK确认。这样设计是为了让双方都确认自己的发送和接收能力正常，同时避免历史重复连接造成资源浪费。

面试官常追问"为什么是三次，不是两次或者四次"。两次握手的问题在于：服务器无法确认客户端的接收能力是否正常，也无法判断客户端是否收到了自己的SYN；如果客户端发送的SYN因为网络延迟变成晚到的重复报文，两次握手会让服务器白白建连。四次握手虽然也能建立连接，但属于冗余，三次足够，所以设计上选三次。

四次挥手是断开连接的过程。第一次由主动关闭方发送FIN，第二次由被动方回应ACK，表示收到关闭请求；但被动方可能还有数据没发完，所以第三次由被动方发送FIN，第四次由主动方回应ACK。正因被动方可能还有数据要传，挥手必须拆成四次，不能像握手那样合并。

回答这组题时我有一条血泪教训：不要只背过程和状态名（CLOSE_WAIT、TIME_WAIT这类），一定要把"为什么"带出来。比如TIME_WAIT为什么等2MSL，是因为要保证最后一个ACK能被对方收到，丢失还能重发；同时让本连接迟到的报文在网络中消失，避免污染后续连接。这些细节一旦带上，面试官基本不会继续死抠。

另一个高频追问是"第一次握手丢失会怎样"和"握手过程中可以携带数据吗"。第一次握手丢失时，客户端触发超时重传，重传次数由tcp_syn_retries这类参数控制，超过次数后连接建立失败；第三次握手的ACK如果丢失，服务器会重传SYN+ACK，直到收到ACK或超时。握手过程中理论上可以携带数据，但通常不会，因为此时双方还没确认对方接收能力，提前传数据浪费资源。这类追问在PDF的一问一答区都有覆盖，值得单独标出来背。

2.3 TCP与UDP选型：怎么答才能让面试官满意

PDF的思路是先把TCP和UDP的核心差异列出来，再放到场景里做选择。TCP面向连接、可靠传输、有拥塞控制和流量控制，适合文件传输、网页访问这类要求完整性的场景；UDP无连接、不保证可靠、开销小、实时性好，适合直播、语音、游戏帧同步这类允许少量丢包但延迟要低的场景。

面试时只背"TCP可靠、UDP不可靠"很容易被追问到卡壳。常见做法是主动补一个量化对比：

这些数据一摆出来，回答层次立刻不一样。还有一点容易被忽略：HTTP/3把底层传输协议从TCP换成了基于UDP的QUIC。很多人困惑UDP不是不可靠吗，怎么还能传HTTP？实际上QUIC在UDP之上自己实现了可靠传输、流量控制和加密，相当于"在用户态重新造了一个TCP"。面试时主动提这个点，会显得你对协议演进有真实理解，而不是背标准答案。

面试官还喜欢问"如果让你设计一个IM系统，消息发送用TCP还是UDP"。这类场景题没有标准答案，但要有自己的结论和理由。我的回答是：文字消息用TCP保证必达，语音和视频用UDP降低延迟，在应用层做丢包补偿。这样既展示了协议选择能力，又体现了业务场景拆分。PDF里强调的正是这种"不讲结论，讲权衡"的思路。

准备这组题时，建议把PDF里的标志位和状态码背到能随手画的程度，比如SYN=1、ACK=1代表什么，FIN和RST分别在什么场景出现。面试官很可能让你在白板上画出三次握手的标志位交换，画错一个字段都会很显眼。

3. DNS解析与HTTP/HTTPS：高频考点的答题边界

3.1 DNS层级结构与递归/迭代查询的边界

DNS解决的是"把域名转成IP地址"的问题。PDF对集中式和分布式DNS服务器的优缺点做了对比：集中式设计有单点故障、通信容量瓶颈、远距离访问延迟、维护成本高这几个致命问题，所以实际部署用分布式层级结构。域名用句点分隔，越靠右层级越高，比如www.example.com中，com是顶级域，example.com是二级域。

DNS解析过程按缓存层级逐步推进：先查浏览器缓存，再查本机Hosts文件，然后向本地DNS服务器发起查询；本地DNS服务器没有缓存时，会向根DNS服务器查询，接着是顶级域DNS服务器，最后是权威DNS服务器。回答时要分清哪一步是递归查询、哪一步是迭代查询：

这部分的坑在于：很多人把"本地DNS服务器向根服务器查询"说成"客户端向根服务器查询"。正确的是浏览器只和本地DNS服务器通信，后续根、顶级域、权威域之间的往来，都由本地DNS服务器代理完成。把这个边界讲清楚，是答好DNS题的关键。

DNS解析过程对很多人来说是黑匣子，我在联调时会用命令把它打回原形：

# 快速查看域名解析结果 nslookup www.example.com # 开启完整追踪，逐级展示从根域名服务器到权威服务器的查询路径 dig +trace www.example.com

nslookup适合快速判断域名能不能解析，失败时先看是不是域名拼错或者DNS配置异常；dig +trace会顺着根域名服务器逐级输出每一层的查询过程，正好对应上面表格里的迭代查询流程，参数+trace表示开启完整追踪，能看到每一级花了多少时间、返回给下一级的服务器地址。

3.2 HTTP缓存机制：强缓存与协商缓存的判别

HTTP缓存是容易被忽略、但命中率很高的考点。PDF把缓存分为强缓存和协商缓存两类。强缓存直接由Expires或Cache-Control控制，命中时不发请求，直接用本地副本；协商缓存是发了请求，但服务器判断资源未变化，返回304，浏览器继续用本地副本，同时通过Etag/If-None-Match、Last-Modified/If-Modified-Since两对请求/响应头完成校验。

面试时最好给出判断优先级：Cache-Control的max-age优先级高于Expires；协商缓存中Etag优先级高于Last-Modified。还要能说明为什么需要Etag：Last-Modified只精确到秒，如果文件在1秒内被改两次，或者修改时间被刻意改掉，就不可靠了；Etag用内容指纹解决这个问题。

在浏览器开发者工具的Network面板里可以直观验证：强缓存命中时，请求不出现在网络面板，浏览器直接使用本地资源，往往显示from disk cache或from memory cache；协商缓存命中时请求会发出，但响应状态码是304。这个观察方法对理解缓存优先级特别有效，比单纯记字段有用。

为了验证缓存是否真的命中，我一般用curl带完整请求头去看响应：

# 第一次请求，-I 表示只获取响应头，观察缓存字段 curl -I https://example.com/static/app.js # 第二次请求，-H 添加请求头，带上协商缓存条件 curl -I -H 'If-None-Match: "5e8f2d3c"' https://example.com/static/app.js

第一条命令会返回Cache-Control、Etag、Last-Modified等响应头字段，能直接看到资源被设置了多长时间的强缓存；第二条命令人为带上Etag条件，服务器如果返回304，说明协商缓存生效。面试时能说出这个验证过程，比单纯背概念更有说服力。

3.3 HTTPS安全层：HTTP与HTTPS的区别及SSL/TLS握手要点

HTTP和HTTPS的区别可以概括成三句话：HTTPS在HTTP与TCP之间加了一层SSL/TLS安全传输层；HTTP通信使用明文，内容可能被窃听；HTTP不验证通信方身份，可能遭遇伪装，也没有完整性校验，报文可能被篡改。HTTPS通过加密、身份认证和完整性校验解决这三个问题。

常见的追问是"SSL/TLS握手怎么工作的"。面试回答不必把每一帧背下来，但要讲清楚四个要点：第一次握手客户端发送支持的加密套件列表和随机数；第二次服务器选定加密套件并返回证书和随机数；客户端验证证书合法性，生成预主密钥，用服务器公钥加密后发送；双方根据预主密钥和两个随机数各自计算会话密钥，之后用对称加密通信。

证书验证是最容易被追问的环节。要能说出证书由CA签发、客户端内置CA根证书、通过信任链层层校验、检查证书域名和有效期这些动作。如果证书校验失败，浏览器会给出"不安全"警告。我曾在面试时栽在"HTTPS是全部非对称加密吗"这个问题上，正确回答是：握手阶段用非对称加密传递密钥，正式数据传输用对称加密，因为对称加密性能更高。

从HTTP迁移到HTTPS是实际项目里常做的事，有细节值得注意：端口从80变成443；证书要绑定域名，证书域名和访问域名不一致会报错；页面里的HTTP资源要全部换成HTTPS，否则出现混合内容警告；跳转要用301而不是302，避免搜索引擎和浏览器对临时重定向的差异化处理。这些点面试官不一定直接问，但场景题里很容易被拿来做背景。

回答HTTPS题还有一个隐含加分项：能说出HTTP/2基于HTTPS。HTTP/2规范要求底层使用TLS，这也是HTTP/2天然具备加密能力的原因。把这个点和HTTP版本演进放一起讲，知识就连成片了。

3.4 浏览器渲染流程与回流重绘：前端的必答项

输入URL回车后的第六步是浏览器渲染页面，这一步对前端候选人几乎是必考。渲染流程可以压缩成五句话：解析HTML构建DOM树，解析CSS构建CSSOM规则树，两者合并生成渲染树，根据渲染树计算布局，最后绘制到屏幕。渲染树只包含可见节点，display:none的节点不会进渲染树，visibility:hidden的节点仍占空间。

高频追问集中在回流和重绘。元素几何属性（宽高、位置、字体大小）变化时，浏览器重新计算布局，触发回流；只改颜色、背景这类不影响布局的属性，触发重绘。回流的代价远大于重绘，因为会引起后续节点甚至整个文档流的重新排列。

实际优化通常围绕减少回流展开：用transform代替top/left动画，把DOM批量修改合并成一次，用DocumentFragment或让元素脱离文档流再操作。面试时把"回流一定引起重绘，重绘不一定引起回流"这个结论带上，基本就够了。这部分在PDF里属于前端也会考的跨岗位知识，后端同学时间有限的话，至少记住流程和结论，以防被追问。

4. HTTP版本演进与避坑排查：从1.1到3.0的高频翻车点

4.1 HTTP/1.1、HTTP/2、HTTP/3的性能演进逻辑

HTTP版本的演进，本质是一部"解决性能问题"的历史。HTTP/0.9只支持GET和HTML内容；HTTP/1.0引入请求头和响应头，但每次请求都要新建连接；HTTP/1.1提出长连接和管道化，解决建连开销，但仍有头部冗余和队头阻塞；HTTP/2用头部压缩、二进制帧、并发传输和服务器推送提升性能；HTTP/3把传输层从TCP换成基于UDP的QUIC，彻底解决TCP层队头阻塞。

HTTP/1.1的队头阻塞表现在两个层面：请求层面，管道化允许连续发送多个请求，但服务器必须按接收顺序响应，前面的请求处理慢，后面响应全被堵住；响应层面，浏览器对同一域名下的并发连接数有限制（常见做法是6个左右），超出的请求只能排队等待。

HTTP/2的核心改动是引入Stream概念。多个Stream复用同一条TCP连接，每个Stream有唯一ID，接收端根据Stream ID把乱序到达的帧重新组装成HTTP消息。这样不同Stream的请求和响应可以交错发送，解决了HTTP/1.1的响应队头阻塞。但TCP是字节流协议，要求数据按序完整到达，如果前面一个Stream丢了一个字节，TCP层会把后续所有字节堵在内核缓冲区，HTTP/2拿不到数据，于是又出现"TCP层队头阻塞"。

HTTP/3选择把TCP换成基于UDP的QUIC，QUIC在用户态实现可靠传输、流量控制、加密和连接迁移。某个包丢失时，只影响它所在的Stream，其他Stream不受影响，从根上解决队头阻塞；同时把握手和TLS加密合并，减少连接建立的RTT次数。答这部分我习惯按"每代解决了什么问题，代价是什么"来讲，容易让面试官觉得你有大局观。

HTTP/2的头部压缩是另一个高频追问点。HPACK算法由静态字典、动态字典和Huffman编码三部分组成。静态表是写死在HTTP/2框架里的61组高频字段索引，像:method: GET、:status: 200这种直接用索引号表示；动态表在同一个连接上维护，要求连接中反复出现完全相同的头部才生效，所以服务器会提供类似http2_max_requests的配置来限制单个连接上的请求数，防止动态表无限增长占内存。回答时能说出这三个组成部分，比只说"有头部压缩"强很多。

服务器推送也是HTTP/2的特色功能：客户端请求HTML时，服务器可以主动把CSS、JS推给客户端，省去客户端逐个解析再请求的时间。但生产实践提醒过，服务器推送容易被滥用，推了客户端不需要的资源反而浪费带宽，所以很多团队更倾向于用preload提示来代替。面试提到这一点，说明你不只看优点，还知道它的边界。

HTTP/1.1时代还有一个经典考点：面对队头阻塞和头部冗余，业界常见优化手段有哪些？通常能列出几个：合并请求减少连接数、雪碧图把多张小图合成一张、CSS和JS文件做压缩、把静态资源放到多个域名下突破连接数限制、使用CDN就近接入。但这些都属于"外部优化"，没有改变协议本身的问题，所以HTTP/2才应运而生。面试时先说出这些手段，再点出局限，正好给HTTP/2做铺垫。

4.2 翻车点清单：五个高频错误与正确应对

这五条翻车点来自我模拟面试和真实面试里见过或踩过的坑，对照PDF的一问一答区比较容易自查。建议你把每条坑当成一道独立面试题，先说现象，再说原因，最后补解决，这个结构本身就是面试官喜欢的答题节奏。

翻车点一：把三次握手的第三次ACK说成携带数据现象：回答"第二次握手之后就能传数据"，或者把第三次ACK描述为正式数据传输的开始。原因：混淆了"连接建立完成"和"连接可用"的边界。第三次握手是客户端告知服务器"我已收到你的SYN+ACK"，握手完成后连接才进入ESTABLISHED状态。解决：先说握手完成，再说"从第三次握手之后可以携带数据，但第三次握手本身通常不携带应用层数据"。

翻车点二：DNS解析过程层级说反现象：把"浏览器直接向根DNS服务器发起查询"当成标准答案说出来。原因：没有区分客户端和本地DNS服务器的角色。浏览器只向本地DNS服务器发起递归请求，后续根、顶级域、权威域的查询由本地DNS服务器完成，是迭代过程。解决：画链路"浏览器→本地DNS→根DNS→顶级域DNS→权威DNS"，明确每个箭头由谁发起。

翻车点三：强缓存与协商缓存混为一谈现象：说"缓存失效就重新请求"，但说不清304怎么来的；或者把Expires和Cache-Control优先级说反。原因：对两类缓存的触发条件理解不够。强缓存不问服务器，协商缓存必须问服务器。解决：按"是否发请求"判别：不发请求的是强缓存，发请求收304的是协商缓存；优先级上Cache-Control的max-age覆盖Expires，Etag覆盖Last-Modified。

翻车点四：断言HTTP/2没有队头阻塞现象：回答"HTTP/2解决了队头阻塞"过于绝对。原因：只看到Stream并发，忽略了TCP字节流特性。HTTP/2解决了HTTP层的响应队头阻塞，但TCP层丢包导致的队头阻塞依然存在，只有HTTP/3用QUIC才彻底解决。解决：用递进关系作答："HTTP/1.1是请求队头阻塞，HTTP/2是TCP层队头阻塞，HTTP/3才彻底解决"。

翻车点五：HTTPS全程都是非对称加密现象：被追问"HTTPS数据加密用什么算法"时答不上来，或答"非对称加密"。原因：没有区分握手阶段和传输阶段。非对称加密只在握手阶段传递密钥，正式数据传输使用对称加密。解决：完整表述为"非对称加密交换密钥，对称加密传输数据，用MAC或AEAD保证完整性"。

如果你发现自己同一个坑踩了两次，大概率是记忆锚点没搭对。我一般把每条坑的"原因"改写成一句口诀，比如"强缓存不问服务器，协商缓存必须问服务器"，贴在资料封面页上。面试前一天扫一遍封面，比临时翻正文有效得多。五条坑不需要全背，但至少要能用自己的话把"现象→原因→解决"说完整，面试官打断追问时，最看重的就是你能不能从表象说到根因。

5. 把这份PDF变成面试话术：三遍阅读法与自测清单

资源下载下来不是拿来收藏的，要变成能说出口的话术。我拆完这份《计算机基础.pdf》之后，摸索出一套三遍阅读法。

第一遍，只看高频重点区的加粗结论和各章节开头的主线描述，不背细节，目标是建立"输入URL回车后发生了什么"这条主线，以及HTTP各版本解决什么问题的演进脉络。这一遍控制在一天内，重点是串起章节关联，别陷入某个考点的细枝末节。

第二遍，进入一问一答区，把每个问题先遮住答案，自己口头回答一遍，再对照答案找漏掉的关键点。口头回答很重要，很多人在纸上写得很顺，一开口就丢掉状态名、端口号、字段名这些"面试信号词"。这一遍我用手机录音，回放时重点听三次握手、四次挥手、HTTPS握手三段是否流畅，因为这三段是面试官最常打断追问的地方。

第三遍，做输出验证。按下表自测，每项要求30秒内给出结构化回答：

提示：自测时如果某条卡壳超过30秒，不是记性差，而是这一步没有和主线关联。回到第2章的主流程，把这个问题挂到对应环节上，再讲一遍，比反复背更有效。

完成三遍后，用面试官视角再走一遍：针对每个高频题，设想两个"如果……怎么办"的追问。比如三次握手第一次丢失会怎样，HTTP缓存返回200却带了Etag怎么办。这些问题在PDF的一问一答区基本都有覆盖，把它们标记出来，考前集中扫一遍。

一个血泪教训：我早期准备面试时只刷题不开口，结果模拟面试连"CLOSE_WAIT在什么状态下出现"都卡了十几秒。从那以后，我每次整理完一份资料，都强制对着录音软件把高频题完整讲一遍，讲不顺的地方就是突破口。希望这份PDF的拆解思路能帮到你，把八股文真正变成自己的面试话术。

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