码迷，mamicode.com
首页 > Web开发 > 详细

使用wireshark抓包分析浏览器无法建立WebSocket连接的问题(server为Alchemy WebSockets组件)

时间：2015-04-22 20:06:31      阅读：981      评论：0      收藏：0      [点我收藏+]

标签：

工作时使用了Websocket技术，在使用的过程中发现，浏览器(Chrome)升级后可能会导致Websocket不可用，更换浏览器后可以正常使用。

近日偶尔一次在本地调试，发现使用相同版本的Chrome浏览器，不可连接线上服务器的WS服务，但是可以连接本地的WS服务。 此时初步怀疑是服务器在某种特殊情况下会触发无法连接的问题。

 

使用Wireshark抓包

Filter：    ip.dst==serverIP or (ip.dst==本地IP and ip.src==serverIP)

一.查看可以正常连接线上服务的浏览器的网络请求(搜狗高速核)

技术分享

可以看到WebSocket连接建立的步骤：

1、先建立TCP连接，1~3条为tcp连接的三次握手

2、发出一个http请求，Header内容如下

技术分享 
GET /write?agentId=255 HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 10.134.71.235:2015
Origin: http://10.134.71.235
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: NddL4PEqgeUKIon0p+IHwQ==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 SE 2.X MetaSr 1.0
Cookie: ASP.NET_SessionId=kdparak1ecjplo4erozul2yl; _un=zouchengzhuo@sogou-inc.com; id=77.NRe6bXSRddXY6INl1HMkRAdn7L4yIt4wcTGYu43q9r4; un=zouchengzhuo@sogou-inc.com; pw=70467311a7ed8f62b58f8f1d65cdb408
websocket连接http请求header内容

服务器返回  

技术分享 
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: LDedYtTLpS6J7EygF4awEchi+D4=
websocket连接http请求返回

 

3.连接建立成功，使用WebSocket协议收发消息

技术分享

其中[FIN][MASKED] 为浏览器给server发消息

[FIN]为server给浏览器发消息，浏览器收到后发一个TCP的 [ACK] 包确认

 

正常的网络请求知道了，接下来服务器不变，更换浏览器

 

二、查看无法正常连接线上服务器的网络请求(Chrome)

技术分享

 

可以看到，HTTP请求发出去后，没有收到101的回复，服务器直接发起了TCP连接断开的流程。

怀疑是HTTP请求的内容不对。查看请求header

技术分享 
GET /write?agentId=255 HTTP/1.1
Host: 10.134.71.235:2015
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://10.134.71.235
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: ASP.NET_SessionId=1rfwnghibfq2jvvjrlbflvl0; _un=zouchengzhuo@sogou-inc.com; id=77.NRe6bXSRddXY6INl1HMkRAdn7L4yIt4wcTGYu43q9r4; un=zouchengzhuo@sogou-inc.com; pw=IsQky+6I5U5zM89pna9UNNirBD9v74G5799FdJvrK78aLTw0mvq5icQJpNlCweeHTl646j88InE03ayWm4PpcA==
Sec-WebSocket-Key: kcEwLRS2BowYzsoYxGCQNw==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
View Code

和搜狗的包对比，好像没有任何问题，接下来浏览器不变，更换服务器

三、查看可以正常连接的本地服务器的网络请求(Chrome)

连接建立过程正常，就不用截图了，主要关注HTTP请求header里边的内容

技术分享 
GET /write?agentId=255 HTTP/1.1
Host: 10.129.157.168:2015
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin:http://localhost:8317
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Sec-WebSocket-Key: ldwAY7BvJ6c0Gt9Xbh/R/Q==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
View Code

分析原因

分析发现，这个header里边没有cookie的数据，推测有可能是http请求里边的cookie导致连接断开。

chrome

这里就发现了第一个奇怪的问题，Chrome为什么有的时候会发送cookie，有的时候不会呢？   

经过多次调试发现：

1.关闭浏览器并重启的第一次，使用m.venus.sogou-inc.com访问，是可以正常使用的

2.无论何时，通过IP直接访问服务器都无法连接

3.只要用IP访问过，用域名访问也无法正常连接了

分析Cookie

用域名访问时的Cookie

技术分享

用IP访问时的Cookie

技术分享

公司对m.venus.sogou-inc.com的解析是经过了代理服务器的，目前OP的nginx还不能转发ws协议的请求

所以浏览器创建Websocket的方式 是  new WebSocket(‘ws://ip:port‘) 而不是 new WebSocket(‘ws://hostname:port‘)

重启浏览器，用域名访问的时候，header中

Host: 10.134.71.235:2015
Origin: http://m.venus.sogou-inc.com

这是一个跨域的http请求，所以请求中默认是不会带上cookie的，chrome对在ws协议中的http请求中，显然也是应用的这个默认设置。

用IP访问的时候

Host: 10.134.71.235:2015
Origin: http://10.134.71.235

这是一个同域的请求，所以会带上cookie。 第二个问题得到了解释

一旦用ip访问过，在此ip下就种下cookie了，而即使是在域名访问的情况下，ws协议发出的http请求的host也是ip:port，所以也会发送ip下的cookie。

可以看到cookies的生命周期都是session级别的，所以重启浏览器后再用域名访问是可以的

第一、三个问题得到了解释

 

但是，搜狗浏览器的请求里边也包含了Cookie，为何搜狗却可以正常连接服务器呢？

搜狗高速核

 

用搜狗高速核多次试验，发现：

1.搜狗高速核的cookie数据中没有发送sessionid

2.搜狗浏览器不管任何时候，都会发送cookie

 技术分享

用域名访问的cookie：

技术分享

用IP访问的cookie：

技术分享

 

通过对比cookie的值发现，发送的cookie是ip域下的cookie。

那么这里有两个没办法解释的问题

1.为什么带有httponly属性的cookie，搜狗浏览器在发送请求的时候不会发出去

2.为何关掉所有搜狗浏览器的进程后，生命周期为session的cookie没有被干掉

这是不是搜狗浏览器的两个BUG呢？

 

到此时基本可以确定，就是因为cookie中带了sessionid导致服务器主动断开连接。

 

云平台的Websocket服务器是用Alchemy Websockets开发的。按照正常的逻辑，WebSocket服务器中不应该用session去判断用户身份，因为它和Http不属于同一个会话。

现在怀疑是因为Alchemy WebSockets组件的BUG导致此问题。

调试Alchemy WebSockets源码

首先在本地IIS中发布一个云平台服务器，然后在VS中开启一个调试的服务，通过IP登录一下本地的云平台，然后通过localhost:调试端口 访问调试的服务，以模拟ws连接的http请求中带上cookie的情况。

从连接开始阶段打上断点单步调试，到Handshake.cs类的时候发现一个方法：

 

技术分享 
        public bool IsValid()
        {
            return (
                       (Host != null) &&
                       (Key != null) &&
                       (Int32.Parse(Version) >= 8)
                   );
        }
View Code

 

在正常情况下此方法返回true，请求中带上cookie且含有sessionId后返回false。原因是key==null。

抓包得到的header：

GET /write?agentId=261 HTTP/1.1
Host: 10.129.157.168:2015
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost:8317
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: ASP.NET_SessionId=5qmgzihkxtvntxirmekbm2tv; _un=zouchengzhuo@sogou-inc.com; id=77.NRe6bXSRddXY6INl1HMkRAdn7L4yIt4wcTGYu43q9r4; un=zouchengzhuo@sogou-inc.com; pw=RGPCwqEawjg9JXHVZ/rLzM4Ac1+nDHlL2y1kKYp6PVLkZ5o/Oj5/OsP8t8vsg3D+djE3x0Q7zH/7ggw2Jme63A==
Sec-WebSocket-Key: TLjHvbrhmKqEK3sNPu7bnA==
Sec-WebSocket-Extensions: permessage-deflate; client_max_windo

 

可以看到Sec-Websocket-Key 是存在的。

调试进入分析处理header的类里边，发现收到的header字符串为

技术分享 
GET /write?agentId=261 HTTP/1.1
Host: 10.129.157.168:2015
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost:8317
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: ASP.NET_SessionId=5qmgzihkxtvntxirmekbm2tv; _un=zouchengzhuo@sogou-inc.com; id=77.NRe6bXSRddXY6INl1HMkRAdn7L4yIt4wcTGYu43q9r4; un=
View Code

 

发现header少了一段。继续分析这个组件的代码，发现

 

Handler.cs 中：

技术分享

TCPServer中：

技术分享

默认只读取了512字节的数据，把这里改为一个足够大的大小来测试一下，就没问题了。

至此问题的原因找到了，Alchemy WebSockets在处理ws连接第二步——发送http请求的时候，对http头的解析方法有问题，导致丢掉了关键性的数据，浏览器中生成的 Ses-Websocket-Key，以至于服务器认为这是个非法的连接请求，给干掉了。

将处理header的地方修改为读取所有数据再处理，就能解决这个问题。

 

但是调试过程中还是留下了两个疑问：

1.为什么带有httponly属性的cookie，搜狗浏览器在发送请求的时候不会发出去

2.为何关掉所有搜狗浏览器的进程后，生命周期为session的cookie没有被干掉

使用wireshark抓包分析浏览器无法建立WebSocket连接的问题(server为Alchemy WebSockets组件)

标签：

原文地址：http://www.cnblogs.com/tzyy/p/4432349.html
踩
(0)
赞
(0)
   
举报
评论 一句话评论（0）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！