Use Wireshark to capture the problem that the browser cannot establish a WebSocket connection (server is Alchemy WebSockets component)

Working with WebSocket technology, the use of the process found that the browser (Chrome) after the upgrade may cause the WebSocket is not available, the browser can be changed after the normal use.

Once in a while, it is occasionally possible to debug locally, discovering that using the same version of the Chrome browser does not connect to the WS service on the online server, but can connect to the local WS service. The initial suspicion is that the server will trigger an unreachable problem in some special case.

Use Wireshark to grab a bag

Filter:ip.dst==serverip or (ip.dst== local IP and Ip.src==serverip)

I. View network requests for browsers that can connect to online services ( Sogou high-speed core )

You can see the steps to establish the WebSocket connection:

1, first establish the TCP connection, the three-bar is the TCP connection three times handshake

2, send an HTTP request, the header content is as follows

get/write?agentid=255 http/1.1upgrade:websocketconnection:upgradehost:10.134.71.235:2015origin:http:// 10.134.71.235pragma:no-cachecache-control:no-cachesec-websocket-key:nddl4peqgeukion0p+ihwq== Sec-websocket-version:13sec-websocket-extensions:permessage-deflate; Client_max_window_bits, x-webkit-deflate-frameuser-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.0cookie:asp.net_session Id=kdparak1ecjplo4erozul2yl; [Email protected]; ID=77.NRE6BXSRDDXY6INL1HMKRADN7L4YIT4WCTGYU43Q9R4; [Email protected]; pw=70467311a7ed8f62b58f8f1d65cdb408

WebSocket connecting HTTP request Header content

Server returns

http/1.1 101 Switching protocolsupgrade:websocketconnection:upgradesec-websocket-accept:ldedyttlps6j7eygf4awechi+ d4=

WebSocket Connection HTTP request returned

3. Connection established successfully, send and receive messages using WebSocket protocol

where [fin][masked] sends a message to the server for the browser

[FIN] sends a message to the browser for the server, and the browser receives a TCP [ACK] packet Acknowledgement

Normal network requests know, then the server does not change, change the browser

II. viewing network requests that do not connect to the online server (Chrome)

As you can see, after the HTTP request is sent out, there is no 101 reply and the server directly initiates the process of the TCP disconnection.

The content of the HTTP request is suspected to be incorrect. View Request Header

get/write?agentid=255 Http/1.1host:10.134.71.235:2015connection:upgradepragma:no-cachecache-control: no-cacheupgrade:websocketorigin:http://10.134.71.235sec-websocket-version:13user-agent:mozilla/5.0 (Windows NT 6.1; WOW64) applewebkit/537.36 (khtml, like Gecko) chrome/41.0.2272.118 safari/537.36accept-encoding:gzip, deflate, sdchaccept-language:zh-cn,zh;q=0.8,en;q=0.6cookie:asp.net_sessionid=1rfwnghibfq2jvvjrlbflvl0; [Email protected]; ID=77.NRE6BXSRDDXY6INL1HMKRADN7L4YIT4WCTGYU43Q9R4; [Email protected]; Pw=isqky+6i5u5zm89pna9unnirbd9v74g5799fdjvrk78altw0mvq5icqjpnlcweehtl646j88ine03aywm4ppca==sec-websocket-key: Kcewlrs2bowyzsoyxgcqnw==sec-websocket-extensions:permessage-deflate; Client_max_window_bits

View Code

and Sogou bag contrast, as if there is no problem, next browser unchanged, replace the server

III. viewing network requests for local servers that can connect properly (Chrome)

Connection establishment process is normal, no need, focus on the HTTP request header inside the content

get/write?agentid=255 Http/1.1host:10.129.157.168:2015connection:upgradepragma:no-cachecache-control: no-cacheupgrade:websocketorigin:http://localhost:8317sec-websocket-version:13user-agent:mozilla/5.0 (Windows NT 6.1; WOW64) applewebkit/537.36 (khtml, like Gecko) chrome/41.0.2272.118 safari/537.36accept-encoding:gzip, deflate, Sdchaccept-language:zh-cn,zh;q=0.8,en;q=0.6sec-websocket-key:ldway7bvj6c0gt9xbh/r/q==sec-websocket-extensions: Permessage-deflate; Client_max_window_bits

View Code

Analysis Reason

The analysis found that there was no cookie data in the header, presumably because the cookie inside the HTTP request caused the connection to be broken.

Chrome

Here's the first strange question, why does chrome sometimes send cookies, sometimes not?

After several debugging discoveries:

1. Close the browser and restart the first time, using m.venus.sogou-inc.com access, is normal to use

2. No connection can be connected via IP direct access server at any time

3. As long as the IP access, with the domain name access also can not connect properly

Analyze cookies

Cookies when accessed with a domain name

Cookies that are accessed with IP

The company's analysis of the m.venus.sogou-inc.com is through the proxy server, the current OP Nginx can not forward the WS-Protocol request

So the way the browser creates WebSocket is the new WebSocket (' Ws://ip:port ') instead of the new WebSocket (' Ws://hostname:port ')

Restart the browser, use the domain name to access the time, the header

host:10.134.71.235:2015

Origin:http://m.venus.sogou-inc.com

This is a cross-domain HTTP request, so there is no cookie in the request, and Chrome is clearly the default setting for the application in the HTTP request in the WS-Protocol.

When using IP to access

host:10.134.71.235:

origin:http://10.134.71.235

This is a request from the same domain, so a cookie will be brought. The second question has been explained.

Once the IP is accessed, the cookie is planted under this IP, and even in the case of domain name access, the host of the HTTP request sent by the WS-Protocol is ip:port, so the cookie under IP is also sent.

You can see that the life cycle of cookies is session level, so it is possible to restart the browser and then access the domain name.

The first to third question has been explained.

However, Sogou browser request inside also contains a cookie, why Sogou can connect the server normally?

Sogou High-speed core

Using Sogou high-speed nuclear test repeatedly, found that:

1. Sogou high-speed core cookie data is not sent SessionID

2. Sogou browser will send a cookie at any time

Cookies accessed with a domain name:

Cookies that are accessed with IP:

By comparing the value of the cookie, the cookie that is sent is a cookie under the IP domain.

So here are two questions that can't be explained.

1. Why cookies with HttpOnly attribute, Sogou browser will not be sent out when sending the request

2. Why the cookie for the session is not killed when all the Sogou browser processes are turned off

This is not a Sogou browser two bug it?

At this point it is basically OK because the cookie with SessionID causes the server to be actively disconnected.

The WebSocket server for the cloud platform was developed with Alchemy WebSockets. According to normal logic, the WebSocket server should not use the session to determine the user identity, because it and HTTP are not part of the same session.

It is now suspected that the issue is caused by a bug in Alchemy websockets components.

Debug Alchemy WebSockets Source code

First publish a cloud platform server in local IIS, then start a debugging service in VS, log on to the local cloud platform via IP, and then access the debugged service through the localhost: Debug port to emulate the cookie in the HTTP request of the WS connection.

One step at a time from the beginning of the connection to a breakpoint, to the Handshake.cs class, find a method:

         Public BOOL IsValid ()        {            return  (                       null)&&                       null) && 8)                   );        }                         

View Code

Under normal circumstances This method returns true, with a cookie in the request and a return of false after containing SessionID. The reason is key==null.

Grab the header of the bag:

get/write?agentid=261 Http/1.1host:10.129.157.168:2015connection:upgradepragma:no-cachecache-control: no-cacheupgrade:websocketorigin:http://localhost:8317sec-websocket-version:13user-agent:mozilla/5.0 (Windows NT 6.1; WOW64) applewebkit/537.36 (khtml, like Gecko) chrome/41.0.2272.118 safari/537.36accept-encoding:gzip, deflate, SDCHACCEPT-LANGUAGE:ZH-CN,ZH;Q=0.8,EN;Q=0.6COOKIE:ASP.NET_SESSIONID=5QMGZIHKXTVNTXIRMEKBM2TV; [Email protected]; ID=77.NRE6BXSRDDXY6INL1HMKRADN7L4YIT4WCTGYU43Q9R4; [Email protected]; Pw=rgpcwqeawjg9jxhvz/rlzm4ac1+ndhll2y1kkyp6pvlkz5o/oj5/osp8t8vsg3d+dje3x0q7zh/7ggw2jme63a==sec-websocket-key: Tljhvbrhmkqek3snpu7bna==sec-websocket-extensions:permessage-deflate; Client_max_windo

You can see that the sec-websocket-key is there.

Debug into the analysis processing header class inside, found the received header string is

get/write?agentid=261 Http/1.1host:10.129.157.168:2015connection:upgradepragma:no-cachecache-control: no-cacheupgrade:websocketorigin:http://localhost:8317sec-websocket-version:13user-agent:mozilla/5.0 (Windows NT 6.1; WOW64) applewebkit/537.36 (khtml, like Gecko) chrome/41.0.2272.118 safari/537.36accept-encoding:gzip, deflate, SDCHACCEPT-LANGUAGE:ZH-CN,ZH;Q=0.8,EN;Q=0.6COOKIE:ASP.NET_SESSIONID=5QMGZIHKXTVNTXIRMEKBM2TV; [Email protected]; ID=77.NRE6BXSRDDXY6INL1HMKRADN7L4YIT4WCTGYU43Q9R4; un=

View Code

Found the header missing a paragraph. Continue to analyze the code of this component and discover

In Handler.cs:

In TCPServer:

The default is to read only 512 bytes of data, and change it to a large enough size to test it, no problem.

The reason for this problem has been found, Alchemy websockets in the second step of processing WS-Connection-when sending HTTP requests, the parsing method of the HTTP header is problematic, resulting in the loss of critical data, the Ses-websocket-key generated in the browser, That the server thought it was an illegal connection request and was killed.

This problem can be solved by modifying the location of the header to read all the data to be processed.

But two questions were left during the commissioning process:

1. Why cookies with HttpOnly attribute, Sogou browser will not be sent out when sending the request

2. Why the cookie for the session is not killed when all the Sogou browser processes are turned off

Use Wireshark to capture the problem that the browser cannot establish a WebSocket connection (server is Alchemy WebSockets component)