はじめに
Grove の 2 人の訪問者が、Lantern Photography の情報を開く際の待機を報告しています。正常な参考と影響を受けた 2 訪問が 1 つのキャプチャに記録されています。長い区間がリクエスト送信後にあるのか、次のリクエストが現れる前にあるのかを調べます。
前のラボの HTTP フィルター、Follow TCP Stream、リクエストとレスポンスのリンクを知っていることが前提です。このラボは新しい独立した Desktop 環境で始まります。時間参照と厳密に定義された 2 区間を学びます。プログラミングやサーバー修復は不要です。これらの制御された記録から分かるのはパケットの時間関係であり、ブラウザー描画やサーバー CPU については断定できません。
リクエストとレスポンスを測定する
このステップでは Aspen の最初の詳細トランザクションを測定します。Desktop から始め、左下の Applications → Terminal Emulator を開き、新しい入力で Wireshark を起動します。
wireshark /home/labex/project/event-page/input/casebook.pcapng
Wireshark を最大化します。サービスは 127.0.0.1:18182 です。Maple（127.0.0.5）が正常な参考、Aspen（127.0.0.6）と Elm（127.0.0.7）が報告された訪問、Pine（127.0.0.8）は無関係です。各訪問は持続接続で一覧、詳細、プログラム、再度詳細を要求します。持続とは、複数のリクエスト・レスポンス交換の間、接続を開いたままにすることです。
Aspen の HTTP メッセージを絞り込みます。
ip.addr == 127.0.0.6 && http
最初の詳細 GET を選び、HTTP を展開して X-Request: aspen-02 を読みます。Response in frame → right-click → Go to Linked Packet で実際のレスポンスへ移動し、逆向きの Request in frame も確認します。入力のリクエストは 42、レスポンスは 46 です。
レスポンスの Time since request を探し、右クリックして Apply as Column を選びます。値は約 1.6017 秒です。1 秒は 1,000 ミリ秒なので、約 1601.7 ms です。
これはこの記録のリクエスト HTTP 解析フレームから、対応するレスポンス HTTP 解析フレームまでの区間です。Wireshark は再構成の最後のセグメントで完全なメッセージをデコードする場合があります。サーバー CPU 時間、ブラウザーのページ読み込み時間、レスポンスの最初のバイトまでの時間と呼ばないでください。
時間参照で区間を目で確認します。リクエストフレーム 42 を選び、Edit → Set/Unset Time Reference を実行します。このバージョンのショートカットは Ctrl+T です。View → Time Display Format で Seconds Since Beginning of Capture を選びます。参照を設定すると、この形式はその参照を使います。リクエストに *REF* が付き、ゼロとして扱われ、対応するレスポンスは約 1.6017 秒後になります。比較後は参照パケットを右クリックし、同じコマンドで参照を解除します。
この対応付けに Seconds Since Previous Captured Packet や Previous Displayed Packet を使わないでください。現在の一覧で隣接するパケットが対応リクエストとは限りません。フィルターを変えると、前に表示されたパケットも変わります。時間参照はキャプチャに永続保存されません。他の分析担当者が再現できるよう、明示的なフレーム番号と測定区間を記録します。
次のプログラムリクエスト aspen-03 をフレーム 48 で見つけます。詳細レスポンス 46 からリクエスト 48 の空白は約 0.3 ms です。レスポンスを参照にしてプログラムリクエストの相対時刻を読み、参照を解除します。この 空白 が 2 つ目の指標です。指定した 2 つの解析フレーム間の区間であり、一般的なユーザーの思考時間ではありません。
ここではフレーム 46 が *REF* です。フレーム 48 の Time 列を読みます。0.000312566 秒は約 0.3 ms です。一方、フレーム 46 の Time since request 列は依然としてその自身のリクエスト・レスポンス対を表します。これらは別の区間です。
2 つ目の Desktop 端末と Mousepad で /home/labex/project/event-page/output/timing.csv を作ります。もう一度 Applications → Terminal Emulator を開き、実行します。
mousepad /home/labex/project/event-page/output/timing.csv
列は訪問、最初の詳細リクエスト、そのレスポンス、次のプログラムリクエスト、ミリ秒での 2 区間、観測した段階を示します。リクエストからレスポンスが長ければ after、次のリクエスト前の空白が長ければ before、どちらも長くなければ normal を使います。この記録では 800 ms を超える区間を長いとします。これは学習用のしきい値であり、本番の性能目標ではありません。丸め誤差 5 ms 以内が許容されます。
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
Ctrl+S で保存します。証拠は Aspen の長い待機を詳細リクエストの後に位置付けます。サーバー内部の原因を特定するものでも、すべてのネットワーク要素が正常だと証明するものでもありません。
空白を比較して証拠を保持する
Elm と正常な Maple の訪問を Aspen と比較し、必要な完全な会話を保存します。Desktop で Wireshark と元の入力に戻って始めます。新しい測定の前にすべての時間参照を解除します。
Elm を絞り込みます。
ip.addr == 127.0.0.7 && http
HTTP フレームリンクで最初の詳細リクエストの実際のレスポンスをたどります。elm-02 はリクエスト 74、レスポンス 78 です。両者の区間は約 0.3 ms です。次のプログラムリクエスト elm-03 はフレーム 80 です。フレーム 78 を時間参照にすると、80 は約 1.6012 秒後に現れます。その後、参照を解除します。
Elm の長い区間は前のレスポンスの後、次のリクエストの前にあります。パケット記録が示すのはこの位置です。クライアントのタイマー、アプリケーション処理、人による操作の遅れは区別できません。追加証拠なしにフロントエンドのバグと決め付けないでください。
Maple も ip.addr == 127.0.0.5 && http で同様に調べます。最初の詳細リクエスト、そのレスポンス、プログラムリクエストは 12、16、17 です。両区間とも 1 ミリ秒未満です。この正常な参考は、長い待機のない同じ順序の通信を示します。
Mousepad に戻り、Aspen の行を保持したまま表を 3 訪問全体に置き換えます。元の入力のフレーム番号とミリ秒を使います。
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
maple,12,16,17,0.3,0.1,normal
aspen,42,46,48,1601.7,0.3,after
elm,74,78,80,0.3,1601.2,before
保存します。影響を受けた 2 訪問は同じように目立つ遅延があり、その位置が違います。接続全体の Duration では区別できません。各ストリームの最後のリクエストだけを残しても、繰り返された詳細リクエストを正しく対応付けられません。
Wireshark でプログラムレスポンスを調べます。HTTP 本文は大きく、TCP セグメントに分割されています。レスポンスを選び、Reassembled TCP と完全な JSON タイトル Lantern Photography を確認します。末尾の余分な空白は合成の練習用パディングで、追加の JSON オブジェクトではありません。解析フレーム間の区間にはメッセージの完成が含まれます。したがって、この値は自動的に最初のバイトの時間とはなりません。
Maple、Aspen、Elm の完全な接続を残します。|| はどちらかの条件が一致すればよいという意味です。表示フィルターを置き換えます。
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
&& http を追加しないでください。エクスポートには前の TCP セグメントも必要です。File → Export Specified Packets、Displayed → All packets を選び、PCAPNG を /home/labex/project/event-page/output/evidence.pcapng に保存します。Pine は除きます。既存出力がある場合、このコースの出力ファイルだけの置換を確認し、元の入力を置き換えないでください。
エクスポートを開き、3 訪問と完全なレスポンスを確認します。出力のフレーム番号は変わる場合がありますが、表は元の入力を明示的に参照します。不完全なら入力を開き直し、完全な接続を再度エクスポートします。新しいフィルターで行が出ない場合、開いたファイルとクライアントアドレスを確認し、フィルターを消して一覧を復元します。
有用な結論は明確です。Aspen の長い区間は詳細リクエスト後、Elm の長い区間は次のプログラムリクエスト前です。比較用に正常な Maple のトランザクションも保持します。サーバー設定は変更しておらず、内部原因についてこれ以上の断定は不要です。
まとめ
Wireshark のリクエストリンク、Time since request、時間参照で異なる 2 つの待機位置を比較しました。正常な参考と独立して読める会話を保持しました。結論は観測された待機を特定し、観測していないアプリケーションやネットワーク内部の原因は断定していません。
