7 ms·
HTTP3 Explained
- gramakri2 1y agoWhere can I download the pdf? It seems the link points to itself
- panki27 1y agoIt's hidden in the "Copy" drop down at the top right. https://http3-explained.haxx.se/~gitbook/pdf?limit=100 https://http3-explained.haxx.se/~gitbook/pdf?limit=100
- ahoka 1y agoAnyone else blocks UDP 80/443 due to privacy concerns?
- detaro 1y agoWhat privacy concern do you have that does not apply to TCP 80/443?
- ahoka 1y agoTracking sessions across different physical connections has some non-trivial privacy implications: https://http3-explained.haxx.se/en/quic/quic-connections#connection-id https://http3-explained.haxx.se/en/quic/quic-connections#con...
- NavinF 1y agoHow do you imagine other protocols handle switching physical connections? With HTTP 1, you send your session ID as a cookie after wasting time creating a new TCP connection
- ahoka 1y agoYes, obviously, but we already know how that is used. This is a more complex protocol that might enable attack vectors that were not possible before and we do not think about when accessing websites: But see the notes taken from the HTTP/3 RFC itself, written by the authors: 10.11. Privacy Considerations Several characteristics of HTTP/3 provide an observer an opportunity to correlate actions of a single client or server over time. These include the value of settings, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client. HTTP/3's preference for using a single QUIC connection allows correlation of a user's activity on a site. Reusing connections for different origins allows for correlation of activity across those origins. Several features of QUIC solicit immediate responses and can be used by an endpoint to measure latency to their peer; this might have privacy implications in certain scenarios.
- NavinF 1y agoHTTP 2 also does connection coalescing. Why are you quoting text instead of a specific concern? QUIC has been around for over a decade now
- MallocVoidstar 1y agoNo.
- frmdstryr 1y agoYes, no performance difference either.
- ckbkr10 1y agoSounds overly complicated, I doubt this will have a widespread adoption
- ofrzeta 1y ago"As of September 2024, HTTP/3 is supported by more than 95% of major web browsers in use and 34% of the top 10 million websites." https://en.wikipedia.org/wiki/HTTP/3 https://en.wikipedia.org/wiki/HTTP/3
- karel-3d 1y agoA lot of servers still don't support that. Go http webserver doesn't support http 3 without external libraries. Nginx doesn't support http 3. Apache doesn't support http 3. node.js doesn't support http 3. Kubernetes ingress doesn't support http 3. should I go on? edit: even curl itself - which created the original document linked above - has http 3 just in an experimental build.
- miyuru 1y ago>Nginx doesn't support http 3 nginx do support it. https://nginx.org/en/docs/quic.html https://nginx.org/en/docs/quic.html
- karel-3d 1y agoah okay i was wrong there, mea culpa
- dotancohen 1y agoThe guy's point still stands - lots of popular software do not yet support http3.
- karel-3d 1y agoAnd I see I was not that wrong; the module is still marked as "experimental" and not built by default. https://nginx.org/en/docs/http/ngx_http_v3_module.html https://nginx.org/en/docs/http/ngx_http_v3_module.html
- code_martial 1y agoHere’s a conceptual background about how and why HTTP/3 came to be (recollected from memory): HTTP/1.0 was built primarily as a textual request-response protocol over the very suitable TCP protocol which guaranteed reliable byte stream semantics. The usual pattern was to use a TCP connection to exchange a request and response pair. As websites grew more complex, a web page was no longer just one document but a collection of resources stitched together into a main document. Many of these resources came from the same source, so HTTP/1.1 came along with one main optimisation — the ability to reuse a connection for multiple resources using Keep Alive semantics. This was important because TCP connections and TLS (nee SSL) took many round-trips to get established and transmitting at optimal speed. Latency is one thing that cannot be optimised by adding more hardware because it’s a function of physical distance and network topology. HTTP/2 came along as a way to improve performance for dynamic applications that were relying more and more on continuous bi-directional data exchange and not just one-and-done resource downloads. Two of its biggest advancements were faster (fewer round-trips) TLS negotiation and the concept of multiple streams over the same TCP connection. HTTP/2 fixed pretty much everything that could be fixed with HTTP performance and semantics for contemporary connected applications but it was still a protocol that worked over TCP. TCP is really good when you have a generally stable physical network (think wired connections) but it performs really badly with frequent interruptions (think Wi-Fi with handoffs and mobile networks). Besides the issues with connection reestablishment, there was also the challenge of “head of the line blocking” — since TCP has no awareness of multiplexed HTTP/2 streams, it blocks everything if a packet is dropped, instead of blocking only the stream to which the packet belonged. This renders HTTP/2 multiplexing a lot less effective. In parallel with HTTP/2, work was also being done to optimise the network connection experience for devices on mobile and wireless networks. The outcome was QUIC — another L4 protocol over UDP (which itself is barebones enough to be nicknamed “the null protocol”). Unlike TCP, UDP just tosses data packets between endpoints without much consideration of their fate or the connection state. QUIC’s main innovation is to integrate encryption into the transport layer and elevate connection semantics to the application space, and allow for the connection state to live at the endpoints rather than in the transport components. This allows retaining context as devices migrate between access points and cellular towers. So HTTP/3? Well, one way to think about it is that it is HTTP/2 semantics over QUIC transport. So you get excellent latency characteristics over frequently interrupted networks and you get true stream multiplexing semantics because QUIC doesn’t try to enforce delivery order or any such thing. Is HTTP/3 the default option going forward? Maybe not until we get the level of support that TCP enjoys at the hardware level. Currently, managing connection state in application software means that over controlled environments (like E-W communications within a data centre), HTTP/3 may not have as good a throughput as HTTP/2.
- akdor1154 1y agoDamn it's nice reading a simple static site like this. Links open instantly to the next fully laid out page of content. If only the rest of the web could be like this..
- INTPenis 1y agoAgreed but where is the actual git repo? I see a text saying this "contents get updated automatically on every commit to this git repository" but where is "this git repository"? I can't find a link to the source anywhere.
- Cthulhu_ 1y agoAfter a quick google: https://github.com/bagder/http3-explained https://github.com/bagder/http3-explained (using a search engine is faster than asking for a link on HN)
- Zambyte 1y agoI found it on HN faster than I could have with a search engine because they asked :)
- rchard2scout 1y agoThe introduction has a "help out" section which links to the github repo: https://github.com/bagder/http3-explained https://github.com/bagder/http3-explained
- dobladov 1y agohttps://github.com/bagder/http3-explained https://github.com/bagder/http3-explained
- madeofpalk 1y agoWorth nothing, that react application (using React Server Components?)! If you have javascript enabled, it renders as a single page app, fetching each additional page via an API. If you disable JS, it renders it all on the server.
- sedatk 1y agoThe document is now five years old and full of statements like “we’ll see that in the upcoming years”. I think it’s due for an update.
- esnard 1y agoLink for anyone willing to contribute: https://github.com/bagder/http3-explained https://github.com/bagder/http3-explained Looks unmaintained, though.
- lsaferite 1y agoI was personally bugged by it claiming that QUIC wasn't an acronym.
- bmicraft 1y agoWell, it seem like is was originally, but isn't now and hasn't been at date of publication. Edit: > The initial QUIC protocol was designed by Jim Roskind at Google and was initially implemented in 2012, announced publicly to the world in 2013 when Google's experimentation broadened. > Back then, QUIC was still claimed to be an acronym for "Quick UDP Internet Connections", but that has been dropped since then. from https://http3-explained.haxx.se/en/proc https://http3-explained.haxx.se/en/proc
- derelicta 1y agoIt's still crazy how quickly http3 got adopted by web actors. Can't wait til we do the same for IMAP and SMTP
- immibis 1y agoEmail is mostly dead - we use Gmail (or Microsoft 365) now. It is to email what Slack is to IRC. With only one or two vendors, the need for widely interoperable protocols is gone - they only need to interoperate between a few large service providers, and that can be done by private agreement.
- lsaferite 1y agoYou realize those ESPs use and support the industry standard open protocols under the hood, right? Slack is 100% proprietary and does not use industry standard protocols for interchange or federation. These are not even remotely comparable. Slack would need to use industry standard and open protocols (i.e. XMPP) to allow federation with products like Teams and Discord for the situations to be comparable.
- immibis 1y agoThe Slack API is an industry standard open protocol.
- lsaferite 1y agoCan you name one other chat service that uses it? Does it allow interop between the chat services? Publishing the spec for your proprietary API does not make it an industry standard.
- immibis 1y agoIt does if your proprietary API is the industry standard. Everything Microsoft puts out is both industry standard and proprietary. So is everything TSMC puts out (their processes). Most of the interconnects in any computer system as well. I actually bought a legal copy of the SATA standard, for $30ish.
- kevg123 1y ago> As the packet loss rate increases, HTTP/2 performs less and less well. At 2% packet loss (which is a terrible network quality, mind you), tests have proven that HTTP/1 users are usually better off - because they typically have up to six TCP connections to distribute lost packets over. This means for every lost packet the other connections can still continue. Why doesn't HTTP/2 use more than one socket?
- sharts 1y agoWill there be HTTP/4 ?
- deleted 1y ago[deleted]