HTTP 1 Vs HTTP 2 Vs HTTP 3!

Поділитися
Вставка
  • Опубліковано 6 лис 2024

КОМЕНТАРІ • 215

  • @anastasiaviva5721
    @anastasiaviva5721 2 місяці тому +167

    If only explanations could win Oscars… Thank u for delivering such high quality content!!!

  • @vylbird8014
    @vylbird8014 Місяць тому +52

    One "Fun" annoyance: You can't use QUIC without a TCP fallback, because a great number of company firewalls will block any port that isn't expressly allowed (as is sensible), and they generally don't allow UDP. Chrome will always open both HTTP3 and HTTP2 connections when trying to reach a host, so if the 3 fails it can fall back to 2 in no time at all.

    • @dmaraptor
      @dmaraptor Місяць тому +5

      Yeah, because QUICK is just UDP no more no less.

    • @vir2plus
      @vir2plus Місяць тому +1

      the new IE6 compatibility

    • @progfarkas
      @progfarkas 21 день тому +1

      If the browser suppots HTTP3: The browser first connects to the website via HTTP/2 and if the server advertises it's HTTP/3 port then the browser attempts to switch to HTTP/3; if it works, cool. The browser will use HTTP/3 for future requests too.
      Failure means there is no UDP response within a time range - that is a few seconds (based on the browser settings). So in this case the initial connection will be really slow. And it's not the server's fault, just a firewall between the server and the client drops UDP packets. (That is why by default the browser first uses HTTP/2.) After the timeout, the browser goes back to HTTP/2 and it will keep using HTTP/2 for future requests until you close the process. (In chrome's network debugger tool the protocol just shows HTTP/2. There is no sign, that it tried HTTP/3, but in the timing window there is a huge connection establish time.)

  • @AqgvP07r-hq3vu
    @AqgvP07r-hq3vu Місяць тому +27

    The thumbnail was so complete and beautiful that i could not press the video and automatically press the like button.

  • @quillaja
    @quillaja Місяць тому +72

    HTTP/4: The AI powered server pushes ads and recommended paid content directly to your devices without the slowdown of waiting for you to request them. Efficiently uploads your private information with 0 round trips to ask for permission.

    • @Gebsfrom404
      @Gebsfrom404 10 днів тому

      What a backwards idea, with neuralink you can have ads directly in your brain! No need to look at a screen or even open your eyes.

  • @arithex
    @arithex 2 місяці тому +35

    Q: How many software engineers does it take, to send a message from one computer to another?
    A: Apparently many millions of us, over a period of about 30 years.

    • @jfbeam
      @jfbeam Місяць тому +6

      One. But it's the most reinvented wheel in human history.

    • @vylbird8014
      @vylbird8014 Місяць тому

      The first message ever sent on ARPANET was "lo". It was supposed to be "login" but the still-experimental router crashed after two characters.

  • @shellcatt
    @shellcatt 2 місяці тому +33

    This video is so packed, if there were a quiz at the end of it I'd definitely fail at it, more than once :D

  • @bartosz0.
    @bartosz0. 2 місяці тому +75

    Me: I understand HTTP fairly well
    ByteByteGo: nope

  • @upgrade1373
    @upgrade1373 2 місяці тому +34

    great way of explaining how the web works

  • @Azcraz
    @Azcraz 20 днів тому +2

    You should EQ filter out some of the low end bass frequencies of your voice (aka high-pass). The voice audio is "boomey" when listening to the video on capable speakers. Great video, love the information and presentation!

  • @georgehelyar
    @georgehelyar 2 місяці тому +33

    The host header was a big deal in http 1.1. Before that you could not host multiple websites on the same ip, so if you were a web host you would only do separate paths for separate sites, or have to give each site their own server. Remember geocities?

    • @joergsonnenberger6836
      @joergsonnenberger6836 Місяць тому +3

      Yeah and they reintroduced the problem with SSL. It's funny how every new generation repeats the problem of the old one.

  • @k1m1
    @k1m1 Місяць тому

    Simple way of getting complex information. It is a perfect content. Subscribed. Well done guys !!!

  • @Cyclically
    @Cyclically 2 місяці тому +12

    These animations are insane

    • @MrHirenP
      @MrHirenP 2 місяці тому

      Do you know how it was done? I’d like to learn this

    • @andycivil
      @andycivil 2 місяці тому +2

      @@MrHirenP It says in the text: Adobe Illustrator and After Effects. I would also like to learn this, but there's NO way I would use an Adobe product. I have to search now and see what the open-source alternative would be.

    • @paulsaulpaul
      @paulsaulpaul Місяць тому +1

      @@andycivil Blender should be able to do all that, supports scripting, and has a very good video editor and compositor built in. The video editor is often overlooked.

  • @sudorandom
    @sudorandom 2 місяці тому +16

    When talking about QUIC integrating with TLS 1.3 the narrator actually says "TCP 1.3" which is not correct 😅
    This is a great summary though, I love the visuals

  • @K9Megahertz
    @K9Megahertz 2 місяці тому +66

    I've never understood why HTTP was designed to close the connection after requesting a single object. I do understand compute resources were much more constrained than they are today, so keeping tens of thousands of TCP connections open might be problematic, but even then I figured it was better to open a connection, request all the objects for a page, then at that point maybe terminate the connection.

    • @Acorn_Anomaly
      @Acorn_Anomaly 2 місяці тому +106

      Because in early versions of HTML, you were unlikely to be required to retrieve that many extra resources in the first place.
      IMAGES didn't even exist as part of HTML for a few years, and while the image tag got included as part of early HTML drafts around 1993, it wasn't actually part of any official HTML standard until the standard itself was established as HTML 2.0 in 1995.
      Consider the name: Hyper _TEXT_ Markup Language. It was primarily intended to be a text-based presentation of information, which could all be delivered as one HTML document, needing one HTTP transfer.
      Hyper _media,_ with so many external resources needed(audio, video, images, scripts, etc), didn't really come around until later, and didn't become a gigantic focus until much later.
      EDIT: Also, HTTP 1.1, which first introduced the ability to use a single connection to handle multiple requests, came out only a year after HTTP 1.0 did, in 1997. Once the need for requesting multiple resources became apparent, it was added to the standard fairly quickly.

    • @K9Megahertz
      @K9Megahertz 2 місяці тому +12

      @@Acorn_Anomaly Thank you, that does shed some light on things. I got on the internet in the early 90's and most pages had images by that time, so I might have been a little late to the party. =)

    • @milind006
      @milind006 2 місяці тому

      @@K9Megahertz @Acorn_anomoly has explained it very well. I just want to add one minor thing.
      The focus on text is evidenced not just from Hyper Text Markup Language, but also the name of the protocol itself: Hyper Text Transfer Protocol. It was all supposed to be about just text.

    • @ericanthony8374
      @ericanthony8374 2 місяці тому +1

      🎉

    • @Acorn_Anomaly
      @Acorn_Anomaly 2 місяці тому

      @@K9MegahertzAdding on to the lack of multimedia thing, I think it's important to note how HTML didn't natively support any form of multimedia content besides images until HTML 5, which had its first draft release in 2008, and wasn't finalized as a standard until _2014._
      That's right, it was only _ten years ago_ that HTML gained native support for audio and video.
      Anything before then relied on external plugins and special browser support(like Adobe Flash or Java applets, or ActiveX objects). It was _not_ a part of HTML.
      (HTML _did_ have a tag for specifying external content, "applet", and later "object", but how they were used was basically up to browsers and plugins. The tag just pointed to the content, it was up to the browser and plugins what to do with it.)

  • @mr0big
    @mr0big 2 місяці тому +18

    1:20 actually we didn't use TLS back in the times of HTTP1.0 because it used too much of the precious CPU cycles. Unless you had to do something really security critical thing you just opted for the cheap solution. Also there wasn't much to be stolen on the internet back then :)

    • @BrianIrwin
      @BrianIrwin Місяць тому +10

      And TLS was called SSL :)

    • @tribela
      @tribela Місяць тому +3

      And SSL was not free(price) to use

    • @vylbird8014
      @vylbird8014 Місяць тому

      @@tribela Not on the general internet anyway. There were no free cert providers.

    • @joergsonnenberger6836
      @joergsonnenberger6836 Місяць тому +1

      SSL 2.0 actually predates HTTP/1.1 by three years.

  • @samjohnson5044
    @samjohnson5044 21 день тому

    Thank you for this historical review!

  • @swamihuman9395
    @swamihuman9395 Місяць тому

    - Thx.
    - Well done: clear/concise; and informative. Excellent graphics, too.
    - Keep up the great content...

  • @lohphat
    @lohphat 10 днів тому

    QUIC breaks content inspection at the f/w and local endpoint security solutions. Many orgs just block it outright until security catches up.

  • @username7763
    @username7763 Місяць тому +2

    Very good explanation. It seems wrong that we still call it HTTP. All these new features and protocol changes are about everything other than the transferring of hypertext.

    • @udasai
      @udasai Місяць тому

      In the future you'll just get a streaming video feed with no client side logic. You won't need to worry about security because it all runs through the NSA trunk line into Google. The next step is to download an AI into your NPU and you won't even need to receive content because the AI will generate it on the fly, along with recommendations for a cold, delicious Coca-Cola product.

    • @daitedve1984
      @daitedve1984 Місяць тому

      This protocol was dumb from the very first second of its idea. Text request, then BINARY reply with picture... WTF?!?! W3C old m0r0ns cannot make anything properly!

  • @-MohammedElSyed-
    @-MohammedElSyed- 6 днів тому

    Thanks for the vid but it would be fair to point the downsides of HTTP 3.0 like you did with the previous versions of this protocol.

  • @PhuongNguyen-rg1rd
    @PhuongNguyen-rg1rd 24 дні тому

    i'm just curious, which tools do you use to make these animation?

  • @SirusStarTV
    @SirusStarTV 2 місяці тому +8

    HTTP 1.1 is text based protocol, each header is separated by CRLF "carriage return and line feed" symbols like in Windows text files, in programming languages written like "
    " in string literal.
    After the last header you need to add additional CRLF to define the start of body of http request or response, the length of data in a body is expected to be set by "Content-Length" header. Example:
    POST /api/endpoint HTTP/1.1 *CRLF*
    Content-Type: application/json *CRLF*
    Content-Length: 34 *CRLF*
    *CRLF*
    { "someJsonKey": "someJsonValue" }

  • @IsmailSheikh-xs1dr
    @IsmailSheikh-xs1dr Місяць тому +2

    There is a mismatch in the thumbnail for the diagrams of HTTP/1.1 and HTTP/2. I think it should be swapped.

    • @-felt
      @-felt Місяць тому

      Did you click on it, watch the video, and/or engage in the comments? If yes; working working as intended.

    • @ankbG
      @ankbG 4 дні тому

      @@-feltThe purpose was the topic not the mismatch. I also recognized it…

  • @BlackbirdDH
    @BlackbirdDH 10 днів тому

    Awesome video .... great visualizations.

  • @kevmoo
    @kevmoo 2 місяці тому +14

    FYI: server push from HTTP 2 is no longer supported and many browsers

    • @lucaxtshotting2378
      @lucaxtshotting2378 2 місяці тому +7

      AND MANY BROWSERS WHATT

    • @kevmoo
      @kevmoo 2 місяці тому

      @@lucaxtshotting2378 in many browsers. Sorry

    • @Phototato
      @Phototato Місяць тому

      @@lucaxtshotting2378 we might never know 😭

    • @dliedke
      @dliedke Місяць тому

      ​In @@lucaxtshotting2378

    • @sfalpha
      @sfalpha Місяць тому +1

      It's also hard to implement from server side.
      Basically they found better way to just insert things in data-URI and it much more easier and faster than doing push.

  • @janangeloayco6882
    @janangeloayco6882 2 місяці тому +1

    thanks for the knowledge . great presentation and easy to absorb lesson ❤

  • @amirsaid
    @amirsaid 2 місяці тому +6

    Thank u, Great explanation as always 👏🏻

  • @kevinmoy3752
    @kevinmoy3752 22 дні тому

    the visual aid goes kinda crazy with it

  • @PatrickStaight
    @PatrickStaight 2 місяці тому +1

    Is QUIC compatible with onion protocol?
    Is QUIC a public standard or are there legal limitations on how it can be used related to ownership?

    • @vylbird8014
      @vylbird8014 Місяць тому +1

      1. No. Onion only transports TCP, not UDP.
      2. It is now. Originally it was controlled by google, but they took it to the IETF and had them formalise it as a standard.

    • @PatrickStaight
      @PatrickStaight Місяць тому

      @@vylbird8014 Thanks for the info.
      You rock!

  • @east4ming
    @east4ming 2 місяці тому +4

    There's an explosion of information, and I need to pause and think in a lot of places.

    • @araz911
      @araz911 Місяць тому +2

      he says 60% of internet is using http 2, LOL

    • @Bonez0r
      @Bonez0r 23 дні тому

      Because we can't process visual text and spoken different text at the same time. So we have to pause to read what's on the screen.

  • @joergsonnenberger6836
    @joergsonnenberger6836 Місяць тому

    There is no "HTTP/1". Chunked encoding allows using persistent connections with dynamically computed requests where the size is not known in advance. You could always send content immediately with HTTP/1.0, it was never required to compute Content-Length. HTTP/2 still has head-of-line blocking problems, just not with dynamic content. The funny part of HTTP/3 is that it has been proven to be often slower than HTTP/2.

  • @RichardPeterShon
    @RichardPeterShon 11 днів тому

    which midware webhost/language stack supports http3?

  • @agustinbs
    @agustinbs 2 місяці тому +1

    AMAZING EXPLANATION THANK YOU SO MUCH

  • @samsuh
    @samsuh 2 місяці тому +2

    neat. appreciate your animations :)

  • @lucaxtshotting2378
    @lucaxtshotting2378 2 місяці тому +3

    ugh I thought I was going to get into a sick video with code examples on how http sits over tcp or whatever... I'm too old for this abstract shit.
    I need to put eyes on browser and compiler (since I'm at it) code.
    It's incredible how the first protocols where developed all by Standford and DARPA or whatever, now it's some guy at google.
    Sick videos for professional level expert knowledge don't do well on youtube, and I understand it. I'm not in the mood for them half of the times myself.

  • @kyjo72682
    @kyjo72682 22 дні тому

    Nice overview. Thanks.

  • @noonenoone4165
    @noonenoone4165 Місяць тому

    hi what tools did you make to do the animation? thx

  • @raj_kundalia
    @raj_kundalia 2 місяці тому

    Thank you for doing this!

  • @EdwinMartin
    @EdwinMartin 2 місяці тому +11

    To be clear: POST was common before 1996. How else would you submit forms? It was only standardized in 1996.

    • @PeterVerhas
      @PeterVerhas 2 місяці тому +6

      You are correct with your statement, but the reasoning is wrong. You can send form data in the request URL using GET.

    • @EdwinMartin
      @EdwinMartin 2 місяці тому +1

      @@PeterVerhas Yes, you can send form data using GET, but I'm sure the url length was limited so it was discouraged.

    • @2pacgamer
      @2pacgamer Місяць тому

      simply by a GET but we do use POST to avoid sending the all data through URL cuz it's not secure

    • @PeterVerhas
      @PeterVerhas Місяць тому

      @@2pacgamer only if you can tell me why it is not secure. It travels in the same tcp channel.

    • @LucyPLM
      @LucyPLM Місяць тому +2

      @@PeterVerhas Its not that its secure because of encryption or something. Its because GET requests are cached, they also stay in your browser history. So if you submit a GET login form with your user and password, that will get cached and saved in your history, the length is very limited. POST however, its not cached, the data is not visible because is in the body not in the header, no length limit, supports different data types such as booleans. Also, the security is more of a safeguard more for the devs/websites rather than the user. Because we made the difference that GET just gets a resource, while POST alters or does something on the server.

  • @williamandrews9904
    @williamandrews9904 2 місяці тому

    Excellent content as always!!

  • @Ruhgtfo
    @Ruhgtfo 2 місяці тому +1

    Suitable for high quality content and 3d objects manipulating transmission.

  • @agneesingh7011
    @agneesingh7011 2 місяці тому +6

    great video, thanks for sharing

  • @kenedyolisi3551
    @kenedyolisi3551 Місяць тому

    Nice illustrations. Truly a picture is worth a thousand words. I think the like button is broken due to how is mashed it 😅.

  • @beremour
    @beremour 25 днів тому

    How do I ensure that my Firefox goes to page with http3/quic ?

  • @AndrejBrat
    @AndrejBrat 14 днів тому

    HTTP/1.1 Head-of-line: is it correct that if a request is delaying, all next request are waiting? As I read, if a request is delaying, just a new request has to wait.

  • @nuanda82
    @nuanda82 2 місяці тому

    thank you! I enjoyed a lot this video!

  • @__christopher__
    @__christopher__ Місяць тому

    I'm pretty sure at the time of HTTP/1, TLS didn't yet exists.

  • @williamleslie4939
    @williamleslie4939 2 місяці тому +1

    Well done!

  • @slartidan
    @slartidan Місяць тому +1

    Websockets are an important feature of HTTP2, that got little attention in this video, imho

    • @vylbird8014
      @vylbird8014 Місяць тому

      As someone who has had to configure a web content filter, I despise websockets. They are an ugly hack. An accident of history that exists solely as a workaround for... everything.
      1. Design TCP.
      2. Design HTTP.
      3. HTTP is amazing!
      4. Firewall admins block everything other than HTTP because they don't know what all the rest is, and it might be a security concern.
      5. But now how do we do real-time chat and games and and low-latency interactions?
      6. Hear me out... What about... TCP over HTTP over TCP!

    • @joergsonnenberger6836
      @joergsonnenberger6836 Місяць тому

      Websockets have little to nothing to do with HTTP. They are essentially just a mechanism to turn a HTTP connection into a plain TCP again. This is another great case of corporate firewalls breaking shit for everyone. WS are in a way much more like FTP.

    • @vylbird8014
      @vylbird8014 Місяць тому

      @@joergsonnenberger6836 Indeed they are, and that is their awkwardness: The only reason they exist is as workaround, to deal with the problem of so many firewalls blocking everything that isn't http(s) for security and content filtering reasons. It's just part a back-and-forth between firewall admins trying to keep out unrecognised traffic and application developers trying to make their unrecognised traffic get through.

  • @jgeoffrey1
    @jgeoffrey1 2 місяці тому +1

    Excellent video Thanks!!

  • @Taras-Nabad
    @Taras-Nabad 2 місяці тому +2

    Well done.

  • @fullStackInKannada
    @fullStackInKannada 2 місяці тому +2

    Very nice, I really liked it :)

  • @offgridvince
    @offgridvince Місяць тому +1

    Excellent 👌

  • @TzOk
    @TzOk Місяць тому

    Sadly, we tend to forget that somewhere deep, underneath those modern layers, a good old TCP/IP still exists.

    • @zazethe6553
      @zazethe6553 22 дні тому

      No, under http/3 there's no TCP as explained here

    • @TzOk
      @TzOk 15 днів тому

      ​@@zazethe6553 HTTP/3 is using the good, old UDP (which belongs to the TCP/IP protocol suite) but in disguise, under the name of a QUIC protocol. Which is yet another prothesis atop an old protocol. Aside from that, QUIC being a sublayer of HTTP/3, is an application protocol. By that, it violates the layer model, by providing transport layer protocol functionality within the application layer protocol.

  • @MomoZone-q5h
    @MomoZone-q5h Місяць тому

    На байбите всегда курс меньше?

  • @TheRealInscrutable
    @TheRealInscrutable Місяць тому

    Why does the http (an application layer) need to care about the physical connection (switching from cellular to WiFi for instance) - should that not be handled lower in the network stack?

    • @AntonioBarba_TheKaneB
      @AntonioBarba_TheKaneB Місяць тому

      the QUIC connection ID is not network level, it's an high level abstraction that could be thought of as some sort of "session ID". When the network stack switches IP addresses, for exemple by losing Wifi signal and switching to 5G, the lower parts of the network stack establish a completely new connection but the application layer uses the connection ID to continue the data transmission as nothing had changed (almost). So, yes, it's an application layer abstraction that allows for better decoupling with the underying network stack.

    • @bltzcstrnx
      @bltzcstrnx Місяць тому

      You need to reestablish connection when the underlying physical connection changes. Because, very likely, in this case, your IP also changes. If you're in the middle of loading during this or in constant connection, it'll likely be disconnected because now the server identifies you as a different client. Having an application layer connection ID means the server can still identify the same client connection even when the underlying address changes.

    • @TheRealInscrutable
      @TheRealInscrutable Місяць тому

      @@bltzcstrnx ah, that's true, I'd forgotten that even the MAC address changes because it's different hardware

    • @vylbird8014
      @vylbird8014 Місяць тому

      Usually yes, but the experience can be disruptive. Files stop downloading and have to be resumed, chat sessions drop, calls freeze, and the user is left annoyed while everything re-establishes from scratch - which can take a frustratingly long time, tens of seconds. Handling it at transport layer means the application layer can carry on mostly unaffected. Not entirely, but having your video call stutter and glitch for a few seconds is a lot better than disconnecting and having to call back.
      And yes, video calls often run over HTTPS. Yes, this is dumb. But it has to be that way, because if the customer is on an office or school network the firewall is almost certain to block everything by default - https is the only protocol you can be sure will actually get through all the time. This is why we invented Fucking Websockets, the bane of the web-filter admin's life.

    • @bltzcstrnx
      @bltzcstrnx Місяць тому

      @@vylbird8014 isn't most web video calls using WebRTC? Which itself uses SCTP for the underlying transport. Also, most real-time mobile applications nowadays are quite good at handling network changes. I've played real-time games on mobile, and it doesn't have a problem switching from wifi to cellular and vice-versa.

  • @DVVlong1990
    @DVVlong1990 24 дні тому

    thanks you for sharing

  • @robfielding8566
    @robfielding8566 Місяць тому +3

    the move to UDP was motivated by the pain of trying to edit TCP in any way. You can just send UDP packets and not do any assembly of them in the kernel; just have the applications do it. And in order to prevent firewalls from messing with it, it's inside of TLS.

    • @vylbird8014
      @vylbird8014 Місяць тому +2

      It's a little bit sillier even than that. The move to UDP, specifically, was because there can never be another protocol at transport layer now. We have TCP, UDP and ICMP - and never may there be another, because we have address translation and firewalls all over the place now. Not that people haven't tried - multipath TCP, SCTP, UDP-lite. They all hit the same problem: Unless the firewalls and address translation all along the route are configured to handle them, they don't work, and that just isn't realistic in most cases. So we are eternally stuck with only TCP and UDP.

    • @bltzcstrnx
      @bltzcstrnx Місяць тому

      @@vylbird8014 the one who designs UDP is a forward thinker. Even with TCP and UDP are cemented, people can just use UDP when designing new application layer protocol.

    • @robfielding8566
      @robfielding8566 Місяць тому

      @@vylbird8014 there is no reason that we need TCP to be in the kernel, given that UDP exists. make everything UDP sent to userland, and userland has TCP as a library. network accelerators basically hand off an entire ethernet card to a userspace program now; to keep it from bothering the kernel. it's like a 10x speedup.

  • @Pivok_App
    @Pivok_App Місяць тому

    damn these animations has got sth to say !
    thx bro!

  • @AslamNazeerShaikh
    @AslamNazeerShaikh 2 місяці тому +1

    Thanks ❤🎉

  • @JohnValenciaArias
    @JohnValenciaArias Місяць тому

    Very good conntent

  • @Kurt-g8l
    @Kurt-g8l Місяць тому

    Полезная подсказка, помогло.

  • @2pacgamer
    @2pacgamer Місяць тому

    really nice !

  • @boomboom-pro
    @boomboom-pro Місяць тому

    Techncial SEO ❤

  • @adolfoquevedo7429
    @adolfoquevedo7429 Місяць тому

    wow thanks!

  • @atelierpenguin
    @atelierpenguin День тому

    I can't remember any more

  • @kjyu4539
    @kjyu4539 2 місяці тому +1

    good video 🙏

  • @DemPilafian
    @DemPilafian 2 місяці тому +2

    1997 sounds dreamy. Having no HTTP Status Codes would eliminate countless hours of pointless navel-gazing debate. It's funny (in a tragic way) how StackOverflow questions about HTTP Status Codes often have multiple directly conflicting incompatible answers each with hundreds of upvotes. Whatever your interpretation of HTTP Status Codes is, it's wrong.

    • @username7763
      @username7763 Місяць тому

      HTTP status codes are important in many scenarios. For example, cases where you browser will prompt you for credentials. Or for cache validation responses or redirects. If you send the wrong response code, the browser will not handle it properly. Yeah there are cases where it isn't clear or meaningful on which should be used when but that doesn't mean they aren't valuable.

    • @DemPilafian
      @DemPilafian Місяць тому +1

      @@username7763 1) You're talking about errors closer to the "protocol" level, and HTTP Status Codes at that level make sense especially when you consider that the "P" in HTTP stands for "Protocol".
      2) The problem with HTTP Status Codes is when it comes to "application" level errors. The 400 Bad Request code gets argued over ad nauseam. It's so tiresome watching other developers fight over this topic.

    • @araz911
      @araz911 Місяць тому

      ​@@DemPilafianbro "кто на работу ... ложил, тот до пенсии дожил"

    • @bltzcstrnx
      @bltzcstrnx Місяць тому

      @@DemPilafian HTTP status code is necessary. How do you know the request is OK before parsing the payload without it? Many HTTP clients check the status code even before touching any of its contents. This is especially true for many REST clients. These clients only proceed if the status code met their expectations. People can debate all they want, it doesn't reduce the importance of HTTP status codes.

    • @DemPilafian
      @DemPilafian Місяць тому

      @@bltzcstrnx That's like saying if you don't like Microsoft you obviously despise computers and want to go back to stone tablets.

  • @dmaraptor
    @dmaraptor Місяць тому

    QUICK ist not a protocol or something brand new or invention. It just reliy on good networks. Old good UDP did it decades ago. If network is bad QUICK sucks.

  • @alexander13094
    @alexander13094 Місяць тому

    Use SCTP? Will develop own protocol!

    • @maighstir3003
      @maighstir3003 Місяць тому

      Status Code Transfer Protocol?

    • @alexander13094
      @alexander13094 Місяць тому

      @@maighstir3003 "The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.
      SCTP is standardized by the Internet Engineering Task Force (IETF) in RFC 9260. The SCTP reference implementation was released as part of FreeBSD version 7, and has since been widely ported to other platforms." Wikipedia

    • @alexander13094
      @alexander13094 Місяць тому

      @@maighstir3003 Stream Control Transmission Protocol RFC 9260

  • @ForsterHedy-y9j
    @ForsterHedy-y9j Місяць тому

    Dejon Shores

  • @hasanshanto2644
    @hasanshanto2644 22 дні тому

    you're the best

  • @KundanKumar-v8k
    @KundanKumar-v8k 2 місяці тому +2

    Present sir

  • @anna-plink
    @anna-plink 2 місяці тому

    Currently it's not possible to use QUIC protocol for a next.js project, right? 🤔

  • @crackwitz
    @crackwitz 2 місяці тому +1

    I like the graphics.
    Please work on the enunciation. "Unlike" needs K, "side" needs D, "assets" needs T, "lets" needs T,... Those issues made the video hard to follow purely by acoustics, not content.

  • @elliotphoenix
    @elliotphoenix 2 місяці тому

    Why the intro feels like AI generated

  • @CharlesWatson-q9c
    @CharlesWatson-q9c Місяць тому

    Adams Crossroad

  • @SharonThompson-z3r
    @SharonThompson-z3r Місяць тому

    Weimann Locks

  • @ramanbull
    @ramanbull 2 місяці тому

    guys !!!! How did u make this vedio?

  • @brianquigley1940
    @brianquigley1940 2 місяці тому +1

    👍 👍 👍 👍

  • @johnp.johnson1541
    @johnp.johnson1541 Місяць тому +1

    HTTP/3 IDs = easier tracking.

    • @joergsonnenberger6836
      @joergsonnenberger6836 Місяць тому +1

      Remember, HTTP/2 and HTTP/3 were pushed primarily by the ad industry.

  • @rishiraj2548
    @rishiraj2548 2 місяці тому +2

    🙂👍🏻

  • @Ribulose15diphosphat
    @Ribulose15diphosphat 2 місяці тому

    A General Design Flaw of the Internet is that there is no secure Packet handling. You either have insecure Packets (UDP) or Secure Streams (TCP).
    In Many Situations, you want Packets, that are resend over a statefull connection, but tolerate a random order.

    • @PeterVerhas
      @PeterVerhas 2 місяці тому

      It is not a design flaw. Tolerating random orders but needing guaranteed delivery are contradicting. In other words, it is not a precise requirement. How long can the app wait for a package to arrive and process other packages sent later? How can it signal that a package has not arrived if it is not a stream?
      If you have some specially tuned needs between the TCP-implemented stream and the UDP-implemented package, then you need a particular application-level protocol implemented using UDP. That is exactly HTTP/3.

  • @cengizbalta6371
    @cengizbalta6371 20 днів тому

    cure

  • @niladrikar4771
    @niladrikar4771 2 місяці тому

    liked it

  • @AncapDude
    @AncapDude 2 місяці тому +4

    Still use 1.1 on all my servers as on 2.0 many websites and applications don't work.

    • @gg-gn3re
      @gg-gn3re 2 місяці тому +2

      "many websites and applications don't work on 2.0" - you
      such as? lol http acts the same as 1.1 for 99% of things

    • @AncapDude
      @AncapDude 2 місяці тому

      @@gg-gn3re It was as I said. On my last try the majority of sites were slower and some didn't work at all.

    • @gg-gn3re
      @gg-gn3re 2 місяці тому

      @@AncapDude such as?

    • @AncapDude
      @AncapDude 2 місяці тому

      @@gg-gn3re WordPress Sites, Shops, other PHP Web apps.

    • @PeterVerhas
      @PeterVerhas 2 місяці тому +3

      @@AncapDudeCris, you must revisit this. Http 2 is implemented by the browsers for years and cluent code does not change at all, 100% backward compatible. So if you are worried about that the clients will not work: don’t. Also, the server will revert back to the old version when the client cannot handle higher than 1.1
      As on the server side: you just have to install the new version of the server, and your application will just work because the http api is the same on the server side as well.
      If your app does not sork on the new version of the server (nginx, Apache or some other server) it means they are very old, outdated and are probably missing also secirity patches.

  • @HeinKyawHlaing-ubesy
    @HeinKyawHlaing-ubesy 5 днів тому

    🙂🙂

  • @multipow
    @multipow 2 місяці тому +1

    @bytebytego I'm confused in few things.
    What is protocol? I mean was it algorithm and someone converted it into code or what it is?
    How it works under the hood

    • @EdwinMartin
      @EdwinMartin 2 місяці тому +1

      A protocol is a set of agreements. So if both the server and browser use these agreements, everything should work fine. It doesn’t say anything about how it should be implemented or which code to use. A protocol might refer to algorithms like BASE64, but how you implement this is up to the developer.

    • @PeterVerhas
      @PeterVerhas 2 місяці тому +1

      @@EdwinMartinAfter saying that, BASE64 is not an algorithm. It is a representation format, a kind of protocol per se, how to represent binary data using a limited character set. How my code works, what it does, converting binary data to a character array and back is the algorithm.

    • @SirusStarTV
      @SirusStarTV 2 місяці тому

      Talking about http protocol, it uses TCP network socket for data communication meaning the TCP guarantees the order of data packets sent.

    • @araz911
      @araz911 Місяць тому

      ​@@EdwinMartin is code a physical thing?

    • @vylbird8014
      @vylbird8014 Місяць тому +1

      It's not the algorithm itself. It's a description of procedure, just like in any formal process between two parties - what to say, when to say it, which documents to expect and when. The technical version of a business process. Except that computers are the most inflexible and stubborn of bureaucrats, so the protocol needs to define every last aspect in exacting and unambiguous detail.

  • @mensaswede4028
    @mensaswede4028 2 місяці тому +1

    HTTP feels like something that was designed as an undergraduate college project.

    • @bltzcstrnx
      @bltzcstrnx Місяць тому

      @@mensaswede4028 it's originally designed by a CERN engineer to facilitate sharing of research papers.

    • @mensaswede4028
      @mensaswede4028 Місяць тому

      @@bltzcstrnx I’m not surprised. Everything about it feels amateurish, like it definitely was not done by a professional software engineer for scalable production purposes.

    • @joergsonnenberger6836
      @joergsonnenberger6836 Місяць тому +2

      @@mensaswede4028 You sound very arrogant. Have you considered that Tim Berners-Lee had different requirements in 1990/1991 and scalability was not even a buzzword yet? If you want to compare it to the work of professional software engineers of the time, maybe take a look at CORBA, which was invented at about the same time. Frankly, I take the simplicity (and naivety) of HTTP/0.9 any day.

    • @mensaswede4028
      @mensaswede4028 Місяць тому

      @@joergsonnenberger6836 My point exactly. It’s a protocol that’s being used for a purpose for which it was never designed or intended.

    • @joergsonnenberger6836
      @joergsonnenberger6836 Місяць тому

      @@mensaswede4028 That doesn't make it a bad design. In fact, much of the complexity in modern versions are a direct result of badly designed systems. Open a random web page and you will see hundreds of requests to dozens of domains. Most of that can be avoided by a well designed web page. It's just that most people don't care. Ads are even worse. That's most of the justification for the complexity of HTTP/2. Now look at each request. How many cookies does a typical website need? All that junk is unnecessary in a well designed system, but that's not in the interest of Google. Instead we optimize the protocols to have somewhat more efficient encodings of junk.

  • @aakhthuu
    @aakhthuu 2 місяці тому

    HT3P

  • @bjornroesbeke
    @bjornroesbeke 2 місяці тому +7

    HTTP2 & 3 is like IPv6, i'll probably stick to the old versions for as long as possible.
    At least now i know what differences there are between them.

    • @EdwinMartin
      @EdwinMartin 2 місяці тому +3

      There’s really no reason to postpone using HTTP 2.0

    • @Acorn_Anomaly
      @Acorn_Anomaly 2 місяці тому +1

      I doubt support for at least 1.1 will ever go away.
      Honestly, if all you've got is a simple, static web page, HTTP 1.1 is all you need.
      The features available in 2.0+ are really more intended for sites that require a more active, constant connection.

    • @PeterVerhas
      @PeterVerhas 2 місяці тому +1

      You are using the new version without realizing it. The browsers support it without telling you. The servers need only version upgrades. The apps do not need to change. Programmers are using new versions without knowing it.

    • @VFPn96kQT
      @VFPn96kQT 2 місяці тому

      HTTP2 is already the most popular protocol for some time. The share of HTTP2 + HTTP3 is ~70% of internet traffic.

    • @SirusStarTV
      @SirusStarTV 2 місяці тому

      The thing i learned recently is that:
      We know that our devices connected to WIFI share the same external ip address but have local ip addresses, but i didn't know that we also share the same external ip address with other ISP customers, they do that because of limited number of IPs in ipv4. The technique is called *Carrier-grade NAT*

  • @maurpine
    @maurpine Місяць тому

    Edmundo Urrutia es un cobarde y un mentiroso.

  • @syntaxerorr
    @syntaxerorr Місяць тому

    No web dev thinks about http3. Its a NFT but for web!

  • @justinparrtech
    @justinparrtech Місяць тому

    The best thing about HTTP 2 and HTTP 3 is that we aren't using them.

  • @gus473
    @gus473 2 місяці тому +4

    C'mon, let's see Byte Byte Go get to 1 million subscribers! Getting closer! 😎✌️

    • @araz911
      @araz911 Місяць тому

      with such amount of misinformation less likely

  • @thegamezoneshow
    @thegamezoneshow 2 місяці тому

    ByteByteGo!!!