The introduction

HTTP is an application layer protocol consisting of requests and responses. It is a standard client-server model.

Let’s take a look at [HTTP Version Draft Evolution]

Let’s look at how it has changed in terms of major changes

Early HTTP/0.9 – single-line protocol

The request consists of a single line of instructions, starting with the only available method GET, followed by the path to the target resource (protocol, server, port number are not required once you connect to the server).

GET /mypage.html
Copy the code

The response is also extremely simple: just the response document itself.

This is a very simple HTML page </HTML>Copy the code

HTTP/0.9 responses do not contain HTTP headers, which means that only HTML files can be transmitted, not other types of files. There are no status codes or error codes: When a problem occurs, a special HTML file containing information describing the problem is sent back.

Second, the HTTP / 1. X

HTTP grew as the HTTP/0.9 protocol had very limited use and browsers and servers rapidly expanded content to make it more versatile. HTTP 1.x has also undergone two major evolutions.

1. HTTP/1.0 – Build scalability

The main changes from http0.x are as follows:

  1. Protocol version information is now sent with each request (HTTP/1.0 is appended to the GET line)
  2. The status code is sent at the beginning of the response, enabling the browser to know whether the request succeeded or failed and adjust its behavior accordingly (such as updating or using local caching)
  3. The introduction of the HTTP header concept allows the transfer of metadata, both for requests and responses, making the protocol very flexible and extensible.
  4. In the new HTTP header (Content-Type) with the ability to transfer other types of documents than plain text HTML files

A typical HTTP/1.0 request would look like this:

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.17Content-type: text/ HTML <HTML> A page containing an image <IMG SRC="/myimage.gif">
</HTML>
Copy the code

Next comes the second connection, requesting the image:

GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17Content-type: text/ GIFCopy the code

Http1.0 was narrowly defined as an attempt, not an official standard, but a few months after its release, the HTTP1.1 standard was released

2. HTTP/1.1 — Standardized protocol

HTTP/1.1 removes a lot of ambiguity and introduces a number of improvements. HTTP/1.1 is one of the more familiar protocols. The following changes were made in this release:

  • A long connection

PersistentConnection supports Pipelining processing, which enables multiple HTTP requests and responses to be transmitted over a TCP Connection, reducing the cost and latency of establishing and closing connections. Keep-alive, HTTP1.0 should be set by itself

  • Support response block, added 24 error status response codes
  • More cache control policies have been introduced
  • Introduce content negotiation mechanisms, including language, encoding, type, etc., and allow the client and server to agree to exchange the most appropriate content
  • Host + port, which specifies the specific site to access. Different domain names can be configured on the server with the same IP address.

So how can browsers improve page loading efficiency in the AGE of HTTP/1.1? There are two main points:

  • Maintains an established TCP connection with the server and processes multiple requests sequentially over the same connection.
  • Multiple TCP connections are established with the server.
3. HTTP /1.x defects
  • A single TCP connection can only handle one request at a time

This means that the start to end times of any two HTTP requests cannot overlap in the same TCP connection.

Pipelining is specified in the HTTP/1.1 specification to address this problem, but it is turned off by default in browsers

About Pipelining:

A client that supports persistent connections MAY “pipeline” its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. A client that supports persistent connections can send multiple requests within a connection (without waiting for a response from any request). The server receiving the request must send the response in the order the request was received.

But here’s the problem:

Because HTTP/1.1 is a text protocol, and the content returned does not distinguish which request to send, the order must be consistent. What if you send two GET/query requests to the server? Q = A and GET/query? Q =B, the server returns two results, and there is no way for the browser to determine which one the response corresponds to.

Pipelining looks like a good idea, but there are many problems in practice:

  • Some proxy servers cannot handle HTTP Pipelining correctly.
  • Proper pipelining implementation is complex.
  • Head of line Blocking: After establishing a TCP connection, suppose that the client sends several consecutive requests to the server on that connection. By standard, the server should return the results in the order it received the requests, assuming that the server took a lot of time to process the first request, then all subsequent requests would have to wait for the first request to end.

So HTTP Pipelining is not enabled in modern browsers by default.

SPDY protocol

Due to HTTP/1.x issues, we introduced Sprite images, inlining small images, using multiple domain names, and so on to improve performance. These optimizations circumvented the protocol, however, until 2009, when Google unveiled its own SPDY protocol to address HTTP/1.1 inefficiencies. With SPDY, Google is officially reinventing HTTP itself. Reducing latency, compressing headers, and so on proved effective with SPDY, which eventually led to the birth of HTTP/2.

The SPDY protocol has been used as the basis for HTTP/2 since it was proven to work in Chrome, and major features are inherited in HTTP/2.

4. HTTP/ 2-SPDY upgrade

In 2015, HTTP/2 was released. HTTP/2 is a replacement for the current HTTP protocol (HTTP/1.x), but it is not a rewrite. HTTP methods/status codes/semantics are the same as HTTP/1.x. HTTP/2 is based on SPDY3 and is focused on performance. One of the biggest goals is to use only one connection between the user and the site.

HTTP/2 as an upgraded version of SPDY and SPDY, the main differences are:

  • HTTP2.0 supports plaintext HTTP transport, while SPDY enforces the use of HTTPS
  • The HTTP2.0 header compression algorithm uses HPACK rather than DEFLATE, which is used by SPDY
  • Improved agreement negotiation and confirmation process
  • .

(b) New features of HTTP2.0 compared to Http1.x

  1. Binary rather than text protocols introduce the concept of binary data frames and streams.
  2. Following multiplexing, instead of content under the same host, only one connection is established. Parallel requests can be processed within the same link, removing the order and blocking constraints of HTTP/1.x

Http/1. X will send any request. Http/1. Allows the server to pre-push resources needed for a web page into the browser’s memory

H2’s excellent performance realization, let’s take a famous example:

HTTP 1. X and HTTP/2 http2.akamai.com/demo

How to upgrade HTTP /2 from HTTP /1?

HTTP2.0 can support non-HTTPS, but now mainstream browsers like Chrome, Firefox, or only support TLS deployment of HTTP /2 protocol, so to upgrade to HTTP /2 or HTTPS first

After upgrading to 2.0, just launch the corresponding protocol directly in the NgniX profile

(4) defects

Only one TCP connection is required under the same domain name. However, packet loss occurs in this connection. The entire TCP starts to wait for retransmission, which blocks all subsequent data. This blocking caused by a single packet is also known as queue head blocking on TCP

In the case of HTTP/1.1, however, multiple TCP connections can be opened, so that only one of them is affected, and the remaining TCP connections can still transmit data

This is due to the underlying TCP protocol, but TCP has been around for so long that it is ubiquitous on all kinds of devices, and the protocol is implemented by the operating system, which makes changing it impossible.

So the problem of TCP squadron head blocking is not solved completely

HTTP/3 – Start all over again

Google was aware of these problems when they launched SPDY, so they created a “QUIC” protocol based on UDP (User Datagram Protocol) that takes the essence of TCP and makes HTTP run on QUIC instead of TCP.

With QUIC, a connection is still established between the two ends, and the connection is negotiated so that data can be transmitted safely and reliably. When we create two different data streams on this connection, they are independent of each other. That is, if a data stream loses a packet, only that data stream must stop and wait for retransmission.

It is expected to completely solve the problem of queue head congestion

However, there are currently no major browsers in any state of any version that support IETF (Note 4) versions of QUIC or HTTP/3.

Although Google Chrome has supported the Google version of QUIC for several years, most of the new implementations under development have decided to focus on the IETF version and are not compatible with the Google version.

reference

note

Persistent connection Non-servers automatically disconnect after returning resources. A persistent connection is held until it receives a notification indicating that the connection is closed. Most of the resources on a page can be transferred over a single TCP link. This greatly reduces the performance loss caused by multiple TCP connections.

2. Slow start To avoid flooding the network with unprocessed packets, TCP uses a warm-up delay called “slow start” for established connections to give the TCP blocking control algorithm a determination of how much data can be transferred, rather than sending all pending data as soon as possible after the connection is established. Because each new connection must go through this slow startup process, this can also be a bottleneck for network performance.

LoadTimes () outputs connectionInfo and npnNegotiatedProtocol as h2, indicating http2 is used

4. IETF International Internet Engineering Task Force. HTTP is a collaboration between THE IETF and the World Wide Web

data

HTTP Overview analysis of Chrome Waterfall

HTTP