计算机网络问答 02：协议流程与关键机制

结论： 典型冷路径依次包含 URL 与安全策略处理、名称解析、路由与邻居解析、传输连接、TLS、HTTP 请求和服务端响应。

原因： 每一步为下一步提供地址、路径、可靠通道、身份与加密参数，最后服务端处理并返回响应首字节。

边界： 缓存、连接复用、HTTP/3、代理、Service Worker 和 CDN 会跳过或改写部分步骤，不能假定每次都完整执行。

排查或示例： 用 Navigation Timing、浏览器网络面板和抓包对齐 DNS、connect、TLS、request 与 responseStart 时间点。

结论： 递归器从缓存开始，未命中时通常按根、顶级域、权威服务器的委派链执行迭代查询。

原因： 每级服务器返回下一层 NS 或最终资源记录，递归器汇总结果并按 TTL 缓存后回复客户端。

边界： 转发器、分视图、DNSSEC、CNAME 链和负缓存会改变路径，根服务器不保存所有主机最终地址。

排查或示例： 使用 dig 的 trace 或分别查询各级 NS，可定位委派错误、glue 缺失和权威数据不一致。

结论： 递归器、操作系统、浏览器和应用都可能在 TTL 或自身策略内继续使用旧答案。

原因： DNS 是分布式系统，权威更新不会主动推送并清空全球缓存；NXDOMAIN 也可能被否定缓存。

边界： TTL 不是精确切换时刻，应用连接池、代理和 CDN 还可能继续保持到旧地址的连接。

排查或示例： 发布前降低 TTL，切换时查询多个递归器并检查本地缓存、连接复用和旧地址流量，最后再回升 TTL。

结论： 发送端可依据重传超时或重复确认等信号推断丢包，并重传缺失的序列范围。

原因： 序列号和确认号描述已发送与已接收的字节位置，RTT 估计用于计算合理的重传超时。

边界： ACK 本身可能延迟或丢失，SACK、RACK 等机制和拥塞算法属于具体实现，不能只看单个重复 ACK。

排查或示例： 抓包时结合序列号、ACK、重传标记和双端时间线，区分真实丢包、乱序与抓包点遗漏。

结论： 高带宽高 RTT 链路需要足够大的在途窗口才能填满链路，所需规模可用带宽时延积近似估算。

原因： 发送方在等待确认期间只能保持窗口允许的未确认数据，窗口太小会让链路大部分时间空闲。

边界： 实际吞吐还受丢包、拥塞算法、接收窗口、应用读写和中间设备影响，公式不是吞吐保证。

排查或示例： 跨地域传输慢时对照 RTT、cwnd、rwnd 和链路容量，判断是否为窗口受限或丢包触发退让。

结论： MTU 限制链路可承载的 IP 包大小，TCP MSS限制段负载；路径 MTU 发现用于找到整条路径最小 MTU。

原因： IPv4 可能由路由器分片，IPv6 路由器不分片，发送端需依据 ICMP 太大消息调整报文。

边界： ICMP 被过滤可能形成 MTU 黑洞；网卡卸载也会让本机抓包显示大于实际链路帧的报文。

排查或示例： 小请求正常、大响应卡住时测试 DF 报文、检查 ICMP、隧道额外头部和 TCP MSS clamping。

结论： 握手协商协议参数、验证服务器身份并通过密钥交换派生会话密钥，随后应用数据受到机密性和完整性保护。

原因： ClientHello 提供版本、密钥份额和扩展，服务器选择参数并发送身份材料，双方验证 Finished 后进入应用数据阶段。

边界： 当前 TLS 1.3 规范是 RFC 9846，它兼容并取代 RFC 8446；会话恢复和 0-RTT 会缩短部分交互。

排查或示例： 用 TLS 调试输出检查版本、密码套件、证书链、SNI、ALPN 和恢复状态，而不是只测试端口是否开放。

结论： 客户端至少要验证信任链、证书有效期、目标主机身份和签名，并考虑吊销或本地策略。

原因： 信任锚为证书链提供根信任，SAN 将证书绑定到域名，签名证明链上证书未被篡改。

边界： 证书未过期不等于可信；企业代理可能安装自有根证书，时钟错误也会导致看似异常的验证失败。

排查或示例： 证书错误时导出完整链并核对 SAN、Issuer、有效期、本机时间、SNI 和客户端信任库。

结论： SNI 告诉服务器客户端访问的主机名，ALPN 用于协商 HTTP/1.1、HTTP/2 等上层协议。

原因： 同一 IP 可托管多个证书和站点，服务器需要在早期选择证书；TLS 内的协议协商避免额外往返。

边界： SNI 与 HTTP Host 处在不同阶段，ECH 等机制可能保护 ClientHello 中的部分信息，HTTP/3 的协商路径也不同。

排查或示例： 多域名站点证书错配时同时检查客户端 SNI、负载均衡证书选择、ALPN 和后续 HTTP authority。

结论： 无状态描述请求语义可独立理解，应用可以通过 Cookie、令牌或显式标识关联服务端状态。

原因： 客户端在每次请求携带凭据，服务端据此加载用户或会话数据，因此状态不必绑定到传输连接。

边界： 认证凭据需要防窃取、防伪造和过期控制；同一连接可能承载多个请求，不能把连接等同用户身份。

排查或示例： 多实例部署可用签名令牌或共享会话存储，并确保代理转发和缓存不会泄露个性化响应。

结论： 它们复用已经建立的传输和加密连接，减少重复握手、慢启动和系统调用成本。

原因： 同一来源的后续请求可直接发送，服务端到下游的连接池也能复用已认证的通道。

边界： 连接有空闲超时、DNS 变化、证书更新和并发上限；长期复用可能继续命中旧后端或失效连接。

排查或示例： 监控新建连接率、复用率、握手时间和连接年龄，并为 DNS 切换与故障准备最大生命周期。

结论： 同一连接上的响应必须保持请求顺序，前一个慢响应会阻塞后续响应，这就是应用层队头阻塞。

原因： HTTP/1.1 缺少像 HTTP/2 那样的独立流，多数客户端因复杂性很少启用管线化，而改用多个连接。

边界： 增加连接会带来额外握手和拥塞状态；服务端内部排队同样可能造成延迟但不属于同一机制。

排查或示例： 瀑布图显示同连接请求串行等待时，可通过连接复用策略、HTTP/2 或拆分慢资源进行验证。

结论： HTTP/2 把消息拆为带流标识的帧，多条流的帧可以交错传输，并由每流和连接级流量控制协调。

原因： 二进制 framing 允许接收端把帧重新归属到对应流，HPACK 则减少重复字段开销。

边界： 所有流仍共享 TCP 的有序字节流，底层丢包会暂时影响该连接；流优先级也不是资源保证。

排查或示例： 分析延迟时同时查看 HTTP/2 流、SETTINGS、窗口更新和 TCP 重传，不能只看请求是否并发发出。

结论： QUIC 在 UDP 上整合 TLS 1.3、可靠流、多路复用、拥塞控制和连接迁移，减少部分握手与连接级阻塞。

原因： 每条 QUIC 流有独立有序交付，某流丢包通常不会阻塞其他流已经到达的数据。

边界： QUIC 不是不可靠传输，也不是没有拥塞控制；UDP 被阻断时客户端仍需要回退到 TCP 协议栈。

排查或示例： 移动网络切换时观察 Connection ID 和路径验证，可验证 QUIC 是否保持连接而非重新建立 TCP。

结论： 两者共享 RFC 9110 定义的 HTTP 核心语义，主要区别在 framing、字段压缩和底层传输。

原因： HTTP/3 使用 QUIC 与 QPACK，HTTP/2 主要运行于 TCP 与 TLS，并使用 HPACK。

边界： 相同方法和状态码不保证部署行为完全相同，协议发现、代理支持、UDP 策略和回退会影响路径。

排查或示例： 服务端开启 h3 后应验证 Alt-Svc、UDP 443、协商结果和 h2 回退，而不是修改业务 API 语义。

结论： 正向代理代表客户端选择外部目标，反向代理作为服务入口接收请求后选择内部上游。

原因： 两者都可能建立两段连接、终止 TLS、缓存或修改字段，但受控方和使用目的不同。

边界： 透明代理、网关和服务网格会让边界更复杂，转发头只有来自可信代理时才可作为身份依据。

排查或示例： 绘制客户端到代理、代理到上游两段五元组和 TLS 终止点，可解释日志源地址与证书位置。

结论： 只需高性能转发通用连接时可考虑四层，需要按主机、路径、Header 或 Cookie 路由时使用七层。

原因： 四层通常以连接五元组调度，七层理解应用消息并能执行重写、认证、缓存等策略。

边界： 七层能力带来解析与终止成本；长连接下按连接调度可能导致负载倾斜，必须结合业务流量形态。

排查或示例： HTTP API 可按路径路由到不同服务，数据库或自定义 TCP 则常使用四层转发并独立做健康检查。

结论： 有效缓存命中通常由边缘直接返回，不回源；未命中、过期、重新验证或不可缓存请求仍会访问源站。

原因： 边缘根据缓存键、Freshness、Vary、验证器和策略判断能否复用已有表示。

边界： 动态加速、边缘计算和分层缓存可能继续访问上层节点；命中状态必须以响应头和平台日志确认。

排查或示例： 排查回源压力时统计 HIT、MISS、REVALIDATED 和 BYPASS，并检查 Query、Cookie 是否造成缓存键碎片。

结论： 经典 WebSocket 先通过 HTTP Upgrade 建立协议切换，成功后在同一传输连接上交换 WebSocket 帧。

原因： 握手借用 HTTP 的 URI、Header、认证和代理能力，切换后消息 framing 与普通 HTTP 请求响应不同。

边界： HTTP/2 和 HTTP/3 还有扩展 CONNECT 等承载方式，具体客户端与代理支持需要验证。

排查或示例： 握手返回 101 但随后断连时分别检查代理 Upgrade 支持、空闲超时、心跳和 WebSocket 帧日志。

结论： 它通过错开并竞争多个地址族连接，避免首选地址族故障导致用户等待很长超时。

原因： 客户端根据 DNS 返回、历史和计时策略发起候选连接，选择较早成功者并取消其他尝试。

边界： 这不意味着双栈问题可以忽略；失败的 IPv6 仍会增加连接竞争、日志噪声和资源开销。

排查或示例： 发现客户端总走 IPv4 时分别测试 AAAA、IPv6 路由和防火墙，并分析连接尝试时间线。