8_http 헤더_쿠키(cookie), 캐시(cache)

@쿠키

○ 정의
 - 서버에서 클라이언트로 보내는 정보들을 저장하기 위해 사용됨
 - 보통 사용자 인증을 위해 사용됨(로그인 정보, 방문기록 등등)
 
○ 쿠키
 - Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
 - Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
 ※ http는 무상태(Stateless)프로토콜임으로 요청과 응답을 받으면 연결이 끊어지고
   클라이언트가 재요청시 서버는 이전 요청을 알지 못하기 때문에 다른 요청시 계속 
   데이터를 전달해야 하는 상황 -> 이를 해결하기 위한것이 쿠키!!
 
○ 쿠키의 생명주기
 - expires : 만료일이 되면 쿠키 삭제
 - max-age : 쿠키 생명주기(시간) 설정(0이나 음수를 설정하면 삭제됨)
 - 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지됨
 - 영속 쿠키 : 만료 날짜를 설정하면 해당 날짜까지만 유지됨

○ 도메인(Domain)
 - 명시하였을 경우 기준 도메인과 서브 도메인을 포함됨
 - 생략하였을 경우 기준 도메인만 적용됨
 
○ 경로(Path)
 - 경로를 포함한 하위 경로까지만 쿠키 접근(보통 path=/ 로 지정)

○ 보안
 - Secure : 명시하였을 경우 https의 경우에만 전송
 - HttpOnly : 명시하였을 경우 http 전송에만 사용되고 
              자바스크립트에서 접근안됨(document.cookie)
  ㄴ> XSS 공격방지
 - SameSite : 요청 도메인과 쿠키에 설정된 도메인이 같을 경우만 쿠키 전송
  ㄴ> XSRF 공격방지

@캐시

○ 정의
 - 웹 페이지 요소를 저장하기 위한 임시저장소
 - 웹 페이지를 빠르게 렌더링 하기 위해 사용됨(이미지, 문서, 비디오 파일 등)
   ㄴ 캐시를 사용하지 않을 시 데이터가 변경되지 않아도 계속 네트워크를 
     사용하여 데이터를 받아야 됨으로 인해 로딩 속도가 느려지게됨

○ 캐시 유효 시간 초과(캐시 만료)
 - 유효 시간이 초과(캐시 만료)되서 서버에 다시 요청할 경우 두가지 케이스가 생김
  1) 서버에서 기존 데이터를 변경한 경우
  2) 서버에서 기존 데이터를 변경하지 않은 경우
    ㄴ 이 경우 데이터를 다시 받을 필요가 없음, 데이터가 같은 사실을 확인 할 수
  있는 경우 클라이언트쪽 캐시(기존 데이터)를 재사용 해도됨

○ Last-Modified, If-Modified-Since 검증(조건부 요청 헤더)
  1) 첫번째 요청시 서버에서 헤더에 Last-Modified : "날짜"를 넣어서 클라이언트에게 전달
  2) 브라우저 캐시에 데이터 최종 수정일로 저장
  3) 두번째 요청시 헤더에 if-modified-since : "날짜"를 넣어서 서버에 전달
  4) 서버에서 데이터 최종 수정일이 같을 경우 데이터가 수정되지 않음을 확인
  5) 서버에서 304 Not Modified상태로 헤더만 클라이언트에게 전달
  6) 클라이언트는 304 Not Modified를 받고 브라우저 캐시에서 조회해서 재사용

○ Last-Modified, If-Modified-Since의 단점
  1) 밀리세컨드 단위로 캐시 조정이 불가능
  2) 날짜 기반 로직 사용
  3) 데이터를 수정했다가 다시 원복했을 경우 날짜는 변경되지만 데이터는 그대로임
  4) 서버에서 캐시 로직이 관리 안됨

○ ETag(Entity Tag)
 - Last-Modified, If-Modified-Since의 단점 보안
 - 캐시 데이터에 임의의 버전이름을 달아둠 
  ex) ETag: "v0.1", ETag: "asdf1"
 - 데이터가 변경시 버전이름을 변경(Hash 재생성)
  ex) ETag: "v0.1" -> ETag: "v0.2"
 - ETag의 버전이름이 같으면 유지, 다를 경우 캐시를 다시받음
 - 캐시 제어 로직을 서버에서 완전 관리

○ ETag(Entity Tag), IF-None-Match 검증(검증 헤더)
  1) 첫번째 요청시 서버에서 헤더에 ETag : "태그명"을 넣어서 클라이언트에게 전달
  2) 브라우저 캐시에 ETag : "태그명" 저장
  3) 두번째 요청시 헤더에 IF-None-Match : "태그명"을 넣어서 서버에 전달
  4) 서버에서 태그명이 같을 경우 데이터가 수정되지 않음을 확인
  5) 서버에서 304 Not Modified상태로 헤더만 클라이언트에게 전달
  6) 클라이언트는 304 Not Modified를 받고 브라우저 캐시에서 조회해서 재사용
  
○ 캐시 제어 헤더
 - Cache-Control: 캐시 제어
  1) Cache-Control: max-age 
     ㄴ 캐시 유효 시간, 초 단위
  2) Cache-Control: no-cache
     ㄴ 데이터는 캐시해도 되지만, 원(origin) 서버에 검증하고 사용, 이름 주의!
  3) Cache-Control: no-store
     ㄴ 민감한 정보가 있으므로 메모리에서 사용하고 최대한 빨리 삭제
 - Pragma: 캐시 제어(하위 호환)
   ㄴ Pragma: no-cache, HTTP1.0 이하
 - Expires: 캐시 유효 기간(하위 호환)
   ㄴ expires: Mon, 01 Jan 1990 00:00:00 GMT
   ㄴ 정확한 날짜로 만료일 지정, HTTP1.0 이하, Cache-Control: max-age 권장하고 우선순위높음

○ 프록시 캐시
 - 클라이언트와 원서버사이에 있는 프록시캐시서버
 - 클라이언트(private 캐시) <-> 프록시캐시서버(public캐시) <-> 원서버

○ 기타 Cache-Control: 캐시 제어
 - Cache-Control: public
   ㄴ 응답이 public 캐시에 저장되어도 됨
 - Cache-Control: private
   ㄴ 응답이 해당 사용자만을 위한 캐시, private 캐시에 저장해야함(default값)
 - Cache-Control: s-maxage
   ㄴ 프록시캐시에만 적용되는 max-age
 - Age: 60(HTTP 헤더)
   ㄴ origin서버에서 응답 후 프록시 캐시 내에 머문 시간(초단위)

○ 캐시 무효화
 - Cache-Control: no-cache, no-store, must-revalidate
 - Pragma: no-cache 
 ※ must-revalidate : 캐시 만료후 최초 조회시 원서버(origin)에 검증해야함
   ㄴ 만약 프록시캐시서버와 원서버 간에 장애가 발생할 경우 no-cache의 경우 Error or 200 OK를 
     브라우저에 보냄, 이를 방지하기 위해 must-revalidate를 사용했을시 프록시캐시서버와 원서버간에
     장애 발생시 504 Gateway Timeout를 프록시 캐시서버에서 클라이언트에게 전달