Click “like” to see, form a habit, the public account search [dime technology] pay attention to more original technical articles. This article has been included in GitHub org_Hejianhui /JavaStudy.
HTTP1.0
HTTP version 1.0 is a stateless, connectionless application-layer protocol. HTTP1.0 specifies that browsers and servers maintain ephemeral links.
The browser establishes a TCP connection with the server for each request. The server disconnects the TCP connection immediately after processing the request (no connection). The server does not track each client order or record past requests (stateless).
This statelessness can be achieved through the cookie/session mechanism for identity authentication and state logging.
Problems with HTTP1.0
Unable to reuse connection
Each time a request is sent, a TCP connection needs to be made, and the TCP connection release process is time-consuming. This connectionless nature leads to low network utilization.
Head of line blocking
Since HTTP1.0 specifies that the next request must be sent before the previous response arrives, assuming that the previous response never arrives, the next request is not sent and subsequent requests are blocked.
HTTP1.1
HTTP1.1 inherits the simplicity of HTTP1.0 and overcomes its performance problems.
A long connection
HTTP1.1 adds a Connection field to Keep HTTP connections stuck by setting keep-alive. Avoid setting up and releasing TCP connections repeatedly each time the client and server request is made. This improves network utilization.
If the client wants to close the HTTP Connection, it can tell the server to close the request by carrying Connection:false in the request header.
Pipelining — awkward pseudo-parallel transport
HTTP1.1 supports request pipelining.
Long connections based on HTTP1.1 make request pipelining possible. Pipelining enables requests to be transmitted “in parallel”.
Such as:
If the body of the response is an HTML page that contains many IMGs, keep-alive can be useful. Ability to send multiple requests “in parallel”. (Note that “parallel” is not really a parallel transport.)
Note that the server must send back the corresponding results in the order in which the client requests them, so that the client can distinguish the contents of each request.
In other words, HTTP pipelining allows us to move the FIFO queue from the client (request queue) to the server (response queue)
If the client sends two requests for HTML and CSS at the same time, if the server’s CSS resources are ready first, the server will send the HTML first, and then the CSS. In other words, CSS response resources are not transferred until the HTML response resources are fully transferred. Two parallel responses are not allowed.
As you can see, HTTP1.1 still does not solve the problem of head of line blocking. There are also various problems with pipelining, so many browsers either don’t support it at all, or turn it off by default, with strict conditions… And it doesn’t seem to be of any real use.
True parallel Transport – Browser optimization strategy
HTTP1.1 supports pipelining, but the server must also send back responses one by one, which is a major drawback. In fact, current browser vendors take a different approach and allow us to open multiple TCP sessions, which means that the parallelism we see above is actually HTTP requests and correspondence over different TCP connections. This is true parallelism!
What many people think of as connection counts:
Actual Situation (China) :
Cache processing – Strong cache, negotiated Cache, and heuristic Cache (new)
In addition, HTTP1.1 adds caching (strong caching and negotiated caching), new fields such as cache-Control, support for breakpoint transmission, and the Host field (which enables a server to create multiple Web sites)
HTTP2.0
Binary framing
HTTP2.0 improves transport performance by adding a binary layered frame between the application and transport layers.
Multiplexing (link sharing) – true parallel transport
- Stream: a bidirectional byte stream on an established connection.
- Message: A complete sequence of data frames corresponding to a logical message.
- Frame: The smallest unit of HTTP2.0 communication. Each frame contains a header that at least identifies the current stream (stream_id).
All HTTP2.0 communication is done over a TCP link that can hold two-way data streams of arbitrary traffic.
Each data stream is sent as a message, which consists of one or more frames. These frames can be sent out of order and then reencapsulated according to the stream identifier (Stream_id) in the header of each frame.
Multiplexing (connection sharing) can cause keywords to block. In HTTP2.0, each data stream can be prioritized and dependent. High-priority streams are processed by the server and returned to the client, and streams can depend on other substreams.
As you can see, HTTP2.0 implements true parallel transport, with the ability to make any number of HTTP requests over a SINGLE TCP. And this powerful function is based on the “secondary system frame” feature.
The head of compression
In HTTP1.x, header metadata is sent as plain text, typically adding 500-8000 bytes to the load per request.
Cookies, for example, are attached to the header by the browser and sent to the server on every request by default.
HTTP2.0 uses encoder to reduce the size of the headers that need to be transferred. The communication parties cache a header_files table to avoid duplicate header transfers and reduce the size of the headers that need to be transferred.
Efficient compression algorithms can greatly compress the header, reducing the number of packets sent and thus reducing latency.
Server push
In addition to the response to the initial request, the server can push additional resources to the client without the explicit need of the client.
HTTP3.0
Google developed a UDP-based QUIC protocol and used it over HTTP/3, formerly known as HTTP-over-quic.
The early Quic protocol existed in both IETF and Google versions until it was confirmed to be named HTTP3.0
The QUIC Working Group of the IETF created the QUIC transport protocol. QUIC is a protocol that uses UDP instead of TCP. Initially, Google helped QUIC, which has since been more commonly referred to as “HTTP/ 2-encryptor-over-UDP.”
People in the community have used informal names such as iQUIC and gQUIC to refer to these different versions of the protocol, to separate THE QUIC protocol from IETF and Google (which differ greatly in detail). The protocol for sending HTTP over “iQUIC” has been known as “HQ” (HTTP-over-quic) for a long time.
On November 7, 2018, Dmitri of Litespeed announced that they and Facebook had successfully completed the first interoperation between two HTTP/3 implementations. Mike Bihop’s follow-up to the HTTPBIS session on this topic can be seen here. The meeting ended with a consensus that the new name was HTTP/3!
The biggest advantage of the 0-RTT-QUIC protocol over HTTP2.0
Caches the context of the current session. When resuming the session next time, you only need to pass the previous cache to the server and verify that the session is successful.
0-RTT connection is arguably QUIC’s biggest performance advantage over HTTP2.
What is 0-RTT connection?
- The transport layer 0-RTT establishes the connection
- The encryption layer 0-RTT establishes the encrypted connection
multiplexing
QUIC is based on UDP, and there is no dependency between multiple streams on a connection. Even if a packet is lost, you only need to resend the lost packet instead of retransmitting the entire connection.
Better mobile performance
QUIC works 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.
Encrypted authenticated root text – armed to the teeth
TCP headers are not encrypted or authenticated, and are easily tampered with, injected into, and eavesdropped by intermediate network devices during transmission.
QUIC’s packet is armed to the teeth. Except for a few packets, such as PUBLIC_RESET and CHLO, all packet headers are authenticated and the packet Body is encrypted.
Therefore, any changes to THE QUIC can be detected by the receiver in a timely manner, effectively reducing the security risk.
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 amount 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.).
Such as:
- I send three packets in total, and the protocol calculates the XOR value of the three packets and sends a separate checksum, so there are four packets 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.
Problems of induction
Whether HTTP1.1 merge requests (such as CSSsprites) are applicable to HTTP2.0
There’s no need.
In header compression, both the client and the server maintain two identical static and dynamic dictionaries.
In static dictionaries, common header names and values are included. Static dictionaries are available on the first request. The header field can now be shortened to the index of the corresponding field in the static dictionary.
The dynamic dictionary is dependent on the context of the connection, and each HTTP/2 connection maintains a different dynamic dictionary. Dynamic dictionaries can be continuously updated at the join.
In other words, the key value or field of the original complete HTTP packet header can be converted into index due to the existence of the dictionary, and then searched and restored at the corresponding end, thus playing a role of compression.
Therefore, the more requests and responses generated on the same link, the more complete the dynamic dictionary will accumulate and the better the header compression will be, so the best practice for HTTP/2 sites is not to merge resources.
In addition, HTTP2.0 multiplexes so that requests can be transmitted in parallel, and one of the reasons HTTP1.1 merges requests is to prevent blocking problems caused by too many HTTP requests. Now that HTTP2.0 is capable of parallel transport, there is no need for merge requests.
Why problems with HTTP3.0: HTTP/2 underlying TCP limitations
Because HTTP/2 uses multiplexing, it is generally necessary to use only one TCP connection under the same domain name, but when packet loss occurs in this connection, HTTP/2 performs worse than HTTP/2.
In the case of packet loss, the entire TCP waits for retransmission and all subsequent data is blocked.
In the case of HTTP/1.1, however, multiple TCP connections can be opened, and only one of them is affected. The remaining TCP connections can still transmit data.
Modifying TCP is an impossible task.
How to enable the QUIC protocol in Chrome
MTF in the resource server and content distribution node have enabled HTTP3.0 protocol, according to the user browser backward compatibility, strongly recommend you to enable experimental QUICK protocol support in Chrome, experience the effect of acceleration:
- Enter Chrome ://flags in the browser address bar
- Find Experimental QUIC Protocol and change Default to Enabled
conclusion
The HTTP 1.0
- No status, no connection
- Short connection: Re-establishing the TCP request each time a request is sent, known as a three-way handshake, is a waste of performance
- There is no host header field, which is the host in the HTTP request header,
- Breakpoint continuation is not allowed, and you cannot transfer only part of the object, requiring the whole object to be transferred
The HTTP 1.1
- Long connection, pipeline, use connection:keep-alive use long connection
- Request pipelining
- – Added cache handling (new fields such as cache-control)
- Add Host field, support breakpoint transmission, etc
- Long connections cause stress to the server
The HTTP 2.0
- Binary framing
- Header compression, both sides maintain a header index table, so that there is no need to send values directly, through the send key to reduce the size of the header
- Multiplexing (or connection sharing), using multiple streams, each of which is transmitted in frames, enables a single TCP connection to handle multiple HTTP requests
- Server push
The HTTP 3.0
- Based on Google’s QUIC protocol, and QUIC protocol is implemented using UDP
- Reduced TCP three-way handshake time, and TLS handshake time
- [Fixed] HTTP 2.0 where a stream is blocked because of packet loss
- Optimized the retransmission policy. The number of the retransmitted packet is different from that of the original packet, reducing the consumption of subsequent retransmission calculation
- Connection migration, instead of using a TCP quad to determine a connection, uses a 64-bit random number to determine the connection
- Better flow control
- Implementation based on UDP
- Even 0 RTT is built
- UDP based multiplexing
- Encrypted authentication packets
- Forward error correction mechanism
GitHub Org_Hejianhui /JavaStudy GitHub Hejianhui /JavaStudy