HTTP/3 – Why should I care?
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 | 130 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/49935 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 202068 / 130
2
4
7
8
13
16
21
23
25
26
27
30
33
36
39
46
50
53
54
56
60
61
62
65
68
73
82
85
86
95
100
101
102
106
108
109
113
118
119
120
125
00:00
Mathematical optimizationCommunications protocolServer (computing)Host Identity ProtocolClient (computing)Transport Layer SecurityBinary fileTDMAData compressionEmailDigital photographyDomain nameDisk read-and-write headLine (geometry)InternetworkingPerfect groupInternetworkingMultiplication signBlock (periodic table)Maxima and minimaMedical imagingFiber bundleMultiplicationOpen setTransport Layer SecurityConnected spaceObject (grammar)CuboidFile Transfer ProtocolStreaming mediaFreewareVideoconferencingEmailBookmark (World Wide Web)Communications protocolExpert systemServer (computing)Web pageRevision controlParallel portComplex (psychology)Network socketLine (geometry)ImplementationMeasurementModal logicLimit (category theory)Band matrix2 (number)Speech synthesisDisk read-and-write headMathematical optimizationWeb browserDomain nameGame theoryWebsiteDistanceLatent heatTelnetSoftwareKey (cryptography)Different (Kate Ryan album)EncryptionComputer networkOperating systemCategory of beingBit rateSocket-SchnittstelleCASE <Informatik>Slide rulePhysical systemDependent and independent variablesComputer fontCodeTrailMathematicsDiagramStatement (computer science)Meeting/InterviewXMLComputer animation
10:30
Letterpress printingNetwork socketTransport Layer SecurityHost Identity ProtocolIndependence (probability theory)Digital photographyGraphical user interfaceSpacetimeCommunications protocolOperating systemBlock (periodic table)Streaming mediaComputer configurationCodeDifferent (Kate Ryan album)MultiplicationEncryptionOrder (biology)Connected spaceFamilyObject (grammar)Roundness (object)Revision controlTransport Layer SecurityMobile appIndependence (probability theory)Single-precision floating-point formatCASE <Informatik>Client (computing)Line (geometry)Computer programmingDefault (computer science)Type theoryLevel (video gaming)FreewareTDMAAddress spaceDisk read-and-write headBuildingSocket-SchnittstelleMultiplication signAbstractionCuboidReflektor <Informatik>Information securityRewritingInternetworkingLogicCartesian coordinate systemKernel (computing)Computer wormSound effectOnline gameFile Transfer ProtocolDataflowServer (computing)Real-time operating systemSoftwareContext awarenessProgramming languageBuffer solutionGoogolUDP <Protokoll>Message passingTheoryHeat transferDirect numerical simulationDampingComputer animation
20:30
Human migrationDigital photographyÜberlastkontrolleInformationData recoveryUDP <Protokoll>BefehlsprozessorKolmogorov complexityGoogolCommunications protocolGraphical user interfaceMobile WebScripting languageScheduling (computing)Computer networkCuboidInsertion lossInternet service providerOnline helpIP addressType theoryOperating systemPoint (geometry)Graphical user interfaceOpen sourceData recoveryConnected spaceMathematical optimizationImplementationGroup actionExpected valueBefehlsprozessorWeb browserMobile appSoftware developerNumberRegular graphUniqueness quantificationLimit (category theory)Ocean currentRevision controlGoogolHuman migrationClient (computing)Server (computing)SoftwareHypermediaScaling (geometry)Closed setMessage passingInterrupt <Informatik>AreaFreewareMetadataTransport Layer SecurityComputer configurationEncryptionStandard deviationMultiplication signCommunications protocolCausalityInternetworkingExtension (kinesiology)TheoryState of matterÜberlastkontrolleEmailCASE <Informatik>SpacetimeBand matrixMeta elementUDP <Protokoll>Operator (mathematics)Physical systemGame controllerView (database)Information privacyComputer animation
30:30
MaizeComputer fileView (database)Computer networkRevision controlHypercubeLibrary (computing)Uniform resource locatorComplex (psychology)Computer wormContext awarenessPairwise comparisonHost Identity ProtocolSocial classModule (mathematics)Supersonic speedSource codeCodeClient (computing)UDP <Protokoll>Point cloudElectronic mailing listRevision controlEmailClient (computing)FreewareCommunications protocolMechanism designMappingServer (computing)Configuration spaceLibrary (computing)Connected spaceHome pageSlide ruleFlow separationLink (knot theory)Mathematical optimizationDifferent (Kate Ryan album)CodeView (database)Level (video gaming)Arithmetic progressionOnline chatWeb pageSoftware testingMathematicsBranch (computer science)Group actionMultiplicationComputer programmingSupport vector machineSpeech synthesisData storage deviceHuman migrationProfil (magazine)Address spaceAuthorizationGoogolMobile appUDP <Protokoll>Lipschitz-StetigkeitImplementationSet (mathematics)Web browserDigital object identifierSoftware developerStandard deviationProcess (computing)Table (information)WikiSoftwareGraph coloringCore dumpContent delivery networkComputer animation
40:29
Multiplication signMultilaterationMeasurementProduct (business)Speech synthesisCASE <Informatik>Library (computing)Transport Layer SecurityLastteilungMobile appConnected spaceProxy serverServer (computing)WritingEncryptionCommunications protocolInternetworkingPerfect groupContent delivery networkCodeMeeting/Interview
Transcript: English(auto-generated)
00:07
Okay, so yeah, we're good to start. I'm going to talk. Okay, perfect. So this is Miroslav Denhu, welcome. And today we're gonna talk about HTTP3.
00:21
Why should we all care? You're gonna tell us, right? Yeah, I hope. I will try to tell my mess. So hi everybody, welcome. And I hope that you are curious about HTTP3 and I wish you to enjoy this talk. This is like an exceptional opportunity for me to speak at your Python.
00:44
As I told, I'm Miroslav Poyman and I'm streaming from Prague. I work here for Akamai technologies in the protocol optimization team. If you don't know that, Akamai runs one of the largest CDNs in the world with more than quarter million servers around the globe.
01:03
And our peak traffic is more than 150 terabits per second. The reason why I'm speaking here today about HTTP3 is that our protocol optimization team enabled QUIC for this whole Akamai network.
01:21
If you are wondering how QUIC is related to HTTP3, then you are watching the right video because I will explain you what QUIC and what HTTP3 are in next approximately 40 minutes. I assume that you have at least a rough idea
01:43
what happens under the hood when you visit your favorite internet website. But don't be afraid if you are not an expert in network protocols, this is an introductory talk. So I will start with a quick recap
02:00
to make everything clear. So when you visit a website, a browser issues HTTP requests. And HTTP is a simple text protocol. You can speak HTTP yourself even without a web browser. You open a TCP connection, for example,
02:23
using Telnet or Netcat and write your request. Hit the return key twice and the server should set a response back. That's all. It's that simple. And I'm pretty sure that most of you know this,
02:43
that most of you know this protocol because it's a year from the 1997 and most websites still use this protocol from the 90s. The difference from the 90s is that most traffic today is encrypted. Encrypted using HTTPS.
03:00
HTTPS means HTTP over TLS. And HTTPS connection is encrypted using TLS. That's the difference. But besides that, nothing changes. Once I open a TLS connection, for example, using OpenSSL, I can write my HTTP request as just I did before.
03:27
If you want something more sophisticated, we should move to 2015 when HTTP two was published. Unlike the first version, HTTP two is a binary protocol. So I want to show you an example here.
03:44
HTTP two has many nice properties. Probably the most important one is that it supports multiplexing. It allows you to download multiple objects at parallel over a single connection. To see why this is useful,
04:02
let's look at an example how a webpage is loaded using HTTP one. With HTTP one, browsers typically open multiple connections per server to allow at least some parallelism.
04:22
In most cases, browsers open six connections per server per domain. So let's look at this slide. First, an HTML page is loaded.
04:41
But that's not all. Like typical page today consists of hundreds of objects, images, JavaScript, styles, fonts, advertisement, tracking codes, whatever. So you have to load much more. So browsers open another five connections
05:02
and download six objects at parallel. The yellow and red lines show, measure the time necessary for connection setup. Further requests have to wait until one of connections is available,
05:22
until one of previous connections finish and so on. Further requests are queued for even longer. In the diagram, the green bars are waiting times. A latency, a time between a server sends a request and gets a response.
05:40
And as you see in this example, these green bars and the waiting before can be much longer than the very tiny blue bars at the end which measure actual download times. The described issue is called HTTP head of line blocking. The issue is that HTTP requests are blocked
06:03
until one of six connections is available. To minimize consequences of head of line blocking, we invented JavaScript bundles or image sprites. The idea is simple. If you download fewer objects, you issue fewer requests and you spend less time waiting.
06:25
But you can imagine that it may not be the best idea to download everything in one blob. Probably because you will be downloading much more than you need.
06:41
With HTTP2, browsers open multiple connections per domain, open one connection per domain only. And then they use it to download all objects concurrently. The blue download times can be longer because the connection is shared, but avoiding the unnecessary waiting is a game changer.
07:04
Today, most top sites use HTTP2. I would say that when performance matter, HTTP2 should be used. Obviously, you should measure what works in your specific use case, but this is my generic recommendation.
07:21
Because with HTTP1, you can be limited by latency, by the distance to the server. With HTTP2, this limitation is suppressed, allowing you to utilize most of the bandwidth. So we have two important HTTP versions.
07:43
We have HTTP1, which is more than 20 years old and still good enough for most sites. And we have HTTP2, which was standardized only five years ago, and which is still good enough,
08:03
which is much better in performance than the previous version. In this situation, it's fair to ask, why we need a new protocol today? Why we need a new HTTP version? What can HTTP3 offer us?
08:23
The answer is that HTTP3 is completely different. It replaces foundations of the internet. That's a brave statement. What are the internet foundations?
08:40
How does the internet work? Not an easy answer. The internet is a complicated beast. But the good news is that we mostly don't care because all the complexity is hidden from us
09:01
by something called TCP. TCP is like a magic box. You write something to the box and on the other side of the internet, somebody can read it from their box. If something gets lost on the way, TCP retransmits it.
09:22
If something is delayed, TCP re-orders it. The TCP layer handles various network glitches for you. So you get a ribe byte stream and you don't have to care how it is implemented.
09:44
You can write anything to a TCP socket. In this talk, we care mainly about HTTP3. But TCP can transport anything. It can be FTP. It can be your emails over a pop free or SMTP
10:01
and hundreds of other protocols. This TCP protocol is older than HTTP. It's here from the 80s with the early implementations from the 90s, from the 70s and we use it since then.
10:22
TCP is implemented in your operating systems. Thanks to that, we can use TCP from almost any programming language, including Python. And we can do that with few lines of code only.
10:43
You know, if you are used to high level APIs, then the TCP sockets may look complicated to you, old fashioned. But if you consider that these few lines of code get your data over the internet
11:00
and how old this API is, I think it's pretty amazing. I have already told you that HTTPS is HTTP over TLS. And TLS is just another box that sits on top of TCP. It encrypts everything that goes in
11:21
and decrypts everything that goes out. TLS prevents. Eavesdropping or data tampering. That means that nobody can read or change your payload. And similar to TCP, TLS is also protocol independent. So we can write HTTP to it.
11:41
We get HTTPS. But for example, FTPS is FTP over TLS over TCP. And now, what would be our options
12:01
if somebody denied us from using TCP? TCP has a younger and less clever brother called UDP. UDP is primitive compared to TCP. If UDP, you sent your packets
12:23
and they may arrive or may not. And if they arrive, they can appear in any order. It means that your app has to handle any network glitch. Typical UDP use cases include DNS,
12:43
online gaming or real time streaming. So, if we had no TCP, we would probably have to use UDP. There are other protocols. There are many other protocols.
13:02
But in practice, only TCP and UDP are supported over the internet by the devices in the wild. So, if I had to use UDP and I wanted something reliable like TCP,
13:22
then maybe I would try to build something like TCP on top of UDP. You know, some kind of abstraction to raise my code between applications.
13:40
And may you know, maybe that may not be the worst idea. Maybe the thing that we built on top of UDP can be actually better than the original TCP. Say hello to QUIC. QUIC is a new transport protocol design in Google.
14:02
It emulates and improves TCP on top of UDP. QUIC is TCP redesigned and rewritten from scratch. QUIC has to implement everything normally provided to you by kernel of your operating system.
14:22
It has to implement it in your apps in user space. And similar to TCP, QUIC retransmits and reorders packets so you get a reliable byte stream. And you don't have to care how it is implemented.
14:42
The difference from TCP is that QUIC has TLS built-in. Everything delivered using QUIC is encrypted by default. And when we compare this to TCP, QUIC can be also used to deliver any message,
15:03
including HTTP, at least in theory or in future. In practice today, we use QUIC almost exclusively with HTTP. But in this talk, we care HTTP. We care about HTTP free. And this gets me to HTTP free.
15:23
HTTP free is HTTP over QUIC. HTTP version three is similar to HTTP version two, but it is delivered using QUIC, using UDP instead of TCP. That's what makes HTTP free so interesting.
15:43
It uses a completely different transport protocol under the hood than we used since the 90s. But one does not rewrite TCP layer just for fun. The new layer should give us some advantages.
16:02
So what they are. The main advantage of QUIC is that it's multiplexed. It supports many independent streams, many independent logical flows within a single connection.
16:21
Wait, wait, wait, wait. Did you listen to me? Didn't I told you that the multiplexing is the main advantage of HTTP two? I did. But let me explain the difference. HTTP two is multiplexed,
16:40
but the underlying TCP is not. So when you are transferring multiple objects, multiple requests in parallel over HTTP two, HTTP two has to serialize them into a single TCP stream.
17:00
And that single TCP stream is guaranteed to deliver any order. And now imagine what happens when one packet is lost. Everything is blocked. Everything has to wait for that one packet. One lost packet completely stops everything.
17:27
Your operating system can have the request, can have the object you need in its buffer, but it won't give it to you because the TCP layer promised to return everything in order.
17:44
This is called TCP head of line blocking. So with HTTP two, we got rid of HTTP head of line blocking, but we got the TCP head of line blocking instead. Slightly better, but not much.
18:02
Quik, unlike TCP, supports independent streams. It knows what objects are in what stream. Thanks to that, when one packet is lost, only objects delivered in that packet are blocked.
18:23
Address can continue. This can improve performance and user experience on lossy connections. Another important quick advantage is that it offers a faster connection setup.
18:43
I probably don't have time to go into much details here, but the problem with TCP is that it has too many layers. So you need one round trip to set up a TCP connection. Then you need at least one round trip
19:02
to set up some encryption context, to set up your TLS. So first useful data can be delivered in the first round trip at best. With Quik, you have one layer less. The quick handshake and TLS handshake can happen at the same time,
19:21
shortening the connection setup. But we can make this even faster, even better. Quik also supports so-called zero RTT. With the zero RTT handshake, we can include useful data with the handshake.
19:42
So there is no extra round trip that you have to wait for. This is possible when a client knows some secret from before. So this is available for reconnections to servers that you spoke to before.
20:04
I have to warn you that there is one danger with the zero RTT. And it's the security issue that it allows like replay attacks. For that reason, you should enable it only for idempotent requests only. For requests that can be replied
20:22
without any side effects. If I have to be fair to TCP, I have to mention that there is a TCP extension called TCP fast open that should enable something like zero RTT in TCP.
20:42
But it does not work very well in the practice. I will explain it in a minute why. Another quick advantage, an interesting one is that QUIC supports connection migration. Unlike TCP, QUIC does not identify
21:03
connections using an IP address and port number. But instead, it uses a unique connection ID sent inside the connection. Thanks to that, it's possible to switch your connections.
21:22
For example, you disconnect from Wi-Fi and get to some mobile signal and your connections, your requests should be able to continue without any interruption. I already mentioned that QUIC is always encrypted.
21:44
What's important here is that QUIC encrypts not only your message, but also metadata, traffic control, headers. Because with TLS over TCP,
22:02
your message is encrypted. But the things around that, like the headers, the metadata are not. And this increased encryption is important for your privacy, obviously. But not only for that,
22:21
it is also important for future development of the technology, for future development of QUIC. Because there's a problem with internet. And the problem is that there are many devices, many boxes that try to help you.
22:42
Whereas boxes think that they understand to the protocols that you are using. So they somehow interfere with it. And they claim that it's in your best interest. But as these boxes get old,
23:01
their understanding gets worse. And at some point, they are likely to cause more harm than help. Take an HTTP2 for example. The old boxes can assume that any TCP on port 80
23:20
is HTTP1 because it was always like that. So with this assumption, the boxes can break any HTTP2 traffic there. And that's the reason why we use HTTP2 over TLS only. We use encrypted HTTP2 only.
23:41
Because when something is encrypted, middle boxes don't see it. So TLS can hide HTTP from the middle boxes. But the problem remains. Because the boxes still see the TCP layer.
24:02
I mentioned TCP fast open. The thing that's something like zero RTT in click. It was never widely adopted because there are many boxes which that consider traffic with this extension invalid.
24:23
And they can drop this traffic. So TCP fast open can become like TCP slope. By encrypting everything in QUIC, including traffic control, including metadata, including headers,
24:41
we refuse any help from the middle boxes. Thanks to that, the QUIC protocol can evolve in future. We say that QUIC avoids ossification. There are other advantages.
25:01
An interesting one is that QUIC offers much faster development. Because it's implemented in user space, it's implemented in apps. You can upgrade QUIC with any software upgrade. You get the new browser version and you can get the new QUIC version. QUIC also offers better options
25:22
for congestion control or loss recovery. That's a very interesting problem. My protocol optimization team spends a lot of time on that. The idea is that you want to send data fast enough to utilize your bandwidth,
25:40
but not too fast to cause packet loss. But no technology comes with advantages only. So there are challenges for QUIC too. From my point of view, the main problem with QUIC is that it's new.
26:05
So for example, internet providers may not expect regular traffic over UDP and they can rate limit it or even block it. And because QUIC is not implemented in operating systems,
26:22
apps have to provide their own implementation. And if we compare like random implementations with the TCP stack optimized since the 80s, like quality of QUIC can be questionable.
26:40
And probably the most discussed challenge is the CPU usage. There's definitely an area where future development and optimizations can help. But let's move from theory to practice. What you can try today? What's the current state of HTTP free?
27:00
I hope that you are curious, but before I get to that, I have to clarify one important distinction. Distinction between two QUIC implementations. We have Google QUIC and IETF QUIC. Google QUIC or GQUIC is proprietary open source,
27:27
is that possible? It's open source available in Chromium, but developed by one company by Google. It's not standardized and it can change with like any Chromium or any Chrome version.
27:46
On the other hand, IETF QUIC or QUIC with no prefix is the upcoming standard. And IT working group is finalizing it, so we will hopefully have an official version soon.
28:03
These two versions are not compatible and support for them differs. That means that when we discuss support, we have to mention support for what of these two versions. Let's start with GQUIC.
28:20
It's quite likely that you are already using Google QUIC today. When a Chrome browser connects to a Google server, it will very often use QUIC. It will use QUIC in most cases. And Chrome is a quite common client
28:40
and Google services are also popular. So significant portion of traffic today is already over QUIC. In Akamai, we enabled GQUIC for all media customers. That's a lot of traffic too.
29:02
But besides that, I'm not aware of any other large scale deployments besides Akamai and Google. I heard some rumors about like closed internal deployments, even large scales, but nothing officially available, nothing public.
29:27
But strictly speaking, GQUIC is not HTTP free. And this talk is about HTTP free. HTTP free is HTTP over IETF QUIC. It's the upcoming standard.
29:42
And we can expect support for HTTP free for the IETF QUIC in all major browsers. Chrome Canary and Firefox Nightly support IETF QUIC for some time already. And Apple announced support for it
30:01
in their next operating systems. So I believe that we will get to like official support in all browsers soon. Speaking about clients, special mention belongs to Chrome, which has an experimental support for HTTP free.
30:26
The reason is that Chrome is not only a command line tool, but it's also a C library, a very popular C library. So if, yeah, so if for example,
30:43
your car will speak HTTP free in future, it will be most likely thanks to libcoro. If you want to learn more about HTTP free, then my first recommendation would be talks from Daniel Sternberg, the author of Quo. On the server side, you can notice that CDNs,
31:01
content-driven networks, do not want to miss this opportunity. CDNs are investing into QUIC and HTTP free. So if you are using their service, you may get HTTP free without an extra effort. If you prefer a do it yourself approach,
31:24
you may like that HTTP free support for NGINX is in progress. The code is developed in a separate QUIC branch. So like the support is not stable yet, but I believe that they will get there.
31:42
Just be aware that like enabling HTTP free is just the first step. I know something about it because our team is spending last few years by looking for the best QUIC configuration.
32:02
We did a lot of optimizations, but we are still not done. If you want to see other HTTP free implementations, visit the GitHub profile of the IT working group. There is not only the list of implementations,
32:21
but also a compatibility table, which shows you what client works with what server. It's pretty green these days, so the future is green. If you want to try HTTP free yourself, I recommend to download Firefox Nightly.
32:42
You can enable HTTP free in its configuration in the about config page. And you can visit one of the test pages. Nginx has a nice test page, Akamai offers one and address can be found at the IT working group.
33:02
So we have two versions. What version to choose today, Google QUIC or IETF QUIC? You know the answer. If you want to develop anything today, go for the standard IT version. Its support is experimental only today,
33:21
but this should get much better soon. Akamai supports QUIC since 2016. We deployed the proprietary version back then, and we are updating it since that. And because this was the only way
33:40
how to offer QUIC advantages to our customers, to our users. And it's still the only way today. But in practice, Google is like backporting changes from the IETF QUIC to their version. So it's quite likely that both versions
34:03
will converge in future. This is very similar to how HTTP2 was born. There was a proprietary protocol called SPDY, it was developed in Google, then IETF took it, standardized it as HTTP2. Today, everybody uses HTTP2
34:20
and nobody cares about SPDY. If you want to see whether a support supports HTTP3 or QUIC, look for an Alt-SVC header. The Alt-SVC header is sent by servers to inform clients that they can switch to HTTP3. This mechanism is different
34:41
than switching from HTTP1 then HTTP2. The reason is that for deciding between HTTP1 and HTTP2, you can open a TCP connection and then negotiate what version to use. With QUIC, you have to open a separate QUIC connection and you have to know where you can connect
35:02
and whether you can connect. By the way, this Alt-SVC header can be quite useful for my job, for protocol optimization. Because all Akamai servers supports QUIC today,
35:21
but we send this Alt-SVC header only when we believe that our clients will benefit from it. Python. This is a Python conference. If you want to try HTTP3 in Python,
35:41
go for the IEO-QUIC library. It's the only Python library mentioned at the IETF-QUIC working group bigger. I tried it and it works nice. Yes, I tried it. That's all. I write Python a lot,
36:02
but my code does not use HTTP3 yet. Sorry. Why? Let's ignore the fact that Google QUIC is available in Chromium only and deployments of IETF-QUIC are experimental at best.
36:23
Let's discuss how can I use HTTP3 once it is standardized, once it is widely deployed. Because I'm afraid that to use HTTP3, I will have to change how I write my code.
36:44
I told you that the main advantage of QUIC is multiplexing is that you can issue multiple requests in parallel. To use that, I need some kind of async programming.
37:00
Probably, I think I owe in Python. Another issue with HTTP3 is like the ALT SVC header. Your client has to remember what servers send this header
37:21
so what servers support QUIC so your clients will need some kind of storage. And the storage will be needed for zero RTD too because you have to remember secrets between sessions. But before speaking about migration to HTTP3, I should probably talk about HTTP2 first
37:42
because I guess that most of you do not even use HTTP2 in Python yet. The most common Python library for issuing HTTP requests is URLF3. You probably use it because it's a dependency of popular libraries like PIP or request and it does not support HTTP2 yet.
38:03
If I had to choose library for HTTP2, I would use HTTPX. There's a nice API and it supports async invocation. So if I have to use HTTP3, I would like to have something like HTTPX, a library that has a nice API,
38:21
it supports all the protocol and it's asynchronous. And I want a library that chooses the best HTTP version for me. When I write Python, I don't want to care about HTTP versions. Until I have that, I will probably use HTTP1 from the 90s.
38:43
Let's summarize what I have presented to you. We have a new transport protocol called QUIC. It's a TCP replacement on top of UDP. HTTP3 is similar to HTTP2, but built on top of QUIC on top of UDP instead of TCP.
39:03
For practical usage, I want to be issue HTTP requests without caring about HTTP versions. Similar to browsers. When I use my browser, I don't care what HTTP version it uses. I like a view that HTTP is only one and the versions are just mappings
39:20
to different transport layers. So HTTP1 and HTTP2 map this one HTTP to TCP, and HTTP3 maps this protocol to UDP. Should you care? I think you should be at least aware that something important and interesting is happening.
39:41
All the big players are involved with that. The change is quite low level, so it may not affect you directly, but if you are programming for the web, then you should at least keep an eye on it. If you want to learn more, I already recommended talks from Daniel Stenbergs.
40:01
If you want more details or more critical view, look for talks from Robin Marks. Obviously, I should not forget about like the IETF QUIC working group and even more links are at my personal homepage with these slides and you will find a link in the schedule or like in the chat.
40:23
And that's all from my side. Thank you, thank you very much for listening to me. Thank you, thank you. I will close the play the pluses and I will remember to do that later. Thank you. Thank you. So we can, thank you, that was a really nice,
40:42
very interesting talk. So we have time for maybe one or two questions, not at all. So I will pick one. Mansour is asking if he's saying, QUIC is adding another layer of encryption below TLS.
41:01
I think that's also a question. It's not. Sorry, I'm also asking if he's adding a performance delay or more, if adding more delay because performance. Like QUIC is not adding another layer. Like it, like you can use HTTP without TLS.
41:21
So compared to plain HTTP, it's adding another layer. But if you compare it to HTTPS, it uses the same layer. It's just like integrated to the protocol itself. So you have to use this encryption. Speaking about performance, like QUIC is faster. Like not obviously in all cases, but in most cases
41:40
and there's the primary reason why we use QUIC to make the internet faster. So again, like you should measure what works in your case, you should optimize it. But like the goal of QUIC is to make the internet faster, to fasten connections. Okay, the last one is Philip is saying,
42:02
I find HTTP2 is in common in Python code base. For example, load balancer for like Nginx. Or when, so he's asking, do you think that the same will happen with HTTP3 so that it is not so popular or not so wide use? I think there are like libraries for HTTP2
42:23
that there are like, there will definitely be libraries for HTTP3. Me personally, like I would recommend for most use cases, like write your apps as you do so far, like speak at the server side and let the server handle that. That means that it's very likely
42:40
that you have, for example, Nginx as a proxy in front of your app. And that Nginx should probably speak HTTP3. I probably don't want to write HTTP3 server in Python, not for a production use case. It can be nice learning tool, but for production, I would use like either some production server or a CDN.
43:03
Okay, perfect. Thank you very much. Thank you for presenting me on Python. And if anyone wants to continue this discussion or to ask more questions, there is a channel in Discord, talk HTTP3. You can go and find me to slap there. Yeah, I will be there.
43:21
Thanks. Okay.