Я прочесываю интернет, пытаясь найти любого, кто может столкнуться с этой проблемой, но придет с пустыми руками. Так вот:Websockets on Tomcat 8 + IIS 8 с ARR 3 не работают
У нас есть веб-приложение java (на основе Spring MVC 4). Он находится за Microsoft IIS, выступая в качестве балансировщика нагрузки/обратного прокси-сервера, используя маршрутизацию запросов приложений (ARR) v3.
Этот IIS выполняет балансировки нагрузки с ARR на 3 различных средах (все работает на же Java-код): dev.example.com, demo.example.com и qa.example.com.
Приложение обслуживает уведомления для браузеров пользователей с помощью WebSockets через SockJS и stompjs, и все это хорошо работает, когда серверы приложений были на 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 Dev Tools показывает, что он отвечает 101, как будто он должен ...
Я пробовал все это с локальным сервером приложений (Tomcat 8 без IIS), и веб-порты работали нормально. Tomcat 7 + IIS + ARR + WebSockets работает отлично. У Tomcat 8 + IIS + ARR + WebSockets нет.
Моя точная версия Tomcat 8 - 8.0.28 - но я получил те же результаты на Tomcat 8.0.26.
Мой следующий шаг - сохранить понижение Tomcat 8 до незначительных версий и посмотреть, что-нибудь изменится. Я обновлю здесь, если что-нибудь обнаружу.
Update
Вот ответ от моего локального сервера (не 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;, но местное - нет.
Update 2
Это все прекрасно работает на qa среды в Microsoft Крае (Windows 10) Я не пробовал Internet Explorer 11, но я должен предположить, что это, вероятно, также работает. Firefox и Chrome на OSX не работают.
Update 3
Запрос от 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
Можете ли вы отключить сжатие на веб-сайтах для Tomcat? Sec-WebSocket-Extensions: permessage-deflate; предполагает, что он сжат, по моему опыту IIS не прокси-серверы сжали веб-узлы. –
@ timmah.faase Я дам ему снимок и отправлю отчет –
Итак, я попытался добавить эту опцию в мою конфигурацию Tomcat: '-Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS = true', которая должна была сделать трюк в соответствии с к документам: «Если true, отключите все встроенные расширения, предоставляемые сервером, такие как сжатие сообщений». Но он, похоже, не изменил заголовки ответов на всех –