使用arr3的Tomcat 8 + iis8上的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:

我在互聯網上搜索,試圖找到任何可能正經歷這個問題但空手而來的人。這里是:

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.

我們有一個java web應用程序(基於Spring MVC 4),它位於Microsoft IIS后面,充當負載均衡器/反向代理,使用應用程序請求路由(ARR) v3。

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.

本IIS使用ARR在3個不同的環境(都運行相同的Java代碼)執行負載平衡:dev.example.com、demo.example.com和qa.example.com。

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.

該應用程序通過SockJS和stompjs使用WebSockets向用戶的瀏覽器提供通知,當應用服務器在Tomcat 7上時,這一切都運行得很好。在將qa.example.com環境升級到Tomcat 8之后,WebSocket連接就停止工作了——它回到了XHR POST請求。

I want to stress that no changes were made to IIS, just the qa application server.

我想強調的是,IIS沒有做任何更改,只有qa應用服務器。

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

Response

響應

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

Here is a sample request/response from the qa environment (broken):

以下是來自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

Response:

回應:

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

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.

惟一明顯的區別是,qa響應包含一個Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15頭,而dev響應沒有。

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上的“失敗請求跟蹤”來調試101個響應,我可以看到IIS覆蓋了一些頭文件——secl - websocket - accept頭文件。

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...

IIS還顯示該請求正在創建一個502.5錯誤。我查了一下,發現了這個:https://support.microsoft.com/en-us/kb/943891,上面說502.5是“WebSocket failure (ARR)”,就是這個意思。奇怪的是,Chrome開發工具顯示它的響應是101,就像它應該的那樣……

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.

我在本地應用服務器(沒有IIS的Tomcat 8)上嘗試了這一切,websockets運行得很好。Tomcat 7 + IIS + ARR + WebSockets很好。Tomcat 8 + IIS + ARR + WebSockets沒有。

My exact version of Tomcat 8 is 8.0.28 - but I got the same results on Tomcat 8.0.26.

我的Tomcat 8的確切版本是8.0.28,但是我在Tomcat 8.0.26上得到了相同的結果。

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.

我的下一步是通過小版本降低Tomcat 8的級別,看看是否有什么變化。如果我發現什么,我會在這里更新。

Update

Here's a response from my local server (no IIS):

以下是我的本地服務器(沒有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

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.

它看起來很像壞掉的qa請求,但是它工作得很好。所以我認為secweb socket擴展是一個轉移注意力的東西。另外,升級:websocket和Connection:升級在我的本地服務器上是小寫的,而當你把IIS放在前面時,升級就是websocket和升級。

Sec-WebSocket-Extensions also has a trailing space in qa after the permessage-deflate; but the local does not.

secl - websocket - extensions在發布消息之后,qa中也有一個尾隨空間;但當地人卻沒有。

Update 2

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.

它在Microsoft Edge (Windows 10)的qa環境中運行良好,我還沒有嘗試過Internet Explorer 11,但我不得不假設它可能也運行良好。OSX上的Firefox和Chrome不工作。

Update 3

Request from Tomcat before it gets modified by IIS/ARR:

在Tomcat被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

2 个解决方案

#1


2  

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.

在我們項目的pom。我們有spring-core:4.2.5,但是spring-websocket和spring-messaging是4.1.6。版本不匹配顯然導致了一些問題。

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.

設置-Dorg.apache.tomcat.websocket。當版本不匹配時,Tomcat啟動選項中的DISABLE_BUILTIN_EXTENSIONS=true沒有效果。在版本與預期相同時設置JVM選項。

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.

101響應現在不包含permessage-deflate, websockets可以通過IIS連接任何問題。我們的應用程序沒有通過套接字發送大量數據,所以我們可以做這個權衡。

#2


2  

The same problem on Tomcat7 and IIS8 using ARR3. We are not using Spring libraries.

用ARR3表示Tomcat7和IIS8也是同樣的問題。我們不使用Spring庫。

No frames are sent after the websocket connection is established if websocket-extensiones are enabled. But if we disabled websocket-extensions then all works perfectly.

如果啟用了websocket-extensiones,則在建立websocket連接之后不會發送幀。但是,如果我們禁用了websocket擴展,那么所有的功能都很好。


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2015/10/22/c9c3cfeb1e6280f4c80c602ae1dcbdd6.html



 
  © 2014-2022 ITdaan.com 联系我们: