Introduction:
The main design ideas of HTTP/2 are probably derived from Google’s SPDY protocol, which was standardized by the Internet Engineering Task Force (IETF). Let’s dive right into the new features of HTTP/2 and compare them to HTTP/1.x.
One, multiplexed single long connection
1. Single long connection
In HTTP/2, when a client requests a page from a server of a domain name, only one TCP connection is created, even though the page may contain hundreds of resources. Prior HTTP/1.x typically created 6-8 TCP connections to request these 100 + resources. A single connection should be the main advantage of HTTP2, as it can reduce the latency associated with TCP handshakes (if built on SSL/TLS, HTTP2 can reduce unnecessary SSL handshakes.
And we also know that TCP has a sliding window, which is slow start, which means that every time a new connection is made, data is slowly transmitted, and then the sliding window gets bigger, so it can be transmitted at a higher speed, which is good, the sliding window of this connection just got bigger, Http1.x creates a new connection to send data (it’s like someone else’s HTTP2 is always running on the highway, and you’re http1.x is a stop-and-go bus). For this reason, HTTP connections that are inherently abrupt and short become very inefficient.
Therefore, HTTP2 uses a single long connection to avoid the network overhead of creating multiple TCP connections and improve throughput.
2. Multiplexing
It’s a connection, but how can it be multiplexed? Backend developers should be familiar with multiplexing, such as using SELECT,poll, and epoll to manage a stack of FDS, where HTTP2 has only one TCP connection but is logically divided into streams. Again, this is a key feature. Let’s take a look at this online loan.
Photo: www.360doc.com/content/16/…
What does http1.x do in the past? Multiple requests can only be executed sequentially over a TCP connection! You say our current network bandwidth is so large, isn’t it a waste? Http2, by contrast, throws no matter how many requests there are into the connection, which can significantly reduce the load time of a page.
How does HTTP2 multiplexing work? For example, if you look at the highway, there is only one road, but there are many tolls.
HTTP2 divides the information to be transmitted into binary frames. The HEADER information is encapsulated in the HEADER Frame, and the corresponding request body is placed in the DATA Frame. A Frame can be viewed as a car on the road. This differentiates the different HTTP requests or responses. However, it is required that the same request or response frames must be ordered and FIFO must be guaranteed, but different request or response frames can be interspersed with each other. This is the multiplexing of HTTP2, does it take full advantage of network bandwidth, does it improve concurrency?
Further, HTTP2 can assign priority to these streams (lanes). The priority can be dynamically changed, such as setting CSS and JavaScript files to a higher priority than images, so that code files can be downloaded and executed more quickly.
Now let’s look at the difference between http1.x and HTTP2 in the process of requesting a page with dozens or hundreds of resources, as shown in the following figure:
Http1.x establishes 6 to 8 TCP connections, one by one with the serial execution of the eight connections, and http2 can send all the requests at once, or compressed, whether or not to determine.
Second, header compression and binary format
Http1.x has always been plain text, and I can only think of one advantage, ease of reading and debugging. However, now that many use HTTPS and SSL has changed plain text to binary, this advantage is gone.
HTTP2 uses an HPACK compression to compress the header and reduce the packet size (debugging such a protocol will require a tool like curl, and further analysis of the network data flow will require an HTTP2 parser like Wireshark). For example, method: GET corresponds to a value of index 2 in the index table. However, there are still some uncertainties in the header, such as the browser name corresponding to the user-agent.
So it also maintains a dynamic index table. The static index is 2-61. When a user-agent Mozilla/5.0 is found during data transfer, it appends this to the dynamic index table where the index is 62. This time, the user-agent Mozilla/5.0 was replaced with 62 at the beginning, so the dynamic index table was built gradually during the data transfer process, and the static index table was written to death.
In addition, HPACK uses Huffman coding to compress something as completely uncertain as the resource path, so that all three can be combined to reduce the header content significantly. Take a look at the HPACK schematic below:
Why does the head need to compress?
There are some duplicates in every HTTP request, such as method: GET. When a client requests resources (such as images for a page) from the same server, the requests appear almost identical. And that mass of consistency is just worth squeezing.
In addition, HTTP 1.1 requests become larger and larger, sometimes larger than the initial size of the TCP window, which can significantly slow down the delivery of requests. Because they need to wait for the ACK response to come back before they can be sent again. In particular, when HTTP requests exceed the maximum size of TCP packets, they are divided into several TCP packets. In this case, compression reduces the number of TCP packets and reduces the RTT time.
In turn, header compression costs CPU, and it doesn’t help if the header can fit inside a TCP packet. In addition, the body of most response messages is much larger than the header, so it is unnecessary to compress the header.
3. Server Push
This feature is often referred to as “cache push.” The main idea is that when a client requests resource X and the server knows that it probably also needs resource Z, the server can proactively push resource Z to the client before the client sends the request.
This feature helps clients cache Z for future use. Server push requires the client to explicitly allow the server to provide this functionality. Even so, the client can choose whether to interrupt the stream of the push. If not, the client can abort by sending an RST_STREAM frame.
These are some of the major new features of HTTP (there are many more that I won’t go into here). Last but not least, it seems that browsers only use HTTP2 if the server supports it and uses SSL. To summarize, why does HTTP2 eliminate SSL’s overhead on http1.x?
1. A single long connection reduces the overhead of the SSL handshake
2. The header is compressed, reducing data transmission
3. Multiplexing can greatly improve transmission efficiency without waiting for the response of the last request
4. Don’t likehttp1.xIn this way, multiple files or resources are grouped into one file or resource (http1.xThe cache will be easier to hit.http1.xHow does the thing you scrunched up inside hit the cache?
Wow.. Writing articles is really tiring. However, I will write another nginx article about how to deploy HTTP2 and do some experiments to test the performance of http2.