[HN Gopher] The Status of HTTP/3
___________________________________________________________________
The Status of HTTP/3
Author : feross
Score : 61 points
Date : 2020-01-13 18:43 UTC (4 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| tyingq wrote:
| Because QIC is UDP based, Chrome first runs a race with TCP just
| in case you're sitting behind some device that blocks UDP.
|
| I wonder how much bandwidth this will waste globally.
| xfalcox wrote:
| I wonder if Happy Eyeballs means that there are 4 races in
| total for systems under dual-stack...
| yeaaaaah wrote:
| All the more reason not to bother with IPv4.
| microcolonel wrote:
| > _I wonder how much bandwidth this will waste globally._
|
| One or two packets? A handful of bytes per initial connection.
| The Connection ID mechanism and QPACK are likely to save a lot
| more data than is lost on initial TCP races.
| eximius wrote:
| Most global bandwidth is from video streaming, so most of the
| data isn't in the first couple packets.
|
| So the number would probably be surprisingly large but also a
| very small fraction of overall traffic.
| sebazzz wrote:
| Isn't that like any device behind NAT?
| tyingq wrote:
| Yes. NAT, firewalls with admins that don't know what QUIC is,
| various corporate MITM boxes, etc.
| big_chungus wrote:
| Most NAT still allows UDP hole-punching (STUN/TURN/ICE)
| unless specifically blocked (which a depressing number still
| do).
| stephenjudkins wrote:
| No. Most NATs handle UDP sessions trivially as long as one
| end of the connection is not behind a NAT itself. Tricks like
| UDP hole punching are necessary only between two endpoints
| that are both behind NATs.
| iso947 wrote:
| And assuming the protocol can cope with changing source
| ports. I've seem some udp protocols that only work if the
| source port is not translated.
| mholt wrote:
| This article omits that Caddy has had long-running experimental
| support for HTTP/3 for a couple of years now:
| https://caddyserver.com/docs/json/apps/http/servers/experime...
| teruakohatu wrote:
| Caddy's strange official binary licencing did them no favours.
| The licensing makes more sense now but they are off people's
| radar.
| PhilippGille wrote:
| This might change with Caddy 2.0.
| WhatIsDukkha wrote:
| From a brief look at the Rust side -
|
| Actix uses Tokio
|
| Quiche doesn't
|
| Quinn does but doesn't look quite ready and I don't see any
| integration attempts with Actix yet.
| Seenso wrote:
| Why are they calling it HTTP/3 and not just keeping the QUIC
| name?
| MrStonedOne wrote:
| That would be like calling http/1 'tcp'.
| microcolonel wrote:
| The IETF is reserving the QUIC name for the underlying
| transport protocol, which has been separated from HTTP/3.
| Google's QUIC has them tightly coupled, so it's just "QUIC",
| whereas IETF QUIC is a general transport protocol (like TCP or
| SCTP, but technically implemented on top of UDP) for multi-
| stream connections, and HTTP/3 is a HTTP application protocol
| on top of QUIC.
| kbenson wrote:
| Well, why did we call it http/2 and not just keep the SPDY
| name?
|
| Probably because it's easier to know what's being talked about
| if we keep the historical protocol name. If the submission
| title was "The status of QUIC" I wouldn't have remembered it
| had anything to do with HTTP.
| Matthias247 wrote:
| You can use QUIC without HTTP/3. QUIC streams are just
| bidirectional Streams without HTTP semantics, and can therefore
| carry arbitrary data.
|
| The HTTP mapping on top of QUIC is called HTTP/3.
| treve wrote:
| Two reasons I can think of:
|
| 1. HTTP/2 was a 'new serialization' of the core HTTP data
| model. HTTP/3 is too, so since it was ratified it made sense to
| use HTTP/3 to keep things consistent. 2. QUIC still exists, but
| it's now the underlying framing/messaging protocol on top of
| UDP. I can imagine future internet protocols being developed on
| top of QUIC that don't need HTTP/3.
| yeaaaaah wrote:
| Yup. For example there's a draft proposal for DNS-over-QUIC:
| https://tools.ietf.org/id/draft-huitema-quic-
| dnsoquic-06.htm...
| whatsmyusername wrote:
| Yeah I'm not deploying this, pretty much ever.
|
| I'll gladly eat the overhead of TCP to be able to avoid the
| reflection and spoofing issues of UDP.
| Rusky wrote:
| The only reason QUIC is built on top of UDP is because
| ossification prevents it from being built on top of IP. It's
| essentially at the same level as TCP- and provides similar
| mechanisms to avoid UDP's issues.
| jrumbut wrote:
| For the builder of small to medium (say, 10k to 1 million monthly
| users, some media but not the primarily focus) websites, apps,
| APIs, etc, is it time to begin deploying HTTP/2 or even 3?
|
| How would one make the decision, what factors would influence it?
| What are some of the best books/essays arguing either direction?
|
| I believe in maintaining best practices even if you can get away
| with sloppiness on a specific project, to be good and fast at
| doing things the right way, but I honestly can't tell where the
| new protocols fall.
| GABeech wrote:
| HTTP/2 absolutely there are a ton of wins with some of the work
| they did. Especially around content loading and ssl.
|
| HTTP/3? Meh. We've started into the realm of solving google
| scale problems in HTTP standards that have marginal if any
| benefit to the 99%
| xfalcox wrote:
| I created a container image of Discourse using nginx with the
| cloudflare patch to enable HTTP/3[1] and for some reason the same
| config that works fine in HTTP/2 loses the content-type header on
| Google Chrome. It works just fine in Firefox...
|
| 1.
| https://github.com/cloudflare/quiche/tree/master/extras/ngin...
| tambre wrote:
| > with almost 300,000 services using it across the world
|
| The Shodan search given scans headers for all requests. So the
| vast majority of results are sites using Google Fonts, Maps, etc.
| axaxs wrote:
| I hate to be a curmudgeon, but I can't help but think that
| designing a new service over UDP isn't the best idea. DNS has
| been fighting off wave after wave of attack vectors, some that
| realistically cannot even be fixed. Making it immune to these
| vectors is going to look a lot like a slapped together TCP over
| UDP...
| faeyanpiraat wrote:
| curmudgeon (noun): a bad-tempered person, especially an old
| one.
| manigandham wrote:
| Too bad no major internet company wants to implement a new
| version of TCP. We can't even get IPv6 done after 15 years.
| kazen44 wrote:
| implementing a new version of TCP would be nearly impossible
| because of all the equipment out in the field already.
|
| Changing transport protocol is far harder then changing IP
| protocol or layer 2 medium.
| manigandham wrote:
| Why doesn't the IP protocol require new hardware if it's a
| lower layer?
| watersb wrote:
| IP doesn't require new hardware _because_ it 's a lower
| layer.
|
| Transmission Control Protocol - TCP - is baked into the
| firmware of every client network interface card, and I
| would suppose in almost all of the switches and routers
| of business infrastructure.
|
| I have no idea what data centers use. Infiniband and
| similar things aren't TCP, I think.
| john37386 wrote:
| Totally agree with you. Many big corporations totally block UDP
| at ISP level because there is no easy/magic solutions against
| amplified DDoS. They usually use some internal backend for DNS,
| Ntp, routed through other ISP.
|
| I am afraid that businesses that will host HTTP/3 will be less
| secure in terms of availavility.
| microcolonel wrote:
| The fact that many corps block UDP doesn't have anything to
| do with the necessity of QUIC. QUIC is on top of UDP because
| _we tried with SCTP, but is never coming_.
|
| For people who have reasonably configured UDP, it offers a
| benefit; the fact that some people have broken UDP is neither
| here nor there. HTTP/2 continues to be an option for TCP-only
| networks.
| profmonocle wrote:
| > I am afraid that businesses that will host HTTP/3 will be
| less secure in terms of availavility.
|
| Presumably most HTTP/3 implementations will gracefully fall
| back to HTTP/2 (or 1.1) if UDP is filtered. Chrome's existing
| QUIC implementation already does this.
|
| Every Google property has had QUIC enabled for quite a while
| now (at least 4-5 years), so if UDP blocking would cause
| availability issues, affected businesses would've noticed by
| now.
| nikeee wrote:
| It's fun to see how we kind of reinvented goold old DNS as soon
| as we use HTTP/3 for DoH. It runs on UDP, but with HTTP in
| between (and encrypted, of course). We could have done that
| with DNS itself, but somehow this never gained traction.
| baby wrote:
| It is basically TCP 2.0 implemented on top of UDP. What
| concerns do you have with this?
| axaxs wrote:
| Well, I have a lot, but I don't want this to turn into a
| dissertation about why I don't like UDP for most things.
|
| The biggest red flag to me is that it is trivial to make the
| server send sizable packets to clients who didn't ask for
| them nor want them. Spoofing is not a solved problem, no
| matter how many times people scream at providers to block it
| before it gets out. Why isn't there a minimal ACK process up
| front? I mean, this thing is designed such that it's
| vulnerable to reflection attacks on -day 1-.
| zamadatix wrote:
| It is slapped together TCP over UDP. They would rather have
| made it over IP but protocol ossification has made that
| impossible.
|
| Don't think of it being UDP as anything more than "it happens
| to go through existing infrastructure without any or much work"
| paulddraper wrote:
| Forget the narrow waist of the internet; this is the spaghetti
| ball of the internet.
|
| It violates all of the encapsulation and decoupling principles
| you learned about as a CS undergrad.
|
| If you have a better transport layer, fine. Make a better
| transport layer. But rolling the whole thing is the best way to
| ensure nothing will ever get done.
|
| HTTP/3 is the new IPv6.
| yzmtf2008 wrote:
| > It violates all of the encapsulation and decoupling
| principles you learned about as a CS undergrad.
|
| I mean, it's not like encapsulation and decoupling ever
| worked with the networking stack. For example, let's pause a
| minute and think about which layer does TLS or NAT sit in.
|
| To quote @tptacek[0]: _There is no such thing as a layering
| violation. You should be immediately suspicious of anyone who
| claims that there are such things._
|
| > HTTP/3 is the new IPv6.
|
| Funny you mentioned IPv6. The famous article [The world in
| which IPv6 was a good design][1] actually gives some good
| context on why QUIC is needed, and believe it or not,
| layering violation with explicitly mentioned.
|
| [0]: https://news.ycombinator.com/item?id=4556125
|
| [1]: https://apenwarr.ca/log/20170810
| skrowl wrote:
| Seems more verbose than https://caniuse.com/#feat=http3
|
| TLDR - No browsers support it (without flag / config changes)
| yet.
| SquareWheel wrote:
| In the age of evergreen browsers, it's possible to go from 0%
| to 85% in just a few weeks time. Upgrading web servers will be
| the real bottleneck.
| Avamander wrote:
| nginx will get H3 this year, so I think we'll see a massive
| uptick in adoption.
| LinuxBender wrote:
| nice! might be a while for haproxy [1] if ever and i've not
| been on apache's IRC in a long time so no idea if they are
| considering adding it to core.
|
| [1] - https://github.com/haproxy/haproxy/issues/62
| Animats wrote:
| All this to support more ads per page.
|
| All this is only a win mostly if you have a huge number of little
| assets from different sources. Ads, trackers, icon buttons,
| malware, etc. If it's all coming from one source, HTTP/2 is good
| enough. If it's mostly one big file, HTTP/1 is good enough.
___________________________________________________________________
(page generated 2020-01-13 23:00 UTC)