HTTP/3 – Why should I care?
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
Pojman, Miloslav
HTTP is the foundation of the current web, and HTTP/3 is the upcoming major version of it. The new version is built on top of the QUIC transport protocol, originally developed in Google. HTTP/3 can change the Internet as we know it today. Since its beginning in the 90s, HTTP transfers data over TCP to ensure reliable connections between clients and servers. QUIC is a TCP alternative, reimplemented on top of unreliable and connectionless UDP. Proprietary Google implementation of QUIC is deployed worldwide and supported by Chrome browsers. Future HTTP/3 will be hopefully standardized by IETF soon, but many diverse implementations are available already today. HTTP/3 improves performance and increases privacy. The switch from TCP to QUIC allows us to address the inherent limitations of previous HTTP versions. The QUIC protocol is completely encrypted, including traffic control headers, which are visible in TCP. This talk introduces HTTP/3 and the underlaying QUIC protocol. It shows both advantages and disadvantages of the new technology, and it describes the landscape of the current implementations and suggests what you can try today.
 Okay, so you're going to talk. I'm going to talk. Okay, perfect. So this is Mira's lab then we will welcome. And today we're going to talk about Hey, she paid three. Why should we all care. You're going to tell us right. Yeah, I hope I will try to still tell my mess. So hi everybody. Welcome. And I hope that you are curious about the three and I wish you to enjoy this talk. This is like an exceptional opportunity for me to speak at your Python. As I told, I'm a lot of women and I'm streaming from Prague. I work here for a come my technologies in the protocol optimization team. You don't know that a come I runs one of the largest CDNs in the world with more than quarter of millions servers around the globe. And our picture thick is more than 150 rabbits per second. The reason why I'm speaking here today about GDP free is that our protocol optimization team enabled quick for this whole a come I network. If you are wondering how quick is related to HTTP free, then you are watching the right video, because I will explain you what quick and what HTTP free are in next approximately 40 minutes. I assume that you have at least rough idea what happens under the hood, where, when 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 to make everything clear. When you visit a website, a browser issues HTTP requests and the GPS a simple text protocol, you can speak HTTP or self. Even without a web browser, you open a TCP connection, for example, using telnet or net cat 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. That most of you know this protocol because it's here 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. 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 open SSL, I can write my HTTP request as just I did before. If you want something more sophisticated, we should move to 2015 when HTTP was published. Unlike the first version, HTTP to is a binary protocol. So I won't show you an example here. HTTP to 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. Let's look at an example. However, that page is closing loaded using HTTP one. With HTTP one. To browser us typically open multiple connections per server. To allow at least some parallelism in most cases, browsers open six connections per server. Per domain. And so let's look at the slide. First, an HTML page is loaded. 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 browser is open another five connections and download six objects at parallel. The yellow and red lines show measure the time necessary for connection setup. For direct requests have to wait until the one of connections is available until one of previous connections finish and so on. For direct requests are queued for even longer. In this diagram, the green bars are waiting times a latency at time between a server sends a request and gets a response. 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 day download times. The described issue is called HTTP head of line blocking. The issue is that HTTP requests are blocked 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. But you can imagine that it may not be the best idea to download everything in one block. Probably because you will be downloading much more than you need. With HTTP to browser is 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 as a game changer. Today, most top sites use HTTP to. I would say that when performance matter, HTTP to should be used. Obviously, you should measure what works in your specific use case. That's my generic recommendation. Because with HTTP one, you can be limited by latency by the distance to the server with HTTP to this limitation is to priest, allowing you to utilize most of that than they. So, we have two important HTTP versions. We have HTTP one, which is more than 20 years old. And still good enough for most sites. And we have HTTP to which was standardized only five years ago. And which is still good enough, which is 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 HTTP free offer us. The answer is that HTTP free is completely different. It replaces foundations of the Internet. That's a brave statement. What are the Internet foundations. 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 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. If something is delayed TCP reorders it. The TCP layer handles various network glitches for you. So you get a ribby stream and you don't have to care how it is implemented. You can write anything to a TCP socket. In this talk, we care mainly about HTTP free. But TCP can transport anything. It can be FTP. It can be emails over a pop free or SMTP and hundreds of other protocols. This TCP protocol is older than HTTP. It's here from the 80s with the early implementations from the 70s. And we use it since then. 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. 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, and how all 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 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. We get HTTPS. But for example, FTPS is FTP over TLS over TCP. And now, what would be our options if somebody denied us from using TCP? TCP has a younger and less clever browser called UDP. UDP is primitive compared to TCP. If UDP, you sent your packets 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, 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. 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, then maybe I would try to build something like TCP on top of UDP, some kind of abstraction to reuse my code between applications. And maybe that may not be a diverse idea. Maybe the thing that we built on top of UDP can be actually better than the original TCP. Say hello to Qwik. Qwik is a new transport protocol design in Google. It emulates and improves TCP on top of UDP. Qwik is TCP redesigned and rewritten from scratch. Qwik has to implement everything normally provided to you by the kernel of your operating system. It has to implement it in your apps in user space. And similar to TCP, Qwik retransmits and reorders packets so you get a reliable byte stream. And you don't have to care how it is implemented. The difference from TCP is that Qwik has the OS built in. Everything delivered using Qwik is encrypted by default. And when we compare this to TCP, Qwik can be also used to deliver any message including HTTP. At least in theory or in future. In practice today, we use Qwik almost exclusively with HTTP. But in this talk, we care about HTTP. And this gets me to HTTP free. HTTP free is HTTP over Qwik. HTTP version free is similar to HTTP version two, but it is delivered using Qwik, using UDP instead of TCP. That's what makes HTTP free so interesting. It uses a completely different transport protocol under the hood than we used since the 90s. But one does not rewrite like TCP layer just for fun. The new layer should give us some advantages. So what they are. The main advantage of Qwik is that it's multiplexed. It supports many independent streams, many independent logical flows within a single connection. Wait, wait, wait, wait. Did you listen to me? Didn't I told you that the multiplexing is the main advantage of HTTP too? I did. But let me explain the difference. HTTP is multiplexed, but the underlying TCP is not. So when you are transferring multiple objects, multiple requests in parallel over HTTP, HTTP has to sterilize them into a single TCP stream. 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. Your operating system 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. This is called TCP head of line blocking. So with HTTP2, we got rid of HTTP head of line blocking. But we got the TCP head of line blocking instead. Slightly better, but not much. Quick, 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. Others can continue. This can improve performance and user experience on lossy connections. Another important quick advantage is that it offers a faster connection setup. 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 to set up some encryption context to set up your TLS. So first useful data can be delivered in the third round trip at best. With Quick, you have one layer less. The Quick handshake and TLS handshake can happen at the same time, shortening the connection setup. But we can make this even faster, even better. Quick also supports so-called zero RTT. With the zero RTT handshake, we can include useful data with the handshake. 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. I have to warn you that there is one danger with the zero RTT. It's the security issue that it allows replay attacks. For that reason, you should enable it only for hidden potent requests only. For requests that can be replied 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. But it does not work very well in the practice. I will explain it in a minute while. Another quick advantage, an interesting one, is that Quick supports connection migration. Unlike TCP, Quick does not identify 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. So 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 Quick is always encrypted. What's important here is that Quick encrypts not only your message, but also metadata, traffic control, headers. Because with TLS over TCP, your message is encrypted. But the things around that, like the headers, the metadata, are not. This increase encryption is important for your privacy, obviously. But not only for that, it is also important for future development of the technology, for future development of Quick. Because there's a problem with internet, and the problem is that there are many devices, many boxes, that try to help you. 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, 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 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. 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. So we use the exception TCP fast open. The thing that's something like zero RTT in Quick. It was never widely adopted, because there are many boxes that consider traffic with this extension invalid. And they can drop this traffic. So TCP fast open can become like TCP slope. By encrypting everything in Quick, including traffic control, including metadata, including headers, we refuse any help from the middle boxes. Thanks to that, the Quick protocol can evolve in future. We say that Quick avoids ossification. There are other advantages. And interesting one is that Quick offers much faster development. Because it's implemented in the user space, it's implemented in apps, you can upgrade Quick with any software upgrade. You get a new browser version, and you can get a new Quick version. Quick also offers better options 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, but not too fast to cause packet loss. But no technology comes with advantages only. So there are challenges for Quick too. From my point of view, the main problem with Quick is that it's new. So for example, internet providers may not expect regular traffic over UDP, and they can rate limit it or even block it. And because Quick is not implemented in operating systems, apps have to provide their own implementation. And if we compare random implementations with the TCP stack optimized since the 80s, quality of Quick can be questionable. 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? I hope that you are curious. But before I get to that, I have to clarify one important distinction. Distinction between two Quick implementations. We have Google Click and IETF Quick. Google Click or G-Click is a proprietary open source. Is that possible? It's open source available in Chromium, but developed by one company by Google. It's standardized and it can change with like any Chromium or any Chrome version. On the other hand, IETF Quick or Quick with no prefix is the upcoming standard. And IETF Working Group is finalizing it, so we will hopefully have an official version soon. 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 G-Quick. It's quite likely that you are already using Google Quick today. When a Chrome browser connects to a Google server, it will very often use Quick. It will use Quick in most cases. And Chrome is a quite common client and Google services are also popular. So significant portion of traffic today is already over Quick. In Akamai, we enabled G-Quick for all media customers. That's a lot of traffic too. 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. But strictly speaking, G-Quick is not HTTP-free. And this talk is about HTTP-free. HTTP-free is HTTP over IETF Quick. It's the upcoming standard. And we can expect support for HTTP-free for the IETF Quick in all major browsers. Chrome Canary and Firefox Nightly support IETF Quick for some time already. And Apple announced support for it in their next operating systems. So I believe that we will get to official support in all browsers soon. Speaking about clients, special mention belongs to Chrome, which has an experimental support for HTTP-free. The reason is that Chrome is not only a command-line tool, it's also a C library, a very popular C library. So if, yeah, so if for example, your car will speak HTTP-free in future, it will be most likely thanks to Lipkara. If you want to learn more about HTTP-free, then my first recommendation would be talks from Danny Austin, but the author of Chrome. On the server side, you can notice that CDNs, content-driven networks, do not want to miss this opportunity. CDNs are investing into Quick 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, you may like that HTTP-free support for NGINX is in progress. The code is developed in a separate quick branch, so the support is not stable yet, but I believe that they will get there. Just be aware that 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 quick configuration. 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 ITI working group. There is not only the list of implementations, 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. 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 ITI working group. We have two versions. What version to choose today? Google Quick or IETF Quick? Let me give you an answer. If you want to develop anything today, go for the standard IETF version. Its support is experimental only today, but this should get much better soon. Akamai supports Quick since 2016. We deployed the proprietary version back then, and we are updating it since that. This was the only way to offer Quick advantages to our customers and users. It's still the only way today. In practice, Google is backporting changes from the IETF Quick to their version. It's quite likely that both versions will converge in the future. This is very similar to how HTTP2 was born. There was a proprietary protocol called Speedy. It was developed in Google, then IETF took it, standardized it as HTTP2. Today, everybody uses HTTP2 and nobody cares about Speedy. If you want to see whether a support supports HTTP3 or Quick, look for an Alt-SVC header. Alt-SVC header is sent by servers to inform clients that they can switch to HTTP3. This mechanism is different than switching from HTTP1 to HTTP2. The reason is that for deciding between HTTP1 and HTTP2, you can open a TCP connection and then negotiate, like, what version to use. With Quick, you have to open a separate Quick connection and you have to know where you can connect 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 support Quick today, 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, go for the IEO Quick library. It's the only Python library mentioned at the IETF Quick Working Group. I tried it and it works nice. Yes, I tried it. That's all. I write Python a lot, but my code does not use HTTP3 yet. Sorry. Why? Let's ignore the fact that Google Quick is available in Chrome only and deployments of IETF Quick are experimental at best. 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. I told you that the main advantage of Quick is multiplexing. Is that you can issue multiple requests in parallel. To use that, I need some kind of async programming. Probably async.io in Python. Another issue with HTTP3 is the Alt-SVC header. Your client has to remember what servers send this header. What servers support Quick? Your clients will need storage. The storage will be needed for 0RTT2. Before speaking about migration to HTTP3, I should probably talk about HTTP2 first. I guess that most of you do not even use HTTP2 in Python yet. The most common library for issuing HTTP requests is URLF3. You probably use it because it is a dependency of popular libraries like PayPal or Request. It does not support HTTP2 yet. If I had to choose a library for HTTP2, I would use HTTPX. It has a nice API and it supports async invocation. I would like to have something like HTTPX. A library that has a nice API, it supports all the protocol and it is asynchronous. I want a library that chooses the best HTTP version for me. When I write Python, I do not want to care about HTTP versions. Until I have that, I will probably use HTTP1 from the 90s. Let's summarize what I have presented to you. We have had new transport protocol called Quick. It is a TCP replacement on top of UDP. HTTP3 is similar to HTTP2, but built on top of Quick on top of UDP instead of TCP. For practical usage, I want to issue HTTP requests without caring about HTTP versions. Similar to browsers. When I use my browser, I do not care what HTTP version it uses. I like to view that HTTP is only one. The versions are just mappings to different transport layers. I use HTTP1 and HTTP2 to map this one HTTP to TCP and HTTP3 maps this protocol to UDP. Should you care? I think you should be aware that something important and interesting is happening. All the big players are involved with that. The change is quite low level, so it may not affect you directly. If you are programming for the VAT, then you should at least keep an eye on it. If you want to learn more, I already recommended talks from Daniel Steinberg's. If you want more details or more critical view, look for talks from Robin Marks. Obviously, I should not forget about the IETF Quick Working Group. I will also mention that even more links are at my personal homepage with these slides. You will find the link in the schedule or in the chat. That's all from my site. Thank you very much for listening to me. Thank you. I will close the play of applause and I will remember to do that. Thank you. That was a really nice, really interesting talk. We have time for maybe one or two questions, not at all. I would pick one. I think it's a question. I think that's also a question. Quick is not adding another layer. If you compare it to HTTPS, it uses the same layer. It's just integrated to the protocol itself. Quick is faster. You should measure what works in your case. I think it's in common. I would recommend for most use cases, write your apps as you do so far. I would recommend for most use cases, write your apps as you do so far. I would recommend for most use cases, write your apps as you do so far. I would recommend for most use cases, write your apps as you do so far. I would recommend for most use cases, write your apps as you do so far.
 Okay, so you're going to talk.  I'm going to talk.  Okay, perfect.  So this is Mira's lab then we will welcome.  And today we're going to talk about Hey, she paid three.  Why should we all care.  You're going to tell us right.  Yeah, I hope I will try to still tell my mess.  So hi everybody.  Welcome.  And I hope that you are curious about the three and I wish you to enjoy this talk.  This is like an exceptional opportunity for me to speak at your Python.  As I told, I'm a lot of women and I'm streaming from Prague.  I work here for a come my technologies in the protocol optimization team.  You don't know that a come I runs one of the largest CDNs in the world with more than quarter of millions servers around the globe.  And our picture thick is more than 150 rabbits per second.  The reason why I'm speaking here today about GDP free is that our protocol optimization team enabled quick for this whole a come I network.  If you are wondering how quick is related to HTTP free, then you are watching the right video, because I will explain you what quick and what HTTP free are in next approximately 40 minutes.  I assume that you have at least rough idea what happens under the hood, where, when 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 to make everything clear.  When you visit a website, a browser issues HTTP requests and the GPS a simple text protocol, you can speak HTTP or self.  Even without a web browser, you open a TCP connection, for example, using telnet or net cat 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.  That most of you know this protocol because it's here 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.  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 open SSL, I can write my HTTP request as just I did before.  If you want something more sophisticated, we should move to 2015 when HTTP was published.  Unlike the first version, HTTP to is a binary protocol.  So I won't show you an example here.  HTTP to 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.  Let's look at an example.  However, that page is closing loaded using HTTP one.  With HTTP one.  To browser us typically open multiple connections per server.  To allow at least some parallelism in most cases, browsers open six connections per server.  Per domain.  And so let's look at the slide.  First, an HTML page is loaded.  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 browser is open another five connections and download six objects at parallel.  The yellow and red lines show measure the time necessary for connection setup.  For direct requests have to wait until the one of connections is available until one of previous connections finish and so on.  For direct requests are queued for even longer.  In this diagram, the green bars are waiting times a latency at time between a server sends a request and gets a response.  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 day download times.  The described issue is called HTTP head of line blocking.  The issue is that HTTP requests are blocked 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.  But you can imagine that it may not be the best idea to download everything in one block.  Probably because you will be downloading much more than you need.  With HTTP to browser is 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 as a game changer.  Today, most top sites use HTTP to.  I would say that when performance matter, HTTP to should be used. Obviously, you should measure what works in your specific use case.  That's my generic recommendation.  Because with HTTP one, you can be limited by latency by the distance to the server with HTTP to this limitation is to priest, allowing you to utilize most of that than they.  So, we have two important HTTP versions.  We have HTTP one, which is more than 20 years old.  And still good enough for most sites.  And we have HTTP to which was standardized only five years ago.  And which is still good enough, which is 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 HTTP free offer us.  The answer is that HTTP free is completely different.  It replaces foundations of the Internet.  That's a brave statement.  What are the Internet foundations. 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 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.  If something is delayed TCP reorders it.  The TCP layer handles various network glitches for you.  So you get a ribby stream and you don't have to care how it is implemented.  You can write anything to a TCP socket.  In this talk, we care mainly about HTTP free.  But TCP can transport anything.  It can be FTP.  It can be emails over a pop free or SMTP and hundreds of other protocols.  This TCP protocol is older than HTTP.  It's here from the 80s with the early implementations from the 70s.  And we use it since then.  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.  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, and how all 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 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.  We get HTTPS.  But for example, FTPS is FTP over TLS over TCP.  And now, what would be our options if somebody denied us from using TCP?  TCP has a younger and less clever browser called UDP.  UDP is primitive compared to TCP.  If UDP, you sent your packets 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, 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.  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,  then maybe I would try to build something like TCP on top of UDP,  some kind of abstraction to reuse my code between applications.  And maybe that may not be a diverse idea.  Maybe the thing that we built on top of UDP can be actually better than the original TCP.  Say hello to Qwik.  Qwik is a new transport protocol design in Google.  It emulates and improves TCP on top of UDP.  Qwik is TCP redesigned and rewritten from scratch.  Qwik has to implement everything normally provided to you by the kernel of your operating system.  It has to implement it in your apps in user space.  And similar to TCP, Qwik retransmits and reorders packets so you get a reliable byte stream.  And you don't have to care how it is implemented.  The difference from TCP is that Qwik has the OS built in.  Everything delivered using Qwik is encrypted by default.  And when we compare this to TCP, Qwik can be also used to deliver any message including HTTP.  At least in theory or in future.  In practice today, we use Qwik almost exclusively with HTTP.  But in this talk, we care about HTTP.  And this gets me to HTTP free.  HTTP free is HTTP over Qwik.  HTTP version free is similar to HTTP version two, but it is delivered using Qwik, using UDP instead of TCP.  That's what makes HTTP free so interesting.  It uses a completely different transport protocol under the hood than we used since the 90s.  But one does not rewrite like TCP layer just for fun.  The new layer should give us some advantages.  So what they are.  The main advantage of Qwik is that it's multiplexed.  It supports many independent streams, many independent logical flows within a single connection.  Wait, wait, wait, wait.  Did you listen to me?  Didn't I told you that the multiplexing is the main advantage of HTTP too?  I did.  But let me explain the difference.  HTTP is multiplexed, but the underlying TCP is not.  So when you are transferring multiple objects, multiple requests in parallel over HTTP,  HTTP has to sterilize them into a single TCP stream.  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.  Your operating system 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.  This is called TCP head of line blocking.  So with HTTP2, we got rid of HTTP head of line blocking.  But we got the TCP head of line blocking instead.  Slightly better, but not much.  Quick, 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.  Others can continue.  This can improve performance and user experience on lossy connections.  Another important quick advantage is that it offers a faster connection setup.  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 to set up some encryption context to set up your TLS.  So first useful data can be delivered in the third round trip at best.  With Quick, you have one layer less.  The Quick handshake and TLS handshake can happen at the same time, shortening the connection setup.  But we can make this even faster, even better.  Quick also supports so-called zero RTT.  With the zero RTT handshake, we can include useful data with the handshake.  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.  I have to warn you that there is one danger with the zero RTT.  It's the security issue that it allows replay attacks.  For that reason, you should enable it only for hidden potent requests only.  For requests that can be replied 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.  But it does not work very well in the practice.  I will explain it in a minute while.  Another quick advantage, an interesting one, is that Quick supports connection migration.  Unlike TCP, Quick does not identify 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.  So 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 Quick is always encrypted.  What's important here is that Quick encrypts not only your message, but also metadata, traffic control, headers.  Because with TLS over TCP, your message is encrypted.  But the things around that, like the headers, the metadata, are not.  This increase encryption is important for your privacy, obviously.  But not only for that, it is also important for future development of the technology, for future development of Quick.  Because there's a problem with internet, and the problem is that there are many devices, many boxes, that try to help you.  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, 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 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.  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.  So we use the exception TCP fast open.  The thing that's something like zero RTT in Quick.  It was never widely adopted, because there are many boxes that consider traffic with this extension invalid.  And they can drop this traffic.  So TCP fast open can become like TCP slope.  By encrypting everything in Quick, including traffic control, including metadata, including headers, we refuse any help from the middle boxes.  Thanks to that, the Quick protocol can evolve in future.  We say that Quick avoids ossification.  There are other advantages.  And interesting one is that Quick offers much faster development.  Because it's implemented in the user space, it's implemented in apps, you can upgrade Quick with any software upgrade.  You get a new browser version, and you can get a new Quick version.  Quick also offers better options 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, but not too fast to cause packet loss.  But no technology comes with advantages only.  So there are challenges for Quick too.  From my point of view, the main problem with Quick is that it's new.  So for example, internet providers may not expect regular traffic over UDP, and they can rate limit it or even block it.  And because Quick is not implemented in operating systems, apps have to provide their own implementation.  And if we compare random implementations with the TCP stack optimized since the 80s, quality of Quick can be questionable.  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?  I hope that you are curious.  But before I get to that, I have to clarify one important distinction.  Distinction between two Quick implementations.  We have Google Click and IETF Quick.  Google Click or G-Click is a proprietary open source.  Is that possible?  It's open source available in Chromium, but developed by one company by Google.  It's standardized and it can change with like any Chromium or any Chrome version.  On the other hand, IETF Quick or Quick with no prefix is the upcoming standard.  And IETF Working Group is finalizing it, so we will hopefully have an official version soon.  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 G-Quick.  It's quite likely that you are already using Google Quick today.  When a Chrome browser connects to a Google server, it will very often use Quick.  It will use Quick in most cases.  And Chrome is a quite common client and Google services are also popular.  So significant portion of traffic today is already over Quick.  In Akamai, we enabled G-Quick for all media customers.  That's a lot of traffic too.  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.  But strictly speaking, G-Quick is not HTTP-free.  And this talk is about HTTP-free.  HTTP-free is HTTP over IETF Quick.  It's the upcoming standard.  And we can expect support for HTTP-free for the IETF Quick in all major browsers.  Chrome Canary and Firefox Nightly support IETF Quick for some time already.  And Apple announced support for it in their next operating systems.  So I believe that we will get to official support in all browsers soon.  Speaking about clients, special mention belongs to Chrome,  which has an experimental support for HTTP-free.  The reason is that Chrome is not only a command-line tool,  it's also a C library, a very popular C library.  So if, yeah, so if for example, your car will speak HTTP-free in future,  it will be most likely thanks to Lipkara.  If you want to learn more about HTTP-free, then my first recommendation would be talks from Danny Austin,  but the author of Chrome. On the server side, you can notice that CDNs,  content-driven networks, do not want to miss this opportunity.  CDNs are investing into Quick 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,  you may like that HTTP-free support for NGINX is in progress.  The code is developed in a separate quick branch, so the support is not stable yet,  but I believe that they will get there.  Just be aware that 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 quick configuration.  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 ITI working group.  There is not only the list of implementations, 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.  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 ITI working group.  We have two versions.  What version to choose today? Google Quick or IETF Quick?  Let me give you an answer.  If you want to develop anything today, go for the standard IETF version.  Its support is experimental only today, but this should get much better soon.  Akamai supports Quick since 2016.  We deployed the proprietary version back then, and we are updating it since that.  This was the only way to offer Quick advantages to our customers and users.  It's still the only way today.  In practice, Google is backporting changes from the IETF Quick to their version.  It's quite likely that both versions will converge in the future.  This is very similar to how HTTP2 was born.  There was a proprietary protocol called Speedy.  It was developed in Google, then IETF took it, standardized it as HTTP2.  Today, everybody uses HTTP2 and nobody cares about Speedy.  If you want to see whether a support supports HTTP3 or Quick, look for an Alt-SVC header.  Alt-SVC header is sent by servers to inform clients that they can switch to HTTP3.  This mechanism is different than switching from HTTP1 to HTTP2.  The reason is that for deciding between HTTP1 and HTTP2, you can open a TCP connection and then negotiate, like, what version to use.  With Quick, you have to open a separate Quick connection and you have to know where you can connect 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 support Quick today, 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, go for the IEO Quick library. It's the only Python library mentioned at the IETF Quick Working Group.  I tried it and it works nice.  Yes, I tried it. That's all.  I write Python a lot, but my code does not use HTTP3 yet.  Sorry.  Why?  Let's ignore the fact that Google Quick is available in Chrome only and deployments of IETF Quick are experimental at best.  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.  I told you that the main advantage of Quick is multiplexing.  Is that you can issue multiple requests in parallel.  To use that, I need some kind of async programming.  Probably async.io in Python.  Another issue with HTTP3 is the Alt-SVC header.  Your client has to remember what servers send this header.  What servers support Quick?  Your clients will need storage.  The storage will be needed for 0RTT2.  Before speaking about migration to HTTP3, I should probably talk about HTTP2 first.  I guess that most of you do not even use HTTP2 in Python yet.  The most common library for issuing HTTP requests is URLF3.  You probably use it because it is a dependency of popular libraries like PayPal or Request.  It does not support HTTP2 yet.  If I had to choose a library for HTTP2, I would use HTTPX.  It has a nice API and it supports async invocation.  I would like to have something like HTTPX.  A library that has a nice API, it supports all the protocol and it is asynchronous.  I want a library that chooses the best HTTP version for me.  When I write Python, I do not want to care about HTTP versions.  Until I have that, I will probably use HTTP1 from the 90s.  Let's summarize what I have presented to you.  We have had new transport protocol called Quick.  It is a TCP replacement on top of UDP.  HTTP3 is similar to HTTP2, but built on top of Quick on top of UDP instead of TCP.  For practical usage, I want to issue HTTP requests without caring about HTTP versions.  Similar to browsers.  When I use my browser, I do not care what HTTP version it uses.  I like to view that HTTP is only one.  The versions are just mappings to different transport layers.  I use HTTP1 and HTTP2 to map this one HTTP to TCP and HTTP3 maps this protocol to UDP.  Should you care?  I think you should be aware that something important and interesting is happening.  All the big players are involved with that.  The change is quite low level, so it may not affect you directly.  If you are programming for the VAT, then you should at least keep an eye on it.  If you want to learn more, I already recommended talks from Daniel Steinberg's.  If you want more details or more critical view, look for talks from Robin Marks.  Obviously, I should not forget about the IETF Quick Working Group.  I will also mention that even more links are at my personal homepage with these slides.  You will find the link in the schedule or in the chat.  That's all from my site.  Thank you very much for listening to me.  Thank you.  I will close the play of applause and I will remember to do that.  Thank you. That was a really nice, really interesting talk.  We have time for maybe one or two questions, not at all.  I would pick one.  I think it's a question.  I think that's also a question.  Quick is not adding another layer.  If you compare it to HTTPS, it uses the same layer.  It's just integrated to the protocol itself.  Quick is faster.  You should measure what works in your case.  I think it's in common.  I would recommend for most use cases, write your apps as you do so far.  I would recommend for most use cases, write your apps as you do so far.  I would recommend for most use cases, write your apps as you do so far.  I would recommend for most use cases, write your apps as you do so far.  I would recommend for most use cases, write your apps as you do so far.
Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_0_263.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_264_311.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_312_755.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_756_1055.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_1056_1307.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_1308_2387.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_2388_3071.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_3072_4283.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_4284_5159.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_5160_6083.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_6084_8855.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_8856_9995.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_9996_11375.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_11376_12515.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_12516_12875.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_12876_13103.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_13104_15467.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_15468_16667.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_16668_19211.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_19212_20903.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_20904_22943.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_22944_24083.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_24084_27743.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_27744_32375.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_32376_34715.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_34716_37355.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_37356_38639.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_38640_40247.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_40248_40787.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_40788_42455.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_42456_44327.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_44328_45275.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_45276_46355.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_46356_46967.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_46968_48227.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_48228_48863.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_48864_49463.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_49464_53195.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_53196_53423.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_53424_53831.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_53832_55007.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_55008_56291.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_56292_57239.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_57240_57947.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_57948_58559.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_58560_59303.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_59304_59903.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_59904_60239.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_60240_60743.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_60744_60803.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_60804_60995.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_60996_61415.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_61416_61739.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_61740_61931.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_61932_62027.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62028_62075.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62076_62123.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62124_62171.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62172_62219.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62220_62423.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62424_62495.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62496_62903.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_62904_63395.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_63396_63575.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_63576_63959.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_63960_64091.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_64092_64727.png Miloslav_Pojman_-_HTTP_3___Why_should_I_care__vXbP7EmpErE_64728_65169.png