ジョジョの奇妙なケーススタディ【ネットワーク遅延】

きっかけ

ネットワーク遅延について書かれた資料を拝見し、インスパイアされてしまいました。
本記事とは異なり、大変真面目な内容です。

すごく整理されてていい。
LAN障害の中で「遅延」って解決しにくい問題の一つだけど、現場のケーススタディって需要あるかな？
ネットワークでなぜ遅延が生じるのか #congestion #latency https://t.co/mucCW4Nzjn @SlideShareさんから
— cloretsblack (@Clorets8lack) 2016年12月26日

はじめに

一言にネットワーク遅延と言っても多くのケースが想定されます。ネットワークを構成する様々な要素、例えば、サーバやクライアントPC、アプリケーションなどに原因が潜んでいる可能性があり、比較的難易度の高い障害ではないかと思います。
ただし、私の経験上、遅延の原因は解決してみればごく当たり前の現象であることがほとんどなので、ケーススタディを充実させるよりもネットワークの原理原則を理解したエンジニアに都度対応させるほうが理にかなっている一面もあり、遅延問題について具体的な事例と解説があまりインターネット上に存在しないように思います。

そのため、初心者がどれだけ検索しても問題事例に行き当たらないという現象が発生しており、ユーザー企業の情報システム部門などではユーザーとサポートベンダの板挟みにあい、苦しんでいる人々がいます。かくいう私もその一人でした。かつての私のような人々に少しでもご参考となればと思い、この記事を書きました。

f:id:cloretsblack:20170103113521p:plain
大体こんなテンションで進んでいきます
集英社ジャンプコミックス荒木飛呂彦著ジョジョの奇妙な冒険より引用

注意
本記事ではネットワークのスループットが断続的に低下する事象を「遅延」と定義します。具体的には理論値よりも明らかに速度が出ていない、以前よりも遅くなったなどの問題を扱います。
また、基本的にLANを中心に解説します。
パケットキャプチャを表示するソフトウェアにはWiresharkを使用しました。

私が今まで現場で見たことのあるネットワーク遅延とその検出方法、解決手法を具体的に書いてみたいと思います。

すべての「遅延」問題の調査に共通する基本
ネゴシエーション不一致
ケーブル不良
アプリケーションの問題
ネットワーク容量
サーバレスポンス遅延
ポート/セッション数枯渇
ジャンボフレームとフラグメント

すべての「遅延」問題の調査に共通する基本

もし、あなたの手元で問題が再現するなら、まずパケットキャプチャを取得するところから始めてください。

なぜパケットキャプチャを取らなければならないのですか？

ネットワークでは様々な機器が連携して動いています。サーバ、クライアントPC、スイッチ、ルータ、それらを繋ぐケーブルなどです。
これら全てをしらみつぶしにチェックすることは手間がかかり、さらに必要な情報が必ずしも取得できるとは限りません。
一方、パケットキャプチャには解析に有用な情報が非常に多く含まれており、またパケットキャプチャにしか現れない情報も存在するからです。

パケットキャプチャは非常に読みづらいのですが、読まなければなりませんか？

パケットキャプチャの解析はネットワークのデバッグ行為に相当します。ソフトウェアと同様に、動作を理解し、原因を突き止めなければ問題を正しく修正することはできません。
しかし、必ずしも解析のスキルを身に着ける必要はありません。パケットキャプチャは問題の状況を伝える最も有効な手段の一つです。
つまり、原因究明のアウトソースが容易になるという利点もありますので積極的に活用していきましょう。

f:id:cloretsblack:20170103093234p:plain
思わず納得
集英社ジャンプコミックス荒木飛呂彦著ジョジョの奇妙な冒険より引用

それでは具体的にネットワーク遅延のケーススタディをみていきましょう

ネゴシエーション不一致

ケーブルの両端にあるネットワークインタフェースでネゴシエーションの不一致が発生するとパケットのドロップが発生しスループットが著しく低下します。
パケットのドロップが発生するとTCPの再送が起きるので、パケットキャプチャの再送の数をカウントするのはネットワークの品質をチェックするのによい方法です。ただし、無線の場合は様々な条件で再送が発生するので、この方法は有線限定です。
Wiresharkで再送を検出するフィルタには以下のものを使います。
tcp.analysis.flags
f:id:cloretsblack:20170102175107p:plain
ちなみにもし様々な事情でWiresharkを使うことができない場合は、端末上で
netstat -s
コマンドにより再送数を簡易的に把握することができます。

再送が多い場合、まず疑うべきはネゴシエーションの不一致です。 GigabitEthernetの普及にともない、古い100Mのスイッチを使用している場合、ネゴシエーション不一致が起こりやすいです。現在では端末のインタフェースもほぼ全てGigabitEthernetになっているのでネットワーク上の100Mのスイッチには要注意です。
ネゴシエーションの状態を知るには接続しているスイッチのランプを確認するか、インテリジェントL2スイッチやルータなどで、インタフェース情報を見てください。

f:id:cloretsblack:20170102180719p:plain

Half-duplexなどになっていた場合はネゴシエーションに失敗している可能性が高いです。このあたりの不一致にはインタフェース同士の相性も出ます。あまり深追いせずに古いスイッチは交換しましょう。

なお、ネゴシエーション不一致の場合、後述するケーブル不良と同様に runts, giants, CRCなどのカウンタが記録されていることがあります。これらの項目は深刻なエラーです。必ずゼロにしなければなりません。

GigabitEthernetでは基本的に自動（オートネゴシエーション）で対抗のlinkを識別します。その際、対抗の設定が自動でない場合は半二重でリンクしてしまいます。
一般的にネットワークの管理ではLAN内の機器のスペックやlink状態を把握しておくことは非常に重要です。

f:id:cloretsblack:20170103115046p:plain
オートネゴはオートネゴでしか倒せない。それがイーサネットのルールッ！
集英社ジャンプコミックス荒木飛呂彦著ジョジョの奇妙な冒険 Part7 スティール・ボール・ランより引用

余談ですが、回線業者に依頼してルータのLAN側のインタフェースを10M固定に設定させた同僚がいました。理由を聞くとWANの帯域が10M以下だったので、10Mがふさわしいと思ったそうです。
その結果、周囲の機器が10Mというレガシー規格にうまく対応できず、パケットドロップが頻発するという事態が発生しました。当該ルータは業者しか触れない契約だったため、最終的に全部のリンク設定をオートネゴシエーションに戻すのに結構なお金と時間がかかったというオチでしたが、緊急の回避方法として、10Mのスタティックモードを設定できる、懐かしのNetscreen-5GTを5000円で仕入れ、ルータとスイッチの間に設置するという荒技を使ったことがあります。
というか、業者さんも止めてほしいです。そういうときは。

まとめ

有線ネットワークの品質は再送数でチェック
リンクの状態を確認し、ネゴシエーションの設定をチェック
解決策：すべてのスイッチをGigabitEthernetのオートネゴシエーションに統一する
打ち合わせ中に業者さんが変な顔をしたら、自分が間違っているかもしれないので聞いてみる

ケーブル不良

メーカー製のケーブルを使用する限り、日本ではほとんど起きないのですが、海外や自作のケーブルを使用していたり、UTPのカテゴリが合っていないなどの場合でまれに発生します。
このケースも前項と同様に再送数のチェック、確実には機器のインタフェース統計で判別します。
大前提として、ローカルエリア内の有線ネットワークにおけるTCP再送はゼロにできます。
少量の再送はスループットに大きな影響を与えないのですが、がんばってゼロにしておくと、異常時に気が付きやすくなるのでおススメです。

f:id:cloretsblack:20170103082337p:plain
伝われ、このスッキリ感
集英社ジャンプコミックス荒木飛呂彦著ジョジョの奇妙な冒険より引用

ケーブル不良のうち、銅線の「より」が少ないことが原因でノイズが乗りやすい状態になっている場合があります。不定期に通信品質が悪化する現象が発生しますので、インタフェース統計の runts, giants, CRCのカウンタは最低でも敷設時、理想的には定期的にチェックするとよいでしょう。
f:id:cloretsblack:20170102180907p:plain

ちなみにCRCエラーが出ると、スイッチによってはCRCチェックの負荷によりpingのRTTに数ミリ秒の遅延が出る場合があります。同一拠点内でのpingに遅延がみられる場合には上記のカウンタを確認すべきです。

まとめ

ケーブル不良はインタフェース統計でチェック
runts, giants, CRCのカウンタがゼロでない場合は要注意
解決策：ケーブル交換

アプリケーションの問題

アプリケーションの使い方によって、以下の例のように非効率的な通信が発生してしまうケースがあります。

ネットワーク上の共有フォルダにインストーラーを置いて、端末から直接実行する
巨大なパワーポイントを共有フォルダに置いて直接開く

1.のケースではファイルの読み込みだけでなく圧縮ファイルの展開、解凍などで共有フォルダに大量の読み書きが発生しがちです。インストール作業を自動化するためにパスを固定したい場合もありますが、一旦ローカルへファイルをコピーしてから実行するよう変更するべきです。

2.のケースではMS Officeがカレントディレクトリにキャッシュを作るという動作を行うために、非効率な読み書きが発生する場合があります。参照用途で、かつ容量の大きい場合にはWEBなどから配布するなどの工夫をすると幸せになれるかもしれません。

ネットワークにおけるアプリケーションの挙動を詳細に解析するのは比較的難しいので、ネットワークの存在を意識した上でアプリケーションの使い方をトライアンドエラーするのがいいかもしれません。その際パケットキャプチャはトラフィックを定量化したり、レスポンスを正確に計測する用途にも使えますので、積極的に活用してみてください。

まとめ

ネットワーク特性を意識したアプリケーションの使い方をすることが大切
トライアンドエラーの効果測定にパケットキャプチャを使うと便利

ネットワーク容量

単純にネットワークに大きなデータが流れているために他の通信が送れないという現象です。
解決策としてはスイッチやルータの流量を収集してトラフィックを可視化するのが良いと思います。
具体的にはSNMPを使って流量のカウンタを収集するZabbixやCacti、MRTG、またはSNMPよりも多くの情報が得られるCiscoのNetFlowコレクタなどの可視化ツールの導入を検討してください。
手前味噌で大変恐縮ですが弊社のSonarmanもおススメです。

私の個人的な観測ですが、ユーザー企業の現場では意外なほどトラフィック可視化が行われていません。
トラブルシューティングにおいては、障害が起きた時のために普段から準備をしておくことがとても大切です。

問題の具体例として、WindowsUpdateやiPhoneの更新が集中するケースの他に、WSUS等の分散配布システムを使用する場合に、多人数の出張などで予期しないトラフィックパターンが生じるケース、クラウド等への大容量バックアップ、P2Pアプリケーションによる巨大ファイルのダウンロードなどが挙げられます。

まとめ

トラフィックの可視化を検討する
人為的ミスが多い
発生状況をヒアリングし個別に検討が必要

サーバレスポンス遅延

サーバそのものの反応が遅い場合があります。WiresharkではSMB2やDNS、LDAPなどのレスポンスタイムを可視化する機能がありますので、そういった機能を使ってもよいですし、WEBサーバであればブラウザの開発ツールがダウンロードに要した時間や処理のレスポンスを可視化してくれます。
注意点として、ファイル共有等でDISKのI/Oタイムアウトがエラーとして返される場合があります。パケットキャプチャでしか見つけられませんが、もし見つけたら絶対に無視してはいけません。DISKが壊れかけています。

まとめ

ブラウザの開発ツールやパケットキャプチャで遅延を計測できる
解決策：サーバ増強

ポート/セッション数枯渇

ルータやプロキシサーバを長期間入れ替えていない、利用者が急激に増えたなどの場合にはセッション数やポートの枯渇を疑ってみるとよいかもしれません。
まずnetstatで機器のコネクション数を確認してください。
さらにパケットキャプチャで不自然な待ち時間やコネクションの切断が発生していないか、ルータのログにNATのセッションテーブルの枯渇が記録されていないか等もチェックポイントです。

最近のブラウザでは表示速度の向上を目的とした分散ダウンロードが一般的になっています。CSSや画像、スクリプトなどは異なるTCPコネクションを利用して並列にダウンロードすることで速度を出しており、それらは一つずつ異なるコネクションを使ってルータやファイアーウォールを通過します。
また、ブラウザの動きに合わせて、サイズの小さな部品をたくさん配置するデザインのWEBサイトも増えています。トップページの表示だけで数百のコネクションを使用するWEBサイトも存在しますので、注意が必要です。
ダウンロードが完了したコネクションは破棄され、ソケットは再利用されますが再利用の際に発生する負荷や、純粋なNATセッション数が上限に達してしまうことが原因で、待ち時間が生じてしまうことがあります。ネットワーク上でコネクションが集中する箇所は常時監視や定期的に点検してみることが大切です。
大量のセッションを消費するアプリケーションの具体例として、Bittorrent等のP2Pアプリケーションのフラッディングや、Bitcoinのマイニングツールなど、特殊なものも存在します。

f:id:cloretsblack:20170103095748p:plain
間違いない
集英社ジャンプコミックス荒木飛呂彦著ジョジョの奇妙な冒険より引用

まとめ

ルータやプロキシサーバなどトラフィックが集中する箇所はコネクション数を監視する
解決策：機器のアップグレードや分散配置

ジャンボフレームとフラグメント

通常のイーサネットフレームは1500バイト程度ですが、ジャンボフレームの普及により、LAN内で高速にデータ通信ができる環境が整いつつあります。しかしVPN等でWANに流れる通信の場合、パケットの分割すなわちフラグメントが問題になるケースがあります。問題の把握にはパケットキャプチャを取得する必要があります。
ジャンボフレームの分割に際し再送が発生していないか、PathMTUで発生するICMPのDestination Host Unreachable　メッセージが端末まできちんと返っているかなどがチェックポイントです。

パケットキャプチャではTCPのシーケンスナンバーを条件にフィルタすることで再送が発生する元のパケット（到達しなかったパケット）がどのような状態であったかがわかります。元のパケットがジャンボフレームだった場合には設定を変更してパケットのサイズを小さくしてみると状況が変化する可能性があります。
f:id:cloretsblack:20170102175120p:plain
(5446バイトのジャンボフレームが分割して再送されている)