3 ms·

There is though a fundamental mismatch between TCP, and the problem HTTP (any version) needs to solve: TCP is for sending stream of bytes, reliably and in the s

There is though a fundamental mismatch between TCP, and the problem HTTP (any version) needs to solve: TCP is for sending stream of bytes, reliably and in the same order they were sent. HTTP needs to transmit some amount of data, reliably. The only aspect of TCP HTTP really wants here is reliability. The order we don’t really care about, we just want to load the whole web page and all associated data (images, scripts, style sheet, fonts…), in a way that can be reassembled at he other end. This makes it okay to send packets out of order, and doing so automatically solves head-of-line blocking. This is a little different when we start streaming audio or video assets: for those, it is often okay for reliability to take a hit (though any gap must be detected). Losing a couple packets may introduce glitches and artefacts, but doesn’t necessarily renders the media unplayable. (This applies more to live streams & chats though. For static content most would prefer to send a buffer in advance, and go back to sacrifice ordering in order to get a perfect (though delayed) playback.) In both use cases, TCP is not a perfect match. The only reason it’s so ubiquitous anyway is because it is so damn convenient.

masklinn 3y ago
That’s a different issue than what parent is talking about: HTTP definitely needs each individual resource to be ordered, what it does not need is for different resources to be ordered relative to one another, which becomes an issue when you mux multiple requests concurrently over a single connection.
crims0n 3y ago
> This is a little different when we start streaming audio or video assets: for those, it is often okay for reliability to take a hit (though any gap must be detected). Losing a couple packets may introduce glitches and artifacts, but doesn’t necessarily renders the media unplayable. This is exactly what UDP is for. There is nothing wrong with TCP and UDP at the transport layer, both do their job and do it well.

masklinn 3y ago

That’s a different issue than what parent is talking about: HTTP definitely needs each individual resource to be ordered, what it does not need is for different resources to be ordered relative to one another, which becomes an issue when you mux multiple requests concurrently over a single connection.

crims0n 3y ago

> This is a little different when we start streaming audio or video assets: for those, it is often okay for reliability to take a hit (though any gap must be detected). Losing a couple packets may introduce glitches and artifacts, but doesn’t necessarily renders the media unplayable. This is exactly what UDP is for. There is nothing wrong with TCP and UDP at the transport layer, both do their job and do it well.