Вопросы Теги

Следует ли отключить proxy_buffering в NGINX для поддержки потоковой передачи SockJS XHR?

У меня есть "одностраничное" веб-приложение, которое требует двунаправленной связи между клиентом и сервером.

Приложение было изначально разработано для полагаются на WebSockets, но были изменены для использования SockJS с отключенной поддержкой WebSocket.

Клиенты, использующие библиотеку SockJS, обычно используют «XHR Streaming» как средство двусторонней связи.

Сервер является Веб-приложение Java, использующее Spring ' s реализация сервера SockJS (из модуля Spring WebSocket), размещенного в Tomcat.

NGINX используется в качестве обратного прокси-сервера для Tomcat.

Конфигурация NGINX по умолчанию для proxy_buffering включена .

Документация NGINX неадекватно объясняет поведение буфера: не очевидно, при каких обстоятельствах буфер будет очищен (т.е. когда данные будут фактически отправлены клиенту), если данные передаются (от Tomcat) через долгоживущее HTTP-соединение.

По моим наблюдениям, данные, отправленные с сервера (ответ на запрос клиента), могут находиться в буфере NGINX до тех пор, пока для этого клиента не произойдет следующий сгенерированный сервером SockJS пульс. Результатом этого является задержка в 25 секунд передачи ответа клиенту!

Я могу очень надежно воспроизвести эту проблему путем экспериментов - поведение детерминировано, но я не могу объяснить взаимосвязь между настроенным размером (ами) буфера, размером передаваемых данных и поведением NGINX.

Мой ответственность сервера - генерировать ответы на вызовы команд клиентов; каждый ответ будет различаться по размеру (от нескольких байтов до десятков килобайт), но самодостаточен.

Основная цель - уменьшить задержку ответов на клиентские команды.

NGINX видит только долгоживущие HTTP-поток; разделение содержимого потока на отдельные ответы на команды (для немедленной отправки) потребует от NGINX понимания проприетарного протокола SockJS, чего он не может.

Таким образом, я считаю, что политика буферизации NGINX принципиально несовместима с моим вариантом использования, и планируем отключить proxy_buffering ; это разумно?

В документации NGINX предполагается, что если proxy_buffering отключен, вышестоящий сервер (Tomcat) будет вынужден держать HTTP-ответ открытым до тех пор, пока все данные не будут получены клиентом ( что кажется разумным определением буферизации!).

Соответственно, документация NGINX не рекомендует отключать proxy_buffering , поскольку это потенциально приведет к потере ресурсов восходящего сервера.

Однако, поскольку мои клиенты используют XHR Streaming, мой сервер уже обязан держать HTTP-соединение открытым для каждого активного клиента (верно?). Таким образом, отключение proxy_buffering не должно отрицательно сказаться на моем сервере Tomcat; Я установил плагин github-oauth jenkins ...

Я настраивал механизм аутентификации для нашей организации, jenkins, у которой не было механизма безопасности, «ананумос» может делать что угодно, удалять задания, строить и т. Д. Я установил

  1. плагин github-oauth jenkins

  2. в моем https: // github ..com / а. OAuthApplication -> создано новое приложение б. предоставили все подробности, главное было обратный вызов авторизации -> http://myserver.example.com:8080/securityRealm/finishLogin myserver.example.com = my jenkin server

  3. Хорошо

  4. Он создал, «ClientId» и «Client secret» -> Записано

  5. Перейдите в Jenkins и настройте «Global security: как указано здесь

Когда я нажал «Сохранить» в конфигурации безопасности Jenkin, Это вызвало большую страшную ошибку

STDERR: hudson.security.AccessDeniedException2: у анонимного отсутствует разрешение Общее / Администрирование в hudson.security.ACL.checkPermission (ACL.java:57)

, а затем, когда я щелкнул домашнюю страницу jekins, он попытался перенаправить меня на мой org github, но потерпел неудачу с "404"

Выход в "Ответе" "section

1
задан 12 July 2016 в 21:23
1 ответ

На основе Jenkins: Доступ запрещен после включения глобальной безопасности. Как вернуться назад? :

Поскольку в описанной выше проблеме они не использовали плагин Github Auth, в моем Jenkins config.xml были другие теги, вот что я сделал:

  1. на моем сервере Jenkins, JENKIN_HOME / config.xml

  2. Сначала под , установите true для ниже 

     AuthenticatedUserReadPermission
useRepositoryPermissions
AuthenticatedUserCreateJobPermission
allowAnonymousReadPermission
allowAnonymousJobStatusPermission

  3. Тогда я, по крайней мере, мог просматривать вакансии Jenkins как «анонимный» пользователь

  4. Затем я создал новый Auth в GitHub моей организации -> Мой профиль -> настройка -> «Приложение OAuth» -> Приложение для разработчиков и предоставил аналогичный вклад, в основном URL обратного вызова авторизации: http: // myjenkinsserver: 8080 / securityRealm / finishLogin

  5. Сгенерирован новый идентификатор клиента и секрет

  6. Изменен jekins config.xml
  7. перезапущен jenkins

  8. на этот раз попытался войти в систему Jenkins он перенаправлен в мою организацию GitHub и спрашивает, что Дженкинс хочет использовать аутентификацию, я "согласен", но получил новую ошибку 

     org.kohsuke.github.HttpException: сервер вернул код ответа HTTP: -1, сообщение: 'null' для URL:  https://ghe.acme.com/api/v3/user

  9. Обнаружено, что этот API неверен,

  10. Изменен jenkins config.xml 

      https: // github.  .com / api / v3

и на этот раз сработало :)

1
ответ дан 3 December 2019 в 23:43

Теги

Похожие вопросы