HTTP 3.0, don’t you know 1 and 2?

It takes about 5 minutes to read the full article.

An overview of the

HTTP protocol has four important phases, which are 0.9/1/2/3, among which 1 is divided into 1.0 and 1.1.

What does the agreement provide for

HTTP/0.9 serves simple HTML file transfers

HTTP/0.9 can only be used to transfer small HTML files encoded in ASCII bytecode

The request and the corresponding format are simple, the request has only one request line, and the corresponding part has only one corresponding body

HTTP/1.0 supports multiple file types

Because HTTP/1.0 supports a wider variety of file formats, requests need to be marked with “file type I need, file encoding…” , request head arises at the historic moment; The server may not be able to prepare the data as specified after receiving the request, so it marks the final organization of the data in the response, hence the response header

Request structure

// Request line GET /4848 HTTP/1.0 // Request header Connection: keep-alive user-agent: Mozilla/3.01 (X11; I; SunOS 5.4 SUN4m) Pragma: no-cache Host: tecfa.unige.ch:7778 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*Copy the code

The corresponding structure

HTTP/1.0 200 OK // Date: Wed, 16 Apr 97 22:54:42 GMT Server: E_WEB (e_moo-web-server / 1.2-D-not WOO) (LambdaMOO 1.8.0 P5) Content-type: Text/HTML // response body <title>Query results</title> <h1>Query results</h1>...Copy the code

Common request headers and response headers

The browser uses the request header to tell the server what type of file it wants, file encoding, compression form, file language…

The server tells the browser what to do with the response header

1. The file type

In addition to HTML, there is Javascript/CSS/ images/audio/video

// Accept: application/json, text/plain, */* // Content-type: application/jsonCopy the code

2. File compression format

To reduce the load, the server compresses data before transferring it, so the browser needs to know how the server compresses data, usually for CSS/JS files

// Request header accept-encoding: gzip, deflate, br // Response header Content-encoding: gzipCopy the code

3. File encoding format

Different types of files have different encoding types. In order to accurately read the file, the browser needs to know the encoding type of the file

// Accept :text/plain; Charset = UTF-8 // Response header Content-Type: application/json; charset=utf-8Copy the code

4. The cache

HTTP/1.0 provides a caching mechanism for caching data that has already been downloaded

Cache-control: no-store, no-cache, must-revalidateCopy the code

5. Basic information about the client

Through the UA, you can know the browser version and operating system

// Request header user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)Copy the code

HTTP/1.1 began to support persistent connections

HTTP requests are built on top of TCP requests, so TCP connections need to be established and broken.

Prior to HTTP1.1, every HTTP request was built on top of a TCP connection, adding a lot of unnecessary overhead.

The same three requests are made, and the time comparison between the two:

Persistent connections are controlled by request headers. If no special processing is performed, the persistent connection is maintained by default.

// Connection header :keep-aliveCopy the code

Persistent connections can be closed in the following ways

// Connection header :closeCopy the code

In addition, HTTP/1.1 introduces other features

1. Virtual host

With the development of virtual host technology, we want to use a physical host to map multiple virtual hosts: each virtual host has its own domain name, but these individual domain names all point to the same IP address.

HTTP/1.1 adds the Host field in the request header to indicate the domain address of the current request, so that the server can do different processing based on the domain name

// Request header Host: nian.frontend.comCopy the code

2. Supports dynamic content generation

With the development of server-side technology, the content of many pages is dynamically generated, so the final data size is not known until the data is transferred, which causes the browser to not know when all the file data will be received. Previously, the response header used content-Length to set the full data size.

HTTP/1.1 solved this problem by introducing the Chunktransfer mechanism: the server would divide the data into several arbitrarily sized data blocks, each data block would be sent with the length of the previous data block, and finally a zero-length block would be used as a signal that the data was sent. This provides support for dynamic content.

// Response header transfer-encodeing: chunkedCopy the code

3. Pipetry

HTTP/1.1 attempts to solve queue header blocking by pipelining.

Pipelining: Multiple HTTP requests are sent together and the server responds in the order requested

Queue head blocking: the next HTTP request cannot start sending until the previous HTTP request receives a response

FireFox and Chrome both experimented with pipelining, but for various reasons they eventually abandoned it

4. The client cookies

Cookie is a small piece of data that the server sends to the user’s browser and saves locally. When the browser sends another request to the same server, it carries the Cookie to inform the server whether the two requests come from the same browser.

// Response header set-cookie: yummy_cookie=chocoCopy the code

// Request header Cookie: yummy_cookie=choco;Copy the code

Fourth, HTTP/2.0 to achieve multiplexing

HTTP/1.1 implements persistent connections, but for each long connection, only one HTTP request is being transmitted at a point in time. This leads to poor bandwidth utilization. For example, with a 100M bandwidth, the actual download speed can theoretically reach 12.5m /S, but may actually be as low as 2.5m /S when loading page resources.

There are three reasons for this bandwidth underutilization: slow TCP startup, TCP contention, and queue header blocking

HTTP queue header blocking: Other requests cannot be processed until the current request receives a response, so that data cannot be requested in parallel

HTTP/2.0 uses multiplexing to solve HTTP queue header blocking, so that requests are sent in parallel.

Multiplexing implementation: binary frame division

Everyone uses the same TCP connection, but each HTTP request has a unique request number to distinguish it from each other.

All sent messages are processed at the binary framing layer and converted into frames with the corresponding request number

After receiving all the frames, the receiver merges the frames with the same number into one complete message

Other features are also introduced in HTTP/2.0

1. Resource priority

Multiplexing breaks requests up frame by frame, with the added benefit that when a high-priority request is received, others can be suspended in favor of critical resources

2. Server push

Server push plays a crucial role in the speed of opening the page for the first time.

* When the browser requests a * HTML page, the server knows that it references several important JS/CSS files. So it’s sent to the browser, so that when the browser has parsed the HTML file, it can get the CSS file and Javascript file that it needs,

3. The head of compression

Browsers and servers maintain the repeated header fields as a dictionary, with short key values for actual transmission.

5. HTTP/3.0 uses UDP protocol

Before we dive into 3.0, let’s take a closer look at the 2.0 issues: TCP queue header blocking and TCP handshake times being too long

What is queue head blocking

Header blocking is divided into HTTP header blocking and TCP header blocking

1. HTTP header blocking means that the client can send the next HTTP request after receiving the response from the previous HTTP request. HTTP/2.0, described above, has been resolved.

2. TCP packet header blocking means that packets are transmitted in an orderly manner. If any packet is lost, it has to wait for retransmission, causing subsequent packets to be blocked.

As the packet loss rate increases,HTTP/2.0 transmission efficiency gets worse and worse.

Some test data showed that HTTP/1 performed better than HTTP/2 when the system reached a 2% packet loss rate

The TCP handshake takes too long. Procedure

When establishing a TCP connection, you need to shake hands with the server three times to confirm the connection

If HTTPS is used, the TLS handshake process is also required, which requires two handshake delay processes.

In this context, HTTP/3.0 was proposed. It is based on the QUIC protocol.

Is network performance optimization still needed?

The impact of HTTP/2.0 multiplexing is huge, as can be seen from web developer tools’ web requests.

• Under version 1.1, requests were blocked for a long time (in gray) because of TCP

Connections can only serve one HTTP/1.1 request at a time.

• In version 2.0, requests can be answered in a timely manner

In the 2.0 era, some of the old optimizations will backfire.

1. File merging

Before, we would use JS file merge, Sprite diagram and other ways to reduce the number of HTTP requests, to achieve the purpose of optimization. TCP in the 1.1 era could only be multiplexed serially, but now it can be transported in parallel.

If files A, B, and C are merged, a separate update of resource A will cause the local cache to merge files to be updated as a whole. Instead of compressing the file, you can update the resource with smaller granularity, which is a better choice.

2. Domain name Sharding

Previously, due to browser restrictions on the number of TCP connections within the same domain name, we used to put files under several different domains to prevent HTTP requests that exceeded the number of connections from being blocked.

But with multiplexing, files can be downloaded at the same time under the same domain name, and there is only one domain name, so we just set up a TCP connection.