你可以在SSL上使用gzip吗？和连接：Keep-Alive标题

Question

我正在评估安全（SSL）网络应用程序的前端性能，我想知道是否可以通过SSL压缩文本文件（html / css / javascript）。我已经做了一些谷歌搜索，但没有找到任何与SSL特别相关的内容。如果可能的话，因为响应也被加密，它是否值得额外的CPU周期？压缩响应会影响性能吗？

另外，我想确保我们保持SSL连接活着，这样我们就不会一遍又一遍地进行SSL握手。我没有在响应标题中看到连接：保持活跃。我确实在请求标题中看到了Keep-Alive：115，但这只是保持连接活动115毫秒（似乎app服务器在处理单个请求后关闭了连接？）不会只要会话不活动超时，您希望服务器设置响应标头吗？

我理解浏览器不会将SSL内容缓存到磁盘，因此即使没有任何更改，我们也会在后续访问中反复提供相同的文件。主要的优化建议是减少http请求的数量，缩小，将脚本移动到底部，图像优化，可能的域分片（尽管需要权衡另一个SSL握手的成本），这种性质的东西。

Answer 1

是的，可以通过SSL使用压缩;它发生在数据加密之前，因此可以帮助缓慢的链接。应该注意的是，这是一个坏主意：this also opens a vulnerability 。

在初始握手之后，SSL的开销比许多人想象的要少 - 即使客户端重新连接，也有一种机制可以在不重新协商密钥的情况下继续现有会话，从而减少CPU使用并减少往返次数。

负载平衡器可以使用延续机制，但是：如果请求在服务器之间交替，则需要更多的完全握手，这会产生明显的影响（每个请求几百毫秒）。配置负载均衡器以将来自同一IP的所有请求转发到同一个应用服务器。

您使用的是哪个应用服务器？如果它无法配置为使用keep-alive，压缩文件等，那么请考虑将其放在可以的反向代理之后（当你在它的时候，放松发送的缓存头）静态内容 - HttpWatchSupport的链接文章在前面有一些有用的提示。）

（* SSL硬件供应商会说“CPU高达5倍”，但有些chaps from Google报告说，当Gmail默认情况下转为SSL时，它只占CPU负载的1％左右）

Answer 2

1. 您可能永远不应该使用TLS压缩。一些用户代理（至少是Chrome）无论如何都会禁用它。

2. 您可以有选择地使用HTTP压缩

3. 您可以随时缩小

4. 让我们谈谈缓存

我假设你正在使用HTTPS Everywhere风格的网站。

情景：

1. 静态内容，如css或js：

   • 使用HTTP压缩
   • 使用缩小
   • 长缓存期（如一年）
   • etag仅略微有用（由于长缓存）
   • 在HTML中的URL中包含某种版本号，指向此资产，以便您可以使用cache-bust

2. 带有ZERO敏感信息的HTML内容（如“关于我们”页面）：

   • 使用HTTP压缩
   • 使用HTML缩小
   • 使用短暂缓存期
   • 使用etag

3. 包含任何敏感信息的HTML内容（如CSRF令牌或银行帐号）：

   • 无HTTP压缩
   • 使用HTML缩小
   • Cache-Control: no-store, must-revalidate
   • etag在这里毫无意义（由于重新验证）
   • 在会话超时后重定向页面的一些逻辑（考虑多个选项卡）。如果有人按下浏览器的“后退”按钮，则由于缓存标头而不显示敏感信息。

您可以对敏感数据使用HTTP压缩IF：

1. 你永远不会在回复中返回用户输入（有一个搜索框？不要使用HTTP压缩）
2. 或者您确实在响应中返回用户输入，但随机填充响应

Answer 3

通过SSL使用压缩功能可以防止漏洞，例如BREACH，CRIME或其他选择的纯文本攻击。

您应该禁用压缩，因为SSL / TLS目前无法抵御这些长度的oracle攻击。

Answer 4

关于第一个问题：SSL正在处理与压缩不同的层。从某种意义上说，这两个是Web服务器的功能，它们可以一起工作而不会重叠。是的，通过启用压缩，您将在服务器上使用更多CPU但具有较少的传出流量。所以这更多的是权衡。

关于第二个问题：Keep-Alive行为实际上取决于HTTP版本。您可以将静态内容移动到非ssl服务器（可能包括图像，电影，音频等）

Answer 5

是的，gzip压缩和Keep-Alive可以与HTTPS / SSL一起使用。此外，浏览器可以缓存SSL内容。

此博客文章提供了有关调整HTTPS / SSL网站的更多信息：

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/