★ FEATURED ARTICLE 简介面向后端与前端求职者的计算机网络面试复习资料由代码随想录知识星球八股文体系整理聚焦高频考点的理解与背诵。内容围绕三次握手与四次挥手、HTTP与HTTPS、DNS域名系统、HTTP缓存等核心概念展开并把「输入URL后浏览器做了什么」这道超高频题拆为URL解析、DNS解析、TCP连接建立、请求与响应、页面渲染、断开连接等环节逐段延伸可追问的细节DNS部分还细讲集中式设计的单点故障、容量与时延弊端、域名层级结构以及递归查询与迭代查询的区别。资源为单个PDF文件约37.83MB按高频重点深入讲解与一问一答补充细碎知识点两条线编排便于按主题检索、对照面试要点自测。已有778人学习。1. 从一个回车键说起计算机基础到底指什么在地址栏敲下一串网址、按下回车进度条转半圈页面就亮起来了。这件事顺滑到没人会多想一秒可一旦有人问这中间到底发生了什么很多人会突然卡住——天天在用却讲不出一句完整的话。计算机基础指的就是这类知识的总称它不是某一门课的考纲而是网络、操作系统、数据结构这些底下那层的公共常识正是这些共识支撑着上层应用运行起来。面试官盯着这些问并不是在考记忆力他想确认的是你遇到问题时知不知道该往哪一层去查。这份计算机基础篇的整理稿做的正是把那条链路一段段拆开、标出重点的事。它最典型的讲法就是从在浏览器里输入 URL 并回车之后发生了什么这一道题开始因为这一道题几乎能把计算机网络的所有高频概念全部牵出来。2. 一次回车背后的七步链路从输入网址到页面亮起来这道题之所以被反复问是因为它像一根可以拉长的线面试官从任意一个点往下拽都能拽出你想要的方向。答得好主动权就在你手上答得糊后面每一个追问都会变成突然的提问。所以关键不在于背下七个步骤的名字而在于每一步都能说清楚为什么必须有这一步。2.1 前三步拆地址、翻通讯录、把连接握起来浏览器拿到一串地址比如https://www.example.com/blog/index.html?page2第一件事是把它解析清楚。https是协议决定了后面走的是加密通道还是明文通道www.example.com是主机名也就是人记得住的那部分端口没写就取默认值http 默认 80https 默认 443/blog/index.html是路径page2是查询参数。解析完成浏览器手上就有了一份构造 HTTP 请求所需的全部材料。但拆完地址并不等于立刻发请求。浏览器会先查看自己的缓存记录请求头里往往带着If-None-Match、If-Modified-Since这类字段相当于问服务器一句我手上这份还能不能用。能用就直接读本地网络一个字都不用发。这一步是很多人在答题时漏掉的可它恰恰是为什么第二次打开同一个网站快很多的答案也是最容易被追问的地方。接着是 DNS 域名解析。域名是给人看的机器只认 IP 地址DNS 就是那本把www.example.com翻译成192.0.2.10的分布式通讯录。查询有先后顺序先翻浏览器自己的缓存再看本机 hosts 文件里有没有写死都没有才去问本地 DNS 服务器一路问到根、顶级域、权威服务器。这一整段链条是后面第 3 章的主角这里先记住它的存在就够了。拿到 IP 之后才是三次握手。客户端先发一个 SYN意思是我想连你我的初始序号是 x服务端回一个 SYNACK意思是收到了我的初始序号是 y确认你的 x客户端再回一个 ACK收到你的 y。三步走完双方都各自确认了两件事我能发、你能收你能发、我能收。那为什么是三次不是两次因为如果只握两次服务端发完 SYNACK 就单方面认为连接建好了可它根本不知道客户端有没有收到这个报文。万一这个报文在网络里丢了客户端会以为自己没连上继续重发 SYN服务端那边却已经占着一份连接资源干等——白白浪费。第三次 ACK 的价值就在于让服务端确认对方确实收到了我的确认这是一次成本极低却能消除歧义的补充确认。至于为什么不是四次答案更简单服务端的 SYN 和 ACK 可以合并成一个报文发出去没有拆开的必要。次数不是玄学是被能不能合并决定的这一点和第 2.3 节要讲的四次挥手刚好形成对照。顺着第一次握手丢了会怎样继续往下想也很能说明问题。客户端的 SYN 没到达服务端它等不到 SYNACK就会超时重传重传间隔通常按指数退避拉长——1 秒、2 秒、4 秒这样翻倍重传到一定次数还不行就报连接超时。还有一种更绕的情况客户端发的 SYN 到了服务端回的 SYNACK 丢了客户端重传 SYN服务端会以为自己上次那个报文没被收到于是再发一次。这类细节面试官很爱问因为背过的人答不出。还有一个常见的追问是握手过程中能不能携带数据。前两次不行连接还没建立带了也没人处理第三次握手可以带因为此时客户端已经确认链路通畅。这个知识点本身很小但能答出来说明你理解的是握手的目的而不是三个报文的名称。2.2 后四步发请求、收响应、画页面、说再见连接建好后浏览器把构造好的请求报文发出去。一个最简的请求长这样GET /blog/index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: text/html Accept-Encoding: gzip, deflate, br If-None-Match: a1b2c3 Connection: keep-alive第一行是请求行三个部分方法、路径、协议版本。Host决定了同一台服务器上你要访问哪个站点虚拟主机全靠它区分。Accept-Encoding告诉服务器我支持这些压缩格式服务器才好决定用哪种方式压缩响应体这也是响应头里出现Content-Encoding的原因。If-None-Match是协商缓存的凭证服务器拿它和自己手上的版本比对一致就返回 304让浏览器继续用本地那份。Connection: keep-alive表示这条 TCP 连接别急着关后面还要接着用。服务器收到请求交给对应的处理程序返回响应报文。响应里最值得关注的是状态码200 表示一切正常301 和 302 是重定向一个永久一个临时304 表示你本地那份还能用404 是资源不存在500 是服务端自己出错了。响应头里还常常带Cache-Control说明这份资源能缓存多久带Set-Cookie让浏览器存下身份凭证。浏览器拿到 HTML 之后开始渲染。HTML 被解析成一棵 DOM 树CSS 被解析成 CSSOM两棵树合成渲染树然后计算每个元素的位置和大小这一步叫布局最后把像素画到屏幕上。这里有个容易被追问的区分如果改动的是元素的尺寸、位置这类几何属性浏览器得重新算一遍布局叫回流如果只改颜色、背景这类不影响布局的属性重新画一遍就行叫重绘。回流代价比重绘大得多所以前端优化里常说少动布局多用 transform。另外script标签会阻塞 HTML 解析这也是它通常被放在页面底部或者加上defer、async的原因。页面显示出来还不算完连接要断开走的是四次挥手。客户端发 FIN我这边没数据要发了服务端回 ACK知道了等服务端把剩下的数据也发完再发一个 FIN我这边也发完了客户端回最后一个 ACK连接正式关闭。为什么挥手要四次握手只要三次因为 TCP 是全双工的两个方向的数据流要分别关闭。服务端收到客户端的 FIN 时很可能自己还有数据没发完所以只能先回一个 ACK 表示收到你的关闭请求等数据发完了再单独发 FIN。这两个动作没法合并所以多了一次。对比一下握手就很清楚握手时服务端没有还没发完的数据这层顾虑SYN 和 ACK 可以合在一个报文里。最后一个 ACK 发完之后客户端还要进入 TIME_WAIT 状态等 2MSL 才真正关闭。等的原因有两个万一最后那个 ACK 丢了服务端会重发 FIN客户端还有机会再回一次同时让这条连接上残留的报文在网络里自然消失不至于串到后面一条用相同端口的新连接上去。2.3 七步只是骨架真正考的是延伸能力把七步背下来只是拿到了入场券。这道题的价值在于它是一条主干每个节点都能长出一串分支从 URL 解析能聊到 HTTP 缓存策略从 DNS 能聊到递归与迭代的区别从三次握手能聊到 SYN 洪泛和半连接队列从 HTTP 请求能聊到 HTTPS 的加密过程从渲染能聊到回流重绘和浏览器的事件循环。所以答这道题有个很实用的策略先按七步给一个完整但简洁的骨架再主动挑一个自己最有把握的点展开一两句深一点的细节。这等于告诉面试官往这个方向问我接得住。反过来如果七步只是机械念完中间不留任何可以停留的地方面试官只能自己找地方切进去那切到哪儿就不由你决定了。我见过不少人把这七步背得滚瓜烂熟却在第二次握手丢了会怎样这种追问上卡住问题就出在只记了流程没记每一步存在的理由。3. DNS 为什么不能只用一台服务器域名到 IP 的翻译链条3.1 DNS 是什么互联网的通讯录打个比方DNS 就像手机通讯录。你按名字找人手机负责把名字换成号码拨出去。你不会去记每个人的十一位数字因为记不住也没必要。DNS 干的是同一件事把www.example.com这样的域名翻译成192.0.2.10这样的 IP 地址让机器能互相找到。域名的写法自带层级。www.server.com里那些句点就是层次的分界线而且越靠右层级越高。.com是顶级域server.com是二级域www是最左边的主机名。这个方向和日常写地址刚好相反——我们写地址是从大到小域名也是从大到小只不过是从右往左读。搞清这个方向后面理解解析顺序才不会乱。为什么当初要设计成分布式因为集中式的方案有四个绕不过去的坑。3.2 集中式的四个坑为什么一台服务器撑不住第一是单点故障。全世界的域名解析都压在一台机器上它一崩整个网络就跟着瘫。这不是性能问题是可用性问题而且没有任何补救余地。第二是通信容量。一台服务器要处理全球的查询请求量级是每秒上百万甚至上千万次。这个数量不是靠堆硬件能解决的网络带宽和单机处理能力都有物理上限。第三是距离带来的时延。一台服务器不可能离所有人都近。假设它架在某个洲另一个洲的用户查一次域名请求要在低速拥堵的链路上来回跑光是往返时延就够把页面加载拖慢一大截。这和内容分发要就近部署是同一个道理。第四是维护。这么一份关键数据要频繁更新还要保证不出错集中维护的成本和风险都被放大到不可接受。分布式的思路就是把这份通讯录拆开按层级分给不同的服务器管根服务器只管.com该问谁顶级域服务器只管server.com该问谁权威服务器才真正存着某个域名对应的 IP。任何一台出问题影响面都被限制在一个局部而且每台服务器只承担自己那一份查询量离用户也更近。3.3 一次完整解析要经过几道手从你敲下回车到拿到 IP中间大概是这样一条路先是浏览器缓存。浏览器会把自己解析过的域名记一段时间命中就直接用。其次是操作系统层面的 hosts 文件这是个可以手工写死域名和 IP 对应关系的小文件本地开发时改它比等 DNS 生效快得多。这两层都没命中才向本地 DNS 服务器发查询——它一般由你的网络服务提供商维护也可能是一个公共 DNS 服务。本地 DNS 服务器收到请求先看自己有没有缓存。有就直接返回没有就开始往上问。它先问根服务器根服务器不负责具体解析但它知道各个顶级域该找谁于是回一个.com你去问那台。本地 DNS 再问顶级域服务器对方同样不解析具体域名只告诉它server.com归那台权威服务器管。最后问到权威服务器那里才真正存着域名和 IP 的映射关系查到之后把结果回给本地 DNS。本地 DNS 把结果转给浏览器同时自己留一份缓存下次别人再问就快得多。这条链路上每一层都有缓存缓存都有有效期也就是 TTL。TTL 设得长解析快但改记录生效慢设得短切换灵活但查询压力大。做上线切换时遇到域名改了但部分地区还访问旧地址多半就是 TTL 在起作用——这是很典型的踩坑现场。3.4 递归查询和迭代查询谁在替你跑腿这两个词最容易背串因为它们的差别不在查什么而在谁在跑。递归查询是你托人办事办到底。客户端只发一次请求然后等着中间的来回奔波全部由被委托的那台服务器负责最后给你一个确定的结果。日常用户到本地 DNS 服务器走的就是递归你只问一次本地 DNS 负责把答案拿回来。迭代查询是你问路对方只告诉你下一站。客户端每问一次得到的是一台更具体的服务器地址然后自己再去问下一台一站一站往下走直到问出结果。本地 DNS 服务器到根、顶级域、权威服务器之间的查询就是迭代。用一句话记住分工普通客户端用递归省事DNS 服务器之间用迭代因为每台服务器只知道自己那一层的下一跳让它替别人跑完全程既不合理也不现实。对比项递归查询迭代查询谁在跑腿被委托的服务器跑完全程查询方自己一站站问请求次数客户端只发一次客户端发多次结果直接给最终 IP给下一跳服务器地址典型场景客户端到本地 DNS本地 DNS 到根/顶级/权威4. HTTP 为什么要一路改版从 1.1 到 3.0 的性能账本4.1 HTTP 的性格简单、灵活以及无状态带来的麻烦HTTP 的基本报文格式就是 header 加 body头部是 key-value 形式的纯文本看一眼就大概知道在说什么这是它简单的地方。它的各个组成部分也没有被写死请求方法、URI、状态码、头字段都允许自行扩展所以它能从最早的网页文档传输一路长成今天承载各种接口的东西。HTTP 工作在应用层下面换成什么传输方式它原则上不太关心——HTTPS 就是在它和 TCP 之间插了一层安全传输层HTTP/3 干脆把底下的 TCP 换成了基于 UDP 的 QUIC。但它的性格里也有三个明显的短板。一是无状态服务器不记得你上一次请求是谁发的好处是不用为每个用户占资源坏处是做有关联的操作时非常别扭。解决办法里最简单的是 Cookie在请求和响应报文里带上一点标识让服务器能把几次请求认成同一个人。二是明文传输信息在网络里是能直接读的用浏览器的开发者工具或者抓包软件都能肉眼看清。这在调试时是极大的便利但也意味着内容容易被窃取。三是不验证身份、不保证完整性通信双方不确认对方是谁报文有没有被改过也无从证明。这三个短板合起来就是不安全这三个字的具体含义。HTTPS 的思路是在 HTTP 和 TCP 之间加一层 SSL/TLS把明文变密文、把身份验证起来、把完整性校验加上三个问题一起解决。4.2 HTTP/1.1长连接救了场队头阻塞又拖后腿最早的 0.9 版本只支持 GET没有请求头服务器只能返回 HTML。1.0 是第一个正式版本引入了请求头和响应头支持多种方法和状态码但有个硬伤不支持持久连接每个请求都要重新建一次 TCP 连接。想想一次握手要几个往返一个页面又有几十个资源这个开销有多大。1.1 最重要的改进就是长连接。只要客户端和服务器任意一端没有明确提出断开TCP 连接就保持住后续请求接着用。这一下省掉了大量重复握手的成本。它还提出了管道化在同一个连接里客户端发完第一个请求不必等响应就可以把第二个请求也发出去。听起来很美好但服务器必须按接收顺序返回响应如果第一个请求处理得慢后面的全被堵住这就是队头阻塞。所以准确地说1.1 的管道化解决了请求侧的队头阻塞没解决响应侧的。而且管道化在实际中并没有默认开启浏览器基本都不支持它——这是一个典型的书上写了、现实里没落地的知识点答的时候如果只背1.1 有管道化很容易被追问到卡壳。1.1 剩下的问题还有几个头部冗余每个请求都带一堆重复的头部字段浪费带宽响应必须按请求顺序来前面慢后面就等着没有请求优先级控制重要的请求和次要的请求排一样长的队请求只能由客户端发起服务器没法主动推东西。4.3 HTTP/2把文本换成二进制用 Stream 做并发HTTP/2 建立在对 1.1 的兼容之上同时从几个方向一起下手。头部压缩用的是 HPACK 算法由三部分组成静态表、动态表和 Huffman 编码。静态表把高频出现的头部字段和值预先编号写死在协议里一共 61 组不会变。客户端和服务器各自维护一份发送时不再传字符串只传索引号长度从十几个字节压到一个字节。动态表则针对同一条连接上重复出现的头部第一次传完整内容后续只传索引。Huffman 编码负责把剩下的字面量再压一遍。# HPACK 静态表节选示意非完整表 static_table { 1: (:authority, ), 2: (:method, GET), 3: (:method, POST), 4: (:path, /), 5: (:path, /index.html), 6: (:scheme, http), 7: (:scheme, https), # ... 共 61 组 } def encode_header(name, value): # 命中静态表时只发索引号1 个字节搞定 # 未命中则先查动态表再不行才用 Huffman 编码发字面量 for idx, (n, v) in static_table.items(): if n name and (v value or v ): return idx return None这段示意代码只说明一件事压缩的本质是用编号代替字符串。真实实现要复杂得多但理解到这个程度就够答题了。动态表有个前提必须在同一条连接上重复传输完全相同的头部否则建不起来。而动态表越大会占用越多内存服务器性能会受影响所以常见的 Web 服务器都提供类似http2_max_requests的配置限制一条连接上能传多少个请求到上限就关闭连接释放内存。这个参数名值得记一下它能把你从背概念拉到知道实际部署时怎么权衡。第二个改进是二进制帧。1.1 的报文是纯文本解析起来要处理各种分隔符和大小写2.0 把数据切成二进制帧用位运算就能高效解析。协议定义了十种帧类型大致分两类头信息帧装压缩后的头部数据帧装包体。每个帧带一个流标识符标明它属于哪条流接收方靠这个 ID 把乱序到达的帧重新拼回完整消息。第三个是并发传输也是 2.0 最核心的设计。这里有三层概念要分清Stream 是一条逻辑上的双向通道Message 是一次完整的请求或响应Frame 是最小的传输单位。一条 TCP 连接上可以跑多个 Stream每个 Stream 有唯一 ID不同 Stream 的帧可以乱序发送接收端再按 Stream ID 组装。这样一来应用层的队头阻塞就解决了——某个请求慢不会挡住别的请求。第四个是服务器推送。客户端请求 HTML 时服务器可以主动把 CSS 一起推过去省掉一次往返。这个功能听起来很美但实际收益要看场景推错了反而浪费带宽所以后来的实践中用得比较克制。HTTP/2 还有流控制、流状态、依赖关系等机制都属于更细的层面。但 2.0 并没有彻底解决队头阻塞只是把战场从应用层挪到了传输层。TCP 是字节流协议它必须保证收到的字节完整且连续内核才会把数据交给应用。只要前面有一个字节没到后面收到的数据只能先堆在缓冲区里等着。对于 HTTP/2 来说这意味着一条连接上所有 Stream 的数据都被同一个 TCP 连接捆在一起一个包丢了所有流一起等。用得越激进——连接复用得越彻底——这个问题的杀伤力越大。4.4 HTTP/3问题出在 TCP那就换掉 TCP既然队头阻塞的根子在 TCP 的有序字节流那最彻底的解法就是不动 HTTP 的语义只换底下的传输方式。HTTP/3 把 TCP 换成了基于 UDP 的 QUIC。UDP 本身不可靠、不保序听起来是倒退但正因为如此可靠性可以在用户态重新实现而且实现得更聪明QUIC 在传输层就实现了按流独立的可靠传输一条流丢包只影响这一条流其他流照常交付。这就在传输层解决了 HTTP/2 遗留的队头阻塞。QUIC 还把加密握手和传输握手合并减少了建立连接的往返次数重连时甚至可以做到零往返。这对移动网络下频繁切换网络、反复重连的场景意义很大。代价是 UDP 在一些网络环境里会被限制或限速这让 HTTP/3 的实际部署比理论上的推进慢一些。但只要理解了换掉 TCP 是为了摆脱字节流的强顺序约束这一层剩下的细节都可以顺着推出来。4.5 四个版本放在一起看版本连接方式主要改进遗留问题HTTP/1.0每次请求新建连接引入请求头、响应头、状态码连接开销极大HTTP/1.1长连接持久连接、管道化实际未普及响应侧队头阻塞、头部冗余、无优先级HTTP/2单连接多 Stream头部压缩、二进制帧、并发、服务器推送TCP 层队头阻塞HTTP/3QUIC over UDP按流独立可靠传输、握手往返更少部分网络对 UDP 有限制5. 易混概念排查五个最容易背串的知识点5.1 误区一握手三次、挥手四次记住数字就够了易混点在于很多人把3和4当成两个需要硬背的常量却不知道它们从哪来一追问就露怯。会混是因为这两个数字太短、太好记口诀一背就过去了。真正的区分点是能不能合并。握手时服务端要回两件事确认收到对方的 SYNACK以及发出自己的 SYN。这两件事没有先后依赖可以塞进一个报文所以是三次。挥手时服务端收到客户端的 FIN只能先回 ACK 表示收到因为它可能还有数据没发完等数据发完才能发自己的 FIN这两个动作有先后顺序不能合并所以是四次。记住能不能合并比记住数字稳得多。5.2 误区二HTTP/1.1 的队头阻塞和 HTTP/2 的队头阻塞是一回事名字一样位置完全不同。1.1 的队头阻塞发生在应用层响应必须按请求顺序返回前面慢后面全等。2.0 把这个问题解决了因为不同 Stream 的帧可以乱序发、乱序收。但 2.0 又冒出一个新的多个 Stream 复用一条 TCP 连接TCP 要求字节有序前面缺一个字节后面所有流的数据都卡在内核缓冲区里。会混是因为两者都叫队头阻塞而且都表现为后面的请求被前面的拖住。区分的方法看层级1.1 卡在响应的顺序2.0 卡在字节的顺序。前者靠 Stream 复用解决后者只能靠换掉 TCP 解决这也是 HTTP/3 存在的全部理由。顺带说一句1.1 的管道化常常被误认为解决了队头阻塞。它只解决了请求侧——请求可以先发出去但响应侧仍然严格按序问题依然存在而且浏览器基本没实现它。这条血泪经验值得记住协议里写了不等于现实里能用。5.3 误区三递归查询和迭代查询只是叫法不同这两个概念的字面意思太接近很容易混成都是查询的两种说法。真正的区别是谁在干活递归是委托方跑完全程最后给你一个确定答案迭代是你自己一站站问每次只拿到下一站的地址继续问。之所以会混是因为在完整的 DNS 解析链路里这两种方式同时存在而且衔接得很自然。客户端到本地 DNS 是递归——你只发一次请求本地 DNS 负责把结果找回来本地 DNS 到根、顶级、权威是迭代——它每问一次拿到一个更具体的去处再自己接着问。把角色和环节对上号就不会再串。5.4 误区四强缓存和协商缓存都是缓存所以差不多差别在于谁说了算。强缓存是浏览器自己判断看Cache-Control的max-age或者老一点的Expires在有效期内直接读本地一个请求都不发开发者工具里显示的是 from disk cache 或 from memory cache。协商缓存是浏览器拿不准带着If-None-Match或If-Modified-Since去问服务器服务器比对之后回 304 表示还能用或者回 200 加新内容。会混是因为两者最终效果都是用了本地的东西但过程完全不同一个不发请求一个发了请求但可能只回一个头部。区分的关键看有没有和服务器发生一次往返。另外要留意Expires是绝对时间受客户端时钟影响Cache-Control是相对秒数更可靠这也是后者逐渐取代前者的原因。做发布上线时遇到用户看到的还是旧版本第一件事就是查这两个头部的配置。5.5 误区五HTTP 无状态所以它也不保持连接这是两个被中文翻译搅在一起的词。无状态说的是 HTTP 协议本身不记录请求之间的上下文服务器处理完一个请求就把这个请求忘了下一次请求对服务器来说都是全新的。这跟 TCP 连接有没有被复用完全是两码事。HTTP/1.1 引入了长连接一条 TCP 连接可以承载很多次 HTTP 请求但 HTTP 依旧是无状态的——服务器不会因为连接还在就记得你上一次请求问了什么。要维持这个人已经登录了这种状态得靠 Cookie、Session、Token 这些额外机制。把连接和状态分开看这一整块就不会再糊涂。6. 什么时候该翻这份计算机基础资料什么时候别指望它判断标准其实很清楚它解决的是概念讲不清、答题没结构的问题不解决动手做不出来的问题。先看适合的情况。如果你正在准备技术面试尤其是后端或前端的岗位网络这块是绕不开的三次握手、四次挥手、HTTP 各版本、DNS 解析这几块几乎每场都会碰到那这份资料的组织方式就很对口——它把高频重点和细碎知识点分成两块重点区把复杂过程拆开讲一问一答区补上边角料你答完主干还能顺手补两句细节。如果你已经能背下名词但被追问为什么就卡住那更适合因为它重点铺的就是过程和图解不是名词清单。再看不适合的情况。如果你想学抓包实操、想看真实网络请求怎么分析这份资料帮不上忙它偏讲解不偏动手你得自己去开浏览器开发者工具。如果你要深入 TCP 拥塞控制、滑动窗口的算法细节那属于另一个专题这里只会带到门口。如果你的目标是学某个框架或者背某门语言的语法方向也完全不同——这是计算机基础的整理不是语言教程。你的处境适不适合原因面试在即网络概念答不成句适合按链路组织能直接转成答题结构背得出名词答不出为什么适合重点讲过程与因果不是名词表想练抓包和真机调试不适合偏概念讲解不含实操步骤想深挖 TCP 算法与内核实现不适合只覆盖到面试所需的深度想系统补一门语言的语法不适合属于计算机基础范畴不是语言教程给自己一个更具体的用法建议先拿输入网址到页面出现这道题当索引从头默讲一遍讲不顺的地方就是当天的复习清单翻到对应章节把那一段读透再回来重讲一次。这样过一遍比顺着 PDF 从头读到尾效率高得多因为你是按自己的漏洞在补不是按目录在扫。我自己的习惯是这样来的早些年准备面试我贪多把资料从头翻到尾合上之后脑子里只剩一堆零散的词被问到为什么三次不是两次当场愣住那次的结果不太好看。从那以后我每次准备面试都强制自己先把那条七步链路默写一遍写不出来的地方标红只补标红的那几段其他的先放着。这么干了几轮之后我发现能讲清楚一条完整链路比背下十个孤立的概念管用得多——面试官要的从来不是你知道多少名词而是你能不能在一条线上把它们串起来讲明白。这份计算机基础篇是九份整理稿里的一册网络部分占了大头DNS、HTTP 各版本、缓存机制都在里面配合另外几册一起看覆盖面会更完整。如果你正卡在知道有这回事但讲不清的阶段把它存下来按上面这条链路的顺序过一遍比零散地搜答案省力。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
