[1]　アプリケーションの遅延
[2]　ＷＡＮ環境におけるレスポンスについて
[3]　クライアントとサーバのパケットのやりとりの実際
[4]　ＷＥＢアクセスでレスポンスが遅い事例
[5]　アプリケーションの遅延（まとめ）

１．アプリケーションの遅延　　　テストトライアルにJump new

　日常の業務を行っていて、各種アプリケーションの応答速度が遅いと感じておられることはありませんか。
アプリケーションの応答速度が遅いと、いらいらするだけでなく、注意力が散漫になりミスの原因にも繋がります。
　本ページでは、アプリケーションの遅延について、詳しく解説します。

　アプリケーションの遅延の要因は、次の２つに分類できます。
　　１．ネットワークインフラに起因するもの
　　２．ネットワークインフラ以外に起因するもの

”１”のネットワークインフラに起因するものについては、
　　「ネットワークの遅延のページ」も　ご参照下さい。

　本ページでは、ＷＡＮとＬＡＮ環境による違い、パケットのやりとりを見て遅延の原因を究明することについて詳しく説明します。

２．ＷＡＮ環境におけるレスポンスについて

　アプリケーションの開発は、クラウド基盤を利用することも多くなりましたが、ＬＡＮ環境で行った場合、注意する点があります。


　ＬＡＮ内の応答速度は、非常に速いため、クライアントとサーバの通信のやりとりが多いプログラムも少ないプログラムもレスポンスには余り影響されません。


　ＬＡＮ環境では、クライアントとサーバ間の応答速度が問題になりませんが、ＷＡＮ環境においては、問題になってくる場合があります。


　ＷＡＮの場合、ＬＡＮに比べると遅延が発生し、一回のやりとりの時間がかかってしまいますので、やりとりが多くなりますと、利用者が感じる遅延が非常に大きくなります。
　アプリケーション開発の場合、ＷＡＮ環境の遅延を意識して基本設計を行う必要があります。
　アプリケーションの仕様上、やりとりが減らせない場合は、やりとりをまとめて処理をするような、ＷＡＮ高速化商品等を導入するケースもあります。

３．クライアントとサーバのパケットのやりとりの実際

　クライアントとサーバの実際のパケットのやりとりを見るためクライアントにてパケットキャプチャを行いました。


　次に、ping（ICMP）、80ポート、wget（WEBを実際に見に行く）のパケットについてみて行きます。

（１）ping（ICMP）：死活監視


＜パケットの詳細＞
11:18:06.266995 IP PC > Server: ICMP echo request, id 4448, seq 1
11:18:06.288856 IP Server > PC: ICMP echo reply, id 4448, seq 1, length 64

　１往復のパケットのやりとりとなっています。

（２）80ポート監視 ：ＷＥＢサーバをアクセスするポート


＜パケットの詳細＞
①11:40:18.561515 IP PC.55874 > Server.http: Flags [S], seq 1053017930,
　win 14600, options [mss 1460,sackOK,TS val 3302755297 ecr 0,nop,wscale 7], length 0

②11:40:18.583100 IP Server.http > PC.55874: Flags [S.], seq 1745710799, ack 1053017931,
　win 14480, options [mss 1300,sackOK,TS val 3421461054 ecr 3302755297,nop,wscale 6], length 0

③11:40:18.583127 IP PC.55874 > Server.http: Flags [.], ack 1,
　win 115, options [nop,nop,TS val 3302755319 ecr 3421461054], length 0

④11:40:18.583150 IP PC.55874 > Server.http: Flags [F.], seq 1, ack 1,
　win 115, options [nop,nop,TS val 3302755319 ecr 3421461054], length 0

⑤11:40:18.605197 IP Server.http > PC.55874: Flags [F.], seq 1, ack 2,
　win 227, options [nop,nop,TS val 3421461076 ecr 3302755319], length 0

⑥11:40:18.605216 IP PC.55874 > Server.http: Flags [.], ack 2,
　win 115, options [nop,nop,TS val 3302755341 ecr 3421461076], length 0

　クライアントから、SYN（コネクション確率要求）を行い、直ぐにFIN（コネクション解放要求）を行っています。
制御パケットのみになりますので、データ部のlengthは、全て 0 となっています。

（３）ｗｇｅｔ（--spiderオプション）の試験：実際にＷＥＢページにアクセスしデータを取得する


＜パケットの詳細＞
①13:23:31.827018 IP PC.37595 > Server.http: Flags [S], seq 1913914691,
　win 14600, options [mss 1460,sackOK,TS val 3308948563 ecr 0,nop,wscale 7], length 0

②13:23:31.846538 IP Server.http > PC.37595: Flags [S.], seq 1660984565, ack 1913914692,
　win 14480, options [mss 1300,sackOK,TS val 3427654430 ecr 3308948563,nop,wscale 6], length 0

③13:23:31.846562 IP PC.37595 > Server.http: Flags [.], ack 1,
　win 115, options [nop,nop,TS val 3308948582 ecr 3427654430], length 0

④13:23:31.846756 IP PC.37595 > Server.http: Flags [P.], seq 1:115, ack 1,
　win 115, options [nop,nop,TS val 3308948582 ecr 3427654430], length 114

⑤13:23:31.866282 IP Server.http > PC.37595: Flags [.], ack 115,
　win 227, options [nop,nop,TS val 3427654450 ecr 3308948582], length 0

⑥13:23:31.868511 IP Server.http > PC.37595: Flags [P.], seq 1:239, ack 115,
　win 227, options [nop,nop,TS val 3427654452 ecr 3308948582], length 238

⑦13:23:31.868523 IP PC.37595 > Server.http: Flags [.], ack 239,
　win 123, options [nop,nop,TS val 3308948604 ecr 3427654452], length 0

⑧13:23:31.868531 IP Server.http > PC.37595: Flags [F.], seq 239, ack 115,
　win 227, options [nop,nop,TS val 3427654452 ecr 3308948582], length 0

⑨13:23:31.868921 IP PC.37595 > Server.http: Flags [F.], seq 115, ack 240,
　win 123, options [nop,nop,TS val 3308948604 ecr 3427654452], length 0

⑩13:23:31.887621 IP Server.http > PC.37595: Flags [.], ack 116,
win 227, options [nop,nop,TS val 3427654471 ecr 3308948604], length 0

　SYN（コネクション確率要求）パケット、FIN（コネクション解放要求）パケットの間に、データのやり取り部分があります。
④～⑦がデータのやりとり部分です。

４．ＷＥＢアクセスでレスポンスが遅い事例

　ＷＥＢアクセスで非常に遅い場合のクライアントとサーバのやりとりの例を示します。



ＷＥＢアクセスが遅い場合のやりとり

＜処理が遅いと仮定した場合の解析＞
　図の青い丸と赤い丸の部分に注目して下さい。
青い丸の部分の値が、pingのレスポンスと変わらない場合は、データのやりとりにおいて遅延が発生している場合があります。
　WWWサーバは、ＤＢ（データベース）サーバにアクセスし、ＤＢサーバの結果を処理して、クライアント側に応答を返す場合もあります。
　データのやりとりのパケットの中身を見ることによりどの部分で遅延が発生しているか推測することが可能です。

　青い丸の部分が遅くなっている場合(ping値も同様に遅い）は、トラヒックが混雑して遅延が発生したり（回線帯域不足）、経由する機器、例えばＦＷ（ファイヤーウォール）等のために遅延が発生している場合も考えられます。

参考： 「アプリケーションの遅延（体感）(3)【サーバインフラ】」のページ

参考： 「ＦＷ超え試験」のページ

５．アプリケーションの遅延（まとめ）

　アプリケーションの遅延は業務に大きな影響を及ぼします。
遅延の原因は、
１．ネットワークインフラに起因するものは、　　
　「ネットワークの遅延」のページに示したとおり、原因も多様です。

２．ネットワークインフラ以外に起因するものは、
　本ページで示したとおり、クライアントとサーバのパケットのやりとりを分析することにより遅延の原因を発見することができる場合があります。
　アプリケーションの遅延は、他にも要因があり、システムのトータル的なチェックが必要です。

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

　・５つのポイントで課題を解決した例（SalesForceの遅延） もご参照下さい。