5

As far as i know, TCP break down a message into segments. So, Why is multiplexing again on HTTP2? What are the benefits of multiplexing twice?

devhak
  • 155
  • 1
  • 6
  • 2
    TCP works on a lower level than http does. That means the fact that TCP implements a package based approach is nothing that is relevant or helpful on the protocol level. There you still have to setup new connections for each single request. – arkascha Jan 30 '18 at 00:05
  • Because HTTP/1.1 requests block the TCP connection: https://stackoverflow.com/questions/36517829/what-does-multiplexing-mean-in-http-2/36519379#36519379 – Barry Pollard Jan 30 '18 at 07:19

3 Answers3

21

TCP isn’t multiplexed. TCP is just a guaranteed messaging stream (i.e. missing packets are re-requested and the TCP stream is basically temporarily blocked while this happens).

TCP, as a packet based protocol, can be used for multiplexed connections if the higher level application protocol (e.g. HTTP) allows sending of multiple messages. Unfortunately HTTP/1.1 does not allow this: once a HTTP/1.1 message is sent, no other message can be sent on that connection until that message is returned in full (ignoring the badly supported pipelining concept). This means HTTP/1.1 is basically synchronous and, if the full bandwidth is not used and other HTTP messages are queued, then it wastes any extra capacity that could be used on the underlying TCP connection.

To get around this more TCP connections can be opened, which basically allows HTTP/1.1 to act like a (limited) multiplexed protocol. If the network bandwidth was fully utilised then those extra connections would not add any benefit - it’s the fact there is capacity and that the other TCP connections are not being fully utilised that means this makes sense.

So HTTP/2 adds multiplexing to the protocol to allow a single TCP connection to be used for multiple in flight HTTP requests.

It does this by changing the text-based HTTP/1.1 protocol to a binary, packet-based protocol. These may look like TCP packets but that’s not really relevant (in the same way that saying TCP is similar to IP because it’s packet based is not relevant). Splitting messages into packets is really the only way of allowing multiple messages to be in flight at the same time.

HTTP/2 also adds the concept of streams so that packets can belong to different requests - TCP has no such concept - and this is what really makes HTTP/2 multiplexed.

In fact, because TCP doesn’t allow separate, independents streams (i.e. multiplexing), and because it is guaranteed, this actually introduces a new problem where a single dropped TCP packet holds up all the HTTP/2 streams on that connection, despite the fact that only one stream should really be affected and the other streams should be able to carry on despite this. This can even make HTTP/2 slower in certain conditions. Google is experimenting with moving away from TCP to QUIC to address this.

More details on what multiplexing means under HTTP/2 (and why it is a good improvement!) in my answer here: What does multiplexing mean in HTTP/2

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • "HTTP/2 also adds the concept of streams so that packets can belong to different requests - TCP has no such concept - and this is what really makes HTTP/2 multiplexed." Do you mean that HTTP/1.1 encapsulates a single HTTP message (request or response) in a single TCP packet, and HTTP/2 encapsulates multiple HTTP messages in a single TCP packet? – Géry Ogam Feb 24 '21 at 14:37
  • 1
    No I mean TCP has no concept of marking a packet as for one HTTP request or another. It's just a stream of packets. So HTTP/1.1 being just a steam of characters, it has to assume all the packets are for request 1, until it sees the magic characters signally the end of request 1 - then it assumes everything is for request 2, until it sees the end of request 2. HTTP/2 however splits each request into a number of frames, marks each frame with a request id (well a stream id, but a stream is basically created for a request) so you can mingle those frames up, and then unmingle them at the other end. – Barry Pollard Feb 24 '21 at 16:03
  • Thanks, I see. The fundamental improvement of HTTP/2 is stream *concurrency* (interleaving of streams), which is allowed by the new splitting of streams into frames with *stream identifiers*. Stream concurrency was impossible in HTTP/1.1 since streams were split into characters so without stream identifiers. Thus the novelty of HTTP/2 is not *pipelining* (which was already available in HTTP/1.1 though not widely supported in web browsers) nor *multiplexing* (which was already available in HTTP/1.1 since multiplexing is just using multiple streams over a single connection). – Géry Ogam Feb 28 '21 at 22:24
  • 1
    Almost, except multiplexing implies concurrency. Serial requests (i.e. one after the other but without breaking the connection in between - made possible with keepalive functionality in HTTP/1.1) isn’t multiplexing. TCP offers serial requests following on from each other and, as per the original question, and the first line in my answer that’s not multiplexing. – Barry Pollard Feb 28 '21 at 22:31
  • I think it depends on what you consider a stream. If you use different stream definitions for HTTP/1.1 and HTTP/2, that is in HTTP/2 you define a stream as a single message (i.e. a sequence of frames) and in HTTP/1.1 you define a stream as *all* messages (i.e. a sequence of messages), then yes HTTP/1.1 does not use multiplexing since there is a single stream (signal) per connection (channel). But if you use the same definitions for HTTP/1.1 and HTTP/2, that is you define a stream as a single message for both, then HTTP/1.1 does use multiplexing since there are multiple streams per connection. – Géry Ogam Mar 01 '21 at 07:50
  • Well personally I wouldn’t consider the second definition as multiplexing. And back to the original question “Why HTTP/2 does multiplexing although TCP does the same thing?” TCP doesn’t do the same thing, and neither does HTTP/1.1. And the HTTP/2 RFC is very clear about its definition of stream and why HTTP/1.1 does not meet that criteria as they are not independent not concurrent: https://tools.ietf.org/html/rfc7540#section-5 – Barry Pollard Mar 01 '21 at 08:01
  • We agree that TCP and HTTP/1.1 do not do the same thing as HTTP/2: TCP and HTTP/1.1 use *sequential* messages (concatenation) while HTTP/2 use *concurrent* messages (interleaving). Now these *ordering* properties seem orthogonal to *multiplexing* which is *sharing* a channel for transmitting multiple signals (irrespectively of the order)—except for multiple *infinite* signals where indeed "multiplexing implies concurrency". So if you consider HTTP/1.1 does not use multiplexing while HTTP/2 does, it means your view (which is fine) is: HTTP/1.1 signal = all messages; HTTP/2 signal = one message. – Géry Ogam Mar 01 '21 at 10:00
  • Yes that is my view, but I'm also answering in context of the question whereas your definition would mean the question doesn't make sense. I would say what you are talking about is "persistent connections" not "multiplexed connections": https://en.wikipedia.org/wiki/HTTP_persistent_connection has the following "The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection." – Barry Pollard Mar 01 '21 at 10:24
  • Yes in my view the original poster makes a terminology confusion by using ‘multiplexing’ as a synonym for ‘splitting’: ‘TCP breaks down a message into segments. So why is multiplexing again on HTTP/2?’ So I think what the original poster was really asking about was: why does HTTP/2 split messages into frames whereas messages are already split into packets at the TCP level? I am not sure he was asking about concurrency, multiplexing or pipelining, but the answer to his question is concurrency. – Géry Ogam Mar 01 '21 at 11:45
  • Thanks for the link. The statement on HTTP/2 persistent connections was added [here](https://en.wikipedia.org/w/index.php?title=HTTP_persistent_connection&diff=578813904&oldid=578812864). But it does not imply that HTTP/1.1 does not allow multiples messages to be multiplexed over a single connection. It implies that HTTP/1.1 does not allow multiples *concurrent* messages to be multiplexed over a single connection. But multiple *sequential* messages can be multiplexed over a single connection, thanks to persistent connections. Unless you view them as a single signal over a single connection. – Géry Ogam Mar 01 '21 at 12:00
1

TCP doesn't do multiplexing. The TCP segments just means that the (single) stream data is chopped up into pieces that can be sent in IP packets. Each TCP segment is only identified with a stream offset (sequence number), not with any useful way to identify separate streams. (We'll ignore the rarely-useful Urgent Pointer thing.)

So to do multiplexing, you need to put something on top of TCP. Which HTTP/2 does.

Ove
  • 770
  • 4
  • 9
1

HTTP & HTTP/2 are both application level protocols that must utilize a lower level protocol like TCP to actually talk on the Internet. The protocol of the Internet is generally TCP over IP over Ethernet.

It looks like this:

enter image description here

As you can see HTTP is sitting above TCP. Below TCP is IP. One of the main protocols of the Internet. IP itself deals with packets which are switched/multiplexed. I think that's where you might be getting the idea that TCP is multiplexed, it's not. Think of a TCP connection as being like a single lane road tunnel where no one can pass. Lets say it has one single lane in each direction. This is what a TCP connection would look like. A tunnel where you put data in one end, and it comes out the other in the same order it went in. That is TCP. You can see there is no multiplexing on that. However, TCP does provides a reliable connection protocol for which other protocols may be built on top of like HTTP. And reliability is essential for HTTP.

HTTP 1.1 is simply a request response protocol. But as you know, it's not multiplexed. So only allow one outstanding request at a time and has to send the whole response to each request at a time. Previously the browsers got around that limitation by creating multiple TCP connections (tunnels) to the server with which to make more requests.

HTTP 2 actually splits the data up again and allows multiplexing over the one connection so that no further connections need to be created. It means the server can start servicing multiple requests and multiplex the responses so that the browser can start receiving images, pages and other resources at the same time, not one at a time.

Hope that makes it clear.

hookenz
  • 36,432
  • 45
  • 177
  • 286
  • I don't consider this a good answer to the question, because, while it has some good information, it focuses on the higher-level abstraction, not on the capabilities of the TCP protocol itself. If an abstraction was the only reason to do something in an inefficient way (i.e., if a more efficient way to use the protocol would exist if it weren't for the abstraction), then the abstraction is bad, should be changed, and probably would have been changed long ago. Thus, IMHO, a good answer should focus on why TCP segmentation isn't capable of multiplexing, not on what is presented to higher levels. – Ove Jan 31 '18 at 01:33
  • @Ove - You're right it was crap. I've rewritten my answer from scratch. – hookenz Jan 31 '18 at 20:22