preface

HTTP/1.1 already covers most of the needs of the Internet, but there’s a lot of room for optimization, so HTTP/2 is here.

It is important to note that HTTP/2 is not HTTP/2.0, as the HTTP/2 Working Group felt that the previous “HTTP/1.0” and “HTTP/1.1” created a lot of confusion and misunderstanding. So it was decided that the HTTP protocol would no longer use small version numbers and only use large version numbers.

HTTP / 2 new features

The head of compression

Why head compression

In HTTP/1 we can use the field “content-encoding” to specify how the body is encoded to compress the body Content and save bandwidth. But in fact, in some common situations in development, such as GET request and 204/301/304 response, body usually has only dozens of bytes, while Header usually carries many fixed Header fields such as “User Agent”, “Cookie”, “Accept” and “Server”. Hundreds or even thousands of bytes. In thousands of request and response packets, many field values are repeated, which is very wasteful. The “long tail effect” leads to a large amount of bandwidth consumption on these highly redundant data. So HTTP/2 focuses on “header compression” as a performance improvement.

How do I compress the head

HTTP/2 developed a special “HPACK” algorithm, at both ends of the client and server to establish a “dictionary”, with the index number to represent the repeated string, but also use Huffman coding to compress the integer and string, can reach 50%~90% of the high compression rate.

Binary format & multiplexing

Why binary format

HTTP/1 uses plain text packets. Its advantage is that it is easy to develop and debug with the simplest tools. But in the computer analysis of the original use of pure text when easy to appear polysemy, such as case, blank characters, carriage return line feed, more words less words and so on, the program must be processed with complex state machine, low efficiency, but also trouble. And binary only “0” and “1”, can strictly define the field size, order, flag bit format, parsing up no ambiguity, simple implementation, and small size, fast speed, do “internal efficiency”.

Binary format concrete implementation

The previous HTTP/1 “Header+Body” message is “smashed” into a number of small binary “frames”. The “HEADERS” frame is used to store the Header DATA and the “DATA” frame is used to store the entity DATA.

These binary “frames” are transmitted to their destination through a stream, a concept of HTTP/2 that you can think of as a virtual “data stream” in which a sequence of data frames flows, which are assembled into HTTP/1 request and response messages.

Because streams are virtual and do not actually exist, HTTP/2 can use streams to send multiple “fragmented” messages simultaneously over a TCP connection. This is often referred to as “multiplexing” — multiple round-trip traffic is multiplexed over a single connection.

At the “flow” level, messages are ordered sequences of “frames”, while at the “connection” level, messages are out-of-order “frames”. There is no sequential relationship between multiple requests/responses, so there is no need to queue, and the problem of “queue head blocking” will not occur, which reduces latency and greatly improves connection utilization. HTTP/2 also adds control frames to manage virtual “flows”, enabling priority and flow control.

Server push

HTTP/2 also changes the traditional “request-response” mode to some extent. Instead of responding to requests completely passively, the server can create a “flow” to actively send messages to the client. For example, when the browser just requests HTML, it sends the JS and CSS files that may be used to the client in advance to reduce the delay of waiting, which is called “server push”.

Nginx sets server push

location / {
   http2_push /style.css
   http2_push /test.png
}
Copy the code

Strengthen the security

Usually HTTP/2 is encrypted. In other words, HTTP/2 commonly seen on the Internet uses the protocol name “HTTPS”, running on TLS.

To distinguish between “encrypted” and “plaintext” versions, the HTTP/2 protocol defines two string identifiers: “H2” for encrypted HTTP/2, “H2C” for plaintext HTTP/2, and the extra letter “C” for “clear text.”

HTTP / 2 faults

  • In the case of IP address switching in the mobile network, the lower LAYER TCP must be re-connected to “shake hands” again and undergo “slow start”. In addition, the HPACK dictionary accumulated in the previous connection has disappeared and the calculation must be started from the beginning, resulting in bandwidth waste and delay.
  • HTTP/2 only makes one connection to a domain name, so if that connection goes wrong, the whole site experience deteriorates.

How do I configure HTTP/2

Configure HTTP/2 with Nginx based on HTTPS

Server {// enable SSL encryption on port 443, and then enable HTTP/2 LISTEN SSL http2; server_name www.xxx.net; ssl_certificate xxx.crt; ssl_certificate_key xxx.key;Copy the code

How does the browser know that the server is communicating using HTTP/2?

When a client initiates a connection handshake, it is followed by an “ALPN” extension, which lists the application protocols supported by the client in priority order. As shown in the figure below, “H2” has the highest priority, followed by “HTTP /1.1”. When the server sees the ALPN extension, it selects an application protocol from the list and responds with the “ALPN” extension, telling the client which one the server has decided to use. Since we use THE HTTP/2 protocol in our Nginx configuration, it selects “H2” here.

HTTP / 3

HTTP/2 does not solve the problem

Team head block

After HTTP/2 breaks multiple “request-response” streams into TCP, TCP breaks them into smaller packets and sends them one by one.

Suppose the client sends three packets using TCP, but the server’s operating system only receives the last two packets. The first packet is lost. What does TCP do?

To ensure reliable transmission, TCP has a special “packet loss and retransmission” mechanism. Lost packets must wait for retransmission confirmation. Other packets can only be stored in the buffer even if they have been received. So the new features of HTTP/3 come out.

HTTP/three new features

HTTP/3 is essentially “HTTP over QUIC”.

What is QUIC protocol? QUIC is a transport layer protocol, using UDP, because UDP is unordered, there is no dependency between packets, so it fundamentally solves the “queue head blocking”. And the TCP that a set of connection management, congestion window, flow control and so on “moved” over, “to its dross, take its essence”, to create a new reliable transmission protocol, can be considered as “the new era of TCP”.

QUIC features:

  • QUIC is based on UDP, which is “connectionless” and requires no “handshake” or “wave” at all, so connections are faster than TCP.
  • QUIC implements reliable transmission based on UDP to ensure that data can reach the destination. Following HTTP/2 “streams” and “multiplexing”, individual “streams” are ordered and may block due to packet loss, but other “streams” are not affected.
  • QUIC uses encrypted communication across the board

The last

Thank you for reading, if you have any questions please correct!