쿠키
HTTP가 Stateless 프로토콜임을 고려할 때, 클라이언트가 로그인했다면 서버에게 자신이 로그인한 것을 알려주기 위해 모든 요청에 로그인 정보를 넘겨야 합니다.
이러한 방식은 개발에도 보안에도 문제가 있기 때문에 쿠키라는 것을 사용합니다.
- 사용처 : 사용자 로그인 세션 관리, 광고 정보 트래킹
- 쿠키 정보는 항상 서버에 전송되며 보안에 민감한 데이터는 저장하면 안됩니다.
쿠키는 브라우저 세션과 관계없이 디스크에 기록되기 때문에 생명주기를 정해주어야 합니다.
-
Expires = 날짜형식 > 만료일이 되면 쿠키를 삭제합니다.
-
max-age = 300(초단위) > 0이나 음수를 지정하면 쿠키를 삭제합니다.
-
세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료 시 까지만 유지됩니다.
-
영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지됩니다.
캐시
캐시의 유무는 서버에서 클라이언트로 전송하는 데이터 양에 상당한 차이를 가져옵니다.
-
Cache-Control : max-age
- 캐시 유효 시간, 단위
-
Cache-Control : no-cache
-
데이터는 캐시해도 되지만, 항상 원(서버)에 검증하고 사용
일부 프록시 캐시 서버에서 확인하는 경우가 있다고 합니다.
-
-
Cache-Control : no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨
cache-control을 통해 일정 시간 유효한 응답 결과를 유지할 수 있습니다. 하지만 캐시 시간이 초과된다면 어떻게 될까요? max-age가 60이라면 60초마다 새로고침을 하게되면 캐시가 의미가 없어집니다.
이런 문제를 해결하기 위해 검증부 헤더를 이용합니다.
캐시가 만료 후에도 서버에서 데이터가 변화하지 않았음을 알려주는 헤더는 다음과 같습니다.
요청 : if-modified-since
응답 : Last-Modified
304 응답은 Response 바디가 없습니다. 따라서 서버에서 재 다운로드해야될 데이터는 없고 헤더를 통해 데이터가 변경되었는 지를 판단합니다.
이 방법도 단점은 있습니다. 1초 미만 단위로 캐시 조정이 불가능하고, 서버에서 별도의 캐시 로직을 관리하고 싶어도 날짜로만 처리해야합니다
ETage는 캐시용 데이터에 임의의 고유한 버전 이름을 달아 데이터가 서버와 클라이언트가 가지고 있는 이름을 비교하여 다를 경우에만 다시 데이터를 전송합니다.
