作者简介：
花名“卡库”，白山云科技系统开发工程师
API开发与管理老鲜肉，丰富的产品开发与运维经验，先后就职于搜狐、新浪等知名互联网公司，曾参与新浪云SAE平台CC防火墙项目，为数十万用户提供安全防护，保证SAE平台性能稳定；2016年入职白山，就此成为酒仙桥地区最大酒窝的系统开发工程师。
针对实时Web应用（如：实时通信、股票基金应用、体育实况更新、多玩家游戏等场景），传统Web中为了实时获取Server端的数据，通常是Client端定期发送HTTP请求，Server端进行响应并返回数据。由于Client定期向Server发送请求，当Server端没有数据更新时，Client仍旧发送请求，这造成了带宽的浪费以及Server端CPU的占用。
为解决上述问题，越来越多企业在思考如何解决长连接问题，WebSocket是较为常用的方法之一。WebSocket通过第一个 HTTP request 建立 TCP 连接，后续数据交换都无需再发送 HTTP request，创建了一个真正的长连接。同时WebSocket 还是一个双通道的连接，可以实现在同一个 TCP 连接上收发信息。
白山云聚合平台也融入了WebSocket，可以为用户提供WebSocket协议到HTTP协议的转换功能，让用户的Client以长连接WebSocket协议的方式连接到云聚合平台，云聚合只需一个HTTP连接即可连接到企业后端，大幅降低后端压力的同时，更免去了用户服务器端适配WebSocket协议的问题。我们在研发测试过程中遇到了一个有意思的问题，这或许是很多开发者都曾遇到过的：使用不同的WebSocket客户端和WebSocket Server通信，WebSocket Server返回数据不一致。
一、问题场景
1.不同客户端访问
（1）python通过WebSocket客户端和WebSocket Server ws://2abe356fc.bsclink.com/交互，输出正常；
（python 客户端输出内容）
（2）Chrome浏览器加载ws.html页面之后，页面中的js调用浏览器自带的WebSocket Client与WebSocket Server ws://2abe356fc.bsclink.com/交互，输出ERROR；
（Chrome浏览器输出内容）
（3）Safari浏览器加载ws.html页面之后，页面中的js调用浏览器自带的WebSocket Client和WebSocket Server ws://2abe356fc.bsclink.com/交互，输出正常；
（Safari浏览器输出内容）
2.浏览器请求流程图
以下是浏览器通过WebSocket协议向服务器请求的流程：
（浏览器请求流程图）
二、问题分析
只有Chrome与Websocket Server间的通信发生异常，判断ERROR很可能是由Chrome浏览器问题导致的，基于此来分析问题产生的具体原因。通过浏览器控制台查看报错相关信息
如上图下方所示，WebSocket协议decode a text frame在转化为uft-8编码时失败。
由于WebSocket Server向Client返回数据时，使用text frame方式，于是我们开始排查WebSocket Server返回数据导致decode失败的原因。
打印WebSocket Server日志，查看返回内容
通过日志，观察到longloop传送给WebSocket Server的内容与WebSocket Server输出到Client的内容一致，均为乱码。基于此我们可以确定WebSocket Server不存在异常情况，于是我们需要确定longloop是否存在异常。通过longloop抓包查看backend返回内容
可以通过TCPDUMP抓包来判定longloop是否存在问题。
（backend返回到longloop的数据）
（longloop返回到WebSocket Server的数据）
通过对比以上两组数据，可以得出如下结论：
经过longloop后，真实返回给Client的数据并未发生变化。
（1） backend的返回数据被gzip压缩；
（2） 压缩的响应数据被发送至WebSocket Server；
（3） 最终由WebSocket Server发送到WebSocket客户端。
backend返回的数据为什么被压缩了？
首先，backend端必须开启gzip压缩，并支持对此返回的数据类型的gzip压缩，才能返回压缩后的响应数据；
其次，客户端要明确声明能接收gzip压缩的响应数据，backend端才能够返回gzip压缩过的数据。
经确认，backend server上的配置开启了gzip压缩功能，并对content-type为text/html的数据支持gzip压缩。
可以判断问题有可能出现在client环节：
Client没有要求返回压缩数据，但是backend端返回了压缩数据；
通过不同浏览器访问，返回不同数据，可以判定不是backend端的问题。
Client主动要求backend端返回被压缩的数据；
只有Chrome浏览器返回了gzip压缩数据，可以推断可能是因为Chrome请求backend端时，在request header中包含了可以接收gzip压缩数据的header，导致backend端返回了gzip压缩数据。
抓包对比Chrome和Safari请求头信息
Chrome相关信息：
1） Chrome浏览器请求ws.html静态文件的请求头中带有Accept-Encoding：
2）Chrome浏览器将ws.html加载到本地后，ws.html文件中的js WebSocket 客户端向WebSocket Server发送请求的请求头中带有Accept-Encoding：
3）Chrome浏览器的请求发送到longloop之后，longloop到backend的请求头中带有Accept-Encoding：
Safari相关信息
1）Safari浏览器请求ws.html静态文件的请求头中带有Accept-Encoding：
2）Safari浏览器将ws.html加载到本地后，ws.html文件中的js WebSocket 客户端向WebSocket Server发送请求的请求头中未带有Accept-Encoding：
3）Safari浏览器的请求发送到longloop之后，longloop到backend的请求头中未带有Accept-Encoding：
通过对比Chrome和Safari相关请求数据，我们可以判断出WebSocket Server返回数据不一致的原因如下：
Chrome，Safari浏览器发送请求时，为了提高网络传输效率、减少网络带宽占用，默认自带gzip压缩支持，两种浏览器加载ws.html时均无异常。但当js调用Chrome浏览器WebSocket 客户端向WebSocket Server端发送请求时，在请求头Accept-Encoding中添加了对gzip的支持，backend收到HTTP请求后，认为客户端能够对gzip压缩的响应数据进行解压缩，从而backend返回了gzip压缩过的响应数据，而WebSocket客户端接收到gzip压缩的数据后，不支持gzip数据解压缩，最终导致了decode出错。
而js调用Safari浏览器WebSocket客户端向WebSocket Server端发送请求时，请求头未带有Accept-Encoding，backend收到http请求后，不会返回被gzip压缩的响应数据，从而WebSocket客户端正常解析访问正常。
三、解决办法
为解决上述问题，我们需要在longloop这一层进行判断：如果user agent为Chrome浏览器，则需要去掉request header中的Accept-Encoding这个header，明确告知服务器端不接受gzip压缩过的数据，这样服务器端就不会返回gzip压缩过的数据，Chrome浏览器即可正常访问。
