In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)06/03 Report--
HTTP/2 is the first update of HTTP protocol since HTTP 1.1 was released in 1999, which is mainly based on SPDY protocol. It is developed by the Hypertext Transfer Protocol Bis (httpbis) working group of the Internet Engineering Task Force (IETF). The organization submitted the HTTP/2 standard proposal to IESG for discussion in December 2014 and was approved on February 17, 2015. The HTTP/2 standard was officially published as RFC 7540 in May 2015.
So what are the specific changes in HTTP/2?
Binary framing
Let's first understand a few concepts:
Frame: the smallest unit message for HTTP/2 data communication: refers to the logical HTTP message in HTTP/2. For example, request and response, the message consists of one or more frames.
Stream: a virtual channel that exists in a connection. Streams can host two-way messages, and each stream has a unique integer ID.
HTTP/2 transmits data in binary format instead of HTTP 1.x text format, and binary protocols are more efficient to parse. The request and response messages of HTTP / 1 are composed of the starting line, the header and the entity body (optional), and the parts are separated by text newlines. HTTP/2 divides the request and response data into smaller frames, and they are binary encoded.
In HTTP/2, all communication under the same domain name is completed on a single connection, which can carry any number of two-way data streams. Each data stream is sent in the form of a message, which in turn consists of one or more frames. Multiple frames can be sent out of order and can be reassembled according to the flow identification at the beginning of the frame.
Multiplexing
Multiplexing replaces the original sequence and blocking mechanism. All requests are done concurrently through a TCP connection. In HTTP 1.x, if you want to concurrently multiple requests, you must use multiple TCP links. In order to control resources, browsers also have a limit of 6-8 TCP link requests for a single domain name. As shown in the figure below, requests circled in red are suspended for a period of time because the number of domain name links has exceeded the limit:
In HTTP/2, with binary framing, HTTP/2 no longer relies on TCP links to achieve multi-stream parallelism, in HTTP/2:
All communications under the same domain name are completed on a single connection.
A single connection can carry any number of two-way data streams.
The data stream is sent in the form of a message, which in turn consists of one or more frames, which can be sent out of order because they can be reassembled according to the flow identification at the beginning of the frame.
This feature has greatly improved performance:
Only one TCP connection is required for the same domain name, which eliminates the latency and memory consumption caused by multiple TCP connections.
Requests and responses that can be staggered in parallel on a single connection without interference with each other.
In HTTP/2, each request can have a priority value of 31bit. 0 represents the highest priority, and the higher the number, the lower the priority. With this priority value, clients and servers can adopt different strategies when dealing with different streams, sending streams, messages, and frames in an optimal way.
Server push
The server can actively push other resources when sending the page HTML, instead of waiting for the browser to parse to the appropriate location, initiating a request and then responding. For example, the server can actively push JS and CSS files to the client without requiring the client to send these requests when parsing the HTML.
The server can push actively, and the client also has the right to choose whether to receive it or not. If the resource pushed by the server has been cached by the browser, the browser can reject it by sending a RST_STREAM frame. Active push also follows the same origin policy, and the server will not casually push third-party resources to the client.
Head compression
The size of HTTP 1.1requests becomes larger and larger, sometimes even larger than the initial size of the TCP window, because they need to wait for the response with ACK to come back before they can continue to be sent. HTTP/2 uses HPACK (a compression format specially designed for http/2 headers) to compress and transmit the message header, which can save the network traffic occupied by the message header. However, every time HTTP/1.x requests, it will carry a lot of redundant header information, which wastes a lot of bandwidth resources.
HTTP carries a set of headers for each communication, describing the resources, browser properties, cookie, and so on, of the communication, such as
To reduce resource consumption and improve performance, HTTP/2 has adopted a compression strategy for these headers:
HTTP/2 uses "header tables" on the client and server to track and store previously sent key-value pairs. For the same data, it is no longer sent through each request and response.
The header table always exists during the connection life of the HTTP/2, and is updated gradually by the client and server together.
Each new header key-value pair is either appended to the end of the current table or replaces the previous value in the table.
For example, in the two requests in the following figure, the first request sends all the header fields, and the second request only needs to send differential data, which can reduce redundant data and reduce overhead.
Let's take a look at a practical example. Here is a package that visits the google home page crawled with WireShark:
The image above shows the header of the first request captured by the access https://www.google.com/. You can see the contents of the header, which takes up a total of 437 bytes. When we select the cookie of the header, we can see that the cookie takes up 118 bytes. Next, let's look at the header of the second request:
As you can see from the figure above, thanks to header compression, cookie only occupies 1 byte in the second request. Let's take a look at the changed Accept field:
Because the Accept field is different from the content in request 1 and needs to be sent to the server, it takes up 29 bytes.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.