[Nginx] Static resource deployment (below)

Cache processing of static resources

Caching overview

What is caching?

缓存（cache）, the original meaning refers to a high-speed memory whose access speed is faster than general random access memory (RAM). Usually, it does not use DRAM technology like system main memory, but uses expensive but faster SRAM technology. The setting of the cache is one of the important factors for the high performance of all modern computer systems.

What is web caching

Web cache refers to a copy of a web resource (such as html page, picture, js, data, etc.) that exists between the web server and the client (browser). The cache will save a copy of the output content according to the incoming request; when the next request comes, if it is the same URL, the cache will decide according to the cache mechanism whether to directly use the copy to respond to the access request, or send the request to the source server again. It is more common that the browser will cache the web pages of the visited website. When the URL address is accessed again, if the web page is not updated, the web page will not be downloaded again, but the locally cached web page will be used directly.Only when the website clearly identifies that the resource has been updated will the browser download the page again

Types of web caching

• client cache
  • browser cache
• server cache
  • Nginx/Redis/Memcached etc.

browser cache

In order to save network resources and speed up browsing, the browser stores the recently requested documents on the user's disk. When the visitor requests this page again, the browser can display the documents from the local disk, which can speed up page browsing. .

Why use browser caching

• One of the lowest cost cache implementations
• Reduce network bandwidth consumption
• Reduce server pressure
• Reduce network latency and speed up page opening

Execution process of browser caching

The fields related to page caching in the HTTP protocol, let's get to know them first:

header	illustrate
Expires	The date and time the cache expires
Cache-Control	Set and cache related configuration information
Last-Modified	Request resource last modification time
ETag	The current value of the entity tag of the request variable, such as the MD5 value of the file

ETag can be simply understood as an ID number

• (1) The user sends a request to the server to obtain data through the browser for the first time, but the client does not have a corresponding cache, so a request needs to be sent to obtain the data;

• (2)After receiving the request, the server returns the success status code of 200 and attaches the corresponding resource and cache information to the response header after obtaining the data of the server and the permission of the server cache

• (3) When the user accesses the same resource again, the client will check whether there is a corresponding cache file in the browser's cache directory

• (4) If no corresponding cache file is found, go to step (2)

• (5) If there is a cache file, then judge whether the cache file is expired. The criteria for judging the expiration is (Expires),

• (6) If it has not expired, return the data directly from the local cache for display (This is called a strong cache)

• (7) If Expires expires, it is necessary to determine whether the cache file has changed

• (8) There are two judgment criteria, one is ETag (Entity Tag) and the other is Last-Modified

• (9) If the judgment result is unchanged, the server will return 304 and obtain the data directly from the cache file (This is called a weak cache)

• (10) If it is judged that there has been a change, obtain the data from the server again, and perform data caching according to 缓存协商( whether cached data is required to be set by the server ).

We can see that the difference between strong cache and weak cache is:

• Strong caching will no longer send requests to the server, and get them directly from the local cache
• A weak cache needs to send a request to the server, and the server responds with a 304 after judging, and then obtains the accessed resources from the local cache
  
  Weak cache:
  
  Strong cache:
  
  (Some people may ask that strong caches do not send requests, why there A response status code? If we look closely, we will find that the response status code 200 here is light gray, because when caching data, it not only caches the accessed resources, but also caches the request header and response header )

Browser cache related instructions

Nginx needs to configure cache-related settings, so the following instructions are required

expires command

expires: This directive is used to control the role of the page cache. You can use this command to control "Expires" and "Cache-Control" in the HTTP response

grammar	expires [modified] time expires epoch|max|off;
Defaults	expires off;
Location	http、server、location

• time: can be an integer or a negative number, specify the expiration time, the unit is s, if it is a negative number, the Cache-Control is no-cache, if it is an integer or 0, the value of the Cache-Control is max-age=time (also is the value you specified);

  • no-cache means that when you use the cache, no matter whether the cache has expired or not, you need to send a request to the server to confirm whether the file or resource has changed (that is, weaken the cache)

  We found that Expires and max-age=time in Cache-Control play the same role. This is because the header information of Expires is the configuration that appears in HTTP1.0, but the value of Expires is the configuration and time related to the server. If the time of the local client is inconsistent with the time of the server, the requirements may not be met. Therefore, in HTTP1.1, the max-age in Cache-Control was used to replace the function of Expires. If both values ​​are present, the value of max-age will be used to calculate whether the cache expires. Some browsers do not support max-age, and the value of Expires will be used for calculation. So we usually configure these two values.

• epoch: Specify the value of Expires as '1 January,1970,00:00:01 GMT' (1970-01-01 00:00:00), and the value of Cache-Control as no-cache

• max: Specify the value of Expires as '31 December2037 23:59:59GMT' (2037-12-31 23:59:59), and the value of Cache-Control as 10 years

• off: Do not cache by default.

For example, let's configure the following:

Then let's take a look at the difference between our response header and the previous one:

add_header directive

The add_header command is used to add the specified response header and response value.

grammar	add_header name value [always];
Defaults	—
Location	http、server、location…

• name: attribute name
• value: attribute value
• always: No matter whether the browser supports it or not, the header information will be added to it

Cache-Control is used as the response header information, and the following values ​​can be set:

Cache response directive:

Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>

instruction	illustrate
must-revalidate	Cacheable but must reconfirm with the origin server
no-cache	Validity must be confirmed before caching
no-store	Do not cache any content of the request or response
no-transform	Proxy cannot change media type
public	A cache that can serve responses to any party
private	Only return responses to specific users
proxy-revalidate	Ask the intermediate cache server to confirm the validity of the cached response
max-age=<seconds>	Respond to the maximum Age value
s-maxage=<seconds>	The maximum age value of public cache server response

For example, let's now configure a no-store that does not cache any content of the request or response:

Nginx cross-domain problem solving

For this content, we mainly solve it from the following aspects:

• Under what circumstances will cross-domain problems occur?
• Examples demonstrate cross-domain issues
• What is the specific solution?

Same Origin Policy

The browser's same-origin policy: It is a convention, and it is the core and most basic security function of the browser. If the browser lacks the same-origin policy, the normal functions of the browser may be affected.

Homologous: the same protocol, domain name (IP) and port means the same origin

http://192.168.200.131/user/1
https://192.168.200.131/user/1
不满足   协议不相同

http://192.168.200.131/user/1
http://192.168.200.132/user/1
不满足 IP地址不一样

http://192.168.200.131/user/1
http://192.168.200.131:8080/user/1
不满足 端口不一样

http://www.nginx.com/user/1
http://www.nginx.org/user/1
不满足 域名不一样

http://192.168.200.131/user/1
http://192.168.200.131:8080/user/1
不满足 端口不一样

http://www.nginx.org:80/user/1
http://www.nginx.org/user/1
满足 协议、端口、域名都一样

cross-domain issues

Briefly describe:

There are two servers, A and B. If an asynchronous request is sent from the page of server A to server B to obtain data, if server A and server B do not satisfy the same-origin policy, cross-domain problems will occur.

Note that cross domain issues arebrowser security issues, not server security issues. There is no cross-domain problem in sending requests between our servers. But now we deploy the front-end pages on the server, and there are cross-domain problems when the front-end pages deployed on different servers send requests

Case presentation of cross-domain issues

What will be the effect of cross-domain problems? Next, I will demonstrate to you through a requirement:

(1) Create a new a.html under the html directory of nginx

<html>
  <head>
        <meta charset="utf-8">
        <title>跨域问题演示</title>
        <script src="jquery.js"></script>
        <script>
            $(function(){
      
      
                $("#btn").click(function(){
      
      
                        $.get('http://192.168.200.133:8080/getUser',function(data){
      
      
                                alert(JSON.stringify(data));
                        });
                });
            });
        </script>
  </head>
  <body>
        <input type="button" value="获取数据" id="btn"/>
  </body>
</html>

(2) Configure the following content in nginx.conf

server{
        listen  8080;
        server_name localhost;
        location /getUser{
                default_type application/json;
                return 200 '{"id":1,"name":"TOM","age":18}';
        }
}
server{
	listen 	80;
	server_name localhost;
	location /{
		root html;
		index index.html;
	}
}

(3) Access test through browser

solution

Use the add_header command, which can be used to add some header information

grammar	add_header name value…
Defaults	—
Location	http、server、location

It is used here to solve the cross-domain problem, and two header information need to be added, one is Access-Control-Allow-Origin,Access-Control-Allow-Methods

Access-Control-Allow-Origin: Literally translated, it is the source address information that allows cross-domain access. You can configure multiple (separated by commas), or you can use to *represent all origins

Access-Control-Allow-Methods: Literally translated, it is a request method that allows cross-domain access. The value can be GET POST PUT DELETE..., which can be set all or as needed. Multiples are separated by commas

Specific configuration

location /getUser{
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE;
    default_type application/json;
    return 200 '{"id":1,"name":"TOM","age":18}';
}

Static resource anti-leech

What is resource hotlinking

Resource hotlinking means that the content is not on your own server, but through technical means, bypassing other people's restrictions, putting other people's content on your own page and finally displaying it to users. In order to steal the space and traffic of large websites. In short, it is to use other people's things to make your own website.

Effect demonstration

Jingdong: https://img14.360buyimg.com/n7/jfs/t1/101062/37/2153/254169/5dcbd410E6d10ba22/4ddbd212be225fcd.jpg

Baidu: https://pics7.baidu.com/feed/cf1b9d16fdfaaf516f7e2011a7cda1e8f11f7a1a.jpeg?token=551979a23a0995e5e5279b8fa1a48b34&s=BD385394D2E963072FD48543BB30030

We prepare a page by ourselves and introduce these two pictures on the page to see the effect

From the above effect, it can be seen that the image address below has added the function of preventing hotlinking, and we can directly use the image on JD.com.

The realization principle of Nginx anti-leech:

Before understanding the principle of anti-leeching, we must first learn an HTTP header Referer. When a browser sends a request to a web server, it usually brings a Referer to tell the browser which page the web page is linked from.

The background server can judge whether it is the website address it trusts according to the obtained Referer information, if it is, it will be allowed to continue to visit, if not, it can return the status information of 403 (the server refuses to access).

Simulate the above server effect locally:

The specific implementation of Nginx anti-leech:

valid_referers:

Nginx will match the referer in the request header with the content after valid_referers:

• If it matches, set the $invalid_referer variable to 0,
• If there is no match, set the $invalid_referer variable to 1,

Case insensitive during matching

grammar	valid_referers none|blocked|server_names|string…
Defaults	—
Location	server、location

• none: If the Referer in the Header is empty, allow access

• blocked: The Referer in the Header is not empty, but the value has been masqueraded by a firewall or proxy. For example , resources without protocol headers such as "http://", etc. are allowed to access."https://"

• server_names: Specify a specific domain name or IP

• string: Can support regular expressions and *strings. If it is a regular expression, it needs to be ~expressed at the beginning, for example

location ~*\.(png|jpg|gif){
           valid_referers none blocked www.baidu.com 192.168.200.222 *.example.com example.*  www.example.org  ~\.google\.;
           if ($invalid_referer){
                return 403;
           }
           root /usr/local/nginx/html;

}

In Nginx, if must be followed by a space

Problems encountered: There are many pictures, how to prevent hotlinking in batches?

Anti-leeching for directories

The configuration is as follows:

location /images {
           valid_referers none blocked www.baidu.com 192.168.200.222 *.example.com example.*  www.example.org  ~\.google\.;
           if ($invalid_referer){
                return 403;
           }
           root /usr/local/nginx/html;

}

In this way, we can perform anti-leech operations on all resources in a directory.

Problems encountered: The restrictions on Referer are relatively rough. For example, if you add a Referer at will, the above method cannot be restricted. So how to solve this problem?

We can use Nginx's third-party modulesngx_http_accesskey_module