您可以通过 SSL 使用 gzip 吗?和连接:Keep-Alive 标头 [英] Can you use gzip over SSL? And Connection: Keep-Alive headers
问题描述
我正在评估一个安全 (SSL) 网络应用程序的前端性能，我想知道是否可以通过 SSL 压缩文本文件 (html/css/javascript).我已经做了一些谷歌搜索，但没有找到任何与 SSL 相关的内容.如果可能的话，由于响应也被加密，额外的 CPU 周期是否值得?压缩响应会影响性能吗?
另外，我想确保我们保持 SSL 连接处于活动状态，这样我们就不会一遍又一遍地进行 SSL 握手.我在 响应 标头中没有看到 Connection: Keep-Alive.我确实在 request 标头中看到了 Keep-Alive: 115 但这只是使连接保持活动状态 115 毫秒(似乎应用服务器在处理单个请求后关闭连接?)您希望服务器在会话不活动超时期间设置 响应 标头?
我知道浏览器不会将 SSL 内容缓存到磁盘，因此即使没有任何更改，我们也会在后续访问中一遍又一遍地提供相同的文件.主要的优化建议是减少 http 请求的数量、缩小、将脚本移到底部、图像优化、可能的域分片(尽管需要权衡另一次 SSL 握手的成本)等等.
是的，可以通过 SSL 使用压缩；它发生在数据加密之前，因此可以帮助解决慢速链接.应该注意的是，这是一个坏主意:这也会打开一个漏洞.
在初次握手之后，SSL 的开销比许多人想象的要少* - 即使客户端重新连接，也有一种机制可以在不重新协商密钥的情况下继续现有会话，从而减少 CPU 使用率和往返次数.
负载均衡器可能会破坏延续机制:如果请求在服务器之间交替，则需要更完整的握手，这可能会产生明显的影响(每个请求大约几百毫秒).将您的负载平衡器配置为将来自同一 IP 的所有请求转发到同一应用服务器.
您使用的是哪个应用服务器?如果它不能被配置为使用保持活动，压缩文件等等，那么考虑把它放在一个可以的反向代理后面(当你在它的时候，放宽用静态内容 - HttpWatchSupport 的链接文章在这方面有一些有用的提示).
(*SSL 硬件供应商会说CPU 最多增加 5 倍"，但有些来自 Google 的 chaps 报告说，当 Gmail 默认使用 SSL 时，它只占了大约 1% 的 CPU 负载)
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.
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)
这篇关于您可以通过 SSL 使用 gzip 吗?和连接:Keep-Alive 标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
