使用Nginx终止grpc流量

Question

This recent blogpost says that nginx is able to terminate http/2 and grpc traffic.

From all the illustrations and the text, it does not look like it can terminate grpc traffic at all, just proxy, forward and route the traffic.

Reason is, I want to offer simple services through nginx with PHP. I know PHP itself has the ability to implement http/2 and grpc but this is kinda "manual", there is nothing ready to use out of the box. If we can use nginx for the termination, it would probably work easily.

Another thing I dont' understand from the same blogpost:

Note: NGINX does not support HTTP/1 and HTTP/2 at the same time on a cleartext (non-TLS) port. It needs prior knowledge as to which version of the protocol will be used. If you want to handle both protocol versions over cleartext, create a listen port for each.

When both are cleartext, the protocol to be used actually is known up front (because it's cleartext) and we could listen for both on the same port. Two different ports only make sense to me, when either of the protocols is not cleartext.

Can someone clear these two points for me?

Answer 1

To me it means "terminate" in the sense of being able to act as the end point for the user from outside the system. In the same way as you often "terminate" HTTPS at the edge point (eg Nginx) but then pass on unencrypted HTTP traffic to a downstream server.

So you still need a separate server which understands how to handle gRPC and this needs to be available on a port for nginx to communicate with it using grpc_pass .

From the PHP examples at the gRPC website it seems to only use PHP as a client side gRPC application rather than the server side:

Note that currently you can only create clients in PHP for gRPC services - you can find out how to create gRPC servers in our other tutorials, eg Node.js.

So you need server side gRPC server (eg Node.js) to answer your gRPC calls - and that cannot just be nginx, though nginx can be used to route the gRPC calls to that gRPC server. There are various reasons to have a webserver like nginx in front of a backend application server including: SSL/TLS offloading, static content handling, load balancing...etc.

When both are cleartext, the protocol to be used actually is known up front (because it's cleartext) and we could listen for both on the same port.

That is not as easy as you think. Parsing messages to see if they are one protocol or another is actually quite complex - especially given that HTTP/1 is textual, HTTP/2 is binary and gRPC only uses HTTP/2 as the transport layer and doesn't even use HTTP semantics underneath this.

Typically there are three ways for a HTTP server to know if it's HTTP/2 or not:

1. Use plaintext HTTP initially and then upgrading it to HTTP/2.
2. Use encrypted HTTPS where it is negotiated using ALPN (or the older NPN) as part of the TLS setup before the first HTTP message is sent.
3. Use plaintext HTTP but assume it's a HTTP/2 connection (due to some previous prior knowledge about the service on that port) and so just start talking HTTP/2.

It looks like Nginx does not allow the first upgrade method of converting a plaintext HTTP/1.1 connection to HTTP/2. This means for plain text HTTP it only allows the connection to be immediately used as HTTP/2 ("prior knowledge"). There is a request to allow HTTP/1 and HTTP/2 to be used on the same port for different connections but to be honest I can understand why that has not been completed yet as would consider that low priority, given that the main use case for HTTP/2 at the moment is for browsers (which are HTTPS only) or for services like gRPC which probably should know whether they are HTTP/2 or not.

Also, as mentioned above, gRPC is not really about HTTP at all - it just uses the binary framing layer of HTTP/2 to send gRPC messages across a flow-controlled, multiplexed connection. This is similar to how Websockets use the HTTP TCP connection to send messages which are not HTTP (though web sockets typically use HTTP semantics to negotiate the web socket connection).

So, as I say, it actually makes sense to me not to complicate the matter and try to guess the protocol when not using HTTPS - it should be known in most cases.