Как указывалось в сообщении в блоге, на которое вы ссылались (и подтверждалось, когда оно превратилось в официальный документ здесь ), IIS будет использовать протокол HTTP / 2 только тогда, когда установлено соединение TLS с сервером IIS.
Как реализовано сегодня в IIS 10, HTTP / 2 идентифицируется с помощью ALPN во время квитирования TLS. Если нет ни ALPN, ни TLS, не будет HTTP / 2. Посмотрите этот доклад BUILD 2015 года, начинающийся примерно с 5'06 ", и имейте в виду, что IIS не реализует механизм обновления HTTP / 1.1 (как указано в 8'46" в видео).
В вашем сценарии это почти наверняка тот случай, когда балансировщик нагрузки установит четкие TCP-соединения и отправит HTTP / 1.1 запросы на внутренние серверы. К тому времени, когда IIS даже может увидеть x-forwarded-proto
заголовок, соединение уже установлено и протокол HTTP / 1.1 уже определен.
Теперь, возможно, ваш балансировщик нагрузки может поддерживать сам HTTP / 2, поэтому браузеры ваших конечных пользователей смогут мультиплексировать запросы и ответы с балансировщиком нагрузки, в то время как он преобразует их в запросы HTTP / 1.1 и ответы на ваши внутренние серверы. ,
Также возможно, что ваш балансировщик нагрузки может устанавливать TLS-соединения с внутренними серверами и использовать HTTP / 2, но это в большинстве случаев будет препятствовать разгрузке SSL.