nginx может использоваться в качестве обратного прокси для бэкенда websocket сервер?
Мы работаем над приложением Ruby on Rails, которое должно использовать в своих интересах html5 websockets. В данный момент у нас есть два отдельных "сервера" так сказать: наше главное приложение, работающее nginx+passenger, и отдельный сервер с помощью платформы Судороги Pratik Naik (который работает Тонкий) обработать websocket соединения.
Идеально, когда это прибывает время для развертывания, у нас было бы приложение для направляющих, работающее nginx+passenger, и websocket сервер будет проксирован позади nginx, таким образом, у нас не должно было бы быть websocket сервера, работающего на другом порте.
Проблема в этой установке, кажется, что nginx закрывает соединения для Утончения слишком рано. Соединение успешно устанавливается к Тонкому серверу, затем сразу согласился с 200 кодами ответа. Наше предположение - то, что nginx не понимает, что клиент пытается установить продолжительное соединение для websocket трафика.
По общему признанию я не весь, что здравый смысл с конфигурацией nginx, таким образом, даже возможно настроить nginx для действия как обратный прокси для websocket сервера? Или я должен ожидать nginx для предложения поддержки нового материала квитирования websocket? Предположение, что наличие и сервер приложений и websocket сервер, слушающий на порте 80, является требованием, которое могло бы означать, что у меня должна быть Тонкая работа отдельного сервера без nginx впереди на данный момент?
Заранее спасибо за любой совет или предложения.:)
- John
4 ответа
В настоящее время вы не можете использовать nginx для этого [это больше не так] , но Я бы посоветовал взглянуть на HAProxy. Я использовал его именно для этой цели.
Уловка состоит в том, чтобы установить длительные тайм-ауты, чтобы соединения сокетов не закрывались. Что-то вроде:
timeout client 86400000 # In the frontend
timeout server 86400000 # In the backend
Если вы хотите обслуживать, скажем, приложение rails и cramp на одном и том же порту, вы можете использовать правила ACL для обнаружения соединения с веб-сокетом и использовать другой бэкэнд. Итак, ваша конфигурация внешнего интерфейса haproxy будет выглядеть примерно так:
frontend all 0.0.0.0:80
timeout client 86400000
default_backend rails_backend
acl websocket hdr(Upgrade) -i WebSocket
use_backend cramp_backend if websocket
Для полноты бэкэнд будет выглядеть как
backend cramp_backend
timeout server 86400000
server cramp1 localhost:8090 maxconn 200 check
Из коробки (то есть из официальных источников) Nginx может устанавливать только HTTP 1.0-соединения с восходящим потоком (= серверной частью), что означает невозможность поддержки активности: Nginx выберет вышестоящий сервер, откроет к нему соединение, прокси, кеш (если хотите) и закроет соединение. Вот и все.
Это основная причина, по которой фреймворки, требующие постоянных подключений к бэкэнду, не работают через Nginx (нет HTTP / 1.1 = нет поддержки активности и нет веб-сокетов, я думаю). Несмотря на этот недостаток, есть очевидное преимущество: Nginx может выбирать из нескольких восходящих потоков (балансировка нагрузки) и переключаться на работающий в случае сбоя некоторых из них.
Правка : Nginx поддерживает HTTP 1.1 для бэкэндов и поддержки активности, начиная с версии 1.1.4. Поддерживаются восходящие потоки fastcgi и proxy. Вот документы
Как насчет Nginx с новым модулем HTTP Push: http://pushmodule.slact.net/. Он берет на себя заботу о жонглировании соединениями (так сказать), о котором можно было бы беспокоиться при использовании обратного прокси. Это, безусловно, жизнеспособная альтернатива Websockets, которые еще не до конца освоены. Я знаю, что разработчик модуля HTTP Push все еще работает над полностью стабильной версией, но он находится в активной разработке. Есть версии, которые используются в производственных кодовых базах. Цитируя автора, "Полезный инструмент со скучным названием"
.Я использую nginx для обратного проксирования на сервер в стиле comet с длинными соединениями для опроса, и он отлично работает. Убедитесь, что вы настроили proxy_send_timeout и proxy_read_timeout на соответствующие значения. Также убедитесь, что ваш внутренний сервер, на который проксирует nginx, поддерживает http 1.0, потому что я не думаю, что прокси-модуль nginx пока поддерживает http 1.1.
Просто чтобы прояснить некоторую путаницу в некоторых ответах: Keepalive позволяет клиенту повторно использовать соединение для отправки другого HTTP запроса. Оно не имеет ничего общего с длительным опросом или удержанием соединения открытым до наступления события, о чем и был задан первоначальный вопрос. Поэтому не имеет значения, что прокси-модуль nginx поддерживает только HTTP 1.0, который не имеет keepalive.