#1875 closed enhancement (duplicate)

allow configuring upstreams as HTTP2 to prevent high latency for SSL connects

Reported by: artheus@… Owned by:
Priority: minor Milestone: nginx-1.17
Component: nginx-module Version: 1.17.x
Keywords: proxy upstream http2 Cc:
uname -a: Linux t-lb-int01-l 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.16.1
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
built with OpenSSL 1.0.2k-fips 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie'


TL;DR; While configuring upstreams, one should be able to configure them as HTTP2.

This way a connection to the upstream should be kept alive, and allowing a high rate of requests to pass through e.g. a reverse proxy.

Allowing this would greatly decrease the resources (CPU and RAM) usage of e.g. backends with SSL termination. This is due to the SSL handshake will be done when connecting, and all other requests should be "multiplexed" in the long-lasting connections to the backend upstreams.

Configuring upstreams like this would prevent e.g. plaintext data from being sent between sites (e.g. data-centers)

example configuration:

upstream h2backend {
    server backend1.example.com:443 http2;
    server backend2.example.com:443 http2;

server {
    location / {
        proxy_pass http://h2backend;

There might be a better/alternative solution to this, which would not confuse users to think that this would allow "http2 push". This suggested solution is only meant for preventing high latency and high resource usage for SSL connections (handshakes) to backend upstreams, strictly configured with SSL.

Change History (1)

comment:1 by Maxim Dounin, 10 months ago

Resolution: duplicate
Status: newclosed

To reduce latency of SSL handshakes, there is SSL session reuse, which is enabled by default. Further, there is keepalive to keep connection alive. As for multiplexing, it is believed to be a bad idea for backend connections, as it is subject to head-of-line-blocking and also affected by congestion problems. Further, if you really need HTTP/2 as a protocol for upstream connections for some reason, you can do so by using grpc_pass. Closing this as a duplicate of #923, see comments there for more details.

Note: See TracTickets for help on using tickets.