Add content for QUIC

content/concepts/transport.md

@@ -115,3 +115,102 @@ and some places in the codebase still use the "swarm" terminology.
 {{% /notice %}}
 
 [definition_switch]: /reference/glossary/#switch
+
+## QUIC
+
+QUIC is a new transport protocol that provides an always-encrypted, stream-multiplexed 
+connection built on top of UDP. It started as an experiment by Google on Google Chrome 
+in 2014, and was later standardized by the IETF in 
+[RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000).
+
+### Key challenges with TCP
+
+1. Head-of-line blocking (HoL blocking): TCP is a single byte stream exposed by the kernel, 
+   so streams layered on top of TCP experience head-of-line (HoL) blocking.
+
+   {{% notice "info" %}}
+   In TCP, head-of-line blocking occurs when a single packet is lost, and packets delivered 
+   after that need to wait in the kernel buffer until a retransmission for the lost packet 
+   is received.
+   {{% /notice %}}
+
+2. Ossification: Because the header of TCP packet is unencrypted, middleboxes can inspect and modify
+   TCP header fields and may break unexpectedly when they encounter anything they don’t understand.
+   This makes it practically impossible to deploy any changes to the TCP protocol that change the 
+   wire format.
+
+3. Handshake inefficiency: the 3-way handshake is inefficient, as it spends 1-RTT on verifying 
+   the client’s address.
+
+QUIC was designed with the following goals in mind:
+
+- Streams at the transport layer, thereby overcoming HoL blocking
+- Reducing the latency of connection establishment to a single RTT for new connections, and to 
+  allow sending of 0-RTT application data for resumed connections
+- Encrypting as much as possible. This eliminates the ossification risk, as middleboxes aren't 
+  able to read any encrypted fields, and allows future evolution of the protocol
+
+### Comparing HTTP/2 and HTTP/3
+
+The IETF introduced a new hypertext transfer protocol standard in late 2018, 
+which turned into a proposed standard for HTTP/3 in 
+[RFC 9114](https://datatracker.ietf.org/doc/html/rfc9114). HTTP/3 combines the advantages 
+of the existing transfer protocols HTTP/2 and HTTP over QUIC in one standard for faster and 
+more stable data transmission.
+
+The following diagram illustrates the OSI model for HTTP/2 and HTTP/3:
+
+![HTTP/2 & HTTP/3 OSI model](https://cloudspoint.xyz/wp-content/uploads/2022/03/http3.png)
+
+A web browser connection typically entails the following **(TCP+TLS+HTTP/2)**:
+
+1. Transport layer: TCP runs on top of the IP layer to provide a reliable 
+   byte stream.
+   - TCP provides a reliable, bidirectional connection between two end systems.
+2. Security layer: A TLS handshake runs on top of TCP to
+   establish an encrypted and authenticated connection.
+   - Standard TLS over TCP requires 3-RTT. A typical TLS 1.3 handshake takes 1-RTT.
+3. Application layer: HTTP runs on a secure transport connection to transfer 
+   information and applies a stream muxer to serve multiple requests.
+   - Application data starts to flow.
+
+In contrast, HTTP/3 runs over [QUIC](##what-is-quic), where QUIC is similar to 
+TCP+TLS+HTTP/2 and runs over UDP. Building on UDP allows HTTP/3 to bypass the challenges 
+found in TCP and use all the advantages of HTTP/2 and HTTP over QUIC.
+
+### What is QUIC?
+
+QUIC combines the functionality of these layers. It sends UDP packets and therefore
+it is responsible for loss detection and repair itself. By using encryption, 
+QUIC avoids ossified middleboxes. The TLS 1.3 handshake is performed in the first flight, 
+removing the 1-RTT cost of verifying the client’s address. QUIC also exposes multiple 
+streams, so no stream multiplexer is needed at the application layer. Part of the application 
+layer is also built directly into QUIC; when you run HTTP on top of QUIC; only a small shim 
+layer exists that maps 
+[HTTP semantics](https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html) 
+onto QUIC streams.
+
+QUIC supports the resumption of connections (0-RTT connections), allowing a 
+client to send application data right away, even before the QUIC handshake has finished.
+
+<!-- to add diagram -->
+
+### QUIC in libp2p
+
+libp2p only supports bidirectional streams and uses TLS 1.3 by default. 
+libp2p directly uses QUIC streams, without any additional framing.
+
+To authenticate each others' peer IDs, peers encode their peer ID into a self-signed certificate,
+which they sign using their host's private key. This is the same way peer IDs are authenticated in
+the [libp2p TLS handshake](https://github.com/libp2p/specs/blob/master/tls/tls.md).
+
+{{% notice "note" %}}
+
+To be clear, there is no additional security handshake and stream muxer needed as QUIC 
+provides all of this by default. This also means that establishing a libp2p connection between
+two nodes using QUIC only takes a single RTT.
+
+{{% /notice %}}
+
+Following the multiaddress format described earlier, a standard QUIC connection will
+look like: `/ip4/127.0.0.1/udp/65432/quic/`.