HTTP1.0 era

HTTP / 0.9 – HTML file

Purpose: Transfer small HTML files

Pattern based on request response

format

Request: GET /index.html (because only one request line is needed to fully express the client’s requirements)

Response: Only response body (no response header, the server doesn’t need to tell the client much, just return data)

coding

Since they are HTML files, ASCII bytecode works best

HTTP/1.0 – Multiple file types

process

  1. Initiate a request: The browser uses the HTTP request header to tell the server what file type, file encoding, compression form, and file language it expects.

  2. Process the request: Prepare the response based on the information in the request header, but sometimes there are some unexpected situations, such as the browser request is GZIP, but the server only supports BR compression, and the content-Encoding field in the response header tells the browser the final processing result

  3. The browser extracts the file using the BR method, decodes it in UTF-8, and parses the file in HTML.

format

request

GET /4848 HTTP/1.0
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 response

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 <title>Query results</title> <h1>Query results</h1> ......Copy the code

Function – request header/response line + response header implementation

  1. Report the final processing of the server — via the status code of the response line
HTTP / 1.0 200 OKCopy the code

  1. Supports multiple file types

    HTML/ Javascript/CSS/ images/Audio/video

    You need to know what type of data the server is returning so that the browser can do something about it

accept: application/json, text/plain, */*
content-type: application/json
Copy the code

  1. Support file compression

    Usually CSS/JS files

    To reduce transmission performance, the server compresses data before transmitting it, so the browser needs to know how the server compresses data

accept-encoding: gzip, deflate, br
content-encoding: gzip
Copy the code

  1. Support for multiple languages
accept-language: zh-CN,zh
Copy the code

  1. Support for multiple encodings

    Since there are many different types of files, each of which may be encoded differently, the browser needs to know the file’s encoding type, not just ASCII, in order to be able to read the file accurately

accept:text/plain; charset=utf-8
content-type: application/json; charset=utf-8
Copy the code

  1. To take the strain off the server

    Provides a Cache mechanism for caching data that has been downloaded

cache-control: no-store, no-cache, must-revalidate
Copy the code

  1. Basic client information can be collected

    The user agent in the request header

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

HTTP/1.1 — TCP persistent connections

TCP persistent link

Multiple HTTP requests can be sent over a TCP connection, and the TCP connection remains open as long as the browser or server is not explicitly disconnected. It reduces the number of TCP connections established and disconnected, reduces the burden on the server, and shortens the overall request time

However, HTTP/1.0 needs to go through three stages of establishing TCP connection, transmitting HTP data and disconnecting TCP connection for each HTTP communication

If the files are small and there are few references per page, this transfer is not a big problem. There are more and more image files in a single page. Sometimes, a page may contain hundreds of external reference resource files. If you need to establish TCP connection, transfer data and disconnect each file when downloading it, it will undoubtedly increase a lot of unnecessary overhead

HTTP/1.0 communication mode

HTTP / 1.1 long connection

Maximum persistent connection of a single domain name

A maximum of six TCP persistent connections can be established for the same domain name in the browser

Closing persistent links
Connection: close
Copy the code

Persistent connections are enabled by default in HTTP/1.1 (Connection: keep-alive) and do not require special request headers

Support for virtual hosting

Host: fastlane.rubiconproject.com
Copy the code

The Host field is added to the HTTP/11 request header to represent the current domain name address, so that the server can do different processing based on different Host values

In HTTP/1.0, an IP can only serve one domain name. However, with the development of virtual host technology, it is necessary to bind multiple virtual hosts to a physical host. Each virtual host has its own separate domain name, and these separate domain names all share the same P address.

Try pipelining

HTTP/1.1 attempts to solve the problem of queue head blocking (one HTTP request can receive a response before the next one can be sent) by pipelining (sending multiple HTTP requests in bulk, but the server still needs to reply based on the order of requests)

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

Supports dynamic content generation

Usually CSS/JS files

Supports dynamic content generation

Transfer-Encodeing: chunked
Copy the code

The full data size (Content-Length: 901) should be set in the response header so that the browser can receive data based on the set data size. However, with the development of server-side technology, the content of many pages is generated dynamically, 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.

HTTP/11 solves this problem by introducing the Chunktransfer mechanism, in which the server will divide the data into several arbitrarily sized data blocks, and each data block will be sent with the length of the previous data block, and finally a zero-length block will be used as a signal that the data is sent. This provides support for dynamic content.

Client Cookie and security mechanism

HTTP / 2.0 era

There are no request and response rows

HTTP / 1.1 era

  1. Features :TCP persistent connection; Each domain name has a maximum of six TCP persistent connections. Domain name Sharding mechanism

    Compared to a single TCP persistent connection, only 1/6*CDN is insufficient: bandwidth utilization is low and the bandwidth is wide

  2. Bandwidth underutilization a core problem with HTTP/1.1 — the difficulty of using up bandwidth. For example, we often say that 100M bandwidth, the actual download speed can reach 12.5m /S, while using HTTP/1.1, maybe when loading page resources can only use up to 2.5m /S, it is difficult to use up 12.5m

    Bandwidth: Refers to the maximum number of bytes that can be sent or received per second. We call the maximum number of bytes sent per second the uplink bandwidth and the maximum number of bytes received per second the downlink bandwidth HTTP/1.1 era

why

  1. TCP slow start
  2. Multiple TCP connections compete for fixed bandwidth
  3. HTTP/1.1 queue header blocking problem

Slow starts and multiple TCP competing for bandwidth are due to TCP’s own mechanism. We don’t have the ability to replace TCP, so we have to find a way to solve HTTP header blocking

TCP slow start: Once a TCP connection is established, it enters the state of sending data. At first, THE TCP protocol uses a very slow speed to send data, and then speeds up the speed of sending data until the speed of sending data reaches an ideal state. This process is called slow start

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

Multiplexing – HTTP/2 resolves HTTP queue header blocking

Only one TCP connection is used for a domain name. In this way, the entire page needs only one slow start and multiple TCP connections are avoided

Each request has a corresponding ID(stream1 for index.html request and stream2 for fo.css request). The HTTP queue header is blocked

Implementation – binary frame segmentation

  1. Sender: After the sent message is processed by the binary framing layer, it is converted into frames with the request number

  2. Recipient: After receiving all frames, all the same frames are merged into a single complete message

You can set the priority of requests

The added benefit of multiplexing is that when a high priority request is received, it is possible to suspend the previous priority processing of key resources (JS/CSS) such as index.htm and bar. When a request is received, the response headers of index.html and bar.js p can be immediately returned to the browser, and then the response body data of index.html and bar.js can be returned to the browser

Server push

Plays a crucial role in the speed of the first page opening. * When a user requests a * HTML page, the server knows that the * HTML page references several important Javascript and CSS files, so after receiving the * HTML request, the server attaches the CSS files and * to the page The Javascript file is 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.

The head of compression

Through HPACK algorithm, that is, dictionary + Huffman coding

HTTP / 3.0 era

HTTP / 2.0 era

Although HTP/2 solves the problem of queue head blocking at the application layer, there are still TCP queue head blocking and TCP handshake time is too long

  1. Team head block

HTTP header blocking: one HTTP request receives a response before the next request can be sent. In the ERA of HTTP/2.0, HTTP header I blocking was solved. The underlying implementation of multiplexing, which shares a TCP connection with different requests through binary framing, was attempted in the HTTP/1.1 era by pipelining (requests can be sent in parallel, but the response must be returned sequentially, with the latter response having to follow the previous one. The request must be idempotent and cannot modify the resource. Browsers abandon this optimization because unexpected interrupts require clients to resend unreceived requests that are not idempotent and cause resource destruction. TCP queue blocking :TCP packets are transmitted in an orderly manner. If a packet in the middle is lost, it waits for the packet to be retransmitted, causing subsequent packets to be blocked. TCP packet header blocking: TCP packets are transmitted in an orderly manner. If one packet is lost, the system waits for the retransmission of the packet, causing subsequent packets to be blocked.

TCP with binary framing serves a request:

The browser opens six TCP connections for each domain name. If one of these TCP connections is blocked, the other five connections can continue to transmit data.

TCP with binary framing serves multiple requests

If packet loss occurs in any of the data flows, all requests in the TCP connection will be blocked

During TCP transmission, the loss of a single packet causes congestion called header congestion on TCP. As the packet loss rate increases, the transmission efficiency of HTTP/2 deteriorates. Some test data showed that HTTP/1 performed better than HTTP/2 when the system reached a 2% packet loss rate

  1. The TCP handshake takes too long. Procedure

When establishing a TCP connection, three handshakes are required to confirm the connection with the server, that is, 1.5 RTT is consumed before data is transmitted.

If HTTPS is used, the TLS handshake process is also required, which requires two handshake delay processes. TLS12 and TLS1.3, each version takes different time to establish a connection

We need to spend 3-4 RTTS before transferring data

Network latency Round Trip Time (RTT) The total Round Trip Time of sending a data packet from the browser to the server and then returning the data packet from the server to the browser is called RTTTCP handshake Time too long

We now know that TCP has drawbacks such as queue blocking and connection establishment delays, but TCP has become rigid (the rigidity of intermediate devices – + the operating system also causes TCP to become rigid) and can only be further optimized by using UDP

Based on QUIC protocol — reliable + multiplexing + encrypted transmission

  1. Similar to TCP traffic control, transmission reliability functions
  2. Integrated TLS encryption function
  3. Realize the quick handshake function
  4. The multiplexing function in HTTP/2 is realized

QUIC integrates “TCP reliability + multiplexing + encrypted transport” to thoroughly optimize the file transfer on the Web from the bottom of the protocol, so when the ecosystem is relatively mature, it can be used to build a more efficient network than HTTP/2 today

The challenge of HTTP / 3

First: As of now, HTTP/3 is not fully supported on the server or browser side. Chrome has supported the Gooe version of oUC for several years, but there are significant differences between this version of QUIC and the official QUC. Because the system kernel optimization of UDP is far from reaching the optimization degree of TCP, which is also an important reason to hinder QUIC third: the problem of intermediate device fossilization. The UDP optimization of these devices is much lower than that of TCP. According to statistics, when QUC is used, the packet loss rate is about 3% to 7%