C05 · 第 5 章 · 应用与测量
DNS、HTTP 与 TLS
说明 DNS 查询和缓存、HTTP 请求及条件验证、TLS 身份认证，按明确的握手假设计量首次 HTTPS 请求的时间。
本章目标
- 区分递归解析器和权威服务器并计算剩余 TTL。
- 解释 HTTP 状态码、ETag 和条件请求的处理关系。
- 区分网络连接、TLS 名称验证与应用身份认证。
- 按连接复用和握手条件分解 HTTPS 请求时延。
本页目录
域名查询与缓存
浏览器访问一个 HTTPS 地址时，首先需要确定域名对应的网络地址。域名系统 DNS 以层次名称组织记录，解析器根据查询名称和记录类型寻找答案。A 记录提供 IPv4 地址，AAAA 记录提供 IPv6 地址，CNAME 记录指向另一个名称；同一名称可能有多条记录，实际连接地址还受到客户端选择策略和网络条件影响。
用户设备通常把问题交给递归解析器，后者利用缓存或向其他 DNS 服务器查询。权威服务器负责某个区域中的记录，递归解析器负责为客户端完成查找，两者职责不同。递归服务得到地址结果后，浏览器仍需要建立连接并请求资源，DNS 查询成功只完成了名称解析阶段。
记录的生存时间 TTL 指示正常缓存的保留期限，单位为秒。缓存命中时通常使用剩余期限，普通客户端的一次命中不会自动把原始记录重新延长一个完整周期。DNS 还存在否定缓存、提前刷新和过期应答扩展，具体行为取决于所用机制；下面的练习采用按 TTL 到期后重新查询的基本缓存模型。
RFC 1034: Domain Names - Concepts and Facilities
P. Mockapetris · 1987 · RFC Editor
打开官方来源RFC 1034 第三至第五节介绍域名空间、服务器和解析器。它为名称的层次关系与缓存机制提供基础定义，部署时涉及的记录类型、安全扩展和具体错误处理还需查看相应的后续规范。
解析器在时刻零得到一条 TTL 为三百秒的地址记录，之后不提前刷新。客户端在第一百四十秒查询相同名称和记录类型，第二次查询发生在第三百二十秒，求两次查询的缓存处理。
第一次查询时，缓存还剩 ，解析器直接返回缓存答案并附带相应剩余 TTL。这个命中没有新的权威查询，因此到期时刻仍为第三百秒。第二次查询已经越过到期时刻，基本模型下需要重新查询；新响应的缓存期限根据新响应携带的 TTL 计算。
若权威服务器在第两百秒改变地址，第一条记录仍可能在既有缓存中保留到第三百秒。我们检查时间轴可以看到，调整权威记录与所有客户端立即获得新答案是两个不同事件。提前降低 TTL 也只影响后续得到的记录，已经缓存的旧答案仍按其剩余期限处理。
HTTP 请求与响应
HTTP 为资源请求定义方法、状态码、字段和消息内容。GET 请求获取资源表示，HEAD 请求返回相应首部而不传输响应内容，POST 等方法具有各自语义。服务器响应状态码帮助客户端判断结果类别，例如成功、重定向、客户端错误或服务端错误，应用还应根据具体状态和字段决定后续行为。
请求中的主机或授权标识用于区分同一服务地址承载的不同站点，路径和查询参数进一步指定资源。域名解析得到的 IP 地址不能代替 HTTP 层的站点标识，直接把 URL 中域名换成 IP 也会影响 TLS 名称验证。调试时应保留原始域名语义，仅在确有需要时使用能分别指定连接地址与名称的工具选项。
HTTP 缓存需要依据响应的缓存策略和新鲜度判断是否复用表示。过期的缓存可以携带验证条件，例如 If-None-Match 配合 ETag；若服务器确认表示未改变，返回 304，客户端继续使用原先保存的内容。304 并不携带重新下载的完整表示，因此缺少对应缓存内容的程序不能把它当作一个新的完整文件。
RFC 9110: HTTP Semantics
R. Fielding, M. Nottingham, J. Reschke · 2022 · RFC Editor
打开官方来源RFC 9110 定义 HTTP 方法、响应状态和条件请求的语义。HTTP/1.1、HTTP/2 与 HTTP/3 采用不同的消息传送方式，但这些共同语义仍然适用；性能分析时需要同时注明协议版本和连接复用情况。
TLS 握手与名称验证
HTTPS 在 HTTP 通信中加入 TLS 保护。TLS 握手协商密码参数、建立会话密钥，并在通常的服务器证书模式下验证服务器身份。客户端检查证书链、有效期和访问名称与证书的匹配关系；加密会话只有在身份验证正确完成后，才对应预期的服务端身份。
TLS 的记录保护提供传输中的机密性和完整性，应用仍需自行处理登录、权限与输入验证。服务器证书认证与用户登录分别确认不同主体，不能互相替代。DNS 返回错误地址时，正确的证书验证通常会阻止客户端把其他站点当作目标站点；如果程序忽略验证错误，这个判断条件就被破坏。
TLS 1.3 的普通完整握手在已建立的可靠传输上通常增加一个往返周期，前提是无需额外的 HelloRetryRequest，并忽略计算和报文发送时间。连接恢复和早期数据具有不同条件，早期数据还需要应用处理重放语义。本节计时采用普通完整握手，不把恢复情形的时延优势混入首次连接。
RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla · 2026 · RFC Editor
打开官方来源RFC 9846 是二〇二六年更新的 TLS 1.3 规范，其协议概览与握手章节说明消息顺序和认证内容。对照该规范阅读证书和握手日志时，应区分协商版本、证书验证结果与应用响应，三者可能分别成功或失败。
首次请求的时间组成
设 DNS 查询需要二十毫秒，到服务器的往返时间为四十毫秒。客户端使用普通 TCP 三次握手、TLS 1.3 完整握手和 HTTP 请求；不发生重试，不使用早期数据，服务器处理时间与报文发送时间忽略。求从开始解析到收到首个响应字节的近似时间。
DNS 用去 。客户端收到 TCP 握手响应并继续发送后续握手数据，按一个往返周期计入 TCP 建立时间；普通 TLS 完整握手再计一个往返周期，HTTP 请求发出到首字节返回再计一个往返周期。因此
若连接已经建立并保持空闲可用，且没有新 DNS 查询和排队，同样的 HTTP 请求只需约四十毫秒到达首字节。这个结果只计算首字节，下载整个文件还要加入内容传输时间。检查时应把每段握手放在时间轴上，避免同时把 TCP 最后一个 ACK 的单向传输另加一次，造成重叠阶段的重复计数。
真实页面还会请求样式、脚本、图片与其他资源，依赖关系影响请求启动时刻。浏览器缓存、连接复用和并行请求会改变总加载时间，服务器处理与渲染也会占用时间。因此，页面完成时间应结合实际请求序列分析，不能把单个请求的首字节时间直接当作整个页面速度。
名称、连接与响应的故障定位
访问失败时，我们先保存具体错误和发生阶段。域名不存在与解析器超时属于不同结果；TCP 连接被拒绝与连接超时也需要分别处理。TLS 失败时应读取验证原因和协商信息，HTTP 返回错误状态时则已经完成了前面的若干通信步骤，可以继续检查路径、权限和服务端响应内容。
一次成功访问仍可能使用缓存答案、已有连接或本地缓存内容。验证新配置时应明确是否建立了新连接、使用哪个解析器以及响应是否来自缓存，必要时在受控条件下比较两组结果。实验报告可记录解析时间、连接时间、TLS 完成时间、首字节时间和总时间，帮助判断变化来自哪一阶段。
Web 协议练习
这些题目使用明确的握手与缓存假设。计算时先列出已经存在的状态，再决定哪些阶段仍需执行；分析协议错误时则保留原始错误类别，避免把所有失败都归为网络断开。每个回答应指出对应的名称解析、传输、身份验证或应用阶段。
解析器在第三十秒缓存一条 TTL 为一百二十秒的记录。按基本缓存模型，第一百秒查询时剩余多久，记录在哪个时刻到期？
查看解答
到期时刻为 秒；第 100 秒查询时剩余 50 秒。缓存命中不改变这个到期时刻。
DNS 已缓存，服务器往返时间为三十毫秒，但没有现有连接。沿用完整握手假设，首字节时间下界近似为多少？
查看解答
DNS 缓存命中省去查询等待，但仍需普通 TCP 建立、TLS 完整握手和 HTTP 请求三个往返周期，总计 。
客户端收到 304 后应从哪里取得内容？若本地已经丢失原缓存文件，能否把这次响应当作完整下载结果？
查看解答
客户端已经保存对应 ETag 的完整表示，发送条件请求后收到 304 时继续使用该表示。若没有对应缓存内容，应重新请求完整表示，并按响应的缓存策略保存。
某主机的四百四十三端口能够连接，但证书名称与访问域名不匹配。连接成功能否说明目标站点的 HTTPS 身份验证已经通过？解释涉及的两个检查。
查看解答
连接地址说明数据发往哪里，证书名称验证说明对端是否对应所访问的名称。即使端口建立成功，证书名称不匹配仍表示身份验证失败，应检查访问名称、证书配置与解析结果。