HTTP2.0 Principle Detailed

There are two main factors that affect a network request, bandwidth and latency. Today's network infrastructure has greatly improved bandwidth, and most of the time latency is impacting response speed. Connection NOT REUSABLE

A connection that cannot be reused causes each request to experience three handshake and slow boot. The three-time handshake is more noticeable in high-latency scenarios, and slow booting has a large impact on file class requests. Head of line blocking

Head of line blocking can cause bandwidth to be underutilized, and subsequent health requests are blocked.

HTTP1.0-HTTP1.1

But pipelining is not the savior, it also has many flaws:

• Pipelining can only be applied to http1.1, in general, servers that support http1.1 require support pipelining

• Only idempotent requests (Get,head) can use pipelining, and non-idempotent requests such as Post cannot be used because there may be successive dependencies between requests.

• The head of line blocking is not fully resolved, and the server's response is still required to return in turn, following the FIFO (first first out) principle. That is, if the request 1 response not come back, 2,3,4,5 response will not be sent back.

• The vast majority of HTTP proxy servers do not support pipelining.

• There is a problem with the old server negotiation that does not support pipelining.

• May cause new front of queue blocking issues.

HTTP2 VS HTTP1.1 Multiplexing

Multiplexing addresses the problem of http1.x Holb (head of line blocking) by sharing a TCP connection over multiple request streams, reducing latency while increasing bandwidth utilization.

Compression Head

HTTP/2.0 specifies that the "Header table" will be used and maintained on both the client and server side to track and store the previously sent key-value pairs, and for the same header, it is not necessary to send by request again, just once.

In fact, if the request does not contain a header (for example, a polling request for the same resource), the first overhead is 0 bytes. At this point all headers are automatically used before the request is sent.

If the header changes, then only the changed data is sent to the headers frame, and the new or modified header frame is appended to the "Header table". The first table is always present during the lifetime of the HTTP2.0 connection, and is incrementally updated by both the client and the server.

Binary Sub-frame

A binary sub-frame layer is added between the application layer and the transport layer to "break the HTTP1.1 performance limit, improve transmission performance, and achieve low latency and high throughput without altering the semantics of HTTP, HTTP methods, status codes, URIs, and header fields." ”

On the binary sub-frame layer, HTTP2.0 divides all the transmitted information into smaller messages and frames, and encodes them in binary format, where http1.x header information is encapsulated into the headers frame, and our request body is encapsulated in the data frame.

The client and server can decompose HTTP messages into non-dependent frames, send them out of order, and then regroup them at the other end. Note that there are multiple streams of traffic in different directions on the same link. The client can either send the stream in a random order, or it can respond to the recipient server, and the server side is the same.

Request priority

Multiplexing causes all resources to be sent in parallel, so the concept of "priority" is needed so that important files can be transferred first, accelerating the rendering of the page. Server push

A server push is a mechanism for sending data before a client requests it.

It is also worth noting that if a client exits a business scenario, it needs to cancel server push for traffic or other reasons, or it can do so by sending the Rst_stream type of frame. HTTP2 Practice

This uses node. js as the server-side language. 1. Generate a TLS certificate

If you want to use HTTP2 in a production environment, you can go here to generate a certificate.

If you only use the development environment, then we can generate a self-signed TSL certificate ourselves.

1. Installing OpenSSH

2. To generate a private key using OpenSSH

   openssl genrsa -des3 -passout pass:1234 -out server.pass.key 2048`

   Here 1234 is the private key password, if you do not want to use the password, you can remove the private key password, typing the following chitian:

   openssl rsa -passin pass:x -in server.pass.key -out server.key

3. Create a certificate signing request
   There is no password private key, if you use the private key with a password, just server.key replace it server.pass.key , Chitian as follows

   openssl req -new -key server.key -out server.csr

4. Create a certificate

   openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

With the above four steps, we got three files

1. server.key your TSL certificate private key

2. SERVER.CSR your TSL certificate signing request

3. server.crt your TSL certificate

2. Create a server using node. js

Installing the NODE-HTTP2 module

npm install http2

Creating a server

var options = {  key: fs.readFileSync(‘./server.key‘),  cert: fs.readFileSync(‘./server.crt‘)};require(‘http2‘).createServer(options, function(request, response) {  response.end(‘Hello world!‘);}).listen(8080);

Start the server

node index.js

Access using a browser

http://localhost:8080

Here, a simple demo is done. Demo Source Download

Click here to access the full demo

Https://github.com/zhanyouwei ... Comparison of test results

Through the above two can be found that the use of HTTP2, the same request, the data transmission size and speed have a very large increase, almost predictable, in the near future, HTTP2 will shine.

HTTP2.0 Principle Detailed