web-dev-qa-db-ja.com

3Gネットワ​​ーク上のWebページの初期接続とSSLハンドシェイクフェーズのロード時間を最適化する方法は?

私のウェブサイトwww.example.com(SSL対応)はAmazon EC2共有ホスティングでホストされています。 Wi-Fi /ブロードバンド接続でより高速にロードします(ロード時間<2秒)。問題は、モバイル**(H +モードではなくHモード)**の3Gネットワ​​ークにあります。接続フェーズを開始すると、SSLハンドシェイクプロセスには多くの時間がかかります(12秒)。 Chrome Networkタブでタイミングパラメータを監視しました。以下は、ウェブページのロードタイミングの測定値です。

Page load Network Timing Stats

ページで処理されるデータの種類:テスト済みのWebページは、AJAXを介して5つのキーと値のペアのJSONデータを受け取り、Webに表示しますページ。これは、5〜6個のテキストコンテンツのみを含む非常に軽量なページです。

多くのWebサイトが3Gモバイルネットワーク(Hモード)でより高速にロードされるのを見てきました。 3Gネットワ​​ークでの最初の接続確立段階で、私のWebサイトが遅すぎます。最初の接続フェーズの遅延を解決/最適化する方法について誰かが助けてくれますか?専用ホスティングに移行すると、現在の問題は解決しますか?

Webサーバーはビジーではなく、常に多くのCPUとメモリが使用可能です。

サーバー設定:Amazon EC2インスタンス-共有ホスティング(32 CPUおよび60 GB RAM)。 Webサーバー-Apache。 SSL-シマンテック。

9
User234334

初期接続

最初の接続にはSSLのネゴシエーションが含まれていることがわかります。したがって、ハンドシェイクが高いため、SSLのセットアップ方法に重大な問題があることを示す良い指標となります。

Google Chrome:リソースのタイミングを理解する

TCPハンドシェイク/再試行およびSSLのネゴシエーションを含む、接続の確立にかかった時間。

SSLハンドシェイクとTTFB

2つの大きな問題があります。SSLハンドシェイクの完了に費やした時間と、TTFBを待機するサーバー(最初のバイトまでの時間)です。

  • TTFB:4079ms(1000ms未満である必要があります)
  • SSLハンドシェイク11830ms(100ms未満でなければなりません)

また、3G/4Gデバイスでテストする場合、電話信号の強度が異なるため、最初のバイトが長くなる可能性があることに注意してください...これにより、断続的な接続の問題やさまざまな待ち時間が発生する可能性があります。

ステップ1:SSLの問題を調査する

あなたが深刻なSSLの問題を抱えていることはかなり明白であり、おそらくOpenSSLまたは同様のものの誤ったインストールが原因です。 SSL Labs を使用してSSL証明書をテストし、それが示唆する問題や警告を修正することから始めます。

SSLの動作がまだ遅い場合、サーバーの過負荷またはサーバー障害が発生している可能性があります。後者の場合は、障害のある場所を絞り込む必要があります。 Server Fault スタックを使用して、この問題についてさらに支援が必要な場合 1人のユーザーが新しいキーを作成するとSSLの問題が解決したと報告された 遭遇する可能性がある、または関連しない場合があります。

ロードバランサーは、サーバーリソースに問題がある場合に役立ちます。

ステップ2:TTFBの調査

調査してSSLの問題を解決しても、TTFBが増加する場合は、十分なリソースがあることを確認してサーバーをテストする必要があります。

最初のバイト時間は、以下の影響を受けますが、これらに限定されません。

  • ユーザーからサーバーをホストするデータセンターまでの距離により、TTFBが増加する可能性があります
  • キャッシュされていないGZIPはTTFBを増やす可能性があります
  • 混雑したネットワークはTTFBを増加させる可能性があります
  • 混雑したサーバーはTTFBを増加させる可能性があります

CPUとRAMを増やすことが常に最適なオプションとは限りません。 ロードバランサー を導入する方が良い場合があります。複数のサーバーを簡単に並べて実行できるというだけでなく、実際にキャッシュとSSL要求をオフロードするからです。その他の利点は次のとおりです。

ソース

  • キャッシング:アプライアンスは、変更のないコンテンツ(画像など)を保存し、Webサーバーにトラフィックを送信せずにクライアントに直接提供できます。
  • 圧縮:ファイルを送信する前に圧縮することにより、HTTPオブジェクトのトラフィック量を削減します。
  • SSLオフロード:SSLトラフィックの処理はWebサーバーのCPUで要求されるため、ロードバランサーは代わりにこの処理を実行できます。
  • 高可用性:1つの障害が発生した場合に、2つの負荷分散アプライアンスを使用できます。

TTFBを下げるためのヒント:

  • データベースが同じネットワーク上にあること、または品質 SQLクラウド であることを確認してください。
  • データベースがメモリから読み取られ、NEVER EVERSWAPファイル!
  • コンテンツ配信ネットワーク を使用して、サーバー要求と圧縮タスクをオフロードします。
  • Varnish Cache を使用して、ページをキャッシュすることでデータベースの負荷を軽減します
  • HDParm を使用して、ハードディスク上の静的ファイルのベンチマークを行います
  • Apache HTTPサーバーベンチマークツール を使用してサーバーのベンチマークを行います
  • WebPageTest を使用して、複数のリモートロケーションで10パスでWebサイトをベンチマークします。
8
Simon Hayter

質問のタイトルを読んで、初期接続とSSL/TLSハンドシェイクを高速化するためにできることが2つあります。これらは3Gだけでなく、あらゆる接続で機能するため、いずれにしてもベストプラクティスとしてこれらを使用する必要があります。

まず、HTTP/2を使用してサイトを提供します。 これにはApache 2.4.17以降が必要です

次に、OCSPステープルを使用するようにApacheを構成します。 これには、Apache 2.3.3以降とOpenSSL 0.9.8h以降が必要です。ここに設定するための適切なガイドが必要です 。 OCSPのステープリングは速度を上げませんが、クライアントのためにいくつかの作業を行い、OCSPルックアップを試行する手間を省きます。

あなたの質問の本文を読んで、ホスティング環境にもっと大きな問題があると思います。これらのロード時間は受け入れられません。あなたはそれが「共有ホスティング」であることを言及します、あなたはその共有ホスティングを管理している人に連絡し、なぜ彼らのサーバーがそんなに異常に遅いのか尋ねるべきです。別の共有ホストを試すか、自分でVPSを実行する方がよいでしょう(これはより多くの作業ですが、速度と柔軟性が向上します)。

既にAWSを使用しているので、なぜ 無料利用枠を試してみてください を試して、自分のサーバーを動作させて最適化してください。テスト用にサブドメインといくつかの静的なHTMLページで使用し、プライマリサイトを移動します(必要に応じて無料利用枠の制限を超えてスケ​​ールアップします)。

6
Tom Brossman