с веб-сокетами и постоянными TCP-соединениями, как балансировщики нагрузки справятся с ограничением порта в 64 КБ, если они обрабатывают большую ферму серверов в бэкэнде? необходимость. некоторые идеи по настройке инфраструктуры для приложения, которое может. потенциально иметь 100k соединений.
Ваш вопрос, похоже, предполагает, что балансировщик нагрузки переводит SNAT (также известный как NAPT). Вот несколько идей по решению проблемы эфемерных портов 64k. Мой опыт связан с продуктом BIG-IP F5 Networks (так что ссылки ведут на их сайт), но концепции у других поставщиков такие же:
Не SNAT. Если исходные порты не переведены, ограничения в 64 КБ не будет. Чтобы отключить SNAT, вам необходимо установить внутренний адрес балансировщика нагрузки в качестве маршрута (обычно маршрута по умолчанию) на внутренних серверах.
Используйте пул SNAT. Это делает пул внутренних IP-адресов доступным для преобразования в балансировщик нагрузки. Например, два IP-адреса в пуле SNAT предоставят вам 128 КБ эфемерных портов, то есть 128 КБ одновременных TCP-соединений.
Более продвинутые подходы:
Я должен отметить, что веб-сокеты представляют собой особую проблему для традиционных балансировщиков нагрузки HTTP, поскольку соединения живут намного дольше - люди действительно сталкиваются с проблемой эфемерных портов, когда они, возможно, никогда не сталкивались с этим раньше. На мой взгляд, лучшее решение - это то, которое устраняет требование SNAT (первое или третье решение выше). Значительно улучшено масштабирование и снижена нагрузка на балансировщик нагрузки. Дополнительная сложность того стоит.
Вот хорошая статья по этому поводу от Лори МакВитти из F5: Веб-сокеты HTML5 меняют правила масштабируемости
Имейте в виду, что сокет - это кортеж из адресов sec / dst, портов src / dst и протокола, и поэтому количество перестановок намного превышает 64 КБ. Бывают ситуации, когда исходящие соединения на прокси-серверах могут иметь проблемы в зависимости от конкретных реализаций, но нумерация портов традиционно не была большой проблемой.
Я нашел больше всего подробный ответ на мой вопрос о StackOverflow.
Я знаю, что это старый вопрос, но у меня есть кое-что, что я могу добавить на случай, если кто-то еще погуглит "Балансировщик нагрузки WebSockets" ...
WebSockets не нужны балансировщики нагрузки. Вот, я это сказал. Причина в том, что браузеры не устанавливают исходящие соединения WebSocket до тех пор, пока после страница загрузилась.
Итак, если страница уже загружена, и у вас есть доступ для выполнения JavaScript, зачем вам в этот момент нужен балансировщик нагрузки? Ты бы не стал. Вы можете сделать что-то простое, например выбрать соединение ws: // или wss: // случайным образом из массива, или вы можете пофантазировать и сделать вызов AJAX, который возвращает конкретный сервер WebSocket для подключения. Вы даже можете поместить URL-адрес WebSocket на страницу из кода на стороне сервера через шаблон.
Масштабирование приложений WebSocket тривиально ... Просто добавьте больше серверов. Каждый раз, когда вы это делаете, просто добавляйте их в список исходящих подключений. Они могут быть расположены в любой точке мира - даже в разных доменах / странах происхождения!
WebSockets также не имеет ограничений на перекрестное происхождение обычных URL-адресов HTTP (S). Подключитесь к wss: //foo.com из http://bar.com. Будет работать нормально! Практически все традиционные проблемы, связанные с масштабированием веб-приложений, были решены с помощью WebSockets. Вы даже можете доставлять CSS, изображения, JavaScript и все остальное через WebSocket после того, как соединение установлено (и теперь кешируйте эти файлы локально в браузере!). Отказ от использования балансировщиков нагрузки и прочего вроде CDN.