Replacing TCP: QUIC is ready for deployment [but not ready to become RFC]
Representatives of the Internet Engineering Council (IETF) announced that the QUIC protocol for data transmission at the transport level is ready for large-scale tests. But due to a number of flaws, it cannot be represented as an RFC yet. Details - in our today's material.
/ Pixabay / www_slon_pics / PD
Work on the QUIC began by Google in 2013. It was tested in Chrome and Chromium browsers. Later, the technology began to support the company's websites, including YouTube. After a couple of years, the IT giant announced that the protocol was tested successfully and will be presented to the IETF.
')
The Internet Council began working on QUIC in March 2016. As representatives of the IETF noted , in the future, QUIC will have to replace TCP, since the latter has exhausted its capabilities in the conditions of modern networks (mostly mobile).
In the TCP protocol, the connection is determined by the IP addresses and ports of the server and client. If for some reason one of these parameters changes, you have to recreate the connection. This results in difficulties with the stability of communication in mobile networks. The user moves between different cell towers and constantly changes the IP address.
QUIC's work is based on the UDP protocol, which allows you to exchange data without checking the recipient's readiness to receive it. Unlike TCP, which uses the “triple handshake” principle, in QUIC, a handshake occurs in one step with an already familiar server and in two steps with a server with which the client has not previously worked. The second stage is needed to open a secure communication channel and exchange cryptographic keys. As a result, QUIC has a lower connection delay and transmission than TCP. When transmitting data to a large distance (for example, from one continent to another) via a mobile device, the difference in the speed of establishing a connection between TCP with TLS and QUIC can reach 300 ms.
QUIC no longer has a set of parameters related to the IP addresses and ports of the server and client. Instead, the protocol works with the connection identifier UUID. This allows you to switch between Wi-Fi and the mobile network, each time without re-creating the connection (the UUID is preserved). The mechanism of operation is similar to the Mosh utility, which saves sessions when switching between wireless networks. Information about it can be found in the official repository of the project .
QUIC additionally includes a data integrity monitoring method — forward error correction, or Forward Error Correction (FEC). Each packet that is transmitted through QUIC has information about the neighbors. Therefore, if it is lost, the contents of the package can be restored.
So far, technology has certain disadvantages. For example, vulnerability to DDoS attacks. According to information security specialists, popular kits for organizing DDoS attacks have built-in support for UDP, which is a big threat. For this reason, when implementing QUIC, it is important to make sure that the handshake mechanism works correctly - it should be optimized and implemented as close as possible to the hardware. Otherwise, those attacks that the kernel could deal with earlier would have to be handled by third-party solutions (for example, nginx).
/ Wikimedia / Sagor Kumar sr / CC
The second drawback is the incompatibility of the protocol with networks that use NAT, Anycast, or ECMP technologies. They work with TCP connections and will not be able to recognize and regulate QUIC traffic. This incompatibility reduces the possibilities for application.
Moreover, the QUIC test results showed that the protocol does not work as well on mobile devices as the creators of the technology promise. According to the experiments , as the network bandwidth and the amount of transmitted data increase, the page load time for TCP and QUIC is evened out. This is because QUIC works in user space , not kernel space.
Another disadvantage of QUIC is the difficulty in troubleshooting. The protocol encrypts not only the data, but also the packet header in which they are transmitted. This makes it difficult for system administrators to evaluate network performance and quickly troubleshoot problems.
Although QUIC is still an experimental technology, the number of sites supporting this protocol is growing - this is shown by the research organization W3Techs. Experts estimate that with the adoption of the standard, the protocol will be used more often - although it is not yet clear when exactly the IETF will present the final version of QUIC.
PS What else do we write in the corporate blog VAS Experts:
/ Pixabay / www_slon_pics / PD
Why did QUIC come about?
Work on the QUIC began by Google in 2013. It was tested in Chrome and Chromium browsers. Later, the technology began to support the company's websites, including YouTube. After a couple of years, the IT giant announced that the protocol was tested successfully and will be presented to the IETF.
')
The Internet Council began working on QUIC in March 2016. As representatives of the IETF noted , in the future, QUIC will have to replace TCP, since the latter has exhausted its capabilities in the conditions of modern networks (mostly mobile).
In the TCP protocol, the connection is determined by the IP addresses and ports of the server and client. If for some reason one of these parameters changes, you have to recreate the connection. This results in difficulties with the stability of communication in mobile networks. The user moves between different cell towers and constantly changes the IP address.
The task of QUIC is to make the process of switching between wireless networks (including Wi-Fi) more “smooth”. In addition, tests conducted by Google show a decrease in the number of rebuffering when watching videos on YouTube by 30%.
Features of the protocol
QUIC's work is based on the UDP protocol, which allows you to exchange data without checking the recipient's readiness to receive it. Unlike TCP, which uses the “triple handshake” principle, in QUIC, a handshake occurs in one step with an already familiar server and in two steps with a server with which the client has not previously worked. The second stage is needed to open a secure communication channel and exchange cryptographic keys. As a result, QUIC has a lower connection delay and transmission than TCP. When transmitting data to a large distance (for example, from one continent to another) via a mobile device, the difference in the speed of establishing a connection between TCP with TLS and QUIC can reach 300 ms.
QUIC no longer has a set of parameters related to the IP addresses and ports of the server and client. Instead, the protocol works with the connection identifier UUID. This allows you to switch between Wi-Fi and the mobile network, each time without re-creating the connection (the UUID is preserved). The mechanism of operation is similar to the Mosh utility, which saves sessions when switching between wireless networks. Information about it can be found in the official repository of the project .
QUIC additionally includes a data integrity monitoring method — forward error correction, or Forward Error Correction (FEC). Each packet that is transmitted through QUIC has information about the neighbors. Therefore, if it is lost, the contents of the package can be restored.
Criticism of technology
So far, technology has certain disadvantages. For example, vulnerability to DDoS attacks. According to information security specialists, popular kits for organizing DDoS attacks have built-in support for UDP, which is a big threat. For this reason, when implementing QUIC, it is important to make sure that the handshake mechanism works correctly - it should be optimized and implemented as close as possible to the hardware. Otherwise, those attacks that the kernel could deal with earlier would have to be handled by third-party solutions (for example, nginx).
/ Wikimedia / Sagor Kumar sr / CC
The second drawback is the incompatibility of the protocol with networks that use NAT, Anycast, or ECMP technologies. They work with TCP connections and will not be able to recognize and regulate QUIC traffic. This incompatibility reduces the possibilities for application.
Moreover, the QUIC test results showed that the protocol does not work as well on mobile devices as the creators of the technology promise. According to the experiments , as the network bandwidth and the amount of transmitted data increase, the page load time for TCP and QUIC is evened out. This is because QUIC works in user space , not kernel space.
Another disadvantage of QUIC is the difficulty in troubleshooting. The protocol encrypts not only the data, but also the packet header in which they are transmitted. This makes it difficult for system administrators to evaluate network performance and quickly troubleshoot problems.
Perspectives
Because of existing vulnerabilities, it may be difficult to protect a system designed on top of QUIC. To eliminate the shortcomings of the protocol, developers need data on its work in real conditions. For this, the IETF involves an IT company in testing.The protocol is already supported by large organizations. CDN-services - Cloudflare and Verizon Digital Media Services (VDMS) started working with QUIC. In Cloudflare, the QUIC connection function is in beta testing. The VDMS team has been working on the implementation of the protocol since 2016, and now all clients of the service can use QUIC. Versions of the QUIC protocol also test Apple, Pandora, Facebook. A full list of companies is available on GitHub .
Although QUIC is still an experimental technology, the number of sites supporting this protocol is growing - this is shown by the research organization W3Techs. Experts estimate that with the adoption of the standard, the protocol will be used more often - although it is not yet clear when exactly the IETF will present the final version of QUIC.
PS What else do we write in the corporate blog VAS Experts:
Source: https://habr.com/ru/post/429380/
All Articles