Microsoft Network Monitor3.4でhttp通信のKeep-Aliveを確認してみました。 ネットワークにもツールにも精通していないので「多分コレで確認できるんだろうなぁ」という程度のネタです。
Microsoft Network Monitorについては、前の投稿でやった程度の知識しかありません。
- 前の投稿 ... ustreamなどの広告抑制対象の調べ方
やり方は、
- Microsoft Network Monitorでキャプチャーしながら適当にサイトを見る。
-
そのキャプチャーログを解析。
Display Filterに条件を書いてApply → Httpリクエストだけを抜き出す。
Source=="クライアントipアドレス" and ProtocolName=="HTTP"
- Frame SummaryのColumnsメニューから、表示項目にSource Portを追加する。
- 1つのSource Portを使って同じDestinationに複数回アクセスしているのを探す。 あったらそれがKeep-Alive中の通信のハズ。
-
Display Filterを書き換える。
さっき見つかったSource PortでフィルタリングしたらKeep-Alive中の通信をピックアップできる ... ハズ。
TCP.SrcPort == 50000 or Tcp.DstPort == 50000
(注:50000ってのは適当な数字です。) ScrPortの方の条件はリクエストパケットの絞込みに、DstPortの方の条件はレスポンス側の絞込みに使います。
ここでいうSource PortってのはブラウザがHttpサーバにアクセスするときに使うエフェメラルポートですね。 (エフェメラルポートについては、適当に検索して調べるか前の投稿で説明してる部分があるのでそれを見てください。)
「最初のフィルタを適用したFrame Summaryの内容をコピー → テキストファイルなどにペーストして、スクリプトを使ってKeep-Aliveを探す」ってのもできそうですね。 その場合はキャプチャー時間が長すぎるとエフェメラルポートがひとまわりするので注意。 まぁとりあえず、今回は「Keep-Aliveしてそうだなぁ」ってのを確認したかっただけなので目視で十分、っと。
ちなみに、レスポンスの方からKeep-Aliveに使われているエフェメラルポートのアタリを付けるのは面倒くさそうです。 レスポンス側のパケットにはDestinationに「HTTP:HTTP Payload...」と書かれている物があります。 これは大きなサイズのファイルがパケット分割されて送信されている物のよう。 リクエスト側で探すならSource Portが同じものを探すだけでいいのですが、レスポンス側で探すとそういうのが混ざってしまうのです。 おとなしくリクエスト側から探した方が楽ですね。