4 ms·

HTTP/1.1 can do this. It's called pipelining. But browsers refuse to implement it.

by jart 5y ago

bigbonch 5y ago
Would still be constrained to head-of-line blocking which HTTP/3 aims to solve.
- baybal2 5y ago
  HTTP/3 will not be adopted because it's a downgrade from HTTP/2 for CDN companies. HTTP/2 has indeed massively benefitted CDNs by providing more effective capacity per buck, but UDP based 3.0/QUIC will singlehandedly destroy it, and bring it to below HTTP 1.1.
  - tehbeard 5y ago
    Could you give an eli5 as to why that's the case? Or are you just throwing out a proclamation?
  - celsoazevedo 5y ago
    Major CDNs seem to be adopting HTTP/3 just fine: Cloudflare: https://blog.cloudflare.com/http3-the-past-present-and-future/ https://blog.cloudflare.com/http3-the-past-present-and-futur... Akamai: https://developer.akamai.com/blog/2020/04/14/quick-introduction-http3 https://developer.akamai.com/blog/2020/04/14/quick-introduct... Fastly: https://www.fastly.com/blog/why-fastly-loves-quic-http3 https://www.fastly.com/blog/why-fastly-loves-quic-http3 Not to mention Google, which uses it a lot for regular pages and for content (eg: YouTube video). Adoption client-side also seems to be moving quickly too. I looked at the stats for 2 of my sites and HTTP/3 is now at 60-70%, with HTTP/2 having dropped to 25-30% already.
    - baybal2 5y ago
      Good for them, when they have money to spend on servers. Budget CDNs are much less happy.
      - celsoazevedo 5y ago
        That might be the case, but HTTP/3 is supported by most major CDNs and browsers. It has been adopted already. Also, if this blog post from 2020 is correct, performance per buck isn't that bad with some teaks: https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio... I assume things have evolved since 2020.
  - anticensor 5y ago
    The solution to that is QUIC over IP, i.e. removing UDP from the stack.
tsimionescu 5y ago
Browsers implemented it, but had to drop support because proxies don't support this, so in practice it turned out to be a major source of bugs.
- ghusbands 5y ago
  It was also a source of obscure bugs and DoS-level resource usage in servers and (non-browser) clients. Some servers managed to send multiple responses together or deadlocked the connection when the timing of requests or available responses was just right. Some servers would queue up responses in memory and so were prone to excess resource usage. Also, if you had a sent request waiting behind a slow/large response, you had to decide whether or not to send an extra request on a separate connection to get the resource sooner. And when a server closed a connection after sending a response (the spec allows it for multiple reasons), it was hard to know whether it was that the server was just not accepting more requests on that connection or whether a particular request caused it and hence whether any of the waiting request(s) should be re-sent or treated as being in error.
1vuio0pswjnm7 5y ago
It isn't multiplexed. You get the responses back in the same order that you request them. I actually prefer this because I use pipelining outside the browser. I do not want to have to re-ordering responses. I have never found the lack of multiplexing to make HTTP/1.1 pipelining any less useful.^1 It is still fast. HTTP/2 and HTTP/3 appear to be designed for a web of advertising, not a web where someone is using non-browser programs to efficiently request multiple files via HTTP from a single IP address. Some browsers implemented it, at least temporarily. However the important point no one mentions is that servers implemented it, permanently. I have been using HTTP/1.1 pipelining continuously since the mid 2000's. I could not even name an httpd that does not implement support for HTTP/1.1 pipellining (no doubt some HN commenter will come up with one, but it is a rare exception to the general rule). 1. I do not need compressed HTTP headers either. I like ASCII headers as they are useful record separators for catenated HTML. I have the forward proxy configured to add useful headers that provide additional information about the connection.

HTTP/1.1 can do this. It's called pipelining. But browsers refuse to implement it.

by jart 5y ago

HTTP/1.1 can do this. It's called pipelining. But browsers refuse to implement it.

bigbonch 5y ago

Would still be constrained to head-of-line blocking which HTTP/3 aims to solve.

baybal2 5y ago
HTTP/3 will not be adopted because it's a downgrade from HTTP/2 for CDN companies. HTTP/2 has indeed massively benefitted CDNs by providing more effective capacity per buck, but UDP based 3.0/QUIC will singlehandedly destroy it, and bring it to below HTTP 1.1.
- tehbeard 5y ago
  Could you give an eli5 as to why that's the case? Or are you just throwing out a proclamation?
- celsoazevedo 5y ago
  Major CDNs seem to be adopting HTTP/3 just fine: Cloudflare: https://blog.cloudflare.com/http3-the-past-present-and-future/ https://blog.cloudflare.com/http3-the-past-present-and-futur... Akamai: https://developer.akamai.com/blog/2020/04/14/quick-introduction-http3 https://developer.akamai.com/blog/2020/04/14/quick-introduct... Fastly: https://www.fastly.com/blog/why-fastly-loves-quic-http3 https://www.fastly.com/blog/why-fastly-loves-quic-http3 Not to mention Google, which uses it a lot for regular pages and for content (eg: YouTube video). Adoption client-side also seems to be moving quickly too. I looked at the stats for 2 of my sites and HTTP/3 is now at 60-70%, with HTTP/2 having dropped to 25-30% already.
  - baybal2 5y ago
    Good for them, when they have money to spend on servers. Budget CDNs are much less happy.
    - celsoazevedo 5y ago
      That might be the case, but HTTP/3 is supported by most major CDNs and browsers. It has been adopted already. Also, if this blog post from 2020 is correct, performance per buck isn't that bad with some teaks: https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio... I assume things have evolved since 2020.
- anticensor 5y ago
  The solution to that is QUIC over IP, i.e. removing UDP from the stack.

tsimionescu 5y ago

Browsers implemented it, but had to drop support because proxies don't support this, so in practice it turned out to be a major source of bugs.

ghusbands 5y ago
It was also a source of obscure bugs and DoS-level resource usage in servers and (non-browser) clients. Some servers managed to send multiple responses together or deadlocked the connection when the timing of requests or available responses was just right. Some servers would queue up responses in memory and so were prone to excess resource usage. Also, if you had a sent request waiting behind a slow/large response, you had to decide whether or not to send an extra request on a separate connection to get the resource sooner. And when a server closed a connection after sending a response (the spec allows it for multiple reasons), it was hard to know whether it was that the server was just not accepting more requests on that connection or whether a particular request caused it and hence whether any of the waiting request(s) should be re-sent or treated as being in error.

1vuio0pswjnm7 5y ago

It isn't multiplexed. You get the responses back in the same order that you request them. I actually prefer this because I use pipelining outside the browser. I do not want to have to re-ordering responses. I have never found the lack of multiplexing to make HTTP/1.1 pipelining any less useful.^1 It is still fast. HTTP/2 and HTTP/3 appear to be designed for a web of advertising, not a web where someone is using non-browser programs to efficiently request multiple files via HTTP from a single IP address. Some browsers implemented it, at least temporarily. However the important point no one mentions is that servers implemented it, permanently. I have been using HTTP/1.1 pipelining continuously since the mid 2000's. I could not even name an httpd that does not implement support for HTTP/1.1 pipellining (no doubt some HN commenter will come up with one, but it is a rare exception to the general rule). 1. I do not need compressed HTTP headers either. I like ASCII headers as they are useful record separators for catenated HTML. I have the forward proxy configured to add useful headers that provide additional information about the connection.