기사 디렉토리

정적 리소스의 캐시 처리

정적 리소스의 캐시 처리

캐싱 개요

캐싱이란 무엇입니까?

缓存（cache）, 원래의 의미는 액세스 속도가 일반적인 RAM(Random Access Memory)보다 빠른 고속 메모리를 말하며 일반적으로 시스템 메인 메모리와 같은 DRAM 기술을 사용하지 않고 비싸지만 더 빠른 SRAM 기술을 사용합니다. 캐시 설정은 모든 최신 컴퓨터 시스템의 고성능을 위한 중요한 요소 중 하나입니다.

웹 캐싱이란 무엇입니까

웹 캐시는 웹 서버와 클라이언트(브라우저) 사이에 존재하는 웹 리소스(예: html 페이지, 사진, js, 데이터 등)의 복사본을 말합니다. 캐시는 들어오는 요청에 따라 출력 내용의 복사본을 저장하고, 다음 요청이 올 때 동일한 URL인 경우 캐시 메커니즘에 따라 액세스 요청에 응답하기 위해 복사본을 직접 사용할지 여부를 결정합니다. , 또는 소스 서버에 요청을 다시 보내십시오. 브라우저가 방문한 웹 사이트의 웹 페이지를 캐시하는 것이 더 일반적입니다.URL 주소에 다시 액세스하면 웹 페이지가 업데이트되지 않으면 웹 페이지가 다시 다운로드되지 않지만 로컬에 캐시된 웹 페이지는 직접 사용.웹사이트에서 리소스가 업데이트되었음을 명확하게 식별하는 경우에만 브라우저가 페이지를 다시 다운로드합니다.

여기에 이미지 설명 삽입

웹 캐싱의 종류

클라이언트 캐시
- 브라우저 캐시
서버 캐시
- Nginx/Redis/Memcached 등

브라우저 캐시

네트워크 리소스를 절약하고 브라우징 속도를 높이기 위해 브라우저는 최근에 요청한 문서를 사용자의 디스크에 저장합니다.방문자가 이 페이지를 다시 요청하면 브라우저는 로컬 디스크의 문서를 표시할 수 있으므로 페이지 브라우징 속도를 높일 수 있습니다.

브라우저 캐싱을 사용하는 이유

가장 저렴한 캐시 구현 중 하나
네트워크 대역폭 소비 감소
서버 압력 감소
네트워크 대기 시간 감소 및 페이지 열기 속도 향상

브라우저 캐싱 실행 프로세스

HTTP 프로토콜의 페이지 캐싱과 관련된 필드를 먼저 알아보겠습니다.

머리글	설명하다
만료	캐시가 만료되는 날짜 및 시간
캐시 제어	관련 구성 정보 설정 및 캐시
최종 수정	리소스 마지막 수정 시간 요청
ETag	파일의 MD5 값과 같은 요청 변수의 엔터티 태그의 현재 값

ETag는 단순히 ID 번호로 이해할 수 있습니다.

여기에 이미지 설명 삽입

(1) 사용자는 처음으로 브라우저를 통해 데이터를 얻기 위해 서버에 요청을 보내지만 클라이언트에는 해당 캐시가 없으므로 데이터를 얻으려면 요청을 보내야 합니다.
(2)요청을 받은 서버는 성공 상태 코드 200을 반환하고 서버의 데이터와 서버 캐시의 권한을 얻은 후 응답 헤더에 해당 리소스 및 캐시 정보를 첨부합니다.
(3) 사용자가 동일한 리소스에 다시 액세스하면 클라이언트는 브라우저의 캐시 디렉토리에 해당 캐시 파일이 있는지 확인합니다.
(4) 해당 캐시 파일이 없으면 (2)단계로 이동
(5) 캐시 파일이 있으면 캐시 파일의 만료 여부를 판단하는데, 만료 판단 기준은 (만료),
(6) 만료되지 않은 경우 표시를 위해 로컬 캐시에서 직접 데이터를 반환합니다(이것을 강력한 캐시라고 합니다.)
(7) Expires가 만료되면 캐시 파일이 변경되었는지 확인해야 합니다.
(8) 판단 기준은 ETag(Entity Tag)와 Last-Modified 두 가지가 있습니다.
(9) 판단 결과가 변경되지 않은 경우 서버는 304를 반환하고 캐시 파일에서 직접 데이터를 가져옵니다(이것을 약한 캐시라고 합니다.)
(10) 변경이 있는 것으로 판단되면 다시 서버에서 데이터를 가져와서 ( 서버에서 캐시된 데이터를 설정해야 하는지 여부 )에 따라 데이터 캐싱을 缓存协商수행 합니다 .

강력한 캐시와 약한 캐시의 차이점은 다음과 같습니다.

강력한 캐싱은 더 이상 서버에 요청을 보내지 않고 로컬 캐시에서 직접 가져옵니다.

약한

캐시 는 서버에

요청 을 보내야 하며, 서버는 판단 후 304로 응답한 다음 로컬 캐시에서 액세스된 리소스를 가져옵니다 . , 응답 상태 코드가 있는 이유 자세히 살펴보면 응답 상태 코드 200이 밝은 회색임을 알 수 있습니다. 데이터를 캐시할 때 액세스된 리소스를 캐시할 뿐만 아니라 요청 헤더와 응답 헤더도 캐시하기 때문입니다.

브라우저 캐시 관련 지침

Nginx는 캐시 관련 설정을 구성해야 하므로 다음 지침이 필요합니다.

만료 명령

만료: 이 지시문은 페이지 캐시의 역할을 제어하는 데 사용됩니다. 이 명령을 사용하여 HTTP 응답에서 "만료" 및 "캐시 제어"를 제어할 수 있습니다.

문법	만료 [수정됨] 시간 만료 epoch\|max\|off;
기본값	만료됨;
위치	http, 서버, 위치

time: 정수 또는 음수일 수 있음, 만료 시간 지정, 단위는 s, 음수이면 Cache-Control은 no-cache, 정수 또는 0이면 Cache 값 -제어는 max-age=time(지정한 값이기도 함)입니다.
- no-cache는 캐시를 사용할 때 캐시가 만료되었는지 여부에 관계없이 파일 또는 리소스가 변경되었는지 확인하기 위해 서버에 요청을 보내야 함을 의미합니다(즉, 캐시가 약화됨).
우리는 Cache-Control에서 Expires와 max-age=time이 같은 역할을 한다는 것을 발견했습니다. 이는 Expires의 헤더 정보는 HTTP1.0에 나타나는 구성인데 Expires의 값은 서버와 관련된 구성과 시간이기 때문에 로컬 클라이언트의 시간과 서버의 시간이 일치하지 않으면 요구 사항이 충족되지 않을 수 있습니다. 따라서 HTTP1.1에서는 Cache-Control의 max-age가 Expires의 기능을 대체하는 데 사용되었습니다. 두 값이 모두 존재하는 경우 캐시 만료 여부를 계산하는 데 max-age 값이 사용되며 일부 브라우저는 max-age를 지원하지 않으며 Expires 값을 사용하여 계산됩니다. 그래서 우리는 보통 이 두 값을 구성합니다.
epoch: Expires 값을 '1 January,1970,00:00:01 GMT'(1970-01-01 00:00:00)로 지정하고 Cache-Control 값을 no-cache로 지정합니다.
max: Expires의 값을 '2037년 12월 31일 23:59:59GMT'(2037-12-31 23:59:59)로 지정하고 Cache-Control의 값을 10년으로 지정합니다.
off: 기본적으로 캐시하지 않습니다.

예를 들어 다음을 구성해
여기에 이미지 설명 삽입
보겠습니다. 그런 다음 응답 헤더와 이전 응답 헤더의 차이점을 살펴보겠습니다.

add_header 지시어

add_header 명령은 지정된 응답 헤더와 응답 값을 추가하는 데 사용됩니다.

문법	add_header 이름 값 [항상];
기본값	—
위치	http, 서버, 위치…

이름: 속성 이름
값: 속성 값
항상: 브라우저가 지원하는지 여부에 관계없이 헤더 정보가 추가됩니다.

Cache-Control은 응답 헤더 정보로 사용되며 다음 값을 설정할 수 있습니다.

캐시 응답 지시문:

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>

지침	설명하다
반드시 재확인	캐시 가능하지만 원본 서버에서 재확인해야 함
캐시 없음	캐싱하기 전에 유효성을 확인해야 합니다.
무점포	요청 또는 응답의 내용을 캐시하지 마십시오.
변환 없음	프록시는 미디어 유형을 변경할 수 없습니다.
공공의	모든 당사자에게 응답을 제공할 수 있는 캐시
사적인	특정 사용자에게만 응답 반환
프록시 재검증	캐시된 응답의 유효성을 확인하도록 중간 캐시 서버에 요청
최대 연령=<초>	최대 연령 값에 응답
s-maxage=<초>	공개 캐시 서버 응답의 최대 연령 값

예를 들어 이제 요청 또는 응답의 내용을 캐시하지 않는 no-store를 구성해 보겠습니다.
여기에 이미지 설명 삽입

Nginx 도메인 간 문제 해결

이 콘텐츠의 경우 주로 다음 측면에서 해결합니다.

도메인 간 문제는 어떤 상황에서 발생합니까?
예는 도메인 간 문제를 보여줍니다.
구체적인 해결책은 무엇입니까?

동일 출처 정책

브라우저의 동일 출처 정책: 이는 브라우저의 핵심이자 가장 기본적인 보안 기능이며, 브라우저에 동일 출처 정책이 없을 경우 브라우저의 정상적인 기능에 영향을 미칠 수 있습니다.

동종: 동일한 프로토콜, 도메인 이름(IP) 및 포트는 동일한 출처를 의미합니다.

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
满足 协议、端口、域名都一样

도메인 간 문제

간단히 설명:

A와 B 두 개의 서버가 있습니다. 데이터를 얻기 위해 서버 A의 페이지에서 서버 B로 비동기 요청을 보내는 경우 서버 A와 서버 B가 동일 출처 정책을 충족하지 않으면 도메인 간 문제가 발생합니다.

교차 도메인 문제는브라우저 보안 문제, 서버 보안 문제가 아닙니다. 서버 간에 요청을 보내는 데 도메인 간 문제가 없습니다. 하지만 지금은 프런트엔드 페이지를 서버에 배포하는데, 서로 다른 서버에 배포된 프런트엔드 페이지가 요청을 보낼 때 도메인 간 문제가 발생합니다.

도메인 간 문제에 대한 사례 발표

도메인 간 문제의 영향은 무엇입니까?다음으로 요구 사항을 통해 설명하겠습니다.

여기에 이미지 설명 삽입

(1) nginx의 html 디렉토리 아래에 새로운 a.html을 생성합니다.

<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) 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) 브라우저를 통한 접속 테스트

여기에 이미지 설명 삽입

해결책

일부 헤더 정보를 추가하는 데 사용할 수 있는 add_header 명령을 사용합니다.

문법	add_header 이름 값…
기본값	—
위치	http, 서버, 위치

여기서는 도메인 간 문제를 해결하기 위해 사용되며 두 개의 헤더 정보를 추가해야 합니다. 하나는 Access-Control-Allow-Origin,Access-Control-Allow-Methods

Access-Control-Allow-Origin: 말 그대로 번역하면 교차 도메인 접근을 허용하는 소스 주소 정보로 여러 개를 구성(쉼표로 구분)하거나 *모든 출처를 나타내기 위해 사용할 수 있습니다.

Access-Control-Allow-Methods: 말 그대로 번역하면 교차 도메인 액세스를 허용하는 요청 방법입니다. 값은 GET POST PUT DELETE...일 수 있으며 모두 또는 필요에 따라 설정할 수 있습니다. 배수는 쉼표로 구분됩니다.

특정 구성

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}';
}

정적 리소스 안티 거머리

리소스 핫링크란?

리소스 핫링크는 콘텐츠가 자신의 서버에 있는 것이 아니라 기술적 수단을 통해 다른 사람의 제한을 우회하고 다른 사람의 콘텐츠를 자신의 페이지에 올려 최종적으로 사용자에게 표시하는 것을 의미합니다. 대형 웹사이트의 공간과 트래픽을 훔치기 위해. 요컨대 남의 것을 이용해 나만의 웹사이트를 만드는 것이다.

효과 데모

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

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

직접 페이지를 준비하고 페이지에 이 두 장의 사진을 소개하여 효과를 확인합니다.

여기에 이미지 설명 삽입

위의 효과에서 아래 이미지 주소에 핫링크 방지 기능이 추가되어 JD.com에서 이미지를 직접 사용할 수 있음을 알 수 있습니다.

Nginx 안티 거머리의 실현 원리:

Anti-leeching의 원리를 이해하기 전에 먼저 HTTP 헤더 Referer를 알아야 하는데, 브라우저가 웹 서버에 요청을 보낼 때 일반적으로 Referer를 가져와 웹 페이지가 어느 페이지에서 링크되어 있는지 브라우저에 알려줍니다.

여기에 이미지 설명 삽입

백그라운드 서버는 획득한 Referer 정보에 따라 신뢰할 수 있는 웹 사이트 주소인지 여부를 판단하고, 신뢰할 수 있는 경우 계속 방문할 수 있으며, 그렇지 않은 경우 상태 정보 403(서버는 액세스를 거부함)을 반환할 수 있습니다. ).

위의 서버 효과를 로컬에서 시뮬레이션합니다.

여기에 이미지 설명 삽입

Nginx anti-leech의 특정 구현:

valid_referers:

Nginx는 요청 헤더의 리퍼러를 valid_referers 뒤의 콘텐츠와 일치시킵니다.

일치하면 $invalid_referer 변수를 0으로 설정하고,
일치하는 항목이 없으면 $invalid_referer 변수를 1로 설정하고,

일치하는 동안 대소문자를 구분하지 않음

문법	valid_referers 없음\|차단됨\|server_names\|문자열…
기본값	—
위치	서버, 위치

none: Header의 Referer가 비어있는 경우 접근 허용
blocked: Header의 Referer는 비어 있지 않으나 방화벽이나 Proxy에 의해 값이 마스커레이드된 경우 등 예를 들어 "http://"와 같은 "https://"프로토콜 헤더가 없는 리소스만 접근이 가능합니다.
server_names: 특정 도메인 이름 또는 IP 지정
string: 정규 표현식 및 *문자열을 지원할 수 있습니다. 정규 표현식인 경우 ~시작 부분에 표현해야 합니다. 예를 들어

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;

}

Nginx에서 if 뒤에는 공백이 있어야 합니다.

문제 발생: 많은 사진이 있습니다. 일괄 핫링크를 방지하는 방법은 무엇입니까?

디렉토리에 대한 거머리 방지

구성은 다음과 같습니다.

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;

}

이러한 방식으로 디렉터리의 모든 리소스에 대해 거머리 방지 작업을 수행할 수 있습니다.

발생하는 문제: Referer에 대한 제한이 비교적 까다롭습니다.예를 들어 임의로 Referer를 추가하면 위의 방법으로 제한할 수 없습니다. 그렇다면 이 문제를 어떻게 해결해야 할까요?

Nginx의 타사 모듈을 사용할 수 있습니다.ngx_http_accesskey_module

[Nginx] 정적 리소스 배포(아래)

기사 디렉토리

정적 리소스의 캐시 처리

캐싱 개요

브라우저 캐시 관련 지침

만료 명령

add_header 지시어

Nginx 도메인 간 문제 해결

동일 출처 정책

도메인 간 문제

도메인 간 문제에 대한 사례 발표

해결책

정적 리소스 안티 거머리

리소스 핫링크란?

Nginx 안티 거머리의 실현 원리:

디렉토리에 대한 거머리 방지

Supongo que te gusta