SSL缓慢。建立安全连接时间太长。

Question

我有一台位于德国的Hetzner服务器，配备了256GB RAM和6个CPU（12线程），操作系统为CENTOS 7.5，使用EA4。我的问题在于SSL。每天大约有2小时时间，我们会收到40个请求/秒，完成请求需要20秒左右。非SSL只需要0.5秒或更短的时间。这是一个示例。

从13:00到15:30（UTC+4），SSL请求需要最长的时间。当您使用SSL打开此链接时，问题就显而易见了。

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

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

- temo

---

这个问题更适合在[sf]上提问。 - Sneftel

希望这不会违反stackoverflow的某些政策。我在这里看到了许多与服务器相关的问题，它们大多得到了很好的答案。 - temo

标记。希望现在能得到一些好的答案。 - temo

我在那个网站上没有SSL。它从另一个拥有有效SSL证书的网站请求数据。 - temo

我刚刚发布了一个相关的问题https://serverfault.com/questions/1141176/apache-2-4-on-windows-slow-to-respond-to-initial-first-request - MeSo2

Answer 1

我也遇到了同样的问题，经过很多查找，发现问题是由于我安装了 mod_unique_id 模块导致的。

进一步检查发现该模块是 mod_security 的一个要求。一开始我尝试移除 mod_security 但没有任何变化，只有在移除 mod_unique_id 模块后，事情才开始顺利起来。

希望这可以帮到你。

- Bursuc Sergiu

---

我现在没有这个问题，希望这能帮到别人。 - temo

这很有帮助。 - Vinod Puliyadi

Answer 2

到目前为止，我无法重现您的问题。 WebPageTest报告非常好看。考虑到您启用了OCSP stapling，SSL协商在预期的100-200毫秒范围内。否则，在IE下会花费更长时间。可以说HTTPS始终比纯HTTP慢，您无法真正进行比较。所有这些使我想到...

一个可能的罪魁祸首是已提到的OCSP stapling。您服务器上的OCSP stapling做的是不时地联系您的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

目前报告显示，至少到2018年6月24日21:47:34 GMT，OCSP响应是有效的，但是Apache默认配置为提前过期。具体来说，仅经过一小时。您应该尝试将此超时时间延长到更有意义的值，例如一周：

SSLStaplingStandardCacheTimeout 604800

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

如果这真的有助于解决问题，那么您应该联系您的CA寻求帮助，或者切换到使用已知没有此类问题的其他CA（比如Let's Encrypt），或者使用可以异步处理OCSP装订并缓存更长时间的不同Web服务器（比如nginx）。

进一步的研究表明，Apache可以被制作成解决慢或不可靠的OCSP响应者，虽然我不确定这些解决方法在您的情况下是否有用。

- sanmai

Answer 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）； - 在服务器上启用缓存； - 考虑在 2 台服务器之间进行负载均衡； - 也许磁盘速度慢 - 检查一下。

P.S. 解决问题 100% 的解决方案很难，因为没有提供太多细节。

- Mindaugas Bernatavičius

Answer 4

感谢大家的回答。

实际上，这不是OCSP的问题。由于证书和Apache配置存在一些问题，我们雇了一名服务器专家来解决它。

因此，如果有人遇到这种问题，应该检查服务器配置并寻找优化方法，还要检查证书。这解决了每次响应等待3-4秒的问题。

更大的问题是使用geoplugin从IP地址检测国家/城市。我不知道Curl会导致如此低的响应时间。当我对我的代码进行分析时，它说从开始到结束需要127毫秒，但结果表明，分析器跳过了这个geoplugin等待时间。

总之，修改代码、处理证书和服务器配置使其发生了变化。

附言：我不知道如何处理这个奖励。我不想让它白白浪费，所以我会把它给那些回答了问题但没有解决我的问题，并且问题在悬赏期到期前一天已经得到解决的人。

- temo