HTTP 2.0 Interview Pass: Mandatory Caching and Negotiated Caching

• Differences between HTTP1.0 and HTTP1.1
  • Persistent Connection
  • Save bandwidth
  • HOST domain
  • Cache handling
• Request response and long connection
• HTTP 2.0 Multiplexing
• HTTP Methods
• Force caching
• Negotiation Cache
• Summarize
  • Header data compression
  • Server Push

HyperText Transfer Protocol (HTTP) is the most widely used application layer protocol. You can see it on websites, apps, and open interfaces. The HTTP protocol is very simple in design, but it covers a lot of content. I believe you have come into contact with this protocol more or less in your daily work.

Differences between HTTP1.0 and HTTP1.1

Persistent Connection

HTTP1.1 supports pipeline processing of persistent connections and requests. Multiple HTTP requests and responses can be transmitted on a TCP connection, reducing the consumption and delay of establishing and closing connections. In HTTP1.1, persistent connection keep-alive is enabled by default, which to some extent makes up for the shortcoming of HTTP1.0 that each request must create a connection. HTTP1.0 needs to use the keep-alive parameter to inform the server to establish a persistent connection.

Save bandwidth

There are some bandwidth wasting phenomena in HTTP1.0, for example, the client only needs a part of an object, but the server sends the whole object, and does not support breakpoint resuming. HTTP1.1 supports sending only header information (without any body information). If the server believes that the client has the authority to request the server, it returns 100. The client starts to send the request body to the server after receiving 100; if it returns 401, the client does not need to send the request body, saving bandwidth.

HOST domain

In HTTP1.0, it is assumed that each server is bound to a unique IP address. Therefore, the URL in the request message does not pass the host name, and HTTP1.0 does not have a host domain. With the development of virtual host technology, multiple virtual hosts (Multi-homed Web Servers) can exist on a physical server, and they share an IP address. Both the request message and the response message of HTTP1.1 support the host domain, and if there is no host domain in the request message, an error (400 Bad Request) will be reported.

Cache handling

In HTTP1.0, If-Modified-Since and Expires in the header are mainly used as the standard for cache judgment. HTTP1.1 introduces more cache control strategies such as Entity tag, If-Unmodified-Since, If-Match, If-None-Match and other optional cache headers to control the cache strategy.

Request response and long connection

The HTTP protocol uses a request/return model. The client (usually a browser) initiates an HTTP request, and the Web server returns the data after receiving the request.

HTTP requests and responses are both text. You can simply think of HTTP protocol as using TCP protocol to transmit text. When a user wants to view a web page, he sends a text request to the web server. The web server parses the text and then sends the web page back to the browser.

So here is a question, is a TCP connection established every time a request is sent?

Of course not. In order to save time for handshakes and waving, when the browser sends a request to the Web server, a timer is set inside the Web server. If the client continues to send requests within a certain range of time, the server will reset the timer. If the server does not receive a request within a certain range of time, the connection will be disconnected. This prevents the waste of handshake and waving resources, and at the same time avoids a connection that takes too long to be recycled, resulting in reduced memory usage efficiency.

This capability can be configured using HTTP protocol headers, such as the following request header:

 Keep-Alive: timeout=10s

It tells the web server that the connection duration is 10 seconds. If there is no request within 10 seconds, the connection will be disconnected.

HTTP 2.0 Multiplexing

Keep-Alive was not a feature that Berners-Lee had when he designed the HTTP protocol. The first version of the HTTP protocol designed by Berners-Lee was version 0.9. Later, as the protocol was gradually improved, version 1.0 was released. Keep-Alive is a feature added to HTTP version 1.1, which is designed to cope with the increasingly complex loading of web page resources. Since the birth of the HTTP protocol, the resources required in web pages have become more and more abundant, and more and more requests need to be sent to open a page, so the design of Keep-Alive was born.

Similarly, when a website needs to load a lot of resources, the browser will try to send requests concurrently (using multi-threading technology). The browser will limit the number of concurrent requests sent at the same time, usually 6. This is a protection for the user's local experience on the one hand, preventing the browser from occupying too many network resources; on the other hand, it is also a protection for site services to prevent excessive instantaneous traffic.

After HTTP 2.0, multiplexing capabilities were added. Similar to the multiplexing mentioned in the RPC framework, requests and responses are split into slices and then transmitted in a mixed manner. In this way, there will be no blocking between requests and responses. You can think about it, for a TCP connection, in the Keep-Alive design of HTTP 1.1, the second request must wait for the first request to return. If the first request is blocked, all subsequent requests will be blocked. The multiplexing of HTTP 2.0 divides the request returns into small slices, so that using the same connection, requests are equivalent to being issued in parallel without interfering with each other.

HTTP Methods

In the RESTful architecture, in addition to the above-mentioned overall architectural solution, some implementation details are also constrained, such as using nominal interfaces and HTTP methods to design the interface provided by the server.

We use GET to retrieve data or perform queries. For example, the following example retrieves the order data with id 123:

 GET / order /123

GET is the HTTP method, and /order is a noun-like name. The semantics of this design is very clear. This interface is used to obtain order data (that is, the representation of the order).

For data update scenarios, according to the HTTP protocol, PUT is an idempotent update behavior, and POST is a non-idempotent update behavior. For example:

 PUT / order /123
 {...order data}

In the above, we use PUT to update an order. If order 123 has not been created, this interface will create the order. If 123 already exists, this interface will update the data of order 123. Why is this so? Because PUT stands for idempotence. For an idempotent interface, the final state is consistent no matter how many times the request is made, which means that the operation is on the same order.

If you use POST to update the order instead:

 POST / order  
 {...order data}

POST represents a non-idempotent design. For example, if the interface above uses POST to submit a form, multiple calls will often generate multiple orders. In other words, a non-idempotent design will generate a new state after each call.

In addition, the HTTP protocol also stipulates the DELETE method for deleting data. In fact, there are several other methods. Students who are interested can check them out, such as OPTIONS and PATCH, and then we will discuss them in the comment area.

In the use of HTTP, we often encounter two types of cache, mandatory cache and negotiated cache, which are introduced one by one below.

Force caching

Your company uses version numbers to manage a JS file that is provided to the outside world. For example, libgo.1.2.3.js is version 1.2.3 of libgo. 1 is the major version, 2 is the minor version, and 3 is the patch number. Every time you make any changes, you update the libgo version number. In this case, after the browser requests the libgo.1.2.3.js file once, does it need to request it again?

Let's sort out our requirements. After the browser performs the GET /libgo.1.2.3.js operation for the first time, if a subsequent web page uses this file (libgo.1.2.3.js), we will not send a second request. This solution requires the browser to cache the file locally and set the expiration time of this file (or permanent validity). This cache mode that does not require a request to be sent again after a request is called forced caching in the HTTP protocol. When a file is cached, the next request will directly use the local version instead of actually sending it out.

When using forced caching, be careful not to force cache data that needs to be dynamically updated. A negative example is that Xiao Ming sets the interface for obtaining user information data to forced cache, which causes users to update their information but have to wait until the forced cache expires before they can see the update.

Negotiation Cache

Let's talk about another scenario: Xiao Ming developed an interface that provides three-level information of provinces, cities and districts across the country. Let me ask you a question first, can forced caching be used in this scenario? Xiao Ming thought forced caching was OK at first, and then suddenly one day he received a notice from the operation that two counties under a certain city had merged and the interface data needed to be adjusted. Xiao Ming was not in a hurry and updated the interface data, but the data had to wait until the forced cache expired.

To cope with this scenario, the HTTP protocol also designs a negotiation cache. After the negotiation cache is enabled, the first time the interface data is obtained, the data will be cached locally and a summary of the data will be stored. When the second request is made, the browser checks that there is a local cache and sends the summary to the server. The server will check whether the summary of the server data is consistent with that sent by the browser. If they are inconsistent, it means that the server data has been updated and the server will return all the data. If they are consistent, it means that the data has not been updated and the server does not need to return the data.

From this perspective, the negotiated cache method saves traffic. For the interface developed by Xiao Ming, the negotiated cache will take effect in most cases. When Xiao Ming updates the data, the negotiated cache becomes invalid and the client data can be updated immediately. Compared with the forced cache, the cost of the negotiated cache is that one more request is required.

Summarize

Currently, the HTTP protocol has developed to version 2.0, and many websites have updated to HTTP 2.0. Most browsers and CDNs also support HTTP 2.0. HTTP 2.0 solves more problems such as head-of-line blocking, HPack compression algorithm, and Server Push. If you can answer these questions, you can basically win the favor of the interviewer.

Header data compression

In HTTP1.1, HTTP requests and responses are composed of three parts: status line, request/response header, and message body. Generally speaking, the message body is compressed with gzip, or the compressed binary file is transmitted, but the status line and header are not compressed at all and are transmitted directly in plain text. As Web functions become more and more complex, the number of requests generated by each page is also increasing, resulting in more and more traffic consumed in the header, especially when the UserAgent and Cookie, which do not change frequently, are transmitted every time, which is a complete waste.

HTTP1.1 does not support header data compression. HTTP2.0 uses the HPACK algorithm to compress header data, which reduces the data size and allows faster transmission over the network.

Server Push

Server push is a mechanism for sending data before the client requests it. Web pages use many resources: HTML, style sheets, scripts, images, and so on. In HTTP 1.1, each of these resources must be explicitly requested. This is a slow process. The browser starts by fetching the HTML, and then incrementally fetches more resources as it parses and evaluates the page. Because the server must wait for the browser to make each request, the network is often idle and underutilized.

To improve latency, HTTP 2.0 introduces server push, which allows the server to push resources to the browser before the browser explicitly requests them, so that the client does not have to create a connection again to send a request to the server to obtain them. In this way, the client can load these resources directly from the local computer without going through the network.