简介计算机基础.pdf 是一份面向程序员、前端/后端开发者及面试求职者的计算机基础知识点整理文档内容聚焦计算机网络与浏览器工作流程两大板块能帮助读者高效备战技术面试、跳槽复习与日常查漏补缺。文档系统梳理了 TCP 三次握手与四次挥手、HTTP 与 HTTPS 协议区别、DNS 域名系统层级结构与递归/迭代查询、HTTP 缓存机制强缓存与协商缓存等高频考点并逐步骤拆解「在浏览器输入 URL 并回车后发生什么」这一经典问题覆盖 URL 解析、DNS 查询、TCP 连接建立、HTTP 请求发送、服务器响应、浏览器渲染、四次挥手断开连接等环节。资源包共 1 个 PDF 文件大小 37.83MB内容源自代码随想录知识星球精华最强八股文计算机基础篇结构清晰、适合离线学习。已有 777 人学习下载适合准备后端/前端面试、系统复习计算机网络基础或希望借助八股问答形式快速巩固核心知识点的读者。1. 输入URL按下回车一个请求背后藏着整个协议栈的设计密码当你在浏览器地址栏敲下一串URL并按下回车从按下那一刻到你看到页面首屏内容中间要经历一次域名解析、一轮TCP三次握手、一次HTTP请求/响应、一次浏览器渲染、最后再四次挥手断开连接。这个过程里的每个环节都是面试官最爱追问的“八股”也是线上问题排查时最容易让人翻车的隐蔽角落。这些问题的答案背后藏着一个共同的设计主线网络既要快又要可靠而这两者天然互斥。三次握手为什么不能是两次四次挥手为什么少一次都不行DNS为什么非要搞出根、顶级域、权威服务器这么多层级HTTP花了二十年从1.0演进到3.0到底在解决什么——拆开看都是同一道设计取舍题在不同层给出的答案。这份解读源自某技术社区知识星球整理的计算机基础面试精华合集我把其中网络相关的高频问题按“现象→机制→实现细节”重新组织让你既能在面试追问下沉着应答也能在排查真实连接问题时多一层判断力。2. TCP三次握手与四次挥手为什么建立要三次、断开要四次2.1 三次握手确认的不只是“你在线”而是双方的收发能力TCP的可靠性建立在一个前提上双方都明确“对方能收、自己能发”。三次握手表面上只是交换三个报文段本质上是一次双向收发能力探测。第一次握手客户端发送SYN报文携带初始序列号seqx然后进入SYN_SENT状态。这一条报文到达服务端后服务端只能确认一件事客户端的发送通路是通的。客户端此刻什么都不知道它不确定SYN有没有被服务端收到连自己的发送能力都没有被确认。第二次握手服务端回复SYNACK报文携带自己的序列号seqy确认号ackx1。客户端收到后它能确认两件事第一服务端的接收通路是通的——因为服务端正确回复了x1说明收到了自己刚才发出的SYN第二服务端的发送通路也是通的——因为服务端确实发出了SYN。到这一步客户端已经确信“我和服务器之间双向都能传输了”。第三次握手客户端发送ACK报文确认号acky1。服务端收到后才最终确认客户端的接收通路是通的——因为客户端确实收到了自己的SYN并且还能正确回ACK。三次握手完成双方才都确认了彼此收发能力连接才建立。可以把每轮握手后双方掌握的信息做一个对照阶段客户端已确认服务端已确认第一次后无客户端的发送能力第二次后服务端收发能力、自己发送能力客户端的发送能力第三次后服务端收发能力、自己收发能力客户端的收发能力这也是为什么第三次握手的ACK包就算丢了连接在大多数情况下照样能用——因为客户端和服务端其实都已经具备通信条件只是服务端不知道“客户端知道自己准备好了”TCP用重传ACK的方式兜底避免连接被白建。2.2 为什么两次不行、四次浪费一次超时重传就能讲清楚如果省掉第二次或第三次握手问题立刻暴露。把建立砍成两次握手是最容易想到的“优化”客户端发SYN服务端回SYNACK连接建立。这看似省了一次往返但遇到一个经典场景就会出现严重问题客户端发出一个SYN报文在网络中滞留住客户端等不到服务端的SYNACK超时重传SYN服务端收到重传的SYN正常建立连接完成数据交换后关闭。此时网络中那个滞留的旧SYN才姗姗到达服务端——两次握手下服务端无法分辨这是一个过期的孤儿SYN还是一个新连接请求于是又分配一个连接直接造成服务端资源被无效连接浪费。三次握手恰好弥补了这个漏洞滞留的旧SYN到达服务端后服务端回复SYNACK客户端发现这个ACK的序号并不对应自己当前期望的值直接忽略不会回第三次ACK——服务端等不到这个ACK就永远不会为一个过期的SYN建立连接。至于四次握手纯属多余。第三次ACK已经让服务端确认了客户端的接收能力所有握手要达成的信息交换都已闭合第四次报文不再携带任何新信息只是白白多消耗一个RTT。TCP的实际连接建立就是“信息论意义上的最小次数”要确认双向收发至少需要三次单向信息交换。2.3 四次挥手全双工连接的对称关闭很多初学者背下“四次挥手”的流程却说不清为什么断开要四次、建立只要三次。关键差异在于TCP是全双工协议数据在两个方向上独立传输建立连接时一对SYN/ACK就能同时确认两个方向但关闭时必须为每个方向单独说“再见”。第一次挥手客户端发送FIN报文表示“我的数据发完了我这边不再发新数据了”客户端进入FIN_WAIT_1。服务端收到FIN后回复ACK进入CLOSE_WAIT状态。注意服务端此时只是确认客户端的发送方向已经关闭服务端自己可能还有响应数据没发完所以不能立刻断开自己这边的发送通道。等服务端把所有剩余数据处理完、响应报文都发出去后才发起第三次挥手服务端发送FIN报文表示“我这边也发完了”进入LAST_ACK状态。客户端收到后回复第四次ACK进入TIME_WAIT等待2MSL后连接才彻底关闭。如果服务端在收到FIN的那一刻恰好没有数据要发TCP允许在第二个报文中把ACK和FIN合并发送这样四次挥手会退化成语义上的三次挥手——但真实网络中极少这样假设因为服务端的处理时间不可控所以四次挥手才是常态。每次挥手关闭一个方向两个方向各自一FIN一ACK拼起来就是四次。2.4 细节追问初次丢包、携带数据与TIME_WAIT面试官最爱从三次握手发散追问的几个问题也恰恰是实践中踩坑最多的地方。第一次握手丢了会怎样客户端发出SYN后收不到SYNACK会基于RTO超时重传SYN默认最初会等1秒左后开始重试连续几次失败后才放弃连接同时通知上层“目标不可达”。线上如果看到大量SYN_SENT堆积多半是网络黑洞或服务端半连接队列满了而不是代码问题。三次握手过程中能携带数据吗前两次不行第三次可以。前两次握手时连接身份还没建立如果允许携带数据攻击者可以不用完成握手就往服务端缓冲区堆垃圾数据——这是经典的资源耗尽攻击面。第三次握手时双方能力已确认客户端可以直接把HTTP请求捎带在ACK里发出去省一次RTT。HTTP/1.1长连接下的首次请求、TLS握手里的False Start本质上都是这种“捎带”思想。最后一个高频追问是TIME_WAIT为什么主动断开方要等2MSL才关闭两个作用一是确保最后一个ACK如果丢失还能有足够时间重传——如果服务端没收到ACK会重发FIN客户端需要保持状态来应对二是让本连接中所有滞留在网络中的报文段在2MSL内全部过期避免它们混入下一个使用相同端口四元组的连接把脏数据带进去。2MSL不是一个拍脑袋的数字一发一收最坏情况下一个报文在单向链路走MSL其确认再走一个MSL两个最大报文段寿命相加才能保证旧报文彻底消散。3. DNS解析为什么分布式层级是唯一解3.1 集中式设计的四个致命伤先设想一个最简单的方案把全世界所有域名和IP的映射关系存在同一台DNS服务器里所有查询都打到这一台机器。这个方案看起来管理简单、查询直接但稍微推演一下就会碰壁。首先是单点故障。这台唯一服务器一挂全球域名解析全部瘫痪任何网站都访问不了这是一种比单个机房宕机更彻底的灾难——因为恢复也依赖域名解析一旦DNS不可用运维甚至无法下载工具来修复。其次是通信容量。一台服务器要处理全世界所有终端的DNS查询量级是千万级QPS起步单机根本没有这个吞吐能力。再次是远距离时延。假设这台服务器部署在某国其他地区的用户每次查询都要穿越低速的国际链路每次访问网页前都先吃几百毫秒的DNS查询延迟体验直接崩掉。最后是维护成本。域名每天都在新增、过期、变更IP新域名要登记、旧域名要删除、IP变更要同步集中式数据库的更新频率和一致性维护成本高到无法落地。这四条约束指向同一个结论DNS必须是一个分布式系统而且必须让每个地区都能就近完成大部分解析DNS的分层设计就是围绕这套约束展开的。3.2 根-顶级-权威层级结构把查询开销摊平域名用句点分隔层级越靠右的层级越高。以www.server.com为例最右的com是顶级域左侧的server.com是二级域再往左的www是主机记录。层级关系决定了查询路径而不是简单地从左往右读。整个解析链路依赖三层服务器根DNS服务器、顶级域DNS服务器、权威DNS服务器。根服务器不负责解析具体域名它只回答“com域该去找谁”顶级域服务器也不负责具体解析它只回答“server.com域该去找谁”只有权威DNS服务器才真正存储“www.server.com对应的IP是多少”这种映射记录而且每个域名所有者都要把自己域内的解析记录托管到权威服务器上。查询过程中本地DNS解析器通常由ISP提供先问根服务器“com去哪查”根服务器指向顶级域服务器再问顶级域服务器“server.com去哪查”顶级域指向该域的权威服务器最后问权威服务器拿到真正的IP。每一层的职责精准切割根服务器只需要维护13组顶级域的指针顶级域只需要维护自己域下所有二级域的指针数据量被严格控制住。根服务器虽然只有少数几组但通过任播技术在全球广泛部署用户实际访问的是离自己最近的一个节点从物理层面把查询时延压下来。3.3 递归查询与迭代查询两种哲学的分工DNS查询有两种模式递归与迭代。递归查询的特点是客户端只发一个请求然后坐等最终结果中间的层层转发全由服务器代劳。迭代查询则相反客户端被“指路”后自己逐级向下一个服务器发起新查询直到拿到最终答案。实际解析过程往往是两者配合浏览器/操作系统向本地DNS服务器发起的查询是递归式的——你问本地DNS要结果它就得给你结果而本地DNS服务器自己向根服务器、顶级域服务器、权威服务器查询时通常采用迭代方式——根服务器只告诉你下一站的地址本地DNS再自己去问。之所以这么分工是为了让资源消耗发生合理的位置普通用户和设备不维护域名系统状态递归查询把它们从复杂的查询链条中解放出来而DNS服务器之间用迭代查询每一层服务器都保持无状态只负责“指路”不承接全链路的解析压力。理解了这个分工就能理解为什么本地DNS服务器是个关键节点它既是用户递归查询的终点又是向上迭代查询的起点还承担着缓存职责——大部分热点域名的解析结果直接命中本地DNS缓存根本走不到根服务器那一层。3.4 缓存的优先级从浏览器到本地DNS一次完整的DNS解析缓存命中顺序是一个从近到远的链条。第一步查浏览器缓存。浏览器或操作系统网络栈会缓存最近解析过的域名结果TTL未过期就直接返回这个环节零网络开销。第二步查操作系统的Hosts文件。Hosts是本地静态映射表优先级很高开发者常用它来把某个域名指向测试环境IP。第三步查本地DNS服务器缓存。ISP的DNS服务器会把之前解析过的记录缓存下来大量重复访问在这里就结束了。只有各级缓存全部未命中才会进入完整的“本地DNS→根→顶级→权威”迭代查询流程。权威服务器返回结果时会带上一个TTL存活时间各级缓存按TTL控制记录保留时长TTL归零才允许重新查询。这套缓存链路的代价是“更新延迟”改了域名指向之后老的IP可能还在各级缓存里存活几十秒甚至几分钟这也是为什么线上改DNS迁移经常要等“全球生效”而不仅仅是等权威服务器更新。4. HTTP协议演进从0.9到3.0每个版本在解决什么4.1 HTTP/0.9与HTTP/1.0从“能通”到“规范”HTTP/0.9是1991年的原型版本只支持GET方法没有请求头、没有状态码、没有版本号服务器只能返回HTML格式内容谈不上通用性。1996年发布的HTTP/1.0是第一个正式版本记录在RFC1945中。它引入了请求头和响应头让客户端可以告诉服务器自己期望的格式、语言、编码方式也让服务器能返回状态码、内容类型、缓存策略等信息支持的请求方法也从GET扩展到了POST、HEAD等。但HTTP/1.0有一个致命短板不支持持久连接。每个请求都要重新建一次TCP连接三次握手加四次挥手在每次请求里都要重新走一遍连接建立的成本被摊到了每一次资源加载头上。一个包含几十个静态资源的页面URL文本解析、TCP握手、慢启动这些开销会重复发生带宽和时延的浪费相当可观。这一阶段的核心矛盾是协议已经“能用”但每次请求都重建连接效率上完全没有为真实页面复杂度做过设计。4.2 HTTP/1.1长连接、管道与队头阻塞HTTP/1.1在1997年发布它引入的第一个关键能力是长连接也叫持久连接。只要客户端和服务器任何一端没有明确提出断开TCP连接可以持续复用多个HTTP请求按顺序在同一个连接上传输省掉了重复建连的开销还顺带降低了服务端TIME_WAIT状态的堆积频率。第二个关键能力是管道化传输它允许客户端在同一个TCP连接里连续发出多个请求不必等第一个请求的响应回来就能发第二个。注意这个机制只解决了“请求”的等待没有解决“响应”的等待服务器必须按照收到请求的顺序返回响应。如果第一个请求在服务端处理耗时特别长它后面的所有响应都会被堵住这就是经典的“队头阻塞”。更要命的是HTTP/1.1管道化技术在真实浏览器中几乎没有被启用过它更多是存在于规范里的能力实际HTTP/1.1页面加载依然高度依赖多连接并发浏览器对同一个域名开6个左右TCP连接来弥补单连接串行响应的不足。除了队头阻塞HTTP/1.1还有几个伴随问题头部冗余严重——每个请求都要重复携带Cookie、User-Agent等大体积的头部字段传输效率很低没有请求优先级控制浏览器无法告诉服务器哪张图必须先渲染请求只能由客户端发起服务器无法主动推资源。这些缺陷为HTTP/2的诞生埋下了伏笔。4.3 HTTP/2二进制帧、HPACK与Stream并发HTTP/2最彻底的改动是把HTTP/1.x的文本格式换成了二进制帧。文本协议虽然可读性好但解析要靠字符串处理和边界判断效率低二进制帧用固定长度的帧头和标志位来做位运算解析快得多。每个二进制帧的结构包含帧长度、帧类型、标志位、流标识符Stream ID和帧数据一共定义了10种帧类型分为数据帧和控制帧两类。头部压缩方面HTTP/2引入了HPACK算法它由三个构件组成静态表、动态表和Huffman编码。静态表是写死在HTTP/2框架里的61组高频头部字段比如:method: GET、:status: 200这类最常见的组合直接用索引号表示一个字节就能替代几十个字节的文本动态表则记录当前连接中出现过的重复头部后续相同头部只用索引引用Huffman编码再对剩余字符串内容做压缩。动态表天生会随连接内请求数增长而膨胀占用服务器内存所以实际部署中Web服务器都有类似http2_max_requests的配置限制一个TCP连接上能处理的请求数到达上限就主动关闭连接释放动态表占用的内存。并发传输是HTTP/2的另一大核心能力。它引入了Stream概念一条TCP连接上可以同时承载多个Stream每个Stream有唯一的Stream ID不同Stream上的帧可以乱序发送、交错传输接收端靠Stream ID把帧重新组装成完整消息。一个HTTP消息由多个Frame构成一个Frame又由多个TCP报文构成Stream是消息的逻辑载体。这个设计直接解决了HTTP/1.x的队头阻塞——慢请求不再堵住后面所有响应并发的Stream各走各的。HTTP/2还支持服务器推送客户端请求HTML页面时服务器可以把CSS、JS一并主动推过来减少客户端逐个发现的往返次数。但HTTP/2的队头阻塞并没有根除只是换了个位置——它从HTTP层下沉到了TCP层。TCP是字节流协议内核必须保证收到的字节数据连续完整才把数据交给上层应用。如果一条TCP连接中前1个字节丢失了后到的所有字节——哪怕它们属于完全不同的Stream——都只能堆在内核缓冲区里HTTP/2应用层拿不到数据所有Stream一起被堵住。这就是HTTP/2最后的痛点。4.4 HTTP/3换掉传输层解决最后的队头阻塞HTTP/2的队头阻塞根源在TCP所以HTTP/3的答案很直接把TCP换掉改用基于UDP的QUIC协议。很多人听到“HTTP/3基于UDP”会误以为HTTP/3不可靠实际上QUIC在UDP之上重新实现了TCP的可靠性有序交付、拥塞控制、重传机制一个都不少而且全部移到了用户态实现修改和部署比内核里的TCP灵活得多。QUIC解决了两个关键问题。第一多路复用的独立性QUIC在协议层原生支持多个Stream并发每条Stream之间的数据传输互相独立一个Stream丢包只影响它自己其他Stream照常跑彻底绕开了TCP字节流的全局顺序约束。第二连接迁移能力TCP连接依赖四元组源IP、源端口、目的IP、目的端口网络切换比如从Wi-Fi切到蜂窝网络会导致连接断开重建QUIC用连接ID来标识连接IP变化后连接ID不变连接可以无缝迁移这对移动端场景是实打实的收益。此外QUIC把TLS加密集成到握手流程里减少了交互往返次数。从HTTP/1.1到HTTP/3的演进线可以压缩成这样一句话HTTP/1.1用长连接省连接管道化解决请求等待HTTP/2用二进制帧和Stream解决响应等待却把队头阻塞藏进了TCPHTTP/3干脆换一个传输层协议让队头阻塞物理上不存在。每一代版本的“代价”都在往更低层挪最终撞到了TCP这堵墙。5. 避坑指南TCP与HTTP实践与面试中那些答错就翻车的细节5.1 半连接队列被打满连接为何一直超时现象压测或线上突增流量时客户端TCP连接一直卡在SYN_SENT请求超时服务端监控显示TCP新建连接成功率骤降。原因每个SYN报文到达服务端后会先进入半连接队列SYN队列等待完成第三次握手。半连接队列有上限当队列被占满内核会直接丢弃新的SYN。占满通常有两种来源一是攻击者只发SYN不完成握手用大量半连接耗尽队列二是短时间内真实并发太高服务端来不及给所有SYN回复SYNACK并完成握手。这两种情况可以通过观察ss -lnt里SYN-RECV状态的连接数来判断。解决调整内核参数net.ipv4.tcp_max_syn_backlog扩大半连接队列开启net.ipv4.tcp_syncookies让内核在队列满时用SYN Cookie机制过渡适当缩小net.ipv4.tcp_synack_retries减少SYNACK重试占用的队列时间。排查时要先区分攻击和真实高并发否则盲目调参数只会让攻击面更大。5.2 TIME_WAIT堆积主动关闭方的端口困局现象高并发短连接场景下客户端或服务端出现大量TIME_WAIT状态连接随后新连接报错“Cannot assign requested address”或者连接建立极慢。原因主动发起关闭的一方在发送最后一个ACK后必须停留2MSL才能释放连接。短连接请求一次就关闭高并发下同一端口快速被反复占用四元组被TIME_WAIT占满新连接无法分配端口。解决最稳妥的办法是减少连接关闭频率——用HTTP长连接让连接复用而不是每个请求都重建。如果必须大量短连接可以开启net.ipv4.tcp_tw_reuse依赖时间戳选项让内核在安全前提下复用TIME_WAIT连接。这里特别提醒一句很多老博客推荐的tcp_tw_recycle在NAT场景下有严重缺陷它会因为时间戳回退丢弃数据包导致部分用户访问失败这个坑我踩过不要再踩第二次。5.3 把管道和多路复用当一回事差在“乱序”二字现象面试或方案评审时把HTTP/1.1的管道化说成是HTTP/2多路复用“不成熟的早期版本”认为两者只是并发能力的强弱差异。原因没有抓住管道最根本的限制——响应必须按请求顺序返回。管道确实允许客户端连续发多个请求但服务端按序响应第一个慢请求会堵住后面所有响应这就是响应队头阻塞。HTTP/2多路复用则完全不同不同Stream的帧可以乱序交错到达接收端靠Stream ID重新组装任意Stream的响应都被解耦。解决记住三个硬性区别管道响应必须有序HTTP/2流帧可乱序管道没有流标识符HTTP/2帧头带Stream ID管道在浏览器中几乎从未被启用HTTP/2是真实落地的通用能力。答到这个颗粒度面试官基本不会再追问反而会顺着你的细节接着问帧结构。5.4 强缓存命中却拿到旧数据问题出在哪现象前端上线新版本接口和静态资源都更新了但用户端仍然请求到旧样式、旧逻辑清空浏览器缓存才恢复。原因强缓存Cache-Control/Expires生效时浏览器在过期时间内直接读本地缓存根本不发HTTP请求。如果你上线时改了文件内容却没有改URL浏览器自然沿用旧缓存。另外很多开发者对Cache-Control和Expires的优先级不清——两者都设置时以Cache-Control为准Expires是绝对时间受客户端本地时钟影响时钟一错缓存就乱。解决页面HTML用Cache-Control: no-cache保证每次请求都去服务器做协商缓存校验静态资源JS/CSS/图片用“文件名内容hash”的方式命名内容变文件名就变缓存自动更新不要只依赖Expires统一用Cache-Control的max-age或no-cache来控制缓存行为。排查时先看DevTools里请求状态是from memory cache还是from disk cache确认命中的是哪一层缓存再决定是改响应头还是改文件名。5.5 改了hosts不生效DNS缓存优先级的陷阱现象本地开发者把域名通过Hosts文件指向测试环境IP重启浏览器后访问仍是线上IP甚至看起来完全没走Hosts。原因DNS解析的缓存优先级比许多人以为的更复杂浏览器先查自身的DNS缓存没命中才会往下走如果浏览器还启用了内置的安全DNS直接向远端DoH服务器发起解析那么系统Hosts文件会被直接跳过操作系统层面如果之前有其他进程缓存了解析结果也可能干扰预期。解决依次排查关闭浏览器的安全DNS选项让它回退到系统解析在浏览器内部清理DNS缓存chrome://net-internals/#dns中的flush操作刷新操作系统级缓存Windows执行ipconfig /flushdnsLinux执行systemd-resolve --flush-caches最后确认Hosts文件格式正确域名和IP之间用Tab间隔、无多余字符。如果这些做完还是不生效用nslookup 域名直接对比权威解析结果能快速判断是缓存问题还是Hosts本身配置问题。6. 设计取舍的最后一块拼图八股文怎么背才算真懂把前面几章串起来看你会发现所有协议设计都是一组约束条件下“方案与代价”的交易。TCP用一次握手确认双向能力多一次都嫌浪费DNS用层级分担查询压力代价是更新生效要等TTL过期HTTP/2用二进制帧换解析效率却把队头阻塞推给了TCPHTTP/3用UDP重造可靠传输换来的是彻底移除传输层队头阻塞代价是协议栈复杂度大幅上升落地部署至今还要面对中间设备的兼容性问题。没有完美的协议只有适合场景的取舍。对正处在面试复习期和刚工作的开发者来说这意味着八股文的正确背法不是背答案而是背“约束链”先记住这个机制解决了什么问题再追问它留下了什么代价最后看下一个版本是怎么补偿这种代价的。比如有人问“HTTP/2为什么用HPACK而不是gzip压缩头部”因为HTTP头部字段高度重复静态表加索引号用固定编码命中重复项比通用压缩算法更快更省再追问“动态表为什么限制大小”因为动态表膨胀会吃满服务器内存所以http2_max_requests这类限制本身就是协议安全设计的一部分。每答一层都要能说出一个设计取舍和它对应的成本。我的一个血泪教训某次线上排查长尾请求变慢的问题我笃定“HTTP/2没有队头阻塞”结果抓包发现大量的TCP重传把多个Stream全堵在了内核缓冲区里——那一刻我才意识到背下来的“结论”如果没有配上“为什么TCP字节流必须有序交付”的机制理解在真实故障面前就是一块脆弱的挡箭牌。从那以后我每次复习协议相关面试题都会强制走一遍“约束→方案→代价”的推导把八股文当成架构决策笔记来读而不是标准答案来念。希望你也能带着这层视角去翻这份计算机基础PDF收获会比死记硬背大得多。希望帮到你。本文还有配套的精品资源点击获取