PCAP 中的 HTTP 慢请求和 TTFB:证明延迟是 DNS、TCP、TLS 还是服务器时间

“网站速度慢”和“API 请求需要 10 秒”不是诊断。数据包捕获可以将延迟分为几个阶段：DNS 查找、TCP 握手、TLS 握手、请求上传、服务器处理、响应下载、重传和客户端行为。

“第一个字节的时间”通常是用户搜索的短语。在数据包证据中，TTFB 并不是一个单一的魔法领域。这是一个时间线。

建立请求时间表

对于 HTTP 或 HTTPS 请求，请检查：

• DNS查询开始
• DNS 响应时间
• TCP同步
• TCP握手完成
• TLS 客户端Hello
• TLS ServerHello 和证书
• 发送的 HTTP 请求字节数
• 第一个响应字节
• 完整响应完成
• 重传或重置

如果 DNS 需要 5 秒，那么服务器还不算慢。如果 TCP 握手很快，但第一个响应字节迟到，则服务器处理或上游依赖性可能是问题。如果 TLS 在 HTTP 之前停止，请重点关注证书、密码、SNI 或中间件行为。

基于 TLS 的 HTTP 需要谨慎的边界

在 HTTPS 捕获中，有效负载可能会被加密，但时间仍然很重要。您通常可以识别：

• 连接开始
• 握手持续时间
• 来自客户端的加密应用程序数据
• 首先从服务器加密应用程序数据
• 丢包或重传
• 连接关闭或重置

即使不解密内容，捕获也可以显示延迟是发生在请求发送之前还是之后。

留意重传

HTTP 速度慢可能是由于数据包丢失造成的。如果在请求上传或响应传递过程中出现 TCP 重传或重复 ACK，则服务器可能不是主要所有者。服务器到客户端路径上丢失的大量响应对于用户来说可能看起来像是后端延迟。

报告应分开：

• 请求离开客户端之前的时间
• 时间服务器似乎正在处理
• 重传响应所花费的时间
• 客户端接收窗口行为

这种区别可以防止后端团队追查网络问题。

PCAP 手术适合的场合

当原始捕获太大或太敏感时，PCAP 手术非常有用。集中的 HTTP 延迟切换应保留：

• DNS窗口
• TCP握手
• TLS 握手（如果存在）
• 请求/响应时间
• 重传证据
• 重置或警报
• 原始时间戳

如果需要匿名，请在重要时保留时间和数据包大小。删除太多上下文可能会使 TTFB 分析变得不可能。

对于诸如“HTTP 慢速请求 pcap”、“第一个字节数据包捕获时间”或“API 延迟 Wireshark”之类的搜索，答案是一个逐阶段的时间线，而不是一个单一的责任标签。