From HTTP/1.1 to HTTP/2, the HTTP protocol has always used TCP as the transport protocol. However, in the latest HTTP/3, TCP has been abandoned, and instead, a reliable transport protocol called QUIC has been implemented at the application layer based on the UDP protocol.
Characteristics of TCP
Timeout Retransmission
The TCP protocol is a connection-oriented and reliable transport layer protocol. Its basic principle for ensuring reliable data transmission is to start a timer after sending data. If an ACK confirmation message for the sent data is not received within this time (confirmed by the acknowledgment number, which is the sequence number of the sent data + 1), the message will be retransmitted. If it continues to fail, after a certain number of attempts, it will give up and send a reset signal to restart the transmission.
1.To ensure reliable delivery of packets, the sender must keep the sent packets in a buffer;2.And start a timeout timer for each sent packet;3.If a response is received from the other party before the timer times out (which may be an acknowledgment for this packet or for subsequent packets), the buffer occupied by that packet is released;4.Otherwise, the packet is retransmitted until an acknowledgment is received or the number of retransmissions exceeds the maximum allowed.5. When the receiver receives a packet, it first performs a CRC check. If correct, it hands the data to the upper layer protocol and sends an acknowledgment packet to the sender, indicating that the data has been received. If the receiver also has data to send to the sender, the acknowledgment can be included in the data packet.
Sequential ReceptionEach TCP segment carries a sequence number, which corresponds to the position in the data byte stream (for example, the first byte has a sequence number of 1, and subsequent bytes increment accordingly). The receiver maintains the expected sequence number and only accepts data that matches the expected sequence number, concatenating the byte stream in order. The receiver informs the sender of the highest successfully received sequence number through an acknowledgment message (ACK), letting the sender know which data to send next.Key Assurance Mechanisms:1. Out-of-order buffering: When the receiver receives packets with non-continuous sequence numbers, it does not discard them directly but buffers them in the reception queue, waiting for the missing preceding packets to arrive before concatenating them in order.2. Retransmission Trigger: If the receiver has not received a packet with a certain sequence number for a long time (timeout), or has received packets with subsequent sequence numbers multiple times, it will send a duplicate ACK to remind the sender to retransmit the missing packet. When the sender receives three identical duplicate ACKs in a row, it can determine that the corresponding packet has been lost without waiting for a timeout, triggering a fast retransmission.3. Sliding Window Coordination: The receiver’s sliding window not only controls the size of the receive buffer but also informs the sender of the range of data that can be sent through the window size field, indirectly coordinating with the rhythm of sequential reception.4. Out-of-order buffering: When the receiver receives packets with non-continuous sequence numbers, it does not discard them directly but buffers them in the reception queue, waiting for the missing preceding packets to arrive before concatenating them in order.Flow Control
If the sender sends data too quickly, the receiver may not be able to keep up, leading to packet loss. To avoid packet loss, the sender’s sending speed must be controlled so that the receiver can keep up, which is the purpose of flow control.
Flow control is implemented by the sliding window protocol (Continuous ARQ protocol). The sliding window protocol ensures that packets are received without errors and in order, while also implementing flow control. The main method is that the ACK returned by the receiver will include the size of its receive window, and this size is used to control the sender’s data transmission.
Flow Control Inducing Deadlock
When the sender receives an acknowledgment with a window size of 0, it stops sending and waits for the next acknowledgment from the receiver. However, if the subsequent non-zero acknowledgment is lost during transmission, the sender will continue to wait, while the receiver thinks the sender has received that acknowledgment and waits for new data, leading to a deadlock. To avoid deadlock caused by flow control, TCP uses a persistent timer. Each time the sender receives a zero-window ACK, it starts this timer. When the time is up, it actively sends a message to inquire about the receiver’s window size. If the receiver still returns a zero window, the timer is reset to continue waiting; if the window is not zero, it indicates that the acknowledgment message was lost, at which point the sending window is reset and sending begins again, thus avoiding deadlock.
Congestion Control
Congestion control operates on the network, preventing too much data from being injected into the network to avoid excessive network load. Common methods include: slow start, congestion avoidance, fast retransmission, and fast recovery.
Slow Start Algorithm
The idea of the slow start algorithm is not to send a large amount of data at the beginning but to probe the level of network congestion, gradually increasing the size of the congestion window (cwnd). The time experienced in a transmission round is actually the round-trip time (RTT), and the congestion window (cwnd) doubles with each transmission round.
To prevent the cwnd from growing too large and causing network congestion, a slow start threshold (ssthresh) state variable must be set. The usage of ssthresh is as follows:
1. When cwnd < ssthresh, use the slow start algorithm
2. When cwnd = ssthresh, either the slow start or congestion avoidance algorithm can be used
3. When cwnd > ssthresh, switch to the congestion avoidance algorithm
Congestion Avoidance Algorithm
The congestion avoidance algorithm allows the congestion window to grow slowly, increasing the sender’s congestion window (cwnd) by 1 for each round-trip time (RTT) instead of doubling it. This way, the congestion window grows slowly in a linear manner.
Whether in the slow start phase or the congestion avoidance phase, as long as the sender determines that network congestion has occurred (not receiving acknowledgments on time, although not receiving acknowledgments may be due to other reasons such as packet loss, but since it cannot be determined, it is treated as congestion):
1. Set the slow start threshold (ssthresh) to half of the sending window size at the time of congestion (but not less than 2)
2. Reset the congestion window (cwnd) to 1 and execute the slow start algorithm
The purpose of this is to quickly reduce the number of packets sent into the network, allowing the congested router enough time to process the packets queued up.
1. Initialize the congestion window (cwnd) to 1 packet segment, and the initial value of the slow start threshold (ssthresh) to 16
2. Execute the slow start algorithm, exponentially increasing to the 4th round, at which point cwnd=16=ssthresh, switch to the congestion avoidance algorithm, and the congestion window grows linearly
3. Assume that when cwnd=24, a timeout (congestion) occurs, then the updated ssthresh=12, cwnd is reset to 1, and the slow start algorithm is executed
4. When cwnd=12=ssthresh, switch to the congestion avoidance algorithm
Fast Retransmission Algorithm
Fast retransmission requires the receiver to immediately send a duplicate acknowledgment upon receiving an out-of-order segment (to inform the sender as soon as possible that a segment has not reached the other party, which can improve network throughput by about 20%). The fast retransmission algorithm stipulates that as soon as the sender receives three duplicate acknowledgments in a row, it should immediately retransmit the segment that the other party has not received, without waiting for the set retransmission timer to expire.
Fast Recovery Algorithm
When the sender receives three duplicate acknowledgments in a row, it executes the “multiplicative decrease” algorithm, halving the ssthresh threshold (to prevent network congestion). However, it does not execute the slow start algorithm next (if network congestion occurs, it would not receive several duplicate acknowledgments, so the sender now believes that the network may not be congested).
TCP Has Head-of-Line Blocking Issues
The issue of TCP head-of-line blocking must be viewed from two perspectives: one ishead-of-line blocking of the sending window, and the other ishead-of-line blocking of the receiving window.
Head-of-Line Blocking of the Sending Window
Data sent by TCP must be acknowledged in order; only after all data has been acknowledged in order can the sending window slide forward. For example, in the diagram below, the sender has sent all the data within the sending window, and the available window size is 0, indicating that the available window is exhausted, and no further data can be sent until an ACK confirmation is received.
Then, when the sender receives the ACK confirmation for bytes 32 to 36, thesliding window moves right by 5 bytes because 5 bytes of data have been acknowledged, and then bytes 52 to 56 become available for sending.
However, if a certain data packet is lost or its corresponding ACK packet is lost in the network, it will prevent the sender from moving the sending window, and it will not be able to send new data. It can only time out and retransmit this data packet until the ACK for this retransmitted packet is received, at which point the sending window will move forward, allowing further sending. For example, in the diagram below, the client is the sender, and the server is the receiver.
The client sends data for bytes 5 to 9, but the ACK confirmation for byte 5 is lost in the network. Therefore, even if the client receives the ACK confirmation for bytes 6 to 9, the sending window will not move forward.
At this point, byte 5 is equivalent to the “head of the line” because the lack of the ACK confirmation for the “head of the line” prevents the sending window from moving forward, causing the sender to be unable to continue sending subsequent data, effectively pausing the sending action. This is the head-of-line blocking issue of the sending window.
Head-of-Line Blocking of the Receiving Window
The data received by the receiver must be within the range of the receiving window. If data exceeding the receiving window range is received, it will be discarded. For example, in the diagram below, if the receiving window range is 32 to 51 bytes, any data received above byte 52 will be discarded.
When the receiving window receives ordered data, it can slide forward, and the already received and acknowledged “ordered” data can be read by the application layer.
However,when the data received by the receiving window is not ordered, for example, if bytes 33 to 40 are received, since byte 32 has not been received, the receiving window cannot slide forward. Therefore, even if bytes 33 to 40 are received first, these data cannot be read by the application layer.Only when the sender retransmits byte 32 and it is received by the receiver will the receiving window slide forward, allowing the application layer to read bytes 32 to 40 from the kernel.
Head-of-Line Blocking in HTTP/2
HTTP/2 achieves concurrent transmission of HTTP by abstracting the concept of Streams, where a Stream represents requests and responses in HTTP/1.1. Frames from different Streams can be sent out of order (thus allowing concurrent transmission of different Streams), as each frame’s header carries Stream ID information, allowing the receiver to assemble HTTP messages in order based on Stream ID. However, frames within the same Stream must be strictly ordered.
However, multiple Stream requests in HTTP/2 are transmitted over a single TCP connection, which means that multiple Streams share the same TCP sliding window. Therefore, when data loss occurs, the sliding window cannot move forward, blocking all HTTP requests, which is a form of TCP head-of-line blocking.
HTTP/3 QUIC
QUIC Without Head-of-Line Blocking
QUIC also borrows the concept of Streams from HTTP/2, allowing multiple HTTP requests (Streams) to be sent concurrently over a single QUIC connection. However,QUIC assigns an independent sliding window to each Stream, which means that there are no dependencies between multiple Streams on a single connection; they each control their own sliding window independently..
If Stream 2 loses a UDP packet, it will only affect the processing of Stream 2 and will not impact other Streams.
Reducing Connection Establishment Latency
For HTTP/1 and HTTP/2 protocols, TCP and TLS are layered, belonging to the transport layer implemented in the kernel and the presentation layer implemented in the OpenSSL library, respectively. Therefore, they are difficult to merge, requiring multiple handshakes: first TCP handshake (1 RTT), then TLS handshake (2 RTT), resulting in a total of 3 RTT of latency before data can be transmitted. Even with session reuse, at least 2 RTT is still required, which increases data transmission latency to a certain extent.
RTT (Round-Trip Time): refers to the total time from when the sender starts sending data until the sender receives confirmation from the receiver (the receiver sends confirmation immediately after receiving the data, not including the data transmission time).
Steps for Establishing a Connection in HTTP/3:
1. First handshake: The client sends an Initial Packet to the server, which contains the following information:
— The IP address and port number of the target server
— The client’s Connection ID
— The client’s TLS certificate
After the server receives the Initial Packet, it sends a Response Packet containing the following information: — The server’s Connection ID
— The server’s TLS certificate
2. Second handshake: The client sends a 0-RTT Packet to the server, which contains the client’s request information. Since the client sends a 0-RTT packet, the server does not need to wait for the client to send request data during the second handshake. After the server receives the 0-RTT Packet, it sends a Handshake Packet containing the following information:
— The server’s Connection ID
— ACK confirming the client’s Connection ID
— Transmission parameters, such as initial congestion window size and maximum packet size, etc.
3. Connection establishment completed: After the client receives the Handshake Packet sent by the server, the connection is established, and the client can start sending request data.
When reconnecting, although HTTP/3 requires a QUIC protocol handshake before transmitting data, this handshake process only requires 1 RTT. The purpose of the handshake is to confirm both parties’ “Connection ID,” and connection migration is based on the Connection ID.
The QUIC protocol of HTTP/3 is not layered with TLS (since QUIC is also an application-layer protocol), so it cancombine the handshake processes of QUIC and TLS. QUIC internally contains TLS, and it carries the “records” from TLS, plus QUIC uses TLS 1.3, so it only requires 1 RTT to “simultaneously” complete connection establishment and key negotiation. Even during the second connection, application data packets can be sent along with QUIC handshake information (connection information + TLS information), achieving a 0-RTT effect.
0-RTT Replay Attack
What is a Replay Attack?
A replay attack refers to an attacker intercepting legitimate communication messages during transmission, saving them, and then replaying these messages at a later time to deceive or attack. Replay attacks are often used to bypass authentication or deceive the server into accepting malicious requests, leading to security issues.
To prevent replay attacks, common methods include addingtimestamps orrandom numbers as non-repetitive factors during communication, and uniquely identifying each communication message to ensure that each message can only be used once. Additionally, techniques such asdigital signatures can be used to verify and encrypt communication messages, ensuring data integrity and security.
How HTTP/3 Addresses 0-RTT Replay Attacks:
To address this issue, HTTP/3 adopts the mechanism of “0-RTT packets using 0-RTT keys,” meaning that the client and server use different keys for encryption and decryption during 0-RTT data transmission. The client uses the previous session key when sending 0-RTT packets, while the server will only use the newly generated key after verifying the validity of that key. This ensures the security of 0-RTT packets but also adds some complexity and latency. Therefore, when using 0-RTT technology, a balance between security and performance must be considered, and careful decisions should be made.