ARR 3を使用したTomcat 8 + IIS 8上のWebソケットは動作していません

Question

この問題が発生している可能性がありますが空の状態になった人を見つけるためにインターネットを調べました。したがって、ここに行きます：

私たちは、Java Webアプリケーション（Spring MVC 4に基づいています）を持っています。 Application Request Routing（ARR）v3を使用するロードバランサ/リバースプロキシとして機能するMicrosoft IISの背後に位置します。 dev.example.com、demo.example.comとqa.example.com：

このIISは、3つの異なる環境（同じ Javaコードを実行しているすべての）のためのARRと負荷分散を行っています。

アプリケーションがSockJSとstompjs経由でのWebSocketを使用してユーザーのブラウザに通知を提供し、アプリケーションサーバにTomcat 8にqa.example.com環境をアップグレードした後にTomcat 7の上にあったが、これはすべてが順調に取り組んできた、のWebSocket接続が動作を停止 - それはXHR POSTリクエストに戻ります。

IISに変更が加えられておらず、qaアプリケーションサーバーだけであることを強調したいと思います。壊れqa環境からのサンプル要求/応答（

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 

されています。ここでは

は（作業）dev環境からのサンプル要求/応答であります）：

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 

唯一の明らかな違いはdev応答がないながらqa応答がSec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15ヘッダを含むことがあります。

101レスポンスをデバッグするためにIISで「Failed Request Tracing」がオンになり、IISによって上書きされるヘッダーがいくつかあることがわかります。つまり、Sec-WebSocket-Acceptヘッダーです。

IISは、その要求が502.5エラーを生成していることも示しています。私はそれを見て、これを見つけた：502.5は "WebSocket failure（ARR）"であると言われているhttps://support.microsoft.com/en-us/kb/943891とそれはすべてです。奇妙なことに、Chrome Dev Toolsは、それがそうであるように101で応答することを示しています。

ローカルアプリケーションサーバー（IISなしのTomcat 8）でこれを試してみました。 Tomcat 7 + IIS + ARR + WebSocketは正常に動作します。 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はローカルサーバーでは小文字ですが、IISを前面に置くと、WebsocketとUpgradeとなります。

Sec-WebSocket-Extensionsもの後にqaに後続スペースがありますが、ローカルではありません。

アップデート2

それはすべて私は、Internet Explorer 11を試していないが、私はそれはおそらくも動作を前提とする必要がマイクロソフトエッジ（Windowsの10）にqa環境で正常に動作します。 FirefoxとOSXの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

私はそれがあった望むほど満足ではないが、私は、解決策を発見しました。私たちのプロジェクトのpom.xml我々はspring-core:4.2.5があったが、spring-websocketとspring-messagingが4.1.6たで

。バージョンのミスマッチがいくつかの問題をはっきりと引き起こしていました。

バージョンがの場合、-Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=trueをTomcat起動オプションに設定すると、は効果がありませんでした。バージョンがのときにJVMオプションを設定すると、同じが期待通りに機能しました。

101レスポンスにはpermessage-deflateが含まれておらず、WebソケットはIIS経由で問題なく接続できます。私たちのアプリケーションは、ソケットを介して大量のデータを送信しないので、このトレードオフはOKです。

Answer 2

ARR3を使用するTomcat7とIIS8で同じ問題が発生します。私たちはSpringライブラリを使用していません。

websocket-extensionが有効な場合、websocket接続が確立された後にフレームが送信されません。しかし、websocket-extensionsを無効にすると、すべてが完全に機能します。