1. 13
  1.  

  2. 5

    Can anybody provide in bullet-point form the advantages of QUIC over current mechanisms? HTTP/3?

    It feels like a massive change that benefits, say, GOOG and FB and AMZN but really doesn’t offer much to normal developers–other than making it harder for folks supporting specs.

    1. 20

      I don’t understand this meme. How does QUIC benefit “big players” more than it benefits anyone else?

      QUIC (HTTP/3 is basically just HTTP/2, but using QUIC as a transport instead of TCP) is basically an attempt to eliminate head-of-line-blocking problems that HTTP/2 and HTTP/1.1+pipelining have. That seems like it could help with any page that downloads a lot of resources, regardless of whether it’s being deployed on a massive server cluster or it’s just a server sitting under my desk.

      Other improvements that QUIC is supposed to make, like avoiding middleboxes that have messed with the unencrypted parts of TLS, and avoiding breaking the connection when the IP address of the client changes, and allowing the initial connection packet to also contain the GET request, seem even more agnostic to the size of the website. In fact, with the hypothetical server-under-my-desk, with its own high-latency residential connection, seems like it would benefit more from the 0RTT-init than a server in a data center with a fiber-optic connection.

      So, yeah… please, actually explain how QUIC benefits GOOG without necessarily benefiting anyone else the same way? Other than not being compatible with existing tooling, which is inevitable with any protocol change, and of course the problems that the article lists, how does it hurt people who just take nginx or IIS and drop it onto their server somewhere?


      Edit: I do find it annoying and disturbing that Google has so much power as a vendor. For example, I hate AMP. The problems AMP is intended to solve are real, but as a solution, it’s sick and wrong. I don’t get AMP vibes from QUIC, though; it’s just a multiplexed stream thingy with an emphasis on reducing latency.

      1. 6

        it’s just a multiplexed stream thingy with an emphasis on reducing latency

        It also solves roaming devices better than Mobile IP (or anything else on the market for IP based networks) ever did by decoupling sessions from IP addresses.

        1. 2

          I don’t think this complaint is entirely valid, but one can argue that small sites can compete with big sites by being faster, but now quic comes along and makes the big sites fast, erasing ones competitive advantage.

          I suppose the same was said when optimizing compilers arrived. The people who could write the tightest leanest code lost a lot of their edge.

          1. 1

            I though QUIC was originally an innovation in TLS handshakes. I feel like the idea has taken on a new shape over the pass couple of years: https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/

            Head-of-line blocking was added later, if you look through the originally spec designs it was a UDP based TLS handshake proposal – all this HTTP/3 hype stuff is new.

            1. 3

              Google QUIC became a full transport protocol early in its development. Regarding HoL, it was IETF that completely eliminated it since the HEADERS stream in Google QUIC was still serialised. HTTP/3 is an IETF innovation since Google QUIC used HTTP/2.