: Deciphering the third transport protocol's four RFCs is a task to rival the proverbial blind man trying to understand an elephant

While Larry was producing most of the content for the “Request/Reponse” chapter for the next edition of our book, I took the lead on writing a section on QUIC, since I have closely followed its development.

Our expectation is that the role of QUIC will be about as important as that of TCP in the coming years, which means it warrants more substantial coverage than we provided in the last edition. So I dug a bit deeper into the bits and bytes of QUIC than I have previously, with a goal of bringing the coverage up to par with our TCP coverage. In addition to reading through the RFCs, I found lots of good information in the original QUIC design spec as well as some conference publications on the design and evaluation of SPDY (predecessor of HTTP/2) and QUIC.

One rather trivial thing that makes it harder for me to get to grips with QUIC is the fact that its RFCs (four of them, spanning hundreds of pages) lack pictures of the packet headers. The rationale for this, I believe, is that QUIC makes extensive use of fields that are variable in length and frequently not aligned on 32-bit boundaries, which makes packet header pictures a bit complicated and less tidy.

  • tal@lemmy.todayEnglish
    7·
    7 hours ago

    QUIC works hand-in-hand with HTTP/3’s multiplexed connections, allowing multiple streams of data to reach all the endpoints independently, and hence independent of packet losses involving other streams. In contrast, HTTP/2, which is carried over TCP, can suffer head-of-line-blocking delays if multiple streams are multiplexed on a TCP connection and any of the TCP packets on that connection are delayed or lost.

    SCTP was going to do that too. It hasn’t seen much uptake.

    https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

    Features of SCTP include:

    • Delivery of chunks within independent streams eliminates unnecessary head-of-line blocking, as opposed to TCP byte-stream delivery.
    • who@feddit.orgEnglish
      4·
      3 hours ago

      SCTP was going to do that too. It hasn’t seen much uptake.

      SCTP has a major obstacle in that the internet is full of middleboxes that will never support it, because it’s not TCP or UDP. QUIC deliberately addresses that by being plain old UDP. Routers, firewalls, etc. don’t have to know anything about it in order to handle it.

    • kunaltyagi@programming.dev
      1·
      3 hours ago

      SCTP has 2 flaws:

      • Lack of a good incremental adoption given ASIC middlewares
      • Lack of real world data at scale (which QUIC had thanks to SPDY thanks to Google and Google Chrome)