it bring to the table?
better speed i presume.
https://www.youtube.com/watch?v=5BT9sEopUoY
multiplexing!
the worldwide adoption will be late. for various reasons. like, in nations such as china, iran etc ... censorship has evolved around HTTP/2 and TCP it is not ready for QUIC and HTTP/3 therefore it is already blocked at least in iran. also, because the implementations are userspace. lot's of software need to change. that means webservers like nginx, CDNs and even your favorite libraries need to implement http/3 before you can use it. some of them are already supporting http/3 but I think what Daniel Stenberg and others mean is that the RFC is near done. the specification is about to be written in stone.
and as for why do we need it. the simplest example that I can think of is this, you know how you can't continue to watch a video while you go from WIFI to LTE? well that is about to change. in QUIC which is the underlying protocol for HTTP/3 you can resume a connection. meaning you can still watch that video without the connection being broken.
if you say, I have never experienced this with youtube. well, you lucky bastard :D QUIC is enabled for you already :D
Thanks, bro. Nice analogy.
Thank you, sir. I was watching this.
0-rtt TLS connections, better multiplexing, freedom from OS's TCP stack
Please explain 🙄
read the quic spec
RTT means the amount of time it takes for a packet to say "hello there" and a response that says "hello to you too". and 0-RTT means that there will be no time wasted. for example, in a normal HTTP/2 connection you have 3-4RTT multiplexing, have you seen the grid of a meat grinder? you know it has a few holes. well, think of each hole as one stream of data and the whole grid as the connection. so, you can have multiple streams of data in one connection. and freedom from OS is well, an opinionated answer. it is both good and bad. good because say you want HTTP/3 on linux right now. you don't have to get the approval of linus torvalds to add it to the kernel ... but bad, because if I can make my own HTTP/3 library and you can do too, how the hell are we going to be on the same track? most of that is ironed out once the specification is complete. but, the small things such as "connection fingerprint" will always vary. as it depends on so many factors like the TLS library it's used or the operating system's default or the standard library defaults of the language you used to build the library etc ... and that means for example, you can tell that which quic implementation is at use on your network. and you can use that metadata for fingerprinting, for censorship etc ...
Best. Explained Like I'm 5. What's the deal with Congestion Control on QUIC?
That, IDK how to explain like you're five :D you better read the RFC https://tools.ietf.org/html/draft-ietf-quic-recovery-32#section-4
As far as I understood, it implements various algorithms for retransmission at the cost of additional latency. Thanks, Sir.
yes but additional latency compared to UDP. remember. QUIC is implemented on top of UDP. so this cost is still less than TCP. but there is still one huge bottleneck. these algorithms all rely on CPU. large networks like CDNs are going to have a rough time with this. because they can't do hardware offloading.
So, HTTP 2 = TCP + TLS + HTTP HTTP 3 = UDP + TLS + HTTP
no, actually better. HTTP3 = UDP + (tls+HTTP). the TLS layer, is embedded within HTTP/3 it is not another layer.
oh, yeah right🤦♂️
Speaking of http3 does the browser already support it? Or it's need not browser support?
major ones do. but on canary versions. like chrome canary and firefox nightly
https://http3check.net/
Обсуждают сегодня