在地址栏输入https://example.com/products/42后，浏览器可能直接使用缓存，也可能复用已有连接。网络请求使用HTTP/3时，还会走QUIC，而不是先建立TCP连接。
所以，这道题适合先限定情境，再顺着一条请求讲。下面以需要联网获取页面、建立新的HTTPS连接为主线，再说明缓存、连接复用和协议版本会改变哪几步。
图是简化的关系示意，不代表所有阶段串行执行，也不是一次请求的实测耗时图。
URL决定请求什么，不等于服务器上的文件路径
浏览器会解析协议、主机、端口、路径、查询等信息。对于上面的地址：
https说明访问HTTPS资源。example.com是需要定位服务的主机名。/products/42是资源路径，可能由后端路由处理，也可能由静态文件或代理规则响应。
没有显式端口时，HTTP和HTTPS的默认端口分别是80、443。路径为空通常按/处理；是否返回index.html、执行Controller或再重定向，是服务端的映射策略，浏览器不会替服务器挑选一个默认文件。RFC 9110 URI定义
浏览器还需要判断请求是否能由HTTP缓存、Service Worker等已有机制处理。这里继续讨论需要访问网络的情况。
DNS提供地址，查询过程不必每次走到根服务器
浏览器或系统的解析机制需要取得主机名对应的地址，结果可能包含IPv4、IPv6地址，也可能经别名等记录继续解析。缓存命中时，不需要重新从根服务器逐级查询。
需要递归解析时，递归解析器会结合已有缓存，向相关DNS服务器继续查询。根、顶级域和权威服务器的分工可以帮助理解这一过程，但它们不是浏览器每次都依次直连的一张固定清单。RFC 1034
hosts、系统缓存、浏览器缓存、加密DNS以及代理分别怎样参与，取决于实现和配置。面试中把它们背成放之四海而皆准的严格顺序，容易与真实环境对不上。
解析结果也可能指向CDN或负载均衡入口。它不一定是最终运行Java业务服务的那台机器。
HTTPS连接里，TCP与TLS要分别讲
对于基于TCP的新建HTTPS连接，浏览器先建立TCP连接，再进行TLS协商。TLS用于验证服务端身份、协商密钥和算法，使HTTP内容能够受到加密与完整性保护。具体握手行为还与TLS版本、会话恢复等条件有关，不能用一个固定往返次数概括。TLS 1.3规范
HTTP版本会改变传输方式：
| 使用情境 | 连接层的主要区别 |
|---|---|
| HTTP/1.1或HTTP/2的HTTPS新连接 | 基于TCP，并使用TLS；HTTP/2可以在一个连接上承载多个流 |
| HTTP/3 | HTTP语义映射到QUIC；QUIC基于UDP并集成TLS安全握手，不是先做TCP三次握手 |
| 已有可复用连接 | 本次请求可能直接使用连接，不会再重复完整建连过程 |
浏览器采用哪一种，需要结合服务端支持、协议发现、网络条件和协商结果判断。不能因为地址是https://，就断言一定使用HTTP/1.1或一定新建TCP连接。HTTP/3规范
请求怎样经过本地链路与路由器
应用数据要通过传输层、IP网络和具体链路发送。以IPv4以太网为例，本机根据路由决定下一跳；目标在远端网络时，以太网帧先发往下一跳网关，目标MAC不是远端网站服务器的MAC。需要时，通过ARP解析当前链路上的下一跳地址。IPv6采用的邻居发现机制不同，不能把ARP推广到所有网络。
路由器继续转发时，会按出站链路重新封装。在不做地址转换等改写的普通IP转发中，端到端的源、目标IP可以保持不变；MAC随链路改变，IPv4的TTL也会递减。经过NAT时，地址甚至端口可能被转换。因此，“整个途中IP永远不变”需要加上适用前提。IPv4路由要求、NAT说明
这些网络动作不是等HTTP请求写好后才第一次发生：前面的DNS、TCP和TLS通信同样要经过网络。分层是在解释每份数据怎样传输，不是一组只执行一次的独立步骤。
服务端响应与浏览器渲染会继续交错
以HTTP/1.1的文本形式表示，请求可以写成：
GET /products/42 HTTP/1.1 Host: example.com Accept: text/html这是报文语义示例。HTTP/2、HTTP/3使用各自的帧和字段编码，不能把上面三行当成它们在网络中的原始字节格式。
入口服务器可能直接返回静态资源，也可能把请求交给后端应用。应用读取数据、生成内容后返回状态码、响应头和响应体；如果返回重定向，浏览器还需要按相应规则处理后续请求。
取得HTML后，浏览器解析文档构建DOM，解析样式形成样式信息，计算布局并绘制，必要时再进行合成。它会在解析期间发现样式、脚本、图片等资源，继续发起请求。下载、解析和部分渲染可以交错推进；脚本也可能阻塞解析或改变文档，导致后续样式、布局和绘制变化。
资源请求会使用缓存和连接复用，HTTP/2、HTTP/3还支持多路复用。不能说每张图片都要重新完成DNS、建连和整套握手，也不能把“页面显示完”直接当作关闭连接的信号。浏览器渲染过程
用Network面板把这些阶段对应到现象
在Chromium浏览器的开发者工具中，打开Network后访问一个允许测试的页面。对主文档请求，重点查看：
- Protocol列：实际使用的是HTTP/1.1、h2还是h3。需要时从表头菜单打开该列。
- Timing：有没有DNS、建立连接等阶段，时间主要花在哪里。复用连接或命中缓存时，部分阶段可能不再出现。
- 响应来源与瀑布图：内容是否来自缓存或Service Worker；HTML、样式、脚本、图片的请求怎样重叠。
Waiting / TTFB包含等待首字节的网络与服务端时间，不等于纯粹的数据库耗时。看到某个阶段很长，只能先缩小排查范围，随后还要结合服务端日志或链路追踪判断。Chrome Network时序说明
讲清这道题时，可以先给出当前情境下的主线，再挑一个实际观察解释“为什么某一步没有出现”。这样既能说明协议，也能把回答接到性能分析和故障排查上。
修订于2026年11月1日：移除笔记对话残留，补HTTPS、HTTP/3、缓存复用、URL映射与地址变化的条件。
/YOLO火焰烟雾检测)
/YOLO工程车辆检测)
