0

I am reading the documentation of Alexa Voice Service capabilities and came across the part on managing HTTP2 connection. I don't really understand how this down channel works behind the scenes. Is it using server push? Well, could server push be used to keep a long connection? Or is it just using some tricks to keep the connection alive for a very long time?

As stated on the documentation, the client needs to establish a down channel stream with the server.

enter image description here

Based on what I read here https://www.rfc-editor.org/rfc/rfc7540, From this state diagram:

enter image description here

once the stream sends a HEADER frame, followed by an END STREAM flag, the state will be half-closed(local) on the point of view of the client. So, this is how half-closed state for the device happened, as stated in above image. Correct me that if I am wrong.

For managing the HTTP connection, this is what it says.

enter image description here

Based on my understanding: the client sets a timeout of 60minutes for the GET request. After the request is sent, the server will not send any response. Then the connection will remain open for 60minutes. But once a response is sent from the server, the connection should be closed. Isn't that supposed to happen? Or, is it because when the server sends response through the down channel stream, it did not send an END STREAM flag so the stream will not be closed?

Community
  • 1
  • 1
JLT
  • 3,052
  • 9
  • 39
  • 86

1 Answers1

3

But once a response is sent from the server, the connection should be closed.

HTTP/1.1 and HTTP/2 use persistent connections, which means that a single connection can be used not just for one request/response, but for several request/response cycles.

Only HTTP/1.0 was closing the connection after the response, and so for HTTP/2 this is not the case, the connection will remain open until either peer decides to explicitly close it.

The recommendations about the idle timeouts are exactly to prevent the client to explicitly close the connection too early when it sees no network traffic, independently from requests or responses.

sbordet
  • 16,856
  • 1
  • 50
  • 45
  • Thank you for the useful info! I think I need to read more about the protocol. I thought the connection is NOT persistent by default. Because every time I send and receive a response, the connection is gone. And I am not involved in closing the connection, so I thought it's the default behavior. Like for instance in java, after reading all the response data from input stream, I thought the connection is closed. Then when I send a new request a new connection will be established... – JLT Nov 13 '19 at 02:39
  • Unless you're using HTTP/1.0 explicitly, even in Java the connection is kept open in most HTTP client implementations, from `HttpUrlConnection` to Jetty's `HttpClient` to Apache's HTTP client, etc. They all have connection pools that are used to reuse connections. – sbordet Nov 13 '19 at 06:33
  • I see. Thanks again! – JLT Nov 13 '19 at 08:55