从输入URL到展示出页面

最新推荐文章于 2025-10-02 22:32:25 发布

原创最新推荐文章于 2025-10-02 22:32:25 发布 · 958 阅读

31 ·

CC 4.0 BY-SA版权

文章标签：

#java-ee

从输入 URL 到页面展示的完整过程

当用户在浏览器地址栏输入 URL（如https://www.baidu.com）并按下回车键后，页面最终展示需经历DNS 解析、TCP 连接、HTTP 请求 / 响应、页面渲染四大核心阶段，涉及网络协议、浏览器内核、操作系统等多层协同，具体流程可拆解为以下 11 个关键步骤：

一、阶段 1：URL 解析与预处理（浏览器层面）

浏览器首先对输入的 URL 进行 “合法性校验与格式拆解”，明确 “要访问的资源是什么、通过什么协议访问、要发送到哪个服务器”。以https://www.baidu.com/s?wd=nat#fragment为例，解析结果如下：

协议（Scheme）：https（超文本传输安全协议，基于 TCP，加密传输），常见协议还包括http（明文）、ftp（文件传输）等；
域名（Domain）：www.baidu.com（服务器的 “人类可读地址”，需转换为 IP 地址才能通信）；
端口（Port）：https默认端口为443（http默认80），URL 中未显式写端口时，浏览器自动填充默认端口；
路径（Path）：/s（服务器上资源的具体路径，对应后端路由）；
查询参数（Query）：wd=nat（用户传递给服务器的参数，如搜索关键词 “nat”）；
锚点（Fragment）：#fragment（页面内的定位标记，仅在浏览器端生效，不会发送到服务器，用于快速跳转到页面指定位置）。

若 URL 不完整（如仅输入baidu.com），浏览器会自动补全协议（默认https）和前缀（添加www.），再进入后续流程。

二、阶段 2：DNS 域名解析（获取服务器 IP）

URL 中的 “域名”（如www.baidu.com）无法直接用于网络通信 —— 网络层仅识别 “IP 地址”（如180.101.49.11），因此需通过DNS（域名系统，Domain Name System） 将域名转换为对应的 IP 地址，这一步本质是 “查询分布式的域名 - IP 映射数据库”。

DNS 解析流程（遵循 “从近到远” 的缓存优先原则）：

浏览器 DNS 缓存查询：浏览器会缓存近期解析过的域名（如 10 分钟内访问过的www.baidu.com），若缓存未过期，直接获取 IP，无需后续步骤；
操作系统 DNS 缓存查询：若浏览器缓存未命中，浏览器会调用操作系统接口（如 Windows 的DNS Client服务、Linux 的nscd服务），查询操作系统本地缓存（如hosts文件，可手动配置域名 - IP 映射）；
本地 DNS 服务器查询：若系统缓存也未命中，操作系统会向 “本地 DNS 服务器”（通常由宽带运营商或企业 IT 配置，如114.114.114.114、8.8.8.8）发送 DNS 查询请求；本地 DNS 服务器通常会缓存大量域名，若命中则直接返回 IP；
根 DNS 服务器查询：若本地 DNS 未命中，会向 “根 DNS 服务器”（全球共 13 组，负责顶级域名管理）发送请求，根 DNS 不直接返回 IP，而是告知 “com顶级域名服务器的地址”；
顶级域名服务器查询：本地 DNS 向 “com顶级域名服务器” 发送请求，顶级域名服务器也不返回 IP，而是告知 “baidu.com二级域名服务器的地址”；
权威 DNS 服务器查询：本地 DNS 向 “baidu.com权威 DNS 服务器”（百度自己维护的 DNS 服务器，负责存储www.baidu.com等子域名的 IP）发送请求，权威 DNS 服务器返回www.baidu.com对应的 IP 地址（如180.101.49.11）；
缓存与返回：本地 DNS 服务器将获取到的 “域名 - IP 映射” 存入自身缓存，同时返回给浏览器；浏览器也将该映射存入自身缓存，供后续短时间内复用。

优化点：DNS 解析支持 “并发查询”（同时查询多个层级的服务器）和 “DNS 预解析”（浏览器提前解析页面中可能用到的域名，如<link rel="dns-prefetch" href="//img.baidu.com">），减少等待时间。

三、阶段 3：建立 TCP 连接（三次握手）

获取服务器 IP 后，浏览器需通过TCP 协议与服务器建立可靠的连接（因 HTTP/HTTPS 基于 TCP 传输，需保证数据不丢失、不重复、按序到达），连接建立过程称为 “TCP 三次握手”，发生在浏览器（客户端）与服务器之间：

三次握手具体流程（以客户端 IP：`192.168.1.2`，服务器 IP：`180.101.49.11:443`为例）：

第一次握手（客户端→服务器）：客户端向服务器发送 “SYN（同步）报文”，包含：
- 标志位：SYN=1（表示请求同步）；
- 客户端初始序列号（Seq）：随机值，如x；
- 目的端口：443（服务器 HTTPS 端口）。此时客户端状态变为 “SYN_SENT”（等待服务器确认）。
第二次握手（服务器→客户端）：服务器接收 SYN 报文后，确认客户端的连接请求，回复 “SYN+ACK（同步 + 确认）报文”，包含：
- 标志位：SYN=1（服务器同步自身序列号）、ACK=1（确认客户端的 Seq）；
- 服务器初始序列号（Seq）：随机值，如y；
- 确认号（Ack）：x+1（表示已接收客户端 Seq=x 的报文，下次期望接收 x+1）。此时服务器状态变为 “SYN_RCVD”（等待客户端确认）。
第三次握手（客户端→服务器）：客户端接收 SYN+ACK 报文后，确认服务器的同步信息，回复 “ACK（确认）报文”，包含：
- 标志位：ACK=1（确认服务器的 Seq）；
- 客户端序列号（Seq）：x+1（延续第一次的 Seq）；
- 确认号（Ack）：y+1（表示已接收服务器 Seq=y 的报文，下次期望接收 y+1）。服务器接收 ACK 报文后，TCP 连接正式建立，双方状态均变为 “ESTABLISHED”（可开始传输数据）。

为什么需要三次握手：核心是 “确认双方的发送和接收能力均正常”—— 第一次握手确认客户端能发、服务器能收；第二次握手确认服务器能发、客户端能收；第三次握手确认客户端能发、服务器能收，避免 “无效连接”（如客户端发送的连接请求超时后重发，服务器误接旧请求建立无用连接）。

四、阶段 4：建立 HTTPS 连接（TLS/SSL 握手，若为 HTTPS 协议）

若 URL 协议是https（而非http），在 TCP 连接建立后，还需额外进行TLS/SSL 握手（Transport Layer Security/Secure Sockets Layer），实现 “数据加密传输” 和 “服务器身份认证”，防止数据被窃听或篡改。

TLS/SSL 握手核心流程（以 TLS 1.2 为例）：

客户端 Hello：客户端向服务器发送 “客户端 Hello” 报文，包含：
- 支持的 TLS 版本（如 TLS 1.2）；
- 支持的加密套件（如ECDHE-RSA-AES256-GCM-SHA384，用于后续加密）；
- 客户端生成的 “随机数 1”（用于后续生成会话密钥）。
服务器 Hello 与证书发送：服务器接收后回复 “服务器 Hello” 报文，包含：
- 确定的 TLS 版本和加密套件（从客户端支持的列表中选择）；
- 服务器生成的 “随机数 2”（与随机数 1 共同用于生成密钥）；
- 服务器的数字证书（由权威 CA 机构颁发，包含服务器公钥、域名、有效期等信息，用于客户端验证服务器身份）。
客户端验证证书与密钥协商：
- 客户端使用 “CA 根证书”（浏览器预装，如 VeriSign、Let’s Encrypt）验证服务器证书的合法性（检查有效期、域名匹配、签名是否有效），若证书无效，浏览器会弹出 “不安全” 警告；
- 客户端生成 “预主密钥（Pre-Master Secret）”，用服务器证书中的公钥加密后发送给服务器（只有服务器的私钥能解密）；
- 客户端和服务器分别使用 “随机数 1 + 随机数 2 + 预主密钥”，通过相同的算法生成会话密钥（Session Key）（用于后续数据加密的对称密钥，因对称加密效率高于非对称加密）。
握手完成确认：
- 客户端向服务器发送 “Finished” 报文，用会话密钥加密，告知服务器 “后续数据将用该密钥加密”；
- 服务器接收后解密 “Finished” 报文，验证通过后，也发送 “Finished” 报文（同样用会话密钥加密）；
- 客户端接收并解密服务器的 “Finished” 报文，TLS/SSL 握手完成，后续 HTTP 请求 / 响应均通过会话密钥加密传输。

五、阶段 5：发送 HTTP 请求（客户端→服务器）

TCP（或 HTTPS）连接建立后，浏览器作为客户端，向服务器发送HTTP 请求（HyperText Transfer Protocol，超文本传输协议），请求获取 URL 对应的资源（如 HTML 文件、图片、JS 脚本）。

HTTP 请求的结构（以 GET 请求为例）：

请求行（Request Line）：包含请求方法、URL 路径、HTTP 版本，如：GET /s?wd=nat HTTP/1.1
- 请求方法：GET（获取资源）、POST（提交数据）、PUT（修改资源）、DELETE（删除资源）等；
- URL 路径：/s?wd=nat（服务器端路由，包含查询参数）；
- HTTP 版本：HTTP/1.1（主流版本，支持长连接；HTTP/2支持多路复用，效率更高）。
请求头（Request Headers）：键值对形式，传递客户端信息和请求偏好，常见字段：
- Host: www.baidu.com（指定服务器域名，用于服务器区分同一 IP 下的不同网站）；
- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/118.0.0.0 Safari/537.36（客户端浏览器和操作系统信息，服务器可据此返回适配的页面）；
- Accept: text/html,application/xhtml+xml（客户端可接收的资源类型，如 HTML、XML）；
- Cookie: BAIDUID=xxx; BIDUPSID=xxx（客户端存储的 Cookie，用于身份认证、会话保持，如登录状态）；
- Connection: keep-alive（请求完成后保持 TCP 连接，供后续请求复用，减少握手开销）。
请求体（Request Body）：仅用于POST、PUT等方法，传递表单数据、JSON 等内容，如wd=nat&tn=baidu（GET方法的参数在 URL 中，请求体为空）。

请求发送后，浏览器进入 “等待响应” 状态，服务器接收请求并处理。

六、阶段 6：服务器处理请求并返回 HTTP 响应（服务器→客户端）

服务器（如百度的 Web 服务器，可能是 Nginx、Apache 等）接收 HTTP 请求后，按以下流程处理并返回响应：

请求解析：服务器解析请求行（确定请求方法和路径）、请求头（获取客户端信息）、请求体（提取提交数据）；
路由匹配：根据请求路径（如/s），将请求转发给对应的后端服务（如百度搜索的后端程序）；
业务处理：后端服务执行逻辑（如查询 “nat” 关键词的搜索结果），生成需要返回的资源（如 HTML 页面、JSON 数据）；
构建响应：服务器根据处理结果，构建HTTP 响应，并通过 TCP（或 HTTPS）连接发送给客户端。

HTTP 响应的结构：

状态行（Status Line）：包含 HTTP 版本、状态码、状态描述，如：HTTP/1.1 200 OK
- 状态码：表示请求处理结果，常见类型：
  - 2xx（成功）：200 OK（请求成功）、204 No Content（成功但无返回内容）；
  - 3xx（重定向）：301 Moved Permanently（永久重定向，如http跳https）、302 Found（临时重定向）；
  - 4xx（客户端错误）：404 Not Found（资源不存在）、403 Forbidden（权限不足）；
  - 5xx（服务器错误）：500 Internal Server Error（服务器内部错误）、503 Service Unavailable（服务器过载）。
响应头（Response Headers）：键值对形式，传递服务器信息和资源属性，常见字段：
- Content-Type: text/html; charset=utf-8（返回资源的类型和编码，如 HTML 文件、UTF-8 编码）；
- Content-Length: 1234（资源的字节大小，用于客户端验证是否接收完整）；
- Server: BWS/1.1（服务器软件版本，如百度的 BWS 服务器）；
- Set-Cookie: BAIDUID=xxx; expires=...（服务器向客户端设置 Cookie，用于后续会话）；
- Cache-Control: max-age=3600（资源缓存策略，如缓存 1 小时，减少重复请求）。
响应体（Response Body）：服务器返回的实际资源内容，如 HTML 代码、JSON 字符串、图片二进制数据等（若状态码为3xx、4xx，响应体可能为空或包含错误提示）。

七、阶段 7：关闭 TCP 连接（四次挥手，可选）

若 HTTP 请求的Connection头为close（或 HTTP/1.0 默认），服务器返回响应后会主动关闭 TCP 连接；若为keep-alive（HTTP/1.1 默认），连接会保持一段时间（如 60 秒），供浏览器后续请求（如获取页面中的图片、JS）复用，避免重复握手。

当连接需关闭时，客户端与服务器通过 “TCP 四次挥手” 终止连接：

第一次挥手（客户端→服务器）：客户端发送 “FIN（结束）报文”，标志位FIN=1，表示 “客户端不再发送数据”，客户端状态变为 “FIN_WAIT_1”；
第二次挥手（服务器→客户端）：服务器接收 FIN 后，回复 “ACK 报文”，确认号 = 客户端 Seq+1，表示 “已接收关闭请求”，服务器状态变为 “CLOSE_WAIT”，客户端状态变为 “FIN_WAIT_2”（等待服务器发送自身的 FIN）；
第三次挥手（服务器→客户端）：服务器处理完剩余数据后，发送 “FIN+ACK 报文”，标志位FIN=1、ACK=1，表示 “服务器也不再发送数据”，服务器状态变为 “LAST_ACK”；
第四次挥手（客户端→服务器）：客户端接收 FIN+ACK 后，回复 “ACK 报文”，确认号 = 服务器 Seq+1，客户端状态变为 “TIME_WAIT”（等待 2MSL，确保服务器接收 ACK，避免服务器重发 FIN），服务器接收 ACK 后状态变为 “CLOSED”；客户端等待 2MSL 后，状态也变为 “CLOSED”，连接彻底关闭。

八、阶段 8：浏览器解析与渲染页面（核心步骤）

浏览器接收服务器返回的响应体（如 HTML 文件）后，进入 “页面渲染” 阶段，将 HTML、CSS、JS 等资源转换为用户可见的页面，该过程由浏览器的渲染引擎（如 Chrome 的 Blink、Firefox 的 Gecko）完成，核心分为 6 步：

1. HTML 解析：生成 DOM 树

渲染引擎按 “从上到下” 的顺序解析 HTML 代码，将每个 HTML 标签（如<html>、<div>、<p>）转换为 “DOM 节点（Document Object Model Node）”；
解析过程中，若遇到<link rel="stylesheet">（外部 CSS）或<script>（JS 脚本），会触发额外的资源加载（CSS 加载不阻塞 HTML 解析，但阻塞渲染；JS 加载和执行会阻塞 HTML 解析，需注意优化）；
最终生成一棵完整的DOM 树（文档对象模型树），描述页面的结构和内容（如 “<html>是根节点，包含<head>和<body>子节点，<body>包含<div>子节点”）。

2. CSS 解析：生成 CSSOM 树

渲染引擎解析 CSS 资源（包括 HTML 内联的<style>标签、外部的.css文件、元素的style属性），将 CSS 规则（如div { color: red; font-size: 16px; }）转换为 “CSSOM 节点（CSS Object Model Node）”；
CSSOM 树描述 “每个 DOM 节点应如何样式化”（如<div>节点的颜色、字体大小、边距等），且支持继承（如子节点继承父节点的字体样式）。

3. 样式计算：生成渲染树（Render Tree）

渲染引擎将 “DOM 树” 与 “CSSOM 树” 合并，生成渲染树；
合并规则：仅包含 “可见的 DOM 节点”（如<head>标签、display: none的节点会被排除），并为每个可见节点附加对应的 CSS 样式（如<div>节点的红色字体、16px 字号）；
渲染树不包含 HTML 的结构信息（如<script>、<meta>标签），仅关注 “哪些节点可见、如何显示”。

4. 布局（Layout）：计算节点位置与大小

渲染引擎遍历渲染树，为每个节点计算 “在页面中的精确位置和尺寸”，该过程称为 “布局（Layout）” 或 “重排（Reflow）”；
计算依据：浏览器窗口大小（如 1920×1080）、节点的 CSS 样式（如width: 50%、margin: 20px）、父节点的布局信息（子节点的位置依赖父节点）；
结果：生成 “布局树（Layout Tree）”，记录每个节点的x/y坐标（位置）和width/height（尺寸）。

5. 绘制（Painting）：将节点绘制到图层

渲染引擎按 “布局树” 的顺序，将每个节点的 “样式和布局信息” 转换为 “像素数据”，该过程称为 “绘制（Painting）” 或 “重绘（Repaint）”；
为优化性能，渲染引擎会将页面拆分为多个 “图层（Layer）”（如视频图层、Canvas 图层、有transform属性的节点图层），每个图层独立绘制，避免单个节点变化导致整个页面重绘；
绘制内容：包括背景色、文字、图片、边框等，最终生成每个图层的 “位图（Bitmap）”。