|
|
|
|
@ -0,0 +1,258 @@
|
|
|
|
|
\documentclass[runningheads]{llncs}
|
|
|
|
|
\usepackage[english]{babel}
|
|
|
|
|
\usepackage{graphicx}
|
|
|
|
|
\usepackage{subcaption}
|
|
|
|
|
\usepackage{float}
|
|
|
|
|
\setlength\intextsep{0mm}
|
|
|
|
|
% Used for displaying a sample figure. If possible, figure files should be included in EPS format.
|
|
|
|
|
% If you use the hyperref package, please uncomment the following line to display URLs in blue roman font according to Springer's eBook style:
|
|
|
|
|
\usepackage[pdfencoding=auto,psdextra,bookmarks=false]{hyperref}
|
|
|
|
|
\renewcommand\UrlFont{\color{blue}\rmfamily}
|
|
|
|
|
% pour que les liens avec le doi soient aussi colorés en bleu comme demandé
|
|
|
|
|
\hypersetup{colorlinks=true,urlcolor=blue}
|
|
|
|
|
% Macros custom
|
|
|
|
|
\newcommand\ProtocolElement[1]{\texttt{#1}}
|
|
|
|
|
|
|
|
|
|
\begin{document}
|
|
|
|
|
|
|
|
|
|
\title{QUIC overview}
|
|
|
|
|
\author{Flavien Haas \and Louis Royer \and Daniel Sanchez Pelegrin\and Maïmouna Diouf \and Carine Koumsaga}
|
|
|
|
|
\institute{UPSSITECH, Paul Sabatier University campus in Toulouse, France}
|
|
|
|
|
\authorrunning{F. Haas, L. Royer, D. Sanchez, M. Diouf, C. Koumsaga}
|
|
|
|
|
% First names are abbreviated in the running head. If there are more than two authors, 'et al.' is used.
|
|
|
|
|
\maketitle
|
|
|
|
|
|
|
|
|
|
\begin{abstract}
|
|
|
|
|
This paper explains the basic principle of QUIC protocol, located just above UDP, in its ways of standardization by the IETF. QUIC is going to be the transport protocol used in HTTP/3, this paper aims to describe how handshake and data transfer are orchestrated while comparing them to TCP HTTP/2. This approach allows explaining the need for QUIC and how it solves HTTP/2’s issues like the lack of early data management, TCP’s head-of-line blocking or higher number of RTT. Then, it shows an overview of QUIC’s next implementations with current research issues and a summary table of the comparison with TCP.
|
|
|
|
|
\keywords{OSI model \and Transport layer \and QUIC \and Internet Protocol}
|
|
|
|
|
\end{abstract}
|
|
|
|
|
|
|
|
|
|
\section{Introduction}
|
|
|
|
|
The beginning of the 21st century has been marked with the use of the internet. For communicating, we used in first telephonic lines that have been made only for voice, and therefore haven't been reliable for data. Transport protocols like TCP \cite{rfc0793} were created to assure that information will be delivered.
|
|
|
|
|
|
|
|
|
|
Many round trips are needed to verify that data are received correctly.
|
|
|
|
|
Now, the complexity of our usages makes the internet an expanding place. In times where connections multiply on a very large scale, these connections must be always faster; and protocol study is necessary to meet those requierements.
|
|
|
|
|
|
|
|
|
|
QUIC is a new transport protocol developed by many companies. It aims to improve the internet efficiency.
|
|
|
|
|
For instance, Google and IETF are the main contributors in this project. Google has developed gQUIC, its own version of the protocol and uses it for its own services.
|
|
|
|
|
On the other hand, IETF's goal is to standardize the protocol to be used worldwide.
|
|
|
|
|
|
|
|
|
|
QUIC introduces HTTP/3 \cite{I-D.ietf-quic-http}.
|
|
|
|
|
The goal is to solve problems related to HTTP/2 linked to the use of TCP: like minimizing the latency of the handshake, introducing early data and prevent TCP’s head-of-line blocking \cite{I-D.ietf-quic-qpack}.
|
|
|
|
|
In this document, we will discuss how IETF's QUIC solves these issues while explaining how it works.
|
|
|
|
|
|
|
|
|
|
The rest of the paper is organized as follows. Section~\ref{section:crypto-based-handshake} describes Crypto-based Handshake. Data transfer is presented in section~\ref{section:data-transfer}. Section~\ref{section:research-issues} presents research issues. Section~\ref{section:general-analysis} summarize differences between TCP and QUIC.
|
|
|
|
|
|
|
|
|
|
\section{Crypto-based Handshake}\label{section:crypto-based-handshake}
|
|
|
|
|
To minimize connection establishment latency, QUIC relies on a combined cryptographic and transport handshake. Each connection starts with a handshake phase in which one client and one server establish a shared secret \cite[section~5.3]{I-D.ietf-quic-transport}.
|
|
|
|
|
|
|
|
|
|
\subsection{Handshake}
|
|
|
|
|
TLS provides two handshake mode to QUIC \cite[section~2.1]{I-D.ietf-quic-tls}:
|
|
|
|
|
\begin{description}
|
|
|
|
|
\item [A full 1-RTT handshake]: client is able to send Application Data after one round trip and the server can immediately respond.
|
|
|
|
|
\item [A 0-RTT handshake]: client uses information previously learned about the server and then is able to send Application Data immediately, but server can accept or reject early data sent with this handshake mode \cite[section~17.2.3]{I-D.ietf-quic-transport} (see section~\ref{section:0-RTT}).
|
|
|
|
|
\end{description}
|
|
|
|
|
|
|
|
|
|
\begin{figure}[ht]
|
|
|
|
|
\centering
|
|
|
|
|
\begin{subfigure}[b]{0.49\linewidth}
|
|
|
|
|
\caption{0-RTT handshake \cite[Figure 4]{I-D.ietf-quic-transport}.}
|
|
|
|
|
\includegraphics[width=\linewidth]{images/0RTThandshake.pdf}
|
|
|
|
|
\label{fig:0RTThandshake}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.49\linewidth}
|
|
|
|
|
\caption{1-RTT handshake \cite[Figure 3]{I-D.ietf-quic-transport}.}
|
|
|
|
|
\includegraphics[width=\linewidth]{images/1RTThandshake.pdf}
|
|
|
|
|
\label{fig:1RTThandshake}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\caption{Comparison between 0-RTT and 1-RTT handshakes.}
|
|
|
|
|
\label{fig:Comparison-0RTThandshake-1RTThandshake}
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
Figure~\ref{fig:0RTThandshake} shows the QUIC handshake with 0-RTT.
|
|
|
|
|
Figure~\ref{fig:1RTThandshake} shows the QUIC handshake with 1-RTT.
|
|
|
|
|
|
|
|
|
|
\label{section:0-RTT}
|
|
|
|
|
0-RTT connection establishment which recently contacted servers allows the client to send application messages before receiving any messages from the server (early data, see \cite[section~17.2.3]{I-D.ietf-quic-transport}).
|
|
|
|
|
|
|
|
|
|
However, 0-RTT lacks certain key security guarantees. In particular, there is no protection against replay attacks in 0-RTT. To enable 0-RTT, QUIC uses connection IDs \cite[section~4.3]{I-D.ietf-quic-invariants} and also provides a way to terminate a connection no longer desired.
|
|
|
|
|
|
|
|
|
|
\subsection{CRYPTO typed frames}
|
|
|
|
|
To transmit the cryptographic handshake, QUIC relies on \ProtocolElement{CRYPTO} typed frames \cite[section~19.6]{I-D.ietf-quic-transport}.
|
|
|
|
|
Each \ProtocolElement{CRYPTO} frame consists in a contiguous block of handshake data and can be sent in all packet types with the exception of 0-RTT.
|
|
|
|
|
|
|
|
|
|
As stated in draft IETF QUIC transport \cite[section~19.6]{I-D.ietf-quic-transport} the \ProtocolElement{CRYPTO} frame contains 3~fields:
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item \ProtocolElement{Offset}: A variable-length integer specifying the byte offset in the stream for the data in this \ProtocolElement{CRYPTO} frame.
|
|
|
|
|
\item \ProtocolElement{Length}: A variable-length integer specifying the length of the \ProtocolElement{Crypto Data} field in this \ProtocolElement{CRYPTO} frame.
|
|
|
|
|
\item \ProtocolElement{Crypto Data}: The cryptographic message data.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
There is a separate flow of cryptographic handshake data in each encryption level. Each of these starts at an offset of 0. This implies that each encryption level is treated as a separate \ProtocolElement{CRYPTO} stream of data.
|
|
|
|
|
|
|
|
|
|
As opposite to TLS records used with TCP, in QUIC multiple \ProtocolElement{CRYPTO} frames may appear in the same QUIC packet as long as they are associated with the same encryption level \cite[section~4]{I-D.ietf-quic-tls}.
|
|
|
|
|
|
|
|
|
|
\subsection{Handshake TLS}
|
|
|
|
|
|
|
|
|
|
TLS is a protocol which permits to establish a secure channel between two communicating entities. It simply expected from the underlying transport a reliable, in-order data stream.
|
|
|
|
|
TLS function in a client-server mode. It can allow the following security objectives:
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item Authentication: The server has to authenticate; the client may not.
|
|
|
|
|
\item Confidentiality of exchanged data.
|
|
|
|
|
\item Integrity of exchanged data.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
As stated in \cite[section~3]{I-D.ietf-quic-tls}, QUIC provides the confidentiality and integrity of packets by using keys from TLS Handshake.
|
|
|
|
|
As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC’s responsibility to deliver it reliably. Each chunk of data that is produced by TLS is associated with the set of keys that TLS is currently using. If QUIC needs to retransmit that data, it must use the same keys even if TLS has already updated to newer keys \cite[section~4]{I-D.ietf-quic-tls}.
|
|
|
|
|
|
|
|
|
|
TLS Handshake and Alert messages are carried directly over the QUIC transport, which takes over the responsibilities of the TLS record layer, while TCP carries TLS record inside TCP packets payload: unlike TLS over TCP, QUIC applications which want to send data do not send it through TLS \ProtocolElement{application\_data} records \cite[section~3]{I-D.ietf-quic-tls}.
|
|
|
|
|
|
|
|
|
|
There are two main interactions between the TLS and QUIC components showed in figure~\ref{fig:QUIC-and-TLS-Interactions}:
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item The TLS component sends and receives messages via the QUIC component, with QUIC providing a reliable stream abstraction to TLS.
|
|
|
|
|
\item The TLS component provides a series of updates to the QUIC
|
|
|
|
|
component.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
\begin{figure}[H]
|
|
|
|
|
\centering
|
|
|
|
|
\caption{QUIC and TLS Interactions \cite[Figure~4]{I-D.ietf-quic-tls}.}
|
|
|
|
|
\includegraphics[width=0.6\linewidth]{images/QUIC-and-TLS-Interactions.pdf}
|
|
|
|
|
\label{fig:QUIC-and-TLS-Interactions}
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
As stated in \cite[section~4.8]{I-D.ietf-quic-tls}, in TLS over TCP, the HelloRetryRequest feature can be used to correct a client’s incorrect KeyShare extension as well as for a stateless round-trip check. From the perspective of QUIC, this just looks like additional messages carried in the Initial encryption level.
|
|
|
|
|
|
|
|
|
|
The inclusion of the QUIC transport parameters extension ensures that handshake and 1-RTT keys are not the same as those that might be produced by a server running TLS over TCP. To avoid the possibility of cross-protocol key synchronization, additional measures are provided to improve key separation \cite[section~9.5]{I-D.ietf-quic-tls}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Data transfer}\label{section:data-transfer}
|
|
|
|
|
In HTTP/2, TCP is used as the transport protocol. Because TCP is reliable and byte-ordered, when multiple streams are multiplexed within the same connection, head-of-line blocking can appear. Head-of-line blocking in TCP is a phenomenon that happens when all the streams of a connection have to wait for a packet of a single stream that is currently lost. This phenomenon occurs because streams are not independent of each other.
|
|
|
|
|
|
|
|
|
|
QUIC uses streams just as TCP but they are independent within the same connection. They are identified by a unique numerical value within the connection: the \ProtocolElement{STREAM ID}. This value is a 62-bit integer that can not be reused during the connection.
|
|
|
|
|
|
|
|
|
|
Within a QUIC connection, data is therefore sent in \ProtocolElement{STREAM} type frames.
|
|
|
|
|
This type of frame is composed of the \ProtocolElement{STREAM ID}, the length of the data sent, the offset within the stream and the data itself. Thanks to the offset, the receiver can reorder data if it does not arrive in order.
|
|
|
|
|
If a packet is lost and \ProtocolElement{STREAM} frames were sent within it, only the streams referred by the frames will only have to wait for retransmission. The other streams which are not involved will be able to continue receiving data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Loss Detection and Retransmission}
|
|
|
|
|
As TCP does, QUIC implements an acknowledgment-based loss detection with TCP's Fast Retransmit, Early Retransmit, FACK, SACK loss recovery, and RACK \cite[section~5.1]{I-D.ietf-quic-recovery} but offers more detailed feedback information for loss detection than TCP \cite[page~74]{innovating-transport-with-quic-Cui-2017}.
|
|
|
|
|
|
|
|
|
|
When a packet is received, once packet protection is removed and all the frames in it have been processed, the receiver has to send an acknowledgment to the sender containing the number of the packet received. By receiving it, the sender can know that the packet sent was successfully received and no retransmission is needed. A timer is settled by the sender when a packet is sent. It prevents the sender to wait for an acknowledgment that never arrives. If an arbitrary amount of time, declared during the handshake, expires, the sender will declare the packet as lost.
|
|
|
|
|
|
|
|
|
|
In QUIC \cite[section~2]{I-D.ietf-quic-recovery}, an ack-eliciting is a packet that needs to be acknowledged within the maximum delay established. A no ack-eliciting packet is a packet containing \ProtocolElement{ACK}, \ProtocolElement{PADDING} or \ProtocolElement{CONNECTION\_CLOSE} frames. This kind of packet does not need to be acknowledged within the maximum delay established. Therefore, the acknowledgment will be sent only if an ACK frame has to be sent for other reasons. For example, if an ack-eliciting packet arrives, the receiver can acknowledge the packet which just arrives and the non-ack-eliciting packet which arrived before.
|
|
|
|
|
|
|
|
|
|
Sending acknowledgments without control can increase the load between the sender and the receiver. The receiver has to balance its sendings. An acknowledgment of an ack-eliciting packet can be delayed as much as the maximum ACK delay time is not exceeded. In some cases, it will wait until more packets arrive to send a packet with more ACK frames rather than sending an acknowledgment every time an ack-eliciting packet arrives. However, an acknowledgment will have to be sent immediately in the following situations:
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item An ack-eliciting packet is received out of order.
|
|
|
|
|
\item A packet marked with the ECN-CE (Explicit Congestion Notification - Congestion Experienced, see section~\ref{section:congestion-control}) codepoint is received.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
An acknowledgment can only be carried in a packet using the same protection as the packet acknowledged. For example, an acknowledgment for an Application data packet will only be carried in an Application data packet and not in a Handshake packet.
|
|
|
|
|
|
|
|
|
|
An ack-eliciting packet will be determined as lost if:
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item The packet is unacknowledged and was sent before and acknowledged packet.
|
|
|
|
|
\item No acknowledgement for the packet has arrived in an arbitrary amount of time, maximum acknowledgement delay, that will be established by the endpoint.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
If a packet is determined as lost the packet itself is not retransmitted. The information will be retransmitted in a new packet with new frames and only if it is necessary: Data in STREAM frames will not have to be retransmitted if a \ProtocolElement{RESET STREAM} frame is received and data in \ProtocolElement{CRYPTO} frames will not have to be retransmitted if the keys of the encryption level are discarded for example.
|
|
|
|
|
|
|
|
|
|
\subsection{Congestion control} \label{section:congestion-control}
|
|
|
|
|
QUIC uses TCP’s NewReno \cite[section~6.3]{I-D.ietf-quic-recovery} for congestion control, but unlike TCP, the congestion window is specified in bytes rather than segments. The mechanisms used in TCP to solve congestion problems are therefore implemented in QUIC with a few improvements that should be noted.
|
|
|
|
|
|
|
|
|
|
Each QUIC connection begins with a slow start. During slow start, QUIC increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed; and in case of loss, the threshold is lowered to half of the last window and the slow start process is resumed. The slow start process ends once the value of the congestion window exceeds the defined threshold, and it switch to avoidance collision.
|
|
|
|
|
|
|
|
|
|
As in TCP, an additive increase multiplicative decrease (AIMD) is used in this phase. It consists of increasing the congestion window by 1 each time until the next loss. When a loss is detected, NewReno halves the congestion window and sets the slow start threshold to the new congestion window.
|
|
|
|
|
|
|
|
|
|
The recovery period is slightly different from the TCP recovery definition, which ends when the lost packet that caused the recovery is recognized. Because QUIC does not retransmit lost packets, the end of recovery is achieved when a new packet is sent.
|
|
|
|
|
The loss of some packets such as Handshake, 0-RTT, and 1-RTT is ignored when their protection keys are not available when they arrive.
|
|
|
|
|
|
|
|
|
|
When persistent congestion is established, the sender's congestion window must be reduced to the minimum congestion window, which is similar to the sender's response on a Retransmission Timeout (RTO) in TCP after Tail Loss Probes(TLP).
|
|
|
|
|
|
|
|
|
|
A sender can use the pipeACK method to determine if the congestion window is sufficiently utilized. This underutilization may be due to pacing, which can delay sending packets. However, as in TCP, a sender can implement alternate mechanisms to update its congestion after periods of under-utilization.
|
|
|
|
|
|
|
|
|
|
QUIC can also use Explicit Congestion Notification (ECN) to signal network congestion before packet loss occurs. ECN is an IP’s header field. It is only used if both endpoints and the nodes existing in the path can read and understand the ECN field. The use of ECN must be validated by the endpoints during connection establishment and when migrating to another path. This validation, when packets are sent to a host on a new path is done as follows:
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item Setting the ECT(0) code point in the IP header of the first outgoing packets.
|
|
|
|
|
\item The validation fails if all packets sent with the ECT(0) code point are lost.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
If a receiver receives a QUIC packet without an ECT or CE code point in the IP header it does not increase the number of ECNs.
|
|
|
|
|
The QUIC signals which control congestion are generic and are designed to support different algorithms. The use of NewReno is not mandatory as another congestion algorithm exists such as Cubic. Moreover, endpoints can use different algorithms between each other.
|
|
|
|
|
|
|
|
|
|
\section{Research issues}\label{section:research-issues}
|
|
|
|
|
Various implementations of IETF's QUIC are already available \cite{quic-wg.implementations}.
|
|
|
|
|
One of the first available implementations was picoQUIC. This project is a minimal implementation of QUIC aiming to provide feedback on the development of a QUIC standard in the IETF QUIC Working Group \cite{picoquic.impl}. It is actively tested against other implementations.
|
|
|
|
|
|
|
|
|
|
Another of the older QUIC implementations is ngtcp2, a community project developed in C. This project provides libraries for client and server roles, with samples of HTTP/3 client and server \cite{ngtcp2.impl}.
|
|
|
|
|
quant is a NetApp's implementation providing libraries for both client and server sides \cite{quant.impl}, but it does not implement HTTP/3.
|
|
|
|
|
|
|
|
|
|
Quiche is developed by Cloudflare. It provides a low-level API written in Rust for processing QUIC packets. It follows the latest version of QUIC's draft \cite{quiche.impl}. There is a patch for NGINX implementing Cloudflare's Quiche's server role with a Rust to C binding layer \cite{nginx.impl}.
|
|
|
|
|
|
|
|
|
|
Recently, HTTP/3 support has been integrated into Curl, although the support is still experimental and needs to be enabled at build time \cite{curl.http3.experimental}. There are two implementations avaible: one using ngtcp2 libraries and the other using quiche's \cite{curl.http3.installation}.
|
|
|
|
|
|
|
|
|
|
Neqo has been developed by Mozilla, it implements a client and a server written in Rust. This project aims to be integrated into Gecko and to provide QUIC support to Firefox in the future \cite{neqo.impl}.
|
|
|
|
|
|
|
|
|
|
There is also active related work \cite{quic-wg.related-activities} as multipath extension \cite{deconinck-quic-multipath-03}, HTTP over multicast quic \cite{pardue-quic-http-mcast-06}, ns-3 module \cite{1902.06121}, or wireshark integration \cite{quic-wg.tools}.
|
|
|
|
|
|
|
|
|
|
\section{General Analysis}\label{section:general-analysis}
|
|
|
|
|
|
|
|
|
|
Some criteria have been chosen to recapitulate in a summary table, Table~\ref{tab:comp_tcp_quic}, the differences between QUIC and TCP. These can be classified into two main categories: general and specified criteria related to data transfer and the handshake.
|
|
|
|
|
|
|
|
|
|
Firstly, the level of each protocol in the OSI model which marks the possibility of updates in case of a security issue or functionality lack. They help the reader to have a first impression of each protocol.
|
|
|
|
|
|
|
|
|
|
Secondly, specified criteria allow an understanding of how each protocol will work in a practical case. The way they manage congestion, handle loss detection and retransmission of packets during data transfer is mandatory for transport protocols to understand the main differences.
|
|
|
|
|
|
|
|
|
|
TCP and QUIC both use Header compression with HTTP to transmit data more efficiently, but HTTP/3 design does not allow the use of HPACK because it would induce Head-of-line blocking. QPACK reuses core concepts from HPACK, but is redesigned to allow correctness in the presence of out-of-order delivery, with flexibility for implementations to balance between resilience against head-of-line blocking and optimal compression ratio \cite[section~1]{I-D.ietf-quic-qpack}.
|
|
|
|
|
|
|
|
|
|
Being able to do independent streams allows early data transmission and to avoid Head-of-line blocking. The reduction of the RTT during the handshake is significant on networks with high latency and helps reduce the load on operator networks always overloaded.
|
|
|
|
|
\begin{table}[H]
|
|
|
|
|
\caption {Comparison between TCP and QUIC for sending a secure web page}
|
|
|
|
|
\centering
|
|
|
|
|
\begin{center}
|
|
|
|
|
\begin{tabular}{|p{4.2cm}|p{3.8cm}|p{3.8cm}|}
|
|
|
|
|
\hline
|
|
|
|
|
\hfil\textbf{Criteria} & \hfil\textbf{TCP (HTTP/2)} & \hfil\textbf{QUIC (HTTP/3)} \\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Layer (OSI model) & \hfil4 & \hfil4.5 \\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Ease of updates & \hfil hard (kernel space) & \hfil easy (user space) \\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Header compression & \hfil HPACK & \hfil QPACK \\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Congestion control algorithm & \multicolumn{2}{c|}{NewReno}\\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Loss detection &\multicolumn{2}{c|}{ using ACK packets and timer}\\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Retransmission packets & \hfil same as lost ones & new packet with same data \\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Independent streams & \hfil no & \hfil yes \\
|
|
|
|
|
\hline
|
|
|
|
|
\hfil Early data transmission & \hfil no & if hosts already know each other and are allowed to \\
|
|
|
|
|
\hline
|
|
|
|
|
|
|
|
|
|
\end{tabular}
|
|
|
|
|
\end{center}
|
|
|
|
|
\label{tab:comp_tcp_quic}
|
|
|
|
|
\end{table}
|
|
|
|
|
\section{Conclusion}\label{section:conclusion}
|
|
|
|
|
This paper showed an overview of the QUIC transport protocol.
|
|
|
|
|
|
|
|
|
|
The comparison between QUIC and TLS over TCP for a basic web page request showed that many round trips aren't needed to assure speed and security.
|
|
|
|
|
HTTP/3 is basically HTTP/2 using QUIC transport protocol, it reduces the number of round trips compared to HTTP over TLS/TCP.
|
|
|
|
|
|
|
|
|
|
The use of QUIC doesn't compromise on security (early data responses used in 0-RTT lacks certain key security guarantees).
|
|
|
|
|
|
|
|
|
|
The main functionalities of a connected transport protocol for assuring the delivery are designed using already existing algorithms and protocols from TCP.
|
|
|
|
|
|
|
|
|
|
QUIC strength is that it's based on UDP transport protocol and this gave freedom of design: one of QUIC's power is to reside in the user space so it is more able to change.
|
|
|
|
|
|
|
|
|
|
There is an active community around the development of different implementations as shown in section~\ref{section:research-issues}.
|
|
|
|
|
Network analysis tools like ns-3 or Wireshark are the firsts to get QUIC support as they're useful for development.
|
|
|
|
|
\newpage
|
|
|
|
|
\bibliography{biblio}
|
|
|
|
|
\bibliographystyle{splncs04}
|
|
|
|
|
|
|
|
|
|
\end{document}
|
