HTTP 캐시 (캐시, 조건부 요청, 캐시 VS 쿠키?)

 Cache

캐시는 한번 사용한 데이터를 복사하여 사용자한테 저장하는 공간으로 빠른 사용자 경험을 제공한다. ( 그냥 내가 정리한 거야~) 사용자가 어느 이미지를 다운로드하였다. 나중에 다시 같은 이미지를 요청할 때 캐시가 아직 유효하다면 서버에서 가져오는 것이 아니라 캐시에서 이미지를 가져온다. 결과적으로 다운 속도도 빠르고 네트워크 사용량을 줄일 수 있다. 

 

max-age

서버에 데이터를 요청했을 때 HTTP 응답 메시지.

  cache-control: max-age=은 캐시가 유효한 시간을 설정한다. 이 부분이 왜 필요할까?? 데이터가 수정되었을수도 있기 때문이다. 서버에서 같은 uri의 데이터를 수정했는데 계속 캐시에서만 가져오면 클라이언트한테는 수정 데이터가 반영되지 않기 때문이다. max-age는 초 단위로 설정한다. 그렇다면 캐시의 유효 시간이 끝난 경우에는 어떻게 동작할까? 이때도 캐시의 유용성이 나타난다.

캐시 유효 시간이 끝났을 경우 HTTP 응답 메시지

 Last-Modified,  if-modified-since

  캐시의 유효 시간이 끝난 경우에도 곧바로 서버에서 데이터를 다시 받아오지않는다. 일단 캐시에 저장된 데이터가 서버에서 수정이 일어났는지 검증한다. 이때 필요한 헤더가 if-modified-since 조건부 요청, Last-Modified 검증헤더이다. 뜻 그대로 데이터가 최종 수정된 날짜를 담는다. 유효 시간이 끝난 경우 클라이언트에서 서버로 재요청할 때 처음 응답 때 받았던 Last-Modified에 담긴 날짜를 조건부 요청에 담아서 보낸다. 이 날짜 이후로 수정했는데 확인하는 것이다. 서버에서 해당 날짜와 last-modified를 비교한다. 같으면 수정이 일어나지 않은 것이므로 위의 그림처럼 메시지를 보낸다.

304 Not Modified 수정 되지않았으니까 리다이렉션해~ 라는 뜻이다. 어디로 리다이렉션해?? 너가 갖고 있는 캐시로 리다이렉션해~ 또한 그림에서 볼 수 있듯이 메시지 바디에 데이터가 담기지 않아서 전송 속도도 빠르고 용량도 적어진다.

 수정이 일어났으면 200 OK와 함께 서버에서 URI를 보내준다.

 Last-Modified, If-Modified-Since에도 단점이 있다. 날짜 기반 로직을 사용하다보니 A의 데이터를 B로 바꿨다가 다시 A로 복구한 경우에도 마지막에 복구한 시점이 Last-Modified에 저장되다 보니 데이터를 다시 뿌려야 한다. 서버서 캐시 로직을 따로 관리할 수가 없다. 그래서 나온 것이 바로~ 

 Etag,  If-None-Match

ETag, If-None-Match이다. ETag는 데이터에 Hash값을 주는 것이다. Hash값이므로 위에서 말한 예시에서처럼 수정하다가 원상태로 복구된 경우에 같은 Hash 값을 갖게된다. 값을 재요청할 때 If-None-Match로 수정 여부를 확인한다. 해시 설계를 할 수 있으므로 제어 로직을 서버에서 관리 가능해진다.

 

 프록시 캐시

 프록시 캐시는 가짜 서버를 만드는 것이다. 프록시 캐시는 유튜브로 예를 들면 이해가 한 번에 된다. 프록시 캐시가 없었다면 우리가 유튜브를 볼 때 영상을 미국의 서버에서 가져와야 한다. 너무 멀다. 그래서 한국에 프록시 캐시 서버를 도입한다. 

 한국에 있는 유저가 영상을 요청하면 미국에 있는 원 서버(Origin server)가 아니라 한국에 있는 서버에서 데이터를 가져온다. 캐시 역할을 하는거지~ 여기서 재밌는게 한국에 있는 서버는 프록시'캐시'서버이니까 처음 영상을 보는 사람은 원 서버에서 가져와야 해서 속도가 느리다고 한다 ㅋㅋㅋㅋㅋ 그래서 사람들이 잘 안 보는 영상 볼 때 속도가 느리다고 한다 ㅋㅋㅋ

 

 캐시 지시어(Cache-Control)

• Cache-Control: no-cache - 이름에 주의해야한다. 캐시가 없다는 뜻이 아니다. 데이터를 캐시 해도 되는 데 사용하기 전에 무조건 프록시 서버가 아닌 원 서버에 검증을(위에서 했던 if-modified-since, if-none-match 이런 거) 진행하고 사용하라는 뜻이다.
• Cache-Control: no-store - 데이터가 민감한 정보를 포함하므로 저장하지말고 사용하고 바로 삭제하라는 뜻이다.
• Cache-Control: must-revalidate - 캐시 만료후 최초 조회 시 원 서버에 검증해야 한다. (no-cache와의 차이가 뭐지?) 

 캐시를 무효화하고 싶은 경우는 무조건 위에 3개 다 작성해줘야 확실하게 무효화된다.

 

 no-cache? must-revalidate? 둘 다 기능이 비슷해보이는데 따로 존재하는 이유가 무엇일까?

 no-cache는 원서버에 검증을 진행하려하는데 네트워크 오류든 어떤 이유로 원서버에 접근이 불가능한 경우 서버 설정에 따라서 오류를 보낼 수도 있고 오류를 보낼 바에 그냥 프록시 캐시에서 접근하자~ 하고 데이터를 전송할 수 있다.

 must-revalidate는 말 그대로 무조건. 재검증해. 원서버에. 원서버 접근 불가하면 그냥 바로 오류 보내야 한다. 중요한 데이터인 경우 사용하면 되겠지~

 

 캐시 VS 쿠키

듣다보니까 저번에 공부했던 쿠키랑 캐시의 차이점이 떠오르지 않았다. 구글링을 좀 해본 결과 간단하게 정리하자면

캐시는 같은 파일 계속 다운하지 않도록 효과적으로 네트워크를 사용할 수 있게 도와준다.

쿠키는 http의 무상태 때문에 발생하는 문제를 해결해준다. 로그인하고 사용자의 이름을 기억하고 싶은데 http는 할 일이 끝나면 연결을 끊기 때문에 원래 상태를 기억하지 못한다. 이걸 쿠키로 해결하는 거다.

 

 

http 다 들었다. jpa 본격적으로 들어야 하는데 좀 무섭구나 ㅋㅋ

 

https://inf.run/QTy9

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의