简介这是一份面向程序员求职与面试准备的计算机网络基础知识点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报文第二次由服务器回应SYNACK第三次由客户端再发ACK确认。这样设计是为了让双方都确认自己的发送和接收能力正常同时避免历史重复连接造成资源浪费。面试官常追问为什么是三次不是两次或者四次。两次握手的问题在于服务器无法确认客户端的接收能力是否正常也无法判断客户端是否收到了自己的SYN如果客户端发送的SYN因为网络延迟变成晚到的重复报文两次握手会让服务器白白建连。四次握手虽然也能建立连接但属于冗余三次足够所以设计上选三次。四次挥手是断开连接的过程。第一次由主动关闭方发送FIN第二次由被动方回应ACK表示收到关闭请求但被动方可能还有数据没发完所以第三次由被动方发送FIN第四次由主动方回应ACK。正因被动方可能还有数据要传挥手必须拆成四次不能像握手那样合并。回答这组题时我有一条血泪教训不要只背过程和状态名CLOSE_WAIT、TIME_WAIT这类一定要把为什么带出来。比如TIME_WAIT为什么等2MSL是因为要保证最后一个ACK能被对方收到丢失还能重发同时让本连接迟到的报文在网络中消失避免污染后续连接。这些细节一旦带上面试官基本不会继续死抠。另一个高频追问是第一次握手丢失会怎样和握手过程中可以携带数据吗。第一次握手丢失时客户端触发超时重传重传次数由tcp_syn_retries这类参数控制超过次数后连接建立失败第三次握手的ACK如果丢失服务器会重传SYNACK直到收到ACK或超时。握手过程中理论上可以携带数据但通常不会因为此时双方还没确认对方接收能力提前传数据浪费资源。这类追问在PDF的一问一答区都有覆盖值得单独标出来背。2.3 TCP与UDP选型怎么答才能让面试官满意PDF的思路是先把TCP和UDP的核心差异列出来再放到场景里做选择。TCP面向连接、可靠传输、有拥塞控制和流量控制适合文件传输、网页访问这类要求完整性的场景UDP无连接、不保证可靠、开销小、实时性好适合直播、语音、游戏帧同步这类允许少量丢包但延迟要低的场景。面试时只背TCP可靠、UDP不可靠很容易被追问到卡壳。常见做法是主动补一个量化对比对比项TCPUDP连接状态面向连接无连接可靠性可靠有确认与重传尽力而为头部大小至少20字节固定8字节典型场景文件传输、网页访问直播、语音、游戏帧这些数据一摆出来回答层次立刻不一样。还有一点容易被忽略HTTP/3把底层传输协议从TCP换成了基于UDP的QUIC。很多人困惑UDP不是不可靠吗怎么还能传HTTP实际上QUIC在UDP之上自己实现了可靠传输、流量控制和加密相当于在用户态重新造了一个TCP。面试时主动提这个点会显得你对协议演进有真实理解而不是背标准答案。面试官还喜欢问如果让你设计一个IM系统消息发送用TCP还是UDP。这类场景题没有标准答案但要有自己的结论和理由。我的回答是文字消息用TCP保证必达语音和视频用UDP降低延迟在应用层做丢包补偿。这样既展示了协议选择能力又体现了业务场景拆分。PDF里强调的正是这种不讲结论讲权衡的思路。准备这组题时建议把PDF里的标志位和状态码背到能随手画的程度比如SYN1、ACK1代表什么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服务器。回答时要分清哪一步是递归查询、哪一步是迭代查询对比项递归查询迭代查询发起方式客户端发一次请求服务器间逐级指向特点等待完整结果每次返回下一级地址适用场景用户浏览器与本地DNSDNS服务器之间这部分的坑在于很多人把本地DNS服务器向根服务器查询说成客户端向根服务器查询。正确的是浏览器只和本地DNS服务器通信后续根、顶级域、权威域之间的往来都由本地DNS服务器代理完成。把这个边界讲清楚是答好DNS题的关键。DNS解析过程对很多人来说是黑匣子我在联调时会用命令把它打回原形# 快速查看域名解析结果 nslookup www.example.com # 开启完整追踪逐级展示从根域名服务器到权威服务器的查询路径 dig trace www.example.comnslookup适合快速判断域名能不能解析失败时先看是不是域名拼错或者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。还要能说明为什么需要EtagLast-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的QUICQUIC在用户态实现可靠传输、流量控制、加密和连接迁移。某个包丢失时只影响它所在的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描述为正式数据传输的开始。原因混淆了连接建立完成和连接可用的边界。第三次握手是客户端告知服务器我已收到你的SYNACK握手完成后连接才进入ESTABLISHED状态。解决先说握手完成再说从第三次握手之后可以携带数据但第三次握手本身通常不携带应用层数据。翻车点二DNS解析过程层级说反现象把浏览器直接向根DNS服务器发起查询当成标准答案说出来。原因没有区分客户端和本地DNS服务器的角色。浏览器只向本地DNS服务器发起递归请求后续根、顶级域、权威域的查询由本地DNS服务器完成是迭代过程。解决画链路浏览器→本地DNS→根DNS→顶级域DNS→权威DNS明确每个箭头由谁发起。翻车点三强缓存与协商缓存混为一谈现象说缓存失效就重新请求但说不清304怎么来的或者把Expires和Cache-Control优先级说反。原因对两类缓存的触发条件理解不够。强缓存不问服务器协商缓存必须问服务器。解决按是否发请求判别不发请求的是强缓存发请求收304的是协商缓存优先级上Cache-Control的max-age覆盖ExpiresEtag覆盖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秒内给出结构化回答自测问题必须答出的要点输入URL回车后发生了什么七个环节按序说出挑一个展开为什么TCP握手要三次收发能力确认防止迟到重复SYN四次挥手为什么是四次被动方可能还有数据要发不能合并DNS递归与迭代的区别客户端只发起一次请求服务器逐级迭代强缓存与协商缓存的判别按是否发请求区分304属于协商缓存HTTP/1.1到HTTP/3的演进每代解决什么、代价是什么HTTPS为什么不全程非对称加密握手交换密钥数据用对称加密提示自测时如果某条卡壳超过30秒不是记性差而是这一步没有和主线关联。回到第2章的主流程把这个问题挂到对应环节上再讲一遍比反复背更有效。完成三遍后用面试官视角再走一遍针对每个高频题设想两个如果……怎么办的追问。比如三次握手第一次丢失会怎样HTTP缓存返回200却带了Etag怎么办。这些问题在PDF的一问一答区基本都有覆盖把它们标记出来考前集中扫一遍。一个血泪教训我早期准备面试时只刷题不开口结果模拟面试连CLOSE_WAIT在什么状态下出现都卡了十几秒。从那以后我每次整理完一份资料都强制对着录音软件把高频题完整讲一遍讲不顺的地方就是突破口。希望这份PDF的拆解思路能帮到你把八股文真正变成自己的面试话术。本文还有配套的精品资源点击获取