Может ли дизайн API с высокой агрегацией разветвления приводить к истощению / превышению времени ожидания порта под нагрузкой для http / 1.1, и http / 2 решает это прозрачно?

Question

Если мы спроектируем API-интерфейс, в котором один входящий запрос приводит к 10 параллельным исходящим запросам к другому API-интерфейсу для агрегирования некоторых данных, то при высокой нагрузке эта конструкция может способствовать увеличению числа проблем из-за истощения портов / тайм-аутов?

Еще несколько фактов:

1. Предположим, что все apis являются REST over http
2. Предположим, что все apis находятся за своими собственными балансировщиками нагрузки / обратными прокси-серверами
3. Если это имеет значение,Предположим, что все apis находятся в .net с использованием HttpClient singleton на Windows Server 2016
4. Все apis имеют разумное время ожидания, например, 10 секунд

Я думаю, что да, так как каждое отдельное соединение будет уникальнымидентифицируется кортежем (source machine IP, source port, target load balancer ip, target load balancer port, TCP).Поэтому, если одно соединение уже существует, другому вызову придется ждать, пока предыдущее соединение на той же машине не освободится.Даже при повторном использовании соединения в http / 1.1 следующий запрос должен будет ждать ответа предыдущего (блокировка заголовка строки), что может привести к большим очередям и, следовательно, к превышению времени ожидания при повышенной нагрузке.

Теперь двавопросы:

1. Верно ли мое понимание предположений?
2. Решает ли http / 2 эту проблему прозрачным образом и делает ли этот API-интерфейс осуществимым для гораздо более высокой нагрузки?