简介这份PDF面向程序员与求职者是计算机基础面试核心考点的精华合集尤其聚焦计算机网络高频问题。内容系统梳理了TCP三次握手与四次挥手、HTTP与HTTPS的区别、HTTP缓存机制、DNS域名解析层级与递归/迭代查询并详细拆解在浏览器中输入URL后从解析、建连、请求、渲染到断开的完整过程。文档采用高频重点讲解加一问一答的结构既有原理图解也给出面试回答的基本要点适合准备技术面试、查漏补缺的开发者。资源为单个PDF文件大小37.83MB文本、图表排版完整可离线反复阅读。目前已有777人学习下载内容源自代码随想录知识星球精华整理并参考小林coding、牛客网等一线资料覆盖从基础概念到实战应答的体系化链路能帮助读者快速搭建计算机网络知识框架从容应对相关考察。1. 计算机网络面试为什么「输入URL按回车」这道题能拉开差距准备计算机基础类面试绕不开一个经典场景面试官让你讲「在浏览器输入URL并按回车之后发生了什么」。这道题的高频程度无论客户端还是服务端方向都排在前面。它难不在答案本身而在于它把DNS解析、TCP握手、HTTP请求与响应、浏览器渲染、四次挥手串成了一条完整链路面试官从中挑任意一个节点深挖都足以判断你是背了八股文还是真正理解了计算机网络的设计动机。这份计算机基础篇PDF就是按这个思路组织的高频重点把机制讲透一问一答区补碎知识点。它把「背结论」变成「顺着设计动机推导」等于替你把面试里最容易翻车的环节提前做了一次排查。接下来先看链路上第一个重量级状态机——TCP。2. TCP握手与挥手为什么次数被定死为三次、四次2.1 三次握手的本质同步双方序列号而不是「确认在线」很多人把三次握手理解成「双方互相确认一下在线」这个说法不算错但没说到根上。三次握手真正做的是两件事协商初始序列号、防止历史连接干扰当前连接。为什么不能是两次假设只有两次握手客户端发SYN服务端回SYNACK服务端就认为连接建立了。但服务端无法确认客户端是否收到了自己的SYN——也就是服务端的初始序列号没有被客户端确认。更关键的是旧SYN问题客户端发出的第一个SYN在网络中滞留很久客户端超时重传后完成了连接并关闭那个滞留的旧SYN这时才到达服务端服务端回了SYNACK就误以为建立了新连接于是白白维持一个无效连接浪费资源。三次握手能消灭这个问题服务端等不到最后一次ACK会认为连接不可用。三次握手的语义是「双向确认对方的发送能力和接收能力」。第一次SYN到达服务端服务端知道客户端想连第二次SYNACK到达客户端客户端确认了自己发的SYN被收到同时把自己的ACK带上第三次ACK到达服务端服务端确认客户端收到了自己的SYN。到这一步双方的初始序列号都完成了同步。方向报文含义时序状态客户端 → 服务端SYN(seqx)客户端初始序列号SYN_SENT服务端 → 客户端SYNACK(seqy, ackx1)服务端初始序列号并确认SYN_RCVD客户端 → 服务端ACK(seqx1, acky1)双向确认完成ESTABLISHED三次握手中第一次和第二次都不能携带数据但第三次可以——第三次握手时客户端已经确认服务端的接收能力没问题可以把HTTP请求的载荷直接塞进ACK里省掉一个RTT。这是HTTP请求跟TCP连接建立重叠时的常见优化。握手的异常分支也是高频追问点。第一次握手丢失客户端会超时重传SYN重传次数受内核参数tcp_syn_retries控制第三次握手丢失客户端已经进入ESTABLISHED开始发数据但服务端还挂在半连接队列里服务端会重传SYNACK直到超时。这里的半连接队列SYN queue是面试官喜欢往下挖的点它由listen的backlog参数决定长度队列满之后新来的SYN会被静默丢弃。线上出现「连接频繁超时、但CPU和带宽都不高」的怪现象时先查的就是这个队列有没有溢出。2.2 四次挥手半关闭状态决定了FIN与ACK必须分开挥手为什么必须四次而不是把中间两步合并核心原因是TCP半关闭half-close的设计。连接是双向的每一方都可以独立关闭自己的发送方向同时继续接收。四次挥手把关闭过程拆成两个独立的单向关闭客户端发FIN表示「我不再发数据了」服务端回ACK表示「收到但我可能还有数据要发」服务端数据发完后回自己的FIN表示「我也不发了」客户端回ACK完成关闭。第二步和第三步不能合并。服务端收到FIN的瞬间应用层可能还有未写完的响应数据。如果协议强制把ACK和FIN合在一起发就必须保证服务端在收到FIN那一刻已经没有数据要发这只能覆盖特例不能作为协议默认行为。所以挥手是四次是「语义完整」的结果不是性能妥协。这个状态下有两个状态值在实战里特别容易出问题。CLOSE_WAIT服务端收到FIN、回了ACK但应用层迟迟不调close()服务端连接就一直挂在CLOSE_WAIT。线上排查「连接数只涨不降」时大量CLOSE_WAIT基本等于你的业务代码忘关闭连接或忘释放资源。FIN_WAIT_2客户端等服务端发FIN这个状态有超时保护但服务端如果一直不关闭客户端会一直挂着。TIME_WAIT是另一个高频考点。主动关闭方发出最后一次ACK后要进入TIME_WAIT并等待2MSL最大报文段生存时间的两倍原因有两个一是保证最后一次ACK如果丢了能在MSL内等到服务端重传的FIN再补一次ACK二是让本次连接中迟到的报文段在网络里自然消亡防止它们串进由相同四元组新建的连接。代价是TIME_WAIT期间四元组被占用高并发短连接场景下服务端会积累大量TIME_WAIT。常见的调优手段是启用tcp_tw_reuse允许客户端复用TIME_WAIT连接以及控制tcp_max_tw_buckets的上限但tcp_tw_recycle在NAT环境下会引发连接错乱属于经典的踩坑参数不建议碰。2.3 用两条命令把握手与挥手的状态机「抓」出来握手和挥手不是靠背的它们真实发生在内核连接状态表里。起一个不关闭的服务端就能稳定观察到半关闭中间态# 服务端收到连接后故意 sleep不调用 close制造 CLOSE_WAIT import socket, time s socket.socket() s.bind((127.0.0.1, 9999)) s.listen(1) conn, _ s.accept() time.sleep(3) # 应用层不 close连接停在 CLOSE_WAIT conn.close()客户端连接后立即关闭然后查看连接状态表python3 server.py python3 -c import socket; ssocket.create_connection((127.0.0.1,9999)); s.close() ss -ant | grep 9999sleep期间执行ss -ant能同时看到客户端的TIME_WAIT和服务端的CLOSE_WAIT。这个实验的价值在于把书中抽象的「状态迁移」变成可观察的内核行为CLOSE_WAIT是内核态半关闭的直接体现只有应用层执行close()后连接才会走到LAST_ACK。以后排查连接泄漏时看到CLOSE_WAIT就明白是「应用层忘记关」而不是网络问题。3. DNS域名解析为什么必须分层缓存而不是让一台服务器管全部3.1 集中式设计的四个死穴DNS要解决的是「域名翻译成IP」。最朴素的想法是建一台超级DNS服务器存下所有域名映射所有人向它查询。这个方案在理论上可行但工程上完全站不住脚。单点故障排第一这台服务器一崩整个互联网的域名解析全部瘫痪。通信容量排第二全世界所有设备都在产生DNS查询量级是每秒上千万次一台服务器根本扛不住即便扛得住也是一场成本灾难。第三是远距离时延服务器不在用户附近跨洋查询要经过低速拥堵链路一个域名解析等几百毫秒体验直接崩。第四是维护成本域名每天在增删改集中式数据库要频繁全量更新没有任何组织能承受这种维护负担。这份PDF把集中式的四个问题讲得很明确。分布式是唯一出路但分布式也带来新问题——怎么让查询在庞大的服务器集群里高效收敛答案是分层域名系统按层级组织越靠右的层级越高。www.example.com里com是顶级域example.com是二级域www.example.com是三级域句点就是层级边界。查询时从根开始一级一级往下指路直到找到负责存储该域名映射的权威服务器。3.2 递归与迭代客户端只问一次服务器之间接力DNS解析过程里有两种查询模式区分它们是理解全链路的关键。递归查询发生在「客户端 → 本地DNS服务器」这一段。普通用户发出的查询要求本地DNS服务器「直接给我完整答案」本地DNS服务器接下任务后自己逐级去问拿到结果再返回给用户。对用户来说整个过程只发一次请求、等一个回应复杂的链路被封装在运营商侧。迭代查询发生在「DNS服务器 → 各级DNS服务器」这一段。本地DNS服务器向根服务器查询时根服务器并不负责解析也不替它继续往下问而是回答「你需要去哪个顶级域服务器查」本地DNS服务器记住这个地址再向顶级域服务器发起下一次查询顶级域服务器再告诉它「去这个权威服务器查」直到权威服务器返回真正的IP。为什么普通终端用递归、服务器之间用迭代因为迭代让每一级服务器只做最轻的事根服务器只需要维护一张「顶级域 → 顶级域服务器地址」的小表每次查询只应答一次指路信息负载极低。而递归则把复杂的查询链条封装起来让客户端实现变简单同时每一级服务器都能把自己的缓存插进链路里——本地DNS服务器拿到结果后会把域名解析记录缓存起来下一次同样的查询直接命中缓存返回不再惊动上层。递归是给用户省事迭代是给服务器省负载。3.3 解析链路的缓存从浏览器到本地DNS再到权威一次完整的DNS解析是沿着缓存逐级查找的过程层级角色缓存策略浏览器缓存客户端本地最近解析过的域名短期有效本地Hosts文件客户端本地人工指定的静态映射优先级很高本地DNS服务器运营商/机构提供缓存历史解析结果TTL内直接返回根DNS服务器顶级域索引只指路不缓存域名映射权威DNS服务器域名实际所有者返回最终IP是解析链路的终点查询顺序是浏览器缓存 → Hosts文件 → 本地DNS服务器 → 逐级向上迭代。本地DNS服务器是缓存收益最大的一层绝大多数用户的域名解析请求都能在这一层命中不会真的每次都打到根服务器。这一层缓存也带来了「更新难」的问题。域名换了IP权威服务器已更新但各级缓存的TTL还没到期用户仍然访问旧IP。TTL太短会增加权威服务器压力太长会拖慢故障切换速度这个取舍从DNS设计之初就存在到今天依然是分布式系统的一致性问题原型。理解这一点后面看HTTP缓存的两套机制时会有很强的既视感——缓存和一致性从来都是成对出现的矛盾。4. HTTP缓存强缓存与协商缓存为什么需要两套并存4.1 强缓存让资源零请求却无法感知更新强缓存的目标是「一次都别问服务器」。浏览器按URL作为key去本地缓存里找如果资源还在有效期内直接使用本地副本连网络请求都不发。开发工具里看到的from disk cache就是这种情况。强缓存的字段有两代。Expires是HTTP/1.0时代的方案值是绝对时间比如Expires: Wed, 21 Oct 2026 07:28:00 GMT。它有一个致命缺陷依赖客户端本地时钟用户改了系统时间缓存就失效或永久生效。HTTP/1.1因此引入了Cache-Control核心字段是max-age单位是秒是相对时间比如Cache-Control: max-age31536000浏览器从收到响应的那一刻开始计时。实际响应头里经常两个字段同时出现这不是冗余而是兼容性要求不认识Cache-Control的老代理服务器会退回使用Expires认识的就用Cache-Control。语义上两者是同级的同时出现时Cache-Control优先。强缓存的代价是「服务器无法主动失效」。如果一个CSS文件被强缓存一年线上更新了资源名才能让用户拿到新版本——这就是为什么前端工程里打包产物要带内容哈希后缀的原因。强缓存适合稳定的静态资源但不适合需要实时感知更新的接口数据。4.2 协商缓存用一次轻量请求换「可以感知到更新」当一个资源没法用强缓存比如max-age已过期或响应头明确no-cache浏览器就进入协商缓存流程带着上次缓存资源的校验标识去问服务器「这个资源还是不是原来的那一个」。协商缓存有两对字段代表两种校验强度。Last-Modified / If-Modified-Since是弱校验。服务器首次响应时返回资源的最后修改时间浏览器后续请求带上If-Modified-Since: Last-Modified的值服务器拿磁盘上文件的实际修改时间比对。它能工作但粒度太粗秒级精度同一秒内文件内容变了但mtime没变服务器会误判「未修改」更麻烦的是某些场景下mtime会自动更新内容没变也算变了导致不必要的304浪费。ETag / If-None-Match是强校验。ETag是资源的指纹常见实现是文件内容的哈希或者inodesizemtime组合。浏览器带If-None-Match: ETag的值服务器按当前内容重新计算指纹比对。内容没变返回304 Not Modified不带响应体内容变了返回200和新内容。强校验也会带来成本每次请求都要重新计算指纹所以服务器一般会对静态资源的ETag做缓存。两套校验为什么都保留一是历史兼容Last-Modified出现得早老代码和老代理服务器未必认识ETag二是成本考量弱校验只需要读一次mtime强校验要读文件或算哈希对高QPS接口来说是实打实的IO开销。规范里规定ETag优先级高于Last-Modified浏览器会同时带上两个头服务器优先用ETag判断。4.3 curl 实测看清响应头里缓存字段的实际语义用curl就能把这两类缓存的完整流程拉出来# 初次请求看服务器给出的缓存控制与校验字段 curl -sI https://example.com/asset.js | grep -iE cache-control|expires|etag|last-modified # 模拟协商把上一步拿到的 ETag 带回去问服务器 curl -s -o /dev/null -w %{http_code}\n \ -H If-None-Match: 上一步拿到的etag \ https://example.com/asset.js第一条命令会返回类似cache-control: public, max-age31536000、etag: abcdef12345的头部它告诉你强缓存的有效期和协商校验的指纹。第二条命令在资源未被修改时返回304修改过则返回200并带上新的ETag。需要特别区分的是Cache-Control里几个容易混淆的值。max-age0表示缓存已过期强制进入协商流程但缓存副本仍然可用——浏览器发请求带上校验头服务器回304就能复用这对应普通刷新F5的行为。no-cache语义是「可以缓存但每次使用前必须验证」与max-age0效果近似。no-store才是真正的不缓存请求和响应都不落盘敏感数据接口一般用这个。很多资源「改了配置还是翻车」就是把这个三个值混着配置导致缓存语义完全不符合预期。5. HTTP版本演进从管道化到二进制帧队头阻塞为什么一直没被根治5.1 HTTP/1.1的处境长连接、管道化与「外部优化」HTTP/1.0每次请求都要建立新的TCP连接开销极大。HTTP/1.1引入长连接持久连接只要双方没有明确断开TCP连接就一直复用。接着又引入管道化Pipelining同一条TCP连接里客户端可以连续发出多个请求不必等第一个响应回来再发第二个。管道化表面上解决了「请求的队头阻塞」——请求确实可以连续发出去了。但它只做了一半服务器必须按照接收请求的顺序返回响应。如果第一个请求对应的响应因为业务处理慢迟迟不返回后面所有已处理完的响应也只能排队等着这就是「响应的队头阻塞」。更现实的情况是管道化技术本身没有被浏览器默认启用绝大多数浏览器从未支持完整实现所以这个特性在实践中几乎是死的。协议层面解决不了社区就只能靠「外部优化」绕着走。合并CSS/JS文件减少请求数把多张小图标合成雪碧图把静态资源部署到不同域名下突破浏览器对单域名6条连接的限制这些手段都是典型的外部优化——协议没有并发能力就靠多开几辆车来拉货。理解这一点才能明白HTTP/2的改进方向不是修修补补而是重新设计并发模型。5.2 HTTP/2的三大改造HPACK、二进制帧、Stream并发HTTP/2做了三个关键改造头部压缩、二进制帧、多路复用流。这三个改造是层层递进的。头部压缩解决「头部冗余」。HTTP/1.1的每个请求都要带上Cookie、User-Agent等一大串文本头重复传输浪费带宽。HTTP/2使用HPACK算法压缩头部它由三部分组成静态字典、动态字典、Huffman编码。静态字典是协议内置的一张表把method: GET、scheme: https这类高频出现的完整字段预置为索引号共61组传输时只传一个数字。动态字典是连接级别的缓存同一个连接里重复出现的自定义头会登记进表后续用索引号代替。Huffman编码进一步压缩字符串的字节数。动态字典有一个被很多人忽略的代价它越大占用的内存越多。如果一条连接上请求无限增加动态表会无限膨胀拖垮服务器。Web服务器的常见做法是用http2_max_requests之类的配置限制单连接上的请求数达到上限就主动断开连接连带着释放动态表内存。这个机制直接解释了为什么某些长连接会在请求数到达阈值后莫名断开——不是网络问题是内存保护策略。二进制帧解决「解析效率和并发控制」。HTTP/1.1的报文是文本格式解析时要按行处理HTTP/2把数据切成帧帧头固定9字节包含Length、Type、Flags、Stream Identifier二进制可以用位运算快速解析。HTTP/2共定义了10种帧类型按用途分数据帧和控制帧两类。多路复用是第三个改造也是解决队头阻塞的核心。HTTP/2引入Stream概念一条TCP连接上有多个Stream每个Stream承载一个HTTP请求-响应用Stream ID区分。不同Stream的帧可以乱序发送、交错传输接收端按Stream ID把帧重新组装成完整的HTTP消息。这解决了HTTP/1.1「一个连接同时只能处理一个事务」的排队问题。版本传输层并发模型队头阻塞位置HTTP/1.0TCP短连接每请求一连接无复用建连开销大HTTP/1.1TCP长连接管道化按序响应应用层/连接层HTTP/2TCPStream多路复用传输层TCP字节流HTTP/3UDP/QUICStream独立丢包恢复仅单个Stream内部但HTTP/2的队头阻塞只是转移了位置没有消灭。它基于TCP传输TCP是字节流协议要求数据完整有序交付前一个字节没到后面已经到达的字节只能堆在内核缓冲区等待应用层拿不到不完整的数据。当某个TCP报文丢包该连接上所有Stream的后续数据全部被阻塞。这份PDF把这个现象讲得很清楚——HTTP/2把队头阻塞从HTTP层转移到了TCP层问题仍在。5.3 服务器推送与流控制HTTP/2比1.1多的两个能力HTTP/2还引入服务器推送客户端请求一个HTML页面时服务器可以推断它还需要哪些CSS和JS主动把这些资源推送过来省掉客户端逐一请求的往返时延。实现上服务器先发一个PUSH_PROMISE帧告知客户端「我会推什么」随后直接发送对应资源帧客户端收到后按正常资源缓存处理。这个机制能显著减少首屏瀑布图的请求链条。流控制则解决了「慢消费者问题」——某个Stream的接收方处理不过来发送方如果继续狂发接收缓冲区会被打爆。HTTP/2允许每个Stream独立设置窗口大小接收方通过WINDOW_UPDATE帧告知发送方还能收多少。窗口是Stream级别不是连接级别一个慢Stream的背压不会拖垮其他Stream。结合5.1来看HTTP/1.1时代被迫做的域名分片、资源合并在HTTP/2下不再有必要——一条连接内多个Stream并发服务器推送又主动喂饱页面这解释了为什么HTTP/2上线后很多前端性能优化方案反而被废弃。5.4 避坑HTTP版本实践与面试的三个踩坑现场整理三个高频翻车场景每条按现象、原因、解决来说。坑1连接池不够用请求排队等连接。现象页面加载耗时异常并发请求一多就变慢网络面板里大量请求处于stalled/queueing状态。原因浏览器对同一域名下的HTTP/1.1连接数有上限通常6条而一个连接同一时刻只能处理一个事务连接被占满后新请求只能在客户端排队。解决升级HTTP/2用单连接的Stream并发替代多连接HTTP/1.1阶段则把请求分散到多个域名或合并请求。以下脚本可以复现排队效应// 服务端按 query 参数延迟响应 const http require(http); http.createServer((req, res) { const d Number(req.url.split(?d)[1]) || 0; setTimeout(() res.end(ok), d); }).listen(9000, () console.log(server on 9000));// 客户端8 个请求并发 2 条连接剩下 6 个必须排队 const http require(http); const agent new http.Agent({ keepAlive: true, maxSockets: 2 }); const t0 Date.now(); let left 8; for (let i 0; i 8; i) { http.get( { host: 127.0.0.1, port: 9000, path: /?d${100 (i % 3) * 200}, agent }, res { res.resume(); if (--left 0) console.log(全部完成耗时 ${Date.now() - t0} ms); } ); }把maxSockets调成2再调成8跑一遍总耗时的差异就是连接级队头阻塞的直接证据。maxSockets对应浏览器连接数上限参数变大意味着更多连接并行收发。坑2HTTP/2连接莫名断开。现象一条连接上持续大量请求后连接被服务端重置GOAWAY帧业务上表现为偶发请求失败。原因连接上的动态表在持续增长占用内存过高触发了服务器的请求数上限保护。解决确认服务端的http2_max_requests配置达到上限主动关闭连接客户端侧实现重新连接的逻辑不要假设长连接永远可用。坑3面试里答「HTTP/2还在制定中」。现象沿用旧教材的说法把HTTP/2描述为未来的事情。原因资料更新滞后。解决以RFC和浏览器实际支持情况为准HTTP/1.1仍是部署最广的版本HTTP/2已在生产环境大面积使用HTTP/3基于QUIC把传输层换成了UDP。重点不是记版本号而是讲清每代版本为了解决什么问题——6. 设计取舍复盘可靠性、有序性与低延迟协议怎么选6.1 为什么TCP的强有序性在HTTP/2时代成了包袱把HTTP/1.1到HTTP/3的演进放在一起看能看出一条清晰的取舍线。TCP提供字节流的可靠有序传输这是它几十年来成功的根基但强有序性在链路丢包时变成枷锁一个包丢失后面全部排队。HTTP/2把它推到了极致——所有Stream共享同一条字节流任何一个Stream的丢包都会拖累整条连接上所有Stream。HTTP/3的解法是放弃TCP把传输层换成基于UDP的QUIC在应用层自己实现丢包检测、乱序重组和可靠传输。这样每个Stream独立处理自己的丢包恢复一个Stream丢包只影响自己。代价是QUIC必须在用户态实现TCP曾经在内核态免费提供的能力复杂度从内核转移到了协议实现。这个取舍说明了工程上的真相没有银弹只有把约束放在哪个层次的权衡。6.2 一个可复现的验证把「协议版本差异」量出来要验证这些设计差异不需要复杂工具。抓一次包就能看到HTTP/1.1与HTTP/2的本质区别HTTP/1.1的报文里明文可见GET / HTTP/1.1和一行行文本头HTTP/2里清一色是不可读的二进制帧要靠帧头的Stream ID来分辨归属。启用HTTP/2的站点在开发者工具里看瀑布图所有资源挤在同一条连接上并行加载同一站点用HTTP/1.1访问资源被分割成多个连接槽位请求多时出现排队。这个对比能直观回答一个问题协议演进到底改了什么。6.3 从这份资料里学到的最重要一课这份PDF把所有高频八股还原成了设计动机。握手次数由语义决定——两次无法双向确认序列号三次刚好完整挥手的四次由半关闭决定——ACK和FIN必须分开才能让数据收尾缓存强弱由代价决定——强缓存省RTT但无法感知更新协商缓存多一次请求但换来可控协议版本由传输模型决定——队头阻塞的根本原因是「单字节粒度有序交付」不是「顺序响应」本身。回想我自己经历过的一次面试追问到「ETag的弱校验服务器端到底怎么算出来的」时卡壳——只会背字段名说不出inodemtime与内容hash的区别和各自成本那一次让我意识到八股和理解的差距。从那以后我每次看协议都强制自己走一遍「现象→机制→实现→取舍」四步先问为什么这么设计再去看代码怎么落地最后想它在什么场景下会付出什么代价。这份计算机基础篇PDF就是照着这条路径整理的建议你也拿它当索引而不是答案库每个结论都顺着机制链路推一遍。希望帮到你。本文还有配套的精品资源点击获取