HTTP/3 for everyone
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46970 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 202086 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
Bit rateQuicksortPulse (signal processing)Projective planeMultiplication signComputer animation
00:38
Self-organizationBitShift operatorNumberComputer animation
01:24
NumberCommunications protocolMultiplication signDependent and independent variablesClient (computing)Particle systemQuicksortBitServer (computing)EmailComputer animation
02:00
Server (computing)LengthHTTP cookieData typeContent (media)EmailCodeSoftwareLink (knot theory)Connected spaceMultiplication signQuicksortReading (process)Streaming media40 (number)InternetworkingState of matterStructural load19 (number)Computer animation
03:00
Host Identity ProtocolTransport Layer SecurityWeb pageGraphical user interfaceWeb pageStructural loadWeb 2.0Heegaard splittingComputing platformGraphical user interfaceTwitterMixed realityQuicksortInformation securityFacebookComputer animation
03:49
Transport Layer SecurityInformation securityInformation privacyRoundness (object)Information securityConnected spaceInformation privacyTransport Layer SecurityServer (computing)QuicksortPlanningComputer animation
04:31
Parallel portFrequencyNumberMedianWeb browserEmailConnected spaceObject (grammar)Web pageHeat transferLine (geometry)WebsiteMedical imagingEntire functionParallel portComputer fileQuicksortMultiplication signView (database)Communications protocolClient (computing)Finite setObservational studyComputer animation
07:09
Communications protocolConnected spaceParallel portEmailLine (geometry)Block (periodic table)SoftwareStreaming mediaSingle-precision floating-point formatInternetworkingBand matrixÜberlastkontrolleTwitterCuboidBit rateMusical ensembleMereologyGame controllerSound effectWeb 2.0Multiplication signComputer animation
08:07
InternetworkingRouter (computing)Computer networkSoftwareCommunications protocolInternetworkingSound effectStructural loadSoftwareCuboidPoint (geometry)Parallel portMultiplication signQuicksortServer (computing)RepetitionRule of inferenceWeb browserRange (statistics)Computer animation
09:08
InternetworkingEncryptionSoftwareWebsiteCuboidQuicksortSound effectVirtual machineMultiplication signBitCommunications protocolServer (computing)Connected spaceOperating systemWeb browserNumberKernel (computing)Open setEncryptionElectronic mailing listDefault (computer science)Router (computing)Level (video gaming)Online helpEmailComputing platformNoise (electronics)TwitterData compressionComplete metric spaceExtension (kinesiology)Condition numberWeb 2.0WindowProcess (computing)InternetworkingParticle systemTheoryOperator (mathematics)Block (periodic table)Computer animation
12:40
QuicksortCASE <Informatik>Group actionHypermediaComputer animation
13:18
Communications protocolGoogolGroup actionCommunications protocolGoogolSoftware testingLine (geometry)Frame problemQuicksortRevision controlOSI modelClient (computing)Stack (abstract data type)Cartesian coordinate systemMultiplication signService (economics)EncryptionServer (computing)Scaling (geometry)Condition numberPlanningMultilaterationWeb 2.0Computer animationSource code
15:36
IP addressConnected spaceEmailQuicksortSoftwareDifferent (Kate Ryan album)Multiplication sign1 (number)EncryptionSoftware developerPattern languagePhysical systemMereologyStructural loadRight angleCuboidInterface (computing)Group actionNoise (electronics)Disk read-and-write headLine (geometry)Electronic mailing listRevision control
17:26
UDP <Protokoll>Communications protocolSpacetimeTransport Layer SecurityControl flowOrder (biology)DataflowSpacetimeCommunications protocolBitGame controllerOrder (biology)QuicksortConnected spaceStreaming mediaDataflowInformation securityInternet service providerString (computer science)Particle systemLogicProcess (computing)1 (number)Computer animation
18:26
Similarity (geometry)Server (computing)Client (computing)Independence (probability theory)Streaming mediaConnected spaceDataflowCommunications protocolBitPoint (geometry)QuicksortWindows RegistryMedical imagingSound effectTerm (mathematics)Order (biology)Right angleChainLink (knot theory)Computer animation
19:44
Independence (probability theory)Link (knot theory)Streaming mediaCommunications protocolIndependence (probability theory)Medical imagingChainRow (database)Right angleCartesian coordinate systemTwitterFreewareTrailComputer animation
20:18
Communications protocolDirect numerical simulationCommunications protocolStreaming mediaQuicksortFreewareFocus (optics)ExistenceCartesian coordinate systemMultiplication signMultilaterationMereologyScripting languageParticle systemEmailArchaeological field surveyFlow separationDependent and independent variablesComputer animation
21:21
EmailCommunications protocolEmailDependent and independent variablesBinary codeTDMAQuicksortTranslation (relic)SoftwareRight angleComputer animation
22:09
Stack (abstract data type)Transport Layer SecurityUDP <Protokoll>BuildingSoftwareTransport Layer SecurityStack (abstract data type)View (database)Streaming mediaQuicksortRight angleRevision controlComputer virusPairwise comparisonComputer animation
22:45
Pairwise comparisonServer (computing)Hacker (term)EmailData compressionRevision controlType theoryDifferent (Kate Ryan album)Web browserQuicksortRevision controlStreaming mediaData miningGraph coloringComputer animation
23:29
Fitness functionConnected spaceGoogolNumberPairwise comparisonStreaming mediaSoftwareCommunications protocolType theoryCASE <Informatik>Goodness of fitParticle systemIndependence (probability theory)Wave packetCodeSystem callComputer animation
25:18
Uniform resource locatorService (economics)InternetworkingMathematicsServer (computing)Optical disc driveEmailComputer animation
25:58
EmailDependent and independent variablesCommunications protocolWebsiteGame theoryInternetworkingSelf-organizationWeb browserFrequencyClient (computing)Multiplication signBlock (periodic table)Server (computing)Service (economics)Communications protocolDenial-of-service attackLaptopParticle systemScaling (geometry)Computer animation
27:07
Direct numerical simulationConnected spaceWeb browserLaptopEmailDirect numerical simulationServer (computing)Public key certificateService (economics)WeightSoftware testingComputer animation
28:16
UDP <Protokoll>AlgorithmClient (computing)Density of statesClient (computing)AlgorithmService (economics)LastteilungStructural loadSelf-organizationConnected spaceDenial-of-service attackDirect numerical simulationReverse engineeringMultiplication signFrequencyLine (geometry)Point (geometry)Server (computing)Dot productInsertion lossBlock (periodic table)Computer animation
29:37
BefehlsprozessorStack (abstract data type)UDP <Protokoll>Computer hardwareComputer hardwareTransport Layer SecurityHeat transferBitMultiplication signKernel (computing)Server (computing)CryptographyQuicksortBand matrixBefehlsprozessorSubsetSpacetime1 (number)Musical ensembleVolume (thermodynamics)Right angleVery-high-bit-rate digital subscriber line
30:56
Transport Layer SecurityMessage passingQuicksortCryptographyGoogolRow (database)Medical imagingMessage passingTransport Layer SecurityRevision controlBit
31:45
Transport Layer SecurityLibrary (computing)Frame problemMessage passingStack (abstract data type)QuicksortCryptographyPoint (geometry)StatisticsParticle systemNeuroinformatikComputer animation
32:29
Stack (abstract data type)Standard deviationKernel (computing)ImplementationSpacetimeSoftware developerGroup actionKernel (computing)Communications protocolRevision controlMultiplication signStandard deviationQuicksortInteractive televisionCartesian coordinate systemLibrary (computing)Right angleProcess (computing)Software testingParticle systemAreaWeb browserResultantDirection (geometry)Residual (numerical analysis)GoogolComputer animation
34:00
QuicksortBitService (economics)Core dumpImplementationNumberVisualization (computer graphics)WindowBlogLogic
34:50
MathematicsGroup actionComplete metric spaceMultiplication signSlide ruleLie groupComputer animation
35:43
FacebookGoogolPoint cloudData typeErlang distributionJava appletImplementationLatent heatStack (abstract data type)Goodness of fitFormal languageInterrupt <Informatik>Degree (graph theory)NumberComputer animation
36:17
ImplementationGraphical user interfacePatch (Unix)Right angleNumberOpen sourceMathematicsServer (computing)Web browserTrail1 (number)WordPatch (Unix)2 (number)Standard deviationLibrary (computing)Revision controlStreaming mediaOpen setHypermediaComputer animationPanel painting
37:48
Web browserComputer networkRevision controlWeb browserSoftware testingServer (computing)FacebookPoint cloud1 (number)Computer animation
38:26
HTTP cookieRevision controlLibrary (computing)Figurate numberServer (computing)Front and back endsDifferent (Kate Ryan album)Core dumpLatent heatRight angleSource code
39:03
Server (computing)Web browserLibrary (computing)Transport Layer SecurityServer (computing)Alpha (investment)Web browserLatent heatFacebookRevision controlService (economics)Right angleMultiplication signComputer animation
39:52
Term (mathematics)Multiplication signLine (geometry)BitTerm (mathematics)QuicksortStreaming media
40:37
Communications protocolCartesian coordinate systemStreaming mediaRevision controlCommunications protocolQuicksortError messageVideoconferencingWebsiteRight angleProduct (business)Computer animation
41:13
Different (Kate Ryan album)Scripting languageWeb 2.0Right angleMereologyMultiplication signTheoryWebsiteNeuroinformatikCommunications protocolComputer animation
41:59
Similarity (geometry)Multiplication signService (economics)Server (computing)Slide ruleComputer animation
42:47
Point cloudOpen sourceFacebookComputer animation
Transcript: English(auto-generated)
00:11
I'll just speed it up a little bit. Then I'm going to talk about HTTP3 today for everyone. So I'm Daniel. I've been here before. This is my 11th talk at Fostum, actually.
00:21
And if anything, this sort of audience makes your pulse go up a little bit. But I started doing HTTP a long time ago. I had this little hobby project. Some of you might have known it. I started it, and I worked with it daily since then. It's fun. You should try it. I work for WolfSSL doing cURL stuff every day.
00:42
But today I'm going to talk about stuff done within the organization IETF, where I'm participating and working with a lot of other people. So this is what I'm about to try to squeeze in, my 45 minutes or so. So we did HTTP 1, 2, and we're going to 3.
01:01
There are some problems along the way. That's why 3 is coming, right? I'm going to explain a little bit about them, how QUIC is the solution to those problems, and a little bit about HTTP 3 on top of QUIC. Some of the challenges with running this tomorrow or now, and something about it when it's about to come,
01:20
or maybe, I don't know. So I talked about this last year. Yes, this is not exactly the same, I promise. But you might recognize a few things, because HTTP 3 is still number 3. So this is how it started. This is a picture from the 90s. We started with HTTP 1, actually. It shipped in, well, HTTP 1.1, no, 1.0, actually,
01:43
shipped in 1996, and then took a long time, and then we did HTTP 2, 2015, and now we're working on HTTP 3. So let's get a little bit faster. So HTTP is this protocol. You've all seen it, you'll play with it. It looks like that. A client asks for something from a server. Request and a header is a new server response
02:01
with a code and a header is on the body and stuff. You've seen it. It's there, it's going to be like that in the future as well. So HTTP, we started out this journey over TCP, while we still do it with TCP. So TCP, Networking 101, is like a chain of links.
02:24
Basically, IP packet is connected, so we send them over the wire, and establish a connection. There's a three-way handshake. Ping, pong, ping, to establish that connection. Three ways, three times across the network, and we get that connection and we can send data over
02:42
in a reliable byte stream, sort of. And it's in clear text. So anyone reading or snooping on the network can see your traffic. TCP, the first RFC, 1981, celebrating 40 years next year. Trust it, we know it, we've used it, it works. It's there, yep.
03:00
But we're talking HTTPS these days, right? So HTTP works over TCP, but we're not talking HTTP clear text, we're talking HTTPS. And do we? Yes, we do, because page loads done by Firefox on the internet today, well, this is divided by continents from Firefox data.
03:20
So yeah, there's somewhere around 80%, maybe more, maybe up to 90% of all page loads, HTTPS. Basically, the web is going HTTPS. The same data from Chrome split on platforms is dead. Yeah, some of them upwards 90, some of them only 70. But that trend is rather clear. It's growing, the web and everything is going
03:42
more and more encrypted, we're talking HTTPS. So it's not only HTTP, right? HTTP over TCP, but we're talking HTTPS here, so we're adding TLS to the mix. TLS is that transport layer security. We add on top, or sort of, so that we get security. And with TLS, we usually also add another extra
04:01
round trip to get that TLS connection. One, actually, sometimes four, back and forth. Anyway, it depends on version and stuff. So with this, we get privacy and security. Nobody can snoop on your traffic, nobody can change your traffic, and you know you're actually sure that you're talking to the right server in the other end. Excellent, that's what we need. So this is what we have.
04:20
We have IP, we do TCP over that, we have TLS to secure that, and we do HTTP over that. HTTPS, what we know and use and love and everyday, everywhere. So back again, TCP is done over, sorry. HTTP is done over TCP. So we started out, actually, HTTP 1.1,
04:40
the great improvement to HTTP 1.0, was shipped in 1997. It was a great improvement to 1.0 because we suddenly fixed how we used TCP connections. Now we could reuse TCP connections. We couldn't do that with HTTP 1.0, yay. But over the years, people come up with, you know, we want to have many images, many of our scripts, many style sheets,
05:01
hundreds of objects on every page. Wait a minute, we only have how many connections? Let's come up with new ways to do more connections in parallel. So all the browsers today do many connections in parallel, and you can trick it to do even more parallel connections. So we went to that world, so now we're into a world
05:21
with a lot of parallel connections, so many that we have to kill them off really often because there are too many to keep up all the time. So the median number of HTTP requests done per TCP request in Firefox is one. So basically, they're all created, created, created, created, used, shut down, shut down, shut down, created, used, shut down.
05:40
And TCP is really inefficient in the beginning because it has a slow start period. So they never get up to speed. So within HTTP, one of one world, we can never use TCP good enough to actually get fast transfers. That's just it, it doesn't work. And we also got this fine thing
06:00
that we call HTTP header line blocking because we have a finite number of connections, typically six per host name by a browser. And your typical website has many more than six objects. It's a hundred images and style sheets and stuff. So you have to use those six connections to download those hundreds of objects. But on which of those six connections
06:21
will you put your next request for the next object? It's a really difficult problem. It's like in the supermarket when you have those line to cashiers. Which one is the fastest? Not the one you pick, right? That's gonna be the trainee or something. No, you never know or annoying customer ahead of you. The browsers and HTTP clients, they have this problem.
06:44
And of course, the entire world and everyone in here too have come up with fine and ingenious ways to work around these problems. Put everything in a single file. Put all JavaScripts in a single blob. Do whatever fun things. Invent new host names so that the browser
07:01
will do many more connections. So yeah, you can be creative. But to sort of combat all those funny workarounds and take a unified effort, we created HTTP2 and shipped that in 2015. So all those funny workarounds into the protocol instead. And now we're going into a world with a single connection per host. Not 48, one.
07:21
That's much better because now TCP can get up to speed. We can saturate the bandwidth in both directions much better. Congestion control, everything is fine and dandy. We have many parallel streams over that single connection. So we get many more, much better parallelism. But instead we fell into another trap. Oh, now we've got TCP header line blocking instead of the previous HTTP header line blocking.
07:42
So now we have, typically we can have a hundred streams over that single TCP connection. And when we lose one little packet because we have a corrupt network and we need to retransmit that single packet, 100 streams are waiting for that single packet to get retransmitted. And then it gets retransmitted and 100 streams can continue again and then we lose another packet.
08:01
Everyone has to wait. Not ideal. And at the same time, a long-going trend in the internet is this thing we call ossification that's been going on in parallel with everything else. Ossification is this effect that, you know, everything is full of boxes, or the internet is. Riders, gateways, load balancers, Wi-Fi routers,
08:22
whatever, a lot of boxes out there. And they're all installed at some point in time in your networks and they run software and they all know how the network works at the time you install that box or someone installed that box. They very rarely actually know how the future is going to be and they're all afraid of the future. So they know, sort of, if it was a zero today,
08:42
it will never be anything else but zeros. We know that. So, and we never upgrade these boxes. We buy them and put them in the networks. We upgrade our servers, we upgrade, well, we do, actually, some of us do. Well, every year or so. And the browsers, you know, they upgrade themselves basically every week, sort of, automatically. So the edges, they upgrade.
09:02
The middle, it's stuck in time. And they know how the network worked when we got those boxes and installed them five years ago, 10 years ago. I'll just, sort of, just really drive this in. So that's me and there's the website and all of those little machines in there, they're middle boxes somewhere. They're stuck in time and their mission is to drive the network as the network worked
09:22
when we installed them. Today, yesterday, a few years ago. This has a fun effect. Fun. Oscillations, we call it. And some things like, wait a minute, you can do HTTP2 in clear text? Right, you just upgrade to HTTP2. You don't have to do that over HTTPS.
09:41
In theory, right, because a lot of these boxes, they know that if you speak TCP port 80, that means HTTP 1.1. So whatever you speak on TCP port 80, those boxes will help you speak HTTP 1.1. So if you speak something else, they will just ruin your traffic completely. This, to the extent that no browser today uses it,
10:03
and one browser in particular specifically intended to, yes, we were going to support it until they tried and figured out that a lot of boxes help you. So no, you have to hide your traffic in encryption to make sure that it actually works. And wait a minute, we can improve TCP instead of doing it.
10:21
Why not invent a way to send data earlier in the TCP handshake? We can call it TFO, TCP Fast Open. It's an invention from 10 years ago, so excellent. So if you talk to a server before, you can send data already in the first packet in the TCP handshake, you know, that three-way handshake. Much faster, you can earn, you can gain a lot of latency there.
10:41
Let's do that. It took five, seven years until all kernels of these three big platforms supported it. Yay, now we can do it on Windows, on Mac, and Linux. The browser started to try it. Does it work? No. Those boxes, you know, they know, they know how a TCP header is supposed to look like. So if you set those little extra bits in the TCP header,
11:02
it says, try TCP Fast Open, a number of them will just float away. So the TCP Fast Open turns out to be, TCP falls slow open in quite a number of times. So now no operating system and no browser enables TFO by default because it doesn't really work across the web.
11:21
And sort of this list goes on. If you wanna try to introduce a new transport protocol, you know, next to TCP and UDP across the internet, it doesn't work either because your Wi-Fi router at home, it can only net those two protocols and nothing else. It'll just stop already there. So no, it won't be any new transport protocols either.
11:40
So we can invent stuff over HTTP level is that it brought place a compression algorithm much better than G-SIP for some purposes. Excellent. Wait a minute. A lot of those boxes, they know HTTP compression. That means G-SIP. So if you send compression, it'll help you. So X percent of those connections
12:01
will simply get ruined traffic because some boxes in between have fixed your traffic along the way. So of course the browsers can do Brotli but they only do Brotli now over HTTPS connections. So hide it from all those boxes. Encrypted is fine. So basically this trend goes on. So this completely stops future innovation
12:20
in a lot of these protocols. If you do it in the clear, someone along the way will ruin your day and it's not going to be fun. So we need to encrypt more. More and more encryption. Make everything a random noise to every box in between and they don't know what it is. They can't ruin it. So that's the way we're going.
12:40
So we need to improve them in spite of this ossification thing by simply making sure that they cannot see what you're doing, they cannot sort of, this is the way it's going to be forever just because we did it today. That's one of the things that sort of led to the creation of the QUIC working group in the IETF.
13:01
That's the official logo and I just want to drive a special thing home. QUIC is a name, not an acronym. Whatever you think. It doesn't stand for anything. It's a name. Why is it all in uppercase? It's that we can shout it, I think. But it's a name. It doesn't stand for anything. So a lot of companies immediately took interest in this.
13:22
All of these are and more are sending people to this working group in the IETF and it has been a fierce participation and activity since it started in 2016. So this is a new transport protocol
13:41
even though I said you can't do it on TCP to P layer, but still. So this is built again on experiments and tests from Google. Pretty much they did it with HTTP2. You remember they did SPDID that became HTTP2 eventually from the IETF. Now they did their experiments
14:00
and to make everything more complicated this time they call it QUIC and let me go back to that. So they deployed this already in 2013 so it's been going on for a while and they have a fairly, you might not know this, but they have a fairly well used client and some popular services and that makes them an excellent place to do these wide scale experiments.
14:23
Does it work really? A billion clients against our billion servers. So yes, they proved that it actually works and it improves a lot of things. So they took that to the IETF in 2015. Let's make this a standard instead of us making funny things in our corner. So yes, the IETF agreed
14:41
with a bunch of caveats and conditions and it created the working group for QUIC in 2016. Two of the conditions, well I can basically possibly add this first, say that my first line here, Google created QUIC, their version of QUIC,
15:01
basically sending HTTP2 frames over UDP and sort of demuxing it in the other end and inserting it in your HTTP2 stack. Sort of just translate it, send it to a UDP, translate it back as HTTP2. And in the IETF they said, well that is a really weird sort of layer violation. Why would you do that all in just one mushy layer?
15:21
Let's split it up. Let's make it a transport protocol and an application layer protocol. So we do QUIC and we do an application layer on top of that. And we need to have proper encryption and not your homegrown thing. We're going with TLS. So when you do a new transport, you can do a lot of things.
15:40
You can fix this head of line blocking problem. I'll get back to how that works. And why not fix that TFO thing I mentioned some data earlier in the handshake? Now I have a sort of a new chance to fix all those problems we've had in transport since that first RFC 1981. A lot of transport people, they have sort of a piped up list
16:01
of fun things to do in transport. Woo hoo, with a chance to redo it. So a lot of fun things are coming in. And for example, why tie a connection to your IP, right? We did that back in the 80s and I don't think anyone really expected the explosion of IP addresses per host. So when you're walking out from your WiFi
16:23
to your cellular network, you have two different interfaces in your system and you have different IP addresses. What happens with your connection? In a TCP connection world, that's tied to your IP address which is tied to your network interface. You have to open a new connection, not with QUIC, but it's because it's not tied to your IP. It can transition between the network interfaces
16:42
because it's tied to your connection ID. And more encryption, always encryption. There's no clear text version of QUIC. It's even more encrypted than TCP with TLS because it's fewer parts of the header in the clear. So basically a few clear text packets
17:00
in the beginning in the handshake, then everything else encrypted. Just the encrypted basically noise to everyone in between. So this is hopefully going to make it sure, may ensure that we can do future development. Hopefully this means that we can make a QUIC version two in the future without a load of those boxes knowing
17:21
and drawing conclusions from the traffic patterns because there shouldn't be much of a traffic pattern. So we build this on top of UDP. We pretend basically that UDP is the IP. So we move everything up one layer. We do everything over UDP.
17:40
We write a reliable transport protocol in user space and we're sending everything over UDP. It's a little bit like reinventing TCP and TLS in one layer and do it over UDP. And no, it's not UDP. We're using UDP when it is not UDP. So UDP, you send whatever you want.
18:01
It might end up in the other end. It could actually change the order. There's no resend, there's no flow control. But we're not doing that. We're using UDP. So we do have to add a lot of stuff on top of UDP. So we add connections and reliability and flow control and we have streams and we have security and stuff on top of UDP.
18:20
So QUIC is a new transport protocol. TCP is out, QUIC is in. So QUIC also then provides streams, for example. So what we had before in, for example, HTTP2, we have it in other protocols too, like SSH or SCDP. We have individual logical streams within the connection.
18:40
So we can actually send many logical flows with a single connection. And you can actually start them from both ends and you can actually make them bidirectional or unidirectional. A little bit more complicated than before. And possibly the biggest point with these streams
19:01
is that they're independent. What does that mean? Why sort of they're independent? That means that if we send them, we know what's in each packet when we send QUIC. If we lose a packet along the way, we know which streams those packets affect. So if we have 100 streams again, we lose a packet, we know which streams are in that lost packet.
19:22
The other streams can go on. So maybe there were two streams affected by that packet. Then the 1998 streams can go on and continue. And just those two streams waiting for that lost packet have to wait. Retransmit that lost packet and those two streams can go on. They're independent, but internally they're all reliable
19:41
and in order and everything. So just to sort of illustrate that with some fun image that I could draw. So TCP, I'd like to illustrate again like a chain with individual links. And here, if you're sending two streams, the green stream and the red stream, if you lose one of those, the green one, the red one also has to wait, right?
20:01
Because it's one single link. If one link is gone, we have to wait until that link is repaired. But in QUIC, the streams are independent. It doesn't matter if we lose a yellow one, the blue one can go on anyway. They're independent. So that's a transport protocol QUIC. So when we do, we provide a transport protocol called QUIC.
20:22
We put an application layer on top of that, right? And the application layer gets streams for free because it's in the transport layer. So it could then virtually be any protocol. And when they brought, when Google first brought this to the IETF, the first discussion was like,
20:40
yeah, we should make sure that it works with more than one protocol, not only for HTTP. We should start with DNS and HTTP. Great, but a little time consuming. So we'll just postpone the DNS part, and focus on the HTTP one. But it doesn't matter. But the intention is there, and the separation exists. So it is actually an application layer on top of a transport layer.
21:03
So there will definitely be more protocols on top of QUIC once QUIC ships because there's sort of a piped up demand. A lot of people are just waiting for QUIC to ship to make sure that they can make their protocols translated over to QUIC instead of TCP. So that's QUIC. That's a transport protocol.
21:21
So when we talk about HTTP three, that's how we make HTTP over this new transport protocol. HTTP is the same, as always, right? That's me, and that's the server, and we send the request, and there's a method and path, you know, headers, maybe a body, and we get a response and headers and a body. I showed you in the beginning.
21:41
That's HTTP, and it's still going to be that. Most people are not going to care about how it's being transferred over the wire. It doesn't matter. This is HTTP for us. HTTP is the same but different. We started out with a protocol in ASCII. We translated it to HTTP two. We did everything binary, and we did all the multiplexing in the HTTP layer, and now we took away the multiplexing
22:02
and put it in the QUIC layer instead, but it's still basically HTTP two like done over QUIC. So just back again to how this sort of translates to a network stack view. This is the IP, and this is the old one, right? HTTP one, HTTP two, pretty much the same.
22:21
Right, HTTP two actually says that you have to use TLS one or two, but anyway, it's the TLS layer. But instead now, we're building on UDP, and we put this huge QUIC blob there, TLS one or three, and we add HTTP three on that, and the streams have sort of moved down one layer. A lot of new stuff, right? At least in sort of, there's a lot of things
22:42
to make QUIC work, but HTTP three is not that different than HTTP two. So if you just look at sort of a basic feature comparison, yeah, we have a different transport, we have streams, we can do, we cannot do clear text versions anymore, but in practice, we don't do that with HTTP two anyway,
23:01
because of what the browsers do. The streams are independent, but that's sort of a minor difference. We're going to do header compression, and we're gonna do server push, and possibly better early data, but they're all sort of, yeah, we're doing the HTTP two like features, but it's now HTTP three because it's over QUIC. And we're changing the prioritization thing over HTTP three.
23:22
It's actually completely gone right now in HTTP three. It is messy in HTTP two, and in 35 minutes, you can hear a talk by Robin Marks about it. It's fun subject, but no, you're not gonna fit in the room anyway. So is this gonna be faster, better, cooler, whatever?
23:43
I think it's going to be faster, thanks to QUIC, because QUIC is going to make your handshakes much faster. Early numbers from Google from years ago when they tried their version, show that upwards around 70% of the connections they saw were able to establish in a zero RTT way,
24:02
basically no handshake at all because you'd had the connection with it before. And zero RTT is much fewer RTTs than five or seven of what you get with TLS and TCP. And you get early data that actually works, so you should be able to send a lot more data much earlier in the handshake.
24:20
So yes, it should be a really good latency improvement for those first important packets, especially in HTTP and such protocols. And the independent streams are really gonna be good, especially for you with good, crappy networks, which typically haunt us in the Western world. But the worse network you have,
24:40
the better QUIC and HTTP3 is going to get, I think, in comparison to previous protocols. By how much, I won't show you any numbers, because we're still in early days. It hasn't been shipped, the protocol isn't done, there is no done codes, and nobody is actually willing to stick out their necks
25:01
and say exactly how much faster it'll be or not, so it remains to be seen. Numbers from Google QUIC days showed that it can be better, from a little better to much better, depending on your use case and what you're doing. Okay, so how do you get to this world of HTTP3
25:21
over QUIC that is done over UDP when HTTPS colon slash slash means TCP, right? So if you ever tried to check the internet, you've seen these URLs in a few places, they're not really possible to replace, right? We can't change these to anything else. We have these HTTPS colon slash URLs,
25:42
we have to work with them, and they actually imply that you connect to TCP port 443 with a TLS establishment afterwards or on top. So how do you get to HTTP3 from that? Easy, you use this fun header, this service over there.
26:01
So you have an old service header, so you actually have to connect to the server with the old-style legacy HTTP2 or HTTP1 first, and talk to it, and you get a server back that says, hey, I'm also available over there for this period of time, and I speak this protocol over there. So that's how you're supposed to do this, per the specs.
26:23
So of course, your browser won't, it'll do this in the background, of course, and try. If it can do this, it can upgrade and use HTTP3 the next time you go to that server. But you also end up in this fun situation that UDP, wide-scale, really high-speed internet data,
26:41
that's something new. Most organization and companies, they have basically blocked UDP already because that's mostly done for DDoS attacks and stuff. So block it or throttle it. So when you do that, my server's over there, and your client tries to connect to it, many times it won't work because your organization or your company have blocked UDP.
27:01
So when you shut down your laptop and bring it home again, it'll work because at home you won't block UDP. So I'm sure that browsers and other users, they're going to raise these connections. Why not just try both, right? Try the old connection and the new connection at the same time. And as I said, it's going to be needed anyway because when you shut down your laptop
27:21
and you bring it home and you open it up again, maybe HTTP3 works now, maybe it doesn't because someone is going to block it in one of the situations and not in the other. So there's going to be a lot of probing, trust testing, raising them against each other. And quick connections are verifying the server certificate anyway, right?
27:41
So even if you just make your bet, it might be a quick server there. And if it connects, you know because you validate the server certificate. So you know that you actually connect to the correct one anyway. And there's also another effort in DNS. It's called quite a mouthful, HTTPS-SVC, which is basically the old service header put into DNS.
28:02
So you're supposed to look up in the DNS first if you'll be able to connect to the server or which server to connect to when you want to speak HTTP3. So that's how you're supposed to do it. So, okay, assuming this all lands and how will we do this? Will it work?
28:20
Will HTTP3 be the best thing ever starting immediately? So there are a few challenges. First, there are some things. We do this over UDP. I mentioned a lot of organizations and companies block connections. So somewhere around three, seven, 20% of connections from clients to service will just fail because someone along the way has blocked UDP
28:42
because UDP is bad and it's mostly DDoS anyway. DDoS and DNS. So all clients that need to have fallback algorithms and they have to work transparently because that's what your users wanna use, right? And this also have this, of course, the reverse incentive that since everyone is gonna fall back anyway,
29:02
it's pretty easy to block UDP because most clients will just silently fall back anyway. So it's going to be interesting. And, right, it's a challenge for the deployment side. If you run up, you deploy your servers, but the traffic, it looks like a DDoS attack.
29:21
So you need to handle that in new ways that you didn't do before. Actually, I think the deployment of the service is going to be possibly the most challenging things because you're not going to run things, your load servers, load balancers and everything. It's going to be new, new things. And so, okay, it only takes about three times the CPU
29:45
before to sort of serve the same bandwidth as you did with HP2. And that's quite a big investment. Maybe that will make you hold it off for a little while. But, I mean, it's still early days. And why does it do this?
30:01
How can anyone accept this? But first, it has this amusing situation that UDP is really unoptimized in Linux, and you would imagine that UDP is really dead simple. Why would that be more inefficient than TCP? But we've actually been polishing TCP for decades, because we've used that for high-speed transfers. UDP, eh, not so much. So there's a lot of things to work on
30:21
to make sure that UDP is faster in the kernels. And, for example, we have really crappy APIs for UDP from user space. So they're really not made for high-volume UDP speed transfers. That is also being worked on. And, of course, there's no hardware offload for QUIC.
30:41
And anyone who knows a little bit about serving TLS in a big server form, you have hardware offload to take care of the crypto stuff in TLS. That's not there for QUIC yet, because TLS is different in QUIC. I'll get back to that about now. So when Google took their version of QUIC,
31:04
which then confusingly is also called QUIC, we call it Google QUIC to sort of, but QUIC became QUIC in the ITF, and they had their own crypto when they brought it to ITF, and ITF said, we can have it like that, we need to have TLS 1.3. This was actually slightly before it became an RFC
31:20
and everything, but sure, we now have TLS 1.3. But TLS is made to be done over TCP. And now to just be a little bit technical here, but we send records of TLS over TCP. Basically, and over QUIC we send messages,
31:41
because TLS records contains messages. Basically, it looks like this. I'll just show you a little image. So this is how you do it over TCP. So you have to send frames like this with messages inside. But that seemed completely pointless. Why would you have those frames? You don't need them when you do it in QUIC, because QUIC is a new protocol,
32:01
so we can just send the messages. Fine, that's sort of, get rid of the crap we don't need, just send the messages. Well, apart from the little detail that no TLS stacks have APIs for this. So yeah, we just have to fix all TLS libraries, right? ECPC. So, and they also need a few other crypto secrets exposed from the TLS layer to the QUIC stack.
32:23
So we just need all TLS libraries to be fixed first too. Sure, I'll get back to that as well. So, and sure, you're right, all these implementations are in userland, right? Which is probably not always a bad thing, because it makes it really easy
32:41
to iterate and try out, right? So, when Google tested it out, the experiment, it was really easy to iterate, they could sort of bump their versions every other day, upgrade the browser, upgrade the server, and just try it. It worked fine in the sort of, but it also makes you, as an application author, you have to get married to one of these libraries
33:01
and hope that it'll stick around for a while. And there's no standard API, so of course you get married even closer to one of these. And you have this kernel user space transition all the time, so back again to the APIs, to the kernel. So how much time do you actually waste by going back and forth kernel space, user space?
33:22
So then your obvious question is, will this then be moved into the kernel? Because, I mean, that's where we're used to, TCP is there, right? And we're used to having the transport protocols and stuff in kernels. And I don't have the answer for this. Maybe it will. I don't think it'll happen soon. I know there are some efforts to do it,
33:40
but there are also some new fun interactions between QUIC and HFP3, which should be in the kernel and how. And would anyone writing a kernel really want a new TLS implementation in the kernel? I don't know. I have my doubts that it'll be a fast development. So I don't think so in near time.
34:01
So what about tooling? There's a lack of tooling, of course. This is a totally new area, right? We're throwing out TCP. We've used TCP for quite a while, right? TCP dump. Who hasn't used that, right? No, no, not anymore, right? All those concepts about segment numbers and windowing and stuff. No, that's gone. So now we need new tools.
34:23
And okay, Wireshark is there, of course. You get it the latest and you can actually use that today and it's excellent. And there are tools coming like Qlog, Qvis. Qlog is sort of a standardized logging for quick service and implementations in general, actually.
34:40
Qvis is a visualizer of those logs. So there are tools coming, but there's definitely a shortage because this is really new stuff. So a little bit thin there. A lot of work to do. So okay, when will this ship? And this is actually, so the Quick Working Europe has a charter when it says we have some milestones
35:00
for when we will ship. And it says there it's going to ship in July 2019. I'm only slightly disingenuous because they actually argue, there's a change suggested that will actually be applied, I think, in the coming week and that they will remove the year completely. There's no milestone anymore.
35:21
But I would say that maybe it'll be around July 2020, perhaps. I've talked about HTTP3 many times and this is one of these slides that tend to change the most, a lot of postponement, maybe this time. Maybe not, I don't know. It's really hard to tell. There's a lot of strong wills in the working group
35:41
and they want to do it right rather than soon. So who knows? Maybe 2021. So there are a lot of HTTP3 and quick implementations. I say over a dozen here, but I think there are even more. So all those companies I showed you before, they all have their own stacks. So there's a multitude of them. You can get them in many languages.
36:02
There's nothing that prevents you from jumping in immediately and start fiddling with them. There are monthly interrupts, which actually proves then that the specifications actually work. Most of these implementations can actually interrupt with each other to a fairly high degree, at least. And we're on draft number 25 right now.
36:22
So what's good? Curl supports it, that's good, right? And if you really insist, you can also use one of the browsers. Or if you use one of those Canary ones or Firefox Nightly, you can enable it. I'll show you in a second.
36:41
You can also enable it in those servers. And there's an NGINX patch that runs with Quiche, which is a quick library that you can run your own experiments already today. They're also up to date with the latest draft version. And I mentioned already, Wireshark can analyze these streams. But not everyone is on track yet.
37:02
There's no Safari version, and there's no word from these, you know, the big standard open source servers. I don't know when they're going to do it. I don't think there are any official news from any of them. And then there's this fun thing. I'm back again to the TLS situation. We only have to change all the TLS libraries. How hard can that be?
37:21
Well, that's the pull request for OpenSSL to make the necessary change for the API. 87, 97, it's still being discussed, so it hasn't even been merged. So it'll take a while, I think. And then that's about getting merged into OpenSSL Git master until that gets shipped in a release
37:41
and then deployed in your Linux servers. I think it'll take a while. So how do you want to run this immediately today? Then you just fire up one of these canary versions of the browsers, and you enter that fun command line option. And if you're a little bit slow
38:00
and just wait a few more days, I think you can change the 24 to a 25 because then they're going to upgrade to 25. And if you want to do it with Firefox, you just find that little thing in the about config, and you enable it. Easy. And you can find test servers even if they're basically no one. You can actually go to Facebook
38:21
and Cloudflare runs some public ones. Other ones, they are just a few test servers. Early days still. You can do it with cURL. And I support the latest draft version. You can do that server over there version approach. And I support two different backends so you can pick whichever library you want to use
38:40
on these two, ng-tcp2 and Kish. And the fallback is tricky, so we don't do that in cURL yet. I don't know really how to handle that. I'll figure it out. You can try it. It's fun. And if you would do that, it would look like this. So you just ask for it to be three instead of anything else, and it'll just show exactly like HTTP looks like.
39:00
There's no difference, really. So just to show you some of the problems that we have to ship this. So you want to ship HTTP3-enabled cURL when? First we have some specifications. They haven't landed mid-2020, maybe. And then we have these libraries that we are using to do all of this binary stuff.
39:20
They're all in alpha versions because the draft versions keep exchanging. So they're probably going to ship after specifications. And then I'm just going to have a few deployed servers before we can do this, right? Only Facebook and two Cloudflare servers are probably not enough. Browser support would be good. They're actually pretty crappy still. And so then I want to fix libcurl,
39:40
and then we just have to have those less library situation fixed. How hard can it be to ship a TLS library API? And then we can ship cURL. It might not be tomorrow. So I'm looking into this crystal ball. How will this look in the future? So yeah, this will take time. I mentioned quite a few obstacles along the way here.
40:00
So yes, it'll take some time. And I think it will grow a little bit slower than HTTP2 did. I would say that HTTP2 didn't grow really fast. But QUIC is also here for the long term. So I think QUIC is truly the TCP replacement. The only existing and sort of viable replacement for TCP that has been done for a very long time.
40:23
And there's some big effort here and a lot of big muscles and big companies behind this. So I'm pretty certain that QUIC will become the TCP replacement. Maybe not tomorrow, maybe not 2021, but it's going to be there down the line. And the future, once this is shipped, people are waiting to add more stuff.
40:40
Multipath, forward error correction, unreliable streams. So you can mix reliable and unreliable streams within the same connection, like bring UDP back into QUIC. Or what about partial reliability? Only a little bit. It's actually sort of pushed by video people.
41:02
And of course, more application protocols. So there's a huge demand of people waiting. Once this ships, there's going to be more work. There's going to be more work on QUIC version two as soon as QUIC version one ships. So there's a lot of people waiting to do things. And always when I say this, people, a lot of you are still waiting for me to mention something about WebSockets, right?
41:23
I'm sorry. That's not actually a part of HTTP at all, HTTP three, definitely not. So it's more of a thing on top. And this time we don't fix it either. You could, in theory, fix WebSockets exactly as people did for HTTP two, if you wanted to.
41:41
But that's probably not how it's going to happen. It's going to happen in a completely different way, which is a new API and things for doing TCP-like things in JavaScript over the web protocols called WebTransport. That's a draft for that. Right, whew, now you can wake up over there.
42:02
HTTP three is coming. It's going to be encrypted all the time over QUIC, over UDP. There are a lot of challenges to do this, especially in the server side. And it might come mid-2020. I'm always the optimist. When I talked about HTTP three last year here at FOSTA,
42:21
I think I said mid-2019. Next year, I'm going to, I wrote a book about it, or a document at least. It's there, it's free. And I just wanted to say that since the acoustics in here is completely crappy and everyone is going to walk out the second I show you the next slide, I'm afraid the better way to ask me questions about this
42:42
is out here or in the cafeteria in five minutes. But you can ask me questions now, too. Thank you.