Minor correction about HTTP/2 server push: it's not for updating a resource in the client side. It's a way to proactively send a resource known to be used on the requested resource (like sending a js when a request to an html is made), to avoid one round trip
It's not limited to that. As used by gRPC, for example. EDIT: I was wrong. Push is a different feature than used by gRPC. HTTP/2 just allows "streaming responses". It's not the same as an independent push, as I assumed. - Essentially: PUSH_PROMISE allows pre-starting a stream from the server, but client still must start all streams. - HTTP/2 allows pushing to an existing stream in roughly the same way as long polling in HTTP/1 (but it's less likely to accidentally die, and more).
@@Verrisin I'd argue that using server push for notifying the client of something is violating the HTTP spec. The HTTP (2 and 3) spec says clearly that it's the server fulfilling requests which it anticipates the client making, so the application layer of the client shouldn't even see those pushes until it itself makes a corresponding request. Do you have some reference for it being used by gRPC for sending data to the client? (A quick googling just shows people saying "gRPC is not using PUSH_PROMISE", but most of them are already some years old, so things might have changed.)
@@PauxloE I remember reading an article that said gRPC requires HTTP/2 because it's utilizing streams and server push for gRPC streaming. - I don't know the (gRPC or HTTP) spec, but do know it doesn't work over HTTP/1. - Maybe it's only using streams and actively polls for responses, but it seems less likely to me, if HTTP/2 can push somehow. (EDIT: It cannot. Pushing into an existing stream opened from a client is roughly the same as just sending more data in a chunked response)
In the end, it's roughly the same, but it's not that _exact_ PUSH feature of HTTP/2. - One could easily implement an extra stream, that lets server "push" what resource-streams the client should open, for example. - In the same way, websockets seem effectively built into (/unnecessary over) HTTP/2. - BUT I am not sure how HTTP/2 handles connections dying and re-establishing, etc. Maybe it's not a drop-in replacement, or there are other gotchas.
Well, If this is so clear. Would you mind to explain how QUIC protocol ensures that packets are not lost and why looses in some streams are insignificant?
Just yesterday I tried to find simple answer to this topic, but I couldn't on any site I've visited, and today this video just popped in my recommendations, and explained everything better in just 4 minutes. Thank you ☺💕
I learnt so much from this short video.. The history of HTTP made understanding the reasons for its successors to be specced and made this a great progression video rather than just a simple DATA DUMP.. Thank you for making this..
Http/1/1.1/2 are built on TCP Http/1.1 introduces "keep-alive" which allows a connection to reuse and avoid the expensive 3 way handshake Http/2: Http streams and (server) push capability Http/3 introduces QUIC protocol based on UDP to make stream first class in transportation layer, replacing TCP usage for mobile devices
HTTP is older than 1996. The first version named 0.9 was released in 1991, when the WWW was created at CERN by Tim Berner-Lee. Before the FORMAL release of HTTP/1, most features were available far before that in various draft states. I would say the HTTP/1 that most of us know and love was shaped around 1994.
One question, if we are moving to UDP based protocol in HTTP/3, isn't that a problem for reliability? I mean in TCP we have concept of ack for it. Doesn't UDP based protocol have issue with packet loss?
TCP can also experience packet loss, but it's handled for you. And handled quite poorly - data transmission stops until you ACK the received packet. That creates an issue of Head-of-line blocking, mentioned in the video. The issue is - you are not commonly sending just one packet of data, so why block on one? QUICK solves this problem, by being way smarter at packet ACKs.
As others have already said, QUIC handles the retransmission for you. In any case, we already use UDP for protocols that should be using TCP (the DNS protocol, for instance). It's not an issue. Back then, networks weren't as reliable as now. Nowadays we can afford to handle retransmission at a higher level because we most likely won't need it as much.
gQUIC started in 2012, so it's takes 10 years to evolve to QUIC in 2020 through to ratification in 2022. The problem QUIC introduces is that each element of the HTTP/3 request is not a separate request which can be intercepted for inspection for IDP/IDS. This forces secuirty solutions to use endpoint tools for monitoring/blocking, or you just reject UDP/443 and force fallback to allow IDP inspection to take place.
The good thing about HTTP/1.1 was that everyone could implement it. You can even talk HTTP manually because it is a text based protocol. Everyone can easily debug it. Starting with HTTP/2, it has become a lot more difficult to implement. You need a lot of time to implement it and implement it correctly. Debugging is not so easy anymore unless you write some tooling that translates the payloads for you. Now for HTTP/3 you are almost required to rely heavily on library support. Implementing your own webserver? You just don't. You are not supposed to. Let the "big guys/girls" make the job. The problem with this is: if nobody feels like implementing a new webserver for fun in their spare time, eventually nobody CAN implement a new webserver and that skill will be lost. That is the huge downside of introducing complexity. You reduce the number of people who understand the stuff to a minimum and they will disappear eventually and the next gen developers won't have half of the knowledge they should have to continue the work properly. Software will be degenerading fast.
Lol, video compression is pretty complex these days, I don't see many people complain about that. Wait until some fairly complex Forward Error Correction becomes mainstream for QUIC (if it didn't already, like RaptorQ for example). The people won't go away, the bar is getting raised every year, but yes you probably won't be able to work on your completely own implementation of HTTP/3 working at a small company.
You don't see people building Roman style roads around anymore; it's simply not something that's demanded by modern society. Unless there's a way to create some demand for it, it'll take a lot of superfluous resources and money to forcibly keep that skill alive beyond its apparent utility.
people wont disappear because implementing a web server is hard. There are still people writing compilers, creating new languages, new web browsers, even new operating systems! (which are not very popular, but still). I think you are worried for no reason.
@@iUniversEi I will read it sometime, thanks for recommendation. Do you actually believe that we will lose the skill of building web servers because its complex? When it has been proven to not be the case in other similar areas (OS, browsers, languages, compilers, etc)?
Don’t forget that HTTP/1.1 introduced chunking so that the size of a resource didn’t have to be known at the time of the request. Ultimately chunking is superseded by HTTP/2.
QUIC took the ideas from HTTP/2 (multiple streams in one connection), made them more generic, and moved to the transport layer, merging with the encryption. After QUIC was finally standardized (the process took a while), of course a version of HTTP which uses it had to be published, otherwise it would not be of much use. (HTTP/3 by itself is much simpler than HTTP/2, because it can use the infrastructure provided by QUIC.) I guess one could have named it "HTTP over QUIC", but they then settled for HTTP/3 instead, as this is more user-intuitive. All HTTP versions can be used in parallel (assuming servers and clients support them), the semantics towards the applications are still the same (and were recently re-specified in a version-independent way in RFC 9110). QUIC (and thus HTTP/3) won't be supported everywhere (specifically people behind old routers/firewalls which might not let UDP through), so HTTP/2 is still useful in those cases.
QUIC is in principle independent of HTTP, but it was developed based on a prototype from Google (used as a replacement for HTTP), and its main motivation is for purposes like HTTP. HTTP/3 is using QUIC as its base, and is therefore in itself much simpler than HTTP/2 (which is based on TCP).
0:17 There was an HTTP/0.9, which left out some of the header structure. I think it was very quickly replaced with HTTP/1.0, which regularized the whole request/response structure.
When using tcp your packets are guaranteed to arrive without errors and in order, or not at all. So if a tcp packet that is part of a request errors, all packets after that one are held up. Later requests are never even seen by the application until that blocking packet makes it through. This is what causes head of line blocking at the transport layer. When you use multiple connections those later requests do make it thru, and it is up to the application to decide if they should be blocked or not.
Are there any benefits of using QUIC over HTTP/2 for requests by desktop clients? Afaik, UDP is more prone to packet loss than TCP, So is QUIC's handling of managing streams at the transport layer more efficient than that of HTTP/2 handling it in application layer? Also, thanks for the wonderfully animated video and simply explained concepts.
The big difference between UDP and TCP is tcp defines a few more fields and associated behavior. The real reason QUIC is on UDP is protocol fossilization due to middle-ware monkeying. QUICs managing of streams is better, but there does seem to be a CPU cost currently associated with using QUIC.
Http/2 realies on TCP, so quic replaces TCP not HTTP/2 UDP is TCP without flow control... it is not inherently more prone to package loss. It simply does nothing when it happens and the user will see the drop, while tcp asks for retransmits. It is by design. The retransmits is reimplemented by quic as well so nothing changes in this regard. The main difference i see is everything will be encrypted and compressed by default. No firewall filtering or l middleman anymore...
Packet losses happens in UDP because you aren't establishing a three way handshake, packets are not kept for resiliency to begin with, they are kept for streaming. QUIC does the handshake, but now using QUIC connection ID, thus server side knows that it is still using the same connecting channel and recognize it as same client, albeit client is now switching b/w multiple telecom protocols. That's what I've understood.
@@marcelo55869 If I understand it correctly, TCP and UDP were two majorly used networking protocols and QUIC is a new addition to them. QUIC is based on UDP but QUIC handles retransmission of packets which are lost. If we overcome the high CPU cost requirements of QUIC (as stated by @Stephen Pollei), QUIC has high chances of replacing TCP as the more reliable and efficient way of communication. Would I be correct in assuming this? PS. Thanks to everyone for the reply.
@@junaidsiddiqui5140 Yes, QUIC fulfills some of the functions of TCP (congestion control, flow control, retransmission of lost packages), also takes over parts of the functions from TLS (record protection), and also provides additional functions (multiple streams in one connection with common congestion control). It's not a drop-in replacement of TCP, as it doesn't just transfer two streams of data (one per direction), but there are multiple streams (one or two-directional ones). So an application protocol which is currently based on TCP, which wants to also support QUIC needs to at least specify which streams are used and how. (This is what most of the version-specific part of the HTTP/3 spec is about.) Some of the innovations now made in QUIC (with regards to congestion and flow control) might end up also in future versions of TCP.
I love your videos. Please keep them coming. I was just wondering if you could share what do you use to create your briliant animations as I would love to put these into my presentations
Luck is 0.0001% Hard work is 100% .... instead of waiting to get lucky, start working hard and get lucky.... Hard work and investing in yourself is the best investment ever. a fellow creator
May I ask which protocol is more suitable for the edge weak network environment, and why? In addition, what is the relationship between QUIC and websocket and today's content?
what about hybrid? end users use ordinary http 2 or 1 and http3 are used by internet hopping devices like routers or switches and servers for fast communication since servers are cpu intensive can transmit alot of data
Learned something new…so I subscribed.
Quality, no fluff, presentation.
Minor correction about HTTP/2 server push: it's not for updating a resource in the client side. It's a way to proactively send a resource known to be used on the requested resource (like sending a js when a request to an html is made), to avoid one round trip
It's not limited to that. As used by gRPC, for example.
EDIT: I was wrong. Push is a different feature than used by gRPC. HTTP/2 just allows "streaming responses". It's not the same as an independent push, as I assumed.
- Essentially: PUSH_PROMISE allows pre-starting a stream from the server, but client still must start all streams.
- HTTP/2 allows pushing to an existing stream in roughly the same way as long polling in HTTP/1 (but it's less likely to accidentally die, and more).
@@Verrisin I'd argue that using server push for notifying the client of something is violating the HTTP spec.
The HTTP (2 and 3) spec says clearly that it's the server fulfilling requests which it anticipates the client making, so the application layer of the client shouldn't even see those pushes until it itself makes a corresponding request.
Do you have some reference for it being used by gRPC for sending data to the client? (A quick googling just shows people saying "gRPC is not using PUSH_PROMISE", but most of them are already some years old, so things might have changed.)
@@PauxloE I remember reading an article that said gRPC requires HTTP/2 because it's utilizing streams and server push for gRPC streaming.
- I don't know the (gRPC or HTTP) spec, but do know it doesn't work over HTTP/1.
- Maybe it's only using streams and actively polls for responses, but it seems less likely to me, if HTTP/2 can push somehow. (EDIT: It cannot. Pushing into an existing stream opened from a client is roughly the same as just sending more data in a chunked response)
In the end, it's roughly the same, but it's not that _exact_ PUSH feature of HTTP/2.
- One could easily implement an extra stream, that lets server "push" what resource-streams the client should open, for example.
- In the same way, websockets seem effectively built into (/unnecessary over) HTTP/2.
- BUT I am not sure how HTTP/2 handles connections dying and re-establishing, etc. Maybe it's not a drop-in replacement, or there are other gotchas.
@ByteByteGo it would be great if you have sample code NODEJS for this
I'm so old.
I know
🤝🏼
y
Yes
I'm so stupid
those are excellent tutorials. clear, short and straight to the point. the best find in years.
these are not tutorials
@@apidas there you're right, but it depends from where you start.
THIS IS IMPORTANT CONTENT THAT THE SYSTEM DESIGN BOOK DOESN'T TAKE.
Well, If this is so clear. Would you mind to explain how QUIC protocol ensures that packets are not lost and why looses in some streams are insignificant?
Just yesterday I tried to find simple answer to this topic, but I couldn't on any site I've visited, and today this video just popped in my recommendations, and explained everything better in just 4 minutes. Thank you ☺💕
brony :(
Your explanation and animations are simply amazing. They are crystal clear and straight to the point.Thanks a ton for sharing your knowledge. 👏👏👏
I learnt so much from this short video..
The history of HTTP made understanding the reasons for its successors to be specced and made this a great progression video rather than just a simple DATA DUMP..
Thank you for making this..
agree!
Http/1/1.1/2 are built on TCP
Http/1.1 introduces "keep-alive" which allows a connection to reuse and avoid the expensive 3 way handshake
Http/2: Http streams and (server) push capability
Http/3 introduces QUIC protocol based on UDP to make stream first class in transportation layer, replacing TCP usage for mobile devices
This is the best channel. Look forward to every new video.
Wow, just discovered this channel. Beautifully animated and on a subject I know very little about. Excellent! Subscribed
beautiful arrows, eh ?)))))
HTTP is older than 1996. The first version named 0.9 was released in 1991, when the WWW was created at CERN by Tim Berner-Lee. Before the FORMAL release of HTTP/1, most features were available far before that in various draft states. I would say the HTTP/1 that most of us know and love was shaped around 1994.
I see.
thank you the video was confusing, LOL what was I using in 1993? Should have said "officially"
@@LuigiSimoncini Yup... _that wasn't version 1 yet_
#rekt
New sub here! This is my first video & followed you on twitter!
This channel is going places!
This 4 minute video is more understandable than the 90 minute lecture I had about this
This video has given me more questions than answers.
Been very looking forward to this, and thank you so much for doing this so clear and concise
One question, if we are moving to UDP based protocol in HTTP/3, isn't that a problem for reliability? I mean in TCP we have concept of ack for it. Doesn't UDP based protocol have issue with packet loss?
HTTP/3 runs on top of QUIC which handles all of the reliability business :)
Refer to Hussein Nasser video on such topics..
TCP can also experience packet loss, but it's handled for you. And handled quite poorly - data transmission stops until you ACK the received packet. That creates an issue of Head-of-line blocking, mentioned in the video.
The issue is - you are not commonly sending just one packet of data, so why block on one?
QUICK solves this problem, by being way smarter at packet ACKs.
As others have already said, QUIC handles the retransmission for you. In any case, we already use UDP for protocols that should be using TCP (the DNS protocol, for instance). It's not an issue. Back then, networks weren't as reliable as now. Nowadays we can afford to handle retransmission at a higher level because we most likely won't need it as much.
There are many Reliable UDP-based protocols for a long time now, QUIC is one of them
So happy to finally find a straight forward explainer on this and why it's important. I'll likely be sharing this and I'm definitely subbing.
Finally, we get 3 and I enjoy it. Hopefully you do too.
What a efficient content within in 4 min and this is unbelievable. Great work team and Thank you for sharing such great content
It was the best explanation I have ever seen on this subject
Such an animated presentation! :D
i'm inverting the color video because dark > white for our eyes!
Keep up the good work guys! I wish this channel existed when I learned my basics.
Apart from the content, the animations and thumbnail are quite good. Cheers to the editor!
So glad to find thus channel, keep learning new tech
The HTTP/3 looks perfect for exceptionally precise user tracking, especially with a direct inbound UDP connection on an end-user device.
Oh- now that you mention it, the connection ID can track users across IPs also adda to it
Easy enough for browser to expire their connection IDs and negotiate new ones say, every 15 minutes.
If you choose to use stateful applications you don’t really get to bitch about them keeping state.
It was a vital info I wanted to understand. Thank you sir for Sharing sincerely and thank you TH-cam 🙏 for the priority order.
Thank you very much respected fellow, you answer lot of questions in just 4 minutes.
I'm so glad this channel just appear to me, just subsribed+liked+love it!
gQUIC started in 2012, so it's takes 10 years to evolve to QUIC in 2020 through to ratification in 2022.
The problem QUIC introduces is that each element of the HTTP/3 request is not a separate request which can be intercepted for inspection for IDP/IDS. This forces secuirty solutions to use endpoint tools for monitoring/blocking, or you just reject UDP/443 and force fallback to allow IDP inspection to take place.
Excellent. Thank you - brief, to the point and informative. Love it.
The good thing about HTTP/1.1 was that everyone could implement it. You can even talk HTTP manually because it is a text based protocol. Everyone can easily debug it.
Starting with HTTP/2, it has become a lot more difficult to implement. You need a lot of time to implement it and implement it correctly. Debugging is not so easy anymore unless you write some tooling that translates the payloads for you. Now for HTTP/3 you are almost required to rely heavily on library support. Implementing your own webserver? You just don't. You are not supposed to. Let the "big guys/girls" make the job. The problem with this is: if nobody feels like implementing a new webserver for fun in their spare time, eventually nobody CAN implement a new webserver and that skill will be lost. That is the huge downside of introducing complexity. You reduce the number of people who understand the stuff to a minimum and they will disappear eventually and the next gen developers won't have half of the knowledge they should have to continue the work properly. Software will be degenerading fast.
Lol, video compression is pretty complex these days, I don't see many people complain about that. Wait until some fairly complex Forward Error Correction becomes mainstream for QUIC (if it didn't already, like RaptorQ for example). The people won't go away, the bar is getting raised every year, but yes you probably won't be able to work on your completely own implementation of HTTP/3 working at a small company.
You don't see people building Roman style roads around anymore; it's simply not something that's demanded by modern society. Unless there's a way to create some demand for it, it'll take a lot of superfluous resources and money to forcibly keep that skill alive beyond its apparent utility.
people wont disappear because implementing a web server is hard. There are still people writing compilers, creating new languages, new web browsers, even new operating systems! (which are not very popular, but still). I think you are worried for no reason.
@@MrShaheer I can recommend Jonathan Blow, "Preventing the Collapse of Civilization", Moscow 2019
@@iUniversEi I will read it sometime, thanks for recommendation. Do you actually believe that we will lose the skill of building web servers because its complex? When it has been proven to not be the case in other similar areas (OS, browsers, languages, compilers, etc)?
I work with firewalls and this is a great explanation thanks 👍
Ultra concise. Just the way I like it! Thank you very much.
Short concise and to the point, thank you
TH-cam just recommend me this channel, jewel of explanation, +1 subscriber :D
Great vid. The concept of streams was being used in the telco field many years ago for signaling applications. Except it was done at layer 4.
High quality content. Good work.
Great initiative, please keep delivering content like that ❤️
Don’t forget that HTTP/1.1 introduced chunking so that the size of a resource didn’t have to be known at the time of the request. Ultimately chunking is superseded by HTTP/2.
Thank you for the clear explanation! Also it's unbelievable that http/3 has been released while /2 merely been used for some years 🤣
QUIC took the ideas from HTTP/2 (multiple streams in one connection), made them more generic, and moved to the transport layer, merging with the encryption.
After QUIC was finally standardized (the process took a while), of course a version of HTTP which uses it had to be published, otherwise it would not be of much use. (HTTP/3 by itself is much simpler than HTTP/2, because it can use the infrastructure provided by QUIC.)
I guess one could have named it "HTTP over QUIC", but they then settled for HTTP/3 instead, as this is more user-intuitive.
All HTTP versions can be used in parallel (assuming servers and clients support them), the semantics towards the applications are still the same (and were recently re-specified in a version-independent way in RFC 9110).
QUIC (and thus HTTP/3) won't be supported everywhere (specifically people behind old routers/firewalls which might not let UDP through), so HTTP/2 is still useful in those cases.
Informative & impressive. Concise & crisp!
Took 4mins to subscribe. Great content!
Try making a full fledge course your explaining skills is very good
Thank you for such a great video. Is there a resource to learn about HTTP3 and HTTP2?
I always thought QUIC was something separate to HTTP/2~3, Thank you for sharing this
QUIC is in principle independent of HTTP, but it was developed based on a prototype from Google (used as a replacement for HTTP), and its main motivation is for purposes like HTTP. HTTP/3 is using QUIC as its base, and is therefore in itself much simpler than HTTP/2 (which is based on TCP).
0:17 There was an HTTP/0.9, which left out some of the header structure. I think it was very quickly replaced with HTTP/1.0, which regularized the whole request/response structure.
Very nice explanation! Very clear and comprehensive! Great animation!
Wow this was excellent explained and visualized.
Good explanation mate 💪. Keep it up
amazing video. tnx.....wondering how quick QUIC will be adapted though in the normal web.
I like this channel. Great content
Great short explanations with the visuals.
Holy .. I learned so much so quickly! Much thanks!
That's a good visualization, thanks for that.
Could you explain more about the difference between Head of Line Blocking at the Application layer vs the Transport layer?
When using tcp your packets are guaranteed to arrive without errors and in order, or not at all. So if a tcp packet that is part of a request errors, all packets after that one are held up. Later requests are never even seen by the application until that blocking packet makes it through. This is what causes head of line blocking at the transport layer. When you use multiple connections those later requests do make it thru, and it is up to the application to decide if they should be blocked or not.
Thanks. Clear and to the point. Well done.
Thank you so much. It is so great, you explained very clear in 4 minutes.
Are there any benefits of using QUIC over HTTP/2 for requests by desktop clients? Afaik, UDP is more prone to packet loss than TCP, So is QUIC's handling of managing streams at the transport layer more efficient than that of HTTP/2 handling it in application layer?
Also, thanks for the wonderfully animated video and simply explained concepts.
The big difference between UDP and TCP is tcp defines a few more fields and associated behavior. The real reason QUIC is on UDP is protocol fossilization due to middle-ware monkeying. QUICs managing of streams is better, but there does seem to be a CPU cost currently associated with using QUIC.
Http/2 realies on TCP, so quic replaces TCP not HTTP/2
UDP is TCP without flow control... it is not inherently more prone to package loss. It simply does nothing when it happens and the user will see the drop, while tcp asks for retransmits. It is by design. The retransmits is reimplemented by quic as well so nothing changes in this regard.
The main difference i see is everything will be encrypted and compressed by default. No firewall filtering or l middleman anymore...
Packet losses happens in UDP because you aren't establishing a three way handshake, packets are not kept for resiliency to begin with, they are kept for streaming. QUIC does the handshake, but now using QUIC connection ID, thus server side knows that it is still using the same connecting channel and recognize it as same client, albeit client is now switching b/w multiple telecom protocols. That's what I've understood.
@@marcelo55869 If I understand it correctly, TCP and UDP were two majorly used networking protocols and QUIC is a new addition to them. QUIC is based on UDP but QUIC handles retransmission of packets which are lost. If we overcome the high CPU cost requirements of QUIC (as stated by @Stephen Pollei), QUIC has high chances of replacing TCP as the more reliable and efficient way of communication. Would I be correct in assuming this?
PS. Thanks to everyone for the reply.
@@junaidsiddiqui5140 Yes, QUIC fulfills some of the functions of TCP (congestion control, flow control, retransmission of lost packages), also takes over parts of the functions from TLS (record protection), and also provides additional functions (multiple streams in one connection with common congestion control).
It's not a drop-in replacement of TCP, as it doesn't just transfer two streams of data (one per direction), but there are multiple streams (one or two-directional ones). So an application protocol which is currently based on TCP, which wants to also support QUIC needs to at least specify which streams are used and how. (This is what most of the version-specific part of the HTTP/3 spec is about.)
Some of the innovations now made in QUIC (with regards to congestion and flow control) might end up also in future versions of TCP.
Amazing video. Thank you, God bless you:)
You're really awesome in explaining it. Thanks ☺
Keep doing good job
You videos are incredibly interesting, thank you very much!
I love your videos. Please keep them coming. I was just wondering if you could share what do you use to create your briliant animations as I would love to put these into my presentations
Thank you for explaining in a nutshell
Thanks for this! How do you animate these videos?
I have no choice but subscribed. 😇
I hope this channel gets to grow AF. Valuable and stright to the point content. Congratz on the format!
pipelining = ARQ Go Back N
streams = ARQ Selective Repeat
pd. Correct me if am wrong
Very clear and informative, thanks
Thank you for the video.
I didn't know about QUIC and was wondering how that internet exchange happens between wifi and mobile data
Thanks for introducing me to http3 !
You got to tighten up barbara
It's beneficial for smoother connectivity, but connection id is yet another footprint that can be used for id'ing a device it seems.
HTTP/3 is nice. Waiting for HTTP/4
So we moved from adherence to the physical communication transport to transport-independent context adherence paradigm.
Great video. What software do you use to generate such animation?
Thanks for the lesson
Very informative. Thank you for this video!
damn! Great animations! Anyone know what software is used for this ?
HTTP 4 you can download the entire server via 5G network for zero latency
So great content.Thank you so much!
You tutorials are excellent!!!!!
I love this guy!
Really, really clear explanations. Thank you.
Nice video, bro.
How do you make the fancy process flow animation?
Simply wow!
Good clear explanation! I just subscribed!
What did you use to make your video?
To the point. Loved it
What tool do you use to create these animations? They are fantastic!
I think it may be created with something like Adobe Aftereffects with plugin. Or maybe handcraften without any side plugins.
I would like to know too.
Luck is 0.0001% Hard work is 100% .... instead of waiting to get lucky, start working hard and get lucky.... Hard work and investing in yourself is the best investment ever. a fellow creator
May I ask which protocol is more suitable for the edge weak network environment, and why? In addition, what is the relationship between QUIC and websocket and today's content?
i love your explanations. thank you
love the video, finally UDP saves us
Good stuff
Great video, packed with clear information and right to the point 👍🏼
Thank you very much for your very useful videos!
thanks for to the point tutorials
well done
3:48 FYI, 25% is a quarter. You’re welcome 👍
thank you
what about hybrid?
end users use ordinary http 2 or 1
and http3 are used by internet hopping devices like routers or switches and servers for fast communication
since servers are cpu intensive can transmit alot of data