web-dev-qa-db-ja.com

SSLが遅い。安全な接続の確立に時間がかかりすぎる

Hetznerに_256GB RAM_ 6 CPUs (12 Threads)の専用サーバーがあり、ドイツにあります。私はCENTOS 7.5を持っています。 EA4。

私の問題はSSLにあります。毎日約2時間、1秒間に40件のリクエストがあり、リクエストの完了には約かかります20秒。非SSLは0.5以下を取ります。 ここ は一例です。

13：00から15:30（UTC + 4）まで、SSLリクエストに最も時間がかかります。この問題は、SSLありとなしで このリンク を開くと明らかです。

WHMを利用できます。 ModSecurityに気づき、問題があるのではないかと思いました。提供されている設定のほとんどを適用しました ここ ですが、SSLに関してはあまりありません。

enter image description here

証明書がこのすべての理由である場合：

enter image description here

sslhttpresponsemod-security
7
temo

回答ありがとうございます。

結局、OCSPではありませんでした。証明書とApache構成に問題が発生しました。私たちはサーバーの人を雇い、彼はそれを修正しました。

したがって、この種の問題が発生した場合は、サーバーの構成を確認して最適化する方法を探す必要があります。また、証明書も確認してください。これにより、すべての応答の待機時間の3〜4秒が修正されました。

より大きな問題は、IPアドレスから国/都市を検出するためのgeopluginの使用でした。 Curlが応答時間をそれほど遅くする可能性があることを私は知りませんでした。もちろん、私はgeopluginのせいではありません。コードをプロファイリングすると、開始から終了まで127ミリ秒と表示されましたが、プロファイラーがこのジオプラグインの待機時間または待機時間をスキップしたことがわかりました。

結論として、コードを変更し、証明書とサーバー構成を処理することで、それが実現しました。

P.S.私はこの恵みにどう対処するかわかりません。私はそれを無駄にしたくないので、答えが私の問題を解決せず、賞金が切れる前日に質問が答えられ、問題がすでに解決されたとしても答えた誰かにそれを与えるつもりです。

0
temo

これまでのところ、私はあなたの問題を再現することができません。 WebPageTestレポートはすべて良好できれいです。 OCSPステープリングが有効になっていることを考慮すると、SSLネゴシエーションは予想される100〜200ミリ秒以内です。 IEでなければ、もっと時間がかかったでしょう。HTTPSは最初はプレーンHTTPよりも常に遅いと言えば、実際に比較することはできません。そのすべてが私にそう思わせます。 。

考えられる原因の1つは、言及されている OCSPステープリング です。サーバーでのOCSPステープリングが行うことは、サーバーがCAに接続して、署名されたOCSP応答を受信することです。この状況では、CAがボトルネックになる可能性があります。期待どおりの応答が時間どおりに提供されない場合は、接続も停止します。これは、SSLネゴシエーション中に発生します。

次のコマンドを使用して、キャッシュされたOCSP応答が有効である期間を確認できます。

openssl s_client -connect banners.analyticson.com:443 -status -servername banners.analyticson.com

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Produced At: Jun 17 21:47:34 2018 GMT
    Cert Status: good
    This Update: Jun 17 21:47:34 2018 GMT
    Next Update: Jun 24 21:47:34 2018 GMT

現在、OCSP応答は少なくとも2018年6月24日21:47:34 GMTまで有効であると報告されています ただし、Apacheはデフォルトでかなり早く期限切れになるように構成されています 。具体的には、ちょうど1時間後です。このタイムアウトを、最大1週間など、より意味のある値に上げてみてください。

SSLStaplingStandardCacheTimeout 604800

もう1つの考えられるアドバイスは、逆張りのアドバイスです。しばらくの間、OCSPステープリングを完全に無効にしてみてください。

これが本当に問題の解決に役立つ場合は、CAに連絡して支援を求めるか、そのような問題がないことがわかっている別のCAを使用するように切り替えるか（Let's Encryptを考えてください）、OCSPステープリングを処理できる別のWebサーバーを使用する必要があります。非同期でそれらをより長い時間キャッシュします（nginxを考えてください）。

さらなる調査によると、Apacheは 遅いまたは信頼性の低いOCSPレスポンダーを回避する にすることができますが、これらの回避策があなたの場合に役立つかどうかはわかりません。

1
sanmai

Modsecurityは、CPUを大量に消費し、TLSと競合する場合、問題になる可能性があります（ただし、確率はそれほど大きくありません）。

重要なのは「毎日約2時間、1秒間に40のリクエストがあり、その時点でリクエストの完了に約20秒かかることもあります。 "その時点でこのサーバーで何かが起こっています（おそらく）CPUをロードします（HTTPS接続を行うとCPUに負荷がかかるため）。したがって、これが発生したときにサーバーを検査してください。これがパフォーマンスのボトルネックになります。

もう1つのポイント-Pingdomからサーバーへのネットワークで何かが起こっている可能性があることを考慮して、問題が次のように起こっているときにcurlでベンチマークします。

x@517713:~$ curl -w "TC:%{time_connect} TST:%{time_starttransfer} TT:%{time_total}\n" https://blog.x.cf -D /dev/null -o /dev/null -s
TC:0.005 TST:0.336 TT:0.377

これらはすべてのオプションです。

    time_namelookup:  %{time_namelookup}\n
       time_connect:  %{time_connect}\n
    time_appconnect:  %{time_appconnect}\n
   time_pretransfer:  %{time_pretransfer}\n
      time_redirect:  %{time_redirect}\n
 time_starttransfer:  %{time_starttransfer}\n
                    ----------\n
         time_total:  %{time_total}\n

何が間違っている可能性があるかについては非常に多くのオプションがあるため、問題がどこにあるかを特定することから始める必要があります：Pingdom、Network、Youサーバー。

それが完了したら、さらに深く掘り下げます。誤動作しているのはサーバーであるとしましょう。-サーバーログを確認します-その間、サーバーに何かが含まれているはずです。 -modsecurityをオフにすることを検討してください（これは非常にCPUを集中的に使用します）。 -サーバーのキャッシュをオンにします。 -2台のサーバー間の負荷分散を検討してください。 -ディスクが遅いかもしれません-確認してください。

P.S.この問題を100％解決するソリューションは、詳細があまり提供されていないため困難です。

1
Mindaugas Bernatavičius