The http-over-QUIC experimental protocol will be renamed HTTP / 3 and is expected to be the third official version of the HTTP protocol, according to Internet Engineering Task Force (IETF) officials. This was prompted by this original suggestion from Mark Nottingham.
The next generation HTTP protocol will use QUIC instead of TCP. However, the loss of UDP packets on carrier networks may be difficult to solve for a while. We have a long way to go to play QUIC.
The QUIC working group in IETF is dedicated to creating the QUIC transport protocol. QUIC is TCP replacement done over UDP. Initially, QUIC was at first a Google effort, then more of an “HTTP / 2 encryption-UDP” protocol.
When the work in IETF began to standardize protocols, it was divided into two layers: the transport and HTTP sections. This transport protocol can also be used to transport other data than just HTTP or HTTP-like protocols explicitly. But the name is still QUIC.
People in the community have used informal names such as iQUIC and gQUIC to refer to these different versions of the protocol, to separate THE QUIC protocol from IETF and Google (which differ greatly in detail). The protocol that sends HTTP through iQUIC is called HQ (HTTP-over-QUIC) for a long time.
So what is a Quic?
Quic(QuickUDP Internet Connections) is a new transport method that reduces latency compared to TCP. On the surface, Quic is very similar to TCP+TLS+HTTP/2 implemented over UDP. Because TCP is implemented in the operating system kernel and middleware firmware, significant changes to TCP are nearly impossible. However, since Quic is built on top of UDP, it is not subject to such limitations.
QuicKey features over existing TCP+TLS+HTTP 2 include
· Greatly shorten the connection establishment time
· Improved congestion control
· Multiplexing of wireless head blocking
· Forward error correction
· Connection migration
Google wants Quic to slowly replace TCP and UDP as the new protocols for moving binary data around the Internet, and for good reason, as testing has proven Quic to be faster and more secure due to its default encryption implementation (currently). The http-over-QUIC protocol draft uses the newly released TLS 1.3 protocol.
On TCP and Quic
TCP was developed when we were still sending packets over the network, the loss of packets on the network was much greater, and computer systems had much longer to answer TCP messages. For example, the timeout time to connect to the host is still 20 seconds, even if the TCP handshake cannot be completed within only 5 seconds, it is unlikely to get an answer. These long delays are the reason why web applications sometimes stagnate. Although we’ve seen huge improvements in reliability and speed, we haven’t touched those delays since the protocol was invented in the ’70s.
Rather than eventually reducing these defaults, which do not change packets and are generally compatible with current TCP implementations, protocol developers are just starting to use UDP and then implementing their own TCP on top of it. The transition to IPv 6 is also an ideal time to update TCP to a version that fixes most of its problems, mainly timeouts, window sizes, and TCP slow starts. Some values can be adjusted in your operating system, but timeout is the most annoying one. If you close a TCP socket that hangs for 5 seconds, your operating system will remain open until the 20 seconds expire, consuming system resources.
Reference links:
Daniel. Haxx. Se/blog / 2018/1… HTTP/3
Medium.com/devgorilla/…
If you want to read more technical articles, please pay attention to netease yunxin blog.
Learn about netease Yunxin, a communication and video cloud service based on netease’s core architecture.
NeteaseYunXin is a PaaS service product combining 18 years of NETEASE’S IM and audio and video technologies. It is a communication and video cloud service based on netease’s core technology architecture, which is stable, easy to use and has comprehensive functions. It is committed to providing the world’s leading technical capabilities and scene-oriented solutions. By integrating the client SDK and OPEN API, developers can quickly realize functions including IM, audio and video calls, live broadcast, on-demand, interactive whiteboard, and SMS.