Tomcat 8 + IIS 8上带有ARR 3的Websockets无法正常工作

Question

我在互联网上搜寻,试图找到任何可能遇到这个问题的人,但却空手而归.所以这里:

我们有一个java Web应用程序(基于Spring MVC 4).它位于Microsoft IIS后面,充当使用应用程序请求路由(ARR)v3的负载平衡器/反向代理.

这种IIS正在执行与负载平衡ARR 3个不同的环境(所有运行的相同的Java代码): dev.example.com,demo.example.com和qa.example.com.

该应用程序通过SockJS和stompjs使用WebSockets向用户的浏览器提供通知,当应用程序服务器在Tomcat 7上时,这一切都运行良好.将qa.example.com环境升级到Tomcat 8后,WebSocket连接停止工作 - 它回退到XHR POST要求.

我想强调的是,IIS,只是qa应用程序服务器没有进行任何更改.

以下是来自dev环境(工作)的示例请求/响应:

Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cache-Control: no-cache
Connection: Upgrade
Cookie: <cookies snipped>
Host: dev.example.com
Origin: https://dev.example.com
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: E7aIek0X6qcO9PAl1n6w4Q==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

响应

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Connection: Upgrade
Date: Thu, 22 Oct 2015 02:19:35 GMT
Expires: 0
Pragma: no-cache
Sec-WebSocket-Accept: dKYK05s4eP87iA20aSo/3ntOrPU=
Server: Microsoft-IIS/8.0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Upgrade: Websocket
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Powered-By: ARR/3.0
X-XSS-Protection: 1; mode=block

以下是来自qa环境的示例请求/响应(已损坏):

Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cache-Control: no-cache
Connection: Upgrade
Cookie: <cookies snipped>
Host: qa.example.com
Origin: https://qa.example.com
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: jTOIAT0+o35+Qi0ZWh2gyQ==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

响应:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Connection: Upgrade
Date: Thu, 22 Oct 2015 02:18:30 GMT
Expires: 0
Pragma: no-cache
Sec-WebSocket-Accept: P+fEH8pvxcu3sEoO5fDizjSbwJc=
Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15
Server: Microsoft-IIS/8.0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Upgrade: Websocket
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Powered-By: ARR/3.0
X-XSS-Protection: 1; mode=block

唯一明显的区别是qa响应包括Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15标题而dev响应没有.

我打开IIS上的"失败的请求跟踪"来调试101响应,我可以看到有一些标题被IIS覆盖 - 即Sec-WebSocket-Accept标题.

IIS还显示该请求正在创建502.5错误.我查了一下,发现了这个:https://support.microsoft.com/en-us/kb/943891,这就是说502.5"WebSocket失败(ARR)",这就是它所说的.奇怪的是,Chrome开发工具显示它响应101就像它应该...

我尝试使用本地应用程序服务器(没有IIS的Tomcat 8)并且websockets工作得很好.Tomcat 7 + IIS + ARR + WebSockets工作得很好.Tomcat 8 + IIS + ARR + WebSockets没有.

我确切的Tomcat 8版本是8.0.28 - 但我在Tomcat 8.0.26上得到了相同的结果.

我的下一步是继续通过次要版本降级Tomcat 8,看看是否有任何变化.如果我发现任何事情,我会在这里更新.

更新

这是我本地服务器的响应(没有IIS):

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Connection: upgrade
Date: Thu, 22 Oct 2015 13:59:23 GMT
Expires: 0
Pragma: no-cache
Sec-WebSocket-Accept: 718HnPxHN8crYYzNGFjQf7w8O+Y=
Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Upgrade: websocket
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

它看起来很像破碎的qa请求,但效果很好.所以我猜这Sec-WebSocket-Extensions件事是红鲱鱼.也Upgrade: websocket和Connection: upgrade我的本地服务器上较低的情况下,而这是Websocket与Upgrade当你把IIS在前面.

Sec-WebSocket-Extensions也有尾随空间qa后,permessage-deflate;但当地没有.

更新2

这一切都适用qa于Microsoft Edge(Windows 10)中的环境我还没有尝试过Internet Explorer 11,但我必须假设它可能也有效.OSX上的Firefox和Chrome不起作用.

更新3

在IIS/ARR修改之前从Tomcat请求:

HTTP/1.1 101 Switching Protocols
Server: Apache-Coyote/1.1
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Accept: luP49lroNK9qTdaNNnSCLXnxAWc=
Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15
Date: Tue, 27 Oct 2015 21:10:48 GMT

Answer 1

I have discovered the solution, although it is not as satisfying as I wish it was.

In our project's pom.xml we had spring-core:4.2.5 but spring-websocket and spring-messaging were 4.1.6. The version mismatch was causing some issues clearly.

-Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=true当版本不匹配时，在 Tomcat 启动选项中设置无效。在版本与预期相同时设置该 JVM 选项。

该101反应现在不包含permessage-deflate和WebSockets的是能够通过IIS没有问题的连接。我们的应用程序不会通过套接字发送大量数据，因此我们可以进行这种权衡。