带有ARR 3的Tomcat 8 + IIS 8上的Websockets无法正常工作 [英] Websockets on Tomcat 8 + IIS 8 with ARR 3 are not working
问题描述
我在互联网上搜寻，试图找到任何可能遇到这个问题的人，但却空手而归。所以这里是：
I've scoured the internet trying to find anyone who might be experiencing this issue but come up empty handed. So here goes:
我们有一个java Web应用程序（基于Spring MVC 4）。它位于Microsoft IIS后面，充当使用应用程序请求路由（ARR）v3的负载均衡器/反向代理。
We have a java web application (based on Spring MVC 4). It sits behind Microsoft IIS acting as a load balancer / reverse proxy using Application Request Routing (ARR) v3.
此IIS正在为3种不同环境的ARR执行负载平衡（所有运行相同 Java代码）： dev.example.com ， demo.example.com 和 qa.example.com 。
This IIS is performing load balancing with ARR for 3 different environments (all running the same Java code): dev.example.com, demo.example.com and qa.example.com.
应用程序通过SockJS使用WebSockets向用户的浏览器提供通知，当应用程序服务器在Tomcat 7上时，stompjs一直运行良好。将 qa.example.com 环境升级到Tomcat 8后，WebSocket连接停止工作 - 它回到XHR POST请求。
The application serves notifications to users' browsers using WebSockets via SockJS and stompjs and this has all been working well while the application servers were on Tomcat 7. After upgrading the qa.example.com environment to Tomcat 8, the WebSocket connections stopped working - it falls back to XHR POST requests.
我想强调的是，没有对IIS进行任何更改，只有 qa 应用程序服务器。
I want to stress that no changes were made to IIS, just the qa application server.
以下是来自 dev 环境（工作）的示例请求/响应：
Here is a sample request/response from the dev environment (working):
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 环境（损坏）：
Here is a sample request/response from the qa environment (broken):
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 响应没有。
The only obvious difference is that the qa response includes a Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15 header while the dev response does not.
我在IIS上启用了失败请求跟踪以调试 101 响应，我可以看到有一些标题被IIS覆盖 - Sec-WebSocket-Accept 标题即。
I turned on "Failed Request Tracing" on IIS to debug the 101 response and I can see that there are some headers that get overwritten by IIS - the Sec-WebSocket-Accept header namely.
IIS也是表明该请求正在创建 502.5 错误。我查了一下，发现了这个： https://support.microsoft.com/en-us / kb / 943891 表示 502.5 是WebSocket失败（ARR），这就是它所说的。奇怪的是，Chrome开发工具显示它响应101就像它应该... ...
IIS also shows that that request is creating a 502.5 error. I looked that up and found this: https://support.microsoft.com/en-us/kb/943891 which says that 502.5 is "WebSocket failure (ARR)" and that's all it says. Weirdly enough though, Chrome Dev Tools shows that it responds with a 101 just like it's supposed to...
我尝试使用本地应用程序服务器（Tomcat 8 with没有IIS）和websockets工作得很好。 Tomcat 7 + IIS + ARR + WebSockets工作得很好。 Tomcat 8 + IIS + ARR + WebSockets没有。
I tried this all with a local application server (Tomcat 8 with no IIS) and the websockets worked just fine. Tomcat 7 + IIS + ARR + WebSockets works just fine. Tomcat 8 + IIS + ARR + WebSockets does not.
我确切的Tomcat 8版本是8.0.28 - 但我在Tomcat 8.0.26上得到了相同的结果。
My exact version of Tomcat 8 is 8.0.28 - but I got the same results on Tomcat 8.0.26.
我的下一步是继续通过次要版本降级Tomcat 8，看看是否有任何变化。如果我发现任何内容，我会在这里更新。
My next step it to keep downgrading Tomcat 8 through minor versions and see if anything changes. I will update here if I discover anything.
这是来自我本地服务器的响应（没有IIS ）：
Here's a response from my local server (no 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 的事情是红鲱鱼。此外升级：websocket 和连接：升级在我的本地服务器上是小写，而它是升级。
It looks a lot like the broken qa request, but it works great. So I guess the Sec-WebSocket-Extensions thing was a red herring. Also Upgrade: websocket and Connection: upgrade is lower case on my local server, whereas it is Websocket and Upgrade when you put IIS in front.
Sec-WebSocket-Extensions 在 permessage-deflate之后的但本地没有。 qa 中也有一个尾随空格;
Sec-WebSocket-Extensions also has a trailing space in qa after the permessage-deflate; but the local does not.
这一切都在<$ c上运行正常$ c> qa Microsoft Edge中的环境（Windows 10）我没有尝试过Internet Explorer 11，但我必须假设它可能也有效。 OSX上的Firefox和Chrome不起作用。
It all works fine on the qa environment in Microsoft Edge (Windows 10) I haven't tried Internet Explorer 11, but I have to assume it probably also works. Firefox and Chrome on OSX do not work.
来自Tomcat的请求在被IIS修改之前/ ARR：
Request from Tomcat before it gets modified by IIS/ARR:
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
推荐答案
我发现了解决方案，尽管它并不像我希望的那样令人满意。
I have discovered the solution, although it is not as satisfying as I wish it was.
在我们项目的 pom.xml 中我们有 spring-core：4.2.5 但是 spring-websocket 和 spring-messaging 4.1.6 。版本不匹配导致一些问题清楚。
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选项按预期工作。
Setting -Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=true in the Tomcat startup options when the versions were mismatched had no effect. Setting that JVM option when the versions were the same worked as expected.
101 响应现在不包含 permessage-deflate ，并且websockets能够通过IIS连接没有问题。我们的应用程序不会通过套接字发送大量数据，所以我们可以做出这种权衡。
The 101 response now does not contain permessage-deflate and websockets are able to connect with no issues through IIS. Our application does not send a lot of data through the sockets so we were OK making this tradeoff.
这篇关于带有ARR 3的Tomcat 8 + IIS 8上的Websockets无法正常工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
