chirho's network world

원문 https://serversforhackers.com/nginx-caching

- varnish와 마찬가지로 nginx도 매우 합리적인 용도의 web cache이다.

- nginx는 static content 처리 못지 않게 dynamic content를 proxy 처리하는 것도 수준급이다.

Use Cases

- nginx는 다른 서버로부터 수신한 content를 cache 처리할 수 있다.

- use case as nginx as a cache server

  - 웹서버의 앞단에 위치 : gateway로 동작, LB와 유사하게 동작.

  - cache result of FastCGI/uWSGI process.

    - 보통의 유저는 사이트의 dynamic 요소를 요구하지 않음. 단지 content를 보기 원할 뿐.

- cache server의 주요 이점 : app. server에 load 경감. static or dynamic content가 두루 cache.

How It Will Work

- Origin Server

 - static file 또는 dynamic하게 생성한 HTML 서비스

 - assets(혹은 content)가 cache될 수 있는지 결정. (HTTP cache header 이용)

- Cache Server

 - frontman : client로부터 HTTP request를 수신. 직접 처리(요청받은 리소스의 신선한 캐시를 가지고 있다면)할지 Origin Server에 처리를 맡길지 결정

 - Origin Server에 처리를 맡긴 후에는 Origin Server가 응답한 헤더에서 이 리소스를 캐시할지 간단히 전달만 할지 결정

 - 역할

  - HTTP request가 캐싱된 응답을 허용하는지, 현재 내가 가진 캐시 리소스가 신선한지 결정

  - 위에서 request가 캐싱을 허용하지 않거나, 캐시 리소스가 오래된 버전이면, HTTP request를 Origin Server에 전달.

  - HTTP response를 적절히 응답

- Client

 - local(private) cache 가짐. 

  - ex) browser cache

  - image, CSS, JS file 등

 - local cache에 fresh item이 있으면 재요청하지 않음

 - 역할

  - 요청을 보냄

  - 응답을 캐싱

  - local cache에서 item을 쓸지, HTTP request를 보낼지 결정

Origin Server

- origin server는 cache될 리소스의 헤더를 적당히 세팅할 책임

- origin server의 리소스 타입별 expires 헤더 세팅 예제

- html,xml,json (-1) < rss, atom (1h) < image (1M) < css,js (1y)

- Cache-Control "public" : 누구나 캐시 가능!

- "private" : browser 등 private cache만 캐싱!

- Cache-Control: no-cache : don't cache!

Cache Server

- reverse proxy + caching function

- proxy_cache_path : level MD5 hash를 이용하여 cache item hierarchy 구성, 검색 용이

- proxy_cache_key : static entry $scheme$request_method$proxy_host$uri

dynamic (CGI) entry 는 FastCGI, SCGI, uSGI 별로 각각 cache_key가 설정되는 듯. (추가 연구 필요)