SSL 慢。建立安全连接耗时过长答案

【问题标题】：SSL slow. Establishing secure connection taking too longSSL 慢。建立安全连接耗时过长
【发布时间】：2018-06-11 18:19:11
【问题描述】：

我在 Hetzner 上有一个带有 256GB RAM 6 CPUs (12 Threads) 的专用服务器，它位于德国。我有 CENTOS 7.5。 EA4.

我的问题在于 SSL。每天大约 2 小时，我们在一秒钟内有 40 个请求，完成请求大约需要 20 秒。非 SSL 需要 0.5 或更少。 Here 就是一个例子。

从13:00 到 15:30 (UTC+4)，SSL 请求花费的时间最多。当您使用 SSL 和不使用 SSL 打开 this link 时，问题很明显。

我有可用的 WHM。我注意到 ModSecurity 并想知道这是否是问题所在。我已经应用了here 提供的大部分设置，但关于 SSL 的内容并不多。

如果证书是所有这些的原因：

【问题讨论】：

这对Server Fault来说是一个更好的问题。
希望它不违反stackoverflow的某些政策。我在这里看到了很多与服务器相关的问题，而且大部分都得到了很好的答案。
这有点离题了。不过，更重要的是，你会在那儿得到比在这儿更有用的回复。如果您愿意，可以点击帖子下方的“标记”，然后请求模组将其迁移到那里。
已标记。现在希望得到一些好的答案。
示例链接看起来证书不正确？ ssllabs.com/ssltest/analyze.html?d=viber.ge

标签： ssl httpresponse mod-security

【解决方案1】：

我遇到了同样的问题，经过大量挖掘后，我发现问题是由于我安装了 mod_unique_id 造成的。

进一步检查表明该模块是 mod_security 的要求。我一开始确实删除了 mod_security，它没有做任何更改，只有在删除 mod_unique_id 模块之后，事情才开始发展。

希望这会有所帮助。

【讨论】：

我现在没有这个问题，希望这会对某人有所帮助。

【解决方案2】：

到目前为止，我无法重现您的问题。 WebPageTest reports are all good and pretty. SSL 协商在预期的 100-200 毫秒内，考虑到您启用了 OCSP 装订。否则，在 IE 下会花费更长的时间。可以说 HTTPS 一开始总是比普通的 HTTP 慢，你无法真正比较它们。这一切都让我觉得……

一个可能的罪魁祸首是提到的OCSP stapling。 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 之前有效，but Apache is configured to expire them quite earlier by default。特别是在一个小时之后。您应该尝试将此超时设置为更有意义的值，例如最多一周：

SSLStaplingStandardCacheTimeout 604800

另一个可能的建议是逆向建议：尝试完全禁用 OCSP 装订一段时间。

如果这确实有助于解决问题，那么您应该联系您的 CA 寻求帮助，或者改用其他已知没有此类问题的 CA（想想 Let's Encrypt），或者使用可以异步处理 OCSP 装订并将它们缓存更长的时间（想想 nginx）。

进一步的研究表明，Apache 可以使用 work around slow or unreliable OCSP responders，尽管我不确定这些变通办法对你的情况有什么好处。

【讨论】：

【解决方案3】：

Modsecurity 可能是个问题，如果它占用大量 CPU 并与 TLS 竞争（尽管可能性不大）。

关键是“每天大约 2 小时，我们在一秒钟内有 40 个请求，而此时完成请求有时需要大约 20 秒。”当时此服务器上发生了一些事情这（可能）使 CPU 加载（因为建立 HTTPS 连接是 CPU 密集型的）。因此，请在发生这种情况时检查您的服务器。这将是您的性能瓶颈。

另一点 - 考虑到从 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、网络、您的服务器。

一旦完成 - 深入研究。假设您的服务器行为不端： - 检查服务器日志——在那段时间里他们应该有一些东西； - 考虑关闭 modsecurity（这是非常 CPU 密集型的）； - 在服务器上开启缓存； - 考虑两台服务器之间的负载平衡； - 也许磁盘很慢 - 检查一下。

附： 100% 解决问题的解决方案很难，因为没有为此提供很多细节。

【讨论】：

【解决方案4】：

谢谢你们的回答。

毕竟不是 OCSP。证书和一些 Apache 配置发生了一些问题。我们雇了服务员，他修好了。

因此，如果有人遇到此类问题，应检查服务器配置并寻找优化方法，同时检查证书。这修复了每个响应的 3-4 秒等待时间。

更大的问题是使用geoplugin 从 IP 地址检测国家/城市。我不知道 Curl 会减慢这么短的响应时间。我当然不是在责怪geoplugin。当我分析我的代码时，它说从开始到结束需要 127 毫秒，但事实证明分析器只是跳过了这个 geoplugin 等待时间。

总之，修改代码、处理证书和服务器配置实现了它。

附：我不知道如何处理这个赏金。我不希望它浪费，所以我会把它交给即使答案没有解决我的问题并且问题在赏金到期并且问题已经解决的前一天回答的人。

【讨论】：