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

Question

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

此外,我想确保我们保持SSL连接活着,所以我们不会一遍又一遍地进行SSL握手.我没有在响应标头中看到Connection:Keep-Alive.我确实看到Keep-Alive:115在请求标题中,但这只是保持连接活动115毫秒(似乎应用服务器在处理单个请求后关闭连接？)您不希望服务器设置只要会话不活动超时,响应头是什么？

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

Answer 1

是的,可以通过SSL使用压缩; 它发生在数据加密之前,因此可以帮助缓慢的链接.应该指出的是,这是一个坏主意:这也会打开一个漏洞.

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

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

您使用的是哪个应用服务器？如果它不能被配置为使用保持活跃,压缩文件等等再考虑把它后面的反向代理是可以(并且当你在它,放松与静态内容发送缓存头- HttpWatchSupport已连结文章有关于那个方面的一些有用的提示).

(*SSL硬件供应商会说"高达5倍的CPU",但谷歌的一些人报告说,当Gmail默认情况下转为SSL时,它只占CPU负载的1%左右)

Answer 2

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

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

3. 你总是可以缩小

4. 我们来谈谈缓存

我将假设您正在使用HTTPS Everywhere样式的网站.

场景:

1. 像css或js这样的静态内容:

   • 使用HTTP压缩
   • 使用缩小
   • 缓存期长(如一年)
   • etag只是勉强有用(由于长缓存)
   • 在HTML中的URL中包含指向此资产的某种版本号,以便您可以缓存

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 服务器（可能包括图像、电影、音频等）