6 ms·

> HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. Satellite networks are not a good example. Regular HTTP/1.1, paired w

by otbutz 3y ago

> HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.

pi-e-sigma 3y ago
[flagged]
- jeltz 3y ago
  You will need to back up that accusation, because now you are accusing Daniel Stenberg of being a liar. On paper HTTP shouldperform much better than HTTP 1.1 and especially HTTP 2 on links with high packet loss since TCP handles packet loss very poorly. https://http3-explained.haxx.se/en/why-quic https://http3-explained.haxx.se/en/why-quic
  - pi-e-sigma 3y ago
    [flagged]
    - golebiewsky 3y ago
      I was actually curious why SACK's don't resolve issue, but according to https://stackoverflow.com/questions/67773211/why-do-tcp-selective-acks-not-prevent-hol-blocking-in-http-2 https://stackoverflow.com/questions/67773211/why-do-tcp-sele... > Even with selective ACK it is still necessary to get the missing data before forwarding the data stream to the application.
      - pi-e-sigma 3y ago
        Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.
        afiori 3y ago
        I am curious of why the kernel does not allow it; there could be an API that gives you fragments of the stream in "events" like {slice: [10000, 10100], data:<blob>} and let the application have a peak preview of future data
        brickteacup 3y ago
        Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its value proposition.
        pi-e-sigma 3y ago
        Except it doesn't work in practice and real world data proves it. Multiplexing streams inside of a single TCP connection don't magically make your data link less prone to dropped packets or high latency.
      - vasilvv 3y ago
        It's possible to build something similar on top of TCP, see Minion [0] for an example. There are multiple reasons why this is less practical than building on top of UDP, the main two being, from my perspective: (1) this requires cooperation from the OS (either in form of giving you advanced API or having high enough privilege level to write TCP manually), and (2) this falls apart in presence of TCP middleboxes. [0] https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/ https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/
      - avianlyric 3y ago
        Yes, TCP provides the guarantee that your application will always receive data in the same order it was sent. Your kernel will do the necessary buffering and packet reordering to provide that guarantee. So SACK might reduce packet resends, but it doesn’t prevent the latency hit that comes for having to waiting for the data went missing. Even if your application is capable of either handling out-of-order data, or is simply capable of handling missing data.
    - jeltz 3y ago
      That HTTP2 is the worst of the bunch is a given. But HTTP3 should on paper be able to handle packets loss better than HTTP1.1 and way better than HTTP2. And SACK does not seem to help under my real life workloads. Maybe poor implementations. I don't know.
      - pi-e-sigma 3y ago
        Just a few years ago HTTP2 was the best thing since sliced bread and any criticism was silenced. This begs the question if HTTP2 was so great then why did they come up with HTTP3? SACK is not a silver bullet because when you have high latency high loss link then nothing really helps. The difference is that HTTP2/3 folks like to deny reality and claim that they can do better when in fact they can't
        jeltz 3y ago
        I don't have high latency, I have high packet loss and high latency on some packets but most not. And that is something TCP cannot handle without breaking down totally but some UDP based protocols can handle it just fine. I don't know about HTTP3 though, that might also fail under those circumstances.
        pi-e-sigma 3y ago
        I suspect your case is not that the packets are simply dropped but that the TCP connections are reset. Lookup your TCP stack statistics to verify. If that's the case try to find out if the resets are made by your side, the source or the intermediaries.
    - kstrauser 3y ago
      > you folks just don't even bother to learn TCP first before shitting on it. Let me stop you right there. I promise you you're not the only person who really knows how TCP works. The people who made HTTP2 and HTTP3 are clearly smart, knowledge folks who have a different perspective than you do. It's OK to disagree with them, but it's a bad look for you to assume that they're ignorant on the subject.
      - pi-e-sigma 3y ago
        I didn't assume they are ignorant. I assumed that the are fraudulent. They knew they couldn't really improve existing protocols because it's simply not possible but moved forward anyway for personal gain. Just like everything from Google for the last 20 years. You make big splash with new and 'revolutionary' 6th version of instant messaging, get your promo and move on. And here we are, HTTP2 ran its course, time for HTTP3 because we need the promotions and the clout of 'innovators'
        ersamsa 3y ago
        Not to disagree but there is something to be learned from failing
        pi-e-sigma 3y ago
        They didn't fail. They got their promotions. It's you, the end user, who is left holding the bag. But fear not, HTTP3 is on the horizon and this time it's going to be glorious!
    - rstuart4133 3y ago
      > Also TCP handles packet loss just fine That's just plain wrong. I commented in more depth in https://news.ycombinator.com/item?id=39709591 https://news.ycombinator.com/item?id=39709591. In short, TCP treats packet loss as congestion signal and slows down. If the packet loss was due to congestion that's absolutely the correct response and it increases TCP's "goodput". But if the packet was lost due to noise then it has the opposite effect and goodput plummets to a fraction of what the link is capable of.
      - GoblinSlayer 3y ago
        In wireshark logs that I saw TCP almost immediately resends the lost packet and exponentially slows down after the resent packet is lost.
supriyo-biswas 3y ago
The specific thing they’re talking about connection migration (and resumption) through multiple disconnection events — HTTP/1 and 2 do not offer a similar feature.
deleted 3y ago
[deleted]

by otbutz 3y ago

pi-e-sigma 3y ago

[flagged]

jeltz 3y ago
You will need to back up that accusation, because now you are accusing Daniel Stenberg of being a liar. On paper HTTP shouldperform much better than HTTP 1.1 and especially HTTP 2 on links with high packet loss since TCP handles packet loss very poorly. https://http3-explained.haxx.se/en/why-quic https://http3-explained.haxx.se/en/why-quic
- pi-e-sigma 3y ago
  [flagged]
  - golebiewsky 3y ago
    I was actually curious why SACK's don't resolve issue, but according to https://stackoverflow.com/questions/67773211/why-do-tcp-selective-acks-not-prevent-hol-blocking-in-http-2 https://stackoverflow.com/questions/67773211/why-do-tcp-sele... > Even with selective ACK it is still necessary to get the missing data before forwarding the data stream to the application.
    - pi-e-sigma 3y ago
      Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.
      - afiori 3y ago
        I am curious of why the kernel does not allow it; there could be an API that gives you fragments of the stream in "events" like {slice: [10000, 10100], data:<blob>} and let the application have a peak preview of future data
      - brickteacup 3y ago
        Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its value proposition.
        pi-e-sigma 3y ago
        Except it doesn't work in practice and real world data proves it. Multiplexing streams inside of a single TCP connection don't magically make your data link less prone to dropped packets or high latency.
    - vasilvv 3y ago
      It's possible to build something similar on top of TCP, see Minion [0] for an example. There are multiple reasons why this is less practical than building on top of UDP, the main two being, from my perspective: (1) this requires cooperation from the OS (either in form of giving you advanced API or having high enough privilege level to write TCP manually), and (2) this falls apart in presence of TCP middleboxes. [0] https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/ https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/
    - avianlyric 3y ago
      Yes, TCP provides the guarantee that your application will always receive data in the same order it was sent. Your kernel will do the necessary buffering and packet reordering to provide that guarantee. So SACK might reduce packet resends, but it doesn’t prevent the latency hit that comes for having to waiting for the data went missing. Even if your application is capable of either handling out-of-order data, or is simply capable of handling missing data.
  - jeltz 3y ago
    That HTTP2 is the worst of the bunch is a given. But HTTP3 should on paper be able to handle packets loss better than HTTP1.1 and way better than HTTP2. And SACK does not seem to help under my real life workloads. Maybe poor implementations. I don't know.
    - pi-e-sigma 3y ago
      Just a few years ago HTTP2 was the best thing since sliced bread and any criticism was silenced. This begs the question if HTTP2 was so great then why did they come up with HTTP3? SACK is not a silver bullet because when you have high latency high loss link then nothing really helps. The difference is that HTTP2/3 folks like to deny reality and claim that they can do better when in fact they can't
      - jeltz 3y ago
        I don't have high latency, I have high packet loss and high latency on some packets but most not. And that is something TCP cannot handle without breaking down totally but some UDP based protocols can handle it just fine. I don't know about HTTP3 though, that might also fail under those circumstances.
        pi-e-sigma 3y ago
        I suspect your case is not that the packets are simply dropped but that the TCP connections are reset. Lookup your TCP stack statistics to verify. If that's the case try to find out if the resets are made by your side, the source or the intermediaries.
  - kstrauser 3y ago
    > you folks just don't even bother to learn TCP first before shitting on it. Let me stop you right there. I promise you you're not the only person who really knows how TCP works. The people who made HTTP2 and HTTP3 are clearly smart, knowledge folks who have a different perspective than you do. It's OK to disagree with them, but it's a bad look for you to assume that they're ignorant on the subject.
    - pi-e-sigma 3y ago
      I didn't assume they are ignorant. I assumed that the are fraudulent. They knew they couldn't really improve existing protocols because it's simply not possible but moved forward anyway for personal gain. Just like everything from Google for the last 20 years. You make big splash with new and 'revolutionary' 6th version of instant messaging, get your promo and move on. And here we are, HTTP2 ran its course, time for HTTP3 because we need the promotions and the clout of 'innovators'
      - ersamsa 3y ago
        Not to disagree but there is something to be learned from failing
        pi-e-sigma 3y ago
        They didn't fail. They got their promotions. It's you, the end user, who is left holding the bag. But fear not, HTTP3 is on the horizon and this time it's going to be glorious!
  - rstuart4133 3y ago
    > Also TCP handles packet loss just fine That's just plain wrong. I commented in more depth in https://news.ycombinator.com/item?id=39709591 https://news.ycombinator.com/item?id=39709591. In short, TCP treats packet loss as congestion signal and slows down. If the packet loss was due to congestion that's absolutely the correct response and it increases TCP's "goodput". But if the packet was lost due to noise then it has the opposite effect and goodput plummets to a fraction of what the link is capable of.
    - GoblinSlayer 3y ago
      In wireshark logs that I saw TCP almost immediately resends the lost packet and exponentially slows down after the resent packet is lost.

supriyo-biswas 3y ago

The specific thing they’re talking about connection migration (and resumption) through multiple disconnection events — HTTP/1 and 2 do not offer a similar feature.

deleted 3y ago

[deleted]