Подключение: Обратный WebSocket-прокси

Обратный WebSocket-прокси позволяет пропускать весь WebSocket-трафик между пользователем и апстримом через сеть Qrator Labs. Подробнее читайте в статье Технологии: Обратный WebSocket-прокси.

Ниже описан необходимый порядок настройки подключения обратного WebSocket-прокси, а также информация по настройке лимитов и балансировки для этой услуги.

Порядок настройки

  1. Сконфигурируйте клиентскую часть своего приложения так, чтобы WebSocket-трафик направлялся на специально выделенный для этого порт.

    Qrator Labs использует один и тот же IP-адрес как для получения трафика по протоколам HTTP и HTTPS, так и для получения трафика по протоколу WebSocket. Для корректного анализа и защиты необходимо, чтобы эти два вида трафика приходили на этот IP-адрес на разные порты.

    Примечание

    Например, вы можете настроить своё приложение так, чтобы оно использовало порт 8080 для передачи WebSocket-трафика, оставив при этом обработку HTTP- и HTTPS-трафика на стандартных портах 80 и 443.

    Обратный WebSocket-прокси в ответ на любой HTTP-запрос, отличный от HTTP 101 Switching Protocols, возвращает ответ с кодом ошибки HTTP 400 Bad Request.

  2. Сообщите специалистам технической поддержки Qrator Labs IP-адреса и порты ваших апстримов, обрабатывающих WebSocket-трафик. Они могут не совпадать с IP-адресами и портами апстримов для обратного HTTP-прокси.

    При использовании нескольких апстримов одновременно будет задействована балансировка, см. раздел Балансировка.

  3. Если необходимо, сообщите специалистам технической поддержки Qrator Labs лимиты на количество одновременных подключений с одного IP-адреса. Подробнее об этом написано в разделе Лимиты.

  4. Настройте файервол (firewall) на апстримах так, чтобы был разрешен трафик только из доверенных сетей.

    Рекомендации по настройке файервола даны в соответствующем разделе статьи Подключение: Обратный HTTP-прокси. Обратите внимание, что в приведённых в нём скриптах необходимо заменить порты 80 и 443 на порты, на которых ваш апстрим принимает запросы по протоколу WebSocket.

Лимиты

Чтобы затруднить проведение DDoS-атак на апстримы вашего приложения, Qrator Labs ограничивает количество WebSocket-соединений, которые пользователи могут инициировать с одного IP-адреса. При исчерпании лимитов WebSockets-прокси будет отклонять новые попытки установить соединения до тех пор, пока какое-либо из ранее установленных соединений не будет закрыто.

Лимиты, используемые по умолчанию, подходят для большинства клиентов, но могут быть изменены при необходимости. Так, если ваше приложение должно обращаться одновременно ко многим WebSocket-ресурсам для одного пользователя, сообщите об этом специалистам технической поддержки, и они увеличат лимит соответствующим образом. Это позволит избежать ошибочных блокировок легитимного трафика.

Если вы планируете часто делать запросы к ресурсу с некоторых заранее известных IP-адресов, сообщите эти IP-адреса технической поддержки для добавления в белый список. На запросы из этого списка будут действовать увеличенные лимиты.

Примечание

Часто клиенты добавляют в белый список сети своих офисов, например, чтобы частое тестирование ресурса со стороны клиента не распознавалось обратным прокси как превышение лимита.

Балансировка

При работе с несколькими апстримами обратный WebSocket-прокси распределяет пользователей между ними, используя алгоритм IP hash. Этот алгоритм выбирает апстрим в зависимости от IP-адреса запроса, при этом повторные соединения с того же IP-адреса устанавливаются с тем же апстримом. На практике это означает, что все соединения, инициируемые одним пользователем, с высокой вероятностью будут проксированы до одного и того же апстрима — что выгодно, в частности, для более эффективного использования кэша на каждом сервере.

Если при попытке установить соединение апстрим не отвечает на запрос в течение 5 секунд, то обратный прокси пытается установить соединение со следующим апстримом по списку. Порядок апстримов в списке может быть изменён по обращению в техническую поддержку.

Ответ со статусом HTTP 400 Bad Request, сигнализирующий о невозможности установить соединение, будет отправлен пользователю только после того, как неудачей завершатся попытки установить соединение с каждым апстримом по очереди.

expand_less