1. 在 Chrome（或其他浏览器）F12 的 Network > Timing 面板里，对于 HTTPS 站点（如 YouTube），它确实不会把“初始连接”（Initial Connection）进一步拆分成“纯 TCP 握手时间”和“纯 SSL/TLS 握手时间”。相反，它把它们合并成一个总时长（你的截图里是 753ms），然后在下面单独标 SSL 的子部分（753.29ms）

3)谷歌浏览器的内置DNS配置台: chrome://net-internals/#dns

• HSTS预载：Google是Chrome内置的HSTS站点列表（Preloaded HSTS），浏览器永久记住“Google必须用HTTPS”。输入http时：\

• 可用使用浏览器的F12看域名的加载时序，来进一步提升自己的运维能力(这个能力如果掌握的话，那还挺重要): 但是针对为啥有些域名看不到对应的详细时序问题，好像是因为F12->应用->service workers的东西。可是我关闭这个玩意后还是看不到具体的

现代浏览器（如Chrome）默认使用DNS over HTTPS (DoH) 或 DNS over TLS (DoT) 来加密DNS查询

1. DNS解析的整体流程（无缓存时的“冷启动”） 假设无任何缓存，流程如下（从本地到全局，递归或迭代方式）：

用户输入URL：在Chrome浏览器中输入 https://www.example.com，浏览器解析域名 www.example.com。 本地检查（Hosts文件 & OS缓存）：浏览器/OS 先查本地静态映射。 浏览器内部查询：如果本地无，浏览器发起DNS查询（可能直接用DoH）。 OS层转发：浏览器通常委托OS的DNS resolver（解析器）处理。 递归DNS服务器查询（通常是ISP或自定义DNS，如8.8.8.8）：

根域名服务器（Root Nameserver）：查询顶级域名（TLD，如 .com）的权威服务器位置。 TLD服务器：查询具体域名的权威服务器（如 example.com 的NS记录）。 权威服务器（Authoritative Nameserver）：返回最终A/AAAA记录（IPv4/IPv6地址）。

响应返回：结果逐层回传，建立TCP连接，加载页面。

整个过程RTT（往返时间）通常<100ms，但缓存能优化到<1ms。HTTPS额外涉及TLS握手，但DNS解析在之前。

Windows的主备DNS切换机制

时间（自开始以来的秒） 操作 0 客户端查询列表的第一个 DNS 服务器 1 如果在 1 秒后未收到响应，客户端将查询列表的第二个 DNS 服务器 2 如果在再 1 秒后未收到响应，客户端会再次查询列表的第二个 DNS 服务器 4 如果在 2 秒后未收到任何响应，客户端会同时查询列表中的所有服务器 8 如果在 4 秒后未收到响应，客户端会同时查询列表中的所有服务器 10 如果在 2 秒后未收到响应，客户端将停止查询