Everything You Need to Know About QUIC and HTTP3

Подписаться 32 тыс.

Просмотров 16 тыс.

50% 1

The Internet waited decades for an upgrade to HTTP/1. But several features of HTTP/2 have proved problematic, and now just six years after its introduction, HTTP/3 has come on the scene along with a brand new transport protocol, QUIC.
In this video, we review the history of HTTP, explain how HTTP/3 fixes problems with HTTP/2 and introduces new challenges, and discuss the NGINX implementation of QUIC and HTTP/3.
NGINX and QUIC
quic.nginx.org/
Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3
bit.ly/3OjKEUL
Chapters:
00:00 Introduction
00:14 Quick history breakdown of QUIC and HTTP3
04:03 HTTP/1.1 c. 1997
05:11 HTTP/2 c.2015
06:01 HTTP/3 .c2021
07:00 HTTP Stacks
07:43 HTTP Versions Today
09:26 Reality of HTTP Deployment
10:15 Environmental Factors
11:57 Revisiting the timeline of HTTP
12:29 What went wrong with HTTP/2
15:51 Head-of-line blocking hurts user experience
18:29 QUIC to the rescure
20:22 New Challenges
20:33 New Challenges: HTTP Version Negotiation
22:44 HTTP/3 Version Negotiation
23:52 New Challenges: UDP Exfiltration
25:00 nginx-quic
27:08 NGINX Configuration: HTTP/1
28:21 Summary of everything you need to know about QUIC and HTTP3

Наука

Опубликовано:

10 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 15

@sonyarianto 2 года назад

This is very good explanation of the evolving HTTP. This is gold content. I like concept explanation like this and will always useful anytime we watch it.

@xorengames 2 года назад

Great job on this presentation! Thanks for getting us up to speed on the current state of NGINX and the new features and challenges that HTTP3 will bring. I'm going to start testing the latest NGINX development branch now. Cheers!

@MikkoRantalainen 28 дней назад

Having public IPv4 address for your client machine is going to be even more valuable because UDP traffic works without any issues if you have public IPv4 address. If you have to use NAT, good luck.

@oleksiistri8429 Год назад

So comprehensible explanation, thank you!

@bitzerbutzer6053 2 года назад

Very good descriptive explanation

@iandaley2295 8 месяцев назад

This is an outstanding explanation

@starplatinum2008 2 года назад

Flawless presentation golden standard

@AbhishekTyagi Год назад

Excellent presentation.

@lukehjo 4 месяца назад

Lovely presentation.

@TimRiker 2 года назад

Excellent presentation! Is the slide deck available?

@MikkoRantalainen 28 дней назад

21:58 I would have loved to see every packet direction with it's own arrow. The double ended arrow "(key exchange and ecrypted session setup)" is missing lots of important details about why TCP latency hits that bad and why UDP can improve things. And you should also mention TLS Session Resumption (session ids and session tickets) and TCP Fast Open (TFO) because those reduce latency a lot for repeated connections which is the situation that QUIC / HTTP/3 is used, too. Otherwise you're comparing first connection of HTTP/2 to repeated connection using HTTP/3 which seems a bit dishonest. The most important part of HTTP/3 is to avoid head-of-line blocking and that really affects only the situation where network is flakey enough to lose random packets.

@nicolekho7791 Год назад

Setting the Alt-Svc header as showed in the video didn't work, I used instead add_header Alt-Svc 'h3=":$server_port"; ma=86400'; as suggested in the NGINX blog and it worked

@JivanPal 2 года назад

Why is this video unlisted...?

@MikkoRantalainen 28 дней назад

I expect a lot of company level firewalls are going to block QUIC / HTTP/3 because it's encrypted traffic over UDP. There's no way the firewall can inspect any of that data and UDP traffic is harder to monitor than TCP traffic in the first place. And because every server supporting HTTP/3 will also support HTTP/2, the end users are not going to see major hit even if HTTP/3 is not allowed. And to avoid smuggling encrypted data over port 53, I wouldn't be too surprised to see that non-plaintext communication over port 53 would be totally blocked, too.