📚독서 스터디

7주 차 7장은 캐시... 7장까지 책을 읽으면서 느낀 점은 내가 이 책을 과연 얼마나 효율적으로 읽고 내것으로 만들고 있는가에 대한 의구심이랄까... 지금은 약간 키워드를 접하는 수준인거 같습니다. 읽어도 완벽하게 이해했다고 보기도 힘들고, 외우고 있지도 않으니까. 결국 사용해야 내가 써 본 기술이 되고, 직접 만져봐야 기억에 오래 남을 테니까. 분명 좋은 책이라는 생각이 드는데, 이놈의 머리가 나빠서인지 좋은 공부 방법이 떠오르진 않네요. 그래도 언젠간 웹이라는 큰 그림의 기둥을 받쳐줄 만한 커다란 기둥이 되어줄 것이라 믿고...

🧐캐시

개발하면서 캐시라는 용어는 곳곳에서 참 많이 듣는다. 나한테 캐시가 뭐야? 라고 물어보면...

사본을 저장 해 놓는거야. 그러니까 원본 파일이 있을텐데, 사용자가 그 파일에 접근하려고 할 때, 유저의 요청이 원본 파일까지 갈 필요도 없이(물론 사본이 생성되어 있다는 가정하에), 또는 재요청 할 필요도 없이 사본을 바로 건네주는거야.

책에서는 캐시를 다음과 같이 소개한다.

웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다.
1. 캐시는 불필요한 데이터 전송을 줄여주고(비용 감소)
2. 네트워크 병목을 줄여주고
3. 원 서버에 대한 요청도 줄여주며(서버 부하 줄임)
4. 거리로 인한 지연을 줄여준다.

⚡불필요한 데이터 전송

캐시를 이용해 첫 번째 서버 응답을 캐시에 보관한다. 캐시된 사본이 뒤이은 요청들에 대한 응답으로 사용된다. 트래픽 낭비를 줄일 수 있다.

🚗대역폭 병목

클라이언트들이 서버에 접근할 때의 속도는, 그 경로에 있는 가장 느린 네트워크의 속도와 같다. 만약 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 선능을 대폭 개선할 수 있을 것이다.

💦갑작스런 요청 쇄도(Flash Crowds)

사람이 급격하게 몰릴 때! 캐싱은 매우 중요한 역할을 한다.

🛫거리로 인한 지연

대역폭이 문제가 아니더러라도 거리가 문제가 될 수 있다. 거리가 먼 만큼 가까운 곳에 캐시를 설치한다면 문서가 전송되는 거리를 수천 킬로미터에서 수십미터로 줄일 수 있다.

💥적중과 부적중

캐시에 요청이 도착했을 때, 그에 대응하는 사본이 있다면 캐시 적중(cache hit) 이라고 하며, 대응하는 사본이 없다면 그냥 원 서버로 전달되기만 할 뿐이다. 이를 캐시 부적중(cache miss)이라고 한다.

🔄 재검사

웹 콘텐츠는 변화가 잦다. 때문에 캐시는 반드시 그들이 갖고 있는 사본이 최신인지 서버를 통해 점검해야 한다. 클라이언트가 사본을 요청했으며 그 사본이 검사를 할 필요가 있을 정도로 오래된 경우에만 재검사를 한다.

컨텐츠가 변경되지 않았어! -> 304 Not Modified 응답

재검사는 순수 캐시 적중보다는 느리지만, 캐시 부적중보다는 빠르다.

• if-Modified-Since 헤더
  Get 요청에 이 헤더를 추가하면 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미다.

🤔적중과 부적중은 어떻게 구별해?

불행히도 두 응답 모두 200 OK가 될 것이다. Date헤더를 이용해서 구별이 가능한데, 응답의 Date 헤더 값을 현재 시각과 비교해서, 응답의 생성일이 더 오래되었다면 클라이언트는 응답이 캐시된 것임을 알 수 있다. 외에도 Age헤더를 사용하는 방법도 있다.

✅캐시 처리

기본적인 캐시 처리는 다음과 같다.
1. 요청 받기 - 네트워크로부터 도작한 요청 메시지를 읽는다.
2. 파싱 - 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다.
3. 검색 - 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온다. (로컬에 저장!)
4. 신선도 검사 - 사본이 충분히 신선하지 검사, 신선하지 않다면 서버에게 변경사항이 있는지 물어본다.
5. 응답 생성 - 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다.
6. 발송 - 응답을 클라이언트에게 돌려준다.
7. 로깅 - 선택적으로, 캐시는 로그파일에 트린잭션에 대해 서술한 로그 하나를 남긴다.

✨사본을 신선하게!

🙅‍♂️문서 만료

Cache-Control과 Expires라는 특별한 헤더들을 이용해서 원 서버가 각 문서에 유효기간을 붙일 수 있게 해준다. 캐시된 문서가 만료되었다면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, 신선한 사본을 얻어와야 한다.

🤸‍♀️유효기간과 나이

• Cache-Control: max-age
  문서의 최대 나이를 정의한다. 처음 생성된 이후부터, 더 이상 신선하지 않다고 간주될 때까지 경과한 시간의 최대값 Cache-Control: max-age=484200
• Expires
  절대 유효기간을 명시한다. Expires: Fri, 05 Jul 2002, 05:00:00 GMT

📌캐시 제어

❌no-cache와 no-store 응답 헤더

no-store는 캐시가 응답의 사본을 만드는 것을 금지한다.
no-cache는 사본이 로컬 캐시 저장소에 저장될 수 있다. 다만 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없다. Do Not Serve From Cache without Revalidation

📘Max-Age 응답 헤더

신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간이다.

🔥Expires 응답 헤더

더 이상 사용이 권장되지 않는다. 초 단위의 시간 대신 실제 만료 날짜를 명시한다. 이제는 만료를 절대시각 대신 경과된 시간으로 표현하는 것이 더 낫다고 판단하고 있다.

❗Must-Revalidate 응답 헤더

캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 재검사 없이는 제공해서는 안 됨을 의미한다.

🤸‍♂️휴리스틱 만료

만약 응답이 Cache-Control: max-age 헤더나 Expires 헤더 중 어느것도 포함하지 않는다면, 캐시는 경험적인 방법으로 최대 나이를 계산한다. 알고리즘의 결과로 얻은 최대 나이 값이 24시간보다 크다면, Heuristic Expiration 경고 헤더가 응답 헤더에 추가되어야 한다.

문제 1. 캐싱이 무엇인가요?
문제 2. Max-Age와 Expires 응답 헤더란?