Я бы не стал доверять проектам, которые пишут бэкенд, поддерживающий http2-only. От этой идеи несет хипстерством за километр.
> On 19 окт. 2015 г., at 15:56, Pavel Odintsov <pavel.odint...@gmail.com> wrote: > > Приветствую! > > Спасибо за ответ! > > Но проблема несколько шире. Уже много фреймфорков написанных чисто на > 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 <mdou...@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 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru