可以通过 SSL 使用 gzip 吗？和连接：保持活动标头
我正在评估工作中安全 (SSL) Web 应用程序的前端性能，我想知道是否可以通过 SSL 压缩文本文件 (html/css/javascript)。我已经进行了一些谷歌搜索，但没有找到任何与 SSL 特别相关的内容。如果可能的话，由于响应也被加密，是否值得额外的 CPU 周期？压缩响应会损害性能吗？
另外，我想确保我们保持 SSL 连接处于活动状态，这样我们就不会一遍又一遍地进行 SSL 握手。我在响应标头中没有看到连接：保持活动。我确实在 request 标头中看到 Keep-Alive: 115，但这仅使连接保持活动状态 115 毫秒（似乎应用服务器在处理单个请求后关闭连接？）您希望服务器在会话不活动超时时间内设置响应标头？
据我了解，浏览器不会将 SSL 内容缓存到磁盘，因此即使没有任何更改，我们也会在后续访问中一遍又一遍地提供相同的文件。主要的优化建议是减少 http 请求的数量、缩小、将脚本移动到底部、图像优化、可能的域分片（尽管需要权衡另一次 SSL 握手的成本），诸如此类的事情。
I'm evaluating the front end performance of a secure (SSL) web app here at work and I'm wondering if it's possible to compress text files (html/css/javascript) over SSL. I've done some googling around but haven't found anything specifically related to SSL. If it's possible, is it even worth the extra CPU cycles since responses are also being encrypted? Would compressing responses hurt performance?
Also, I'm wanting to make sure we're keeping the SSL connection alive so we're not making SSL handshakes over and over. I'm not seeing Connection: Keep-Alive in the response headers. I do see Keep-Alive: 115 in the request headers but that's only keeping the connection alive for 115 milliseconds (seems like the app server is closing the connection after a single request is processed?) Wouldn't you want the server to be setting that response header for as long as the session inactivity timeout is?
I understand browsers don't cache SSL content to disk so we're serving the same files over and over and over on subsequent visits even though nothing has changed. The main optimization recommendations are reducing the number of http requests, minification, moving scripts to bottom, image optimization, possible domain sharding (though need to weigh the cost of another SSL handshake), things of that nature.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，可以通过 SSL 使用压缩；它发生在数据加密之前，因此可以帮助克服慢速链接。应该注意的是，这是一个坏主意：这也会打开一个漏洞。
初次握手后，SSL 的开销比许多人想象的要少* - 即使客户端重新连接，也有一种机制可以继续现有会话而无需重新协商密钥，从而减少 CPU 使用率和往返次数。
不过，负载均衡器可能会破坏延续机制：如果请求在服务器之间交替，则需要更完整的握手，这可能会产生明显的影响（每个请求大约几百毫秒）。配置负载均衡器以将来自同一 IP 的所有请求转发到同一应用服务器。
您使用哪个应用程序服务器？如果无法将其配置为使用保持活动状态、压缩文件等，请考虑将其放在可以的反向代理后面（当您这样做时，放松使用以下命令发送的缓存标头静态内容 - HttpWatchSupport 的链接文章在这方面有一些有用的提示）。
（*SSL 硬件供应商会说“CPU 增加多达 5 倍”，但有些 来自 Google 的 chaps 报告称，当 Gmail 默认使用 SSL 时，它仅占约 1% 的 CPU 负载）
Yes, compression can be used over SSL; it takes place before the data is encrypted so can help over slow links. It should be noted that this is a bad idea: this also opens a vulnerability.
After the initial handshake, SSL is less of an overhead than many people think* - even if the client reconnects, there's a mechanism to continue existing sessions without renegotiating keys, resulting in less CPU usage and fewer round-trips.
Load balancers can screw with the continuation mechanism, though: if requests alternate between servers then more full handshakes are required, which can have a noticeable impact (~few hundred ms per request). Configure your load balancer to forward all requests from the same IP to the same app server.
Which app server are you using? If it can't be configured to use keep-alive, compress files and so on then consider putting it behind a reverse proxy that can (and while you're at it, relax the cache headers sent with static content - HttpWatchSupport's linked article has some useful hints on that front).
(*SSL hardware vendors will say things like "up to 5 times more CPU" but some chaps from Google reported that when Gmail went to SSL by default, it only accounted for ~1% CPU load)
您可能永远不应该使用 TLS 压缩。无论如何，某些用户代理（至少 Chrome）会禁用它。
您可以有选择地使用 HTTP 压缩
您始终可以缩小
我们也来谈谈缓存
假设您正在使用 HTTPS Everywhere 风格的网站。
场景：
静态内容，如 css 或 js：
具有零敏感信息的 HTML 内容（例如“关于我们”页面）：
包含任何敏感信息的 HTML 内容（例如 CSRF 令牌或银行帐号） ：
缓存控制：无存储，必须重新验证您可以对敏感数据使用 HTTP 压缩如果：
You should probably never use TLS compression. Some user agents (at least Chrome) will disable it anyways.
You can selectively use HTTP compression
You can always minify
Let's talk about caching too
I am going to assume you are using an HTTPS Everywhere style web site.
Scenario:
Static content like css or js:
HTML content with ZERO sensitive info (like an About Us page):
HTML content with ANY sensitive info (like a CSRF token or bank account number):
Cache-Control: no-store, must-revalidateYou can use HTTP compression with sensitive data IF:
使用 SSL 压缩会让您面临漏洞，例如 BREACH、CRIME 或其他选定的纯文本攻击。
您应该禁用压缩，因为 SSL/TLS 目前无法缓解这些长度预言机攻击。
Using compression with SSL opens you up to vulnerabilities like BREACH, CRIME, or other chosen plain-text attacks.
You should disable compression as SSL/TLS have no way to currently mitigate against these length oracle attacks.
对于你的第一个问题：SSL 工作在与压缩不同的层上。从某种意义上说，这两个是 Web 服务器的功能，可以一起工作而不重叠。是的，通过启用压缩，您将在服务器上使用更多的 CPU，但传出流量会更少。所以这更多的是一种权衡。
对于第二个问题：Keep-Alive 行为实际上取决于 HTTP 版本。您可以将静态内容移动到非 SSL 服务器（可能包括图像、电影、音频等）
To your first question: SSL is working on a different layer than compression. In a sense these two are features of a web server that can work together and not overlap. Yes, by enabling compression you'll use more CPU on your server but have less of outgoing traffic. So it's more of a tradeoff.
To your second question: Keep-Alive behavior is really dependent on HTTP version. You could move your static content to a non-ssl server (may include images, movies, audio, etc)