ThousandEyes は、Webアプリのパフォーマンスに関わるネットワーク問題をピンポイントで解析します。我々はウェブサイトやネットワークのパフォーマンス問題をすばやく特定するために必要なデータとツールを提供しています。そのテストの1つが「HTTP Server」テストです。クライアントから提供されたURLに基づき、cURLを使用してプロセスの各ステップを実行します。 「通常の」ケースでは、クライアントがウェブサーバーと直接通信しているときに、これらの値を測定するのは簡単なことです。しかし、残念ながら、一部のクライアントはプロキシの背後にあり、監視したいWebサーバーと直接話すことはできません。エージェントはプロキシを使用するように設定できますが、HTTPプロキシを使用してパフォーマンスを測定するのは少し面倒です。このブログ記事では、直接通信とプロキシ通信の違いと、プロキシがタイミング測定にどのように影響するかを説明させていただきます。
HTTPリクエストの構造
URLを取得する際には、DNS解決（DNS時間）、TCP接続（接続時間）、SSLハンドシェイク（SSL時間）、リクエスト送信と最初のバイトの待機応答（待ち時間）、および完全な応答を受信（受信時間）の5つの異なる段階があります。エージェントの1人がWebサーバーに直接リクエストした際に、これらの値を測定するのはとても簡単です。図1は、www.cnn.comのサンプルリクエストのタイミング図を示しています。
DNS時間は、www.cnn.comのIPアドレスに解決する時間として計算されます。接続時間は、DNS解決から返されたIPアドレスへのTCP接続を確立するのにかかる時間です。 URLがHTTPSを介して提供される場合、次にSSLハンドシェイクが行われます。待機時間は、HTTP要求が送信されてから応答の最初のバイトが受信されるまでの時間として計算されます。最後に、受信時間は、最初と最後のバイトが受信されるまでの時間です。
プロキシ環境下では
HTTPプロキシを介して通常のHTTP（HTTPSではない）要求が行われた場合、これらの手順のほとんどすべてが影響を受けます。図2は、www.cnn.comへの代理リクエストを行うクライアントの通信パターンを示しています。 DNS時間は、www.cnn.comではなく、プロキシのホスト名を解決する時間です。同様に、接続時間はプロキシサーバーに接続する時間です。次のステップは、クライアントからのHTTP要求のプロキシへの送信です。この時点で、プロキシはwww.cnn.comをIPアドレスに解決し、このIPアドレスへの接続を開き、クライアントのHTTP要求をWebサーバーに転送する必要があります。プロキシはそれを受け取ったクライアントにデータを転送します。
クライアントの観点から見ると、元のDNS時間と接続時間は待機時間の一部として呑み込まれました。これらの値を個別に測定することはもはや不可能です。一般的には、待ち時間の増加は、Webサーバーが要求を十分に素早く処理するためのリソースを持っていないことが原因です。残念なことに、プロキシを使用すると、接続時間が長くなるようなこの種の問題を、遅いDNSプロバイダやパケットロスの多いネットワークが原因かを切り分けることができなくなります。
HTTPS要求のプロキシ
クライアントがプロキシ経由でHTTPS要求を行うと、全体像はさらに複雑になります。図3は、https://www.bofa.comの代理リクエストの通信パターンを示しています。 DNSと接続時間はプロキシされたHTTPリクエストと同じ方法で測定されますが、SSLハンドシェイクの処理には特別な処理が必要です。これを行うために、クライアントはまず接続を開くべきサイトを示す "CONNECT"メッセージをプロキシに送信します。次に、プロキシはwww.bofa.comのDNS解決を行い、得たIPアドレスへのTCP接続を開きます。この時点で、接続が確立されたことを示すメッセージをクライアントに返します。クライアントはSSLハンドシェークを開始します。SSLハンドシェイクは、Webサーバーへのプロキシのオープン接続を介してトンネリングされます。 SSL時間は、「CONNECT」メッセージが送信されてからSSLハンドシェイクが完了するまでの時間として測定されます。最後に、クライアントはトンネル接続を介して暗号化された要求を送信し、待機時間と受信時間はプロキシなしで測定されます。 HTTPトンネリングの詳細については、RFC 2817を参照してください。
プロキシされたHTTP接続では、DNSと接続時間が待機時間の一部として飲み込まれてしまいました。ただし、HTTPS要求を行う場合、これらの値はSSL時間の一部になります。さらに、クライアントとプロキシ間で追加の "CONNECT"メッセージと "Connection established"メッセージが送信されるため、SSL時間も膨らんでしまいます。
実例
実際のWebサイトで5つのステップの値がどのように変化するかを示すために、プロキシの有と無の両方のパターンで、http：//www.cnn.comおよびhttps://www.bofa.comに対するcURLクライアントの測定を行いました。 以下がその結果です。
いずれの場合も、プロキシを使用した場合の影響がはっきりとわかります。 プロキシのDNS名はキャッシュされており、ネットワーク上では近いため、非常に小さなDNSと接続時間となります。 予想通り、このステップではDNSとの接続時間に対応するcnn.comの待機時間が大幅に増加しています。 一方、bofa.comでは、待機時間と受信時間の両方がプロキシ有りと無しで一致していますが、SSL時間が大幅に増大しています。
Chrome上のプロキシのタイミング
プロキシされたHTTPS接続の場合、リクエストを繰り返すcURLの方式は、Chromeがタイミングを報告する方式（ThousandEYesの「ページ読み込み」テストに表示されるような）とは少し異なります。具体的には、「CONNECT」と「Connection established」メッセージの間の時間はChromeの接続時間に含まれ、cURLはSSL時間の一部としてカウントします。 全体的な効果はそれほど大きなものではありませんが、cURLとChromeのタイミングを比較しようとするときには気をつけなければなりません。
結論
このブログ記事では、プロキシ有/無のウェブリクエストのタイミングと、プロキシが採用されている場合の結果がどのように歪むかについて説明しました。 HTTPプロキシはエンタープライズ環境では広く採用されているため、サイトパフォーマンスを測定する際に結果を注意深く解釈する必要があります。 プロキシは、ページコンテンツがローカルにキャッシュされている場合はオブジェクトの読み込みを高速化できますが、監視対象のサイトの真のパフォーマンス特性を隠す場合もあります。
