SSL速度慢。建立安全连接的时间过长

Question

我在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打开this link而没有。

时，问题就很明显了

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

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

Answer 1

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

进一步检查表明该模块是mod_security的必需项。起初我确实删除了mod_security，但并没有做任何更改，只是删除了 mod_unique_id 模块，然后事情开始飞起来。

希望这会有所帮助。

Answer 2

到目前为止，我无法重现您的问题。考虑到您已启用OCSP装订，WebPageTest reports are all good and pretty. SSL协商在预期的100-200毫秒内。否则，在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日格林尼治标准时间but Apache is configured to expire them quite earlier by default}有效。特别是一个小时后。您应该尝试将此超时设置为更有意义的值，例如长达一周的时间：

SSLStaplingStandardCacheTimeout 604800

另一种可能的建议是相反的建议：尝试一段时间完全禁用OCSP装订。

如果这确实可以帮助您解决问题，那么您应该与CA联系以寻求帮助，或者切换到使用其他已知不存在此类问题的CA（请考虑加密），或者使用可以异步处理OCSP装订并缓存更长的时间（请考虑使用nginx）。

进一步的研究表明，可以使用Apache work around slow or unreliable OCSP responders，尽管我不确定这些变通办法是否对您有用。

Answer 3

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

关键是“ 每天大约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）； -打开服务器上的缓存； -考虑2台服务器之间的负载平衡； -也许磁盘很慢-检查一下。

P.S。要解决这一问题的解决方案很难100％地解决，因为没有提供很多详细信息。

Answer 4

谢谢你们的回答。

毕竟不是OCSP。证书和某些Apache配置碰巧存在一些问题。我们雇用了服务器人员，他将其修复。

因此，如果任何人遇到此类问题，都应检查服务器配置并寻找优化方法，并检查证书。这将每个响应的等待时间定为3-4秒。

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

最后，修改代码，处理证书和服务器配置使其成为现实。

P.S。我不知道如何处理这个赏金。我不想浪费它，所以我将它提供给即使您的回答仍无法解决我的问题并且在悬赏期满且问题已解决的前一天得到了回答的人。