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


11

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

ページ読み込みネットワークのタイミング統計

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

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

Webサーバーはビジーではなく、常に使用可能なCPUとメモリがたくさんあります。

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


Elastic Load Balancerを使用してHTTPSを処理してみましたか?私はそれをAmazonで使用していますが、このようなパフォーマンスの問題は見たことがありません。繰り返しになりますが、3G接続に対して特にテストしたことはありません。
スティーブンオスターミラー

ありがとうございました。サーバーは負荷分散されていません。特定のパラメータでサーバーを再度テストし、それを試します。
User234334

回答:


8

初期接続

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

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

TCPハンドシェイク/再試行やSSLのネゴシエーションなど、接続の確立にかかった時間。

SSLハンドシェイクとTTFB

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

  • TTFB:4079ミリ秒(1000ミリ秒未満である必要があります)
  • SSLハンドシェイク11830ms(100ms未満である必要があります)

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

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

SSLに重大な問題があることは明らかで、おそらくOpenSSLのインストールの失敗などが原因です。まず、SSL Labsを使用してSSL証明書をテストし、提案されている問題や警告を修正します。

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

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

ステップ2:TTFBの調査

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

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

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

時には、CPUとRAMを増やすことが常に最良の選択肢であるとは限りません。ロードバランサーを導入すると、複数のサーバーを簡単に並べて実行できるだけでなく、実際にキャッシュとSSL要求の負荷を軽減できるため、導入する方が良い場合があります。他のいくつかの利点は次のとおりです。

ソース

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

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


詳しい説明ありがとうございます。提案されたパラメーターでサーバーを再度テストし、最適なものを実装します!
User234334 2016年

質問のグラフは、SSLハンドシェイクと最初のリクエストおよびTTFBを分離しています。そのグラフによると、問題は実際にはリクエストが行われる前のSSLにあります。
スティーブンオスターミラー

@StephenOstermiller見事に見つけた。SSLが11000ミリ秒を超えている間、待機中のTTFBは4000ミリ秒です。SSLがTTFBに影響している可能性があります。それを反映するように質問を更新しました。
Simon Hayter

ありがとうございました!www.ssllabs.comでSSLをテストしましたが、評価は「A」でした。警告/問題は報告されていません。Apacheのバージョンは2.2.15であり、古くなっています。今すぐ更新する必要があります。私のウェブサイトのコンテンツ(TBでのサイズ)は/ var / www / html /にあります。Apacheを更新/再インストールすると、ウェブサイトのコンテンツが削除されますか?データを失うことなく更新する最も安全な方法はありますか?
User234334 2016年

もう1つのポイント-OpenSSLも最新バージョンです。
User234334

6

質問のタイトルを読むと、初期接続と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ページで使用し、プライマリサイトを移動します(必要に応じて、無料枠の制限を超えて拡大します)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.