【计算机网络】网址到网页过程解析
你写的是：通过 ARP 协议在以太网中以广播的形式获得目标 MAC 地址。这句话在同一局域网内是对的。下一跳网关的 MAC 地址目标 IP 是服务器 IP目标 MAC 是网关 MAC因为服务器不在你的局域网里，ARP 广播不可能跨互联网广播到服务器那里。
你这份总结整体思路是对的，可以把它理解成一句话：
浏览器先把“网址”变成 HTTP 请求，再通过 DNS 找到服务器 IP，通过 TCP 建立连接，然后一层层封装成网络包发出去，服务器处理后返回响应，浏览器再解析并渲染页面。
下面按你的 8 步解释一遍。
1、解析 URL，生成 HTTP 请求
比如你输入：
https://www.example.com/user/info?id=1
浏览器会先拆 URL：
协议：https
域名：www.example.com
路径：/user/info
参数：id=1
然后浏览器知道：
我要用 HTTPS 协议
访问 www.example.com 这台服务器
请求 /user/info?id=1 这个资源
于是生成 HTTP 请求报文，大概像这样：
GET /user/info?id=1 HTTP/1.1
Host: www.example.com
User-Agent: Chrome
Accept: text/html
这里注意：
URL 里写的是域名，不是 IP。浏览器还不知道服务器真正的 IP 地址。
所以接下来要 DNS 解析。
2、DNS 解析：把域名变成 IP
计算机通信真正需要的是 IP 地址，比如：
www.example.com -> 93.184.216.34
DNS 的作用就是：
把域名解析成 IP 地址
它一般会按缓存优先：
浏览器 DNS 缓存
↓
操作系统 DNS 缓存
↓
本地 hosts 文件
↓
本地 DNS 服务器
↓
根域名服务器
↓
顶级域名服务器，例如 .com
↓
权威域名服务器
你写的“递归查询”和“迭代查询”也基本对。
简单记忆：
客户端通常把问题交给本地 DNS 服务器，这是递归查询。
也就是：
客户端：你帮我查 www.example.com 的 IP
本地 DNS：好的，我去问根、问 .com、问权威 DNS，最后把结果给你
而本地 DNS 服务器去问其他 DNS 服务器时，通常是迭代查询：
本地 DNS：你知道 www.example.com 吗？
根 DNS：我不知道具体 IP，但你去问 .com
.com DNS：我不知道具体 IP，但你去问 example.com 的权威 DNS
权威 DNS：它的 IP 是 xxx.xxx.xxx.xxx
3、建立 TCP 连接：三次握手
拿到 IP 后，浏览器就可以和服务器建立连接了。
如果是 HTTP/1.1 或 HTTP/2，一般底层还是 TCP。
TCP 三次握手可以记成：
客户端：我想连接你，Seq = x
服务器：可以，我也想连接你，Ack = x + 1，Seq = y
客户端：收到，Ack = y + 1
也就是：
SYN
SYN + ACK
ACK
三次握手的目的不是单纯“打招呼”，而是确认两件事：
客户端能发，服务器能收
服务器能发，客户端能收
双方都知道彼此的初始序列号
你写的：
这个过程结束后会对每个数据块添加一个 TCP 头部，每个数据块的长度为 MSS
这里可以稍微改一下：
HTTP 请求数据会交给 TCP，TCP 会把数据拆成一个个 TCP 段，每个 TCP 段加上 TCP 头部。每段数据的最大长度通常受 MSS 限制。
MSS 可以理解成：
一个 TCP 段里最多能装多少应用层数据
4、封装 IP 报文：实现跨网络定位
TCP 只负责：
可靠传输
端口定位
数据分段
丢包重传
顺序控制
但是 TCP 不负责“怎么从你家电脑找到服务器”。
所以 TCP 段要交给 IP 层。
IP 层会加 IP 头：
源 IP：你的电脑 IP
目标 IP：服务器 IP
协议：TCP
这样这个包就具备了跨网络传输的能力。
简单说：
TCP 负责可靠传输
IP 负责找到目标主机
5、添加 MAC 头部：实现局域网内传输
IP 解决的是：
最终要去哪个 IP
但是在真实网络里，数据是一跳一跳传的。
比如：
你的电脑 -> 家里的路由器 -> 运营商路由器 -> 更多路由器 -> 目标服务器
每一跳都需要知道：
下一跳设备的 MAC 地址
所以数据链路层会加 MAC 头：
源 MAC：你的网卡 MAC 地址
目标 MAC：下一跳设备的 MAC 地址
注意一个容易混淆的点：
目标 MAC 不一定是最终服务器的 MAC。
如果服务器不在同一个局域网里，那么你的电脑要先把包发给网关，也就是路由器。
所以此时：
目标 IP：服务器 IP
目标 MAC：网关/路由器的 MAC
这点非常重要。
ARP 的作用是：
根据 IP 查询对应的 MAC 地址
比如你的电脑要发给网关，就会问：
谁是 192.168.1.1？把你的 MAC 地址告诉我
网关回应：
我是 192.168.1.1，我的 MAC 是 xx:xx:xx:xx
然后你的电脑才能封装 MAC 头，把数据发出去。
6、网卡、交换机、路由器转发
这里可以分成三类设备理解。
网卡
网卡负责真正把数据发出去。
它会把二进制数据变成电信号、光信号或者无线信号。
网络包 -> 电信号/无线信号 -> 发出去
交换机
交换机工作在数据链路层，主要看 MAC 地址。
它根据 MAC 地址表决定：
这个帧应该从哪个端口转发出去
交换机不关心最终 IP 是谁，它主要关心：
目标 MAC 是谁
路由器
路由器工作在网络层，主要看 IP 地址。
它根据路由表决定：
这个 IP 包下一跳该发给谁
每经过一个路由器，会发生一个很关键的变化：
源 IP 和目标 IP 通常不变
源 MAC 和目标 MAC 会变
因为 IP 表示最终目的地，MAC 表示当前这一跳的发送方和接收方。
可以这么记：
IP 管终点
MAC 管下一跳
7、服务器接收并响应请求
数据包到达服务器后，会一层层拆包。
第一层：检查 MAC
服务器网卡先看：
目标 MAC 是不是我？
不是就丢弃，是就继续往上交。
第二层：检查 IP
IP 层看：
目标 IP 是不是我？
是的话继续处理。
第三层：交给 TCP
IP 头里有协议字段，发现上层是 TCP，于是交给 TCP。
TCP 再看端口号：
目标端口：80 或 443
然后找到对应的应用进程，比如 Nginx、Tomcat、Node 服务等。
第四层：应用层处理 HTTP 请求
Web 服务器拿到 HTTP 请求后，会根据路径处理：
GET /index.html
GET /api/user/info
如果是静态资源：
直接读取 HTML、CSS、JS、图片等文件
如果是动态接口：
转发给后端服务
后端查数据库/Redis
业务处理
生成响应结果
最后服务器生成 HTTP 响应：
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
然后响应数据再反向经过：
HTTP 响应
↓
TCP 封装
↓
IP 封装
↓
MAC 封装
↓
网络传输
↓
客户端接收
8、浏览器渲染页面
客户端收到 HTTP 响应后，浏览器开始解析和渲染。
如果返回的是 HTML，浏览器会做这些事：
解析 HTML，生成 DOM 树
解析 CSS，生成 CSSOM 树
合并 DOM 和 CSSOM，生成渲染树
布局 Layout，计算元素位置和大小
绘制 Paint，把内容画到屏幕上
如果 HTML 里还有：
<link rel="stylesheet" href="style.css">
<script src="main.js"></script>
<img src="logo.png">
浏览器还会继续发请求去下载 CSS、JS、图片等资源。
所以“输入网址到页面显示”不是只有一个请求，通常会有很多请求：
HTML 请求
CSS 请求
JS 请求
图片请求
字体请求
接口请求
你这份总结里几个需要微调的地方
1、ARP 不是直接找“目标服务器 MAC”
你写的是：
通过 ARP 协议在以太网中以广播的形式获得目标 MAC 地址。
这句话在同一局域网内是对的。
但如果访问的是互联网服务器，通常不是获取服务器 MAC，而是获取：
下一跳网关的 MAC 地址
也就是：
目标 IP 是服务器 IP
目标 MAC 是网关 MAC
因为服务器不在你的局域网里，ARP 广播不可能跨互联网广播到服务器那里。
2、交换机和路由器的职责不同
你写：
交换机再转发给路由器，然后在路由器中层层跳跃最终到达目标服务器。
可以更准确地说：
交换机负责局域网内根据 MAC 转发
路由器负责不同网络之间根据 IP 转发
所以路径可能是：
电脑
↓
交换机/无线 AP
↓
家庭路由器/网关
↓
运营商路由器
↓
骨干网路由器
↓
目标机房路由器
↓
负载均衡器
↓
Web 服务器
3、HTTP/2 仍然通常基于 TCP，但 HTTP/3 基于 UDP
你写 HTTP1.0、HTTP1.1、HTTP2.0，这里可以补一句：
HTTP/1.1 和 HTTP/2 通常基于 TCP
HTTP/3 基于 UDP + QUIC
所以如果面试官追问：
一定会 TCP 三次握手吗？
你可以回答：
如果是 HTTP/1.1 或 HTTP/2，一般会走 TCP 三次握手。
如果是 HTTPS，还会有 TLS 握手。
如果是 HTTP/3，则基于 UDP/QUIC，不走传统 TCP 三次握手。
4、HTTPS 还要多一步 TLS 握手
如果网址是：
https://www.example.com
那么 TCP 三次握手后，还要进行 TLS 握手。
它的目的包括：
验证服务器身份
协商加密算法
生成会话密钥
后续 HTTP 数据加密传输
所以 HTTPS 的大致过程是：
DNS 解析
↓
TCP 三次握手
↓
TLS 握手
↓
发送加密后的 HTTP 请求
↓
服务器返回加密后的 HTTP 响应
最终面试版回答
你可以这样说：
用户在浏览器输入 URL 后，浏览器首先会解析 URL，确定协议、域名、端口、资源路径等信息，并生成 HTTP 请求。由于网络通信需要 IP 地址，所以浏览器会先进行 DNS 解析，把域名解析成服务器 IP。拿到 IP 后，如果是 HTTP/1.1 或 HTTP/2，客户端会和服务器进行 TCP 三次握手，建立可靠连接；如果是 HTTPS，还会在 TCP 连接之后进行 TLS 握手，完成身份认证和密钥协商。
连接建立后，HTTP 请求交给传输层，TCP 会把数据拆分成 TCP 段，并添加源端口、目标端口、序列号、确认号等信息。然后交给网络层，IP 层添加源 IP 和目标 IP，用于跨网络寻址。再交给数据链路层，添加 MAC 头，用于当前局域网内的下一跳传输。这里要注意，目标 MAC 通常不是最终服务器的 MAC，而是下一跳网关的 MAC，MAC 地址一般通过 ARP 获取。
之后数据通过网卡发送出去，经过交换机、路由器等网络设备层层转发。交换机主要根据 MAC 地址转发，路由器主要根据 IP 地址和路由表选择下一跳。数据到达服务器后，服务器从数据链路层、网络层、传输层逐层解包，根据端口号找到对应的 Web 服务进程，处理 HTTP 请求，生成 HTTP 响应并返回给客户端。客户端浏览器收到响应后，解析 HTML、CSS、JS，构建 DOM 树和 CSSOM 树，生成渲染树，完成布局和绘制，最终把页面显示出来。
你后面补充的 CDN、DNS 负载均衡、LVS、Nginx 那段也很好，可以作为加分项。
可以这样接：
从工程架构角度看，请求不一定直接到达源站服务器。如果是静态资源，可能会被 CDN 边缘节点直接命中并返回；如果是动态请求，流量可能先经过 DNS 全局负载均衡，被调度到最近或最合适的机房。进入机房后，通常会先到 VIP，由 LVS 等四层负载均衡根据 IP 和端口做转发，再到 Nginx 这类七层负载均衡，根据域名、路径、Header 等信息转发到具体后端服务。
简单记：
浏览器层面：URL -> HTTP 请求
域名层面：DNS -> IP
传输层面：TCP / TLS
网络层面：IP 路由
链路层面：MAC / ARP / 交换机
服务端层面：负载均衡 -> Web 服务 -> 后端服务
客户端层面：解析资源 -> 渲染页面
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
1
0- 0
已为社区贡献2条内容
所有评论(0)