Можно ли использовать nginx в качестве обратного прокси-сервера для сервера бэкэнд-сервера?

Мы работаем над приложением Ruby on Rails, которое должно использовать веб-узлы html5. На данный момент у нас есть два отдельных "сервера", так сказать: наше основное приложение, работающее на nginx + пассажире, и отдельный сервер с использованием Pratik Naik Cramp (который работает на Thin) для обработки соединений в веб-каталоге.

В идеале, когда придет время для развертывания, у нас будет приложение rails, работающее на nginx + пассажире, и сервер websocket будет проксимироваться за nginx, поэтому нам не нужно будет запускать сервер websocket на другом порт.

Проблема в том, что в этой настройке кажется, что nginx слишком рано закрывает соединения с Thin. Соединение успешно установлено на тонком сервере, а затем сразу же закрывается кодом ответа 200. Наша догадка заключается в том, что nginx не понимает, что клиент пытается установить долговременное соединение для трафика websocket.

По общему признанию, я не настолько разбираюсь в настройке nginx, так что даже можно ли настроить nginx как обратный прокси-сервер для сервера websocket? Или мне нужно ждать, пока nginx предложит поддержку нового материала для рукопожатия для веб-рассылки? Предполагая, что наличие сервера приложений и сервера websocket, прослушивающих порт 80, является требованием, может это означать, что я должен иметь Thin, работающий на отдельном сервере без nginx спереди?

Заранее благодарим за любые советы или предложения.:)

-Джон

Ответ 1

~~Вы не можете использовать nginx для этого в настоящее время~~ ^{[it not true больше]} но я бы предложил посмотреть на 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

Ответ 2

Как насчет использования моего модуля nginx_tcp_proxy_module?

Этот модуль предназначен для общего прокси-сервера TCP с Nginx. Я думаю, что он также подходит для websocket. И я просто добавляю tcp_ssl_module в ветку разработки.

Ответ 3

nginx ( >= 1.3.13) теперь поддерживает обратные прокси-серверы.

# the upstream server doesn't need a prefix! 
# no need for wss:// or http:// because nginx will upgrade to http1.1 in the config below
upstream app_server {
    server localhost:3000;
}

server {
    # ...

    location / {
        proxy_pass http://app_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_redirect off;
    }
}

Ответ 4

Из коробки (то есть официальных источников) Nginx может устанавливать только HTTP 1.0-соединения с upstream (= backend), что означает, что keepalive не является возможным: Nginx будет выбирать восходящий сервер, открывать соединение с ним, прокси, кеш ( если вы хотите) и закройте соединение. Что это.

Это основная причина, по которой рамки, требующие постоянных соединений с бэкэнд, не будут работать через Nginx (нет HTTP/1.1 = no keepalive и никаких веб-ящиков, которые, как я полагаю). Несмотря на то, что этот недостаток является очевидным преимуществом: Nginx может выбирать из нескольких восходящих потоков (баланс нагрузки) и отказоустойчивости для живых, если некоторые из них не удались.

Изменить: Nginx поддерживает HTTP 1.1 для бэкэнд и keepalive с версии 1.1.4. Поддерживаются "fastcgi" и "proxy" вверх по течению. Здесь представлены документы

Ответ 5

Для тех, кто интересуется одной и той же проблемой, nginx официально поддерживает HTTP 1.1 вверх по течению. См. Документацию nginx для "keepalive" и "proxy_http_version 1.1".

Ответ 6

Как насчет Nginx с новым модулем HTTP Push: http://pushmodule.slact.net/. Он заботится о жонглировании соединения (так сказать), о котором, возможно, стоит беспокоиться с обратным прокси. Это, безусловно, жизнеспособная альтернатива веб-сокетам, которые еще не полностью включены в микс. Я знаю, что разработчик модуля HTTP Push все еще работает над полностью стабильной версией, но он активно развивается. Существуют версии, которые используются в производственных кодах. Процитировать автора: "Полезный инструмент с скучным именем".

Ответ 7

Я использую nginx для обратного прокси-сервера для сервера кометного стиля с длинными подключениями для опроса, и он отлично работает. Убедитесь, что вы настроили proxy_send_timeout и proxy_read_timeout соответствующие значения. Также убедитесь, что ваш серверный сервер, который nginx использует для проксирования, поддерживает http 1.0, потому что я не думаю, что модуль прокси-сервера nginx делает http 1.1 еще.

Просто, чтобы устранить некоторую путаницу в нескольких ответах: Keepalive позволяет клиенту повторно использовать соединение для отправки другого HTTP-запроса. Это не имеет никакого отношения к длительному опросу или открытию связей до тех пор, пока не произойдет какое-либо событие, о чем спрашивал первоначальный вопрос. Поэтому это не имеет значения, поскольку модуль прокси nginx поддерживает только HTTP 1.0, который не имеет keepalive.