4 ms·

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.

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).

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).