QUIC および HTTP/3 パケット キャプチャのトラブルシューティング: UDP から学べること

QUIC と HTTP/3 では、トランスポートが UDP 上で実行され、ほとんどのアプリケーション データが暗号化されるため、パケット キャプチャ分析が難しく感じられます。 TCP シーケンス番号に慣れているエンジニアは、QUIC キャプチャを開いて、有用な証拠が消えてしまったように感じるかもしれません。

それは消えませんでした。証拠が変わりました。

QUIC キャプチャで何がわかるか

アプリケーション データを復号化しなくても、PCAP では次のことが表示されることがよくあります。

• ポート 443 へのクライアント UDP パケット
• サーバーの UDP 応答
• 接続ID
• パケットサイズ
• ハンドシェイクのタイミング
• UDP パケット レベルでの再送信のような動作
• パスの変更
• TCP/TLS へのフォールバック
• ICMPエラー
• ファイアウォールまたは NAT ドロップ

クライアントが QUIC Initial パケットを送信してもサーバーが応答しない場合は、UDP ブロック、サーバー ポリシー、ルーティング、またはミドルボックスの動作に問題がある可能性があります。 QUIC が失敗し、クライアントが TCP/TLS にフォールバックした場合、そのフォールバックは重要な証拠となります。

UDP 443 は、TCP 443 とは異なる方法でブロックされることがよくあります

多くのネットワークでは、TCP 443 は許可されていますが、UDP 443 は制限されています。サイトは HTTP/2 では動作しますが、HTTP/3 では失敗したり機能が低下したりすることがあります。ユーザー側から見ると、これはブラウザのランダムな速度低下や接続障害のように見える場合があります。

質問をキャプチャします:

• クライアントは UDP 443 を試行しましたか?
• サーバーは応答しましたか？
• ICMP は到達不能を報告しましたか?
• クライアントは再試行しましたか?
• クライアントは TCP 443 にフォールバックしましたか?
• フォールバックまでにどのくらいの時間が失われましたか?

これは、パケット キャプチャによって、「HTTPS が機能する」ことが「HTTP/3 が機能する」と同じではないことを証明できる方法です。

QUIC タイミングは依然として重要

QUIC は暗号化された UDP パケット内の信頼性を処理するため、従来の TCP 分析ラベルは直接適用されません。ただし、パケットのタイミングは依然として重要です。

• 同じようなサイズのパケットが繰り返される
• サーバー応答前のギャップ
• 喪失後に破裂する
• パケットサイズの変化
• パス間の移行
• フォールバックまでの長い遅延

これらのパターンは、ストリームを復号化しなくてもネットワーク診断をサポートできます。

PCAP 手術が適している場所

PCAP 手術は、エンジニアが関連する UDP フローを分離し、タイミングを維持し、共有可能なキャプチャを準備するのに役立ちます。 QUIC ケースでは、多くの場合、フォールバックに関するコンテキストが必要です。

• DNSクエリ
• UDP 443 の試行
• サーバーの応答または不在
• TCP 443 フォールバック
• フォールバック後の TLS ハンドシェイク
• タイミングへの影響

キャプチャがサニタイズされた場合でも、接続 ID とパケット サイズが役立つ可能性があります。プライバシー ポリシーで要求されている場合にのみ削除し、変更内容を記録してください。

「QUIC パケット キャプチャ」、「HTTP/3 UDP 443 がブロックされました」、または「TCP への QUIC フォールバック」などの検索の場合、ペイロードが暗号化されているため、答えはあきらめません。トランスポートのタイミングとフォールバック パスは依然として有益なストーリーを伝えます。