PCAP での HTTP 低速リクエストと TTFB: 遅延が DNS、TCP、TLS、またはサーバー時間によるものかどうかを証明する

「Web サイトが遅い」「API リクエストに 10 秒かかる」は診断ではありません。パケット キャプチャでは、遅延を DNS ルックアップ、TCP ハンドシェイク、TLS ハンドシェイク、リクエストのアップロード、サーバーの処理、レスポンスのダウンロード、再送信、クライアントの動作のフェーズに分割できます。

最初のバイトまでの時間は、ユーザーがよく検索するフレーズです。パケット証拠において、TTFB は単一の魔法のフィールドではありません。タイムラインです。

リクエストのタイムラインを構築する

HTTP または HTTPS リクエストの場合は、以下を検査します。

• DNSクエリ開始
• DNS応答時間
• TCP SYN
• TCPハンドシェイクの完了
• TLS ClientHello
• TLS ServerHello と証明書
• 送信されたHTTPリクエストバイト数
• 最初の応答バイト
• 完全な応答完了
• 再送信またはリセット

DNS に 5 秒かかる場合、サーバーはまだ遅くなっていません。 TCP ハンドシェイクは速いが、最初の応答バイトが遅い場合は、サーバーの処理またはアップストリームの依存関係に問題がある可能性があります。 TLS が HTTP の前に停止する場合は、証明書、暗号、SNI、またはミドルボックスの動作に注目してください。

HTTP over TLS には慎重な境界が必要

HTTPS キャプチャでは、ペイロードが暗号化される可能性がありますが、それでもタイミングが重要です。多くの場合、次のことが特定できます。

• 接続開始
• ハンドシェイク時間
• クライアントからの暗号化されたアプリケーション データ
• サーバーからの最初の暗号化されたアプリケーション データ
• パケット損失または再送信
• 接続を閉じるかリセットする

コンテンツを復号化しなくても、リクエストの送信前または送信後に遅延が発生したかどうかをキャプチャで確認できます。

再送信に注意する

HTTP が遅いのは、パケット損失が原因である可能性があります。リクエストのアップロードまたはレスポンスの配信中に TCP の再送信または重複した ACK が発生した場合、サーバーがプライマリ所有者ではない可能性があります。サーバーからクライアントへのパスで損失を伴う大規模な応答は、ユーザーにとってバックエンドの遅延のように見える可能性があります。

レポートは次のものに分けて行う必要があります。

• リクエストがクライアントを離れるまでの時間
• タイムサーバーが処理しているようです
• 応答の再送信に費やした時間
• クライアント側の受信ウィンドウの動作

この区別により、バックエンド チームがネットワークの問題を追跡するのを防ぐことができます。

PCAP 手術が適している場所

PCAP 手術は、元のキャプチャが大きすぎるか、感度が高すぎる場合に役立ちます。集中的な HTTP 遅延ハンドオフでは、以下を維持する必要があります。

• DNSウィンドウ
• TCPハンドシェイク
• TLS ハンドシェイク (存在する場合)
• リクエスト/レスポンスのタイミング
• 再送信の証拠
• リセットまたはアラート
• 元のタイムスタンプ

匿名化が必要な場合は、重要なタイミングとパケット サイズを保存します。コンテキストを削除しすぎると、TTFB 分析が不可能になる可能性があります。

「HTTP スロー リクエスト pcap」、「最初のバイト パケット キャプチャまでの時間」、または「API レイテンシ Wireshark」などの検索の場合、答えは単一の責任ラベルではなく、フェーズごとのタイムラインです。