|
|
|
|
|
|
by stephen_g
3709 days ago
|
|
|
Are you saying HTTP/2 're-implementing multiple connections on top of a single TCP stream' is a bad thing? There is an entirely valid reason to do so (that TCP connections need to have slow-start to avoid congestion). TCP will always be inefficient for sending single, small files. HTTP/2 doing this is great, because it means you can do away with the hacks that were used with HTTP/1.1 to get around connection limits, and you can do away with the hacks like putting all your JS in a single file to get around slow-start (by reducing the number of files sent), which is bad for caching (if users have your site cached and you change one JS file, their browsers have to download the whole concatenated collection of files again). I'm all for trying to keep things simple, but I think much of the complexity in HTTP/2 is solving valid, real problems that will improve the speed of the web, which is a good thing. |
|
|
Not necessarily; I'm saying that it is another layer of multiplexing on to of a layer of single connections, that is on top of multiplexing, which is on top of a single connection, etc. I'm saying that the main reason HTTP/2 exists is because of the limits we had to put in place in HTTP/1.1, like connection limits, and the uphill battle it is to get standards changed like how TCP window size works or how to deal with slow start.
Eventually, we'll come full circle le when someone uncovers an optimization that occurs when you make multiple TCP connections to a server, all running HTTP/2 over them.