我在这里评估安全(SSL)Web应用程序的前端性能,我想知道是否可以通过SSL压缩文本文件(html/css/javascript).我已经做了一些谷歌搜索,但没有找到任何与SSL特别相关的内容.如果可能的话,因为响应也被加密,它是否值得额外的CPU周期？压缩响应会影响性能吗？
此外,我想确保我们保持SSL连接活着,所以我们不会一遍又一遍地进行SSL握手.我没有在响应标头中看到Connection:Keep-Alive.我确实看到Keep-Alive:115在请求标题中,但这只是保持连接活动115毫秒(似乎应用服务器在处理单个请求后关闭连接？)您不希望服务器设置只要会话不活动超时,响应头是什么？
我知道浏览器不会将SSL内容缓存到磁盘,所以即使没有任何变化,我们也会在后续访问中反复提供相同的文件.主要的优化建议是减少http请求的数量,缩小,将脚本移动到底部,图像优化,可能的域分片(尽管需要权衡另一个SSL握手的成本),这种性质的东西.
是的,可以通过SSL使用压缩; 它发生在数据加密之前,因此可以帮助缓慢的链接.应该指出的是,这是一个坏主意:这也会打开一个漏洞.
在初始握手之后,SSL的开销比许多人想象的要少 - 即使客户端重新连接,也有一种机制可以在不重新协商密钥的情况下继续现有会话,从而减少CPU使用并减少往返次数.
但是,负载平衡器可以使用延续机制:如果请求在服务器之间交替,则需要更多的完全握手,这会产生明显的影响(每个请求约几百毫秒).配置负载均衡器以将来自同一IP的所有请求转发到同一应用服务器.
您使用的是哪个应用服务器？如果它不能被配置为使用保持活跃,压缩文件等等再考虑把它后面的反向代理是可以(并且当你在它,放松与静态内容发送缓存头- HttpWatchSupport已连结文章有关于那个方面的一些有用的提示).
(*SSL硬件供应商会说"高达5倍的CPU",但谷歌的一些人报告说,当Gmail默认情况下转为SSL时,它只占CPU负载的1%左右)
您可能永远不应该使用TLS压缩.一些用户代理(至少是Chrome)无论如何都会禁用它.
您可以有选择地使用HTTP压缩
你总是可以缩小
我们来谈谈缓存
我将假设您正在使用HTTPS Everywhere样式的网站.
场景:
像css或js这样的静态内容:
使用HTTP压缩
使用缩小
缓存期长(如一年)
etag只是勉强有用(由于长缓存)
在HTML中的URL中包含指向此资产的某种版本号,以便您可以缓存
带有ZERO敏感信息的HTML内容(如"关于我们"页面):
使用HTTP压缩
使用HTML缩小
使用短暂的缓存期
使用etag
带有任何敏感信息的HTML内容(如CSRF令牌或银行帐号):
没有HTTP压缩
使用HTML缩小
Cache-Control: no-store, must-revalidate
etag在这里毫无意义(由于重新验证)
会话超时后重定向页面的一些逻辑(考虑多个选项卡).如果有人按下浏览器的"后退"按钮,则由于缓存标头而不显示敏感信息.
您可以对敏感数据使用HTTP压缩IF:
你永远不会在响应中返回用户输入(有一个搜索框？不要使用HTTP压缩)
或者您确实在响应中返回用户输入,但随机填充响应
通过SSL使用压缩可以防止漏洞,例如BREACH,CRIME或其他选择的纯文本攻击.
您应该禁用压缩,因为SSL/TLS目前无法减轻这些长度的oracle攻击.
京公网安备 11010802040832号 | 京ICP备19059560号-6 