QUIC protocol received status of proposed standard

IETF Committee (Internet Engineering Task Force), developing protocols and Internet architecture, Completed Formation of RFC for QUIC protocol and published related specifications under Identifiers RFC 8999 (independent of the Protocol property), RFC 9000 (transport over UDP), RFC 9001 (TLS encryption QUIC communication channel) and RFC 9002 (overload control and detecting packet loss during data transmission).

RFC received the status of the “proposed standard”, after which work will begin to give the RFC status of the draft standard (DRAFT STANDARD), which actually mean full stabilization of the protocol and take into account all comments made. The HTTP / 3 protocol that determines the use of the QUIC protocol as a transport for HTTP / 2 while it is at the draft Specifications , but in the near future and it will be finally standardized in IETF.

Recall that the Protocol Quic (Quick UDP Internet Connections) C 2013 has been developing by Google as an alternative to TCP + TLS bond For Web, decisive with a lot of installation time and coordination of connections in TCP and eliminating the delay in loss of packets during data transfer. QUIC is an add-in over UDP protocol that supports multiplexing multiple connections and providing encryption methods equivalent to TLS / SSL. In the process of developing in IETF standard, changes have been made to the protocol, which led to the emergence of two parallel existing branches, one for HTTP / 3, and the second-supported Google (Chrome supports both options, and the Firefox version of the IETF).

Basic Features Quic:

  • High security similar to TLS (essentially QUIC provides the ability to use TLS over UDP);
  • Monitoring the integrity of the stream preventing packet loss;
  • Ability to instantly install the connection (0-RTT, about 75% of cases, data can be transmitted immediately after sending the connection installation package) and provide minimal delays between sending a request and receiving an answer (RTT, Round Trip Time);
  • Use when re-transmitting a package of another sequence number, which avoids ambiguity when determining the received packages and get rid of the timaouts;
  • loss of the package affects the delivery of only the associated stream and does not stop the delivery of the data in parallel transmitted through the current connection stream;
/Media reports.