Приветствую!

Спасибо за ответ!

Но проблема несколько шире. Уже много фреймфорков написанных чисто на
http 2.0 (gRPC - и это только начало), которые не содержат большого
количества ненужного кода для поддержки http 1.1 просто потому что он
не нужен и смысла в нем минимум.

Отсутствие поддержки http2 со стороны бэкэнда в среде, где с клиентам
уже можно общаться по http2 будет тормомзом прогресса, потому что мы
не можем использовать везде http2 и исключительно из-за прихоти
реверс-прокси должны тыщить http2.

Я за унификацию :) Скорее вижу подход, где между бэкэндом и реверс
прокси бегает http2, а также во всей внутренней инфраструктуре и
силами реверс прокси это дело понижается до особо не продвинутых
внешних клиентов.

Но схему наоборот - http2 до публичного клиента и древний http 1.1 в
бэнбоне.... не вяжется, не нравится мне это.



2015-10-19 15:50 GMT+03:00 Maxim Dounin <mdounin@mdounin.ru>:
> Hello!
>
> On Sun, Oct 18, 2015 at 09:58:20PM +0300, Pavel Odintsov wrote:
>
>> Всем привет!
>>
>> Имеется сервер gRPC на С++, который работает только поверх
>> шифрованного HTTP2. Имеется желание его проксировать силами Nginx для
>> повышения надежности и реверс-проксирования.
>>
>> Суть в том, что Nginx должен общаться с gRPC бэкэндом только по
>> HTTP2/TLS, иначе оно не работает.
>>
>> Но Nginx не может подключиться к http2 бэкэнду вот с такой ошибкой:
>> 2015/10/18 20:54:07 [error] 2954#2954: *3 peer closed connection in
>> SSL handshake while SSL handshaking to upstream, client: 127.0.0.1,
>> server: api.fastnetmon.io, request: "POST
>> /fastmitigation.Fastnetmon/GetBanlist HTTP/2.0", upstream:
>> "https://127.0.0.1:10777/fastmitigation.Fastnetmon/GetBanlist", host:
>> "api.fastnetmon.io:443"
>
> [...]
>
> Just for the record:
>
> Разгадка в том, что поддержки HTTP/2 в proxy - нет и не
> планируется.
>
> Основное преимущество SPDY и HTTP/2 перед HTTP - это больший
> параллелизм при меньших затратах на установление соединений (одно
> соединение, в нём много запросов одновременно). При работе с
> бекендом - с тем же успехом можно поддерживать нужное количество
> HTTP-соединений, разницы по latency - не будет, по throughput -
> обычный HTTP будет лучше, выигрыш HTTP/2 - только по ресурсам на
> уровне ядра (меньше сокетов). И чтобы этот выигрыш получить -
> надо переписать работу с upstream'ами чуть менее, чем полностью,
> добавив поддержку мультиплексирования нескольких запросов в одном
> соединении. Смысла тратить на это силы и время - очень мало.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



--
Sincerely yours, Pavel Odintsov
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru