confusion regarding bidirectional and full-duplex in articles about http/2

Question

Some articles describing http/2 are praising it for being both bidirectional and full-duplex.

AFAIK bidirectional means that communication is in both directions so duplex is by its nature bidirectional, yes?

Duplex can be created by one simplex stream that is reversed at some specific points (half-duplex) or it can be created as two opposite simplex streams (full-duplex).

Maybe bidirectional is about how can initiate a message exchange? In http/1 only client can initiate by sending request to the server in which the server returns a response. In http/2 a server can send (push) some resource without being explicitly asked for it. But we can use Server-sent events in http/1.1 (that is server can push messages if it wants to after doing a little bit configuration on both the client and the server, but it's still over http/1.1 protocol).

When you think about it you may notice that http/1 is as well bidirectional and full-duplex (since pipelining wouldn't be possible in half-duplex). So no change here from http/2 perspective.

What has changed is that http/1 required responses to arrive in exact order in which they were requested. http/2 lifts that with streams and multiplexing.

Tiffanytiffi

Answer 1

Bidirectional means you can send data in both directions.

Full duplex means you can send data in both directions at the same time - you can have two threads, one writing data and one reading data, executing concurrently.

If we take as endpoints "client" and "server" (no matter how many TCP connections between the two), then obviously both HTTP/1.1 and HTTP/2 are full duplex.

If we take as endpoints the two ends of a single TCP connection between client and server, again both HTTP/1.1 and HTTP/2 are - in general - full duplex.

This is obvious for HTTP/2 but less known for HTTP/1.1 because it is commonly thought as a "first the request, then the response" protocol - however, that is not the case. It is perfectly possible, for example for a server that echoes back the content bytes that the client sends, to have the client make a large upload, and while the upload is still going the server already starts to respond echoing back the bytes - upload and download happen at the same time.

We can now enter the matter of unsolicited communication from server to client.

This is not possible in HTTP/1.1. Even with Server Sent Events (SSE) the client makes a request and the server responds with an "infinite response" - but the client must make the request first.

In HTTP/1.1, SSE is not full duplex from the point of view of a single TCP connection: the client first makes the request, then the server responds with an "infinite response". From that point on, the client can communicate with the server only by making another request, which means opening a new connection.

In HTTP/2, SSE is full duplex because it would be possible for the client to communicate to the server by making another request on the same TCP connection, thanks to HTTP/2 multiplexing.

The SSE "infinite response" can be seen as "the server writes chunks of data that can be interpreted as pushed messages" but the SSE protocol is too simple to allow generic messages from server to client (e.g. data cannot be binary). You would not consider a download that stutters as the server pushing data to the client :)

Unsolicited communication from server to client is also not possible in HTTP/2, because HTTP/2 can "push" a resource to the client, but only in the context of a previous request.

For example, a HTTP/2 client establishes a connection with the server, but then it does not send any request; in this case, the server won't be able to push anything to the client (not even a welcome page), as it needs a previous request to do so.

That is why HTTP/2 cannot be a complete substitute for the WebSocket protocol, which is the only web protocol that you can use for full unsolicited communication from server to client.

Goodale

Great answer. One thing though: I wouldn't consider websockets as 100% unsolicited communication since it can only be established by the client with http upgrade request. If a connection is established we have unsolicited communication but the same is true for http/2 with SSE (one TCP connection, both parties can send messages at will). – Tiffanytiffi

@Tiffanytiffi all the protocols we discussed have a "client" establishing a connection. I don't consider connection establishment as part of the definition of bidirectional, duplex or unsolicited, because some party must start the communication. WebSocket establishes the connection by sending a HTTP/1.1 request (so at that point is not yet WebSocket). After that request, the server replies with a HTTP 101, and after that we are in WebSocket land, where the "client" can be just passive, never send anything to the server, and only receive unsolicited messages from the server. 1/2 – Goodale

In none of the other protocols you can establish the connection and then get an unsolicited message from the server - the client must send a request first. 2/2 – Goodale

yes, all the technologies we've discussed are client-server. For the completeness I'd like to mention that there's also WebRTC which is peer-to-peer where there's no need for an explicit permission from the client to send or receive messages. – Tiffanytiffi

Very insightful. @Goodale In your example of upload/download over HTTP1.1, you point out the full-duplex behaviour. But later you give an example of a client not able to send messages in simultaneous with SSE's infinite responses. Could we say HTTP1.1, is duplex, only when the client initiates the streaming? If yes, is there a more accurate term than "full-duplex"? Thanks – Cotonou

I use the terms "duplex" and "full-duplex" interchangeably, opposed to "half-duplex" (the latter where only one endpoint can send at a time). With HTTP/1.1 and SSE, once the request is finished, you only have an infinite response. Can you also make an infinite request along with an infinite response? Technically yes, but I'd say that's abusing the HTTP protocol, better switch to something else like WebSocket at that point. – Goodale

@Goodale "Unsolicited communication from server to client is also not possible in HTTP/2" - This statement suggests that HTTP/2 stream is not full duplex.. However both websocket and gRPC over H2 makes use of a single stream for bidirectional communication. Along with that, the RFC says that the server can initiate a stream. – Soracco

@Soracco both WebSocket and gRPC can send server-to-client data, but only in the context of a stream previously initiated by the client. The HTTP/2 protocol at the transport level may allow the server to initiate unsolicited streams, but you would need a custom client to support that -- normal HTTP clients do not support it. – Goodale

Thanks @sbordet. Yes, That's what I was thinking. But doesn't that mean gRPC and websockets would diverge from the HTTP spec? Isnt HTTP known for its request-response model? I do have a question on the same topic . Do you mind posting your answer here? - #75503117 – Soracco