The client is an Ubuntu 20.04 64-bit with the local IP 192.168.79.132 and the server is an Ubuntu Server 20.04 reachable over the IP 192.168.79.128. Both hosts are running as virtual machines (VM) in the same local network. Since curl also supports the current HTTP standard over TCP/TLS it can be used for direct comparison of the TCP/TLS and QUIC protocol stacks. The QUIC implementation by Cloudflare is based on the IETF QUIC and HTTP/3 drafts in revision 29. We have used the QUIC implementation quiche by Cloudflare which provides a patch for Nginx to support HTTP/3 and can be integrated into the curl web client tool. To test how QUIC traffic is working, a simple point-to-point topology was chosen with a local firewall on the server. Together with the FIN message from the client, the first application data can already be transmitted.
If the data provided by the server is trusted by the client and the validity of the FIN message is confirmed, the client also sends an encrypted FIN message finalizing the cryptographic handshake.
Furthermore, the server certificate, the signature and a hashed transcript of the setup so far, called the Finished Message ( FIN), are transmitted in the same message but already encrypted. On receiving the CH, the server answers with a Server Hello (SH) containing the chosen cipher suite and the key share for the server-side in plain text. The choice of algorithm could be preset or based on a guess performed in the client implementation. After the stream is set up, the client sends a Client Hello (CH) message to the server along with the supported cipher suites and the necessary key information for one cipher suite ( key share) that is most likely supported by the server. The client starts initiating the TCP 3-way handshake with a server that is listening on a specific port. Since QUIC is directly built upon the encryption capabilities provided by TLS 1.3, this section introduces the basics of how the TLS handshake, shown in Figure 2, works. The original ISO/OSI network stack did not include a specific security layer but TLS is usually regarded as a separate layer. 1: Protocol stacks of HTTP/2 over TCP/TLS and HTTP/3 over QUIC based on and. At the time of writing, the Internet Engineering Task Force (IETF) standardizes QUIC and HTTP/3 which could lead to a change of the web’s core protocol from TCP to UDP in the near future. QUIC can further be configured to utilize the new TLS 1.3 0-RTT handshake for known endpoints, completely eliminating the RTTs for the connection setup. By combining these components, QUIC is able to eliminate the two additional RTTs introduced by TLS. It shows that QUIC combines the transport layer stream abstraction, the encryption handling and parts of the application layer into one layer. The differences between the HTTP/2 and HTTP/3 protocol are shown in Figure 1. The most prominent solution approach is the Quick UDP Internet Connection (QUIC), laying the foundation for the new HTTP/3 standard. The extra amount of RTTs became an issue for increasingly popular real-time applications in high latency networks.
0 kommentar(er)
