浏览器发出一个 HTTPS 请求，背后发生了什么？
先给出主链路
浏览器解析 URL，查询可用缓存，必要时解析域名、建立连接并完成 TLS，再发送 HTTP 请求。请求经过代理或负载均衡进入应用，应用读取所需数据并返回响应；浏览器处理响应后继续加载资源或渲染页面。具体步骤会因缓存、连接复用和 HTTP 版本不同而变化，不能认定每次请求都要完整走一遍。
DNS 与连接建立
域名解析把主机名转换为可访问地址，结果可能来自浏览器、操作系统或递归解析器缓存。得到 IP 不代表已经知道后端是哪台应用机器，它也可能是 CDN 或负载均衡入口。
HTTP/1.1 和常见 HTTP/2 连接通常基于 TCP；HTTPS 再通过 TLS 验证证书并协商加密参数。HTTP/3 使用基于 UDP 的 QUIC，并把 TLS 握手与传输结合，因此不能说所有 HTTPS 都先做 TCP 三次握手。
TLS 到底验证什么
客户端需要验证证书链、有效期和主机名等条件。加密连接保护传输内容，但不自动保证网站业务可靠，也不能防止应用主动返回错误数据。已有会话可能通过恢复机制减少握手成本；是否生效与协议、客户端和服务端配置有关。
讲延迟时要区分 DNS、连接、握手和服务端响应时间，不能把一个总耗时直接归因于数据库。
HTTP 与应用处理
请求包含方法、路径、请求头和可选请求体。服务端通常执行路由、认证授权、参数校验，再访问缓存、数据库或其他服务。响应则包含状态码、响应头和响应体。代理会影响真实客户端地址的取得，应用只应信任受控代理写入的转发头。
连接可以复用，HTTP/2 还能在单连接上复用多个流。复用不意味着没有队头阻塞、拥塞或服务端资源限制；应根据协议层次分析瓶颈。
缓存与失败怎样追问
强缓存命中时可能无需发网络请求；协商缓存会带上验证条件，服务端可以返回 304，让客户端复用已有内容。CDN 缓存命中也可能让请求不进入应用。用户信息等响应需要正确区分公共与私有缓存，避免跨用户泄露。
排查一次超时，应沿链路找证据：域名是否解析、连接是否成功、证书是否匹配、请求是否到达代理与应用、应用耗时在哪段。用同一请求标识关联日志，再结合浏览器网络面板或链路追踪验证。本文没有执行网络抓包，具体时序需在目标环境观察。
面试时先讲稳定主链路，再补充“缓存可能跳过步骤、连接可能复用、HTTP/3 传输不同”，比把固定流程背成绝对规则更准确。