4 ms·

Do we need HTTP/3?

by hl05 5y ago

Do we need HTTP/3?

ng55QPSK 5y ago
The google thinks so.
bawolff 5y ago
We don't need anything. Like any technology it has pros and cons. The pro side being it improves performance for users with certain network conditions.
ardit33 5y ago
No... it is just a nice to have for some large sites. For most HTTP/1.1 is still good enough
jeltz 5y ago
For unreliable networks we do need it. TCP has always performed poorly when there is a lot of packet loss.
- mobilemidget 5y ago
  My personal opinion would prefer to improve those networks vs going UDP for http(s). Until spoofing, amplification attacks on UDP are properly tackled and not causing most internet outages, I'm not really looking forward to a UDP web (http/3)
  - viraptor 5y ago
    Does http3 have a problem with amplification on the first answer packet? I'm not sure spoofing is something transport protocols have to solve though. Authenticated bgp and source filtering is the layer for it and we needed it for decades already.
    - Vecr 5y ago
      If I remember the amplification is about 3x, you need acks for the server to send more than that.
  - serendipitous 5y ago
    > Until spoofing, amplification attacks on UDP are properly tackled This is already addressed by QUIC (the transport protocol used by HTTP/3). Those things are no more of a problem for HTTP/3 than they are for HTTP/2 or HTTP/1.
- midasuni 5y ago
  Wasn’t that the whole reason behind improved congestion algorithms like bbr which no longer assumed minor packet loss was the sign of congestion?
- wahern 5y ago
  That all depends on the congestion control algorithm. Different implementations of TCP can use different algorithms while still being compatible. The same is true of QUIC. The recently published QUIC standard specifies a tweaked version of TCP NewReno. See https://www.rfc-editor.org/rfc/rfc9002.txt https://www.rfc-editor.org/rfc/rfc9002.txt and https://datatracker.ietf.org/doc/html/rfc6582 https://datatracker.ietf.org/doc/html/rfc6582 But AFAIU this is not the algorithm Google itself uses for QUIC, nor the one they used for their famous benchmarks showing latency improvements on mobile. To derive maximum benefit (or even just most of the benefit) of a tailored congestion control algorithm, you'll want to control both sides, keeping them in sync as you iterate improvements and changes. And maintain different flavors for different application environments. Only huge companies like Google and Facebook will be able to do this effectively.
  - kevincox 5y ago
    QUIC does have more than just different congestion control For example it has forward error correction which can be very important for lossy connections. There are other improvements that can't really be added to TCP either such as roaming between IP addresses. (MPTCP exists but IIUC requires make-before-break which is not always possible).
vbezhenar 5y ago
I have the opinion that we don't need anything past HTTP/1.1 on 3G internet. Anything better is a luxury which is not necessary. But that's my threshold of comfort.
- weird-eye-issue 5y ago
  How long does it take to fully load the average web page over 3G?
  - vbezhenar 5y ago
    I don't know about average web pages, but websites that I use regularly are loading quite fast. 3G in my village is something around 10 Mbits/s, youtube is absolutely fine, for example. PS may be it's not strictly 3G, but it's displayed as 3G on my phone.
    - weird-eye-issue 5y ago
      According to Google, 3G is generally limited to 3Mbps in practice (7Mbps in theory) so I think you might be getting lucky
- bullen 5y ago
  You would be right if 3G didn't jump down to 2G randomly, 4G does not have this flaw, 5G is meaningless. HTTP/1.1 is the final transport for humanity, but you need fiber (external IP, preferably static, but operators/governements are not helping) to sell something. HTTP/2 has head of line blocking issue. HTTP/3 wont become a standard outside of biased actors like Google.
  - rapsey 5y ago
    Http3 works or will work soon in major browsers and cdn's. It will cary a large chunk of internet traffic.
  - chrismorgan 5y ago
    A lot of the world has killed off 2G (e.g. in Australia it all got shut down 3–5 years ago), and it’s on the chopping block in a lot of the rest of the world (e.g. looks like the remaining 2G services in the USA goes EOL by the end of next year). 3G is also already on the chopping block in many places (e.g. looks like next year in the USA, and in Australia its spectrum has steadily been being reallocated in recent years, and the biggest telco is scheduled to kill it altogether in 2024). Fortunately after that it’s designed in compatible ways, so 4G and 5G and whatever comes after that can all coexist. For the HTTP versions, I’d put it more this way: HTTP/1.1 is the baseline that will continue to work forever. HTTP/2 is normally a significant improvement over HTTP/1.1, but it has one crucial flaw which makes it worse than the alternative of half a dozen HTTP/1.1 connections on connections with high packet loss. HTTP/3 is the best of both worlds, roundly better than HTTP/1 and HTTP/2, but because it’s using UDP, it’ll have some teething issues for a few years because of badly-configured corporate equipment. But it will become widely supported in server software—there’s no reason for it not to.

Do we need HTTP/3?

by hl05 5y ago

Do we need HTTP/3?

ng55QPSK 5y ago

The google thinks so.

bawolff 5y ago

We don't need anything. Like any technology it has pros and cons. The pro side being it improves performance for users with certain network conditions.

ardit33 5y ago

No... it is just a nice to have for some large sites. For most HTTP/1.1 is still good enough

jeltz 5y ago

For unreliable networks we do need it. TCP has always performed poorly when there is a lot of packet loss.

mobilemidget 5y ago
My personal opinion would prefer to improve those networks vs going UDP for http(s). Until spoofing, amplification attacks on UDP are properly tackled and not causing most internet outages, I'm not really looking forward to a UDP web (http/3)
- viraptor 5y ago
  Does http3 have a problem with amplification on the first answer packet? I'm not sure spoofing is something transport protocols have to solve though. Authenticated bgp and source filtering is the layer for it and we needed it for decades already.
  - Vecr 5y ago
    If I remember the amplification is about 3x, you need acks for the server to send more than that.
- serendipitous 5y ago
  > Until spoofing, amplification attacks on UDP are properly tackled This is already addressed by QUIC (the transport protocol used by HTTP/3). Those things are no more of a problem for HTTP/3 than they are for HTTP/2 or HTTP/1.
midasuni 5y ago
Wasn’t that the whole reason behind improved congestion algorithms like bbr which no longer assumed minor packet loss was the sign of congestion?
wahern 5y ago
That all depends on the congestion control algorithm. Different implementations of TCP can use different algorithms while still being compatible. The same is true of QUIC. The recently published QUIC standard specifies a tweaked version of TCP NewReno. See https://www.rfc-editor.org/rfc/rfc9002.txt https://www.rfc-editor.org/rfc/rfc9002.txt and https://datatracker.ietf.org/doc/html/rfc6582 https://datatracker.ietf.org/doc/html/rfc6582 But AFAIU this is not the algorithm Google itself uses for QUIC, nor the one they used for their famous benchmarks showing latency improvements on mobile. To derive maximum benefit (or even just most of the benefit) of a tailored congestion control algorithm, you'll want to control both sides, keeping them in sync as you iterate improvements and changes. And maintain different flavors for different application environments. Only huge companies like Google and Facebook will be able to do this effectively.
- kevincox 5y ago
  QUIC does have more than just different congestion control For example it has forward error correction which can be very important for lossy connections. There are other improvements that can't really be added to TCP either such as roaming between IP addresses. (MPTCP exists but IIUC requires make-before-break which is not always possible).

vbezhenar 5y ago

I have the opinion that we don't need anything past HTTP/1.1 on 3G internet. Anything better is a luxury which is not necessary. But that's my threshold of comfort.

weird-eye-issue 5y ago
How long does it take to fully load the average web page over 3G?
- vbezhenar 5y ago
  I don't know about average web pages, but websites that I use regularly are loading quite fast. 3G in my village is something around 10 Mbits/s, youtube is absolutely fine, for example. PS may be it's not strictly 3G, but it's displayed as 3G on my phone.
  - weird-eye-issue 5y ago
    According to Google, 3G is generally limited to 3Mbps in practice (7Mbps in theory) so I think you might be getting lucky
bullen 5y ago
You would be right if 3G didn't jump down to 2G randomly, 4G does not have this flaw, 5G is meaningless. HTTP/1.1 is the final transport for humanity, but you need fiber (external IP, preferably static, but operators/governements are not helping) to sell something. HTTP/2 has head of line blocking issue. HTTP/3 wont become a standard outside of biased actors like Google.
- rapsey 5y ago
  Http3 works or will work soon in major browsers and cdn's. It will cary a large chunk of internet traffic.
- chrismorgan 5y ago
  A lot of the world has killed off 2G (e.g. in Australia it all got shut down 3–5 years ago), and it’s on the chopping block in a lot of the rest of the world (e.g. looks like the remaining 2G services in the USA goes EOL by the end of next year). 3G is also already on the chopping block in many places (e.g. looks like next year in the USA, and in Australia its spectrum has steadily been being reallocated in recent years, and the biggest telco is scheduled to kill it altogether in 2024). Fortunately after that it’s designed in compatible ways, so 4G and 5G and whatever comes after that can all coexist. For the HTTP versions, I’d put it more this way: HTTP/1.1 is the baseline that will continue to work forever. HTTP/2 is normally a significant improvement over HTTP/1.1, but it has one crucial flaw which makes it worse than the alternative of half a dozen HTTP/1.1 connections on connections with high packet loss. HTTP/3 is the best of both worlds, roundly better than HTTP/1 and HTTP/2, but because it’s using UDP, it’ll have some teething issues for a few years because of badly-configured corporate equipment. But it will become widely supported in server software—there’s no reason for it not to.