企业官网建设流程全解析

简介：《计算机基础.pdf》是一份面向后端与前端开发求职者的计算机网络八股文精华合集，内容源自代码随想录知识星球“最强八股文”第五版中的计算机基础篇。资源将面试高频的TCP三次握手与四次挥手、HTTP与HTTPS区别、DNS域名解析流程、浏览器输入URL后的完整工作链路，以及HTTP缓存的强缓存与协商缓存机制等问题，以图文结合的方式拆解成一问一答的要点，适合需要在短时间内构建知识框架并针对性背诵的读者。包体为单个PDF文件，共37.83MB，版式清晰、可直接在电脑或移动端阅读，方便按章节划重点与反复回看。目前已有777人学习下载，对于准备技术面试、梳理网络基础薄弱环节的开发者来说，是一份拿来即用的复习资料。内容不仅讲清“输入URL发生了什么”的完整流程，还覆盖DNS递归查询与迭代查询的区别、四次挥手为什么是四次等追问点，既给出过程图解又标注回答要点，能帮助读者在面试中更有条理地表达。

1. 输入URL按下回车：一次浏览背后发生了什么

点外卖时你只看到下单、出餐、配送三个状态，但每一次状态刷新背后都有一整条链路在跑。输入网址按回车也一样：浏览器先查这个域名对应的IP，再和服务器建立TCP连接、发送HTTP请求、接收响应、渲染页面、最后挥手断开。这七个步骤是计算机网络的“主干道”，也是面试里出现频率最高的一组题——面试官随便挑一步都能往深处问：DNS为什么是分布式的？握手为什么是三次？HTTP和HTTPS差在哪？把这条链路走通，网络知识就不再是零散术语，而是一张能自圆其说的地图。这份计算机基础资料也是按这个思路组织的，接下来我把这七个步骤一个一个拆开看。

2. DNS到底是什么：互联网的电话簿与它的分布式自救

你有没有想过，为什么上网不用记一串数字，而是记一个单词？因为人记“server.com”比记“220.181.111.188”容易得多。但机器只认数字，所以中间需要一个翻译官，把域名翻译成IP地址。这个翻译官就是DNS（Domain Name System，域名系统）。

如果只是“翻译”这一个动作，那问题很简单——建一台超级服务器，全世界都来查它就行。但事情没这么简单。

2.1 为什么不能只有一个DNS总机：集中式的四个死穴

打个比方：老式单位里只有一个总机电话，所有人都打这个号码查分机。刚开始还行，但人越来越多，总机忙不过来；总机一坏，全单位都失联；离得远的部门打过来还要转好几条线路，慢得要命；而且每天都有新人入职、换岗，总机的话务员得不停更新名单，累死也赶不上变化。

DNS如果采用集中式设计，遇到的正是这四个问题。

第一是单点故障。全世界只有一台DNS服务器，它一崩，整个互联网跟着瘫痪，这个风险任何公司都扛不住。第二是通信容量。所有设备的DNS查询都打向这一台机器，查询量是上千万、上亿级别的，一台服务器根本处理不过来。第三是远距离延迟。服务器放美国，澳大利亚的用户查一次域名要跨越大半条地球，请求势必经过低速和拥堵的链路，延迟高到无法接受。第四是维护成本。域名每天都在新增、变更，集中在一个数据库里频繁更新，代价巨大。

所以DNS从一开始就是分布式的：把域名和IP的映射关系打散到全球无数台服务器上，各管一段，互相指路。这也是它能扛住今天互联网规模的根本原因。

2.2 域名的层级：越靠右，级别越高

用收快递来理解域名的层级。你写地址“中国广东省深圳市南山区”，是从大到小一层层定位的。域名也一样，看www.server.com这个名字，句点就是层级边界，越靠右的位置层级越高。

最右边是顶级域，比如.com、.net、.org，相当于“国家”这一级。往左一级是二级域，比如server.com，相当于“城市”。再往左是主机名，比如www.server.com，相当于“具体街道门牌”。

这套层级的意义在于：根DNS服务器不用知道全世界的域名映射，它只负责指路——“你要查.com的域名？去找管.com的服务器”。顶级域服务器也不用知道所有细节，它只负责指到下一级。每一层都只存自己该管的那一小段，这样既分摊了压力，数据更新也不用全量同步。

2.3 一次DNS解析的完整旅程：从浏览器到权威服务器

当你在浏览器输入www.server.com按下回车，域名解析并不是一口气从最顶层查到底的，而是一级一级“问”出来的。整个流程可以拆成八步：

注意看第4到第6步：根服务器和顶级域服务器都不负责“最终翻译”，它们只告诉你“下一站去哪”。真正给出IP的是权威DNS服务器——它是这个域名的“户籍档案”。

这里也体现出缓存的重要性。每一步的缓存，都是为了让下一次解析少跑一趟。第1步浏览器缓存通常只存活几分钟，第3步本地DNS服务器的缓存能存活几小时到几天，缓存的存在让绝大多数解析在第3步就结束了，根本到不了根服务器。

2.4 递归查询与迭代查询：包打听和指路人

DNS解析里还有一对高频概念：递归查询和迭代查询。很多人分不清，其实用问路来记特别形象。

递归查询就像你找了一个“包打听”：你只问他一句“去server.com怎么走”，他全权负责跑完整个流程，问完这个问那个，最后把完整答案带回来给你。你只需要发一次请求，等着拿结果就行。普通用户的浏览器向本地DNS服务器发起的查询，就是递归查询。

迭代查询就像你找到一个“指路人”：他告诉你“先去找管.com的服务器”，你跑过去，那台服务器又说“再去找管server.com的权威服务器”，你再跑过去。每次都是别人指个方向，路你自己跑。本地DNS服务器依次向根服务器、顶级域服务器、权威服务器发起的查询，就是迭代查询。

谁在跑路，是判断标准：全程有人替你跑、你只等答案的，是递归；每问一次就被指一次路、然后自己接着追问的，是迭代。

3. 三次握手与四次挥手：为什么必须是三次，不能是两次或四次

TCP是传输层最核心的协议，而它最出名的就是“三次握手”建立连接、“四次挥手”断开连接。这两个过程几乎是每场技术面试的必问题，而且问题往往不是“过程是什么”，而是“为什么是三次，不是两次或四次”。这一章把这两个问题彻底讲透。

3.1 三次握手：两个人互相确认“你能听到我吗”

通俗地说，TCP连接是“可靠”的，但可靠不是天生的，得先确认双方都能正常收发消息。三次握手干的就是这件事。

想象两个人用手台对讲机联络。第一次，A说：“B，你能听到我说话吗？”——这是客户端发送SYN报文。第二次，B听到后回答：“A，我能听到你，你也能听到我吗？”——这是服务器回应SYN+ACK报文。第三次，A再回一句：“我能听到你，我们开始吧。”——这是客户端发送ACK报文。

经过这一来一回，双方确认了两件事：我的消息能发到你那里，你的消息也能发到我这里。到第三次握手结束时，客户端和服务器都对彼此的收发能力有了确定认知，连接才算正式建立。

注意第二次握手是“SYN+ACK”两个标志位一起发出去的，这相当于B把“我听到了”和“我也想确认你”两件事合并成了同一句话。这也是三次而不是更多的关键。

3.2 为什么不是两次，也不是四次：历史失效连接是主要原因

很多人会问：第一次握手客户端不就已经自报家门了吗？服务器回一句确认，客户端再回一句，这不是对称的吗？为什么不能省掉第三次？

关键在一个词：历史失效连接。假设客户端的第一次SYN在网络上卡了很久，迟迟没到服务器，客户端等不到回应，以为丢了，又重发了一个SYN。过一会儿，那个卡住的旧SYN先到了——注意，现在是两个SYN都到了。

如果只有两次握手，服务器收到旧SYN后会立刻回复SYN+ACK，然后以为连接建立成功。但客户端真正想要的是第二次重发的那个连接，旧SYN在客户端眼里已经被判定为超时作废了。结果就是：服务器上留下一个客户端根本不会理会的“死连接”，白白占着资源。

三次握手能解决这个问题：客户端收到服务器的SYN+ACK后，会判断这个响应是不是自己正在等待的那次握手。如果服务器响应的是旧SYN，客户端发现序列号对不上，会发RST报文直接把连接重置掉。但要做到这一步，前提是必须有第三次ACK让客户端有机会表达“这个连接我不要了”。所以两次永远不够。

那四次呢？三次已经让双方都确认了对方的收发能力，信息量已经完整，第四次不会再增加任何有效信息，只会多一次网络开销。三次是“刚好够用”的最优解。

3.3 为什么断开要四次：因为双方都要独立地说再见

建连是三次，断连却是四次，初看很不对称。但想想TCP连接的本质——它是全双工的，数据的发送和接收是两个独立方向，就像一个双向对讲频道，A说给B听是一路，B说给A听是另一路。每一路都需要单独关闭，所以挥手天然比握手多。

过程拆分来看就清楚了。第一次挥手：客户端说“我要说的都说完了，准备断开”——发送FIN报文。第二次挥手：服务器回“收到你的话，我这边知道了”——发送ACK报文。但注意，服务器只是确认“收到你说完了”，它自己可能还有数据没发完，所以这时候连接并没有断开。第三次挥手：服务器把剩余数据发完后，说“我这边也说完了，可以断了”——发送FIN报文。第四次挥手：客户端回“收到，再见”——发送ACK报文，连接彻底关闭。

问题来了：第二次和第三次为什么不能合并成一次？因为服务器在收到FIN时往往还有数据要发。如果服务器恰好也没话说了，理论上三次可以完成，但在实际场景里，服务器“确认收到”和“我也要断开”是两个时刻，中间隔着一段不确定的数据传输时间，所以必须拆成两次。这也是面试时最容易暴露“背答案”和“真理解”区别的地方——很多人会背四次的报文名称，却说不清为什么不能省。

3.4 高频追问：第一次握手丢了会发生什么，握手时能带数据吗

面试官不会满足于“过程是什么”，他们更爱问“如果某一步出错了呢”。

如果第一次握手丢失，也就是客户端的SYN报文在网络中消失了，服务器根本不会知道有人想连接。客户端会启动超时重传，等不到SYN+ACK就重新发一次SYN，而且不是只重发一次，通常会按指数退避的节奏重试几次，直到建立连接或放弃。

第二次握手丢失同理，客户端依然收不到SYN+ACK，还是会超时重传。这里有个容易被忽略的点：服务器如果收到了重传的SYN，它不会知道这是第一次还是第二次，只会计数握手次数，然后重新回应。所以重传的代价主要是时间，而不是协议状态错乱。

握手能否携带数据也是经典问题。答案很明确：第一次和第二次握手不能带数据，因为连接还没建立，此时携带数据会放大风险，容易被用来做SYN洪泛攻击。第三次握手可以带数据，因为客户端发出ACK时，已经确认了“服务器能收到我的消息，我也能收到服务器的消息”，连接事实上已经可用，这时带上首个HTTP请求数据，能省一次往返时间。

4. HTTP与HTTPS：一字之差，安全差了多少

HTTP是浏览器和服务器之间对话的语言。你在地址栏输入的那段网址，前面写的http://或https://，决定了这场对话是“裸奔”还是“加密”。这一章讲清楚HTTP的性格、HTTPS做了什么，以及HTTP缓存是怎么替浏览器省时间的。

4.1 HTTP的三个先天问题：无状态、明文、不安全

HTTP的设计理念是简单、灵活、易于扩展。报文格式就是一个header加一个body，头部是key-value形式的纯文本，连状态码都设计成三位数字，比如404、500，一看就懂。而且它允许开发人员自定义请求方法、状态码和头字段，这也是它能应用几十年的原因。

但“简单”的另一面是“简陋”。HTTP有三个先天问题。

第一个问题是无状态。服务器不记忆“你是谁”，每次请求都是独立的，它不知道你上一次干了什么。这种设计减轻了服务器负担，但带来一个麻烦：你登录后刷新页面，服务器不记得你登录过，所有需要状态的关联操作都很别扭。解决方案是Cookie——服务器在响应报文里写一个标识，浏览器存下来，下次请求时通过Cookie头带给服务器，服务器凭这个标识认出你。有了Cookie，无状态才没有变成“失忆”。

第二个问题是明文传输。HTTP的报文内容在网络上是可以直接读的，浏览器按F12打开控制台就能看到请求和响应的完整内容，用抓包工具同样能看。明文对调试很友好，但对敏感信息来说是灾难。

第三个问题是不安全。具体有三层：通信内容不加密，可能被窃听；不验证服务器身份，可能遇到伪装站点；无法证明报文完整性，内容可能在路上被篡改。这三个问题不是理论风险，而是实打实的攻击面。

4.2 HTTPS做了什么：加密、验身份、防篡改

HTTPS就是冲着这三个问题来的。它没有发明新协议，而是在HTTP和TCP之间加了一层SSL/TLS安全传输层。

打个比方：HTTP是寄明信片，任何人经手都能看到内容。HTTPS是寄挂号信——信纸装进密封信封，内容只有收件人拆开才能看；信封上有发件人签名和防伪标识，收件人能确认寄件人是谁；封口有特殊工艺，路上被拆开过会被发现。

对应到技术上：加密解决窃听问题，即使数据被截获，看到的也是密文；证书机制解决伪装问题，浏览器会验证服务器的数字证书，确认它确实是域名对应的那台服务器；完整性校验解决篡改问题，报文内容被改过，接收方验签时会发现对不上。

资料里特别提到一个容易忽略的点：HTTP/2是基于HTTPS的，所以它的安全性有保障。也就是说，协议版本的演进和是否加密是两个独立维度——用HTTP/1.1裸奔，用HTTP/2也一样要套SSL/TLS。日常排查问题时可别以为“版本够新就等于安全”。

4.3 HTTP缓存：让浏览器少跑几趟的两种机制

说完了安全，再讲一个和日常体验强相关的机制：HTTP缓存。你打开一个网页，图片、样式、脚本反复加载，每次都要从服务器重新下载，那网页得多慢。HTTP缓存的思路很简单：把服务器返回的资源副本存起来，下次直接复用。

这里有两种机制，很多人混在一起。第一种是强缓存，服务器在响应头里明确告诉浏览器“这个资源在多少秒内有效”。在有效期内，浏览器根本不发起请求，直接用本地副本，你看网络面板会发现状态码是200 from disk cache。

Cache-Control: max-age=3600 # 强缓存：3600秒内直接用本地副本，不发请求 ETag: "5d8c72a2edda8" # 资源指纹：内容一变这个值就变

第二种是协商缓存。强缓存过期后，浏览器不能直接删掉本地副本，而是带着它去问服务器“这个资源变了没有”。问的方式有两种：用Last-Modified问“最后修改时间变了没”，或者用ETag问“指纹变了没”。服务器比对后发现没变，就回一个304状态码，什么内容都不返回，浏览器继续用本地副本。

这里的关键区别是：强缓存命中时，请求根本没发出去；协商缓存命中时，请求发出去了，只不过省掉了响应体。所以优先级永远是先强缓存、再协商缓存，两者是串行工作的。面试时把这个顺序讲清楚，比单纯背Cache-Control和ETag两个词要扎实得多。

5. 易混区别：连接、缓存、协议版本里的那些坑

计算机网络的难点往往不在单个概念，而在概念之间的边界。这一章把初学者最容易混的五组概念拉出来逐一对比，每组都是面试官最爱用来区分“背没背熟”的陷阱。

5.1 易混一：HTTP/1.1管道化与HTTP/2并发传输

HTTP/1.1里有个“管道化”机制，HTTP/2里有个“并发传输”，都涉及“同时发多个请求”，但本质完全不同。

管道化是HTTP/1.1为了解决“每次请求都要等响应”的低效而提出的。在同一个TCP连接里，客户端可以先发请求A，不等A的响应，立刻发请求B。听起来像并发，但服务器必须按接收请求的顺序来发送响应：A没处理完，B就得在后面排队。如果A是一个耗时操作，B明明早就处理好了也要被堵在后面，这就是“响应队头阻塞”。资料里特意强调：管道化技术不是默认开启的，而且浏览器基本都没有支持，所以它实际是个“纸面上的优化”。

HTTP/2的并发传输是另一套设计。它引入了Stream（流）概念，多个Stream复用在同一条TCP连接上，每个Stream有唯一的Stream ID。关键区别在于：不同Stream的帧是可以乱序发送的，接收端根据Stream ID把帧重新组装成消息。所以流B根本不需要等流A处理完，这才是真正的并发。

一句话区分：管道化是“同时发出去了，但响应还得排队”；HTTP/2并发是“发出去了，响应也各回各家”。

5.2 易混二：HTTP/2解决了队头阻塞，但没完全解决

很多人在这一步掉坑：既然HTTP/2支持并发传输，那队头阻塞是不是彻底没了？答案是：应用层的没了，传输层的还在。

HTTP/2解决的是HTTP/1.1的队头阻塞——那个“慢响应堵住后续响应”的问题。但HTTP/2底层的传输协议还是TCP，而TCP是字节流协议，它必须保证字节顺序的完整和连续。内核缓冲区里的数据必须按顺序拼好，才会交给上层应用。如果前一个字节还没到达，后面先到的字节就得老老实实待在内核缓冲区里等着。

打个比方：传输通道是一条传送带，货物必须按顺序到达出口。虽然HTTP/2把每个Stream的货物都贴了标签、允许交错摆放，但传送带本身要求“前面的不到，后面的不准卸货”。只要TCP丢了一个包，后面所有Stream的数据都得跟着等重传。这就是HTTP/2队头阻塞的由来——问题没有消失，而是从应用层下沉到了传输层。

这个区分很重要，因为它直接解释了HTTP/3为什么要换掉TCP。

5.3 易混三：递归查询与迭代查询，谁在跑路

DNS里这两个概念，我在前面章节已经分别讲过，这里单独拎出来做对比，因为太容易搞反了。

记住一句话：递归是“包打听”，迭代是“指路人”。面向普通用户的DNS请求，比如你的浏览器向本地DNS服务器发起的查询，是递归——你只发一次请求，剩下的路由由本地DNS全权代理。DNS服务器之间的互相询问，比如本地DNS问根服务器“该找谁问”，根服务器指路，本地DNS再去找顶级域服务器，是迭代——每次都有人告诉你下一个该找谁，但路是你自己跑的。

误区最容易出在“谁是发起方”上。很多人以为“我发起的查询就是迭代查询”，其实站在浏览器的角度，它只需要发一个请求，全程坐等结果，这叫递归。迭代的主体是本地DNS服务器，不是你的浏览器。区分标准只有一个：跑腿的到底是谁。

5.4 易混四：强缓存与协商缓存，谁决定用谁

从上面章节里缓存的两个机制延伸出一个高频混淆点：强缓存和协商缓存到底谁先谁后？命中后有什么区别？

强缓存是浏览器单方面做决定。响应头里的Cache-Control: max-age=3600说“一小时内有效”，浏览器就认这个期限，期限没到，连请求都不发，本地直接取用。协商缓存是服务器做决定。强缓存过期后，浏览器带上资源的指纹或修改时间去问服务器，服务器比对后说“没变”，回一个304，省掉响应体；服务器说“变了”，就回200和新内容。

很多初学者以为协商缓存比强缓存“高级”，其实正好相反。强缓存一次请求都不发，性能最好；协商缓存每次都要发请求，只是省了下载内容。把两者排个优先级：强缓存先命中，没命中就进入协商缓存流程。这个顺序在任何标准浏览器里都是一样的。

5.5 易混五：三次握手和四次挥手为什么不对称

“建连三次，断连四次”，这个不对称让很多人背了很久，面试一追问就翻车。本质原因前面已经讲过，这里用一句话总结：握手时双方都没什么历史负担，一次往返就能确认彼此的收发能力；挥手时服务器可能还有数据没发完，它必须在“收到你断开请求”和“我也要断开”之间，隔出一个把剩余数据发完的时间段。

所以你看到的四次挥手，实际上是把“服务器的确认”和“服务器的告别”拆成了两件事。如果服务器收到FIN时恰好自己也没话说了，第二次和第三次是可以合并的——实际网络里也确实存在三次挥手的情况。把这个特例说出来，比单纯背“必须四次”更能体现你真懂。

6. TCP还是UDP：什么时候选哪个，以及这份资料该怎么用

理解了三次握手和四次挥手，你其实已经看到了TCP的性格：可靠、有序，但有代价。每一次握手重传都在消耗时间，每一次确认都在增加往返次数。TCP适合的是“一字节都不能丢”的场景，比如文件传输、网页加载、邮件收发——这些场景丢一个字节，整个文件可能就坏了。

UDP站在另一头。它不握手、不确认、不重传，数据报发出去就不管了。代价是不可靠，收获是低延迟。适合的场景是实时音视频通话、在线游戏、直播——这些场景里偶尔丢一帧画面、跳一个音，用户基本察觉不到；但如果为了等重传卡住几秒，体验才是灾难。

这个选择的边界正在移动。HTTP/3把TCP换成了基于UDP的QUIC，说明“UDP + 上层自己实现可靠机制”也是一种可行方案。TCP的可靠未必是不可替代的，但在大多数后端系统里，TCP仍然是无脑不出错的选择。

聊回这份资料本身。它不是教科书，而是按面试官提问的习惯组织的——每个高频点都分“高频重点”和“一问一答”两种形态。重点区把三次握手、HTTP缓存、DNS解析这类问题讲透，问答区补充细碎但可能被突击提问的知识点。适合的使用方式是：先按“输入URL按下回车”这条链路把主干走通，再针对薄弱环节去问答区检索补漏。

我自己的习惯是，每次网页加载变慢时，都会强制自己按这条链路排查一遍：是DNS解析变慢了，还是TCP建连卡住了，还是HTTP缓存失效导致重复下载？这个习惯帮我彻底告别了“背了忘、忘了背”的循环，因为每一步都有了现实场景对应。建议你也试试，链路走通一次，胜过背十遍答案。希望帮到你。

本文还有配套的精品资源，点击获取