Websockets trên Tomcat 8 + IIS 8 với ARR 3 không hoạt động

Question

Tôi đã lùng sục Internet cố gắng tìm bất kỳ ai có thể gặp phải vấn đề này nhưng lại đưa tay trắng ra. Vì vậy, ở đây đi:

Chúng tôi có một ứng dụng web java (dựa trên Spring MVC 4). Nó nằm phía sau Microsoft IIS hoạt động như một bộ cân bằng tải/proxy ngược sử dụng Application Request Routing (ARR) v3.

IIS này được thực hiện cân bằng tải với ARR trong 3 môi trường khác nhau (tất cả chạy mã cùng Java): dev.example.com, demo.example.com và qa.example.com.

Ứng dụng cung cấp thông báo cho trình duyệt của người dùng bằng cách sử dụng WebSockets thông qua SockJS và stompjs và tất cả đều hoạt động tốt trong khi máy chủ ứng dụng trên Tomcat 7. Sau khi nâng cấp môi trường qa.example.com lên Tomcat 8, kết nối WebSocket ngừng hoạt động - rơi trở lại yêu cầu XHR POST.

Tôi muốn nhấn mạnh rằng không có thay đổi nào được thực hiện đối với IIS, chỉ cần máy chủ ứng dụng qa.

Đây là một yêu cầu mẫu/phản hồi từ môi trường dev (làm việc):

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 

đáp ứng

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 

Dưới đây là một yêu cầu mẫu/phản hồi từ môi trường qa (chia):

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 

đáp ứng:

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 

Sự khác biệt rõ ràng duy nhất là phản ứng qa bao gồm một tiêu đề Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15 trong khi phản ứng dev không.

Tôi bật "Không yêu cầu truy tìm" trên IIS để gỡ lỗi phản hồi 101 và tôi có thể thấy rằng có một số tiêu đề bị ghi đè bởi IIS - tiêu đề Sec-WebSocket-Accept cụ thể.

IIS cũng cho thấy rằng yêu cầu đó đang tạo ra lỗi 502.5. Tôi nhìn lên và thấy điều này: https://support.microsoft.com/en-us/kb/943891 mà nói rằng 502.5 là "WebSocket thất bại (ARR)" và đó là tất cả nó nói. Mặc dù vậy, Chrome Dev Tools cho thấy rằng nó phản hồi với 101 giống như nó phải ...

Tôi đã thử tất cả với một máy chủ ứng dụng cục bộ (Tomcat 8 không có IIS) và các websockets hoạt động tốt. Tomcat 7 + IIS + ARR + WebSockets hoạt động tốt. Tomcat 8 + IIS + ARR + WebSockets thì không.

Phiên bản chính xác của Tomcat 8 là 8.0.28 - nhưng tôi nhận được kết quả tương tự trên Tomcat 8.0.26.

Bước tiếp theo của tôi là tiếp tục hạ cấp Tomcat 8 qua các phiên bản nhỏ và xem có thay đổi gì không. Tôi sẽ cập nhật ở đây nếu tôi khám phá bất cứ điều gì.

Cập nhật

Dưới đây là một phản hồi từ máy chủ địa phương của tôi (không 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 

Nó trông rất giống những chia qa yêu cầu, nhưng nó hoạt động tuyệt vời. Vì vậy, tôi đoán điều Sec-WebSocket-Extensions là một cá trích đỏ. Ngoài ra Upgrade: websocket và Connection: upgrade là trường hợp thấp hơn trên máy chủ cục bộ của tôi, trong khi đó là Websocket và Upgrade khi bạn đặt IIS ở phía trước.

Sec-WebSocket-Extensions cũng có dấu cách ở qa sau permessage-deflate; nhưng địa phương không có.

Cập nhật 2

Tất cả đều hoạt động tốt đối với môi trường qa trong Microsoft Edge (Windows 10) Tôi đã không cố gắng trình duyệt Internet Explorer 11, nhưng tôi phải thừa nhận nó có lẽ cũng làm việc. Firefox và Chrome trên OSX không hoạt động.

Cập nhật 3

Yêu cầu từ Tomcat trước khi nó được sửa đổi bởi 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 

Answer 1

tôi đã khám phá ra các giải pháp, mặc dù nó không phải là thỏa mãn như tôi muốn nó được.

Trong dự án của chúng tôi pom.xml chúng tôi có spring-core:4.2.5 nhưng spring-websocket và spring-messaging là 4.1.6. Phiên bản không phù hợp đã gây ra một số vấn đề rõ ràng.

Đặt -Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=true trong tùy chọn khởi động Tomcat khi các phiên bản là không khớp không có hiệu lực. Đặt tùy chọn JVM đó khi các phiên bản là cùng một hoạt động như mong đợi.

Phản hồi 101 hiện không chứa permessage-deflate và ổ cắm web có thể kết nối mà không gặp sự cố nào thông qua IIS. Ứng dụng của chúng tôi không gửi nhiều dữ liệu thông qua các ổ cắm để chúng tôi có thể thực hiện sự cân bằng này.

Answer 2

Cùng một vấn đề trên Tomcat7 và IIS8 bằng ARR3. Chúng tôi không sử dụng thư viện Spring.

Không có khung nào được gửi sau khi kết nối websocket được thiết lập nếu mở rộng websocket được bật. Nhưng nếu chúng ta vô hiệu hóa phần mở rộng websocket thì tất cả đều hoạt động hoàn hảo.