There aren’t many HTTP 2.0 interview questions, but there are plenty of applications based on HTTP 2.0, such as Google’s gRPC framework for efficiency. At the same time, many of the flaws in HTTP 1.0 have been addressed in HTTP 2.0.

So it’s important to understand HTTP 2.0 if you excel in the interview process and have a better understanding of the implementation of frameworks like gRPC in practice. HTTP 2.0 is also replacing HTTP 1.0 in many scenarios.

Problems with HTTP 1.0

Once you look at the HTTP 1.0 protocol implementation, you’ll see that it has a number of problems.

Problem 1: TCP connection number limit. To avoid network congestion, excessive CPU and memory are occupied. Therefore, different browsers limit the number of TCP connections.

Problem two: queue head blocking problem. Each TCP connection can process only one HTTP request at a time. The browser follows the FIFO principle. If the previous TCP connection does not return a request, the subsequent request will be blocked.

Pipelining has been proposed, but there are still many problems. For example, a slow first response will still block subsequent responses; The server needs to cache multiple responses in order to return, consuming more resources. The server may have to reprocess multiple requests if the browser disconnects and retries. There must also be client-proxy-server support for pipelining.

Problem three: Header content is too much, each time need to send repeatedly, there is no corresponding compression transmission optimization scheme;

Problem 4: In order to reduce the number of requests, it is necessary to do optimization work such as file merging, but at the same time, it will increase the delay of a single request;

Problem five: plaintext transmission is not secure;

The advent of HTTP 2.0

RFC 7540 defines HTTP 2.0 protocol specifications and details for HTTP 1.0 issues. The implementation of HTTP 2.0 is based on some standards of the SPDY protocol.

HTTP 2.0 provides optimizations for binary framing, header compression, multiplexing, request prioritization, server push, and more.

HTTP 2.0 is a next-generation Internet communication protocol formed on The basis of SPDY (An experimental protocol for a Faster Web, The Chromium Projects). HTTP/2 aims to reduce latency by enabling request and response multiplexing, reducing protocol overhead by compressing HTTPS header fields, and increasing request priority and server-side push support.

What is the SPDY protocol

SPDY is an application layer protocol based on TCP protocol developed by Google. The goal is to optimize the performance of the HTTP protocol to reduce load times and improve security of web pages through compression, multiplexing, and prioritization. The core idea of the protocol is to minimize the number of TCP connections. SPDY is not intended as an alternative to HTTP, but rather an enhancement of the HTTP protocol.

Internet Engineering Task Force (IETF) standardized SPDY protocol proposed by Google and launched HTTP 2.0 protocol standard similar to SPDY protocol (REFERRED to as HTTP/2) in May 2015. Google therefore announced that it was dropping support for the SPDY protocol in favor of HTTP/2.

Here’s a closer look at the new features HTTP 2.0 offers.

Binary Framing Layer

How can HTTP 2.0 overcome HTTP 1.1’s performance limitations, improve transport performance, and achieve low latency and high throughput without affecting HTTP1.x? One of the keys is to add a binary framing layer between the application layer (HTTP) and transport layer (TCP). The binary framing layer is at the heart of HTTP 2.0 performance enhancements.

While HTTP 1.1 communicates in plain text at the application layer, HTTP 2.0 divides all transmitted information into smaller messages and frames and encodes them in binary format. At the same time, both clients and servers need to introduce new binary encoding and decoding mechanisms. As shown in the figure below, HTTP 2.0 does not change the semantics of HTTP 1.x, but uses binary framing at the application layer.

There are three concepts related to binary framing: frames, messages, and streams.

Frame: The smallest unit of HTTP 2.0 communication. All frames share an 8-byte header that contains the frame’s length, type, flag, one reserved bit, and at least an identifier that identifies the stream to which the current frame belongs. Frames carry certain types of data, such as HTTP headers, loads, and so on.

+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) . +---------------------------------------------------------------+Copy the code

Frame-based, with binary transmission instead of plaintext transmission, the original message message is divided into smaller data frames:

At the binary framing layer, HTTP 2.0 divides all transmitted information into smaller messages and frames and encodes them in binary format, where the HTTP 1.1 header information is encapsulated in the Headers frame and the Request Body in the Data frame.

Message: A unit of communication larger than a frame, which is a logical HTTP message (request/response), consisting of a series of data frames that form a complete message. For example, a sequence of DATA frames and a HEADERS frame compose the request message. Consists of one or more frames.

Flow: a unit of communication larger than a message. It is a virtual channel in a TCP connection that can carry two-way messages. Each stream has a unique integer identifier.

To prevent traffic ID conflict between the two ends, the flow initiated by the client has an odd ID, and the flow initiated by the server has an even ID. All HTTP 2.0 traffic is done over a single TCP connection that can host any number of two-way data streams. Accordingly, each data stream is sent as a message, which consists of one or more frames that can be sent out of order and then reassembled according to the stream identifier at the beginning of each frame.

The binary framing layer preserves HTTP semantics, including headers, methods, etc., and is no different from HTTP 1.x in terms of application layer. At the same time, all communication with the host can be done over a TCP connection.

  • The mode of single connection and multiple resources reduces the connection pressure of the server, occupies less memory, and has higher connection throughput.
  • Network congestion is improved due to the reduction of TCP connections, and the slow start time is reduced so that congestion and packet loss recovery is faster.

MultiPlexing

Multiplexing allows multiple request-response messages to be sent simultaneously over a TCP connection. The message is composed of frames, and the data of each frame is marked with the flow (StreamID). When received, the other party splice the data of all frames of each stream according to the flow ID to form a complete piece of data. This is HTTP/2 multiplexing.

The concept of flow enables multiple request-response parallelism on a single connection, solves the problem of “Head of line blocking”, and reduces the number of TCP connections and slow start of TCP connections. Therefore, HTTP/2 requires only one connection for the same domain name, instead of six to eight connections like HTTP/1.

Note that data of different streams can be sent interleaved, but data of the same stream can only be sent sequentially.

Server Push

The client sends a request, and the server returns multiple responses in advance so that the client does not have to make subsequent requests. That is, in HTTP/2, the server can send multiple responses to a single request from the client. The server pushes resources to the client without explicit request from the client.

Stream 2(/script.js) and Stream 4(/style.css) :

If a request is sent from the home page, the server may respond with the home page content, logo, and style sheet because it knows the client will use them. This not only reduces data transfer redundant steps, but also speeds up page response and improves user experience.

Server push is mainly optimized for resource inlining. Compared with HTTP/1.1, server push has the following advantages:

  • The client can cache pushed resources.
  • The client can reject pushed resources;
  • Push resources can be shared by different pages;
  • The server can push resources according to priority;

Disadvantages of push: All pushed resources must comply with the same origin policy. In other words, the server cannot just push third-party resources to the client, but only after the confirmation of both parties.

The Header compression (HPACK)

HTTP/1.1 does not support HTTP header compression, hence SPDY and HTTP/2. SPDY uses a generic algorithm, while HTTP/2 uses an algorithm designed specifically for header compression (the HPACK algorithm).

The HTTP protocol is stateless, and every request must be accompanied by all the information (describing the properties of the resource), retransmitting data in hundreds or even thousands of bytes. Therefore, many request header fields are repeated, such as cookies. The same content must be attached to each request, which will waste a lot of bandwidth and affect the speed.

In fact, you only need to send the same header once. HTTP/2 optimizes this by introducing header compression. On the one hand, the header information is compressed using gzip or COMPRESS and then sent. On the other hand, both the client and the server maintain a header table where all fields are stored, producing an index number, and then don’t send the same field, just the index number.

Request priority

By dividing HTTP messages into many individual frames, you can further optimize performance by optimizing the interleaving and transmission order of these frames. Dependencies and weights can be set for each Stream in HTTP/2, and priority can be assigned by Dependency tree, eliminating the problem of critical requests being blocked.

Reset connections at the application layer

For HTTP/1, the remote end is notified to close the connection by setting a reset flag in the TCP segment. In this way, the connection is disconnected and must be re-established the next time a request is made. HTTP/2 introduces a frame of type RST_STREAM, which can do a better job of canceling a request stream if the connection is constantly open.

Flow control

TCP uses the sliding window algorithm to control traffic. The sender has a Sending Window and the receiver has a Receive Window. HTTP/2 flow control is similar to Receive Window, in that the data receiver notifies the other party of the size of the flow Window in bytes, indicating how much data can still be received. Only frames of Data type have flow control.

In this way, you can restrict the other end from sending data. For each stream, each end must tell the other that it has enough room to process new data, and the other end is only allowed to send so much data until the window is enlarged.

summary

Every new protocol requires a process of adoption, and HTTP/2 is no exception. Fortunately, it is an upper-layer protocol and only adds a layer between HTTP/1 and TCP, so it is bound to be used gradually. Now that you know these new features of HTTP/2, you can probably see why more and more browsers and middleware are adopting HTTP/2. Because it’s really efficient and worth learning and using.

About the blogger: Author of the technology book SpringBoot Inside Technology, loves to delve into technology and writes technical articles.

Public account: “program new vision”, the blogger’s public account, welcome to follow ~

Technical exchange: Please contact the weibo user at Zhuan2quan