The Status of HTTP/3
infoq.com
infoq.com
(To clarify, nginx's config is also declarative... well, mostly: they got in trouble for mixing declarative and imperative [1].)
You'd be surprised what we've been able to accomplish with upgrades to Caddy's configuration in Caddy 2. Its config is technically declarative, but the underlying JSON structure [2] implies a procedural flow, enabling you to compose certain behaviors that almost feels imperative. When Caddy 2 release candidates go out in a couple months, try it out with both the Caddyfile (soon to be majorly improved in beta 13) and the underlying JSON and you'll see what I mean.
Oh, but if you want to still use your nginx config, go ahead (WIP) [3]. :)
[1]: https://www.nginx.com/resources/wiki/start/topics/depth/ifis...
1. https://github.com/cloudflare/quiche/tree/master/extras/ngin...
I wonder how much bandwidth this will waste globally.
So the number would probably be surprisingly large but also a very small fraction of overall traffic.
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.
Just interesting to contemplate the total effect when you have a userbase like Chrome's.
The Shodan search given scans headers for all requests. So the vast majority of results are sites using Google Fonts, Maps, etc.
I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility.
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.
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.
Don't think of it being UDP as anything more than "it happens to go through existing infrastructure without any or much work"
If ever something seems dumb in network protocol design the answer probably lies with ossification. Hopefully the design of HTTP/3 ends that.
You can use most ports just fine. Multiplayer games show this every day. If those don't work in corporate networks (I include "public" wlan in this) that's fine too. It's not up to you what should be allowed or not in a company setting. ISPs don't block ports just for fun.
And if you are big enough like Google or Facebook, just offer a service only on that port. If it doesn't work, show a warning that the customer should complain to the network owner.
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.
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 was explicitly mentioned.
Transport Layer Security? Transport layer.
> which layer does NAT
Network Address Translation? Network layer.
---
That said, the names aren't as important as the layer and independence. E.g. TLS can be used to secure any TCP traffic: STMP, HTTP, etc.
Same for NAT: https://networkengineering.stackexchange.com/questions/3145/...
> the names aren't as important as the layer and independence
That's the point. Layers don't mean anything in the real world where ossifications are a thing and replacing infrastructures has a cost. There are plenty of protocols that require cross-layer coupling (aka "layering violations") and asking for layering compliance really doesn't make anyone except layering lawyers' life better.
TLS is a encryption layer that works with many protocols. Assigning some special number to it isn't the important part.
Yeah but the point is TLS also doesn't work by just magically changing TCP to TLS (where would you even change that?). It works by using HTTP over TLS. The issue is also not with OSI layers, but the fact that there are dependencies between different components that are supposed to be encapsulated from each other. In this view, HTTPS (HTTP + TLS) isn't really different from HTTP/3 (HTTPS + QUIC).
Changing transport protocol is far harder then changing IP protocol or layer 2 medium.
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.
If you wish you can run IP over Infiniband (IPoIB) but I think most people using Infiniband are running a lower latency protocol like RDMA
https://wiki.archlinux.org/index.php/InfiniBand#TCP/IP_(IPoI...
[0]: https://news.ycombinator.com/item?id=22040780
I enjoy discovering my misconceptions on this topic, as I am no longer building computer networks. Mostly harmless.
In exchange... among other things, it would break all existing NAT implementations, since NAT is based on port numbers and existing devices wouldn't know where to find the port number in the new protocol. So everyone behind a home router would be unable to use the new protocol until they upgraded their router firmware – which of course most 'normal people' never do, so realistically you're waiting years until they get a new router.
Not only is that a gigantic practical disadvantage, it also feels rather inelegant itself. After all, routers shouldn't need to know the details of the transport protocol just to route packets. If it weren't for NAT they wouldn't have to, which is probably why port numbers aren't part of IP itself. NAT sucks. But NAT isn't going away; even on IPv6 some people insist on using it. By tunneling QUIC inside UDP, we at least regain the elegance of separating what routers need to know (IP + UDP) from the real "transport protocol" (QUIC).
The TCP protocol is implemented only by endpoints, at least in principle.
It's the "security appliances", also known as "middleboxes" that are the problem. Think web proxies, antimalware scanners, firewalls, and inline IDS systems.
These things are the bane of the Internet, because they ossify protocols, blocking any further development.
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-.
Amplification attacks and spoofing are taken care of by QUIC, so these are not problems at the moment.
AFAICT, QUIC loosely defines a way to do client address validation, but it isn't required! It's worded as 'CAN' and 'MAY' in places, and places outside the spec basically hint that 'oh no! it adds another round trip'. This makes it feel totally bolted on. Why wasn't it required up front? If someone came up to me with this idea of QUIC, the -first- thing I'd tell them is to solve this problem definitively first. The idea seems sound to me, but not if you let everyone turn it off...
AFAIK it's rather common in multiplayer games to do TCP-like features over UDP, as they usually need the UDP features but also need reliable transport for some data, and it's rather tricky to do both UDP and TCP at the same time.
See for example https://fabiensanglard.net/quakeSource/quakeSourceNetWork.ph... or https://gafferongames.com/post/reliability_ordering_and_cong...
However, that isn't useful by itself. Where it's useful is for attacking a third party. To do this, you spoof the source IP of your query to be the IP of the victim. This is called reflection. See, in TCP, every connection starts with a tiny three way handshake. So if you spoof the IP, the target would just get an unknown SYNACK which is tiny. It wouldn't respond, and nothing further happens. In UDP, there is no such handshake. So the target gets the entire response.
So in short, DNS amplification attacks are only useful with reflection, which doesn't work over TCP.
So this lets you prevent amplification. If somebody asks a question with a long answer, but doesn't provide the token to prove they're on path, you make them go around again first, a legitimate user sees one round trip wasted to get a token but attacks don't work..
Address validation in QUIC is optional, per the RFC.
They tried with SCTP and DCCP.
Unlikely, since TCP + TLS implemented over UDP is a better description of QUIC.
Neither TCP nor UDP were designed when you had to assume the internet to be a battle ground which pitted hackers, police forces, nation states against each other, and you. In such an environment it's not at all surprising to hear Comcast was attacking their own customers using bit torrent or competing video streaming by sending them fake TCP RESETS.
But TLS on the other hand - that's exactly the environment TLS is designed for. They are not going to find it so each to screw with QUIC, because TLS is baked into its DNA.
Is this true.
Below we use HTTP/1.1 pipelining to send multiple requests (30) over a single TCP connection in order to print short descriptions of the last 30 infoq.com articles posted to HN.
http11 ()
{
while read x;do case $x in https://*)x1=${x#https://*/};;http://*)x1=${x#http://*/};;*)x1=${x#*/};esac;[ $x1 != $x ]||x1="";x2=${x#*//};x3=${x2%%/*};printf "GET /$x1 HTTP/1.1\r\nHost: $x3\r\nConnection: keep-alive\r\n\r\n";done|sed '/^$/d;N;$!P;$!D;$d';printf "Connection: close\r\n\r\n";
}
curl https://news.ycombinator.com/from?site=infoq.com|grep -o "https://www.infoq[^\"?]*"| http11 |openssl s_client -connect www.infoq.com:443 -ign_eof -quiet 2>/dev/null|sed -n '/@id/p;/^ \"description\": \"/p'In the example, all 30 requests were sent at the same time. openssl did not wait for any responses.
This example can be repeated again and again and every time, all the responses are received, in order. It is reliable.
Not sure who "you" refers to in the above statement, however if it applies to me then that statement is incorrect. I have been using HTTP/1.1 pipelining outside the browser for decades.
HTTP/1.1 was written for HTTP clients. Browsers are just one type of client, not the only type. More than half the traffic on the internet is initiated by non-interactive clients. Besides headless, that excludes browsers.
From RFC 2616:
user agent
The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
> A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response).
Maybe this was just yet another case where plenty of intermediaries are broken and mass-deployment has always been difficult?
> HTTP/2, derived from the now deprecated SPDY protocol, introduced the concept of first-class streams embedded in the same connection.
Was this not done by SCTP?
* https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
It's just that (a) network boxes often block 'unknown' protocols, and (b) web servers/browsers did not bother implementing the protocol.
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.
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%
Such as connection migration over different networks? Who ever needs that?
"Sorry, call dropped. I was leaving the house and I lost connection to the Wifi..."
Compared with HTTP/1.1, HTTP/2 has known regressions which can be catastrophic on poor-quality connections, mostly due to TCP head-of-line blocking. At Fastmail we found concrete performance problems for some users from deploying HTTP/2 so that we rolled it back for a while and tried again later after shuffling a couple of things around to mitigate the worst such problems (can’t remember what we actually did). But even so, a small fraction of our users will get a worse experience from HTTP/2 than from HTTP/1.1. (Don’t think I’m speaking against HTTP/2; overall it’s an improvement for performance over HTTP/1.1, often a big improvement. But for developing things like interactive apps, it’s helpful to understand the differences and their effects.)
HTTP/3, meanwhile, does not suffer from such problems (which is most of why they made it). The main risk is that it’s less likely to work at all—but browsers take that into consideration and fall back to HTTP over TCP (HTTP/1.1 or HTTP/2) smoothly.
Presuming you have capable server software, I’d honestly consider deploying HTTP/3 to be lower risk than deploying HTTP/2.
One should also consider the robustness of the HTTP/2 or HTTP/3 implementation. Consider such things as this variety of DoS attacks against HTTP/2 from the last six months: https://github.com/Netflix/security-bulletins/blob/master/ad.... It’s improbable that these are are only major attack vectors in HTTP/2 and HTTP/3 implementations.
Consider this comparison between OSI and TCP/IP models from Wikipedia[1]:
> The OSI protocol suite that was specified as part of the OSI project was considered by many as too complicated and inefficient, and to a large extent unimplementable. Taking the "forklift upgrade" approach to networking, it specified eliminating all existing networking protocols and replacing them at all layers of the stack. This made implementation difficult, and was resisted by many vendors and users with significant investments in other network technologies. In addition, the protocols included so many optional features that many vendors' implementations were not interoperable.
> Although the OSI model is often still referenced, the Internet protocol suite has become the standard for networking. TCP/IP's pragmatic approach to computer networking and to independent implementations of simplified protocols made it a practical methodology. Some protocols and specifications in the OSI stack remain in use, one example being IS-IS, which was specified for OSI as ISO/IEC 10589:2002 and adapted for Internet use with TCP/IP as RFC 1142
There's a similar discussion on the TCP/IP article as well[2], highlighting the impracticality of OSI "layers" in terms of implementation.
> The IETF protocol development effort is not concerned with strict layering. Some of its protocols may not fit cleanly into the OSI model, although RFCs sometimes refer to it and often use the old OSI layer numbers. The IETF has repeatedly stated[citation needed] that Internet protocol and architecture development is not intended to be OSI-compliant. RFC 3439, addressing Internet architecture, contains a section entitled: "Layering Considered Harmful".
In practice, a short discussion about SSL/TLS is enough to point the inadequacies of OSI, and orient one towards conforming their conceptual model closer to TCP/IP and relevant RFC's.
The advice I follow personally, given the "popularity" of OSI (people call "layer 1-7" as if it were an actual thing, 90% of the blogs and literature uses the OSI model), is to simply translate into TCP/IP lingo/concepts in your mind whenever you read/speak about it. Not everyone will get it around you, but at least you'll have a more solid implementation should you be working with low-levels of the net stack.
For reference, RFC 1122[3] defines the Internet Protocol Suite with 4 layers: application, transport, internet (or internetwork, the idea of routing) and link. Does not assume or require a physical layer in the spec itself — hence it works on 'anything' from USB to Fiber passing by Ethernet or Bluetooth and PCIe/Thunderbolt if you just follow the protocol.
[1]: https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/...
[2]: https://en.wikipedia.org/wiki/Internet_protocol_suite#Compar...
But it's not "the" only way to do it and following it doesn't guarantee a better outcome than not following it. Still, I thought it was a good way of presenting the material, but then I came across student after student insisting it was the only possible way to structure network stacks. It's not. Despite being a ISO standard, no real follows it exactly. It's prime use just an educational tool.
I see that the WG charter has one milestone in May 2020, and Daniel Stenberg of curl has mentioned early 2020 before. In addition, AFAIU, both Chrome and Firefox have implementations ready, though still behind flags.
Is it likely that we'll see actual deployments and a wider rollout already in 2020?
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.
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.
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.
The HTTP mapping on top of QUIC is called HTTP/3.
Something similar happened with SPDY (Google's experiment) and HTTP/2 (IETF standard based on SPDY).
TLDR - No browsers support it (without flag / config changes) yet.
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.
I'm also very afraid of the future of Web Assembly.
Both of these technologies i'm afraid aren't going to make things better, faster and more lightweight. They are just going to allow the bloat of the web to become worse without noticeable symptoms.
This is a problem with computers in general. For example IDEs and simple electron apps taking huge amounts of memory.
(Any introduction on QUIC will explain you these if you are interest.)
If no, then QUIC has failed its purpose, for the tech-savvy browser users at least.
If yes, I'd be happy.
But if browsers like Firefox find a way to skip ahead in the stream (through the ads/trackers while never downloading/parsing them in the first place) then things could be back to normal (for us the ad-blocker users).
Still though, if used for good, QUIC (or HTTP/3) seems like a pretty good piece of tech.
I should have worded my comment better. It wasn't a claim, it was more like a "I think Google wants this protocol to succeed for their own ulterior motives (serve ads and impede blockers), but is that what is actually going to happen?".
I'll gladly eat the overhead of TCP to be able to avoid the reflection and spoofing issues of UDP.
Apple has shown that TCP is not ossified. They have innovative features like Path MTU probing/blackhole detection [1] and multipath TCP [2].
[1] This actually isn't innovative, but Android hasn't enabled it, even though it was widely available since before Android existed; maybe enabling it is an innovation?
[2] Initially for Siri only, but now available to applications if you make the right incantations. I haven't been able to actually use it, and I'm pretty sure there's some hidden performance issues. For example, there's no reasonable way to make all the substreams of a MPTCP connection go to the same network queue, and you probably want that for performance, but that would be a problem with QUICs multipath features as well; I haven't seen if anybody made reasonable configuration for MPTCP yet, either.
Whitelisting patterns are incredibly common. Breaking that breaks a lot of stuff.