웹 최적화 캐시 Etag, Cache-Control

 캐시 전략은 클라이언트와 서버에 각각 적용할 수 있다. 중요한 점은 서버에 I/O Call를 발생시키지 않아야 좋은 것이다.

 서버에서 Redis나 Ehcache 활용하거나, 아니면 DB 수준에서 캐싱을 사용하든가 등등 서버단에서도 지원할 수 있는 방법은 많다. 하지만 중요한 건 사용자가 Call를 요청의 수가 적으면 서버단의 CPU를 쓰지 않을 수 있다. 그런 기법의 예로는 디바운싱도 있다. 디바운싱은 화면의 UI를 변경을 억제하는 데 쓰일 수도 있지만 Call을 여러 번 쏘지 않도록 유도할 수도 있다. 클라이언트 단, 아니 Http Cache에 대해 소개해보려고 한다.

우린 결국 Http Call를 무조건 요청한다. 이는 Html, css, Js 등 모든 리소스를 받을 때 모두 통용된다. 이런 Http 헤더에 Cache-Control key에 value를 넣어 value에 적혀있는 시간만큼 Client에 있는 값을 쓸 수 있도록 할 수 있다. Cache-Control에 적혀있는 시간이 지나면 기존과 동일하게 실제 Call이 요청된다.

이 Cache-Control과 독립적으로 사용할 수 있는 친구는 Etag다. Etag는 반환되는 리소스의 값을 해시로 준다. 그리고 해당 값을 서버로 Client가 자동으로 보내고, 또한 스프링의 경우에는 Filter를 이용하거나 직접 request header에서 Etag를 꺼내서 직접 비교해도 된다. Etag의 Hash 값은 어떻게 만들어질까? Md5Utils.java를 이용해서 만들어진다.