5 ms·

I don't think this article was very good and seems to be written by someone that doesn't really know what they're talking about, or by someone that does but "du

I don't think this article was very good and seems to be written by someone that doesn't really know what they're talking about, or by someone that does but "dumbed down" to a degree where it's conclusion inaccurate. I think HTTP3 is probably doomed for a IPv6 like existence for a long while. While everyone claims that TCP is apparently "too slow", the vast majority of corporate/enterprise settings will just block it. It seems like a technology built by the big players who want to shave a few cycles off each connection and save $millions rather than a practical standard. Do I want to use HTTP3 at home? Yeah, sounds cool. Will I be able to use it at work? Probably not for 5+ years.

api 3y ago
HTTP3 doesn't have the same chicken-or-egg problem as IPv6. It runs over UDP. IPv6 is a full protocol rev which takes a lot longer to accomplish. Once a large multi-vendor network is deployed revving the base protocol is really hard.
- ronsor 3y ago
  Not to mention the companies backing it are so large and critical they can simply mandate it and enterprises will just have to deal with it, somehow.
  - londons_explore 3y ago
    so far, there is no reason to mandate http/3. There is barely any infrastructure cost to running a dual HTTP/1.1 and HTTP/3 setup. And the two are so similar to application developers that there is no reason to mandate anyone move over. However... It only takes one killer feature not compatible with HTTP/1.1 (eg. realtime VR with a stream per eye, and it turns out HTTP/1.1 can't do realtime bidirectional streams), and suddenly everyone will start turning off HTTP/1.1 services and replacing it with a page saying "please upgrade your web browser".
  - api 3y ago
    That part is great. It uses UDP, which means it helps prevent UDP from being sidelined or blocked by middleboxes. That in turn helps prevent the Internet from becoming a de-facto HTTP-only network, which was a trend that was kind of happening in the 20-teens and had me concerned.
    - apitman 3y ago
      I agree, I just hope we don't see the opposite problem happen where we end up in a world where HTTP/1.1 over TCP goes away. I implemented a HTTP/1.1 server with range request support in JavaScript in a few hours last week. It's incomplete and likely rather insecure, but it works with curl and browsers. There's something important about having this ability.
      - api 3y ago
        HTTP/1.1 going away is less likely than IPv4 going away.
- Spivak 3y ago
  Yeah but > Palo Alto Networks recommends creating a security policy in the firewall to block the QUIC application. With the QUIC traffic getting blocked by the Firewall, the Chrome browser will fall back to using traditional TLS/SSL. Note that this will not cause the user to lose any functionality on their browser. Firewall gains better visibility and control of Google applications with or without the SSL decryption enabled. https://docs.paloaltonetworks.com/best-practices/10-2/decryption-best-practices/decryption-best-practices/deploy-ssl-decryption-using-best-practices https://docs.paloaltonetworks.com/best-practices/10-2/decryp... https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?... Fortinet also recommends blocking it. > However, due to the protocol is still in an experimental stage, it is not supported by Fortinet and causes some issues when SSL inspection profiles are needed to block specific websites or applications provided by Google itself. https://community.fortinet.com/t5/FortiGate/Technical-Note-Disabling-Blocking-QUIC-Protocol-to-force-Google/ta-p/191657?externalId=FD36529 https://community.fortinet.com/t5/FortiGate/Technical-Note-D... And given how trivial and likely udp/443 is already blocked because the only reason prior to QUIC you would be hitting udp/443 is some malware trying to get past the firewall and hoping it's open without inspection turned on you're fighting an uphill battle.
  - b112 3y ago
    Is this the same Fortinet that just did a stock pump by releasing fake news stories about toothbrush DDoS attacks?: https://www.forbes.com/sites/daveywinder/2024/02/08/surprising-3-million-hacked-toothbrushes-story-goes-viral-is-it-true/?sh=fbeead26147d https://www.forbes.com/sites/daveywinder/2024/02/08/surprisi... I wonder how valid their claims are for anything, if they just make up things for press and publicity.
    - miohtama 3y ago
      Do I need a Fortinet firewall for my tooth brush?
- apitman 3y ago
  > IPv6 is a full protocol rev which takes a lot longer to accomplish And maybe will never happen. There are alternatives for a lot of what you get from IPv6, such as NAT (terrible but works for most people's needs) and SNI routing (I'm more bullish on this). Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful.
  - bombcar 3y ago
    > Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful. There are quite a few, but people probably haven't heard of them, because either they were involved below the Internet (think: physical links) or were used for things like telephony or other interconnects. There are also other interfaces that involve communication but aren't Internet or telephone like (think things like ic2 or canbus, etc).
  - dehrmann 3y ago
    If it's still not adopted more in 5-10 years, I wonder if they'll make what everyone wanted all along: IPv4 with longer addresses.
    - Thiez 3y ago
      That would be absurd. Why introduce a completely new protocol with 0 hardware or software support? Who would possibly adopt this over IPv6?
      - hot_gril 3y ago
        It would be possible to do basically this with the existing IPv6 header and much of the v6 infra. All existing IPv4 hosts get the same /32 on v6, and any NATs stay intact. On the UI side, keep the ipv4 address format like 8.8.8.8. Going to V6 is very low-risk, low-impact this way. V4 packets can even be converted to V6 and vice versa because it's the same address space at first. Once there's sufficient adoption of V6, individual network operators can break things up into /40, /48, etc if needed, which wouldn't be reachable via V4 anymore*. Back to UI, a /40 would look like 8.8.8.8.4. Unlike today's v6 which is a totally separate network with new routes and randomized addresses. It also has v6-mapped-v4 addresses, but that's different. * If you really want some more temporary compatibility, /40 would still be sorta reachable from V4 if you added a special kind of NAT that encodes the extra 8 address bits into the port number, but idk if that'd be palatable.
- simiones 3y ago
  Even if HTTP/3 had gone the route of registering QUIC as a new transport protocol instead of UDP, I think it would have still been at least one or two orders of magnitude easier to deploy than IPv6 was (though still much harder than going over UDP is, I'm not suggesting this was a bad choice in any way!). They would have had problems with kernel updates and with devices that make assumptions and more paranoid security policies, but they would have probably been able to convince most people to allow their packets to flow after a few years. Changing IPv6 is a much more fundamental change to the Internet as a whole.
  - lxgr 3y ago
    I think assigning a new IP protocol number would have made QUIC a complete non-starter, and for almost no benefit compared to just encapsulating it in UDP. That's why WebRTC encapsulates SCTP (for data connections) in UDP, why ESP (for IPsec) is encapsulated in UDP etc. > they would have probably been able to convince most people to allow their packets to flow after a few years Looking at all these stateful NATs in network cabinets that nobody has looked at for years, I highly, highly doubt it.
- deleted 3y ago
  [deleted]
- hot_gril 3y ago
  I'm annoyed that the comment above yours dismisses the entire article based on the false assumption that QUIC is its own L4 protocol. I was fooled for a second, then I actually read the article, where it clearly says QUIC runs over UDP. So there's no chicken-and-egg.
  - wmf 3y ago
    A lot of firewalls are blocking UDP and unknown L4 protocols so QUIC is blocked either way. QUIC can only work because happy eyeballs falls back to HTTP/2. UDP is definitely better for NATs since they don't know how to translate unknown protocols (e.g. SCTP).
    - hot_gril 3y ago
      Which firewalls are broadly blocking UDP? I haven't seen that on a residential router or ISP. Lots of things rely on UDP already.
      - wmf 3y ago
        Corporate firewalls tend to be much more restrictive than consumer.
        hot_gril 3y ago
        Yeah, if it's just corporate falling back to HTTP2 (or maybe more realistically, HTTP1), then I think it's alright. Same corporate users delayed leaving unencrypted HTTP, broken versions of TLS, Windows XP, etc yet everyone else adopted anyway. They'll either follow suit eventually or work around it.
01HNNWZ0MV43FF 3y ago
If you use Chromium or Firefox, you may have used HTTP/3 and not realized. It happened to me! https://ifconfig.net/ https://ifconfig.net/ uses HTTP/3 by virtue of Cloudflare's proxy using it. I'm on Firefox 115, half a year old, and the network inspector says I connect to ifconfig over HTTP/3. The rollout's been really smooth and quiet. Browsers do the same "happy eyeballs" optimization as they did for HTTP/2 and SPDY, racing QUIC with TCP and using which-ever one connects first, or maybe dropping TCP if QUIC connects a couple milliseconds later. Hell, CF actually rolled out HTTP/3 before the pandemic, in 2019 https://blog.cloudflare.com/http3-the-past-present-and-future/ https://blog.cloudflare.com/http3-the-past-present-and-futur...
jeroenhd 3y ago
HTTP3 works fine. It's used by Cloudflare, which (unfortunately) means that half the websites you visit probably use it. It's available in nginx, caddy, and a bunch of other servers. Sure, most servers will just support the protocol at the reverse proxy level and lack the optimisations that make HTTP3 faster for the big cloud providers that stand to gain most, but you can just set up HTTP3 on your own server if you want. I don't know what you're using at work that prevents you from using HTTP3. I'm guessing you're referring to one of those awful middleboxes or some kind of firewall that blocks outgoing UDP traffic. Luckily, that stuff isn't relevant for most connections on the internet.
- williamcotton 3y ago
  If you put an HTTP3 nginx server in front of HTTP1 applications you get a lot of the UX benefits… parallel requests that make bundling, and to an extent tools like GraphQL and Falcon, somewhat obsolete and in turn applications much less complicated.
mike_hock 3y ago
Yes, it saves server resources at extreme scales. The client-side savings are purely theoretical. If their JS bloatware crap takes 2s to respond to a click, the 3x 30ms network roundtrip to fetch a resource with a new HTTPS connection hardly matters.
foobiekr 3y ago
ipv6 is very, very widely deployed in mobile networks. Download some net tools and check out your phone's interface table. Also v6 did a bunch of things right. NDP and link local addresses for v6 actually work. The fragmentation changes were 100% the right thing to do. v6 extensions like SR and uSID are both solid and consolidate a lot of stupid stuff into something clean. v6 had a bad, rocky start. A lot of that was completely inadequate attention to the transition, and the vendors fucked up almost everything for years, on their own gear and interop, but at this point v6 is fine. Would I launch a v6 only service? No, because at this point the SPs are the problem. Verizon as of a few years ago and maybe now still didn't do v6 to any of their home users. So many things like that.
- lxgr 3y ago
  > Verizon as of a few years ago and maybe now still didn't do v6 to any of their home users. So many things like that. My FIOS home connection has had IPv6 since some time last year. Consumer ISPs are actually quite motivated to offer IPv6 since it gives them a path forward without an IPv4 address per customer better than CG-NAT. Many consumers also just use their ISP's CPE, which makes this shift easier as well. I think the bigger obstacle will be managed corporate connections (for Wi-Fi or other client access connectivity) that are only upgraded once every few years and just don't support IPv6.
- unethical_ban 3y ago
  I finally got IPv6 working on my home network this week. /60 prefix from the ISP, Slaac with PD for addresses, RA for DNS, unbound DNS working just fine. OPNsense works great! This is something I've wanted to get working for years.
- hot_gril 3y ago
  Ipv6 isn't just an upgraded protocol over ipv4. It could've been, but it's not. It's a totally separate network with its own routing. So just changing all hardware along the way to support ipv6 doesn't mean it's adopted.
  - doublepg23 3y ago
unethical_ban 3y ago
The write that the tcp three way handshake is syn-ack-synack. I don't trust it.
deleted 3y ago
[deleted]
1vuio0pswjnm7 3y ago
HTTP/3 may have good speed for webpages that trigger many HTTP requests to source ads and support tracking/telemetry from multiple, disparate servers controlled by different entitites. (Makes sense since HTTP/3 was designed by an advertising company.) But HTTP/3 speed is not any better than HTTP/1.1 speed for downloading a file or a series of files from the same server in a single TCP connection. Some have said it's worse. (HTTP/1.1 was not designed by an advertising company so if it sucks for ads/tracking/telemetry then that makes perfect sense.)
- 1vuio0pswjnm7 3y ago
  https://news.ycombinator.com/item?id=39164152 https://news.ycombinator.com/item?id=39164152

api 3y ago

HTTP3 doesn't have the same chicken-or-egg problem as IPv6. It runs over UDP. IPv6 is a full protocol rev which takes a lot longer to accomplish. Once a large multi-vendor network is deployed revving the base protocol is really hard.

ronsor 3y ago
Not to mention the companies backing it are so large and critical they can simply mandate it and enterprises will just have to deal with it, somehow.
- londons_explore 3y ago
  so far, there is no reason to mandate http/3. There is barely any infrastructure cost to running a dual HTTP/1.1 and HTTP/3 setup. And the two are so similar to application developers that there is no reason to mandate anyone move over. However... It only takes one killer feature not compatible with HTTP/1.1 (eg. realtime VR with a stream per eye, and it turns out HTTP/1.1 can't do realtime bidirectional streams), and suddenly everyone will start turning off HTTP/1.1 services and replacing it with a page saying "please upgrade your web browser".
- api 3y ago
  That part is great. It uses UDP, which means it helps prevent UDP from being sidelined or blocked by middleboxes. That in turn helps prevent the Internet from becoming a de-facto HTTP-only network, which was a trend that was kind of happening in the 20-teens and had me concerned.
  - apitman 3y ago
    I agree, I just hope we don't see the opposite problem happen where we end up in a world where HTTP/1.1 over TCP goes away. I implemented a HTTP/1.1 server with range request support in JavaScript in a few hours last week. It's incomplete and likely rather insecure, but it works with curl and browsers. There's something important about having this ability.
    - api 3y ago
      HTTP/1.1 going away is less likely than IPv4 going away.
Spivak 3y ago
Yeah but > Palo Alto Networks recommends creating a security policy in the firewall to block the QUIC application. With the QUIC traffic getting blocked by the Firewall, the Chrome browser will fall back to using traditional TLS/SSL. Note that this will not cause the user to lose any functionality on their browser. Firewall gains better visibility and control of Google applications with or without the SSL decryption enabled. https://docs.paloaltonetworks.com/best-practices/10-2/decryption-best-practices/decryption-best-practices/deploy-ssl-decryption-using-best-practices https://docs.paloaltonetworks.com/best-practices/10-2/decryp... https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?... Fortinet also recommends blocking it. > However, due to the protocol is still in an experimental stage, it is not supported by Fortinet and causes some issues when SSL inspection profiles are needed to block specific websites or applications provided by Google itself. https://community.fortinet.com/t5/FortiGate/Technical-Note-Disabling-Blocking-QUIC-Protocol-to-force-Google/ta-p/191657?externalId=FD36529 https://community.fortinet.com/t5/FortiGate/Technical-Note-D... And given how trivial and likely udp/443 is already blocked because the only reason prior to QUIC you would be hitting udp/443 is some malware trying to get past the firewall and hoping it's open without inspection turned on you're fighting an uphill battle.
- b112 3y ago
  Is this the same Fortinet that just did a stock pump by releasing fake news stories about toothbrush DDoS attacks?: https://www.forbes.com/sites/daveywinder/2024/02/08/surprising-3-million-hacked-toothbrushes-story-goes-viral-is-it-true/?sh=fbeead26147d https://www.forbes.com/sites/daveywinder/2024/02/08/surprisi... I wonder how valid their claims are for anything, if they just make up things for press and publicity.
  - miohtama 3y ago
    Do I need a Fortinet firewall for my tooth brush?
apitman 3y ago
> IPv6 is a full protocol rev which takes a lot longer to accomplish And maybe will never happen. There are alternatives for a lot of what you get from IPv6, such as NAT (terrible but works for most people's needs) and SNI routing (I'm more bullish on this). Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful.
- bombcar 3y ago
  > Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful. There are quite a few, but people probably haven't heard of them, because either they were involved below the Internet (think: physical links) or were used for things like telephony or other interconnects. There are also other interfaces that involve communication but aren't Internet or telephone like (think things like ic2 or canbus, etc).
- dehrmann 3y ago
  If it's still not adopted more in 5-10 years, I wonder if they'll make what everyone wanted all along: IPv4 with longer addresses.
  - Thiez 3y ago
    That would be absurd. Why introduce a completely new protocol with 0 hardware or software support? Who would possibly adopt this over IPv6?
    - hot_gril 3y ago
      It would be possible to do basically this with the existing IPv6 header and much of the v6 infra. All existing IPv4 hosts get the same /32 on v6, and any NATs stay intact. On the UI side, keep the ipv4 address format like 8.8.8.8. Going to V6 is very low-risk, low-impact this way. V4 packets can even be converted to V6 and vice versa because it's the same address space at first. Once there's sufficient adoption of V6, individual network operators can break things up into /40, /48, etc if needed, which wouldn't be reachable via V4 anymore*. Back to UI, a /40 would look like 8.8.8.8.4. Unlike today's v6 which is a totally separate network with new routes and randomized addresses. It also has v6-mapped-v4 addresses, but that's different. * If you really want some more temporary compatibility, /40 would still be sorta reachable from V4 if you added a special kind of NAT that encodes the extra 8 address bits into the port number, but idk if that'd be palatable.
simiones 3y ago
Even if HTTP/3 had gone the route of registering QUIC as a new transport protocol instead of UDP, I think it would have still been at least one or two orders of magnitude easier to deploy than IPv6 was (though still much harder than going over UDP is, I'm not suggesting this was a bad choice in any way!). They would have had problems with kernel updates and with devices that make assumptions and more paranoid security policies, but they would have probably been able to convince most people to allow their packets to flow after a few years. Changing IPv6 is a much more fundamental change to the Internet as a whole.
- lxgr 3y ago
  I think assigning a new IP protocol number would have made QUIC a complete non-starter, and for almost no benefit compared to just encapsulating it in UDP. That's why WebRTC encapsulates SCTP (for data connections) in UDP, why ESP (for IPsec) is encapsulated in UDP etc. > they would have probably been able to convince most people to allow their packets to flow after a few years Looking at all these stateful NATs in network cabinets that nobody has looked at for years, I highly, highly doubt it.
deleted 3y ago
[deleted]
hot_gril 3y ago
I'm annoyed that the comment above yours dismisses the entire article based on the false assumption that QUIC is its own L4 protocol. I was fooled for a second, then I actually read the article, where it clearly says QUIC runs over UDP. So there's no chicken-and-egg.
- wmf 3y ago
  A lot of firewalls are blocking UDP and unknown L4 protocols so QUIC is blocked either way. QUIC can only work because happy eyeballs falls back to HTTP/2. UDP is definitely better for NATs since they don't know how to translate unknown protocols (e.g. SCTP).
  - hot_gril 3y ago
    Which firewalls are broadly blocking UDP? I haven't seen that on a residential router or ISP. Lots of things rely on UDP already.
    - wmf 3y ago
      Corporate firewalls tend to be much more restrictive than consumer.
      - hot_gril 3y ago
        Yeah, if it's just corporate falling back to HTTP2 (or maybe more realistically, HTTP1), then I think it's alright. Same corporate users delayed leaving unencrypted HTTP, broken versions of TLS, Windows XP, etc yet everyone else adopted anyway. They'll either follow suit eventually or work around it.

01HNNWZ0MV43FF 3y ago

If you use Chromium or Firefox, you may have used HTTP/3 and not realized. It happened to me! https://ifconfig.net/ https://ifconfig.net/ uses HTTP/3 by virtue of Cloudflare's proxy using it. I'm on Firefox 115, half a year old, and the network inspector says I connect to ifconfig over HTTP/3. The rollout's been really smooth and quiet. Browsers do the same "happy eyeballs" optimization as they did for HTTP/2 and SPDY, racing QUIC with TCP and using which-ever one connects first, or maybe dropping TCP if QUIC connects a couple milliseconds later. Hell, CF actually rolled out HTTP/3 before the pandemic, in 2019 https://blog.cloudflare.com/http3-the-past-present-and-future/ https://blog.cloudflare.com/http3-the-past-present-and-futur...

jeroenhd 3y ago

HTTP3 works fine. It's used by Cloudflare, which (unfortunately) means that half the websites you visit probably use it. It's available in nginx, caddy, and a bunch of other servers. Sure, most servers will just support the protocol at the reverse proxy level and lack the optimisations that make HTTP3 faster for the big cloud providers that stand to gain most, but you can just set up HTTP3 on your own server if you want. I don't know what you're using at work that prevents you from using HTTP3. I'm guessing you're referring to one of those awful middleboxes or some kind of firewall that blocks outgoing UDP traffic. Luckily, that stuff isn't relevant for most connections on the internet.

williamcotton 3y ago
If you put an HTTP3 nginx server in front of HTTP1 applications you get a lot of the UX benefits… parallel requests that make bundling, and to an extent tools like GraphQL and Falcon, somewhat obsolete and in turn applications much less complicated.

mike_hock 3y ago

Yes, it saves server resources at extreme scales. The client-side savings are purely theoretical. If their JS bloatware crap takes 2s to respond to a click, the 3x 30ms network roundtrip to fetch a resource with a new HTTPS connection hardly matters.

foobiekr 3y ago

ipv6 is very, very widely deployed in mobile networks. Download some net tools and check out your phone's interface table. Also v6 did a bunch of things right. NDP and link local addresses for v6 actually work. The fragmentation changes were 100% the right thing to do. v6 extensions like SR and uSID are both solid and consolidate a lot of stupid stuff into something clean. v6 had a bad, rocky start. A lot of that was completely inadequate attention to the transition, and the vendors fucked up almost everything for years, on their own gear and interop, but at this point v6 is fine. Would I launch a v6 only service? No, because at this point the SPs are the problem. Verizon as of a few years ago and maybe now still didn't do v6 to any of their home users. So many things like that.

lxgr 3y ago
> Verizon as of a few years ago and maybe now still didn't do v6 to any of their home users. So many things like that. My FIOS home connection has had IPv6 since some time last year. Consumer ISPs are actually quite motivated to offer IPv6 since it gives them a path forward without an IPv4 address per customer better than CG-NAT. Many consumers also just use their ISP's CPE, which makes this shift easier as well. I think the bigger obstacle will be managed corporate connections (for Wi-Fi or other client access connectivity) that are only upgraded once every few years and just don't support IPv6.
unethical_ban 3y ago
I finally got IPv6 working on my home network this week. /60 prefix from the ISP, Slaac with PD for addresses, RA for DNS, unbound DNS working just fine. OPNsense works great! This is something I've wanted to get working for years.
hot_gril 3y ago
Ipv6 isn't just an upgraded protocol over ipv4. It could've been, but it's not. It's a totally separate network with its own routing. So just changing all hardware along the way to support ipv6 doesn't mean it's adopted.
- doublepg23 3y ago

unethical_ban 3y ago

The write that the tcp three way handshake is syn-ack-synack. I don't trust it.

deleted 3y ago

[deleted]

1vuio0pswjnm7 3y ago

HTTP/3 may have good speed for webpages that trigger many HTTP requests to source ads and support tracking/telemetry from multiple, disparate servers controlled by different entitites. (Makes sense since HTTP/3 was designed by an advertising company.) But HTTP/3 speed is not any better than HTTP/1.1 speed for downloading a file or a series of files from the same server in a single TCP connection. Some have said it's worse. (HTTP/1.1 was not designed by an advertising company so if it sucks for ads/tracking/telemetry then that makes perfect sense.)

1vuio0pswjnm7 3y ago
https://news.ycombinator.com/item?id=39164152 https://news.ycombinator.com/item?id=39164152