Developers recently who are behind from the Google Chrome web browser, released the news of the addition of support for the HTTP / 3 protocol to the experimental builds of Chrome Canary, which implements a plugin to enable HTTP over QUIC.
The QUIC protocol itself was added to the browser five years ago and since then it has been used to optimize work with Google services. At the same time, the QUIC version of Google used in Chrome differed in some details from the version of the IETF specifications, but now the implementations are in sync.
Google Chrome Canary just became the first (available) browser to integrate (very) experimental #QUIC and HTTP / 3 support!
Add flags "–enable-quic –quic-version = h3-23" and you should see "http / 2 + quic / 99" show up in the devtools, which is actually http3 in disguise! pic.twitter.com/5Fhui46h3x
- Robin Marx (@programmingart) September 19, 2019
It is important to highlight that Google has developed QUIC (Quick UDP Internet Connections) since 2013 as an alternative to the TCP + TLS package for the Web, which solves problems with long configuration and negotiation times for TCP connections and eliminates delays in packet loss during data transfer.
QUIC is a complement to the UDP protocol that supports multiplexing of multiple connections and provides encryption methods equivalent to TLS / SSL.
The protocol in question is already built into Google's server infrastructure, is part of Chrome, is planned for inclusion in Firefox, and is actively used to serve customer requests on Google's servers.
Among the main characteristics of QUIC that stand out are:
- High security, similar to TLS (in fact, QUIC provides the ability to use TLS over UDP)
- Flow integrity control that prevents packet loss
- The ability to instantly establish a connection (0-RTT, in about 75% of cases, data can be transmitted immediately after sending the connection setup packet) and ensure minimal delays between sending a request and receiving a reply (RTT, Round Trip Time)
- Not using the same sequence number when retransmitting a packet, which avoids ambiguity in determining received packets and eliminates wait times
- Losing a packet affects the delivery of only the stream associated with it and does not stop the delivery of data in streams transmitted in parallel over the current connection
- Error correction tools that minimize delays due to retransmission of lost packets.
- The use of special packet-level error correction codes to reduce situations that require retransmission of lost packet data.
- The cryptographic limits of the blocks are aligned with the limits of the QUIC packets, reducing the effect of packet loss on the decoding of the content of the following packets
- No problems with blocking the TCP queue
- Support for connection identifier, which reduces the time to establish a reconnection for mobile clients
- Ability to connect advanced mechanisms to control connection overload
It is also highlighted that it makes use of the technique of predicting the bandwidth in each direction to ensure an optimal intensity of packet delivery, preventing it from reaching a state of congestion in which packet loss is observed;
As well as remarkable performance and performance gains over TCP. For video services like YouTube, QUIC showed a 30% reduction in re-buffering operations when watching videos.
The HTTP / 3 protocol standardizes the use of QUIC as a transport for HTTP / 2. To enable HTTP / 3 and the QUIC version of the 23 draft IETF specifications, Chrome must be run with the options "–enable-quic –quic-version = h3-23" and then when the quic test site opens .rocks: 4433 in network inspection mode in developer tools, HTTP / 3 activity will show as "http / 2 + quic / 99".
Compared to a packet lost by parallel HTTP connections only 1 of the many connections will be stopped, which means that QUIC can support out-of-order delivery so that a lost packet will have less impact.
Si you want to know more about it about this, you can consult the following link.