4 ms·

QUIC is HTTP 2 over UDP

27 points by johnhenry 10y ago

rijoja 10y ago
Sounds interesting but is it used anywhere?
- johnhenry 10y ago
  It's actually enabled in Chrome right now: https://en.wikipedia.org/wiki/QUIC#Client_.28browser.29_support https://en.wikipedia.org/wiki/QUIC#Client_.28browser.29_supp.... If you're using Chrome and you visit chrome://net-internals/#quic, you may notice that you're using it right now.
  - rijoja 10y ago
    Wow had no idea. But isn't TCP good enough? I guess I could google for a benchmark but I am to lazy. Because it's made for speed issues right?
    - johnhenry 10y ago
      I didn't know it was in active use either until I saw your question and decided to research, so thanks!. Why do we need cars? Isn't my horse good enough? :p It's simply a new, experimental technology that offers some benefits over an older one. Yes, speed is one of the benefits, but there are some other advantages listed here: https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp...
      - sigil 10y ago
        Thanks for the explainer. This stood out: > QUIC has implemented its own identifier for unique connections called the Connection UUID. It's possible to go from WiFi to LTE and still keep your Connection UUID, so no need to renegotiate the connection or TLS. Your previous connection is still valid. This sounds more viable than Multipath TCP.
        rijoja 10y ago
        Nice feature. Also not relying on the rightfully conservative TCP standard, they can iterate over new ideas. I thought the area should be thoroughly examined by now. But they have another good idea: Forward error correction. This is essentially RAID 5 on the network level. This introduces an overhead of 10 % so one in tenth packages might be lost. However this saves us from a costly roundtrip. My knowledge of networking is a bit rusty but this is not implemented in TCP I suppose. Anybody got any idea of when support for this will arrive to more mainstream servers. Such as apache?
  - saurik 10y ago
    Huh; for whatever reason, I have "QUIC Enabled: false" (Chrome 55.0.2883.95 64-bit on Mac OS X 10.12.1).
Matthias247 10y ago
QUIC is certainly interesting, but I can not agree with the headline. IMHO HTTP over QUIC needs a very different implementation than HTTP/2 over TCP/SSL. The majority of frame types and frame handling mechanisms are no longer needed and even if they are, they will be used in other ways. That's similar to the situation that HTTP/2 is not simply HTTP/1.1 over a multiplexing layer that gets introduced on top of TCP but also a completely different thing, as the multiplexing layer and the HTTP related mechanisms (header transmission, compression, etc.) are tightly interacting there. My current estimation is that webservers would need to have 3 completely different implementations of the HTTP stack (for HTTP/1.1, HTTP/2 and HTTP/QUIC), where only the most upper layer (interfaces for sending requests and respones) can be shared, the remaining stuff will be very different.

27 points by johnhenry 10y ago

rijoja 10y ago

Sounds interesting but is it used anywhere?

johnhenry 10y ago
It's actually enabled in Chrome right now: https://en.wikipedia.org/wiki/QUIC#Client_.28browser.29_support https://en.wikipedia.org/wiki/QUIC#Client_.28browser.29_supp.... If you're using Chrome and you visit chrome://net-internals/#quic, you may notice that you're using it right now.
- rijoja 10y ago
  Wow had no idea. But isn't TCP good enough? I guess I could google for a benchmark but I am to lazy. Because it's made for speed issues right?
  - johnhenry 10y ago
    I didn't know it was in active use either until I saw your question and decided to research, so thanks!. Why do we need cars? Isn't my horse good enough? :p It's simply a new, experimental technology that offers some benefits over an older one. Yes, speed is one of the benefits, but there are some other advantages listed here: https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp...
    - sigil 10y ago
      Thanks for the explainer. This stood out: > QUIC has implemented its own identifier for unique connections called the Connection UUID. It's possible to go from WiFi to LTE and still keep your Connection UUID, so no need to renegotiate the connection or TLS. Your previous connection is still valid. This sounds more viable than Multipath TCP.
      - rijoja 10y ago
        Nice feature. Also not relying on the rightfully conservative TCP standard, they can iterate over new ideas. I thought the area should be thoroughly examined by now. But they have another good idea: Forward error correction. This is essentially RAID 5 on the network level. This introduces an overhead of 10 % so one in tenth packages might be lost. However this saves us from a costly roundtrip. My knowledge of networking is a bit rusty but this is not implemented in TCP I suppose. Anybody got any idea of when support for this will arrive to more mainstream servers. Such as apache?
- saurik 10y ago
  Huh; for whatever reason, I have "QUIC Enabled: false" (Chrome 55.0.2883.95 64-bit on Mac OS X 10.12.1).

Matthias247 10y ago

QUIC is certainly interesting, but I can not agree with the headline. IMHO HTTP over QUIC needs a very different implementation than HTTP/2 over TCP/SSL. The majority of frame types and frame handling mechanisms are no longer needed and even if they are, they will be used in other ways. That's similar to the situation that HTTP/2 is not simply HTTP/1.1 over a multiplexing layer that gets introduced on top of TCP but also a completely different thing, as the multiplexing layer and the HTTP related mechanisms (header transmission, compression, etc.) are tightly interacting there. My current estimation is that webservers would need to have 3 completely different implementations of the HTTP stack (for HTTP/1.1, HTTP/2 and HTTP/QUIC), where only the most upper layer (interfaces for sending requests and respones) can be shared, the remaining stuff will be very different.