Websockets на Tomcat 8 + IIS 8 с ARR 3 не работают

Я искал интернет, пытаясь найти любого, кто может столкнуться с этой проблемой, но придет с пустыми руками. Итак, вот:

У нас есть веб-приложение java (на основе Spring MVC 4). Он находится за Microsoft IIS, выступая в качестве балансировщика нагрузки/обратного прокси-сервера, используя маршрутизацию запросов приложений (ARR) v3.

Этот IIS выполняет балансировку нагрузки с помощью ARR для трех разных сред (все работают с тем же 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 (рабочий):

Вот пример запроса/ответа из среды qa (сломан):

Единственное очевидное отличие состоит в том, что ответ 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):

Он очень похож на сломанный запрос qa, но он отлично работает. Поэтому я думаю, что вещь Sec-WebSocket-Extensions была красной селедкой. Кроме того, Upgrade: websocket и Connection: upgrade являются строчными буквами на моем локальном сервере, тогда как Websocket и Upgrade, когда вы ставите IIS спереди.

Sec-WebSocket-Extensions также имеет конечное пространство в qa после permessage-deflate;, но локальное не имеет.

Обновление 2

Все работает отлично в среде qa в Microsoft Edge (Windows 10). Я не пробовал Internet Explorer 11, но я должен предположить, что он, вероятно, также работает. Firefox и Chrome на OSX не работают.

Обновление 3

Запрос от Tomcat до того, как он будет изменен IIS/ARR:

Ответы

Ответ 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, и веб-узлы могут подключаться без проблем через IIS. Наше приложение не отправляет много данных через сокеты, поэтому мы были в порядке, делая этот компромисс.

Ответ 2

То же самое касается Tomcat7 и IIS8 с использованием ARR3. Мы не используем библиотеки Spring.

Никакие фреймы не отправляются после того, как установлено соединение с веб-сервером, если включены расширения websocket. Но если мы отключили расширение websocket, все работает отлично.