HTTP0.9

1. Http0.9 is a simple protocol with only a GET command, no header, and the target to GET HTML
2. The server closes the TCP connection after sending the packet

HTTP1.0

1. POST and HEAD commands have been added from a single GET request
2. Supports sending content in any format
3. Each communication must include a header (HTTP header) that describes some metadata
4. New features include Status Code, multi-character set support, multi-part Type, authorization, cache, and Content encoding

The disadvantage of HTTP1.0

1. The connection cannot be reused: each TCP connection can only send one request. When data is sent, the connection is closed. If additional resources are requested, a new connection must be created.
2. Head-of-line blocking: When a page requests a large number of resources, blocking causes the remaining resources to wait for other resources to complete the request when the maximum number of requests is reached.

HTTP1.1

1. Long Connection: HTTP1.1 added the Connection field to Keep the TCP Connection Alive by setting keep-alive. Avoid setting up and releasing TCP connections repeatedly each time the client and server request is made. Closure can tell the server to close the request by carrying Connection:false in the request header.
2. Pipelining: A TCP connection can send multiple requests at the same time, but the server must respond to each request in the same order.
3. Cache processing: HTTP 1.0 mainly used if-Modified-since and Expires in the header as the criteria for cache judgment. HTTP 1.1 introduced more cache control policies such as Entity Tag, If-unmodified-since, if-match, if-none-match, etc.
4. Added commands: PUT, PATCH, HEAD, OPTIONS, and DELETE.
5. Error notification: 24 error status response codes have been added to HTTP1.1.

The disadvantage of HTTP1.1

1. Bloated header: HTTP/1.1 can compress the request content, but the header cannot be compressed. HTTP/1 is used to carry too much content in the header, which increases the transmission cost to some extent.
2. Queue head blocking: Although TCP connections are allowed to be multiplexed, the same TCP connection must be pipelined to receive the response in the order in which it is sent. If the first request is time consuming, subsequent requests, even if the server has finished processing them, will wait for the previous request to finish processing before starting to return in order, and many requests will queue up.

Add: To prevent this problem, modern browsers open up to six connections for a single domain and send requests through each connection. It achieves some degree of parallelism, but each connection is still subject to queue head blocking. In addition, it is not an efficient use of limited equipment resources.

3. Inefficient TCP utilization :TCP as one of the most reliable protocols, its core is the congestion window.

   Transmission control protocol (TCP) is designed to be conservative in assumptions and to be fair to different traffic applications on the same network. Its congestion avoidance mechanism is designed to work even under the worst network conditions and to ensure relative fairness if there are conflicting requirements. That’s one of the reasons for its success.

   Congestion window refers to the TCP packet data that can be sent by the sender before the receiver confirms the packet. (If the congestion window is set to 1, the sender sends one packet and the receiver confirms the sent packet before sending the next one)

   Generally speaking, sending packets one at a time is not very inefficient. TCP has a concept called Slow Start that explores the appropriate size of the congestion window for the current connection. The slow start is designed to allow new connections to figure out what’s going on on the network and not clutter an already congested network. It allows the sender to send an additional unacknowledged packet for each confirmed reply received. This means that a new connection can send two packets after receiving one acknowledgement reply; After receiving two confirmations, you can send four; And so on. This geometric growth will soon reach the upper limit of the number of packets sent according to the protocol, and then the connection will enter the congestion avoidance stage. This mechanism needs several round trips to know the optimal congestion window size, but the time cost of several round trips cannot be ignored.

Modern operating systems generally take 4-10 packets as the initial congestion window size. If you set a packet to the lower limit of 1460 bytes (i.e., the maximum payload), you can only send 5840 bytes first (assuming a congestion window of 4) and then wait for an acknowledgement reply.

4. Limited priority setting: If the browser opens multiple sockets for a given domain (each of which suffers from header blocking) and starts requesting resources, the browser has a limited number of ways to specify priority: either initiate the request or not.

   However, some resources on a Web page are more important than others, which inevitably exacerbates the queuing effect of resources. This is because browsers delay requests for other resources in order to request higher-priority resources first.

   However, during the processing process, the browser does not initiate new resource requests, so the server cannot use this period of time to send resources with lower priorities, and the total page download time is prolonged. It can also be the case that a high-priority resource is discovered by the browser, but is placed behind a lower-priority resource that is being fetched, depending on how the browser handles it.

HTTP2.0

SPDY is on top of TCP. Compared to HTTP/1, HTTP/2 transmits data in binary format, which has a smaller transfer volume and load.

HTTP2.0 breaks through the performance limitations of HTTP1.1 and improves transport performance by adding a binary layered frame between the application and transport layers (a core part of http2’s multiplexing capabilities).

1. Multiplexing mechanism: binary frame layer mechanism is introduced to achieve multiplexing. The framing layer is a frame-based binary protocol. This facilitates machine parsing. Requests and responses are intertwined.) Multiplexing is a good solution to the problem of browsers limiting the number of requests to the same domain name, and also makes it easier to achieve full speed transmission, since every new TCP connection requires a slow speed increase.
2. Requests can be prioritized: HTTP2.0 allows each data stream to be prioritized and returned to the client, and streams can depend on other substreams. (The client’s framing layer marks the request priority on the segmentation block)
3. Header compression: Request header compression to increase transmission efficiency.
4. Server push: In addition to the response to the initial request, the server can push additional resources to the client without explicit request from the client.

Implementation of multiplexing mechanism:

All HTTP2.0 communication is in a TCP pipe, using a TCP long connection. Download the entire resources page, just a slow start, and avoid the race, the browser request, on every request of the frame layer division, will play on the same request segmentation block the same id number, and then through the protocol stack divided all the body sent to the server, and then through the server request frame layer according to the id number of the assembly, The frame splitting layer of the server will divide the response data according to the same response body, divide the id and reply to the client, and the client will assemble the response.

For frames in HTTP2, http1 is not frame-based, but text-delimited. Thus, there may be problems with http1 requests or responses:

1. Only one request or response can be processed at a time, and parsing cannot be stopped until it is complete.
2. There is no way to predict how many inner layers are required for parsing.

HTTP/1 request and response packets consist of the start line, head, and body, separated by newlines. HTTP/2 is designed to split request and response data into smaller frames, encoded in binary, and easily parsed.

Frame structure Summary All frames contain a 9 byte frame header + different body length. The structure of the body varies depending on the type of frame.

HTTP / 2 frame structure

HTTP3.0

Why should there be problems with HTTP3.0,HTTP/2 underlying TCP limitations:

HTTP/2 uses multiplexing. Generally, only one TCP connection needs to be used in the same domain name. However, when packet loss occurs in this connection (TCP does not prevent packet loss, but retransmits packets rapidly after packet loss), the entire TCP waits for retransmission, causing all subsequent data to be blocked. In the case of HTTP/1.1, multiple TCP connections can be enabled, and only one of them is affected. The remaining TCP connections can still transmit data.

Google developed an experimental network protocol called QUIC (short for fast UDP Internet Connection) based on UDP.

Advantage:

1. Cache the context of the current session: The next time the session is resumed, you only need to pass the previous cache to the server and verify that the cache is successful.

2. Multiplexing: QUIC is based on UDP, and there is no dependency between multiple streams on a connection. Even if packets are lost, only the lost packets need to be retransmitted, rather than the entire connection.

3. Better mobile performance: QUIC performs better on mobile than TCP because TCP identifies connections based on IP, whereas QUIC identifies links by ID. No matter how the network environment changes, as long as the ID is inconvenient, it can be quickly reconnected.

4. The root of encrypted authentication – armed to the teeth: THE TCP header is not encrypted or authenticated, and is easily tampered with, injected into, and eavesdropped on by intermediate network devices during transmission.

   QUIC: Except for a few packets, such as PUBLIC_RESET and CHLO, all packet headers are authenticated and the packet format is encrypted. Therefore, any changes to THE QUIC can be detected by the receiver in a timely manner, effectively reducing the security risk.

5. Forward Error correction mechanism: QUIC protocol has a very unique feature called Foward Error Connec (FEC). Each packet contains the data of other packets in addition to its own content, so a small number of lost packets can be directly assembled from the redundant data of other packets without retransmission. Forward error correction sacrifices the upper limit of the data that can be sent per packet, but the improvement is greater than the retransmission caused by packet loss, because retransmission takes more time (including the time spent confirming packet loss, requesting retransmission, waiting for new packets, etc.).

   For example, if I send a total of three packets, the protocol calculates the XOR value of the three packets and sends a separate check packet, so a total of four packets are sent. When non-checksum packet loss occurs, the contents of the lost packets can be calculated through the other three packets.

   Of course, this technique can only be used in the case of a missing packet. If multiple packets are missing, no error correction mechanism can be used, only retransmission can be used.

How to enable QUIC in Chrome:

• Enter Chrome ://flags/ in the address bar.

• Experimental QUIC Protocol: Change the Default to Enabled

Some of the content has not been written in detail, you can add in the comments section

Related recommendations:

HTTP/2 Basics tutorial

What are we talking about when we talk about HTTP queue header blocking?

Connection management for HTTP/1.x