Quickly understand the characteristics and differences of HTTP1.0 1.1 2.0 3.0

HTTP1.0

HTTP version 1.0 is a stateless, connectionless application layer protocol. HTTP 1.0 stipulates that the browser and server maintain a short-lived connection.

Each time the browser makes a request, it needs to establish a TCP connection with the server. The server disconnects the TCP connection immediately after processing (no connection). The server does not track each client order or record past requests (stateless).

This statelessness can be used with the help of cookie/session mechanism for identity authentication and status recording.

Problems with HTTP 1.0

Unable to reuse connection

Each time a request is sent, a TCP connection is required, and the TCP connection release process is relatively time-consuming. This connectionless feature will reduce the utilization rate of the network.

Head of line blocking

Since HTTP1.0 stipulates that the next request must be sent before the response to the previous request arrives, assuming that the response to the previous request has not arrived, the next request will not be sent and the subsequent requests will be blocked.

HTTP1.1

HTTP1.1 inherits the simplicity of HTTP1.0 and overcomes the performance problems of HTTP1.0.

Long Connection

HTTP1.1 adds the Connection field, which keeps the HTTP connection connected by setting Keep-Alive. This avoids the need to repeatedly establish and release a TCP connection between the client and the server for each request, thus improving network utilization.

If the client wants to close the HTTP connection, it can carry Connection:false in the request header to tell the server to close the request.

Pipelining — Awkward pseudo-parallelism

HTTP1.1 supports request pipelining.

Based on the long connection of HTTP1.1, request pipelining is possible, which enables requests to be transmitted in parallel.

For example:

If the body of the response is an HTML page that contains many imgs, keep-alive is very useful. It can send multiple requests "in parallel". (Note that "in parallel" here does not mean parallel transmission in the true sense)

It should be noted that the server must return the corresponding results in the order of the client's requests to ensure that the client can distinguish the response content of each request.

In other words, HTTP pipelining allows us to migrate the first-in-first-out queue from the client (request queue) to the server (response queue).

If the client sends two requests at the same time to obtain HTML and CSS respectively, if the server's CSS resource is ready first, the server will send HTML first and then CSS. In other words, the CSS response resource will not be transmitted until the HTML response resource is completely transmitted. Two parallel responses are not allowed at the same time.

It can be seen that HTTP1.1 still cannot solve the problem of head of line blocking. At the same time, there are various problems with the "pipelining" technology, so many browsers either do not support it at all, or directly turn it off by default, and the conditions for turning it on are very harsh... and it seems that it is actually useless.

True parallel transmission — browser optimization strategy

HTTP1.1 supports pipelining, but the server must also send back responses one by one, which is a big flaw. In fact, browser manufacturers at this stage have adopted another approach, which allows us to open multiple TCP sessions. In other words, the parallelism we see in the above figure is actually HTTP requests and responses on different TCP connections. This is true parallelism!

Many people think that the number of connections is:

Actual situation (China):

Cache processing — strong cache, negotiation cache, heuristic cache (new)

In addition, HTTP1.1 also adds cache processing (strong cache and negotiated cache), new fields such as cache-control, support for breakpoint transmission, and an increase in the Host field (enabling a server to create multiple Web sites)

HTTP2.0

Binary framing

HTTP2.0 breaks through the performance limitations of HTTP1.1 and improves transmission performance by adding a binary layered frame between the application layer and the transport layer.

Multiplexing (link sharing) — true parallel transmission

• stream: A bidirectional flow of bytes over an established connection.
• Message: A complete series of data frames corresponding to a logical message.
• Frame: The smallest unit of HTTP2.0 communication. Each frame contains a header and at least identifies the current stream (stream_id).

All HTTP 2.0 communications are done over a TCP link, which can carry bidirectional data flows of any traffic.

Each data stream is sent in the form of a message, which consists of one or more frames. These frames can be sent out of order and then repackaged according to the stream identifier (Stream_id) in the header of each frame.

Multiplexing (connection sharing) may cause keywords to be blocked. In HTTP2.0, each data stream can set priority and dependency. High-priority data streams will be processed by the server first and returned to the client. Data streams can also depend on other sub-data streams.

It can be seen that HTTP2.0 realizes true parallel transmission, which can make any number of HTTP requests on one TCP. This powerful function is based on the feature of "two-level framing".

Header Compression

In HTTP 1.X, header metadata is sent as plain text, typically adding 500-8000 bytes of payload to each request.

For example, cookies. By default, the browser will attach the cookie to the header and send it to the server every time a request is made.

HTTP2.0 uses encoder to reduce the size of headers that need to be transmitted. Both communicating parties cache a header_files table, which not only avoids the transmission of duplicate headers, but also reduces the size that needs to be transmitted.

Efficient compression algorithms can greatly compress the header, reduce the number of packets sent, and thus reduce latency.

Server Push

In addition to the response to the initial request, the server can also push additional resources to the client without the client's explicit request.

HTTP3.0

Google developed a QUIC protocol based on the UDP protocol and used it on HTTP/3. The previous name of HTTP/3 was HTTP-over-QUIC.

The early QUIC protocol had two versions, IETF and Google, until it was confirmed and named HTTP 3.0

The QUIC working group of IETF created the QUIC transport protocol. QUIC is a protocol that uses UDP instead of TCP. Initially, Google started to support QUIC, and later QUIC was more commonly known as "HTTP/2-encrypted-over-UDP".

People in the community have been using informal names like iQUIC and gQUIC to refer to these different versions of the protocol to separate the QUIC protocol from the IETF and Google (because they differ so much in details). The protocol for sending HTTP over "iQUIC" was called "HQ" (HTTP-over-QUIC) for a long time.

On November 7, 2018, Dmitri from Litespeed announced that they and Facebook had successfully completed the first interoperation between two HTTP/3 implementations. Mike Bihop's subsequent presentation in the HTTPBIS session on the topic can be seen here. The session ended with a consensus that the new name is HTTP/3!

0-RTT — The biggest advantage of QUIC protocol over HTTP2.0

Cache the context of the current session. The next time you resume the session, you only need to pass the previous cache to the server. Once it is verified, it can be transmitted.

0-RTT connection establishment can be said to be the biggest performance advantage of QUIC compared to HTTP2.

What is 0-RTT connection?

• Transport layer 0-RTT can establish a connection
• Encryption layer 0-RTT can establish an encrypted connection

Multiplexing

QUIC is based on UDP. There is no dependency between multiple streams on a connection. Even if packets are lost, only the lost packets need to be resent without retransmitting the entire connection.

Better mobile performance

QUIC performs better than TCP on mobile devices because TCP identifies connections based on IP, while QUIC identifies connections by ID. No matter how the network environment changes, as long as the ID is inconvenient, you can quickly reconnect.

The root of encryption authentication — armed to the teeth

The TCP protocol header is not encrypted or authenticated, and can be easily tampered with, injected, and eavesdropped by intermediate network devices during transmission.

QUIC packets are armed to the teeth. Except for individual messages, such as PUBLIC_RESET and CHLO, all message headers are authenticated and message bodies are encrypted.

Therefore, as long as any changes are made to QUIC, the receiving end can detect them in time, effectively reducing security risks.

Forward Error Correction

The QUIC protocol has a very unique feature called Forward Error Correction (FEC). Each data packet includes the data of other data packets in addition to its own content. Therefore, a small amount of packet loss can be directly assembled through the redundant data of other packets without retransmission.

Forward error correction sacrifices the upper limit of the data that can be sent per data packet, but the improvement it brings is greater than the data retransmission caused by packet loss, because data retransmission will consume more time (including the time consumed in steps such as confirming packet loss, requesting retransmission, and waiting for new data packets).

For example:

• I sent a total of three packets. The protocol would calculate the XOR value of the three packets and send out a separate verification packet, which means a total of four packets were sent.
• When a non-verification packet is lost, the content of the lost data packet can be calculated from the other three packets.
• Of course, this technology can only be used when one packet is lost. If multiple packets are lost, the error correction mechanism cannot be used and only retransmission can be used.

Problem Summary

Are HTTP1.1 merge requests (such as CSSsprites) applicable to HTTP2.0?

no need.

In header compression technology, both the client and the server maintain two identical static dictionaries and dynamic dictionaries.

The static dictionary contains common header name and value combinations. The static dictionary can be used during the first request. Now the header fields can be abbreviated as the index of the corresponding field in the static dictionary.

The dynamic dictionary is related to the context of the connection. The dynamic dictionary maintained by each HTTP/2 connection is different. The dynamic dictionary can be continuously updated during the connection.

In other words, the key values ​​or fields of the original complete HTTP message header can now be converted into an index due to the existence of the dictionary, and then searched and restored at the corresponding end, which plays a compression role.

Therefore, the more requests and responses generated on the same link, the more complete the dynamic dictionary is accumulated, and the better the header compression effect is. Therefore, for HTTP/2 websites, the best practice is not to merge resources.

In addition, HTTP2.0 multiplexing allows requests to be transmitted in parallel, and one of the reasons why HTTP1.1 merges requests is to prevent blocking problems caused by too many HTTP requests. Now that HTTP2.0 can be transmitted in parallel, there is no need to merge requests.

Why HTTP 3.0: Problems caused by the limitations of HTTP/2's underlying TCP

Since HTTP/2 uses multiplexing, generally speaking, only one TCP link is needed for the same domain name. However, when packet loss occurs in this connection, the performance of HTTP/2 will be worse than that of HTTP/2.

The reason is: when packet loss occurs, the entire TCP starts waiting for retransmission, causing all subsequent data to be blocked.

However, for HTTP/1.1, multiple TCP connections can be opened. This situation will only affect one of the connections, and the remaining TCP links can still transmit data normally.

Because modifying the TCP protocol is an impossible task.

How to enable QUIC protocol in Chrome

MTF has enabled HTTP3.0 protocol on both resource servers and content distribution nodes. Based on the backward compatibility of user browsers, it is strongly recommended that you enable experimental QUICK protocol support in Chrome browser to experience the acceleration effect:

In the browser address bar: enter chrome://flags

Find Experimental QUIC protocol and change Default to Enabled

Summarize

HTTP 1.0

• Stateless, connectionless
• Short connection: Each time a request is sent, a TCP request must be re-established, that is, a three-way handshake, which wastes performance
• No host header field, that is, the host in the http request header,
• Breakpoint resuming is not allowed, and only part of the object cannot be transferred. The entire object must be transferred.

HTTP 1.1

• Long connection, pipeline, use connection:keep-alive to use long connection
• Request Pipelining
• Added cache handling (new fields such as cache-control)
• Add Host field to support breakpoint transmission, etc.
• Because long connections will put pressure on the server

HTTP 2.0

• Binary framing
• Header compression: Both parties maintain a header index table, so that there is no need to send values ​​directly, and the header size can be reduced by sending keys.
• Multiplexing (or connection sharing) uses multiple streams, each of which is transmitted in frames, so that one TCP connection can handle multiple HTTP requests.
• Server push

HTTP 3.0

• Based on Google's QUIC protocol, the quic protocol is implemented using udp
• Reduced the TCP three-way handshake time and the TLS handshake time
• Solved the problem in http 2.0 where the previous stream was lost and the next stream was blocked
• The retransmission strategy is optimized. The retransmission packet and the original packet have different numbers, which reduces the consumption of subsequent retransmission calculations.
• Connection migration no longer uses TCP quadruple to determine a connection, but uses a 64-bit random number to determine the connection
• More appropriate flow control

UDP-based implementation

0RTT connection

UDP-based multiplexing

Encrypted and authenticated messages

Forward Error Correction