
简介计算机基础知识是程序员面试的高频考点尤其计算机网络部分更是必问内容。这份《计算机基础.pdf》源自代码随想录知识星球精华“最强八股文”第五版系统梳理了TCP三次握手与四次挥手、HTTP/HTTPS区别、DNS域名解析、HTTP缓存机制等核心知识点并逐步拆解在浏览器输入URL后发生的完整流程从URL解析、DNS查询到TCP连接、请求发送、页面渲染直至断开连接。内容采用高频重点讲解与一问一答结合的形式既深入剖析原理也补充容易被忽略的细碎考点DNS部分还专门对比了递归查询与迭代查询、集中式与分布式设计等引申问题。资源包内共1个PDF文件压缩包大小37.83MB适合后端、前端开发者和准备校招/社招的求职者快速复习、查漏补缺。已有777人学习下载是一份高浓缩、可直接查阅背诵的计算机基础面试复习手册。1. 眼前的“八股文”是什么计算机网络凭什么成了面试硬通货为什么面试官那么爱问“在浏览器里输入URL并按下回车后会发生什么”因为这一道题几乎能把计算机网络六成以上的考点串起来DNS解析、TCP三次握手、HTTP请求与响应、浏览器渲染、四次挥手。计算机网络不像操作系统那样靠“背命令”就能应付它是理科里的理科——每一个结论都必须建立在推导过程上面试官最擅长的就是沿着你的回答一路追问“为什么”。所以你会发现真正能把计网答好的人从来不是死记硬背的而是脑子里有一张完整的链路图。很多备考的人把这类资料叫“八股文”觉得背结论就行。可实际面试里面试官问“为什么握手要三次、挥手要四次”“第一次握手丢了怎么办”“三次握手能不能携带数据”时只背结论的人会立刻卡壳。这份《计算机基础》PDF的做法是把高频题拆成“超高频重点区”和“一问一答区”重点区先把过程讲透、画清楚问答区再补充那些细碎但可能被问到的知识点。你先看懂过程再背要点而不是对着八股文硬记——这是它和普通面试题集最不一样的地方。2. 输入URL回车之后一道题串起半本计网的七步把“输入URL回车”这件事拆开大约七个步骤URL解析、DNS域名解析、TCP三次握手、发送HTTP请求、服务器处理并返回、浏览器渲染页面、TCP四次挥手。这道题是面试官公认的“超高频题”答得好可以把话题引导到你更熟悉的模块答不好就会一直被追问到哑火。下面一步步走每一步都标出它能引出的典型追问方便你心里有数。2.1 前三步URL解析、DNS查询、三次握手第一步URL解析。浏览器拿到你输入的地址先拆出协议、主机、端口、路径、查询参数这些信息然后构造一个HTTP请求。这里面有个很多人忽略的细节请求构造出来之后浏览器并不会立刻把它发到网络上而是先判断HTTP缓存——如果命中强缓存这次请求直接就用本地副本了根本不会走到服务器。这一步是后面理解HTTP缓存机制的入口面试官从“回车那一刻发生了什么”切入缓存问题是很常见的操作。第二步DNS域名解析。浏览器需要知道这个域名对应的IP地址才能发起连接。它会先查浏览器缓存再查本地Hosts文件接着问本地DNS服务器再一路问到根DNS、顶级域DNS、权威DNS。完整过程会在下一章展开这里你只需要记住这是一条“从近到远、逐级向上”的查询链路。第三步TCP三次握手。HTTP请求要可靠传输得先建立TCP连接。客户端发SYN服务器回SYNACK客户端再回ACK。为什么是三次而不是两次因为第二次握手只能让客户端确认“服务器收到了我的请求、服务器愿意建立连接”但服务器自己并不确定“客户端是否收到了我的回复”——第三次握手就是给服务器吃定心丸。面试官的经典追问是“第三次握手能不能携带数据”答案是可以因为此时双方都已确认连接可用数据可以捎带在ACK里。2.2 后四步请求、响应、渲染、挥手第四步浏览器发送HTTP/HTTPS请求。请求由请求行、请求头和请求体组成请求行里带着方法GET、POST、PUT、DELETE、路径和协议版本。这里能扩展的问题很多GET和POST有什么区别GET能不能带请求体注意别回答“GET不能带请求体”协议本身没有禁止只是约定俗成不这么用。回答时把“规范允许”和“实践惯例”分开说反而显得你理解得准。第五步服务器处理请求并返回HTTP响应。响应报文包含状态码、响应头、响应体。状态码是常考内容200表示成功301/302是重定向304表示协商缓存命中还可以继续用旧资源404是找不到500是服务器内部错误。响应头里的Cache-Control、Content-Encoding、Set-Cookie等字段也是从这一步延伸出的高频考点。第六步浏览器渲染页面。前端岗位必问。HTML被解析成DOM树CSS被解析成CSSOM两者合并成渲染树然后布局、绘制。这个过程里最常考的是“回流和重绘的区别”回流重排是布局变化触发的重新计算比如改了窗口大小、增删DOM重绘是样式变化但布局不变时的重新绘制比如改了颜色。回流的成本比重绘高得多因为要重新计算几何信息。第七步断开连接之TCP四次挥手。客户端发FIN服务器回ACK服务器再发FIN客户端最后回ACK。为什么要四次关键在于服务器第一次回的ACK只代表“我收到你的关闭请求了”但服务器可能还有数据没发完要等自己的数据全部发完才能再发一个FIN表示“我也说完了”。全双工的通道两边各关一次自然就是四次。2.3 一个容易被漏掉的细节HTTP缓存发生在所有请求之前很多人在答这道题时从URL解析直接跳到“浏览器发请求”中间漏掉了缓存判断。实际上浏览器构造完请求后要做的第一件事是问自己“这个东西我本地有没有”判断依据是响应头里的Cache-Control如果强缓存还没过期浏览器直接用本地缓存地址栏甚至可能显示“200 from cache”这次请求根本不出门。如果强缓存过期了就进入协商缓存流程带上If-None-Match或If-Modified-Since去问服务器服务器看资源没变就回304变了就回200带新资源。提示强缓存和协商缓存是HTTP缓存的两个阶段后面第5章会专门辨析它们的字段和适用场景这里先记住它们发生的时间点——强缓存发生在发请求之前协商缓存发生在发请求之后。把这一步补上整道题的链路就从“请求—响应”升级成了“缓存判断—请求—响应—渲染”面试官会明显觉得你不只是在背流程而是真的理解浏览器是怎么工作的。答完这条链路你甚至可以主动说“顺着缓存这边还能聊到强缓存和协商缓存的区别”——直接把面试官往你准备好的方向带这就是这道题最值钱的用法。3. DNS到底在忙什么互联网的分布式通讯录你记住一个域名记不住一串IP这是DNS存在的全部理由。但DNS不只是“域名翻译器”它是一整套分布式的全球数据库系统。要真正理解DNS得先回答一个问题为什么它必须是分布式的面试官问DNS很少只问“DNS是什么”更多会从“为什么要这样设计”切入。3.1 集中式DNS的三个致命问题如果整个互联网只有一台DNS服务器把全世界所有域名和IP的映射都存进去会发生什么首先是单点故障这台服务器一旦崩溃整个网络跟着瘫痪。其次是通信容量全球的DNS查询量级是千万级甚至上亿级一台服务器根本处理不过来。再次是远距离延迟单一服务器不可能邻近所有用户一个在美国的服务器无法让其他地区的用户快速查询查询请求经过低速拥堵链路时延会非常严重。最后还有维护成本所有人都往同一台服务器更新域名记录维护和同步的工作量是不可想象的。打个比方你就明白了这就像全国只有一张身份证登记表放在一个房间里。表丢了全国人民都没法办事所有人都跑同一个窗口排队住在远处的人为了查一条记录得跨省跑一趟更别提每天成千上万条新记录要更新工作人员根本忙不过来。所以DNS必须是分散的、分层的——把登记表拆成无数个小本子放到全世界各个角落。3.2 域名层级和DNS解析八步域名是用句点来分隔层级的www.server.com这个域名里com在最右侧表示顶级域server是二级域www是三级域。越靠右的层级越高查询的时候却是从最高层一层层问下来的。面试时能画出这个层级关系就已经赢了一半。DNS解析的整体过程可以拆成八个步骤浏览器先查自己的缓存里有没有这个域名对应的IP没有的话查计算机本地Hosts文件还没有就向本地DNS服务器发查询请求——这个服务器通常由你的互联网服务提供商ISP提供本地DNS服务器如果也没有缓存就向根DNS服务器查询根DNS服务器不负责具体解析但它会告诉你“该去找哪个顶级域DNS服务器”本地DNS接着向顶级域DNS服务器查询顶级域服务器再告诉它“该去找哪个权威DNS服务器”本地DNS最后向权威DNS服务器查询权威服务器存着这个域名和IP的真实映射给出最终答案本地DNS把IP返回给浏览器同时把结果缓存下来下次访问就直接返回。为方便记忆这三类服务器的分工可以这样理解服务器类型负责什么根DNS服务器不解析具体域名只指向顶级域服务器顶级域DNS服务器不解析具体域名只指向权威服务器权威DNS服务器存有域名和IP的真实映射给出最终答案面试中问到“DNS解析过程”你能按这八步答出来并且每步都说出“谁在问谁、谁给了什么答案”这道题基本就过关了。最常见的错误是只答“浏览器→DNS→IP”就结束了丢失了本地DNS服务器和根服务器这两个关键角色面试官一听就知道你没真正查过。3.3 递归查询和迭代查询谁在替你跑腿递归查询和迭代查询是DNS解析里最容易被搞混的一对概念因为它们在同一条链路上出现都在“一层层往上问”。区分方法很简单看跑腿的人是谁。递归查询里跑腿的是上层服务器。DNS客户端向本地DNS服务器发一个查询请求本地DNS服务器自己一路去问根服务器、顶级域服务器、权威服务器最后把完整结果直接交给客户端。客户端从头到尾只发了一次请求剩下的全是别人代劳。迭代查询里跑腿的是客户端自己。客户端问当前服务器“下一步该找谁”服务器返回一个更高级的服务器地址客户端再自己去问那个更高级的服务器一层层往上走直到拿到完整解析结果。每一步都是“一问一答”没有谁替你完成任务。一条准确的速记客户端对本地DNS服务器发起的是递归查询本地DNS服务器对根、顶级、权威服务器发起的是迭代查询。面试时把这个关系一句话说清——“我对本地DNS发起递归查询本地DNS替我逐级迭代”—面试官基本不会再追问方向性的问题。4. HTTP的进化之路从1.0到3.0每一代在补什么坑HTTP是浏览器和服务器之间“对话”的规则。面试考HTTP很少考某条报文怎么写更多是考整个演变逻辑——因为每一代版本的出现都是为了解决上一代留下的痛点。沿着“1.0 → 1.1 → 2.0 → 3.0”这条线讲下来你能自然带出长连接、管道化、队头阻塞、头部压缩、二进制帧、服务器推送这些考点。4.1 HTTP的基础特征无状态、明文、不安全先看HTTP本身。它的特性可以概括为简单、灵活、易于扩展、应用广泛、跨平台。简单是指报文格式就是header加body头部是key-value形式的纯文本容易理解灵活是指请求方法、URI/URL、状态码、头字段这些都没有被写死允许开发人员自定义和扩充扩展性强是因为它工作在应用层下层协议可以根据需要替换——HTTPS就是在HTTP和TCP之间插入了SSL/TLS层HTTP/3则把TCP直接换成了基于UDP的QUIC。这三个优点的代价也很大。第一是“无状态”服务器不会记住HTTP的状态不需要额外资源记录信息减轻了负担但完成有关联性的操作时非常麻烦。解决方案之一是Cookie技术通过在请求和响应报文中写入Cookie来控制客户端状态。第二是“明文传输”F12控制台或者Wireshark抓包能直接肉眼看到报文内容调试方便但信息透明容易被窃取。第三是“不安全”通信不加密内容可能被窃听不验证通信方身份可能遭遇伪装无法证明报文完整可能已被篡改。这三个问题就是后来HTTPS要解决的三个核心方向。4.2 HTTP/1.1长连接、管道化以及它救不了的队头阻塞HTTP/0.9是1991年的老古董只支持GET方法没有请求头服务器只能返回HTML格式的内容。HTTP/1.0作为第一个正式版本引入了请求头、响应头、多种请求方法和状态码但有一个致命短板不支持持久连接每次请求都要重新建立TCP连接三次握手的开销被重复支付。HTTP/1.1的核心改进是“长连接”只要客户端和服务器任何一端没有明确提出断开TCP连接就保持住后续请求复用同一条连接。在此基础上又提出了“管道化网络传输”同一个TCP连接里客户端可以先发A请求不等A响应就接着发B请求减少整体响应时间。听着很美好但服务器必须按接收请求的顺序返回响应——如果A请求处理得很慢排在后面的B请求哪怕处理好了也得干等这就是“队头阻塞”。而且管道化不是默认开启的浏览器基本都没有支持它是个实际应用价值有限的历史方案。版本连接方式多个请求的处理主要痛点HTTP/1.0短连接一个请求一个连接每次都要重新握手HTTP/1.1长连接管道化请求但按顺序响应响应端队头阻塞、头部冗余HTTP/2.0长连接多Stream并发传输传输层仍受TCP队头阻塞HTTP/3.0UDPQUIC多Stream并发协议复杂度高普及度有限HTTP/1.1还有几个没法回避的问题头部冗余每次请求和响应都重复携带相似的头部信息白白浪费带宽没有请求优先级控制请求只能从客户端发起服务器只能被动响应。为了改善这些性能问题业界想了很多“外部优化”比如合并小图片、拆分多个域名、上CDN但都是补丁式的治标不治本。真正从协议层面动手的是HTTP/2。4.3 HTTP/2到底改了什么头部压缩、二进制帧、并发Stream、服务器推送HTTP/2是基于HTTPS的安全性有保障。它做了四件大事。第一件头部压缩。压缩算法叫HPACK由三部分组成静态字典、动态字典、Huffman编码。客户端和服务器各自维护一张字典用长度较短的索引号来表示重复出现的字符串高频出现的头部字段和字符串在静态表里直接查索引动态表则记录同一连接上重复传输的相同头部再配合Huffman编码进一步压缩数据。注意一个前提动态表只有在“同一个连接上重复传输完全相同的HTTP头部”时才生效。动态表越大会占用越多内存影响服务器性能所以Web服务器一般会配置请求数上限来限制动态表无限增长请求数到上限后关闭连接以释放内存# 限制单条 HTTP/2 连接上可传输的最大请求数 # 超过这个数会关闭连接释放动态表占用的内存 http2_max_requests 1000;这个配置是Web服务器层面对HTTP/2动态表内存风险的实际约束面试时提到它能说明你不只看了理论还知道落地时的代价。第二件二进制帧。HTTP/1是文本格式用空格和换行分隔解析依赖字符串匹配效率低HTTP/2把数据改成二进制帧传输位运算就能高效解析。HTTP/2总共定义了10种类型的帧分为数据帧和控制帧两大类。每帧带有流标识符Stream ID接收方根据Stream ID从乱序到达的帧里找到属于同一个消息的帧再有序组装成完整的HTTP消息。第三件并发传输。HTTP/2引出了Stream概念多个Stream复用一条TCP连接每个HTTP请求用唯一的Stream ID区分。不同Stream的帧可以乱序发送所以多个请求和响应可以并行交错接收端通过Stream ID有序组装——HTTP/1.1那里“必须按顺序响应”的队头阻塞基本被解决。三个概念的关系是一条TCP连接上跑多个Stream一个Stream对应一个HTTP消息Message一个Message由多个帧Frame组成。注意每个帧又可能由多个TCP报文构成。第四件服务器推送。HTTP/1.1里客户端请求HTML服务器只能回HTMLCSS要等浏览器解析到引用了再发第二次请求HTTP/2里服务器可以对一个请求发送多个响应在返回HTML的同时主动把CSS、JS推给客户端减少消息往返次数。但HTTP/2没有彻底消灭队头阻塞只是把问题“上移”到了传输层。它依然是基于TCP传输的TCP是字节流协议内核必须保证接收到的字节数据完整且连续才会把缓冲区数据交给HTTP应用层。如果前一个字节没到后面收到的字节就只能在内核缓冲区里等着HTTP/2应用层拿不到数据——这就是TCP层面的队头阻塞。要根治只能换掉TCP于是HTTP/3登场。4.4 HTTP/3换掉TCP直接骑在UDP上HTTP/3的思路极其直接既然队头阻塞的根子在TCP那就把TCP换成UDP。UDP本身不保证可靠传输但HTTP/3在UDP之上实现了QUIC协议在用户态自己搞定可靠性、流量控制和拥塞控制。更关键的是QUIC遇到丢包只重传丢失的那一段其他Stream的数据不受影响、照常传输。以前TCP里“前1个字节不到后面的全部堵住”的场景在HTTP/3里彻底消失。代价是QUIC协议复杂度大幅提升目前普及度还在路上。面试答题时把HTTP/3说成“基于QUIC的HTTPUDP之上的可靠传输彻底绕开TCP队头阻塞”就够用了不必深入到QUIC的握手细节。5. 面试最爱考的易混辨析考场上翻车的高发区有些概念成对出现背的时候觉得差不多考场上一紧张就混成一锅粥。下面这几组是我见过翻车率最高的每一组按“哪里像、为什么混、怎么分清”过一遍。5.1 三次握手 vs 四次挥手易混点都发生在TCP连接的过程里都是“一来一回”式的报文交换经常被串成“为什么不是四次握手”“为什么要三次挥手”。为什么混握手和挥手都涉及SYN、ACK、FIN这些标志位报文结构相似建立的连接又都是同一条TCP连接时间一久容易记岔。怎么区分核心在于“全双工通道的两边要各自关闭”。建立连接时双方状态清楚客户端发了SYN服务器确认、也发起自己的SYN客户端再确认一次三次把双向通道都激活就够了。断开连接时客户端发FIN只代表“我这边说完了”服务器回ACK是告诉它“我收到你的关闭请求了”但服务器可能还有数据没发完等数据发完服务器再发自己的FIN客户端回ACK确认——每一次FIN都代表一边通道的关闭两边各一次所以是四次。一句话记忆握手是“双方都没说过话一次确认就能同时确认两边”挥手是“两边可能都在说话得分开告别”。5.2 HTTP vs HTTPS易混点名字只差一个S都是传网页的协议工作流程看起来都是“请求—响应”。为什么混两者都叫超文本传输协议HTTP请求的报文格式在HTTPS里也一样导致很多人觉得HTTPS只是“加了个锁”。怎么区分HTTP是明文传输报文内容可以直接抓包看到HTTPS是HTTP加上SSL/TLS安全传输层端口也从80变成443。这个“S”做的三件事恰好对应HTTP的三个安全隐患加密内容防止窃听证书验证身份防止伪装完整性校验防止篡改。面试答“HTTPS为什么安全”时落脚点要放在SSL/TLS层——它通过证书验证服务器身份再通过握手协商出一个对称密钥后续所有数据都用这个密钥加密传输。5.3 递归查询 vs 迭代查询易混点都出现在DNS解析过程里而且都在“一层层往上问”。为什么混描述的是同一条DNS查询链路术语又长得像很多人以为是一回事的两种叫法。怎么区分看跑腿的人。递归是服务器代劳——客户端向本地DNS发一次请求本地DNS自己一路查完把最终结果交回来客户端全程只等结果迭代是客户端自己跑——每问一个服务器对方只告诉“下一步该找谁”客户端再亲自去问下一家最后自己拼出完整答案。加一条速记客户端对本地DNS是递归本地DNS对根、顶级、权威是迭代。5.4 强缓存 vs 协商缓存易混点都叫HTTP缓存都能让下一次访问变快响应头里的字段长得也像。为什么混Cache-Control、Expires、ETag、Last-Modified这些字段堆在一起没分清哪些管“直接用”哪些管“先问一下再用”。怎么区分强缓存不用发请求浏览器自己看Cache-Control的max-age有没有过期没过期直接取本地副本状态码显示200 from cache协商缓存必须发请求带着条件去问服务器“这个资源变了吗”——If-None-Match对应ETagIf-Modified-Since对应Last-Modified服务器说没变就回304继续用旧资源变了就回200带新资源。想要验证一个网站的缓存策略一条命令就能看出端倪# 查看资源的响应头判断它走的是强缓存还是协商缓存 curl -I https://example.com # 关注 Cache-Control强缓存过期时间、ETag协商缓存标识、Last-Modified 字段缓存策略上强缓存胜在快零网络请求协商缓存胜在新鲜每次都会确认资源是否过期。两者可以同时存在强缓存先拦截过期后再走协商缓存。实际线上资源多数是“强缓存一年 协商缓存兜底”的组合。5.5 管道化 vs HTTP/2并发易混点都是在一条TCP连接上同时处理多个请求描述的都是“复用连接”。为什么混HTTP/1.1管道化和HTTP/2都谈“多请求复用同一个TCP连接”如果不了解实现细节很容易当成同一个东西。怎么区分管道化是“假并发”。它做到了同时发出请求但服务器必须按接收顺序返回响应只要前面一个请求处理慢了后面的响应全部排队且浏览器基本都不支持这个特性。HTTP/2是“真并发”。它用Stream ID区分不同请求不同Stream的帧可以乱序发送响应也可以乱序返回接收端靠Stream ID把它们重新组装起来。一句话记忆管道化是单车道顺序排队HTTP/2是多车道并行分流。6. 这份资料什么时候用面试前两周和前两天各有各的用法先说什么时候用。最适合两种情况一种是时间紧、网上教程太散、不知道背什么的人——这份PDF已经把超高频题单独圈出来URL回车、三次握手、四次挥手、HTTP缓存、DNS解析是现成的背诵路径另一种是已经有基础、想“过一遍八股”查漏补缺的人——重点看一问一答区快速扫那些零散的知识点。方法上我建议把“超高频重点区”的每一道题都当成画图题三次握手画一张时序图四次挥手画一张时序图URL回车画一条从上到下的链路图。能画出来就是真懂画不出来就回头看讲解再画第一天画图第二天只记关键术语和数字。这个“高频重点区打底 一问一答区补漏”的组合就是这份资料最标准的用法。再说什么时候别用。不推荐给三类人完全没学过计算机网络的人术语都看不懂直接背八股等于闭眼背字典想研究协议源码和实现细节的人资料定位是面试背诵材料不是源码导读岗位根本不考察网络基础的人投入产出比太低不如把时间花在更有用的方向。记住它是备考地图不是教科书更不是手册。第一次面试时我自信满满地把“为什么挥手要四次”答成“因为TCP是全双工”面试官接着问了一句“那握手也是全双工为什么要三次”我当场愣住。后来才想明白问题出在只背了“全双工”四个字没把它拆成“两个方向的通道各自独立关闭”。从那以后我每次备考计网都强制走一遍“先画图、再解释每一个数字为什么是这个数”的习惯——能把3和4解释清楚才算真正过了这关。希望这份资料也能帮到你。本文还有配套的精品资源点击获取