Minor updates to HTTP3/QUIC

files/en-us/glossary/quic/index.md

@@ -8,27 +8,15 @@ tags:
   - Web Performance
 ---
 
-**Quick UDP Internet Connection**, or **QUIC**, is an experimental multiplexed transport protocol implemented on UDP. It was developed by Google as a way to experiment with ways to improve TCP and web application delivery.
+**Quick UDP Internet Connection**, or **QUIC**, is a multiplexed transport protocol implemented on UDP. It is used instead of {{Glossary("TCP")}} as the transport layer in HTTP/3.
 
-As TCP is built into the kernel of many operating systems being able to experiment with changes, test them and implement modifications is an extremely slow process. The creation of QUIC allows developers to conduct experiments and try new things faster.
+QUIC was designed to provide quicker setup and lower latency for HTTP connections. In particular:
 
-QUIC was designed to support the semantics of HTTP/2. It provides multiplexing, flow control, security and congestion control.
+- In TCP, the initial TCP handshake is optionally followed by a TLS handshake, which must complete before data can be transmitted. Since TLS is almost ubiquitous now, QUIC integrates the TLS handshake into the initial QUIC handshake, reducing the number of messages that must be exchanged during setup.
 
-Key features of QUIC include:
-
-- Reduction in connection establishment time.
-- Improved congestion control.
-- Multiplexing without head-of-line blocking.
-- Forward error correction.
-- Connection migration.
-
-There is limited browser and server support for QUIC today.
-
-### Resources
-
-- [Chromium Projects Documentation](https://www.chromium.org/quic/)
-- [IETF Draft](https://datatracker.ietf.org/doc/html/draft-tsvwg-quic-protocol-02)
+- HTTP/2 is a multiplexed protocol, allowing multiple simultaneous HTTP transactions. However, the transactions are multiplexed over a single TCP connection, meaning that packet loss and subsequent retransmissions at the TCP layer can block all transactions. QUIC avoids this by running over TCP and implementing packet loss detection and retransmission separately for each stream, meaning that packet loss only blocks the particular stream whose packets were lost.
 
 ## See also
 
-- [HTTP/2](/en-US/docs/Glossary/HTTP_2)
+- {{rfc("9000", "the QUIC specification")}}
+- {{rfc("9114", "the HTTP/3 specification")}}

files/en-us/web/http/basics_of_http/evolution_of_http/index.md

@@ -188,18 +188,16 @@ This rapid adoption was likely because HTTP/2 didn't require changes to websites
 
 ## Post-HTTP/2 evolution
 
-HTTP hasn't stopped evolving since the release of HTTP/2. Like with HTTP/1.x, HTTP's extensibility is still being used to add new features. Notably, we can cite new extensions of the HTTP protocol that appeared in 2016:
+HTTP's extensibility is still being used to add new features. Notably, we can cite new extensions of the HTTP protocol that appeared in 2016:
 
 - Support for {{HTTPHeader("Alt-Svc")}} allowed the dissociation of the identification and the location of a given resource. This meant a smarter {{Glossary("CDN")}} caching mechanism.
-- The introduction of {{HTTPHeader("Client-Hints")}} allowed the browser or client to proactively communicate information about its requirements and hardware constraints to the server.
+- The introduction of [client hints](/en-US/docs/Web/HTTP/Client_hints) allowed the browser or client to proactively communicate information about its requirements and hardware constraints to the server.
 - The introduction of security-related prefixes in the {{HTTPHeader("Cookie")}} header helped guarantee that secure cookies couldn't be altered.
 
-This evolution of HTTP has lead to the creation of many applications and has driven the adoption of the protocol. The environment in which HTTP is used today is quite different from that of the early 1990s. HTTP's original design proved to be scalable, allowing the web to evolve over a quarter of a century. By fixing flaws and retaining the flexibility and extensibility that made HTTP such a success, the adoption of HTTP/2 points to a bright future for the protocol.
-
 ## HTTP/3 - HTTP over QUIC
 
-{{SeeCompatTable}}
+The next major version of HTTP, HTTP/3 has the same semantics as earlier versions of HTTP but uses {{Glossary("QUIC")}} instead of {{Glossary("TCP")}} for the transport layer portion.
 
-The next major version of HTTP, HTTP/3, will use {{Glossary("QUIC")}} instead {{Glossary("TCP")}}/{{Glossary("TLS")}} for the transport layer portion.
+QUIC is designed to provide much lower latency for HTTP connections. Like HTTP/2, it is a multiplexed protocol, but HTTP/2 runs over a single TCP connection, so packet loss detection and retransmission handled at the TCP layer can block all streams. QUIC runs multiple streams over {{Glossary("UDP")}} and implements packet loss detection and retransmission independently for each stream, so that if an error occurs, only the stream with data in that packet is blocked.
 
-See {{bug(1158011)}} for implementation status in Firefox.
+HTTP/3 is defined in {{RFC("9114")}} and is supported by most major browsers including Chromium (and its variants such as Chrome and Edge) and Firefox.

files/en-us/web/http/client_hints/index.md

@@ -8,7 +8,9 @@ tags:
   - Performance
 ---
 
-**Client Hints** are a set of [HTTP request header](/en-US/docs/Web/HTTP/Headers) fields that a server can proactively request from a client to get information about the device, network, user, and user-agent-specific preferences.
+{{HTTPSidebar}}
+
+**Client hints** are a set of [HTTP request header](/en-US/docs/Web/HTTP/Headers) fields that a server can proactively request from a client to get information about the device, network, user, and user-agent-specific preferences.
 The server can determine which resources to send, based on the information that the client chooses to provide.
 
 The set of "hint" headers are listed in the topic [HTTP Headers](/en-US/docs/Web/HTTP/Headers#client_hints) and [summarized below](#hint_types).