3 ms·

Still not massively convinced HTTP needed to progress beyond 1.1. I’m sure someone at Google got a promotion out of it though.

by mnd999 5y ago

tialaramex 5y ago
Pretty early on it becomes apparent that you'd quite like to fetch more than one resource. In 1992 you're fetching one page of HTML markup or maybe a file somebody linked, but by 1995 you're definitely fetching a picture of the author's cat and the logo of the organisation they work for. Maybe there is a little animated GIF explaining that the page is under construction. Today obviously most documents on the web have lots of resources ("Under construction" GIFs are gone, but pictures of the author's cat are still very much a thing, now joined by audio and video, style and of course scripts). Obviously one thing you can do is, for every resources spin up a new HTTP connection to the remote server. These connections have no relationship to each other, so that's a bunch of extra overhead but nevertheless your browser today will probably try to do this several times per server. Still that's pretty inadequate, surely we can do better? So, OK, HTTP/1.1 also has keep-alive. We can re-use connections, ask for a resource, wait until that's delivered, then fetch another one. But notice this is strictly sequential. If you're a Unix person it's natural to try the next idea for HTTP, pipelining. Don't wait until things are delivered, just ask for everything you want, surely the remote server will provide one at a time, reading your next request, serving that, then the next one and so on, right? But for 1990s server programmers excited by threads this doesn't work. Their server has one thread gathering requests, and for each request it spawns a thread to provide the answer. If I try to pileline my HTTP requests I get muddled nonsense back from their server. Sometimes. Is that forbidden by the HTTP specification. Sure. Did it happen anyway? Yes. So your browser does not use pipelining in HTTP/1.1 Also, this suffers head-of-line blocking. If I request CreditCardStatement19960402.pdf and you must send a tape robot to retrieve that, too bad, even though I also wanted bankname.jpeg and hideousfont.css I can't retrieve those because I'm waiting for CreditCardStatement19960402.pdf. The network is idle while we wait for the robot. Google's servers and Google's browser spoke SPDY back in the day, which fixes a bunch of this. That doesn't exist any more because HTTP/2 was standardised and has the same fixes plus other stuff, some of which proved very useful, other things not so much. Only one way to find out.
- mnd999 5y ago
  Sure, HTTP 1.1 was a clear improvement over 1.0.
- omegalulw 5y ago
  Why not have the server packetize and label? ... <file1, bytes 2048-4096> <file2, bytes 0-125> ... The server has to order critical stuff first on a pipelined connection to reduce latency but this approach can easily send stuff the client requested and will request, while collecting data serverside by any number of threads.
  - tialaramex 5y ago
    Is your question, "Why didn't we invent a better protocol than HTTP/1.1" ? Because the answer is we did, but the previous poster doesn't like newer HTTP protocols. If you just meant, "Why didn't we ignore how the HTTP/1.1 protocol is defined and do something else?", that's not what a protocol is, you're not going to build a successful application without agreement about the protocol.
- kevin_thibedeau 5y ago
  HTTP/2 should have been implemented over SCTP. It's silly that we're restricted to two bulk transport protocols and have to hack things on top of them. Google could have used it's influence to break the logjam.

Still not massively convinced HTTP needed to progress beyond 1.1. I’m sure someone at Google got a promotion out of it though.

by mnd999 5y ago

Still not massively convinced HTTP needed to progress beyond 1.1. I’m sure someone at Google got a promotion out of it though.

tialaramex 5y ago

Pretty early on it becomes apparent that you'd quite like to fetch more than one resource. In 1992 you're fetching one page of HTML markup or maybe a file somebody linked, but by 1995 you're definitely fetching a picture of the author's cat and the logo of the organisation they work for. Maybe there is a little animated GIF explaining that the page is under construction. Today obviously most documents on the web have lots of resources ("Under construction" GIFs are gone, but pictures of the author's cat are still very much a thing, now joined by audio and video, style and of course scripts). Obviously one thing you can do is, for every resources spin up a new HTTP connection to the remote server. These connections have no relationship to each other, so that's a bunch of extra overhead but nevertheless your browser today will probably try to do this several times per server. Still that's pretty inadequate, surely we can do better? So, OK, HTTP/1.1 also has keep-alive. We can re-use connections, ask for a resource, wait until that's delivered, then fetch another one. But notice this is strictly sequential. If you're a Unix person it's natural to try the next idea for HTTP, pipelining. Don't wait until things are delivered, just ask for everything you want, surely the remote server will provide one at a time, reading your next request, serving that, then the next one and so on, right? But for 1990s server programmers excited by threads this doesn't work. Their server has one thread gathering requests, and for each request it spawns a thread to provide the answer. If I try to pileline my HTTP requests I get muddled nonsense back from their server. Sometimes. Is that forbidden by the HTTP specification. Sure. Did it happen anyway? Yes. So your browser does not use pipelining in HTTP/1.1 Also, this suffers head-of-line blocking. If I request CreditCardStatement19960402.pdf and you must send a tape robot to retrieve that, too bad, even though I also wanted bankname.jpeg and hideousfont.css I can't retrieve those because I'm waiting for CreditCardStatement19960402.pdf. The network is idle while we wait for the robot. Google's servers and Google's browser spoke SPDY back in the day, which fixes a bunch of this. That doesn't exist any more because HTTP/2 was standardised and has the same fixes plus other stuff, some of which proved very useful, other things not so much. Only one way to find out.

mnd999 5y ago
Sure, HTTP 1.1 was a clear improvement over 1.0.
omegalulw 5y ago
Why not have the server packetize and label? ... <file1, bytes 2048-4096> <file2, bytes 0-125> ... The server has to order critical stuff first on a pipelined connection to reduce latency but this approach can easily send stuff the client requested and will request, while collecting data serverside by any number of threads.
- tialaramex 5y ago
  Is your question, "Why didn't we invent a better protocol than HTTP/1.1" ? Because the answer is we did, but the previous poster doesn't like newer HTTP protocols. If you just meant, "Why didn't we ignore how the HTTP/1.1 protocol is defined and do something else?", that's not what a protocol is, you're not going to build a successful application without agreement about the protocol.
kevin_thibedeau 5y ago
HTTP/2 should have been implemented over SCTP. It's silly that we're restricted to two bulk transport protocols and have to hack things on top of them. Google could have used it's influence to break the logjam.