Давайте посмотрим на этот сценарий.
В традиционной модели LB у нас будет LB (будь то обратный прокси-сервер или нет) отдает req/rep серверам уровня приложений. Эта модель подходит для общего стиля общения req/rep, но что происходит, когда у нас есть постоянные соединения?
Давайте посмотрим на пример HTTP/2.
Здесь у нас нет простой парадигмы Req/Rep, где я могу просто отправить запрос и сбалансировать нагрузку на этот запрос и получить ответ. Вся эта архитектура не имеет состояния (забудьте о липких сессиях, так как это имеет последствия, не относящиеся к этому примеру). Что происходит, у нас есть постоянное соединение, такое как с HTTP/2.
Я не могу подключить соединение HTTP/2 к LB, иначе этот LB будет очень быстро насыщаться, и все клиентские запросы, у которых еще нет сокета, связанного с этим LB, будут неудачными. Если они полагаются на DNS, чтобы указать на этот LB, возникает множество проблем, когда у нас заканчивается место в сокетах.
Нам нужно что-то, чтобы почти перенаправить первоначальный запрос SYN на другой сервер, который может быть другим LB или самим прикладным уровнем (забудьте о безопасности/внешних атаках).
Клиент отправляет запрос s1.com --> (отвечает на DNS и возвращает ip .123)
Затем клиент отправляет запрос на подключение HTTP/2 на .123 (это LB), но вместо подключения и передачи на прикладной уровень он отправляет ответ на «перенаправление .. аналогично 302 в HTTP» на ip .124 . IP .124 может быть другим типом LB или может быть самим прикладным уровнем, где фактический сокет привязан для связи HTTP/2.
Управление .123 и узлами, на которые он указывает, можно было бы контролировать с помощью различных инструментов, которые существуют в настоящее время, но с точки зрения этой «переадресации HTTP/2 для балансировки проблемы загрузки сокетов» я не смог найти решение .
Есть ли лучший способ справиться с этим (опять же, не для внутренних служб, а для внешних запросов) или существует прокси/служба/система, которая существует для решения этой проблемы?
DSR немного отличается тем, что решает проблему на другом уровне и действительно актуален, когда у вас много обратного трафика, но не решает проблему, если трафик двунаправленный (также не работает на многих облачных провайдерах). ). DSR имеет большое значение для потоковой передачи мультимедиа и интенсивного трафика ответов сервера.
Спасибо за любую информацию или помощь, которую вы можете предоставить по этой теме!
Как
