据报道，SPDY 容易受到CRIME 攻击，但这将在下一个协议版本中进行修补。CRIME 的具体目标是 HTTP cookie，因此固定协议在压缩 cookie 时会做一些特殊的事情（即，它不会压缩带有其余标头的 cookie；相反，它将使用专用通道来传输 cookie 值，使用特定代码说明“与以前相同的 cookie”）。

作为一般规则，加密会泄漏数据长度，而压缩（任何类型的压缩）使长度取决于数据字节值，从而增加了信息泄漏。加密和压缩不能很好地混合在一起。我个人建议不要为 HTTPS 激活 SPDY。但是，对于纯 HTTP，请继续；它不会让事情变得比使用纯 HTTP 更糟糕的安全性。

收集一些关于 SPDY 的实际带宽优势的硬数据会很有趣。谷歌最初吹嘘要让页面加载“快 55%”，但这是在实验室条件下。实际加速可能因站点处理的请求类型而有很大差异。像往常一样，除非通过明确的措施证明，否则没有性能问题。

SPDY 必须使用 TLS，因为未加密的流量经常被善意的 HTTP 代理破坏。这意味着 SPDY 在很大程度上与使用代理拦截和解码 TLS 流量的位置不兼容。

SPDY 减少了HTTP 流量的开销；因此涉及大量小型 HTTP 请求的应用程序会看到很大的加速，涉及少量大型请求的用例会看到轻微的加速（如果有的话）。

由于 CRIME cookie 压缩问题， Chrome v21禁用了 SPDY 中的标头压缩，因此从理论上讲，它在不久前就不受该特定攻击的影响。据说在 v22 或 v23 中会有更优雅/永久的修复，但我没有可比较的更改日志。Chrome 目前是 v24。

不太可能存在任何已知的安全相关问题；我的研究表明，您使用 SPDY 和使用 HTTPS 一样安全——无论您想表达什么意思。

如果您有一个带有标准资产集合的“普通”网站，SPDY 可能不会提供超过几十毫秒的加速。所以在那种情况下，它真的不值得麻烦。但是，如果您有一个高度交互的 AJAX 密集型应用程序，其中包含许多小查询和更新，SPDY 为自然阻抗不匹配交互性和 HTTP 提供了一个优雅的解决方案。

虽然 4 之前的 SPDY 协议版本（仍在开发中）确实容易受到 CRIME 攻击，但并不知道 SPDY 的实际浏览器实现容易受到攻击。Firefox 目前只是有效地禁用了请求标头压缩，而 Google Chrome 将每个 cookie 放在自己的 Huffman 组中。Adam Langley 在他的博客文章中详细介绍了此事。

如果您在站点范围内启用了 HTTPS，那么使用 SPDY 应该是一个非常可观的胜利。请注意，当 Google 搜索默认切换为使用 SSL 时，尽管有 HTTPS 的成本，但对于支持 SPDY 的浏览器（如 Google Chrome）来说，它实际上更快。