A, HTTP / 0.9

Date: Released in 1991

  1. HTTP is an application layer protocol based on TCP/IP.

  2. It does not involve packet transmission, and mainly specifies the communication format between the client and the server

  3. By default, port 80 is used

  4. This version is extremely simple, with only one command, GET

  5. The protocol states that the server can only respond to a string in HTML format and not in any other format

  6. After sending the response data, the server closes the TCP connection

Second, the HTTP / 1.0

Date: Released in 1996

  1. Any format of content can be sent, including text, pictures, binary, video, etc

  2. In addition to the GET command, the POST command and HEAD command were introduced

  3. Add HTTP headers to the request and response format

  4. Added status code, multi-character set support, multi-part type, Authorization, cache, and Content Encoding

  5. (Short connection) A TCP connection is established for each request. Each TCP connection can only send one request. After sending data, the connection is closed

    TCP connections are expensive to create because they require a three-way handshake between the client and the server and are sent at a slow start rate. Therefore, the performance of HTTP 1.0 was poor. This becomes more and more of a problem as web pages load with more and more external resources.

    To solve this problem, some browsers use a non-standard Connection field on the request (to establish a long Connection)

      Connection: keep-alive
Copy the code

    This field requires the server not to close the TCP connection for reuse by other requests. The server also responds to this field.

      Connection: keep-alive
Copy the code

    A reusable TCP connection is established until the client or server actively closes the connection. However, this is not a standard field, and different implementations may behave differently, so it is not a fundamental solution.

3. HTTP/1.1 (by far the most mainstream version)

Date: January 1997

1. Introduction of persistent connection

That is, a TCP Connection is not closed by default and can be reused by multiple requests without declaring Connection: keep-alive.

A TCP Connection can be closed by sending Connection: close on the client’s last request.

Connection: close
Copy the code

2. Currently, most browsers allow up to six simultaneous TCP persistent connections for the same domain name.

3. Pipelining has been introduced

Clients can send multiple requests simultaneously within the same TCP connection, further improving the efficiency of the HTTP protocol

For example, a client needs to request two resources. The previous approach was to send A request and wait for A response from the server within the same TCP connection before sending B request. The pipe mechanism allows the browser to make A request and B request simultaneously, but the server responds to A request first and responds to B request after completion.

4. The Content – Length:

Multiple responses can be transmitted simultaneously in the same TCP connection, and this field is used to distinguish what belongs to which response

Content-Length: 3495
Copy the code

The above code tells the browser that the length of this response is 3,495 bytes, and that the following bytes belong to the next response. In version 1.0, the content-Length field was not required because the browser noticed that the server had closed the TCP connection, indicating that all packets had been received.

5. Block transmission coding:

The prerequisite for using the Content-Length field is that the server must know the Length of the response before sending it.

For some time-consuming dynamic operations, this means that the server can’t send data until all operations are complete, which is obviously inefficient. A better approach would be to send a block of data as it is generated, using “stream” instead of “buffer.”

Therefore, version 1.1 stipulates that you can use “chunked transfer encoding” instead of content-length fields. Any request or response header with a transfer-encoding field indicates that the response will consist of an undetermined number of data blocks.

Each non-empty data block is preceded by a hexadecimal value that represents the length of the block. Finally, a block of size 0, indicating that the response data sent. Here’s an example

6. Add the PUT, PATCH, HEAD, OPTIONS, DELETE methods and host field

The Host field made it possible to send requests to different web sites on the same server, laying the foundation for the rise of virtual hosts (where multiple virtual hosts can exist on a single physical server and share an IP address)

HOST field: specifies the server HOST name and port number to which the request will be sent

7. Cache processing:

HTTP/1.1 adds some new cache features to 1.0, including the introduction of entity tags, commonly known as e-tags, and the addition of a more powerful cache-control header

useETagsVerify the cached response

  • The server uses HTTP headersETagTo pass a validation token;
  • With validation tokens, resource updates can be checked effectively. If the resource has not changed, no data will be transferred. Such as:

The last GET request initiated by the browser exceeds 120s(cache-control :max-age=120), and the browser initiates a new request for the same resource. First, the browser checks the local cache and finds the previous response. However, the response has expired and the previous response cannot be used. At this point, the browser can make a new request and get a new complete response, but this is relatively inefficient because the resource has not been modified and there is no need to re-download the resource already in the cache.

This is the problem that ETag solves. The server generates and returns any ETag, which is usually a hash or other fingerprint of the contents of the file. The client does not need to know how the ETag is generated; It just needs to send it to the server on the next request. If the value of the ETag is still the same, the resource has not changed, and you can skip the download and access the local cache resource.

conclusion

Although version 1.1 allows the reuse of TCP connections, all data communications within the same TCP connection are sequential. The server processes the requests in a queued order. The server will respond only after processing one response. If the previous request takes a long time to process, there will be many more requests waiting in the queue, causing a “queue head jam” problem. At the same time, HTTP is a stateless connection, so repeated fields need to be added for each request, reducing bandwidth utilization.

A new problem with multiplexing is that critical requests can be blocked on the basis of connection sharing. SPDY allows you to set a priority for each request so that the most important requests get the first response. For example, when the browser loads the home page, the HTML content of the home page should be displayed first, and then all kinds of static resource files and script files are loaded, so as to ensure that users can see the content of the web page in the first time.

There are only two ways to avoid this problem: either reduce the number of requests or open more persistent connections at the same time. This has led to many web optimization techniques, such as merging scripts and stylesheets, embedding images into CSS code, domain sharding, and so on. This extra work could have been avoided if the HTTP protocol had been better designed.

HTTP / 2.0

In 2015, HTTP/2 was released. It’s not called HTTP/2.0 because the standards committee doesn’t plan to release any more sub-versions, and the next new version will be HTTP/3.

1 Binary Protocol

HTTP/1.1 headers must be text (ASCII encoding), and the data body can be either text or binary. HTTP/2, on the other hand, is a thoroughly binary protocol. The headers and data bodies are binary and are collectively called “frames” : header frames and data frames.

One advantage of binary protocols is that additional frames can be defined. HTTP/2 defines nearly a dozen frames, laying the foundation for future advanced applications. Parsing the data would be cumbersome if you did this with text, but binary parsing is much more convenient.

2 multiplex

HTTP/2 reuse TCP connections. Within a connection, both the client and the browser can send multiple requests or responses at the same time, and they don’t have to be sequentially mapped, thus avoiding “queue head congestion.”

For example, in A TCP connection, the server receives A request and B request at the same time. It responds to A request first, but finds the processing time is too long, so it sends the processed part of A request, then responds to B request, and sends the rest of A request when it is complete.

This two-way, real-time communication is called Multiplexing.

3 the data flow

Because HTTP/2 packets are sent out of sequence, consecutive packets within the same connection may be different responses. Therefore, the packet must be flagged to indicate which response it belongs to.

HTTP/2 refers to all packets per request or response as a stream. Each data stream has a unique number. When a packet is sent, it must be marked with a data stream ID to distinguish which data stream it belongs to. In addition, the ID of the data flow sent by the client is odd, and that of the server is even.

Halfway through the data stream, both the client and server can send a signal (RST_STREAM frame) to cancel the data stream. In version 1.1, the only way to cancel the data flow is to close the TCP connection. This means that HTTP/2 can cancel a request while keeping the TCP connection open for use by other requests.

The client can also specify the priority of the data flow. The higher the priority, the sooner the server will respond.

4 Header information compression

The HTTP protocol does not carry status, 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 wastes a lot of bandwidth and affects speed.

HTTP/2 optimizes this with the introduction of Header Compression. On the one hand, headers are compressed using GZIP or COMPRESS before being sent. On the other hand, both the client and the server maintain a header table. All fields are stored in the table and an index number is generated. In the future, instead of sending the same field, only the index number is sent.

5 Server Push

HTTP/2 allows the server to proactively send resources to the client, unrequested. This is called server push.

A common scenario is when a client requests a web page that contains many static resources. Under normal circumstances, the client must receive a web page, parse the HTML source code, find a static resource, and then send a static resource request. In fact, the server can anticipate that after the client requests the web page, it is likely to request static resources, so it actively sends these static resources along with the web page to the client.