4 ms·
From my understanding it's mostly head-of-the-line blocking. HTTP/2 was introduced to solve head-of-the-line blocking on the application level (one HTTP/1.1 co
by isbvhodnvemrwvn 6y ago
From my understanding it's mostly head-of-the-line blocking.
HTTP/2 was introduced to solve head-of-the-line blocking on the application level (one HTTP/1.1 connection could only handle one request at the time, barring poorly supported pipelining)
TCP itself also only allows one stream of data to flow at the time (in each direction) - in case of poor network quality you are going to lose some TCP segments, and if you fill in the receiver's window, the transfer might halt until retransmission succeeds (this includes ALL streams within HTTP/2). Using UDP allows you to circumvent that.
- anderspitman 6y agoI've wondered about this. It makes sense in theory, but it seems like if you have data loss on one channel and need retransmission, you probably also have data loss on other channels so they'll end up waiting for their own retransmissions anyway. It seems more like an inherent issue with building reliable streams on an unreliable channel. I'm sure there's hard research on it. Anyone know some good papers?
- cakoose 6y agoThis one seems pretty thorough: https://upcommons.upc.edu/bitstream/handle/2117/169283/TJM1de1.pdf https://upcommons.upc.edu/bitstream/handle/2117/169283/TJM1d... (Chapter 5). There's also a bunch from Google at various stages of QUIC development.