14 ms·

HTTP/3: Everything you need to know about the next-generation web protocol

220 points by homarp 5y ago

deleted 5y ago
[deleted]
hrdwdmrbl 5y ago
I’m still waiting for everyone to support http/2!
sleepydog 5y ago
> The protocol utilizes space congestion control over User Datagram Protocol (UDP). I'm assuming they meant "user space congestion control" ? Even so, there's nothing about the protocol that says congestion control has to occur in user space.
- detaro 5y ago
  But unless you push QUIC in the kernel, which afaik nobody is really doing yet, it will be. And it's not necessarily seen as a bad thing - opinions about that generally depend on how you think about apps "knowing better" than the OS.
  - tptacek 5y ago
    Some of what's on Portswigger is extremely good (as is the case with anything James Kettle writes), because it's coming directly from practitioners. But Portswigger also functions as a sort of industry newsletter, and some of the content comes from non-subject-matter-experts. That's the case with this article, and I think it's reasonable to assume the author is just confused here. I think it's pretty obvious that the feature/quirk of QUIC that the author is trying to summarize is that it's a UDP protocol (the most noteworthy thing about QUIC!) that provides its own congestion control, which is what makes it possible to run as a bulk transport for ~all Internet traffic, which is the premise of any new HTTP protocol.
bfung 5y ago
The REAL web3. Sorry, couldn’t help my inner troll, take my karma.
- serverholic 5y ago
  This is getting pretty old.
tyingq 5y ago
I wonder if the various corporate MITM nanny gateways and firewalls will keep up with this. And not just the manufacturers, but the device owners that don't keep them up to date. I know Chrome had to implement a race between tcp and quic to detect various forms of broken firewalls, content filtering devices, etc. Maybe it would be better just to let things break and force the issue?
- sgift 5y ago
  > Maybe it would be better just to let things break and force the issue? I think it would be better, but unfortunately it won't happen. Too much money riding on it. I still hope newer versions of http continue to be designed to be more resistant against these garbage tools.
- kmonsen 5y ago
  I helped out with implementing quick in chrome, letting things break was never an option that was considered.
- FridgeSeal 5y ago
  I'm really interested to know how far we could push performance, encryption/security, features, etc if we didn't care about legacy systems or breaking current setups. What are we missing out on, because of the refusal to let go of pointless legacy systems?
  - tyingq 5y ago
    Yeah, that's an interesting question. If we had, for example, moved to IPV6 only some time ago...what innovations would have followed on that more solid ground, no NAT, etc. Or perhaps on a smaller timescale, just pushing ESNI as a non-negotiable thing.
    - josephcsible 5y ago
      > just pushing ESNI as a non-negotiable thing Well, ECH instead of eSNI now, but yes, I would have loved this. Since browsers are all going to be willing to fall back to sending the website name in cleartext, anyone evil enough to be willing to do censorship or surveillance will just block eSNI and ECH.
linkdd 5y ago
When HTTP/2 came out, I was wondering how long it would take for the billions of websites/APIs/webservices/... out there to migrate from HTTP/1.1 HTTP/2 came out in 2014, and since then I still haven't seen it used in production in the jobs I worked at. Now, I wonder again, will HTTP/4 be released before we migrate to HTTP/3 ? The real question here is, what are the arguments in favor of a migration? When starting a new web project, should you really consider anything else than HTTP/1.1?
- xyzzy_plugh 5y ago
  If you use Go or gRPC, then you're probably using HTTP/2. I've seen both used, at least somewhat, by every company I've done work for in the last 5-6 years.
  - halpert 5y ago
    The default Go http server is 1.1, no?
    - ferdowsi 5y ago
      The default Go server supports HTTP/2. https://pkg.go.dev/net/http https://pkg.go.dev/net/http > Starting with Go 1.6, the http package has transparent support for the HTTP/2 protocol when using HTTPS.
  - linkdd 5y ago
    > If you use Go or gRPC I'm not. My go-to web frameworks are Elixir/Phoenix, Python/Django, NodeJS/ApolloServer. I have an irrational hatred for the Go language, but still use it to develop quickly some CLI tools.
    - topicseed 5y ago
      > I have an irrational hatred for the Go language Do you mind sharing why?
jrockway 5y ago
I feel like there is still a lot to learn. I tried rolling out HTTP/3 for jrock.us. It works in Firefox but not Chrome. On https://h3.jrock.us/ https://h3.jrock.us/, I serve the header: alt-svc: h3="nodes.jrock.us:31313"; ma=300, h3-29="nodes.jrock.us:31313"; ma=300 Chrome will not request subsequent resources with HTTP/3. Firefox will. Obviously I am using a super-weird setup. I'm not using port 443 since I use managed Kubernetes which has a nodePort range that doesn't include 443. Then, h3.jrock.us is a CNAME for public-ingress.jrock.us which is an A record for 206.189.254.193. nodes.jrock.us is an A record that is a list of all nodes in my cluster. (This is because DigtialOcean doesn't support UDP load balancing, and I don't want to run my own load balancer, though I probably should. I am also missing out on IPv6 support, which annoys me greatly.) Everything is handled by Envoy; any load balancing is at the TCP level (load balancer) or UDP level (Kubernetes service). I can't see anything in the standards that should prevent this from working, but it is indeed prevented from working. Sigh! Guess I should just run my own fleet of load balancers. (Oh, ya know what, I'll interject another piece of annoyance here. I don't really want to use this pattern for non-test traffic, since there is some latency between nodes becoming unavailable and DNS caches noticing that. So if I roll all of my nodes, my website will break through the nodes.jrock.us route in that case. Even if I only roll one, browsers don't really know that they should fall back to another A record. This forces people to do load balancing at the IP layer, instead of at the application layer, which is really annoying. I wish there was a protocol where I could specify retry policies at the DNS layer. So you'd look up "jrock.us", get A 1.2.3.1, 1.2.3.2, 1.2.3.4, and "hey, if any of those fail to connect in 1 second, try the next and use that for 60 seconds". Each browser appears to do their own thing, and in-cluster I have a TON more control with things like xDS.)
- javajosh 5y ago
  Yikes! I don't think I would play with a new HTTP version with such a setup. I would want to keep things as simple as possible, and write the simplest port-binding daemon I could in whatever language I liked best, and invoke it by hand. Test locally then on your local subnet, then public test on a $5/mo Ubuntu VPS. At that point I feel like I'd be ready to start thinking about testing on your setup. :)
- smt88 5y ago
elchief 5y ago
I was scraping an HTTP/2 site the other day, and discovered that Python requests library does not support it :S HTTPX and Hyper didn't work either (probably due to ALPN?) Had to call Curl from Python to make it work
- tyingq 5y ago
  The bundled urllib doesn't even support HTTP/1.1 properly. It sends "Connection: close" and uses a connection-per-request model. I suppose since it's hard to scrape anything without a headless browser these days, the http[s] scraping libraries are stagnated.
  - hackcasual 5y ago
    The flip side to that is headless browsers have gotten a lot better
1vuio0pswjnm7 5y ago
"Nearly 8% of the top 10 million websites support HTTP/3, according to the latest figures from W3Techs." And 100% support HTTP/1.1. HTTP.1.1, while not new, sounds quite useful. Being a mostly non-commercial, text-only web user, I only request resources from the host domain. The browser does not automatically follow URLs sourced in a page nor does it process Javascript to fetch or make XHR for additional resources. Often I do not use a browser to make HTTP requests, preferring to use smaller command line utilities instead, as for me this can be faster and more flexible. There is never any delay for a website to "load". For example, if I request the resource "index.html" from the host example.com, I do not make connections to any third party host domains, e.g., doubleclick.net. Thus, "head-of-line blocking" is generally not an issue. Perhaps if I were requesting multiple resources, e.g., index0001.html through index1500.html, from example.com, then HTTP/3 might be faster than HTTP/1.1 pipelining, but I have not seen any evidence to support that idea. I have been using HTTP/1.1 pipelining to request multiple resources from the same host for a long time. Year after year it keeps working, and in some cases working better than ever before. In the years before Nginx was popular, when Apache was the most popular web server, it was common to see maximums set at 100 HTTP requests per TCP connection. Today, in some cases, maximums seem to have no upper bound. I have made thousands of HTTP requests over a single TCP connection. The so-called "head-of-line blocking" problem seems to be restricted to "complex" websites that use resources from multiple hosts, especially trackers and ad servers. Those are often websites with lots of advertising, distractions and annoyances. I enjoy using the web without invoking the "complex" website model. Nearly 100% of websites look great in the text-only browser, meaning I can read all the text and glean the information conveyed. For me, most "complex" websites can still be treated as if they were "simple" websites without losing information. When I visit example.com, I only request index.html from example.com. Nothing more. I do not make additional connections to third party domains, and, as such, there are no "blocking" problems to worry about. HTTP/3 may be optimised for certain types of websites, i.e., complex ones, and a certain type of web usage, i.e., consumption of "complex" websites that include third party "content" and/or hidden elements. The biggest push for "HTTP/3/" comes from companies with vested interests in "complex" websites, the proliferation of online advertising and the attraction of "eyeballs". HTTP/1.1 feels less corporate, from a time before Google et al.'s takeover of the web. I do like the idea of QUIC (though I do no think Google was the first to implement the idea of reliable transmission over UDP), and I look forward to potentially using other (less web browser-centric, advertising-oriented) protocols over QUIC "connections".
quasarj 5y ago
Everything I need to know? Hardly! How is it to debug? How do I troubleshoot? How do I dump a stream and see what is going on? And that's just the tip of the iceberg of what I need to know before I can consider using it...
- deleted 5y ago
  [deleted]
throw0101a 5y ago
> HTTP/3 runs over QUIC – an encrypted general-purpose transport protocol that multiplexes multiple streams of data on a single connection. Kind of sucks that SCTP, which also allows for multiplexing, never caught on for general use—probably because lack of support in various mid-network network boxen. I guess we're generally stuck with tunnelling everything over HTTP (TCP and UDP) going forward. Every other kind of protocol implementation is out of the question because of NAT and various proxies.
- Orphis 5y ago
  It would help to have quality implementations of the full SCTP specs first.
- EvanAnderson 5y ago
  Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses, SCTP was used for everything we use TCP for, and "well-known ports" were eschewed in favor of DNS SRV records for service location (and all the goodness they bring).
  - p_l 5y ago
    Sounds a bit like half way to OSI network style
    - EvanAnderson 5y ago
      Perhaps. When OSI was still a going concern I was far too young to have paid attention. Glancing at the PDF for the X.224 spec[0] I see things like "The initiator may assign the transport connection to an existing network connection of which it is the owner or to a new network connection (see Note 1) which it creates for this purpose." In X.225[1] I see some references to re-using transport connections. (Egad, the ITU documentation is much less fun to read than RFCs.) It certainly looks like the layering in the OSI protocols is taken nearly to the absurd. I do know Vint Cerf has stated using the IP address as the connection endpoint identifier in TCP and UDP was a mistake.[2] [0] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.224-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [1] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.225-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [2] https://youtu.be/t9M0RPNr9qg?t=2229 https://youtu.be/t9M0RPNr9qg?t=2229
philip1209 5y ago
Great - now Heroku will be two versions behind on HTTP.
rixed 5y ago
This article is technically shallow, not giving any detail about the protocol but instead just quoting supposed experts opinion about it. > [list of obstacles to be overcome in deploying HTTP/3] includes getting the technology to work with (...) deep packet inspection devices How do you reconcile this with the alleged increased used security? I know that everything relying on TLS for security is already just theatre in practice but still. > the protocol is much easier than TCP to evolve/tweak and new best practices will emerge Knowing only Google and/or other $big_corp will influence those evolutions, this does not strike me as a benefit either. I can wait before facing wire level DRM enforcement, for instance.
- arjvik 5y ago
  > I know that everything relying on TLS for security is already just theatre in practice Could you expand on that?
  - rixed 5y ago
    From what I've seen, it seems routine practice for large non-technical organisations to light-heartedly implement one of these techniques, from simplest to more elaborate: - adding a compromised certificate authority to the set of trusted ones in the clients (won't work reliably any longer for most servers I believe) - copying around the servers private keys and forcing those servers to nehociate below perfect forward secrecy so that traffic can be decrypted on the fly from many places (for when you control the servers, but still copying private keys around and decrypting at the perimeter is not great) - enforcing the use of a compromised browser/ssl lib on the client machines that will just store/forward the traffic - installing "security" agents on controlled clients that forward all session keys on the fly or optionally tunnel the whole clear traffic to another box (I know a startup whom this is the only product) I've personally been professionally involved with several of these tools at this point, even authored one, and I'm not even particularly interested in these topics, so I guess anyone working in security could bring more stories. In conclusion, I believe TLS is both too complex and too flawed to be relied upon, and is just delaying the adoption of better protocols (some with no trusted authority, mandatory anonymous clients authorisation, mandatory secure encryption, you name it, again I'm not much into this, maybe some already well known protocol fits the bill)
deleted 5y ago
[deleted]
otabdeveloper4 5y ago
No, not everything. "When will this bullshit die" isn't answered.
posix86 5y ago
I'm surprised that a major feature of QUIC isn't mentioned at all: Identification of session solely through connection IDs, unrelated to IP addresses. When you travel & change network, from WIFI to cellular, from one cellular tower to another, your phone / laptop often changes IP address, causing the TCP sessions to be directed into the void. Meaning, they wait until they timeout, then restart with new handshake. QUIC uses connection IDs to identify sessions independent of IP addresses, so a single packet from the new IP is enough to make the server switch to sending to the new IP without having to establish a new session at all. This is again mainly an issue for unstable connections when browsing (and fast travels in old cellular networks), and even then not a major problem, but still, it's pretty cool.
- nikita2206 5y ago
  I think it’s because it’s a network level session which isn’t very useful for the app level. Those connections are still ephemeral enough that you wouldn’t be able to treat their IDs as application’s session ID, you’d simply get randomly interrupted sessions otherwise.
  - posix86 5y ago
    Agreed on the last point but isn't that the case for all improvements? From an application layer, all you see is a set of datastreams that are now less interrupted/delayed than before....
- 1vuio0pswjnm7 5y ago
  CurveCP, also UDP-based, predates QUIC and can do this as well. https://curvecp.org/addressing.html https://curvecp.org/addressing.html "A CurveCP connection remains fully functional even if the client changes IP address."
  - posix86 5y ago
    As it should be, in my opinion. A connection should be between hosts, and anything path related on a different abstraction layer.
samwillis 5y ago
Slight aside but in many ways I wish HTTP2 had been closer to John Graham-Cummings suggestion here: “Speeding up HTTP with minimal protocol changes” https://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html https://blog.jgc.org/2012/12/speeding-up-http-with-minimal-p... It’s basically HTTP2s out of order pipelining but implemented as a simple extension to HTTP1.1 text protocol. I think it would have been nice to maintain and improve the text protocol in that way. Previous discussions: 2012: https://news.ycombinator.com/item?id=4931837 https://news.ycombinator.com/item?id=4931837 2013: https://news.ycombinator.com/item?id=6012660 https://news.ycombinator.com/item?id=6012660
yagizdegirmenci 5y ago
It's crazy that no one else commented this yet but the author of the cURL has an awesome free book about HTTP/3 and QUIC. See: https://http3-explained.haxx.se/en https://http3-explained.haxx.se/en
- homarp 5y ago
  and he also did the similar "http2 explained" https://daniel.haxx.se/http2/ https://daniel.haxx.se/http2/
minus7 5y ago
> Nearly 8% of the top 10 million websites support HTTP/3, according to the latest figures from W3Techs. Let me guess: those are all behind Cloudflare
john567 5y ago
I'm interested in using HTTP/3 for bi-directional communication. Anyone with more experience on this care to weigh in? I know there's WebSockets but that's typically implemented over HTTP/1.1 with durable TCP connections. Let's say I wanted to do near real time (lowest possible latency preferably) synchronization in a server/client architecture, can HTTP/3 make sense here?
- Matthias247 5y ago
  HTTP/3 pretty much performs like HTTP/2 there. You kind of have 2 options: 1. Make as many requests/responses as you require, and let the mulitiplexing of the protocol level do the job for you. Still might mean extra latency for sending another request to get the next chunk of data, but you might be able to send it ahead of time (long-polling style). 2. Make a single request, and stream all data bidirectionally in the request and resopnse body. bodies can be almost infinite and if you are using a custom library you can use them however you want. E.g. put small delimited messages into it in either direction - which is what gRPC streaming is doing. This will require libraries which actually support streaming, and not just Request->Response. Especially browsers are tricky here. All those options have in common that you get reliability and flow-control in them. If you don't want to have that - because you maybe e.g. rather want to skip outdated data - then building on a lower layer like directly on QUIC makes more sense. This capability might come to browsers with WebTransport.
  - john567 5y ago
    Ok, so streaming might be an option. In this case I'm not limited to browsers. Just curious if it might be applicable elsewhere.
    - john567 5y ago
      Looks like WebTransport has been designed to do what I want to do.
jpambrun 5y ago
Meanwhile the company I work for installs root certs on our machines and pass everything through a proxy that blocks http/2. I doubt I will ever see http/3..
egberts1 5y ago
Not going to open UDP ports at the home gateway firewall. Just not worth the associated baggage that UDP brings outside of HTTP/3-QUIC.
- BenjiWiebe 5y ago
  Do you block all UDP including outbound? I guess DNS works over TCP (and TCP/HTTP) these days...

220 points by homarp 5y ago

deleted 5y ago

[deleted]

hrdwdmrbl 5y ago

I’m still waiting for everyone to support http/2!

sleepydog 5y ago

> The protocol utilizes space congestion control over User Datagram Protocol (UDP). I'm assuming they meant "user space congestion control" ? Even so, there's nothing about the protocol that says congestion control has to occur in user space.

detaro 5y ago
But unless you push QUIC in the kernel, which afaik nobody is really doing yet, it will be. And it's not necessarily seen as a bad thing - opinions about that generally depend on how you think about apps "knowing better" than the OS.
- tptacek 5y ago
  Some of what's on Portswigger is extremely good (as is the case with anything James Kettle writes), because it's coming directly from practitioners. But Portswigger also functions as a sort of industry newsletter, and some of the content comes from non-subject-matter-experts. That's the case with this article, and I think it's reasonable to assume the author is just confused here. I think it's pretty obvious that the feature/quirk of QUIC that the author is trying to summarize is that it's a UDP protocol (the most noteworthy thing about QUIC!) that provides its own congestion control, which is what makes it possible to run as a bulk transport for ~all Internet traffic, which is the premise of any new HTTP protocol.

bfung 5y ago

The REAL web3. Sorry, couldn’t help my inner troll, take my karma.

serverholic 5y ago
This is getting pretty old.

tyingq 5y ago

I wonder if the various corporate MITM nanny gateways and firewalls will keep up with this. And not just the manufacturers, but the device owners that don't keep them up to date. I know Chrome had to implement a race between tcp and quic to detect various forms of broken firewalls, content filtering devices, etc. Maybe it would be better just to let things break and force the issue?

sgift 5y ago
> Maybe it would be better just to let things break and force the issue? I think it would be better, but unfortunately it won't happen. Too much money riding on it. I still hope newer versions of http continue to be designed to be more resistant against these garbage tools.
kmonsen 5y ago
I helped out with implementing quick in chrome, letting things break was never an option that was considered.
FridgeSeal 5y ago
I'm really interested to know how far we could push performance, encryption/security, features, etc if we didn't care about legacy systems or breaking current setups. What are we missing out on, because of the refusal to let go of pointless legacy systems?
- tyingq 5y ago
  Yeah, that's an interesting question. If we had, for example, moved to IPV6 only some time ago...what innovations would have followed on that more solid ground, no NAT, etc. Or perhaps on a smaller timescale, just pushing ESNI as a non-negotiable thing.
  - josephcsible 5y ago
    > just pushing ESNI as a non-negotiable thing Well, ECH instead of eSNI now, but yes, I would have loved this. Since browsers are all going to be willing to fall back to sending the website name in cleartext, anyone evil enough to be willing to do censorship or surveillance will just block eSNI and ECH.

linkdd 5y ago

When HTTP/2 came out, I was wondering how long it would take for the billions of websites/APIs/webservices/... out there to migrate from HTTP/1.1 HTTP/2 came out in 2014, and since then I still haven't seen it used in production in the jobs I worked at. Now, I wonder again, will HTTP/4 be released before we migrate to HTTP/3 ? The real question here is, what are the arguments in favor of a migration? When starting a new web project, should you really consider anything else than HTTP/1.1?

xyzzy_plugh 5y ago
If you use Go or gRPC, then you're probably using HTTP/2. I've seen both used, at least somewhat, by every company I've done work for in the last 5-6 years.
- halpert 5y ago
  The default Go http server is 1.1, no?
  - ferdowsi 5y ago
    The default Go server supports HTTP/2. https://pkg.go.dev/net/http https://pkg.go.dev/net/http > Starting with Go 1.6, the http package has transparent support for the HTTP/2 protocol when using HTTPS.
- linkdd 5y ago
  > If you use Go or gRPC I'm not. My go-to web frameworks are Elixir/Phoenix, Python/Django, NodeJS/ApolloServer. I have an irrational hatred for the Go language, but still use it to develop quickly some CLI tools.
  - topicseed 5y ago
    > I have an irrational hatred for the Go language Do you mind sharing why?

jrockway 5y ago

I feel like there is still a lot to learn. I tried rolling out HTTP/3 for jrock.us. It works in Firefox but not Chrome. On https://h3.jrock.us/ https://h3.jrock.us/, I serve the header: alt-svc: h3="nodes.jrock.us:31313"; ma=300, h3-29="nodes.jrock.us:31313"; ma=300 Chrome will not request subsequent resources with HTTP/3. Firefox will. Obviously I am using a super-weird setup. I'm not using port 443 since I use managed Kubernetes which has a nodePort range that doesn't include 443. Then, h3.jrock.us is a CNAME for public-ingress.jrock.us which is an A record for 206.189.254.193. nodes.jrock.us is an A record that is a list of all nodes in my cluster. (This is because DigtialOcean doesn't support UDP load balancing, and I don't want to run my own load balancer, though I probably should. I am also missing out on IPv6 support, which annoys me greatly.) Everything is handled by Envoy; any load balancing is at the TCP level (load balancer) or UDP level (Kubernetes service). I can't see anything in the standards that should prevent this from working, but it is indeed prevented from working. Sigh! Guess I should just run my own fleet of load balancers. (Oh, ya know what, I'll interject another piece of annoyance here. I don't really want to use this pattern for non-test traffic, since there is some latency between nodes becoming unavailable and DNS caches noticing that. So if I roll all of my nodes, my website will break through the nodes.jrock.us route in that case. Even if I only roll one, browsers don't really know that they should fall back to another A record. This forces people to do load balancing at the IP layer, instead of at the application layer, which is really annoying. I wish there was a protocol where I could specify retry policies at the DNS layer. So you'd look up "jrock.us", get A 1.2.3.1, 1.2.3.2, 1.2.3.4, and "hey, if any of those fail to connect in 1 second, try the next and use that for 60 seconds". Each browser appears to do their own thing, and in-cluster I have a TON more control with things like xDS.)

javajosh 5y ago
Yikes! I don't think I would play with a new HTTP version with such a setup. I would want to keep things as simple as possible, and write the simplest port-binding daemon I could in whatever language I liked best, and invoke it by hand. Test locally then on your local subnet, then public test on a $5/mo Ubuntu VPS. At that point I feel like I'd be ready to start thinking about testing on your setup. :)
smt88 5y ago

elchief 5y ago

I was scraping an HTTP/2 site the other day, and discovered that Python requests library does not support it :S HTTPX and Hyper didn't work either (probably due to ALPN?) Had to call Curl from Python to make it work

tyingq 5y ago
The bundled urllib doesn't even support HTTP/1.1 properly. It sends "Connection: close" and uses a connection-per-request model. I suppose since it's hard to scrape anything without a headless browser these days, the http[s] scraping libraries are stagnated.
- hackcasual 5y ago
  The flip side to that is headless browsers have gotten a lot better

1vuio0pswjnm7 5y ago

"Nearly 8% of the top 10 million websites support HTTP/3, according to the latest figures from W3Techs." And 100% support HTTP/1.1. HTTP.1.1, while not new, sounds quite useful. Being a mostly non-commercial, text-only web user, I only request resources from the host domain. The browser does not automatically follow URLs sourced in a page nor does it process Javascript to fetch or make XHR for additional resources. Often I do not use a browser to make HTTP requests, preferring to use smaller command line utilities instead, as for me this can be faster and more flexible. There is never any delay for a website to "load". For example, if I request the resource "index.html" from the host example.com, I do not make connections to any third party host domains, e.g., doubleclick.net. Thus, "head-of-line blocking" is generally not an issue. Perhaps if I were requesting multiple resources, e.g., index0001.html through index1500.html, from example.com, then HTTP/3 might be faster than HTTP/1.1 pipelining, but I have not seen any evidence to support that idea. I have been using HTTP/1.1 pipelining to request multiple resources from the same host for a long time. Year after year it keeps working, and in some cases working better than ever before. In the years before Nginx was popular, when Apache was the most popular web server, it was common to see maximums set at 100 HTTP requests per TCP connection. Today, in some cases, maximums seem to have no upper bound. I have made thousands of HTTP requests over a single TCP connection. The so-called "head-of-line blocking" problem seems to be restricted to "complex" websites that use resources from multiple hosts, especially trackers and ad servers. Those are often websites with lots of advertising, distractions and annoyances. I enjoy using the web without invoking the "complex" website model. Nearly 100% of websites look great in the text-only browser, meaning I can read all the text and glean the information conveyed. For me, most "complex" websites can still be treated as if they were "simple" websites without losing information. When I visit example.com, I only request index.html from example.com. Nothing more. I do not make additional connections to third party domains, and, as such, there are no "blocking" problems to worry about. HTTP/3 may be optimised for certain types of websites, i.e., complex ones, and a certain type of web usage, i.e., consumption of "complex" websites that include third party "content" and/or hidden elements. The biggest push for "HTTP/3/" comes from companies with vested interests in "complex" websites, the proliferation of online advertising and the attraction of "eyeballs". HTTP/1.1 feels less corporate, from a time before Google et al.'s takeover of the web. I do like the idea of QUIC (though I do no think Google was the first to implement the idea of reliable transmission over UDP), and I look forward to potentially using other (less web browser-centric, advertising-oriented) protocols over QUIC "connections".

quasarj 5y ago

Everything I need to know? Hardly! How is it to debug? How do I troubleshoot? How do I dump a stream and see what is going on? And that's just the tip of the iceberg of what I need to know before I can consider using it...

deleted 5y ago
[deleted]

throw0101a 5y ago

> HTTP/3 runs over QUIC – an encrypted general-purpose transport protocol that multiplexes multiple streams of data on a single connection. Kind of sucks that SCTP, which also allows for multiplexing, never caught on for general use—probably because lack of support in various mid-network network boxen. I guess we're generally stuck with tunnelling everything over HTTP (TCP and UDP) going forward. Every other kind of protocol implementation is out of the question because of NAT and various proxies.

Orphis 5y ago
It would help to have quality implementations of the full SCTP specs first.
EvanAnderson 5y ago
Sometimes I imagine an "alternate history" where IPv4 had 64-bit addresses, SCTP was used for everything we use TCP for, and "well-known ports" were eschewed in favor of DNS SRV records for service location (and all the goodness they bring).
- p_l 5y ago
  Sounds a bit like half way to OSI network style
  - EvanAnderson 5y ago
    Perhaps. When OSI was still a going concern I was far too young to have paid attention. Glancing at the PDF for the X.224 spec[0] I see things like "The initiator may assign the transport connection to an existing network connection of which it is the owner or to a new network connection (see Note 1) which it creates for this purpose." In X.225[1] I see some references to re-using transport connections. (Egad, the ITU documentation is much less fun to read than RFCs.) It certainly looks like the layering in the OSI protocols is taken nearly to the absurd. I do know Vint Cerf has stated using the IP address as the connection endpoint identifier in TCP and UDP was a mistake.[2] [0] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.224-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [1] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.225-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... [2] https://youtu.be/t9M0RPNr9qg?t=2229 https://youtu.be/t9M0RPNr9qg?t=2229

philip1209 5y ago

Great - now Heroku will be two versions behind on HTTP.

rixed 5y ago

This article is technically shallow, not giving any detail about the protocol but instead just quoting supposed experts opinion about it. > [list of obstacles to be overcome in deploying HTTP/3] includes getting the technology to work with (...) deep packet inspection devices How do you reconcile this with the alleged increased used security? I know that everything relying on TLS for security is already just theatre in practice but still. > the protocol is much easier than TCP to evolve/tweak and new best practices will emerge Knowing only Google and/or other $big_corp will influence those evolutions, this does not strike me as a benefit either. I can wait before facing wire level DRM enforcement, for instance.

arjvik 5y ago
> I know that everything relying on TLS for security is already just theatre in practice Could you expand on that?
- rixed 5y ago
  From what I've seen, it seems routine practice for large non-technical organisations to light-heartedly implement one of these techniques, from simplest to more elaborate: - adding a compromised certificate authority to the set of trusted ones in the clients (won't work reliably any longer for most servers I believe) - copying around the servers private keys and forcing those servers to nehociate below perfect forward secrecy so that traffic can be decrypted on the fly from many places (for when you control the servers, but still copying private keys around and decrypting at the perimeter is not great) - enforcing the use of a compromised browser/ssl lib on the client machines that will just store/forward the traffic - installing "security" agents on controlled clients that forward all session keys on the fly or optionally tunnel the whole clear traffic to another box (I know a startup whom this is the only product) I've personally been professionally involved with several of these tools at this point, even authored one, and I'm not even particularly interested in these topics, so I guess anyone working in security could bring more stories. In conclusion, I believe TLS is both too complex and too flawed to be relied upon, and is just delaying the adoption of better protocols (some with no trusted authority, mandatory anonymous clients authorisation, mandatory secure encryption, you name it, again I'm not much into this, maybe some already well known protocol fits the bill)

deleted 5y ago

[deleted]

otabdeveloper4 5y ago

No, not everything. "When will this bullshit die" isn't answered.

posix86 5y ago

I'm surprised that a major feature of QUIC isn't mentioned at all: Identification of session solely through connection IDs, unrelated to IP addresses. When you travel & change network, from WIFI to cellular, from one cellular tower to another, your phone / laptop often changes IP address, causing the TCP sessions to be directed into the void. Meaning, they wait until they timeout, then restart with new handshake. QUIC uses connection IDs to identify sessions independent of IP addresses, so a single packet from the new IP is enough to make the server switch to sending to the new IP without having to establish a new session at all. This is again mainly an issue for unstable connections when browsing (and fast travels in old cellular networks), and even then not a major problem, but still, it's pretty cool.

nikita2206 5y ago
I think it’s because it’s a network level session which isn’t very useful for the app level. Those connections are still ephemeral enough that you wouldn’t be able to treat their IDs as application’s session ID, you’d simply get randomly interrupted sessions otherwise.
- posix86 5y ago
  Agreed on the last point but isn't that the case for all improvements? From an application layer, all you see is a set of datastreams that are now less interrupted/delayed than before....
1vuio0pswjnm7 5y ago
CurveCP, also UDP-based, predates QUIC and can do this as well. https://curvecp.org/addressing.html https://curvecp.org/addressing.html "A CurveCP connection remains fully functional even if the client changes IP address."
- posix86 5y ago
  As it should be, in my opinion. A connection should be between hosts, and anything path related on a different abstraction layer.

samwillis 5y ago

Slight aside but in many ways I wish HTTP2 had been closer to John Graham-Cummings suggestion here: “Speeding up HTTP with minimal protocol changes” https://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html https://blog.jgc.org/2012/12/speeding-up-http-with-minimal-p... It’s basically HTTP2s out of order pipelining but implemented as a simple extension to HTTP1.1 text protocol. I think it would have been nice to maintain and improve the text protocol in that way. Previous discussions: 2012: https://news.ycombinator.com/item?id=4931837 https://news.ycombinator.com/item?id=4931837 2013: https://news.ycombinator.com/item?id=6012660 https://news.ycombinator.com/item?id=6012660

yagizdegirmenci 5y ago

It's crazy that no one else commented this yet but the author of the cURL has an awesome free book about HTTP/3 and QUIC. See: https://http3-explained.haxx.se/en https://http3-explained.haxx.se/en

homarp 5y ago
and he also did the similar "http2 explained" https://daniel.haxx.se/http2/ https://daniel.haxx.se/http2/

minus7 5y ago

> Nearly 8% of the top 10 million websites support HTTP/3, according to the latest figures from W3Techs. Let me guess: those are all behind Cloudflare

john567 5y ago

I'm interested in using HTTP/3 for bi-directional communication. Anyone with more experience on this care to weigh in? I know there's WebSockets but that's typically implemented over HTTP/1.1 with durable TCP connections. Let's say I wanted to do near real time (lowest possible latency preferably) synchronization in a server/client architecture, can HTTP/3 make sense here?

Matthias247 5y ago
HTTP/3 pretty much performs like HTTP/2 there. You kind of have 2 options: 1. Make as many requests/responses as you require, and let the mulitiplexing of the protocol level do the job for you. Still might mean extra latency for sending another request to get the next chunk of data, but you might be able to send it ahead of time (long-polling style). 2. Make a single request, and stream all data bidirectionally in the request and resopnse body. bodies can be almost infinite and if you are using a custom library you can use them however you want. E.g. put small delimited messages into it in either direction - which is what gRPC streaming is doing. This will require libraries which actually support streaming, and not just Request->Response. Especially browsers are tricky here. All those options have in common that you get reliability and flow-control in them. If you don't want to have that - because you maybe e.g. rather want to skip outdated data - then building on a lower layer like directly on QUIC makes more sense. This capability might come to browsers with WebTransport.
- john567 5y ago
  Ok, so streaming might be an option. In this case I'm not limited to browsers. Just curious if it might be applicable elsewhere.
  - john567 5y ago
    Looks like WebTransport has been designed to do what I want to do.

jpambrun 5y ago

Meanwhile the company I work for installs root certs on our machines and pass everything through a proxy that blocks http/2. I doubt I will ever see http/3..

egberts1 5y ago

Not going to open UDP ports at the home gateway firewall. Just not worth the associated baggage that UDP brings outside of HTTP/3-QUIC.

BenjiWiebe 5y ago
Do you block all UDP including outbound? I guess DNS works over TCP (and TCP/HTTP) these days...