Балансировщики нагрузки на основе Http/2 с поддержкой внутреннего и внешнего интерфейса
Мы, как предприятие, хотим перейти на http/2 . Следующее - наша инфраструктура.
инфраструктура В настоящее время мы используем AWS ALB в качестве балансировщика нагрузки, поддерживаемого экземплярами EC2, на которых мы запускаем веб-сервер Apache. Веб-сервер Apache - это http-сервер, который затем подключается к сервлетному контейнеру tomcat через соединитель mod_jk. Веб-приложение есть в коте.
Мы включили http / 2 на веб-сервере apache, но проблема в том, что AWS ALB взаимодействует с http / 2 только с внешним интерфейсом, а не с внутренним. Я ознакомился с решениями, позволяющими решить эту проблему путем запуска AWS ALB в качестве балансировщика нагрузки уровня 4 (режим TCP или режим сквозного прохождения TCP). Ниже приводится одна из таких ссылок, в которой говорится об этом. С этим может быть несколько проблем, поскольку информация, передаваемая клиентом в формате http / 2, будет потеряна при преобразовании в TCP на балансировщике нагрузки, например, заголовок x-forwarded-for, который идентифицирует клиента. Кроме того, я полагаю (и, как в некоторых блогах), прилипание сеанса также приведет к броску, поскольку это также одна из функций, которая поддерживается только на уровне 7.
Вопрос заключается в том, как поддерживать http / 2 в AWS ALB во внешнем интерфейсе и бэкэнде, без ущерба для таких функций, как привязка к сеансу и идентификация клиента. Если нет AWS ALB, существуют ли другие балансировщики нагрузки, которые поддерживают сквозной http/2 .
Можно ли включить http / 2 только с внешним интерфейсом и иметь http/1.1 между AWS ALB и экземпляром бэкэнда (веб-сервером Apache). Мой вопрос заключается в том, что если бы у нас был включен http / 2 во внешнем интерфейсе, было бы мультиплексирование запросов через одно TCP-соединение между браузером и ALB, но было бы одно TCP-соединение на запрос между балансировщиком нагрузки и веб-сервером apache. и, следовательно, не будет действительно мультиплексирование запроса. Пожалуйста, поправьте меня, если мое понимание здесь не так.
Как показано на диаграмме инфраструктуры, мы также используем AWS Cloudfront в качестве CDN . Аналогичная проблема существует и с облачным фронтом. Облачный фронт AWS взаимодействует с клиентом по протоколу http / 2, а с бэкендом - по протоколу http/1.1 (здесь термин "сервер" относится к AWS ALB) . Каково состояние принудительной установки сервера на облачном фронте AWS? Категорически не упоминается в их документации. Push-сервер будет одной из функций, которую мы хотели бы использовать.