Technology that large concurrent servers have to say-HTTP Cache

As mentioned above, the technical order is made by a single person on the server side, and sometimes the client needs to cooperate.

A link request can be roughly divided into several stages.

If the client sends the same request and the results are the same, can we buffer it? Can I reduce the number of steps?

Yes. Generally, the following methods are available:

1. first, we try to buffer data on the server. We try not to release the content sent from a long link that has already been returned. The content just sent is directly returned in the next request. This is not suitable for frequent access, applicable to special requests in special cases.

2. lastupdatetime is the last modification time for static files. The HTTP header returned by the client's first request contains the lastupdatetime, and the client adds the page to the cache. The second request header contains lastupdatetime, the server compares it with the current lastupdatetime. If the difference is the same, the server directly tells the client that the file has not been modified and uses it in your cache.

In fact, the last-modified and if-modified-since fields in the request header are returned by HTTP.

For example

Return Header

HTTP/1.1 200 OK
Date: Wed, 20 Mar 2013 07:35:22 GMT
Content-Type: text/html; charset = UTF-8
Content-encoding: Gzip
Last-modified: Wed, 20 Mar 2013 07:35:22 GMT
Transfer-encoding: chunked
Server: yumeiz

Request Header

Get, HTTP, 1.1
HOST: www.xxx.com
Connection: keep-alive
If-modified-since: Wed, 20 Mar 2013 07:35:22 GMT

Return Baotou again:

HTTP/1.1 304 not modified

For some dynamic requests without modification time, the server can specify a field. When the second request finds that this field has not changed, it also tells the client to directly use the content in the cache.

In fact, this field is etag, And the request header field is if-None-match.

For example

Return the packet header (only point to the corresponding field, and others are the same as above)

Etag = "ABCD"

Request Header

If-None-match = W/"ABCD"

Through the above, we know that when the client receives a 304 not modified header, it means that the pages in the cache can be directly used to play a significant role in files with frequent requests, such as JS and CSS, there are also some large image files, which means they are sent for saving lives...

3. the above methods actually require the participation of the server. We know that some files such as JS, CSS, and HTML are too frequent to change, but the request frequency is too large, if there is pressure on requests, even if the server returns 304, there is a lot of concurrency pressure. Can the client directly use the cache without confirmation?

Do you still remember that the cookie has an expiration time and the request can also have an expiration time? If the request has not expired, the client will directly load the cached page and will not confirm it again, no check, no link, no server!

In this way, the connection with the server is completely lost, reducing the load on the server and reducing the bandwidth...

In fact, this field is expires.

For example

HTTP/1.1 200 OK
Date: Wed, 20 Mar 2013 07:35:22 GMT
Content-Type: text/html; charset = UTF-8
Content-encoding: Gzip
Expires: Wed, 20 Mar 2013 08:01:22 GMT
Transfer-encoding: chunked
Server: yumeiz

There is also a field max-age, which works the same way and can overwrite expires.

Max-age indicates how many seconds it takes to expire from now on.

Max-age usage:

Cache-control: Max-age = 3600

Looking back, the second and second methods actually omit the service processing on the server. The second method is that there is no server at all, which is equivalent to offline processing for a period of time, although it is contrary to the spirit of interconnection, it can solve the problem.

The preceding methods can also be used together. For example, the returned headers include both expires and last-modified, as shown in figure

HTTP/1.1 200 OK
Date: Wed, 20 Mar 2013 07:35:22 GMT
Content-Type: text/html; charset = UTF-8
Content-encoding: Gzip
Last-modified: Wed, 20 Mar 2013 03:35:22 GMT
Expires: Wed, 20 Mar 2013 08:01:22 GMT
Transfer-encoding: chunked
Server: yumeiz

When the expires does not expire, the client cache is used directly. If the expires, the server is requested again. If the file modification time is not changed, the system returns 304 and refresh the expires.

For example:

HTTP/1.1 304 not modified
Server: yumeiz
Date: Wed, 20 Mar 2013 08:02:22 GMT
Vary: Accept-Encoding
Last-modified: Wed, 20 Mar 2013 03:35:22 GMT
Expires: Wed, 20 Mar 2013 08:35:22 GMT
Cache-control: Max-age = 31536000