[1]　ネットワークの遅延
[2]　データが伝わる速度　（電気通信）
[3]　ネットワークの遅延の実際
[4]　ネットワークの遅延の実験（網内遅延を疑似発生）
[5]　アプリケーションの遅延（体感）(1)【APの種類】
[6]　アプリケーションの遅延（体感）(2)【システム構成】
[7]　アプリケーションの遅延（体感）(3)【サーバインフラ】
[8]　パケットキャプチャによる解析
[9]　WireSharkで表示した例
[10]　ネットワークの遅延（まとめ）

１．ネットワークの遅延　　　　　　テストトライアルにJump new

　

　企業活動を行うたいめには、ＩＴサービスの利用が不可欠となりました。これは、ネットワークインフラが充実したのが大きな要因です。
クラウド時代を迎え、ネットワークに繋がっていない端末は、非常に少なくなりました。ますます、ネットワークの重要性が高まってきます。
　ここで問題になってきているのが、ネットワークの遅延の問題です。本ページでは、この点について詳しく解説します。

２．データが伝わる速度　（電気通信）

１．データが伝わる速度　（電気通信）

　データの伝達は、電気によって運ばれています。電気の速度は、毎秒約３０万キロメートルと非常に高速です。

　１秒間の伝達距離は、地球の７回り半に相当します。

伝送ロスがないとすると、　東京から札幌まで、約１，２００ｋｍ（直線でなくケーブル道）の距離となりますので、約４．０ｍｓで到達することになります。


日本国内の場合、上記のように短時間となりますが、東京−ニューヨークですと、直線距離では、約１０，９００ｋｍとなり、海底ケーブル、地形を考慮するとケーブル長は、２０％増しとすると、約１３，１００ｋｍとなります。



　日本国内の通信と比べ、１０倍以上になりますので、システム構築では遅延を意識する必要があります。

＜参考：光ファイバーについて＞
　電気と同じスピードで伝達されるのが、「光」です。ＩＴインフラとして、光ファイバーが導入されるようになりました。

　光ファイバーは、

①　電気ではないので、電磁誘導を受けない。
②　広帯域の容量を確保できる。
等のメリットがあり、急速に導入され、今では、自宅まで光回線を引く時代になりました。

３．ネットワークの遅延の実際

　伝送損失が０であれば、日本国内は非常に短い伝達時間となりますが、実際には、間に、伝送装置、ルータ等が入りますので、ネットワークの遅延が発生します。

　次の図は、東京～大阪間で、中継装置が無い例を示しています。



実際は、東京～大阪間で多くの機器を経由しています。

東京から、大阪までの、traceroute の実行例を示します。

traceroute to 大阪(from 東京), 30 hops max, 60 byte packets

1内部機器　0.419 ms　0.890 ms　1.057 ms
2内部機器　0.315 ms　0.346 ms　0.397 ms
3内部機器(Router)　1.282 ms　1.348 ms　1.389 ms
4ISP-A 機器　6.087 ms　6.108 ms　6.137 ms
5ISP-A 機器　4.854 ms　4.899 ms　4.930 ms
6ISP-A 機器　14.589 ms　14.993 ms　13.080 ms
7ISP-B（IX）機器　6.707 ms　6.660 ms　6.674 ms
8ISP-C 機器　6.756 ms　6.806 ms　6.670 ms
9ISP-C 機器　6.801 ms　6.712 ms　6.440 ms
10ISP-C 機器　20.302 ms　18.833 ms　18.378 ms
11ISP-C 機器　13.324 ms　13.991 ms　13.098 ms
12ISP-C 機器　13.767 ms　14.407 ms　13.776 ms
13ISP-C 機器　13.807 ms　14.031 ms　13.523 ms
14Server　13.901 ms　13.341 ms　13.349 ms

構成のイメージ図を次に示します。ISP:インターネットサービスプロバイダ



実際のシステムは、図のように、沢山の機器を経由します。
この構成（サンプル）で、東京の機器から、大阪のサーバへのping値は、

　東京～大阪機器へのping値　　11.2 ms（平均値）

でした。

同様に、東京から、札幌までの、traceroute の実行例を示します。

traceroute to 札幌(from 東京）, 30 hops max, 60 byte packets

1内部機器　0.435 ms　0.878 ms　1.068 ms
2内部機器　0.298 ms　0.361 ms　0.414 ms
3内部機器(Router)　1.481 ms　1.573 ms　1.657 ms
4ISP-A 機器　3.011 ms　4.064 ms　4.102 ms
5ISP-A 機器　2.223 ms　2.276 ms　2.295 ms
6ISP-A 機器　12.224 ms　12.371 ms　11.147 ms
7ISP-B（IX）機器　3.012 ms　2.983 ms　3.211 ms
8ISP-C 機器　22.285 ms　22.222 ms　21.573 ms
9ISP-C 機器　19.989 ms　20.022 ms　22.447 ms
10ISP-C 機器　22.387 ms　22.327 ms　21.826 ms
11ISP-C 機器　21.858 ms　21.889 ms　19.727 ms
12Server　22.722 ms　27.268 ms　22.729 ms
上記の場合、通過する機器は、１１個でした。

この構成で、東京の機器から、札幌のサーバへのping値は、

　東京～札幌機器へのping値　22.4 ms（平均値）

でした。

同様に、東京から、アメリカ東海岸の機器までの、tracerouteの実行例を示します。

traceroute to 米国機器（from東京）, 30 hops max, 60 byte packets

1内部機器　7.718 ms　 7.908 ms　 8.100 ms
2内部機器　0.423 ms　 0.478 ms　 0.542 ms
3内部機器(Router)　1.469 ms　 1.550 ms　 1.632 ms
4ISP-A　3.481 ms　 3.610 ms　 4.281 ms
5ISP-A　2.379 ms　 2.416 ms　 2.452 ms
6ISP-A　3.594 ms　 3.694 ms　 3.810 ms
7ISP-B　4.429 ms　 3.605 ms　 3.997 ms
8ISP-B　3.358 ms　 3.168 ms　 3.146 ms
9ISP-C　84.676 ms　 86.218 ms　 84.874 ms
10ISP-C　159.183 ms　 136.427 ms　 136.960 ms
11ISP-C　145.412 ms　 142.274 ms　 165.360 ms
12ISP-C　154.366 ms　 151.744 ms　 143.483 ms
13ISP-D　208.072 ms　 210.515 ms　 219.707 ms
14ISP-D　217.582 ms　 227.867 ms　 205.651 ms
15* * *　　　
この構成で、東京の機器から、米国のサーバへのping値は、
　東京～米国機器へのping値　202 ms（平均値）
でした。

距離、伝送時間（ロス無：電気、光の速度）、ping値を示します。

４．ネットワークの遅延の実験（網内遅延を疑似発生）

　前述のとおり、距離が遠くなるとかなりの遅延が発生します。
　それでは、遅延が大きくなると体感としては、どのように感じるのでしょうか。

　疑似ネットワークにより、遅延を強制的に発生させ、その時のファイルのダウンロード時間を測定しました。

　詳しくは、次のリンク先をご参照下さい。

遅延と体感（ネットワークの遅延の実験）へリンク

５．アプリケーションの遅延（体感）(1)【APの種類】

　これまで、伝送速度の遅延を説明してきましたが、実際にアプリケーションを利用した体感は、アプリケーションの種類によって、遅延値が影響する場合と、影響が少ない場合があります。　

　一般的に、ファイル容量の小さなデータへのアクセス（Webアクセス等）については、遅延の許容が大きいのですが、大きなファイルを扱うアプリケーション（ファイル共有等）は、遅延の影響を受け易いと言えます。

　特に遅延の大きい海外と通信の場合、大きなファイルを取り扱うアプリケーションには、ＷＡＮ高速化装置の導入を行わないと人間が操作するには耐えられない程、遅延の影響を受けます。

　国内でも、ＩＳＰの伝送路の組み方によると、遠回りをして接続されている場合があります。

例：富山−松本間は、直線距離では、８５ｋｍ程度ですが、実際の伝送路が、富山～大阪～松本　と　大阪の機器を経由している場合もあります。

　この地域で、ファイルサーバを共有するシステムを構築した際、レスポンスが遅いとの苦情を受け、別の伝送路のネットワークを利用して問題を解決したことがあります。

　Ｗｅｂのアクセスについては、それ程苦情がなかったにも関わらず、ファイルサーバについては、遅延の影響を受けました。

　このように、利用するアプリケーションにより、遅延の影響が違いますので、「遅延が何ｍｓ以下であるので、ストレスが無い。」とは言い切れません。

　使用されるアプリケーションにより、遅延の許容範囲を考慮する必要があります。

６．アプリケーションの遅延（体感）(2)【システム構成】

　以下の図は、一般的な、企業内ネットワークの構成です。


　このような構成では、遅延の発生要因は複数考えられます。
・ネットワーク
・ネットワーク（地域網）
・ＦＷ（ファイアーウォール）
・サーバ
・その他経由する機器
のどれも全体のスループット（赤矢印）に影響します。

　これまで、ネットワークの遅延は、回線帯域が狭いことが原因のほとんどでした。
　ブロードバンドが普及し、狭帯域のネットワークから広帯域のネットワークにどんどん移行されています。
　帯域に余裕がある場合でも、遅延は発生することがあります。

　遅延がある＝帯域が狭い　だけではありません。

　単なる死活監視（ｐｉｎｇ試験）では、ＦＷ（ファイアウォール）を経由した試験ができません。
　その場合、もっと上位レイヤ（アプリケーションに近いレベル）からの試験が有効です。

　「ＦＷ超え試験」にリンク

　機器のｃｏｎｆｉｇ設定が誤っている場合も遅延が発生することがあります。また、冗長化構成を取られた機器の中の１つが不具合の場合にも遅延が発生します。

７．アプリケーションの遅延（体感）(3)【サーバインフラ】

サーバインフラの違いによっても、アプリケーションの遅延（体感）が違います。

　次の構成において、ロケーションが異なるクラウドサービス上に、ＷＥＢサーバを構築しました。


　　　　　　　　　　　　　　　　　　　　　　　　　EEC（End to End Checker)


それぞれのサーバに対して、
　・ping試験
　・80ポート試験
　・WGET試験（０バイトの情報を入手）
を東京事務所より行った試験結果です。【値は平均値】


（　　）内は、ミニマム値


次に示すグラフは、２０１５年９月１７日（木）のＥＥＣの出力結果です。

グラフの凡例は、
青：速い、緑：少し遅い、紫：遅い、赤：timeout
を表します。

１時間に１００回試験をし、１００回とも速ければ、青色のみになります。
５０回が速く、５０回が少し遅い場合は、半分が青色、半分が緑色となります。
青、緑、紫、赤で、１００％表示としています。

今回の表示の閾値は次の通りです。

速い　青　　45.000 ～ 145.000 (ms)　　(間隔：100.000 ms)
少し遅い　緑　145.000 ～ 245.000 (ms)　　(間隔：100.000 ms)
遅い　紫　245.000 ～　　
関西クラウドセンタ


北海道クラウドセンタ


　なんと、距離の遠い北海道クラウドセンタのＷＥＢのアクセスの方が速い結果となりました。

　関西クラウドセンタの方が、距離も近く、ping値も小さいにも関わらず、wegt（アプリケーション試験）において、遅延値が逆転しています。同じベンダのクラウドサービスですが、クラウドを構成している共通機器の状況により、wgetのレスポンス値に違いが生じていると考えられます。

　以上から分かることは、単に、ping値を試験しただけでは、実際の体感が分らないことを意味しています。

　体感値を知るには、できるだけアプリケーションに近いレベルの試験が必要なことが分かります。

８．パケットキャプチャによる解析

関西クラウドセンタのWWWサーバ、北海道クラウドセンタのWWWサーバにおける、

　wget [-spider オプション]の動作のパケットキャプチャを行いました。

　キャプチャの場所は、EECのNICで行っています。
　次の図は、各サイトへのアクセス状況の時間経過を示しています。



パケットキャプチャの生データを次に示します。
実施日：２０１５年１０月１３日（火）
【北海道WWW】
①17:04:48.076115 IP EEC.36804 > 北海道WWW.http: Flags [S], seq 1925599048,
　win 14600, options [mss 1460,sackOK,TS val 3149424812 ecr 0,nop,wscale 7], length 0

②17:04:48.098702 IP 北海道WWW.http > EEC.36804: Flags [S.], seq 303900495, ack 1925599049,
　win 14480, options [mss 1300,sackOK,TS val 3268127821 ecr 3149424812,nop,wscale 6], length 0

③17:04:48.098727 IP EEC.36804 > 北海道WWW.http: Flags [.], ack 1,
　win 115, options [nop,nop,TS val 3149424834 ecr 3268127821], length 0

④17:04:48.098843 IP EEC.36804 > 北海道WWW.http: Flags [P.], seq 1:115, ack 1,
　win 115, options [nop,nop,TS val 3149424834 ecr 3268127821], length 114

⑤17:04:48.120529 IP 北海道WWW.http > EEC.36804: Flags [.], ack 115,
　win 227, options [nop,nop,TS val 3268127843 ecr 3149424834], length 0

⑥17:04:48.123100 IP 北海道WWW.http > EEC.36804: Flags [P.], seq 1:239, ack 115,
　win 227, options [nop,nop,TS val 3268127845 ecr 3149424834], length 238

⑦17:04:48.123113 IP EEC.36804 > 北海道WWW.http: Flags [.], ack 239,
　win 123, options [nop,nop,TS val 3149424859 ecr 3268127845], length 0

⑧17:04:48.123177 IP 北海道WWW.http > EEC.36804: Flags [F.], seq 239, ack 115,
　win 227, options [nop,nop,TS val 3268127845 ecr 3149424834], length 0

⑨17:04:48.123275 IP EEC.36804 > 北海道WWW.http: Flags [F.], seq 115, ack 240,
　win 123, options [nop,nop,TS val 3149424859 ecr 3268127845], length 0

⑩17:04:48.145099 IP 北海道WWW.http > EEC.36804: Flags [.], ack 116,
　win 227, options [nop,nop,TS val 3268127867 ecr 3149424859], length 0

【関西WWW】
①16:34:33.973846 IP EEC.48447 > 関西WWW.http: Flags [S], seq 243990028,
　win 14600, options [mss 1460,sackOK,TS val 3147610709 ecr 0,nop,wscale 7], length 0
②16:34:33.988993 IP 関西WWW.http > EEC.48447: Flags [S.], seq 671472849, ack 243990029,
　win 5792, options [mss 1300,sackOK,TS val 2548729406 ecr 3147610709,nop,wscale 7], length 0
③16:34:33.989016 IP EEC.48447 > 関西WWW.http: Flags [.], ack 1,
　win 115, options [nop,nop,TS val 3147610725 ecr 2548729406], length 0
④16:34:33.989131 IP EEC.48447 > 関西WWW.http: Flags [P.], seq 1:114, ack 1,
　win 115, options [nop,nop,TS val 3147610725 ecr 2548729406], length 113
⑤16:34:34.004188 IP 関西WWW.http > EEC.48447: Flags [.], ack 114,
　win 46, options [nop,nop,TS val 2548729421 ecr 3147610725], length 0

⑤と⑥の間の差：２５３ｍｓ　

⑥16:34:34.257345 IP 関西WWW.http > EEC.48447: Flags [P.], seq 1:241, ack 114,
　win 46, options [nop,nop,TS val 2548729674 ecr 3147610725], length 240
⑦16:34:34.257364 IP EEC.48447 > 関西WWW.http: Flags [.], ack 241,
　win 123, options [nop,nop,TS val 3147610993 ecr 2548729674], length 0
⑧16:34:34.257370 IP 関西WWW.http > EEC.48447: Flags [F.], seq 241, ack 114,
　win 46, options [nop,nop,TS val 2548729674 ecr 3147610725], length 0
⑨16:34:34.257567 IP EEC.48447 > 関西WWW.http: Flags [F.], seq 114, ack 242,
　win 123, options [nop,nop,TS val 3147610993 ecr 2548729674], length 0
⑩16:34:34.273013 IP 関西WWW.http > EEC.48447: Flags [.], ack 115,
　win 46, options [nop,nop,TS val 2548729690 ecr 3147610993], length 0


各項目のレスポンスの内訳（単位：ｍｓ）




　SYN（コネクション確率要求）とFIN（コネクション解放要求）については、距離の相応した妥当なレスポンスだと考えられます。
　データの要求に対する応答がかなりの差となっています。


過去のデータの調査

関西CCにおける過去のデータを示します。特に利用側（クラウドを利用する側）では、WWWサーバの変更等は行っておりません。

２０１５年５月のデータ


５月２１日に大きな値の変化が出ています。
次のグラフは、５月２１日のデータです。


時間ごとの試験結果を次に示します。



　９時台のミニマム値は、３２ｍｓでしたが、１１時台には、２３０ｍｓと大きく変化しています。

　WEBアクセスでは、一概に、「２００ｍｓ台＝悪い」　ではありませんが、この数字が大きくなってくるとお客さまのストレスが高まってくると考えられます。

　今回の事例では、ユーザ側でのアプリケーションインフラ[ミドルウェア、Apache（WWW)の入れ替え等]の変更を行っていませんので、レスポンスの変化は、

・ミドルウェア
・アプリケーション
・クラウド基盤　　←
の　「クラウド基盤」に原因があることが推測されます。

９．WireSharkで表示した例

　「７．パケットキャプチャによる解析」の結果をWireSharkを用いて表示します。
　WireSharkを利用すると、遅延が生じたパケットを容易に探し出すと事可能です。



　SYN(パケット確立要求）とFIN（パケット解放要求）の時間は、関西クラウドの方が短いですが、データ部の応答は関西の方が時間を要しているのが分ります。

　上記の例のように、遅延が発生している場合に、ある特定のパケットが遅れているかどうかを調べるのはとても有効です。

　下の図は、一般に見かけられるインターネット上のWEBサーバの構成です。

　レスポンスに問題がある場合、図の赤点線部分でパケットキャプチャを行い、WEBサーバに問題があるのか、DBサーバに問題があるのか切り分けが可能となります。

10．ネットワークの遅延（まとめ）

　これまで説明してきたとおり、システム設計においては、伝送路としての物理的なネットワークの遅延を考慮する必要があります。特に海外との通信には注意が必要です。
　また、利用するアプリケーションにより、システム設計に気を付けることが重要です。

　物理的な影響（距離）以外にも、アプリケーションを利用した体感は、
・クライアントとサーバの間で経由する機器
・アプリケーションの種類
・サーバ基盤
により、レスポンスが異なってきます。

　ＩＴインフラは複雑、また、起業活動における生命線となっておりますので、安定したサービスの提供は益々重要となってきます。

　このような背景から、システムのトータル的なチェックが必要です。

　トータル的なチェックは、保守運用サービスに必要なこと の５つのポイントが重要です。

　・５つのポイントで課題を解決した例（SalesForceの遅延）

　・アプリケーションの遅延　　　　　　のページもご参照願います。