浏览器F12
约 718 字大约 2 分钟
2025-10-31
- 在 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查询
- 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 秒后未收到响应,客户端将停止查询
