HTTP/3 explained

https://http3-explained.haxx.se/en/

by signa11 • 7 years ago

716 231 7 years ago

http3-explained.haxx.se

jorrizza• 7 years ago

The author gave a talk about the topic at FOSDEM last weekend.

https://fosdem.org/2019/schedule/event/http3/

DaiHafVaho• 7 years ago

This "book" does not work without JS enabled.

Disappointingly, out of all of the changes in HTTP/3, cookies are still present. It'd be nice if HTTP/4 weren't also a continuation of Google entrenching its tracking practices into the Web's structure and protocols.

api• 7 years ago

Cookies date back to the late 1990s, and it's relatively easy for browsers to implement anti-tracking features that block cookies except for their respective sites and block cross-site tracking cookies. Firefox and Safari have features like this. Don't know about Chrome, but it's likely that Chrome blocks other peoples tracking in favor of Google's.

m0dest• 7 years ago

Don't know about Chrome, but it's likely that Chrome blocks other peoples tracking in favor of Google's.

citation needed

epc• 7 years ago

If you think of 1994 as late 1990s, sure.

Cookies have been around almost as long as the web proper, and vilified for about the same amount of time.

snazz2• 7 years ago

I’m not a web developer, so sorry for the dumb question, but how would you possibly do authentication (the login on this site, for instance) without cookies or something that’s functionally equivalent?

duiker101• 7 years ago

Haven't seen it in a long time but websites used to keep the session id in the query string

codezero2• 7 years ago

Its possible to do this on the server side. Form submissions don’t require JavaScript, and authentication post submission can be done with cookies. Or if you want to go way back http basic auth.

To be clear: I support JavaScript on the web, just hoping to answer your question.

Also sorry: I answered the wrong question. Http basic with would still work.

I remember a time when basic auth gave you a unique url and the referrer was used to validate you. This was easy to break because you can fake the referrer.

Jonnax• 7 years ago

JavaScript is part of the web. Developers shouldn't have to cater for an incredibly small percentage of people that don't enable it.

3xblah5• 7 years ago

No need to enable it. It is on by default. :)

If it were off by default, would web developers cater to the incredibly small percentage of people who change default settings to turn it on?

Why is there even a setting? How many people would ever want to turn Javascript off?

When they provide a setting to toggle Javascript are browser developers catering to an incredibly small percentage of people? How many people use it?

johnisgood• 7 years ago

JavaScript for this particular website is overkill, in my humble opinion. Just because it is part of the web, it does not necessarily mean it should be abused. I especially dislike websites that send me JavaScript-only, even when the site is almost completely static.

wenc• 7 years ago

JavaScript complaints on HN are often unproductive and irrelevant to the discussion at hand. I wonder how we can disincentivize such comments.

anc84• 7 years ago

It does not load any third-party content though which in my book, counts as a +10 on the "does not work with JS disabled" scale.

jimmy1• 7 years ago

Out of all the web storage methods, cookies are still the most reliable and secure to implement sessions. I for one am glad they are not going anywhere.

takeda5• 7 years ago

Cookies are a hack to implement sessions. If http/2 and now http/3 would go for real innovation, we would replace cookies with proper sessions, like PHK suggested: https://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep...

3xblah5• 7 years ago

# lang={en,fr,ja,zh}

https://daniel.haxx.se/http3-explained/details.html

https://legacy.gitbook.com/download/pdf/book/bagder/http3-ex...

https://legacy.gitbook.com/download/mobi/book/bagder/http3-e...

https://legacy.gitbook.com/download/epub/book/bagder/http3-e...

tfolbrecht• 7 years ago

It's also been rendered in ePub, Mobi, and PDF https://legacy.gitbook.com/book/bagder/http3-explained/detai...

vszakats• 7 years ago

The book can be downloaded in pdf/e-book formats (and multiple languages) from: https://daniel.haxx.se/http3-explained/

camccar• 7 years ago

looks like it was made with mdBook https://github.com/rust-lang-nursery/mdBook

steveklabnik• 7 years ago

I don’t believe so. mdBook is a port of gitbook, and I believe it was made with that.

mscasts2• 7 years ago

Many, many sites haven't even started migration to http/2 yet. Why should I care about http/3 now? It seems kind of far in the future.

andy_ppp• 7 years ago

Haha, you are on a technology forum, the topics might well be forward thinking :-)

dmix• 7 years ago

The book says 7% of all internet traffic already uses QUIC (HTTP/3) and Chrome has long implemented Google’s version of it.

But this book isn’t about concerning yourself with using it or implementing it, it’s about understanding what the future holds, how it works, and what roadblocks lie ahead.

The lack of API support in OpenSSL for it’s TLS requirements and poor optimization for heavy UDP traffic loads on Linux et al (they say it doubles CPU vs HTTP/2 for the same traffic) sounds like it’s going to be a major hurdle for widespread adoption any time soon.

krferriter3• 7 years ago

Yeah a lot of the public internet is hosted by all-in-one vendors like Google Sites, Wordpress, Squarespace, etc, and object stores like S3, GCP buckets, Cloudflare, CDNs. The website owner just uploads the content, the hosting vendor does all the TLS, protocols, load balancing, whatever else. If the hosting providers update the protocols they use a huge chunk of websites will just immediately use the new one with no interaction whatsoever required on the part of the owner of the website.

If they add easy support in NGINX and HTTPD, then its easier for self-hosted endpoints to change as well, with minimal to no effort on their side.

acqq2• 7 years ago

The book says 7% of all internet traffic already uses QUIC (HTTP/3)

The way I have understood, the book says that what is now in use (these 7%) is a "Google-only-QUIC" whereas the "standardized HTTP/3" is still used... nowhere?

mscasts2• 7 years ago

Good point. What about Windows support?

est315• 7 years ago

Well, Google is in control of Chrome as well as the two most visited websites in the world. They can dream up any protocol they want, implement it in Chrome and use it for its sites, at any pace they desire. This is basically what happened with SPDY (now HTTP 2.0) and the upcoming HTTP 3.0 as well.

IMO it's positive. We are getting free new stuff, and I actually prefer to have two incremental steps, where HTTP 2.0 still uses TCP, giving stuff like multiplexing and pipelining, and HTTP 3.0 uses a novel UDP based transport layer protocol, improving stuff further.

There is objectionable stuff like the recent manifest 3.0 version to make ad blockers crappier but this is not one of the objectionable things imo.

nitrix• 7 years ago

I want to mention that ENet (http://enet.bespin.org/) did this a decade ago and mostly ignored.

zamadatix3• 7 years ago

At first glance I don't think it's fair to say "ENet did this a decade ago". ENet simply provides multi channel communication over a UDP stream. It doesnot provide 0/1 RTT handshakes, encryption of the protocol beyond the initial handshake, or HTTP bindings. Based on some Github issues it doesn't even look like there was a protocol extension/version negotiation.

QUIC is also decently old itself, the last 7 years have been spent proving it is well suited for the real world and able to be iterated upon. This is the kind of difference that matters for standards track vs ignored.

andrewmcwatters• 7 years ago

nitrix isn't referring to the other features, simply the concept of reliability over UDP to minimize overhead. The games industry has been using this concept for decades for efficient networking, and only now is the web community thinking about it.

est315• 7 years ago

Your comment made me wonder: Is the PR to add ipv6 support to ENet still open? Last times I checked was maybe 3 years ago. Seems it's still open: https://github.com/lsalzman/enet/pull/21

Asooka• 7 years ago

It's sad that the site doesn't work without javascript. We had this exact navigation working with iframes 20 years ago. And I could resize the TOC on the left back then.

cupofjoakim• 7 years ago

Hey, javascript is fundamental to web today, unlike 20 years ago. Even if a site like this definitely wouldn't need javascript since it's so simple, there really isn't much of a trade-of since less than one percent of all visitors are likely to have javascript disabled.

mrspeaker• 7 years ago

I disagree JavaScript is fundamental to the web - I'm a huge JavaScript fan (top 1% I'd say), and write it for my job... I've written a few books on it even... but I always use noscript when browsing the web: hackernews, reddit, twitter - can all operate fine without JavaScript. Dodgy third-party ad scripts/malware do need it, but I don't really want them running anyway.

Yes, 20% of sites I load are either a blank page or "You need to enable JavaScript to run this app" (it's the new "An error has occurred"). If it's a friend's site, or something that obviously needs it - like a game, or art project - then I'll temporarily whitelist it. But if not, then hey, I just got a 20% productivity boost by saving some time on whatever it is that thinks it needs JavaScript!

corebit• 7 years ago

Hacker News works great without javascript.

I browse with no javascript a large proportion of the time.

The web is so refreshingly fast without all the scripts.

zzzcpan3• 7 years ago

Authors own user-agent doesn't do javascript.

zamadatix3• 7 years ago

There is a way to make an iframe in the body of the page change by clicking the navigation bar in the main page without reloading the main page/navigation bar?

thefreeman2• 7 years ago

yea you put a target on the anchor tag with the name of the iframe

3xblah5• 7 years ago

I was able to access all the content as either html or md. I could also download PDF and other formats. I am not using a javascript-enabled browser.

exabrial2• 7 years ago

TLS 1.3 _being required_ makes me sigh loudly. What about local development, where tools like tcpdump and wireshark are really handy? What about air gapped systems? What about devices that are power constrained?

It's not that I think an encrypted web is bad, it's a very good thing. I am just spooked by tying a a text transfer protocol to a TCP system.

zamadatix3• 7 years ago

Perhaps it's best if a non-web protocol caters to those use cases so it can best serve it's 99% use case anyways.

This follows into the debugging conversation, web browsers and web servers have debugging tools 10x better than reading HTTP packets in Wireshark/tcpdump.

xfitm3• 7 years ago

You probably don't want to have debug tools around in prod. It's easier to install tcpdump and start looking at packets, IMO.

petronio2• 7 years ago

At least for local development, disable the cipher suites with a DH key exchange and configure wireshark to use the private key.

codedokode2• 7 years ago

So inconvenient.

kevin_thibedeau• 7 years ago

The world is moving to ECDHE which makes this less trivial.

est315• 7 years ago

What about local development, where tools like tcpdump and wireshark are really handy?

You can tell browsers to dump the session keys, which then can be read by wireshark [1].

What about devices that are power constrained?

That's thinking from 10 years ago. 10 years ago, there were no native AES extensions in power constrained devices. But now there are, so encryption is really power efficient.

I am just spooked by tying a a text transfer protocol to a TCP system.

I guess instead of "TCP system" you meant transport layer protocol. I can actually understand your view: stuff is getting more complicated. I can fire up netcat, connecting to wikipedia, typing out a HTTP/1.0 request manually. With 1.1 this is hard and with 2.0 it's impossible due to TLS requirements. But there are reasons for this added complexity: you want to be able to re-use connections, or use something better than TCP. As long as there is a spec, and there are several implementations lying around, I think it's okay to add complexity if there is a performance reward for it. Most people care about the performance, who wants to fire up netcat to do a HTTP request.

[1] https://jimshaver.net/2015/02/11/decrypting-tls-browser-traf...

exabrial2• 7 years ago

To clarify, HTTP 1.0/1.1 were successfully transmitted over TCP, multiple versions of SSL, then several versions of TLS. Just seems a bit pretentious to be tying to TLS 1.3.

treve2• 7 years ago

Worth adding that when HTTP/3 arrives, HTTP/1 doesn't go away. I imagine that HTTP/1 will never go away exactly for the reasons why people like it.

thefreeman2• 7 years ago

You are going to be using tools like tcpdump and wireshark for debugging, but can't figure out how to install a root certificate on your local machine?

dharmab• 7 years ago

You don't need a root cert, you can just load the session keys into Wireshark

LukeShu• 7 years ago

- HTTP/1 is "1 HTTP stream over 1 TCP-ish L4 connection" (TLS-over-TCP is a TCP-ish L4 connection)

- HTTP/2 is "multiple HTTP streams multiplexed over 1 TCP-ish L4 connection"

- HTTP/3 is "HTTP over QUIC"

HTTP/3 is meant to replace HTTP/1 or HTTP/2 only to the degree that QUIC replaces TCP. In your air-gapped system, or for local development, QUIC-instead-of-TCP is less compelling.

tylerl• 7 years ago

What about them? Don't use HTTP/3 if you don't want encryption.

The whole point of HTTP/3 is that it doesn't treat TLS as a separate layer, that it tightly binds parts of the two protocols to allow more efficient use of time and data. It's not just an option, the protocol doesn't make sense without it. If doing encrypted HTTP isn't what you're after, then this protocol isn't for you.

boomlinde• 7 years ago

Then you can of course use another protocol, not thinking of HTTP/3 as a replacement of HTTP/2 or HTTP/1.1.

matthewaveryusa• 7 years ago

That's a good point. I completely understand clients MUST use TLS. On the server side though, a workflow I really like is to have a pass-through proxy that terminates TLS so I don't need a TLS stack in each one of my apps. This is a pretty common pattern so I'm sure libraries will allow for http3 without TLS -- who knows though, maybe I'm a crazy eccentric heathen.

yellowapple• 7 years ago

To expand on that point: load balancers will also have to maintain encrypted connections between themselves and their web servers behind the scenes. That's probably a "best practice" security-wise, but it's convenient to be able to handle the TLS stuff at a load balancer level and stick to plain HTTP behind the scenes.

I suppose this can still happen regardless, except the HTTP/3 connection would stop at the load balancer (which would have to translate to plain ol' HTTP/1 for the servers behind it).

dochtman3• 7 years ago

If your client or server has support for key log files, Wireshark can deal with TLS quite well. In fact, this is usually how I debug my QUIC implementation.

raxxorrax• 7 years ago

[..] around 70% of all HTTPS requests Firefox issues get HTTP/2 [...]

Frequent use of Google probably puts this number on the higher end without revealing much information about general adaptation.

Personally, I am waiting for HTTP/5, since the speed for new protocol versions seems to be set on "suddenly very fast".

That said, I think HTTP/2 was a good add-on for the protocol.

On the other hand a lot of over-engineered protocols fail or are a giant pain to use. I think we will only see adaptation if there is a real tangible benefit to upgrade infrastructure.

Quic doesn't really convince me yet. It is certainly advantageous for some cases, but it isn't obvious to me. Yes, non-blocking parallel streaming connections are certainly great... 0-RTT? Hm, I don't think the speed advantages are worth the reduced security if used with a payload. Maybe for Google and similar services, but otherwise? Quic needs to re-implement TCPs error checking and puts these mechanism outside of the kernel space. Let's hope we don't see other shitty proprietary protocols that are "similar" to HTTP.

(I am no web- or network-developer)

dochtman3• 7 years ago

The important part of QUIC is that lost packets will not block delivery of all other data being delivered over the same connection, but only the data from any affected streams (for example, a single HTTP request/response will usually be one stream).

vardump• 7 years ago

Quic needs to re-implement TCPs error checking...

Have you ever err... checked how bad TCP's error checking is? It just adds together all 16-bit words! Hard to imagine worse algorithm for the purpose.

johncolanduoni2• 7 years ago

And with required authenticated encryption, one would hope an intervening switch or router couldn't accidentally forge a message that's supposed to be hard to forge when you're trying.

tialaramex10• 7 years ago

0-RTT is one of those features where the decision was it's better if we build it and in the end nobody uses it (because it's so dangerous) than if we don't build it and then we all wish we had it, because now we need an entirely new protocol to get it.

Protocols that live on top of a transport (QUIC or TLS 1.3 itself) that offers 0-RTT are supposed to explicitly define whether and how it's used. HTTP is drafting such advice.

You should definitely avoid software that "magically" uses 0-RTT today without that definition being completed, particularly client software. Because of how TLS works, if you never use client software that can do 0-RTT, nothing you send can be replayed, so you're safe. The danger only sneaks in if you run client software that does 0-RTT _and_ the server has dangerous behaviour. Well, you can't tell about the server, but you can easily choose not to run that client.

No popular TLS 1.3 clients (e.g. Firefox, Chrome) do 0-RTT today. They've talked about it, and I can imagine it sneaking in for specific jobs where nobody can see how it causes problems, but I do not expect them to screw up and start doing 0-RTT GET /money-transfer?dollars=1million because they've been here before and they know what will happen when some idiot builds a server.

In client software libraries it's a bit scarier. So, if you use an HTTP library and one day it's like "Yay, now we do 0-RTT to make everything faster" that's probably going to need some stern words in a bug report.

collinmanderson3• 7 years ago

Cloudflare for example allows 0-RTT for "only GET requests with no query parameters"

https://blog.cloudflare.com/introducing-0-rtt/

tialaramex10• 7 years ago

No popular TLS 1.3 clients (e.g. Firefox, Chrome) do 0-RTT today.

This was wrong. 0-RTT is enabled in current Firefox builds. I haven't been able to determine under what circumstances Mozilla now chooses to do 0-RTT, but you can switch it off if you're concerned, it is controlled by the pref security.tls.enable_0rtt_data

shpx• 7 years ago

HTTP/2 accounted for 66.88% of TLS connections to Cloudflare's edge a year ago.

https://blog.cloudflare.com/deprecating-spdy/

aaaaaaaaaaab• 7 years ago

Personally, I am waiting for HTTP/5, since the speed for new protocol versions seems to be set on "suddenly very fast".

Major versions look better on Googlers’ quarterly promotion case.

1_player3• 7 years ago

So much negativity in this thread.

Personally I am _very_ excited by HTTP/3 (and QUIC), it feels like the building block for Internet 2.0, with connection migration over different IPs, mandatory encryption, bidirectional streams and it being a user-space library – sure, more bloat, but from now on we won't have to wait for your kernel to support feature X, or even worse, your ISP-provided router or decade old middleware router on the Internet.

I haven't had the chance to read the actual spec yet, but it's obvious that while the current tech (HTTP2) is an improvement over what we had before, HTTP/3 is a good base to make the web even faster and more secure.

HTTP/3 won't be IPv6: it only requires support from the two parties that benefit from it the most: browser vendors and web server vendors. We won't have to wait on the whole internet to upgrade their hardware.

zzzcpan3• 7 years ago

Googlenet is not internet 2.0 and barely anyone in the world beyond a couple of megacorps can benefit from HTTP/2, HTTP/3, HTTP/4, etc. It feels more like the web is dead, completely captured by megacorps.

dochtman3• 7 years ago

QUIC is developed by an IETF working group where anyone can participate, and there are definitely some productive participants who don't work for Google (or any of the other big companies).

est315• 7 years ago

The web is captured by megacorps but it's not captured because of HTTP/2.0. It's captured because of network effects or whatever. And you are wrong, there is a benefit from using HTTP/2.0 on any website that has more than 1 resource to download.

tialaramex10• 7 years ago

So, presumably organisations like the IRS and Wikipedia are "barely anyone" and all of the big technology companies are "a couple of megacorps" but can you explain why you believe the _users_ don't benefit?

[About a third of all "popular" (ie top 10 million) web sites are HTTP/2 today]

Or did you just mean "I don't care about the facts, I'm angry and the world changes which I don't really understand, so I just make things up and call that truth because it's easier" ?

rswail2• 7 years ago

Running nginx as reverse proxy on internal system. HTTP/2 happens automagically if a client requests it.

It definitely has an impact on our system which requires sub 50ms response times on 2000+ concurrent requests.

It's a PITA if you want to debug the streams because not plain text, but given that we're over TLS, that's not really possible anyway.

In testing, we use ye-olde HTTP/1.1 and no TLS, but even over HTTP/2 and TLS, the browser will still display a JSON request/response happily. Rare that we have to go lower in the stack.

marcosdumay2• 7 years ago

Honestly, I'd feel much better if people were standardizing QUIC and we simply run HTTP/1.1 over it.

Instead we now have transport layers that are application specific and 3 completely different web protocols with none of them being considered legacy, 2 of them being complex enough that people aren't very willing to move.

That does not look like a good foundation for anything.

detaro3• 7 years ago

Part of the process while moving QUIC through IETF was separating it from the HTTP layer, which is why now HTTP/3 and QUIC are different things - although given history and involved players, the HTTP use case was a priority, but other companies are looking to use it underneath other protocols. From my understanding, compared to HTTP/2, the stream concept has moved out of the HTTP spec in the underlying level, where it hopefully can benefit other use cases too.

collinmanderson3• 7 years ago

http/2 usage has gone from 24% to 33% in the last year, which is pretty good growth.

https://w3techs.com/technologies/details/ce-http2/all/all

jlouis• 7 years ago

I'm worried, not because of the standard itself, which seems well thought out, even if rushed.

I'm worried because you have a protocol implemented in the userland for a few mainstream languages. It seems everyone now has to pay the price of a protocol implementation on top of a protocol implementation on top of a protocol implementation. Big players---either because they have thousands of open source developers, or is backed by a corporation---they have it easy. Smaller players? Not so much.

Also, note that the exact problem that HTTP/3 tries to solve was known in the design process of HTTP/2 and some people even noted having multiple flow control schemes at multiple layers would become a problem. We are letting the same people design the next layer, and probably too fast in the name of time to market.

This should definitely live in a way people can make use of it easily, with an API highly amenable to binding. If it gains traction, we need a new UDP interface to the kernel as well, for batching packets back and forth. This kills operating system diversity as well, or runs the risk at doing so.

OTOH, I see the lure: SCTP never caught on for a reason, and much of this is the opposite of my above worries.

shereadsthenews5• 7 years ago

The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Being in userspace is a feature.

Andrex• 7 years ago

Big players---either because they have thousands of open source developers, or is backed by a corporation---they have it easy. Smaller players? Not so much.

If you think that's bad, try building a browser from scratch these days!

Then, make it adhere 100% to the HTML5 and CSS3 specs! (W3C versions; I know WHATWG has uses living docs.)

xorcist2• 7 years ago

SCTP never caught on for a reason,

What is that reason, exactly?

I know why I never use it. The use cases where it really shines aren't that common, and it's a very heavy, telco-style, protocol.

However those things are (mostly) true for QUIC as well.

xfs2• 7 years ago

some people even noted having multiple flow control schemes at multiple layers would become a problem

It could, but it didn't in reality. HTTP/2 has two levels of flow control, stream-level and connection-level. You use 1 connection per site and as many streams as you want multiplexed inside that connection, thus stream-level flow control is necessary to avoid stream head-of-line blocking.

The actual layering violation is connection-level flow control, which seems to duplicate TCP flow control, but it's not mandatory, as you can see most if not all open source implementations simply set a very large connection-level window size to hand off flow control at this level to TCP.

There is a good reason for this to exist, which is to compete for bandwidth with HTTP/1.1 domain sharding technique which uses N connections per "site", effectively having N times the Initial Congestion Window (IW) than what HTTP/2 can have in one connection. IW was a huge issue in improving connection startup latency, and after managing to convince Linux netdev to raise it to 10, Google couldn't get them to allow applications to customize its value anymore. The only solution for Google was to add some flow control information in HTTP/2 and pass it to coupled TCP flow control to improve IW. So in reality only one flow control scheme is working at any time, instead of the common perception of TCP over TCP meltdown. For anyone else they can simply not do connection-level flow control in HTTP/2 and nothing of value is lost.

Matthias247• 7 years ago

I'm worried because you have a protocol implemented in the userland for a few mainstream languages. It seems everyone now has to pay the price of a protocol implementation on top of a protocol implementation on top of a protocol implementation. Big players---either because they have thousands of open source developers, or is backed by a corporation---they have it easy. Smaller players? Not so much.

This can be partially mitigated in the same way it has been worked-around before: Through proxies. The fact that HTTP/3 is still only HTTP makes it even easier.

E.g. on the server side it might be good enough to have an API gateway, load balancer or CDN which understands HTTP/3 and forwards things in boring HTTP/1.1 to internal services. That's not very different from terminating TLS somewhere before the actual service implementation. Actually service implementations don't even have to speak HTTP - they can also talk via stdin/out to a HTTP/3 server in another language - which means back to CGI.

On the client side, we could deploy a client-side proxy server which translates localhost HTTP/1.1 requests into remote HTTP/3 requests. If that thing is part of the OS distribution, it's actually not that much different from a TCP/IP stack which is delivered as part of the kernel. However if it's not part of the OS it might cause some trust issues. And apart from that it might be a bit inconvenient for users, since now applications need to be changed to make use of the proxy.

the84722• 7 years ago

If it gains traction, we need a new UDP interface to the kernel as well, for batching packets back and forth.

Those already exist.

http://man7.org/linux/man-pages/man2/sendmmsg.2.html http://man7.org/linux/man-pages/man2/recvmmsg.2.html

jimmaswell2• 7 years ago

Irrespective of the protocol, my optimism for the future of the web has been curtailed by developments like extensions having less and less power over time (recent example is Google's plans to intentionally cripple ad blockers), plugins going away, hobbyist websites becoming more burdensome to set up and maintain if insecure http is deprecated, browsers planning to disable autoplay, etc. It feels like the golden age of the creative and vibrant web peaked during the brief window where all the new HTML5 stuff was around, Firefox used the old extension system, and Flash and Java applets were still common.

After that point it's been becoming more and more sterilized. My web apps that automatically played some sound aren't going to work anymore without some obnoxious "click here to begin" screen that doesn't fit in with the content. No more plugins letting us extend our browsers in new ways (what a convenient "coincidence" for Google that this gives them more control over what the user gets to do and makes tracking what goes on easier). I have to give Reddit Enhancement Suite permission every single time it tries to show a preview from a domain it hasn't previously done so from before. It's all suffocating. HTML5 makes up for some of the lost capability but it's not enough and what parts of HTML5 are going to actually work are basically at the whim of Google now.

But at least HTTP/3 will let us load buzzfeed listicles a few milliseconds faster, so there's that.

iwalton3• 7 years ago

At least Let's Encrypt has made certificates easier than ever to add and update. Installation of a self-updating certificate takes less than 10 minutes on many server setups.

skybrian• 7 years ago

This is a special case of production values going up, as also seen in movies, video games, and many other products. User expectations gradually rise until only large organizations of professionals can meet them.

On the other hand, we already live in this world. When was the last time you used a homemade CPU or graphics chip?

It's still possible for an indie scene to arise that values hand-crafted stuff, possibly at a different layer.

chrisweekly2• 7 years ago

wat

I'm trying to interpret your stance in the most favorable possible manner, but... dude. If you think hobbyist websites are increasingly burdensome to set up, you haven't been paying any attention at all.

sfink• 7 years ago

Yep. Sadly, the Web is a victim of its own success. There aren't just a few bad actors anymore. There are legions more than willing to write an endless number of malware extensions with randomly permuted uuids. There's an ad industry that long ago went off the deep end and are hoping people don't notice just a little longer. The price list for exploits is well known and buyers are easy to find.

Then again, it is still a massive cross platform content publishing and distribution system that works, despite the hostile ecosystem it inhabits. And it even includes the first truly successful cross platform programming environment.

So there's that.

dotancohen• 7 years ago

This off-topic post is akin to "we have homeless people, so no resources should be allocated to space flight".

The energies invested in developing HTTP successor protocols are not being deprived from efforts to stifle Google from ruining the concept of the web browser as a _user_ agent.

tialaramex10• 7 years ago

It's a misconception that you have to wait with IPv6.

If you're a large organisation you can move to IPv6 "today". What you do is, internally you cease buying IPv4-only gear and using IPv4 addressing etcetera. Everything inside is purely IPv6. A lot of your networking gets simpler when you do this, and debugging is a LOT smoother because there's no more "Huh 10.0.0.1, could be _anything_" everything has globally unique addresses because it's not crammed into this tiny 32-bit space.

At the edge, you have protocol translators to get from IPv6 (which all your internal stuff users) to IPv4 (which some things on the Internet use) but you probably already had a bunch of gear at the edge anyway, to implement corporate policies like "No surfing for porn at work" and "Nobody from outside should be connecting to port 22 on our machines!".

This isn't really practical for "One man and an AWS account" type businesses where your "Internet access" is a Comcast account and an iPhone, but if you're big enough to actually have an IT department, suggest they look into it. It may be cheaper and simpler than they'd realised.

1_player3• 7 years ago

It's a misconception that you have to wait with IPv6.

Yes and no. As I stated at the end of my comment, the problem w/ IPv6 is that who's benefitting the most isn't clear: I am interested in it, as a power user. Average Joe doesn't care. App developer doesn't care (no killer IPv6 apps yet). Large ISPs with extensive CG-NAT deployments don't care (not worth the money, yet, see IPv6 adoption in the UK).

Who cares about HTTP/3? Average Joe — Not really. Mozilla/Google — Hell yeah they do. It'll be in Chrome before anyone else (if it isn't already). Same with nginx/Apache/any other webserver, Joe Blog with his own VPS will want to enable it. And that's all you need.

iforgotpassword• 7 years ago

What you do is, internally you cease buying IPv4-only gear and using IPv4 addressing etcetera. Everything inside is purely IPv6.

"Throw everything away and start from scratch." uh yeah, that's totally gonna work for a large organization. They'll be done in an afternoon! That includes rewriting all your legacy apps that only support ipv4, including the ones you bought from 3rd parties where you don't even have the source code.

simias2• 7 years ago

It may be my embedded developer bias but I don't actually consider moving things outside of the kernel to be necessarily a good thing. Standard kernel interfaces are (usually) a guarantee of stability and good isolation, are generally easier to probe using standard tools, easier to accelerate in hardware etc... Not everything should be in the kernel of course, but low level network protocols should be IMO because they're good targets for potential hardware-acceleration (I'm convinced that it would make sense to handle SSL in-kernel for instance, with a userland daemon handling certificate validation, but that's a story for an other day).

I mean, if you can easily update whatever userland library you're using, why can't you upgrade your OS? If the library is easy to upgrade it means that it uses a well defined and backward-compatible interface. What do you get by shifting everything one layer up? In the end it's just software, there's not really any reason why upgrading a kernel driver should be any harder than upgrading a .so/.dll.

So the logic is "kernels are too slow to update and integrate the last new standards, so let's just move everything one step up because browsers auto-update"? Except that there's no technical reason for that, on my Linux box my browser and my kernel are updated at the same time when I run "apt-get upgrade" or "pacman -Syu" or whatever applies. The kernel I'm using at the moment has been built less than a week ago.

So if the problem is that Windows sucks balls and as a result people end up effectively re-creating an operating system on top of it to work around that, then yeah, from a practical standpoint I get it but I'm definitely not "_very_ excited" about it. It's a rather ugly hack.

If in general if the question is "who do you trust more to select and implement new internet standards, kernel developers or web developers?" then I take a side-glance at the few GBs used by my web browser to display a handful of static pages at the moment and I know the answer as far as I'm concerned...

So yeah, it might make sense, but I still think it just goes to show what a shitshow modern software development has become. Instead of fixing things we just add a new layer on top and we rationalize that it's better that way.

k_• 7 years ago

I generally agree with that, but what about mobile? AFAIK android kernel updates are really slow to reach users; when they actually do (depending on support from vendors, which vary a lot).

1_player3• 7 years ago

The problem isn't your kernel that needs updating. That's the least of your problems.

The problem are the network appliances that are sitting between you and the server. i.e. the whole internet. To support feature X, everything between you and the server will need to support that (unless it's backwards compatible, but that's not always the case, as described in the article).

Decade-long adoption will solve this problem, until one day your packet gets routed through some router running Linux v2.5 and your connection silently fails.

This isn't good enough to build a faster (and more reliable) internet on, whereas UDP is a 40-year old standard, and we can assume everybody supports it, even Linux v2.5

justincormack3• 7 years ago

Linux has TLS in kernel right now, with userland cert handling. Barely anyone is using it though.

On the other hand there are some really nice QUIC implementations in Rust, and running in userspace has security advantages.

jjtheblunt• 7 years ago

I can't believe you wrote "Internet 2.0". Not sure why.

mlindner• 7 years ago

or even worse, your ISP-provided router or decade old middleware router on the Internet.

I can guarantee you that middleware will continue to exist. If they need to they'll force QUIC connections to terminate and switch to TLS 1.3. There's no way that companies will allow encrypted communications leaving their companies en-masse without being able to decrypt the content. Even more so for any totalitarian state governments that need to spy on their citizens..

JoshTriplett2• 7 years ago

There's no way that companies will allow encrypted communications leaving their companies en-masse without being able to decrypt the content.

Then they'll install MITM certificates on the individual endpoints that they already control. The ability to intercept connections between endpoints is inexorably going away.

MaxBarraclough• 7 years ago

About the mandatory encryption and the performance: this will prevent ISP caching of static content. That would be bad news for, say, Steam and Debian, who use HTTP (not HTTPS [0][1]) to distribute content. (They verify integrity with secure hashing, of course.) I presume they'll decline to adopt HTTP/3.

[0] https://developer.valvesoftware.com/wiki/SteamPipe#LAN_Cachi...

[1] https://whydoesaptnotusehttps.com/

smittywerben• 7 years ago

Bit late to the party, I misunderstood the HTTP/3 but I am very excited for QUIC, and _not_ because of Google's illuminati spec but because I hope people will be interested in secure UDP.

I like datagrams so much more than an accept-listen-keepalive-blocking-foreverloop-callback-async-threaded-future hell that is TCP.

I could be wrong of course I need to read the spec too. Anything UDP makes me giddy.

ldng2• 7 years ago

One thing I don't understand is, if it's encrypted, we'll never see hardware accelerated QUIC ?

I've read it's 2 to 3 times more CPU intensive, aren't we implicitly giving an artificial competitive advantage to the "Cloud" ? By the "Cloud" I mean big provider with like (obviously) Google, Cloudflare, Akamaï ...

That is raising the barrier of entry for newcomers, is it not ?

Isn't TCP already versioned ?

CaliforniaKarl• 7 years ago

One thing I don't understand is, if it's encrypted, we'll never see hardware accelerated QUIC ?

I think parts of it can still be hardware-accelerated. For example, OpenSSL et al will take advantage of available AES encryption CPU instructions, if it knows about them. So, if the TLS library supports such offloading, then the HTTP/3 library would get that benefit.

I've read it's 2 to 3 times more CPU intensive, aren't we implicitly giving an artificial competitive advantage to the "Cloud" ? By the "Cloud" I mean big provider with like (obviously) Google, Cloudflare, Akamaï ...

Happily, a number of those vendors are kernel developers, and contribute changes back upstream. So, if the bottleneck is in the kernel (for example, by a lack of UDP fast processing paths), then I expect those cloud providers would be working on contributions to make kernel UDP as performant as kernel TCP.

The next thing that would be missing is support for UDP offloading in the NIC space. But TBH I don't know much about the current state of hardware offloading, so I can't speak to it.

Isn't TCP already versioned ?

I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'.

[0] https://www.iana.org/assignments/protocol-numbers/protocol-n...

ldng2• 7 years ago

Hum, right, parts of TLS could be offloaded. Now will the TLS protocol will continue to evolve ? And will QUIC follow ?

And you could offload UDP, TLS but not QUIC itself. Unless you're BigBuck Company and offload to FPGAs competition can't afford. Could happen.

It's a gap that might close, but right now, to me, it is a notable competitive advantage.

takeda5• 7 years ago

> Isn't TCP already versioned ?
I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'.

Currently there is only a single TCP, it didn't need new version, because it has options mechanism to add additional information as needed. If it would need to be redesigned a new protocol would be created and a new protocol number would be allocated. Kind of like what happened with ICMP and ICMPv6.

tracker14• 7 years ago

I'm not sure there's a reason large parts of it couldn't be hardware accelerated.. for that matter why specific implementations couldn't happen on a network controller for that matter. Sure, initial implementations will be software only, so that it can be implemented on top of the OS, that doesn't negate the opportunity to move pieces down the stack.

wmf2• 7 years ago

Some NICs already accelerate TLS so QUIC probably won't be any more difficult. Although QUIC NICs may not be available until 2-3 years after the RFC.

lol768• 7 years ago

As the packet loss rate increases, HTTP/2 performs less and less good. 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 six TCP connections up to distribute the lost packet over so for each lost packet the other connections without loss can still continue.
Fixing this issue is not easy, if at all possible, to do with TCP.

Are there any resources to better understand _why_ this can't be resolved? If HTTP 1.1 performs better under poor network conditions, why can't we start using more concurrent TCP connections with HTTP 2 when it makes sense?

I'm a bit wary of this use of UDP when we've essentially re-implemented some of TCP on top, though I understand it's common in game networking.

jayd16• 7 years ago

Are there any resources to better understand _why_ this can't be resolved?

The issue is TCP's design assumption around a single stream. You don't get any out of order packets but that also means you don't get any out of order packets, even if you want them. When you have multiple conceptual streams within a single TCP connections you actually just want the order maintained within those conceptual streams and not the whole TCP connection, but routers don't know that. If you can ignore this issue, http/2 is really nice because you're saving a lot of the overhead of spinning up and tearing down connections.

If HTTP 1.1 performs better under poor network conditions, why can't we start using more concurrent TCP connections with HTTP 2 when it makes sense?

Because it performs worse under good conditions. TCP has no support for handing off what is effectively part of the connection into a new TCP connection.

And QUIC essentially _is_ your suggestion.

KMag2• 7 years ago

Good points, but the fragment

just want the order maintained within those conceptual streams and not the whole TCP connection, but routers don't know that.

seems to imply that routers inspect TCP streams and maintain order. I'm not aware of any routers that actually do anything like this, and things need to keep working just fine if different packets in the stream take different paths. Certainly in theory, IP routers don't have do inspect packets any deeper than the IP headers, if they're not doing NAT / filtering / shaping. The protocols are designed to strictly minimize the minimum amount of state kept in the routers.

As far as I'm aware, only the kernel (or userspace) TCP stack makes much effort at all to maintain packet order (other than routers generally using FIFOs).

mcguire• 7 years ago

The other problem with TCP the assumption that packet loss is caused by congestion. That's why a 2% loss causes more than a 2% drop in bandwidth. Unfortunately, congestion is no longer a problem on the modern internet. [1]

1. Sic.

shereadsthenews5• 7 years ago

TCP fix requires a lot of coordination. First you need microsecond time stamps. Then you need an RFC to reduce RTOmin below 200ms. Then you need ATO discovery and negotiation. A lot of moving parts and you end up with a protocol that’s still worse than QUIC. Also note that Linux maintainers have refused to accept patches for all of these things and QUIC is to some extent a social workaround for their intransigence.

jandrese2• 7 years ago

There are TCP proxies designed to make it work better over lossy links. These are frequently found in satcom modems.

An example of this is SCPS-TP.

https://en.wikipedia.org/wiki/Space_Communications_Protocol_...

xfs2• 7 years ago

why can't we start using more concurrent TCP connections with HTTP 2 when it makes sense

Because using 6 TCP connections per site is a hack to have larger initial congestion windows, i.e. faster page loading, ending up using more bandwidth in retransmission instead of in goodput. Instead we could have more intelligent congestion control algorithms in one TCP connection to properly fill up the available bandwidth. See https://web.archive.org/web/20131113155029/https://insoucian... for a more detailed account (esp. the figure of "Etsy’s sharding causes so much congestion").

athenot• 7 years ago

Several things that excite me about this protocol:

— UDP-based and different stream multiplexing such that packet loss on one stream doesn't hold up all the other streams.

— Fast handshakes, to start sending data faster.

— TLS 1.3 required, no more clear-text option.

Overall this has the potential to help with overall latency on the web, and that is something I am really looking forward to.

(Yes I'm aware that there are many steps that can be done today to reduce latency, but having this level of attention at the protocol level is also an improvement.)

tialaramex10• 7 years ago

There is in practice no clear-text HTTP/2

The documentation says how in theory it could happen, but all actual client software just does ALPN, which is a TLS feature to let you pick a different sub-protocol after connecting. Since it's a TLS feature you are obliged to use encryption.

fiatjaf2• 7 years ago

If we aren't using TCP anymore does that mean all network congestion tooling developed in the last 30 years are suddenly worthless and quality of service will degrade everywhere?

collinmanderson3• 7 years ago

HTTP/3 hopes to improve flow control.

the_other_guy• 7 years ago

HTTP3 is exciting, I got a couple of questions:

1. is QUIC only for HTTP3 or can be generalized for any TCP-based L7 protocol but over TLS/UDP?

2. How is Websockets dealt with in HTTP3?

pacificmint• 7 years ago

From the link:

The QUIC working group that was established to standardize the protocol within the IETF quickly decided that the QUIC protocol should be able to transfer other protocols than "just" HTTP.
...
The working group did however soon decide that in order to get the proper focus and ability to deliver QUIC version 1 on time, it would focus on delivering HTTP, leaving non-HTTP transports to later work.

ttsda• 7 years ago

Non-HTTP over QUIC
The work on sending other protocols than HTTP over QUIC has been postponed to be worked on after QUIC version 1 has shipped.

I'm very interested in this bit. I'm working on a sensor network using M2M SIM cards which are billed for each 100kb. Being able to maintain an encrypted connection without having to handshake every time could have nice applications.

IshKebab2• 7 years ago

QUIC is a name, not an acronym.

Pretty sure it stands for Quick UDP Internet Connections.

https://lwn.net/Articles/558826/

winklock• 7 years ago

The QUIC protocol draft states that it's not an acronym: https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec...

BurnGpuBurn• 7 years ago

The original creator of quick also explicitly named it as an acronym [0]. But of course, if the big boys at IETF decree it's not an acronym, it isn't. Just like we've always been at war with Oceanea.

[0] https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...

IshKebab2• 7 years ago

Well they are wrong then.

all_blue_chucks• 7 years ago

I've got to say, the phrase "physical TCP connection" made me chuckle.

aruggirello• 7 years ago

Obligatory xkcd:

https://xkcd.com/927/

fiatjaf2• 7 years ago

So HTTP/2 was crap all the time but was still forced upon everybody with the repeated discourse: "it's much much better"?

And HTTPS, which is much slower than HTTP, was said to be much much faster BECAUSE with HTTPS you could used HTTP/2 and not with with HTTP.

Solar19• 7 years ago

Any data on HTTP/3 performance? I don't see it in the book. There's the general claim that it's faster/lower latency, but there are no numbers behind that claim -- last time I checked QUIC's performance benefits were incredibly slight.

shereadsthenews5• 7 years ago

It is really easy to observe the performance benefit of QUIC in a congested datacenter network. In the face of loss, QUIC tail latency is dramatically better than TCP tail latency. This is mainly due to TCP's 200ms minimum retransmit time; a single dropped packet will add at least 200ms to the request time (modulo tail loss probing which can lower this to ~20ms in many cases). When your request service time is 10µs this makes a huge difference.

tbronchain• 7 years ago

A lot of enterprises, operators and organizations block or rate-limit UDP traffic

That was my first thought, and the following seem to be assuming that companies will decide to change their policy. But many public WiFi block UDP traffic, are they going to change their policy? Are the people in charge of it even aware about it? (Think coffee shops, restaurants, hotels, ...) Are we going to have websites supporting legacy protocols ("virtually forever") in order to build a highly available internet?

Also, ISPs in some countries have not been UDP-friendly. I'm thinking about China mainly, where UDP traffic if being throttled and often blocked (connection shutdown) if the volume of traffic is consequent - I assume they apply this policy to block fast VPNs. Are they going to change their policy? Worst scenario here, would be to see a new http-like protocol coming out in China, resulting in an even larger segmentation of the internet

discreditable4• 7 years ago

Working in a school I block QUIC traffic so my web filter can (attempt to) keep kids off porn. Such filtering is required by law for schools. I haven't found a passive filter that handles QUIC. I don't want to install invasive client software or MITM connections.

tialaramex10• 7 years ago

There won't ever be a passive filter. The QUIC traffic is deliberately opaque.

If you control the clients you may be able to retain your status quo for some time (by just refusing to upgrade) but the direction is away from having anything filterable. So client software or MITM are your only options.

comex• 7 years ago

How do you handle regular old HTTPS?

CloudNetworking• 7 years ago

If QUIC is a name and not an acronym, as the book says, why is it written all in CAPITALS?

That's the real question nobody is asking.

zackmorris• 7 years ago

I'm still reading through the article, but I have to say that I'm pleasantly surprised by QUIC and HTTP/3. I first learned socket programming around the fall of 1998 (give or take a year) in order to write a game networking layer:

https://beej.us/guide/bgnet/

Here are just a few of the immediately obvious flaws I found:

* The UDP checksum is only 16 bits, when it should have been 32 or arbitrary

* The UDP header is far too large, using/wasting something like 28 bytes (I'm drawing that from memory) when it only needed about 12 bytes to represent source ip, source port, destination ip, destination port

* TCP is a separate protocol from UDP, when it should have been a layer over it (this was probably done in the name of efficiency, before computers were fast enough to compress packet headers)

* Secure protocols like TLS and SSL needed several handshakes to begin sending data, when they should have started sending encrypted data immediately while working on keys

* Nagle's algorithm imposed rather arbitrary delays (WAN has different load balancing requirements than LAN)

* NAT has numerous flaws and optional implementation requirements so some routers don't even handle it properly (and Microsoft's UPnP is an incomplete technique for NAT-busting because it can't handle nested networks, Apple's Bonjour has similar problems, making this an open problem)

* TCP is connection oriented so your stream dropped by doing something as simple as changing networks (WIFI broke a lot of things by the early 2000s)

There's probably more I'm forgetting. But I want to stress that these were immediately obvious for me, even then. What I really needed was something like:

* State transfer (TCP would have probably been more useful as a message-oriented stream, this is also an issue with UNIX sockets, for example, could be used to implement a software-transactional-memory or STM)

* One-shot delivery (UDP is a stand in for this, I can't remember the name of it, but basically unreliable packets have a wrapping sequence number so newer packets flush older packets in the queue so that latency-sensitive things like shooting in games can be implemented)

* Token address (the peers should have their own UUID or similar that remain "connected" even after network changes)

* Separately-negotiated encryption (we should be able to skip the negotiation part on any stream if we already have the keys)

Right now the only protocol I'm aware of that comes close to fixing even a handful of these is WebRTC. I find it really sad that more of an effort wasn't made in the beginning to do the above bullet points properly. But in fairness, TCP/IP was mostly used for business, which had different requirements like firewalls. I also find it sad that insecurities in Microsoft's (and early Linux) network stacks led to the "deny all by default" firewalling which lead to NAT, relegating all of us to second class netizens. So I applaud Google's (and others') efforts here, but it demonstrates how deeply rooted some of these flaws were that only billion dollar corporations have the R&D budgets to repair such damage.

spc4763• 7 years ago

Yeah, it really sucks that the developers of TCP didn't foresee these issues in 1981 when they first designed it. I can't believe they were so short-sighted.

Okay, enough with the sarcasm. Is it too much to ask for historical perspective in protocol design?

rswail2• 7 years ago

Agreed, as well as the "Oh why didn't the Berkley people implement the OSI 7 layer model, then TCP would have been layered over UDP".

The reason that TCP beat out all the other protocols is because it didn't "layer" everything. OSI was beautiful in the abstract, but a complete cluster-fuck in the implementation.

Now we have enough processing power that the abstract layering makes more sense. But where the layers interact with cross-layer requirements like security was never actually dealt with in the OSI days.

lazulicurio• 7 years ago

Really neat resource. Coming into this thread with next-to-no knowledge of HTTP/3, this was a great high-level overview of the motivation and resulting protocol.

I'm wondering if anyone with a little more knowledge could go deeper into what the difference is between "TLS messages" and "TLS records" as talked about in this[1] snippet:

the working group also decided that [...] [QUIC] should only use "TLS messages" and not "TLS records" for the protocol

From my understanding quickly reading through the spec, it looks like HTTP/3 starts with a standard TLS handshake for key exchange, but then QUIC "crypto" frames are used to carry application-level data instead of TLS frames[2]. Is this accurate? If so, why define a new frame format? Just to be able to lump multiple frames into one packet[3]?

[1] https://http3-explained.haxx.se/en/proc-status.html

[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_r...

[3] https://tools.ietf.org/html/draft-ietf-quic-tls-18#page-8

tialaramex10• 7 years ago

From my understanding quickly reading through the spec, it looks like HTTP/3 starts with a standard TLS handshake for key exchange, but then QUIC "crypto" frames are used to carry application-level data instead of TLS frames[2]. Is this accurate?

Sort of, kinda, no? It's a "standard TLS handshake" from a cryptographic point of view, but the TLS standard specifies that all this data travels over TCP. QUIC doesn't use TCP, so for QUIC the same data is cut up differently and moved over QUIC's UDP channel. So, everything uses QUIC's frames, not just application data.

QUIC needs to solve a bunch of problems TCP already solved, plus the new problems, and chooses to do so in one place rather than split them and have an extra protocol layer. For example, "What do I do if some device duplicates a packet?" is solved in TCP, so TLS doesn't need to fix it. But QUIC needs to fix it. On the other hand, "What do I do if some middleman tries to close my connection to www.example.com?" is something TCP doesn't solve and neither does TLS but QUIC wants to, so again QUIC needs to fix it.

One reason to do all this in one place is that "it's encrypted" is often a very effective solution even when your problem isn't hostiles just idiots. For example maybe idiots drop all packets with the bytes that spell "CUNT" in them in some forlorn attempt to protect "the children". Ugh. Now nobody can mention the town of Scunthorpe! But wait, if we encrypt everything now the idiot filter will just drop an apparently random and vanishingly small proportion of packets, which we can live with. "I just randomly drop one entire packet for every 4 gigabytes transmitted" is still stupid, but now everything basically works again.

BorRagnarok• 7 years ago

Happy for everybody, but since it only really delivers benefits in less than 2% of use cases (those with crappy connections) I personally can't wait to have it be as quickly implemented and supported as ipv6 was.

HTTP/3 explained

Related Stories