在研究 WebSocket 协议的时候，发现了一个有趣的设计，以下是 WebSocket 帧的说明图：
注意看上面的MASK位和Masking-key位。Masking-key指定了一串掩码，数据帧中负载的应用数据不能直接解析为应用数据，只有通过二进制的掩码与数据帧中的应用负载数据进行指定的公式计算，才能得到真正的应用数据，这个计算公式并不复杂，而且也是公开透明的，大家可以在这里找到这个计算方式，这里想讨论的是，这个设计的目的到底是什么呢？
大部分资料里只是说这个设计目的是为了安全，但是获取数据的Masking-key就在数据中，算法也是公开的，似乎所谓的安全只是为了增加一点点获取真实数据的复杂度而已。
原来这个设计的目的并不是为了保护数据不被窃取，而是防止“缓存中毒”。
什么是缓存中毒？
解释这个问题，要先了解什么是缓存。一些 HTTP 代理服务器，为了提高效率，会将某些 HTTP 请求与响应数据缓存起来，例如，A 用户通过浏览器请求过某个 CDN 上的 JS 文件，例如 http://cdn.xxx.com/jquery.min.js，相应的 CDN 服务器 A 返回了正常的数据响应，那么 A 和 CDN 服务器之间的代理服务器，则可能会将这次请求和响应的 JS 文件缓存起来，此时 B 用户也请求了这个 JS 文件，如果 B 用户的流量也经过了这个代理服务器，那么代理服务器会将 A 触发的缓存直接返回给 B。
也就是说，如果 A 触发的缓存不是正确的 JS 文件，而是经过伪装的，携带了木马的脚本文件，那么这个脚本就会返回给其他用户，形成了一种攻击手段。这就是缓存中毒。
WebSocket 为什么能触发缓存中毒？
发起攻击的人会先建立一个可以响应 WebSocket 的服务器程序，然后通过客户端与它进行连接，然后客户端向服务器发送一个经过精心修饰的数据报文，从二进制的角度看，如果它的数据看起来是这样的：
GET http://cdn.xxx.com/jquery.min.js HTTP/1.1
Host: xxxx
...
然后他的服务器响应返回一段看起来像是一个正常的 HTTP 响应的消息：
HTTP/1.1 200 OK
content-type: text/javascript
...
带有木马的脚本内容
从流量途径的代理服务器的角度看，这次请求看起来像是一个 HTTP 的流量，而它的响应看起来也是一个正常的 HTTP 流量，那么代理服务器就可能要把这个响应缓存起来，于是形成了缓存中毒攻击形式。
掩码的出现，轻微的解决了这个问题，因为它干扰了 WebSocket 帧的数据，WebSocket 协议要求客户端发送给服务器的消息必须携带掩码，这对于一些别有用心的人想要构造一些别有用心的数据报文造成了一定程度的干扰，但是它并没有解决全部问题，因为实现 WebSocket 协议的应用可以选择遵守还是不遵守这个协议，正常使用的浏览器肯定是遵守的，但是如果自己实现一套 WebSocket 协议的客户端和服务器程序，就不受这个规范的控制了。
