HTTP/1.0, the protocol is still in the exploratory stage, IETF has officially released four major versions:

I see that HTTPS is not included in the HTTP version evolution, but I think it should be included in the HTTP version evolution, considering the importance and universality of HTTPS, as well as the security improvements to HTTP/1.1 and the foundation for HTTP/2.0.

  • HTTP/1.0, released in November 1996 under the document RFC 1945, is now out of date. Its main achievement is to introduce the concept of HTTP content head, which allows the transfer of meta data for both requests and responses, making the protocol more extensible. Supports transfer of files other than HTML files.

  • HTTP/1.1, published by THE Internet Engineering Task Force of the IETF in June 1999, RFC 2616, defines a version of the HTTP protocol that is widely used today. It is also the longest version, and is still used by many websites. The most notable feature is the “long connection”, and the introduction of caching.

  • HyperText Transfer Protocol Secure (HTTPS), which is a Secure and encrypted transport Protocol that establishes HTTP transport over TLS/SSL layer, was officially confirmed by RFC 2818 published in May 2000. This is a widely used update that will become the basis for HTTP/2.0, which I will cover in a separate article later.

  • HTTP/2.0, the latest version, has been evolving since it was formally standardized in May 2015. The most critical feature is the introduction of frame structure, multiplexing

  • HTTP/3.0, still in development…

HTTP / 1.0

GET /mypage.html HTTP/1.0 user-agent: NCSA_Mosaic/2.0 (Windows 3.1) 200 OK Date: Tue, 15 Nov 1994 08:12:31 GMT Server: CERN/3.0 libwww/2.17 Content-type: <IMG SRC="/myimage.gif"> </HTML> ' 'Copy the code

This is a typical HTTP/1.0 request message, and as you can see, it already contains the HEAD header field and uses a status code.

The problem with HTTP/1.0 was “short links” :

  • Short links mean that a new TCP connection is created for each HTTP request and closed immediately upon receipt of the reply. Back in ’95, that wasn’t a problem. Because the content is still mostly text.

  • As the content of the site grows, this link pattern leads to three problems: time to frequently create new connections + server signaling overhead + slow startup

    • TCP connection reuse failure causes the client to undergo three handshakes each time it initiates an HTTP request, which has a significant impact on web page loading speed in scenarios with high latency.

    • Four handshakes are required to release THE TCP connection. When a web page is heavily visited, the server is overwhelmed and network signaling storms occur. In fact, TCP connections can support hot connections. HTTP short connections destroy TCP capabilities, and new cold connections degrade TCP performance. TCP Hot connections refer to active connections, and cold connections refer to new connections.

    • The transmission window of a TCP connection has Slow Start. The Slow Start means that the bandwidth increases each time the TCP receiving window receives an ACKNOWLEDGEMENT ACK. However, if packet loss occurs, TCP considers it to be network congestion and takes measures to alleviate network congestion. However, frequent HTTP disconnections cause TCP connections to be in a low-bandwidth state, which affects the transmission of large files.

HTTP / 1.1

Arguably, HTTP/1.1 was built to address the pain points of 1.0. It supports the following key features:

  1. The keep-alive connection is supported
    • After completing an HTTP request, the TCP connection is kept for a period of time and is repeatedly used to send a series of HTTP requests.
    • Note: This does not mean that only one TCP connection is established between the client and server. In fact, multiple connections can still be established between the HTTP/1.1 client and server, but the transfer efficiency is much higher than 1.0.
    • The long connection saves the time and signaling cost of creating a TCP connection and releasing a TCP connection three-way handshake, greatly reduces the page loading delay, and maintains sufficient transmission bandwidth by taking advantage of TCP’s sliding window capability.
    • The server can set the minimum hold time for a long connection. TCP connections are released after being idle for a period of time.
    • Long connections are implemented through Connection control in head. This field indicates the TCP connection mode between the client and server. Connection :close indicates a short connection. If connection:keep-alive indicates a long connection

  1. Enforces the Host header field in the message

    • HTTP/1.0 assumes that each IP address is bound to a domain name, so there is no hostname in the request message.
    • However, by HTTP/1.1, a server can host multiple systems, support multiple hosts, and IP addresses are no longer unique. Adding the host field enables different domain names to be configured on the same IP address server, making Internet hosting possible.

  2. Allows response data to be chunked (chunked)

    • Generally, the server sends the response data to the client as a whole packet. The Content-Length field in Message indicates the Length of the response message body. The Length must be accurate. If the content-Length is shorter than the actual Length returned, the Content will be truncated. If the content-Length is longer than the actual Length, the client will always be pendding. If the previous response message is not completed, the subsequent data will be blocked, i.e. Head of Line blocking.
    • HTTP/1.1 allows the server to process and send the response data in chunks, which is very effective for large data files. The server does not need to package the whole data and tell the client the total size of the sent content in advance, just add transfer-encoding in the HTTP response header: Chunked, which tells the browser that I’m using chunked transfer encoding, and the chunks are reassembled on the browser side.
    • The advantage of this is that the transmission efficiency and success rate are improved, and congestion and delay are reduced.

  1. HTTP/1.1 adds cache management and control, which I’ll cover separately in a later article

The disadvantage of HTTP / 1.1

There are two sides to every coin, and while addressing the problem, HTTP/1.1 introduces some new problems:

  1. In the idle state, long connections still consume server resources and can be subject to DDoS attacks when they are heavily loaded.

  2. HOLB (Head of Line Blocking) is a Blocking connection, so HTTP requests and responses are still serial by default. In other words, HTTP requests are sent sequentially, and the next request is sent only after the current request is answered. If a request is blocked, subsequent requests on the same TCP connection will be blocked.

    • Thus, pipelining is a solution proposed in HTTP/1.1, where a client can initiate a second request without waiting for a response, and the server can return the response in the order it arrived, thus reducing latency.
    • Pipelining, however, does not solve the HOLB problem because the protocol dictates that the server receiving the request must send the response in the order it is received. That is, if the first request is blocked, the server cannot respond to subsequent requests even if it receives them. Pipelining is therefore not widely accepted.

HTTP / 2.0

Fifteen years later, HTTP/2.0 arrived on the Web. HTTP/2.0 is a more complete upgrade than HTTP/1.1. First of all, HTTP/2.0 connections are based on TLS encrypted transport, not plaintext transport like 1.x. Second, he converted HTTP packets into binary frames and introduced the Stream mechanism, breaking the HTTP serial limit at one stroke!

Binary Frame

HTTP/2.0 adds a binary framing layer between the application and transport layers, binary Framing. Its purpose is to improve transport performance and achieve low latency and high throughput without altering HTTP/1.1 content:

As shown above, the binary framing layer divides HTTP/1.1 messages into frames and embeds them into streams. The data frame is separated from the header frame, which allows compression for the header.

In the binary framing layer, HTTP/2 splits all transmitted information into smaller messages and frames and encodes them in binary format, where HTTP1.1 headers are encapsulated in HEADER frames. The corresponding Message body is wrapped inside the DATA Frame.

Header Compression

  • Http1.1 contains a large amount of information in the header, usually in the hundreds of bytes, and is repeated with each request.

  • HTTP /2 uses binary frames to compress the size of the headers that need to be transmitted, while the client and server each cache a header field table, avoiding duplicate header transmission and reducing the size of the headers that need to be transmitted. Especially for polling requests for the same resource, the signaling overhead of the header is zero bytes, in which case all header fields automatically use the values sent by the previous request.

  • If the header changes, you simply add the change to the binary frame, and the change is added to the cached table of header fields, which remain for the lifetime of the HTTP 2.0 connection and are updated by both the client and the server.

  • HTTP /2 uses the HPACK② algorithm specifically designed for header compression.

Multiplexing

  • In the previous section, we mentioned that HTTP/1.1 introduced the problem of HOLB queue head congestion due to the serial relationship between HTTP requests and responses. HTTP/1.1 also limits the number of client connections to the same domain, such as Chrome’s limit of 16, which also affects the efficiency of page loading. This is one of the reasons why some sites have multiple static resource CDN domain names.

  • HTTP/2.0 multiplexing introduces the Stream mechanism. In a TCP connection, it can carry the multiplexing of any number of streams, put HTTP requests and responses into binary frames, and realize multi-stream parallelism through Stream. The following figure shows a TCP connection:

  • Each stream has multiple frames that are not dependent on each other, and these frames can be sent and responded out of order and can be prioritized. Messages can be exchanged bidirectionally on the same TCP connection in parallel. When they reach the end point, different streams are reconnected according to the Stream ID at the head of different frames to assemble them.

  • The client sends the stream ID to the server for each request. When the server responds, it returns the ID, and the client knows that the response belongs to that request. In this way, the disordered asynchronous multiplexing is realized, which greatly improves the concurrent ability of the client and speeds up the loading of resources.

  • In HTTP/2.0, because streams all use the same TCP connection, the connection can be very “hot” and can carry much larger data streams, allowing high bandwidth to really serve HTTP performance!

  • Multiplexing converts serial transmissions of multiple requests and responses to parallel or out of sequence, distinguished from one another by streamId. This completely eliminates HOLB queue head congestion and allows each request to be prioritized, with the server responding first to the request with a higher priority.

Request Priorities

A few more words about request priority. After binary framing, requests are sent out in a different order, which affects page assembly time, so HTTP/2.0 has added a feature that identifies priorities for specific content.

  • The server can control the allocation of resources (CPU, memory, bandwidth) according to the priority of the flow, and sends the request response with higher priority to the client when the response data is ready.

  • But the order is not absolute, and a mix of priorities is necessary. Because of absolute adherence, the problem of queue head blocking can be introduced again: slow high-priority requests block the delivery of other resources.

  • The priority level can change dynamically at run time, and as the user scrolls through the page, the user can tell the browser which image is most important, increasing the request priority for that image.

  • Recommended priority Settings: main HTML > CSS files > JS files > Images/videos, etc

Server Push

This mechanism is easy to understand. In HTTP/1.X, the server sends whatever the client requests. HTTP/2.0 In order to improve the transmission efficiency, the server can send the required resources along with index.html to the client without the client’s request, eliminating the need for the client to repeat the request step!

  • The triggering of this server push is still determined based on the request object of the client.

  • When a server wants to actively PUSH a resource, it sends a Frame of Type:PUSH_PROMISE with the Stream ID that PUSH needs to create, telling the client: “I’m going to send you the resource with this ID.” When the client parses the Frame, it recognizes PUSH_PROMISE and is ready to accept it.








Thank you for reading. If there are any inaccuracies or errors, please leave comments and correct them

Summary is not easy, please do not reprint without permission, otherwise don’t blame old uncle you are welcome

Welcome technical friends to communicate with me, wechat 1296386616

References:

What about the chunking transfer encoding in HTTP? Liu zhijun foofish.net/http-transf…

HTTP / 2 profile by Ilya Grigorik & Surma developers.google.com/web/fundame…

Learning HTTP/2.0 Server Push Filter by Helospark github.com/helospark/l…