This is the 6th day of my participation in the August More Text Challenge

Recently I am doing the front end test summary series, interested friends can add attention, welcome to correct, exchange.

Strive for each knowledge point can sum up some more, at least to do in the interview, for each knowledge point can kan up, not dumb fire.


The differences between HTTP versions are also a common interview question.

HTTP has gone through four versions — HTTP 0.9, HTTP 1.0, HTTP 1.1, and HTTP 2.0. Let’s take a look at how each version changes HTTP.

The HTTP 0.9

HTTP 0.9 was one of the earliest releases, released in 1991.

It accepts only GET as a request method, does not specify a version number in the communication, and does not support request headers. Since this version does not support the POST method, the client cannot pass much information to the server.

HTTP 0.9 is typically stateless, with each transaction processed independently and the connection released at the end of the transaction. The stateless nature of the HTTP protocol took shape in its first version.

The HTTP 1.0

HTTP 1.0, the second version of the HTTP protocol, was released in 1996 and is still widely used today, especially in proxy servers.

This is the first VERSION of the HTTP protocol to have a version number specified in the communication and has the following features:

  • Not only GET commands are supported, but request methods such as POST and HEAD are also supported.

  • HTTP request and response formats have also changed, with each communication containing headers that describe some information in addition to the data to be transferred.

  • No longer limited to the plain text format of version 0.9

    Multiple data formats can be supported, based on the Content-Type attribute in the header, making it possible for the Internet to transfer binaries like images, audio, and video, not just text.

  • Cache is supported. When a client accesses the same web site within a specified period of time, it can access the cache directly.

  • Other new features include Status Code, multi-character set support, multi-part Type, authorization, cache, and Content encoding.

Version 1.0 works by sending only one request per TCP connection. When the server responds, the connection is closed and the TCP connection needs to be re-established for the next request. TCP connections are expensive to establish because of the need for three handshakes between the client and server and slow start.

The HTTP 1.0 version has poor performance. The more external resources a web page loads, the more this problem becomes. To solve this problem, some browsers add a Connection field to the request header:

This field requires that the server not close the TCP connection so that other requests can be reused. The server also responds to this field.

A TCP connection is established that can be reused until the client or server actively closes the connection. However, this is not a standard field and may not behave consistently across implementations, so it is not a fundamental solution.

The HTTP 1.1

The default Connection is keep-alive, which works well with the proxy server.

It also supports piped multiple requests simultaneously to reduce line load and increase transmission speed.

HTTP 1.1 has the following features:

  • Introduction of persistent Connection

    That is, TCP connections are not closed by default and can be reused by multiple requests without the Connection: keep-alive declaration. The client and server can close the connection if they find the other side inactive for a period of time. However, it is standard practice for the client to send Connection: close on its last request, explicitly asking the server to close the TCP Connection.

  • Added a pipeline mechanism

    In the same TCP connection, multiple requests can be sent simultaneously, which increases the concurrency and further improves the efficiency of the HTTP protocol.

    For example, the client needs to request two resources. In the past, in the same TCP connection, first send A request, and then wait for the server to respond, and then send A request B.

    The pipeline mechanism allows the browser to make both A and B requests at the same time, but the server responds to A and B requests in the same order.

    A TCP connection can now send multiple responses, and there has to be a mechanism to distinguish which response packets belong to. This is what the Content-Length field is for, declaring the length of the response.

  • Block transfer encoding

    To use the Content-Length field, the server must know the Length of the response before sending it. For some time-consuming dynamic operations, this means that the server waits until all operations are complete before sending data, which is obviously inefficient.

    A better approach is to send a block of data as it is generated, using a stream instead of a buffer.

    Therefore, HTTP 1.1 allows for “chunked transfer encoding” instead of using the Content-Length field. Any request or response header with a Transfer-Encoding field indicates that the response will consist of an undetermined number of data blocks.

  • Added request modes such as PUT, PATCH, OPTIONS, and DELETE.

  • The Host field has been added to the client request header to specify the domain name of the server.

  • HTTP 1.1 supports file breakpoint continuation, RANGE:bytes. HTTP 1.0 transmits a file from the file header, which is 0 bytes. RANGE:bytes=XXXX Indicates that the server is required to send the file from the XXXX byte. The return code is 206 (Partial Content)

HTTP / 2.0

This is also the latest version of HTTP, which was officially released as an Internet standard in May 2015.

It has the following characteristics:

  • Binary protocol

    The HTTP 1.1 header must be text (ASCII encoded), and the data body can be either text or binary.

    HTTP 2.0 is a completely binary protocol, with both headers and data bodies being binary and collectively referred to as “frames” : header and data frames.

  • multiplex

    HTTP 2.0 multiplexes TCP connections so that both the client and the browser can send multiple requests or responses at the same time, without having to follow the sequence. This avoids “queue congestion”. And the number of concurrent requests is orders of magnitude larger than HTTP 1.1).

    For example, in A TCP connection, the server receives both A request and B request, and responds to A request first, only to find that the process is time-consuming. It sends the completed part of A request, responds to B request, and then sends the rest of A request.

  • Header compression

    The HTTP protocol has no state, and all information must be attached to each request. Therefore, many fields of the request are repeated, such as Cookie and User Agent. The same content must be attached to each request, which will waste a lot of bandwidth and affect the speed.

    HTTP 2.0 optimizes this by introducing header compression. On the one hand, header information is compressed and sent using GZIP or C ompress; On the other hand, both the client and the server maintain a header table where all fields are stored, generating an index number, and then not sending the same field, but only the index number, which increases speed.

  • Server push

    HTTP 2.0 allows a server to send unsolicited resources to a client. This is called server push. This means that when we request data from a Web server that supports HTTP 2.0, the server will incidentally push some resources that the client needs to the client, so that the client will not create a connection to send a request to the server. This is a great way to load static resources. These resources pushed by the server side actually exist somewhere on the client side, and the client side can load these resources directly from the local, without going to the network, the speed is naturally much faster.


HTTP/0.9: support only GET method, can only send HTML format string.

HTTP/1.0: support a variety of data formats, add POST, HEAD and other methods, increase header information, can only send one request at a time (no persistent connection)

HTTP/1.1: default persistent connection, request pipelinization, increase cache processing, increase Host field, support breakpoint transmission block transmission, etc.

HTTP/2.0: binary framing, multiplexing, header compression, server push


Thanks for reading!


Learn interesting knowledge, meet interesting friends, shape interesting soul!

Hello everyone, I am the author of “programming Samadhi”, I am king Yi, my public account is “programming Samadhi”, welcome to pay attention, I hope you can give me more advice!

You come, with expectations, I have ink to welcome! You return, no matter gain or loss, only to yu Yun give each other!

Knowledge and skills should be paid equal attention to, internal force and external power should be repaired simultaneously, theory and practice should grasp both hands, both hands should be hard!