9 ms·

HTTP/2 and HTTP/3 are both very useful even without server push. HTTP/2 fixed the issues of HTTP pipelining and made it so multiple requests could share one con

HTTP/2 and HTTP/3 are both very useful even without server push. HTTP/2 fixed the issues of HTTP pipelining and made it so multiple requests could share one connection without issues like head-of-line blocking, and HTTP/3 improves things further so that a missed packet in one request doesn't slow down simultaneous requests. Server push was never a critical feature of them. The measured improvements from 2 and 3 were almost always without server push.

CyberRabbi 6y ago
You can open multiple tcp connections in parallel to virtually eliminate the head of line blocking problem for the vast majority of experiences. The problem has been exaggerated for the sake of justifying http2/3 but in practical terms it barely affects the average user experience. 80% optimal was good enough. On the other hand it reduces cost by a few percentage points for the vanishingly few web hosts large enough such that that would have a meaningful financial impact.
- vhiremath4 6y ago
  There is a cost to opening a new connection and having to re-incur multiple roundtrips in order to complete a new TCP and TLS handshake. This is a meaningful overhead savings for folks with a network setup that has high last-mile latency.
  - CyberRabbi 6y ago
    As has been demonstrated by my original post, clearly saving a few rtt is irrelevant here. Anyway your point is halfway-irrelevant since if you initiate all connections in parallel you only suffer the rtt latency of a single connection. The only people saving here are the people running servers that serve world-scale numbers of requests. The average user notices nearly no difference.
    - alexchamberlain 6y ago
      The world-scale companies are also the companies writing the standards.
      - CyberRabbi 6y ago
        Funny that
    - vhiremath4 6y ago
      I'm not sure I fully follow here, but I would like to be able to. Created a video response: https://www.loom.com/share/4539869f41cf47c5a154a342308584de https://www.loom.com/share/4539869f41cf47c5a154a342308584de
      - CyberRabbi 6y ago
        Hehe I engage with people like that all the time and I think I’ve learned a lot. In my humble opinion the people who are easily offended aren’t really worth discussing difficult problems with. Actually I find that I learn a lot more from people who don’t get hung up when their ego happens to unintentionally get bruised. I think you need to reread my initial post in this thread. The importance of minimizing rtt blocking is acknowledged in my questioning of chrome’s decision to not implement http push.
        vhiremath4 6y ago
        My ego is not bruised. As I said: > I'm not sure I fully follow here, but I would like to be able to What I'm calling out is that you may have fallen into the trap (as I did years back) that you need to be an asshole to drive towards solving hard problems. You don't, and it actually blocked me from creating the psychological safety necessary to get good ideas out of people who otherwise wouldn't feel comfortable speaking up. Genuinely good/supporting vibes from my direction to you - do with it what you will, but I do believe your ego is showing here more than mine. We can agree to disagree since I believe each of us will over-index on our past life experiences vs. those of some random person on Hacker News. > I think you need to reread my initial post in this thread. The importance of minimizing rtt blocking is acknowledged in my questioning of chrome’s decision to not implement http push. I think I get what you're saying, but honestly the way you're wording your points is a bit confusing. I am going to chalk this up to "I'm just too dumb" for sake of laziness at this point.
- TwoBit 6y ago
  Isn't part of the idea with HTTP2 that the server can see everything you're asking for and more intelligently prioritize vs a bunch of separate independent connections?
  - CyberRabbi 6y ago
    I’m not aware of any open source servers that implement such an optimization and if proprietary software exists that does, it’s trivial to implement custom logic to do that across multiple connections as well.
    - jlokier 6y ago
      It's actually not trivial to optimize dynamic prioritisation across multiple connections. To keep a TCP efficient, the sending process needs to fill up the send buffer to a reasonable amount, generally by writing data to the kernel with write()/send(). If the sending process doesn't do this, the sending TCP will not send full frames as fast as the network or receiver allows, and do so at a steady cadence. But to prioritise the data flow of multiple responses across multiple connections, the sender needs to pause existing TCP flows in progress as soon as it has higher priority response data ready to send if the higher priority TCP will send at full rate. Yet if the higher priority TCP is sending slower than full rate temporarily due to slow start, congestion control or receive window full, etc., the lower priority TCP needs to be resumed just enough to fill the gaps. It's not even possible to do this with the ordinary sockets API, so it's certainly not trivial. With HTTP/2 and TCP in kernel, it's still not optimal because prioritised response data will be queued behind data already in the TCP send buffer, but at least there's only one send buffer's worth to compete with rather than lots. With HTTP/3 and QUIC in userspace, adaptive prioritisation can be optimised further because the decision is made on every packet just before it leaves the machine. Per-packet prioritisation would be possible in theory with HTTP/1 and HTTP/2 by implementing TCP in userspace, or by implementing HTTP in kernelspace, in either case tightly coupling TCP and HTTP. I don't know of anyone doing it, because it would be a lot of work for a marginal gain.
      - CyberRabbi 6y ago
- raxxorrax 6y ago
  But you would have to implement it on a layer that maybe should be exempt from dealing with network loading. I agree that the benefits only fit certain use cases, but it is still nice to have it and it is already widely adapted.
- lxgr 6y ago
  > vanishingly few web hosts large enough such that that would have a meaningful financial impact By that logic, electricity wasted on inefficient power adapters and devices in standby mode is irrelevant: The marginal savings per household are cents per year. If it doesn't hurt me as an end user (and I don't see how HTTP/2 does), what's the objection here? Nor is any smaller service provider forced to adopt it server-side.
  - CyberRabbi 6y ago
    The premise of my argument is that the end user is barely affected either way. There is potential harm to the web ecosystem by making the stack more complex and I am questioning the rationale for tolerating that harm is since these fundamental changes are being mostly driven by the specific use cases of large corporation, not the needs of the greater community. You’re right no one is forced to adopt this new web stack and for that I am grateful. Given recent events I will likely not adopt google’s web stack.
littlecranky67 6y ago
> so that a missed packet in one request doesn't slow down simultaneous requests This is already true for HTTP/1.1. The browser uses 6 parallel TCP connections to fetch resources, and a packet los in one of the TCP connections wouldn't stall the other ones. QUIC only fixes this for HTTP/2.0 which uses a single TCP connection with multiplexed HTTP streams; a single packet loss on the TCP level would stall all multiplexed streams on an OS level.
- M2Ys4U 6y ago
  But HTTP/1.1 using multiple TCP streams means that, where there are a lot of small requests, there's a lot of bandwidth left on the table because the TCP window never grows.
  - littlecranky67 6y ago
    Late with a reply, but want to note that this is not true. Most OSes scale tcp congestion control windows (snd_cwnd) based on the target IP, that is any increase of the window in any tcp connection to the same host increases the window for all open connections. Even if you close all connections, the kernel caches the last known window size for this host and re-uses this on subsequent connections for a given timeframe.

CyberRabbi 6y ago

You can open multiple tcp connections in parallel to virtually eliminate the head of line blocking problem for the vast majority of experiences. The problem has been exaggerated for the sake of justifying http2/3 but in practical terms it barely affects the average user experience. 80% optimal was good enough. On the other hand it reduces cost by a few percentage points for the vanishingly few web hosts large enough such that that would have a meaningful financial impact.

vhiremath4 6y ago
There is a cost to opening a new connection and having to re-incur multiple roundtrips in order to complete a new TCP and TLS handshake. This is a meaningful overhead savings for folks with a network setup that has high last-mile latency.
- CyberRabbi 6y ago
  As has been demonstrated by my original post, clearly saving a few rtt is irrelevant here. Anyway your point is halfway-irrelevant since if you initiate all connections in parallel you only suffer the rtt latency of a single connection. The only people saving here are the people running servers that serve world-scale numbers of requests. The average user notices nearly no difference.
  - alexchamberlain 6y ago
    The world-scale companies are also the companies writing the standards.
    - CyberRabbi 6y ago
      Funny that
  - vhiremath4 6y ago
    I'm not sure I fully follow here, but I would like to be able to. Created a video response: https://www.loom.com/share/4539869f41cf47c5a154a342308584de https://www.loom.com/share/4539869f41cf47c5a154a342308584de
    - CyberRabbi 6y ago
      Hehe I engage with people like that all the time and I think I’ve learned a lot. In my humble opinion the people who are easily offended aren’t really worth discussing difficult problems with. Actually I find that I learn a lot more from people who don’t get hung up when their ego happens to unintentionally get bruised. I think you need to reread my initial post in this thread. The importance of minimizing rtt blocking is acknowledged in my questioning of chrome’s decision to not implement http push.
      - vhiremath4 6y ago
        My ego is not bruised. As I said: > I'm not sure I fully follow here, but I would like to be able to What I'm calling out is that you may have fallen into the trap (as I did years back) that you need to be an asshole to drive towards solving hard problems. You don't, and it actually blocked me from creating the psychological safety necessary to get good ideas out of people who otherwise wouldn't feel comfortable speaking up. Genuinely good/supporting vibes from my direction to you - do with it what you will, but I do believe your ego is showing here more than mine. We can agree to disagree since I believe each of us will over-index on our past life experiences vs. those of some random person on Hacker News. > I think you need to reread my initial post in this thread. The importance of minimizing rtt blocking is acknowledged in my questioning of chrome’s decision to not implement http push. I think I get what you're saying, but honestly the way you're wording your points is a bit confusing. I am going to chalk this up to "I'm just too dumb" for sake of laziness at this point.
TwoBit 6y ago
Isn't part of the idea with HTTP2 that the server can see everything you're asking for and more intelligently prioritize vs a bunch of separate independent connections?
- CyberRabbi 6y ago
  I’m not aware of any open source servers that implement such an optimization and if proprietary software exists that does, it’s trivial to implement custom logic to do that across multiple connections as well.
  - jlokier 6y ago
    It's actually not trivial to optimize dynamic prioritisation across multiple connections. To keep a TCP efficient, the sending process needs to fill up the send buffer to a reasonable amount, generally by writing data to the kernel with write()/send(). If the sending process doesn't do this, the sending TCP will not send full frames as fast as the network or receiver allows, and do so at a steady cadence. But to prioritise the data flow of multiple responses across multiple connections, the sender needs to pause existing TCP flows in progress as soon as it has higher priority response data ready to send if the higher priority TCP will send at full rate. Yet if the higher priority TCP is sending slower than full rate temporarily due to slow start, congestion control or receive window full, etc., the lower priority TCP needs to be resumed just enough to fill the gaps. It's not even possible to do this with the ordinary sockets API, so it's certainly not trivial. With HTTP/2 and TCP in kernel, it's still not optimal because prioritised response data will be queued behind data already in the TCP send buffer, but at least there's only one send buffer's worth to compete with rather than lots. With HTTP/3 and QUIC in userspace, adaptive prioritisation can be optimised further because the decision is made on every packet just before it leaves the machine. Per-packet prioritisation would be possible in theory with HTTP/1 and HTTP/2 by implementing TCP in userspace, or by implementing HTTP in kernelspace, in either case tightly coupling TCP and HTTP. I don't know of anyone doing it, because it would be a lot of work for a marginal gain.
    - CyberRabbi 6y ago
raxxorrax 6y ago
But you would have to implement it on a layer that maybe should be exempt from dealing with network loading. I agree that the benefits only fit certain use cases, but it is still nice to have it and it is already widely adapted.
lxgr 6y ago
> vanishingly few web hosts large enough such that that would have a meaningful financial impact By that logic, electricity wasted on inefficient power adapters and devices in standby mode is irrelevant: The marginal savings per household are cents per year. If it doesn't hurt me as an end user (and I don't see how HTTP/2 does), what's the objection here? Nor is any smaller service provider forced to adopt it server-side.
- CyberRabbi 6y ago
  The premise of my argument is that the end user is barely affected either way. There is potential harm to the web ecosystem by making the stack more complex and I am questioning the rationale for tolerating that harm is since these fundamental changes are being mostly driven by the specific use cases of large corporation, not the needs of the greater community. You’re right no one is forced to adopt this new web stack and for that I am grateful. Given recent events I will likely not adopt google’s web stack.

littlecranky67 6y ago

> so that a missed packet in one request doesn't slow down simultaneous requests This is already true for HTTP/1.1. The browser uses 6 parallel TCP connections to fetch resources, and a packet los in one of the TCP connections wouldn't stall the other ones. QUIC only fixes this for HTTP/2.0 which uses a single TCP connection with multiplexed HTTP streams; a single packet loss on the TCP level would stall all multiplexed streams on an OS level.

M2Ys4U 6y ago
But HTTP/1.1 using multiple TCP streams means that, where there are a lot of small requests, there's a lot of bandwidth left on the table because the TCP window never grows.
- littlecranky67 6y ago
  Late with a reply, but want to note that this is not true. Most OSes scale tcp congestion control windows (snd_cwnd) based on the target IP, that is any increase of the window in any tcp connection to the same host increases the window for all open connections. Even if you close all connections, the kernel caches the last known window size for this host and re-uses this on subsequent connections for a given timeframe.