hokkaido.cap#4 ケーススタディ(ネットワークの遅延と戦う:前編)
TRANSCRIPT
ケーススタディ（ネットワークの遅延と戦う – 前編）
Hokkaido.cap #4
2011.07.22
Masayuki YAMAKI
今日の目標
• ユーザーが「ネットワークが遅い」と言ってくるシナリオを体験し、ネットワーク遅延時のパケットがWiresharkでどのように見えるか確認しましょう。
• Expert Info、TCP Stream Graph等、便利な解析機能の使い方を覚えましょう。
2
前回までのおさらい
• これまでの資料を以下のURLで公開しています。（USBメモリにも収録しています）Wiresharkを初めて使う方は参照しながら進めてみてください。
http://www.slideshare.net/eightroll
• 操作方法がわからない場合は、遠慮せずにどんどん質問してください。
3
今日の進め方
• 「実践パケット解析第8章ケーススタディ（ネット
ワークの遅延と戦う）」の内容をベースに進めます。本書をお持ちの方は演習に合わせて参照してください。（スライドには概要のみ記載しています）
• 気付いた点やわからない点があれば自由にディスカッションしましょう。
4
5
演習資料
－ ネットワークの遅延と戦う（前編） －
ダウンロードの遅延 (1/6)
• サンプルファイル : slowdownload.pcap
• 大量のHTTP通信とTCPによるダウンロードが記録されているキャプチャファイル。
• 異常なトラフィックを見分けるため、「Expert Info」機能を使う。
• [Analyze] → [Expert Info]→ [Expert Info Composite]
- 最新バージョンでは Window Update はNoteレベルではなくChatレベルに分類される。
6
ダウンロードの遅延 (2/6)
• Window Updateが大量に記録されている。
- データ受信速度が速くなったり遅くなったりしている。
7
ダウンロードの遅延 (3/6)
• 問題の起きているパケット
- Expert Infoを見ると、ダウンロードが進むにつれTCP Segment lost、Dupulicate ACKが増えている。
8
ダウンロードの遅延 (4/6)
• TCPで遅延を示すメッセージの例
9
項目 説明
TCP Window Update ウィンドウサイズが変更された
TCP Previous segment lost パケットの欠落、破棄
TCP Dup Ack
受信側から同じ応答確認番号のACKを受け取った(クライアントはサーバーに対し受け取れな
かったパケットを再度送信するよう求めている)
TCP Out-Of-Order 順番の乱れたパケット
TCP Retransmission TCPによる再送信
ダウンロードの遅延 (5/6)
• スループットの確認
- 1023番のパケットを選択し、[Statistics]→[TCP Stream Graph]→[Round Trip Time Graph]
10
ダウンロードの遅延 (6/6)
• RTT (Round Trip Time)- 任意のTCPセグメントを相手側が正しく受信してから
確認応答セグメント（データサイズ分だけ確認応答番号を増加させ、ACKフラグをONにして送られるパケット）が返ってくるまでの往復遅延時間
- このRTTをもとに、RTO（Retransmission Time Out）が調整される
- ブロードバンド回線であれば、RTTは通常0.1秒以下
→ このケースでは明らかに遅延が発生していることがわかる
11
12
ルーティングの不具合 (1/4)
• サンプルファイル : icmp-tracert-slow.pcap
• ネットワーク遅延調査のため、tracerouteを実行した結果が記録されているキャプチャデータ。
13
ルーティングの不具合 (2/4)
• traceroute- 宛先に到達するまでのすべてのルータに、 TTL（Time to
Live : パケットの生存期間）を1から順に増やしてパケットを送信。
- 途中経路にあるルータはICMPの生存時間超過パケット（ICMP Time Exceeded）を返す。
14
TTL1TTL2
TTL3
ルーティングの不具合 (3/4)
15
C:¥>tracert twitter.com
twitter.com [199.59.149.198] へのルートをトレースしています経由するホップ数は最大 30 です:
1 2 ms 1 ms 1 ms gateway [10.1.60.1]2 5 ms 4 ms 4 ms 60.36.159.2273 5 ms 5 ms 6 ms 60.36.159.2544 23 ms 27 ms 22 ms 118.21.174.213
・・・17 155 ms 154 ms 143 ms ae-43-90.car3.SanJose1.Level3.net [4.69.152.197]18 137 ms 156 ms 132 ms TWITTER-INC.car3.SanJose1.Level3.net [4.71.113.194]19 142 ms 159 ms 144 ms 199.16.159.5320 147 ms 183 ms 152 ms www2.twitter.com [199.59.149.198]
トレースを完了しました。
ルーティングの不具合 (4/4)
• このケースからわかること
- 最初のルータから応答を受け取っておらず、3秒後に再送している。（2回目、3回目も受け取っていない）
- TTLを2にして送信→2番目のルータから応答を受信
- 以降は宛先に到達するまでTTLの値を増やしながら、上記の繰り返し。
→ 1番目のルータに問題がある可能性が高い
16
17
二重に見える (1/3)
• サンプルファイル : double-vision.pcap
• すべてのパケットが2回送信されている。
18
二重に見える (2/3)
• パケットが2重に送信される主な理由
- ルーティングの間違い
- ポートミラーリング設定の間違い
• 本当に同じパケットかどうか
→IPヘッダのID（identification）を確認
19
二重に見える (3/3)
• TTLの値が異なればルーティングの問題
1番目のパケット 2番目のパケット
20
→ サブネットマスクの設定ミスにより、送信パケットが返ってきてしまう。
→ 通常の通信量では気付かないが、ネットワーク使用量のピーク時になると通信が遅くなる。
21
サーバが私を拒否してる？ (1/3)
• サンプルファイル : http-client-refuse.pcap
• 一見通常に見える通信だが、ブラウザでページをロードしようとするとなにも起きない。
22
サーバが私を拒否してる？ (2/3)
• 28番目のパケット受信に9秒かかっており、サーバ側からRSTパケットを送出して通信が終了している。
23
• [Analyze] → [Follow TCP Stream] で解析する。
サーバが私を拒否してる？ (3/3)
• サーバにFlashのアプレットをリクエストしているが、
ポップアップをブロックするプログラムがこれをブロックしている。
24
25
まとめと参考資料
この演習のまとめ
• ネットワーク遅延が発生した場合、Wiresharkでどのように見えるか確認しました。
• Expert Info、TCP Stream Graphを利用した調査方法を学習しました。
• ネットワーク遅延に関連するトラブルは実際の利用シーンでも遭遇することが多いため、次回も引き続き学習していきましょう。
26
参考資料
• 実践パケット解析 - Wiresharkを使ったトラブルシューティング
- http://www.oreilly.co.jp/books/9784873113517
- ISBN978-4-87311-351-7
• Key：雑学事典 - TCP における確認応答と再送制御
- http://www.7key.jp/nw/tcpip/tcp/tcp2.html
27
写真提供 : ジャイアントパンダ写真集（フリー素材） http://giantpanda.jp
28