"Almost RFC": What Happens to QUIC

A compact overview of the project’s progress – the latest news about the tests and the presented protocol implementations. We invite those interested in the topic under cat.

Project development

QUIC have been developing since 2013, and since March 2016, the IETF has also joined the process (Internet Engineering Task Force). At that time, in the protocol considered as TCP replacements, discovered a number of shortcomings: vulnerability to DDoS attacks, incompatibility with NAT, Anycast, ECMP; plus – potential difficulties for network administrators and monitoring.

To strengthen the weaknesses, QUIC began to be actively implemented and tested. Then this was done by large telecoms and IT companies that offered their own implementation protocol, and over the past year the share of its “users” of the total number of websites was almost doubled…

Who is testing

At the end of last year, the implementation of the module to support HTTP / 3 NGINX offered at Cloudflare. The company prepared it based on its library quichecomplying with the IETF QUIC specification, and notedthat acted without the participation of engineers and official support from NGINX.

Almost exactly six months later, NGINX announced the launch of its own experimental version of QUIC + HTTP / 3 and stressedthat this project is not related to what was presented earlier by Cloudflare. NGINX now supports a special wiki portal on this topic, where there is setup guides and link to test results various client and server implementations.

Mozilla also released a test build at the same time as Cloudflare. For Firefox, it was prepared based on neqo… Enough time has passed since the release, but still you can see the criticism its performance compared to the custom implementation of QUIC support for Chrome.

During the year, other versions were released – for example, Microsoft’s implementation based on msquic…

What now

Recently on the Chromium Blog announced that the company will extend automatic support from Google-QUIC to IETF-QUIC. This revision made it possible to improve the performance of the main services of the company – to reduce the latency for search and video rebuffering time by 2% and 9%, respectively, plus – to increase the bandwidth for mobile and desktop platforms.

The release caused a mixed reaction in the IT community. Some expressed against excessive centralization of the protocol development process, others – were not impressed “Insignificant” increase in productivity, others – expressed concern total QUIC complexity…

Fearsthat “TCP replacement will be expensive” in terms of load balancing has been heard before. But during the discussion of the project on HN, residents even remembered a thirty-year-old project called CORBA (Common Object Request Broker Architecture), pointing out that its excessive complexity was much more “exhaust” compared to current innovations and their shortcomings – for example, the unresolved instability of the protocol to amplified attacks…

This is not to say what was done without opinions in defense… But specialized publications nevertheless noted a weighty fact – technically, Safari supports appeared even earlier, with the introduction of the 14th version.

Nearest milestone

QUIC Working Group completes collecting feedback, discussion of various aspects work of the protocol and is preparing for the adoption of the corresponding standard. With what intensity and efficiency its further implementation will go – the next few months will show.

PS Additional reading in our hubblog: