Answer: All correct
HTTP1.0: Each network connection needs TCP, not so efficient
HTTP1.1: One network connection can have multi request/response in sequence
But sometime one request/response might take a long time, cause blocking the rest of request/response
HTTP2: Allow multi request/response in paralle
HTTP3: Based on HTTPS, use streaming, https://quicwg.org/
-
QUIC Protocol: HTTP/3 is based on the QUIC (Quick UDP Internet Connections) protocol. QUIC was initially developed by Google, and it's an experimental transport layer network protocol. It combines characteristics of the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). In essence, QUIC provides the reliability of TCP but with reduced latency, thanks to its use of UDP.
-
Reduced Latency: HTTP/3 addresses the "head-of-line blocking" problem that can occur in HTTP/2. In HTTP/2, a lost or delayed packet blocks all streams (even if data from the other streams has arrived), since all streams are multiplexed onto a single TCP connection. QUIC overcomes this by using separate streams that don't block each other, which is very beneficial for improving speed on noisy networks.
-
Built-In Encryption: Another major difference between HTTP/3 and its predecessors is that HTTP/3 includes encryption by default. The encryption is based on TLS 1.3. In HTTP/2 and HTTP/1.1, encryption was optional.
-
Improved Connection Establishment: In comparison to HTTP/1 and HTTP/2, HTTP/3 has a simplified process for setting up a connection. HTTP/3 needs fewer round trips between the client and server to establish a connection. This is because QUIC combines the initial connection and TLS handshake stages that are separate in HTTP/2, which leads to faster initial page load times.
-
Improved Handling of Packet Loss: QUIC handles packet loss better than TCP (used in HTTP/1 and HTTP/2). If a TCP packet is lost, the entire TCP stream is paused until that packet is retransmitted and received, which isn't the case with QUIC.