NGINX: HTTP/2 Server Push and gRPC

NGINX: HTTP/2 Server Push
and gRPC

Amir Rawdat
Technical Marketing Engineer, NGINX
Formerly:
• Customer Applications Engineer, Nokia
• R&D Software Design, Mitel
Faisal Memon
Product Marketing Manager, NGINX
Formerly:
• Sr. Technical Marketing Engineer,
Riverbed
• Technical Marketing Engineer, Cisco
• Software Engineer, Cisco
Who are we?

Agenda
• Introducing NGINX
• NGINX HTTP/2 support
• HTTP/2 Server Push overview
• NGINX gRPC reverse proxy overview
• Demo
• Summary and Q&A

Where NGINX fits
Internet
Web Server
Serve content from disk
Application Gateway
FastCGI, uWSGI, Passenger…
Reverse Proxy
Caching, load balancing…
HTTP traffic

447 million
Total sites running on NGINX
Source: Netcraft February 2018 Web Server Survey

About NGINX, Inc.
• Founded in 2011, NGINX Plus first released in
2013
• VC-backed by enterprise software industry
leaders
• Offices in SF, London, Cork, Singapore,
Sydney, and Moscow
• 1,500+ commercial customers
• 200+ employees

“I wanted people to use it,
so I made it open source.”
- Igor Sysoev, NGINX creator and
founder

Agenda
• Introducing NGINX
• NGINX HTTP/2 overview
• NGINX HTTP/2 Server Push overview
• NGINX gRPC reverse proxy overview
• Demo
• Summary and Q&A

HTTP/2 Overview
Main benefits of HTTP/2:
• True connection multiplexing – No need for multiple connections, no head of line blocking
• Binary header – Less overhead, plug-ins available for WireShark
• Mandatory SSL – Browser-enforced, more secure

How NGINX Supports HTTP/2
• Backwards compatibility – Using ALPN, can support HTTP/2 alongside HTTP/1 (requires OpenSSL1.0.2 or later)
• HTTP/2 Gateway – Translates HTTP/2 into a protocol existing app servers can understand

NGINX HTTP/2 Support
• Initial release: September 2015
• NGINX 1.9.5 and later
• NGINX Plus R7 and later
• Used by 78% of all HTTP/2 enabled websites

NGINX HTTP/2 Support
• Add http2 argument to listen directive
• For clear text HTTP/2, remove SSL configuration
server {
listen 80;
server_name www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
ssl_certificate server.crt;
ssl_certificate_key server.key;
}

HTTP/2 Server Push Overview
• User requests /demo.html
• Server responds with /demo.html
• Server pre-emptively sends style.css and image.jpg
• Stored in separate browser push cache until needed
• Support added in NGINX 1.13.9

HTTP/2 Server Push Testing
• HTTP sequential GETs – No optimizations
• HTTP with preload hints – Includes Preload hints in the first response
• HTTP/2 with server push – Preemptively push dependencies

HTTP/2 Server Push Testing
• HTTP/2 and HTTPS introduce one additional RTT for SSL handshake
• HTTP/2 Server push eliminates stylesheet RTT
• Reduces 2 RTT overall compared to unoptimized HTTP/2

HTTP/2 Server Push Config (Method 1)
server {
root /var/www/html;
# whenever a client requests demo.html
# push /style.css, /image1.jpg, and
# /image2.jpg
location = /demo.html {
http2_push /style.css;
http2_push /image1.jpg;
http2_push /image2.jpg;
}
}
• http2_push – Defines resources to be pushed
to clients. When NGINX receives a request for
/demo.html, it will request and push
image1.jpg, and image2.jpg.

HTTP/2 Server Push Config (Method 2)
server {
root /var/www/html;
# whenever a client requests demo.html
# push /style.css, /image1.jpg, and
# /image2.jpg
http2_push_preload on;
}
}
• http2_push_preload – Instructs NGINX to parse HTTP
Link: headers and push specified resources.
• Link: </style.css>; as=style;
rel=preload, </favicon.ico>; as=image;
rel=preload
• Useful if you want application server to control what gets pushed.

HTTP/2 Server Push Config (Advanced)
server {
add_header Set-Cookie "session=1";
add_header Link $resources;
http2_push_preload on;
}
}
map $http_cookie $resources {
"~*session=1" "";
default "</style.css>; as=style;
rel=preload, </image1.jpg>;
as=image; rel=preload,
</image2.jpg>; as=style;
rel=preload";
}
• map directive sets up following logic:
• If no session cookie push resources
• If session cookie don’t push resources
• NGINX inserts session cookie on first request
• Resources will only be pushed once per browser session

HTTP/2 Server Push Verification
• Chrome Developer Tools: The Initiator column on the Network tab indicates several resources were pushed to the client as part of a
request for /demo.html.

gRPC Overview
• gRPC is transported over HTTP/2. Does not work with HTTP/1.
• Can be cleartext or SSL-encrypted
• A gRPC call is implemented as an HTTP POST request
• Uses compact “protocol buffers” to exchange data between client and server
• Protocol buffers are implemented in C++ as a class
• Support added in NGINX 1.13.10

gRPC Proxying
server {
listen 80 http2;
location / {
grpc_pass grpc://localhost:50051;
}
}
• grpc_pass – Use like fastcgi_pass,
proxy_pass, etc.
• grpc:// – Use instead of http://.

gRPC Proxying with SSL Termination
server {
location / {
grpc_pass grpc://localhost:50051;
}
}
• Configure SSL and HTTP/2 as usual
• Go sample application needs to modified to point to NGINX IP
Address and port.

gRPC Proxying with SSL Termination
creds := credentials.NewTLS( &tls.Config{ InsecureSkipVerify: true } )
// remember to update address to use the new NGINX listen port
conn, err := grpc.Dial( address, grpc.WithTransportCredentials( creds ) )
Modify client application, using sample Go application:
• Add crypto/tls and google.golang.org/grpc/credentials to your import list
• Modify the grpc.Dial() call to the following:.

gRPC Proxying with SSL End-to-End
server {
location / {
grpc_pass grpcs://localhost:50051;
}
}
• Use grpcs instead of grpc
• Modify server to listen on SSL
cer, err := tls.LoadX509KeyPair( "cert.pem", "key.pem" )
config := &tls.Config{ Certificates: []tls.Certificate{cer} }
lis, err := tls.Listen( "tcp", port, config )
NGINX configuration:
Server configuration for sample Go application:

gRPC Routing
location /helloworld.ServiceA {
grpc_pass grpc://192.168.20.11:50051;
}
location /helloworld.ServiceB {
grpc_pass grpc://192.168.20.12:50052;
}
• Usually structured as application_name.method

gRPC Load Balancing
upstream grpcservers {
server 192.168.20.21:50051;
server 192.168.20.22:50052;
}
server {
ssl_certificate ssl/certificate.pem;
ssl_certificate_key ssl/key.pem;
location /helloworld.Greeter {
grpc_pass grpc://grpcservers;
error_page 502 = /error502grpc;
}
location = /error502grpc {
internal;
default_type application/grpc;
add_header grpc-status 14;
add_header grpc-message "unavailable";
return 204;
}
}
• gRPC server work with standard upstream blocks.
• Can use grpcs for encrypted gRPC
• If no servers are available, the /error502grpc location
returns a gRPC-compliant error message.

NGINX Conf 2018
The official event for all things NGINX
October 8-11, 2018 | Atlanta, GA
Learn how to use NGINX to modernize existing applications and build new
microservice applications. There will be two session tracks:
• NGINX Builders: Hands-on insights for developers, IT ops, and DevOps
• NGINX Designers: Strategy and trends for architects and IT leaders
Early bird registration now open: nginx.com/nginxconf
How are you planning to use Server Push and gRPC?
Let us know: nginx-inquiries@nginx.com

Summary
• NGINX 1.13.9 and later support HTTP/2 server push
• Use h2_push to have NGINX push resources
• Use h2_push_preload on; to have NGINX use the Link: header
• NGINX 1.13.10 and later support gRPC proxying
• Use grpc_pass like proxy_pass, fastcgi_pass, etc. to proxy gRPC
connections
• Use grpc:// and grpcs:// like http:// and https:// to tell NGINX
what server(s) to proxy to
• Use location blocks to route gRPC requests
• Use upstream blocks to define groups of gRPC servers to load balance

Q & ATry NGINX Plus free for 30 days: nginx.com/free-trial-request

NGINX: HTTP/2 Server Push and gRPC

More Related Content

NGINX: HTTP/2 Server Push and gRPC

Editor's Notes