1. ケーススタディ
（ネットワークの遅延と戦う – 前編）
Hokkaido.cap #4
2011.07.22
Masayuki YAMAKI

2. 今日の目標
• ユーザーが「ネットワークが遅い」と言ってくるシ
ナリオを体験し、ネットワーク遅延時のパケット
がWiresharkでどのように見えるか確認しましょ
う。
• Expert Info、TCP Stream Graph等、便利な解析
機能の使い方を覚えましょう。
2

3. 前回までのおさらい
• これまでの資料を以下のURLで公開しています。
（USBメモリにも収録しています）
Wiresharkを初めて使う方は参照しながら進め
てみてください。
http://www.slideshare.net/eightroll
• 操作方法がわからない場合は、遠慮せずにど
んどん質問してください。
3

4. 今日の進め方
• 「実践パケット解析 第8章 ケーススタディ（ネット
ワークの遅延と戦う）」の内容をベースに進めま
す。本書をお持ちの方は演習に合わせて参照
してください。
（スライドには概要のみ記載しています）
• 気付いた点やわからない点があれば自由に
ディスカッションしましょう。
4

5. 演習資料
－ ネットワークの遅延と戦う（前編） －
5

6. ダウンロードの遅延 (1/6)
• サンプルファイル : slowdownload.pcap
• 大量のHTTP通信とTCPによるダウンロードが記
録されているキャプチャファイル。
• 異常なトラフィックを見分けるため、
「Expert Info」機能を使う。
• [Analyze] → [Expert Info]
→ [Expert Info Composite]
- 最新バージョンでは Window Update はNoteレベル
ではなくChatレベルに分類される。
6

7. ダウンロードの遅延 (2/6)
• Window Updateが大量に記録されている。
- データ受信速度が速くなったり遅くなったりしている。
7

8. ダウンロードの遅延 (3/6)
• 問題の起きているパケット
- Expert Infoを見ると、ダウンロードが進むにつれ
TCP Segment lost、Dupulicate ACKが増えている。
8

9. ダウンロードの遅延 (4/6)
• TCPで遅延を示すメッセージの例
項目 説明
TCP Window Update ウィンドウサイズが変更された
TCP Previous segment lost パケットの欠落、破棄
受信側から同じ応答確認番号のACK
を受け取った
TCP Dup Ack (クライアントはサーバーに対し受け取れな
かったパケットを再度送信するよう求めてい
る)
TCP Out-Of-Order 順番の乱れたパケット
TCP Retransmission TCPによる再送信
9

10. ダウンロードの遅延 (5/6)
• スループットの確認
- 1023番のパケットを選択し、[Statistics]→
[TCP Stream Graph]→[Round Trip Time Graph]
10

11. ダウンロードの遅延 (6/6)
• RTT (Round Trip Time)
- 任意のTCPセグメントを相手側が正しく受信してから
確認応答セグメント（データサイズ分だけ確認応答
番号を増加させ、ACKフラグをONにして送られるパ
ケット）が返ってくるまでの往復遅延時間
- このRTTをもとに、RTO（Retransmission Time Out）が
調整される
- ブロードバンド回線であれば、RTTは通常0.1秒以下
→ このケースでは明らかに遅延が発生していること
がわかる
11

12. 12

13. ルーティングの不具合 (1/4)
• サンプルファイル : icmp-tracert-slow.pcap
• ネットワーク遅延調査のため、tracerouteを実行
した結果が記録されているキャプチャデータ。
13

14. ルーティングの不具合 (2/4)
• traceroute
- 宛先に到達するまでのすべてのルータに、 TTL（Time to
Live : パケットの生存期間）を1から順に増やしてパケッ
トを送信。
- 途中経路にあるルータはICMPの生存時間超過パケット
（ICMP Time Exceeded）を返す。
TTL1
TTL2
TTL3
14

15. ルーティングの不具合 (3/4)
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.227
3 5 ms 5 ms 6 ms 60.36.159.254
4 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.53
20 147 ms 183 ms 152 ms www2.twitter.com [199.59.149.198]
トレースを完了しました。
15

16. ルーティングの不具合 (4/4)
• このケースからわかること
- 最初のルータから応答を受け取っておらず、3秒後
に再送している。（2回目、3回目も受け取っていな
い）
- TTLを2にして送信→2番目のルータから応答を受信
- 以降は宛先に到達するまでTTLの値を増やしながら、
上記の繰り返し。
→ 1番目のルータに問題がある可能性が高い
16

17. 17

18. 二重に見える (1/3)
• サンプルファイル : double-vision.pcap
• すべてのパケットが2回送信されている。
18

19. 二重に見える (2/3)
• パケットが2重に送信される主な理由
- ルーティングの間違い
- ポートミラーリング設定の間違い
• 本当に同じパケットかどうか
→IPヘッダのID（identification）を確認
19

20. 二重に見える (3/3)
• TTLの値が異なればルーティングの問題
1番目のパケット 2番目のパケット
→ サブネットマスクの設定ミスにより、送信パケッ
トが返ってきてしまう。
→ 通常の通信量では気付かないが、ネットワー
ク使用量のピーク時になると通信が遅くなる。
20

21. 21

22. サーバが私を拒否してる？ (1/3)
• サンプルファイル : http-client-refuse.pcap
• 一見通常に見える通信だが、ブラウザでページ
をロードしようとするとなにも起きない。
22

23. サーバが私を拒否してる？ (2/3)
• 28番目のパケット受信に9秒かかっており、サー
バ側からRSTパケットを送出して通信が終了して
いる。
• [Analyze] → [Follow TCP Stream] で解析する。
23

24. サーバが私を拒否してる？ (3/3)
• サーバにFlashのアプレットをリクエストしているが、
ポップアップをブロックするプログラムがこれをブ
ロックしている。
24

25. まとめと参考資料
25

26. この演習のまとめ
• ネットワーク遅延が発生した場合、Wiresharkで
どのように見えるか確認しました。
• Expert Info、TCP Stream Graphを利用した調査
方法を学習しました。
• ネットワーク遅延に関連するトラブルは実際の
利用シーンでも遭遇することが多いため、次回
も引き続き学習していきましょう。
26

27. 参考資料
• 実践パケット解析 - Wiresharkを使ったトラブル
シューティング
- http://www.oreilly.co.jp/books/9784873113517
- ISBN978-4-87311-351-7
• Key：雑学事典 - TCP における確認応答と再送制御
- http://www.7key.jp/nw/tcpip/tcp/tcp2.html
写真提供 : ジャイアントパンダ写真集（フリー素材） http://giantpanda.jp
27

28. 28