HTTP is an application layer protocol of computer network. Currently, the general version is 1.1, and the latest version is 2.
The first thing we need to know is that a protocol is a specification that both sides follow, in this case the client and the server. A protocol is just a piece of text, it’s not a piece of software that works. For an agreement to take effect, it must have the support of both sides, which is implementation.
To understand the protocol and implementation, take a look at an example. For example, if you want to produce a new type of water cup, you write a specification document for the cup, specifying the size, material, surface coating and pattern of the cup, etc. This specification document is the agreement, and then you take the document to the factory that produces the cup, and ask the factory to produce the actual cup for you according to the specification document, and this cup is the concrete implementation.
As can be seen from the above examples, concrete implementation is the soil where agreements can exist. The client is usually implemented by a browser, such as the commonly used Chrome browser, and the server is implemented by a Web server, such as Apache.
Everything has a process and a reason for it, which is not covered here in previous versions of HTTP/1.1. In 2009, more than a decade after HTTP/1.1 was officially released in 1997, Google invented a protocol called SPDY that attempted to replace HTTP/1.1. Why would Google create its own protocol when it doesn’t use HTTP/1.1? Because HTTP/1.1 based clients and servers are too slow to transfer files. SPDY is pronounced Speedy, and the goal is to be at least 50% faster than HTTP/1.1. Since SPDY is so good, of course it should be included in the standard. Since 2012, the HTTP specification working group has been working on the HTTP/2 specification until 2015, when the HTTP/2 standard specification was published.
HTTP2 differs from HTTP1.1 in several major ways.
- Head compression.
- Server push.
- Binary format transmission.
- Multiplexing.
The head of compression
Many header fields in HTTP requests are repetitive or even unnecessary, but they are still included in each request, such as Cookie, user-agent, Host, and Accept. These fields are usually not changed in the same network session, but are sent repeatedly. The same is true for the response header. Especially for some small requests, header fields may account for a large proportion of the entire network packet. HTTP/1.1 supports compression of the request body, but not the request header. HTTP/2 makes up for this shortcoming.
server push
Server push is when the server sends static resources to the client without request. In HTTP/1.1, to request a page, first request HTML files, then request CSS files, JavaScript files, images, font files and other static resources based on the HTML content, which can consume a lot of time. Through the server push function of HTTP/2, all other static resources of the response can be sent to the client in parallel when the HTML file is responded for the first time, which greatly saves the time of network transmission and accelerates the speed of page display.
Binary format transfer
HTTP/1.1 transmits text-based messages that are human-friendly but machine-unfriendly. Text itself is not a kind of structured information, and parsing it is relatively inefficient; In contrast, HTTP/2 transmits a binary message, which is not human-friendly but machine-friendly, and is a structured form of information. HTTP/2 abstracts a pair of independent HTTP requests/responses into a Stream consisting of several frames. Each frame consists of several bytes, and the bytes or groups of bytes are partitioned to give them different semantics. For example, the first three bytes define the length of the frame Paylad in bytes, the fourth byte defines the type of the frame, and the fourth byte defines the unique identifier of the Stream. Of course, the main number of bytes is the payload that actually carries the information that’s going to be transmitted. In this way, each request/response is composed of several frames. Each frame corresponds to a unique Stream, and its corresponding sequence in the Stream pair is recorded, which facilitates packet assembly after the client/server receives all frames.
multiplexing
Because of the frame frame, multiplexing is possible. Each TCP connection can simultaneously transmit multiple streams in parallel, greatly improving the transmission efficiency of the TCP connection.
HTTP/2 network messages can only be transmitted in HTTPS for two reasons
- Use HTTPS for transport, which is backward compatible with the infrastructure currently on the Internet. Because HTTPS is encrypted, HTTP/2 frame information can be hidden, and middleware and proxy servers on the Internet can directly forward information. If it is sent over HTTP, servers over the Internet cannot understand the binary data format of HTTP/2 when looking up information in network packets.
- Many browser vendors prefer to use HTTPS to request web pages because it is more secure, and some new features will only support HTTPS. The browser attitude toward HTTP is to scrap it and not support it as much as possible. Therefore, the new HTTP/2 protocol is only supported under HTTPS.
To support HTTP/2, both the server and the client must support it, including intermediate proxy servers and so on.
- Client support is better, mainstream browsers are basically supported, compatibility is no problem (only IE11 in Windows10 partially supported)
- Support on the server side is more complex, depending on the situation. Most of the operating systems used by the support servers are Linux, and most of the Web servers used are system-level software (such as Apache). These Web servers are basically built-in by the Linux operating system. If the server has an older operating system version, the native Web Server may not support HTTP/2. On the other hand, to implement HTTP/2, you generally rely on the OpenSSL library internally to support HTTPS (because HTTP/2 must run over HTTPS), and HTTP/2 also has requirements for OpenSSL versions (ALPN must be supported: Application Layer Protocol Negotiation), so if the server is to fully support HTTP/2, you may need to upgrade these software, or even the operating system. But for a stable server, making such an upgrade is risky and potentially cumbersome (system-level software is often overpowered, and upgrades can affect other services).
Is there another way to support HTTP/2 without upgrading the server infrastructure? In fact, we can add another set of infrastructure (software or services) before the server, which serves as an intermediate layer to handle HTTP/2 requests, and the server itself still only supports HTTP/1.1. This strategy can be implemented in the following two ways:
- Reverse proxy server: for example, nginx supports HTTP/2, and the client supports HTTP/2, so they can communicate with each other. Nginx translates HTTP/2 messages into HTTP/1.1, which communicates with the final server.
- CDN