История изменений

ваш браузер создаст 6 соединений и если среди них есть ощутимые по времени выполнения забьет ему половину пула(если сервер настоящий, а не однопотоковый)

Какого «пула»? Если мы отбросим новомодные приблуды плана «сервер, который только перебрасывает запросы на другой сервер», то в плане выполнения вычислений в ответ на запрос поток HTTP/2 не отличается от соединения HTTP/1.1, то есть, будут выделяться те же ресурсы после установленяи соединений. Если не используется TLS, то даже фактор стоимости TLS handshake-а перестает влиять, и тогда 6 потоков HTTP/2 по тяжести обработки не отличаются от 6 соединений HTTP/1.1. (и в том числе потому HTTP/2 без TLS многими реализациями просто не поддерживается)

Другое дело, что по RFC 7540 клиент и сервер должны поддерживать ОТ 100 потоков, а это уже другая весовая категория.

хттп2 создаст одно и будет эффективно со сжатием гонять через него все запросы

Во-первых, HTTP/2 жмет только заголовки, payload может быть любым и не входит в протокол HTTP. Во-вторых, сжатие заголовков HTTP/2 затрачивает время CPU в обмен на экономию полосы канала, это не бесплатная штука.

$ head -c 1G </dev/urandom | /usr/bin/time gzip >/dev/null
21.69user 0.19system 0:21.95elapsed 99%CPU (0avgtext+0avgdata 1904maxresident)k
$ head -c 1G </dev/urandom | /usr/bin/time lz4 -c >/dev/null
0.35user 0.65system 0:03.28elapsed 30%CPU (0avgtext+0avgdata 9756maxresident)k
$ head -c 1G </dev/urandom | /usr/bin/time cat >/dev/null
0.02user 0.40system 0:02.95elapsed 14%CPU (0avgtext+0avgdata 2100maxresident)k

По этой причине HTTP/2 может приводить к замедлению обработки на сервере по сравнению с нешифрованным и нежатым HTTP/1.1 даже при равенстве числа потоков.

вместо 10и потоков одного сервера будет 10 докер-инстансов по которым запросы распределять будет балансировщик. Ну я надеюсь, что смысл заключается именно в этом, а не «пиу-пиу, рякт-рякт, быстрый хомяк плохого не посоветует». Хотя правда скорее в том, что чем меньше ваше ПО переиспользует общие ресурсы, тем больше денжищь с вас будет сдирать облачный провайдер, поэтому наврать телепузикам, что так быстрее и надежнее экономически целесообразно.

Вот здесь я пытался понять, что ты пишешь, но не смог. Слова по отдельности ясны, предложения в целом — нет.

ваш браузер создаст 6 соединений и если среди них есть ощутимые по времени выполнения забьет ему половину пула(если сервер настоящий, а не однопотоковый)

Какого «пула»? Если мы отбросим новомодные приблуды плана «сервер, который только перебрасывает запросы на другой сервер», то в плане выполнения вычислений в ответ на запрос поток HTTP/2 не отличается от соединения HTTP/1.1, то есть, будут выделяться те же ресурсы после установленяи соединений. Если не используется TLS, то даже фактор стоимости handshake-а перестает влиять, и тогда 6 потоков HTTP/2 по тяжести обработки не отличаются от 6 соединений HTTP/1.1.

Другое дело, что по RFC 7540 клиент и сервер должны поддерживать ОТ 100 потоков, а это уже другая весовая категория.

хттп2 создаст одно и будет эффективно со сжатием гонять через него все запросы

Во-первых, HTTP/2 жмет только заголовки, payload может быть любым и не входит в протокол HTTP. Во-вторых, сжатие заголовков HTTP/2 затрачивает время CPU в обмен на экономию полосы канала, это не бесплатная штука.

$ head -c 1G </dev/urandom | /usr/bin/time gzip >/dev/null
21.69user 0.19system 0:21.95elapsed 99%CPU (0avgtext+0avgdata 1904maxresident)k
$ head -c 1G </dev/urandom | /usr/bin/time lz4 -c >/dev/null
0.35user 0.65system 0:03.28elapsed 30%CPU (0avgtext+0avgdata 9756maxresident)k
$ head -c 1G </dev/urandom | /usr/bin/time cat >/dev/null
0.02user 0.40system 0:02.95elapsed 14%CPU (0avgtext+0avgdata 2100maxresident)k

По этой причине HTTP/2 может приводить к замедлению обработки на сервере по сравнению с нешифрованным и нежатым HTTP/1.1 даже при равенстве числа потоков.

вместо 10и потоков одного сервера будет 10 докер-инстансов по которым запросы распределять будет балансировщик. Ну я надеюсь, что смысл заключается именно в этом, а не «пиу-пиу, рякт-рякт, быстрый хомяк плохого не посоветует». Хотя правда скорее в том, что чем меньше ваше ПО переиспользует общие ресурсы, тем больше денжищь с вас будет сдирать облачный провайдер, поэтому наврать телепузикам, что так быстрее и надежнее экономически целесообразно.

Вот здесь я пытался понять, что ты пишешь, но не смог. Слова по отдельности ясны, предложения в целом — нет.