0

We are migrating our service from Websocket to HTTP/2. However, we found that the connection must be re-established when the stream ID out of the available range. Since we maintains the connection between our reverse proxy and the actual app server, the HTTP/2 connection between the them will be re-established several times a day and the events that initiated by the server might be lost.

So, my question is how do we gracefully re-establish the connections between the servers?

Fred Pym
  • 2,149
  • 1
  • 20
  • 29

1 Answers1

0

The HTTP/2 stream id is 31-bits long meaning you can have 2^32 - 1 stream ids of which the odd ones are for the client initiated and even for the server initiated. This is 2,147,483,647 messages that can be sent before the stream ids are exhausted.

Are you really sending over 2 billion (US not UK billion!) messages several times a day that would mean you reach this limit? If so I am not sure HTTP is the best protocol for you and you may be best sticking with web sockets. HTTP adds overheads with HTTP headers that mean it’s not optimal for small, frequent messages.

Anyway to answer your question, the HTTP/2 spec has the following to say:

Stream identifiers cannot be reused. Long-lived connections can result in an endpoint exhausting the available range of stream identifiers. A client that is unable to establish a new stream identifier can establish a new connection for new streams. A server that is unable to establish a new stream identifier can send a GOAWAY frame so that the client is forced to open a new connection for new streams.

So basically you have to code the client and server to handle this and the client should automatically start a new stream when it is unable to increment the stream id. That is not to say it should tear down the old connection until all in flight messages have been answered - there may be two connections in progress for a period of tome. If this is not possible then I would suggest either the client or server proactively closes the connection in advance as the limit approaches, and new messages are queued until the connection is closed out and then a new message is established.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • Thanks for the reply:) Actually we are a smart speaker manufacturer in China. We have sold devices and all the devices will first connect to our reverse proxy and the reverse proxy connects to our app server. Before this migration, the connection of device <--> reverse proxy and reverse proxy <--> app server are both Websocket. To migrate to HTTP/2 is for aligning with the transfer protocol of Alexa Voice Service. So you are saying may be we should just keep the Websocket connection between the proxy and the app server? – Fred Pym Feb 19 '19 at 08:42
  • Well if no need to change the back end then not sure why you would. Also the benefits of HTTP/2 in the backend are questionable (see this question https://stackoverflow.com/questions/41637076/http2-with-node-js-behind-nginx-proxy). However you should also find out how your reverse proxy handles the situation you describe. Are you sure it will drop the connection and lose packets and not just handle this scenario? – Barry Pollard Feb 19 '19 at 09:15