쿠키
-
쿠키를 설명하기전에 HTTP특징에 대해 먼저 알아야한다
-
HTTP는 무상태(Stateless)프로토콜이다.
-
클라이언트와 서버거 요청과 응답을 주고 받고 연결이 끊어진다.
-
다시 요청하면 이전 요청 기억 못함
->쿠키는 이 문제를 해결 해준다.
-
서버에서 보낸 쿠키를 웹브라우저의 쿠키저장소에 쿠키를 저장한다.
-
이렇게 단순히 쿠키만 사용하면 보안위험이 너무 크다.
-
그래서 이런식으로 쿠키마다 sessionid를 부여를 한다.
-
주로 사용자 로그인 세션관리 사용한다.
-
쿠키 정보는 항상 서버에 전송된다. -> 네트워크 많은 트래픽 유발!
-
네트워크에 전송하지 않고 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 를 사용한다.
-
중요한 정보는 적지 않는다.
쿠키 path, domain
domain
-
명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
-
domain=example.org를 지정해서 쿠키 생성
- example.org는 물론이고
- dev.example.org도 쿠키 접근
- 생략: 현재 문서 기준 도메인만 적용
- example.org 에서 쿠키를 생성하고 domain 지정을 생략
- example.org 에서만 쿠키 접근
- dev.example.org는 쿠키 미접근
path
- 예) path=/home
- 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
- 일반적으로 path=/ 루트로 지정
쿠키 보안
Secure
- 쿠키는 http, https를 구분하지 않고 전송
- Secure를 적용하면 https인 경우에만 전송
HttpOnly
- XSS 공격 방지
- 자바스크립트에서 접근 불가(document.cookie)
- HTTP 전송에만 사용
SameSite
- XSRF 공격 방지
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
캐시
-
캐시란 쉽게 설명 하자면 클라이언트에서 서버로 무엇인가를 요청하고 그것을 다시 재요청 했을때 서버가 데이터들을 다 다시 받고 만들고 하는것을 방지하기 위한 것이다.
-
캐시가 없으면 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운받아야한다.-> 브라우저 속도 느려짐
-
캐쉬를 사용하면 처음 데이터를 받을때 서버에서 cash control을 심어서 보낸다.(캐쉬의 생명주기 포함)
-
캐쉬를 브라우저의 캐쉬저장소에 보관한다.
-
똑같은 데이터를 재 요청 하면 서버와의 통신은 하지않고 캐쉬저장소에서 바로 꺼내서 사용한다.
-
하지만 캐시 생명주기가 끝나면 다시 서버에 요청하고 다운 받아야한다.
-> 이를 해결하기위해 검증 헤더와 조건부 요청 을 사용한다
캐시 시간 초과
서버에서 기존 데이터 변경x , (캐시 시간초과)
- 시간은 지났지만 캐시에 있는 캐시에 있는 데이터는 같으니 재사용 할수 있지 않을까?
검증헤더(Last modified)
- 서버 응답시 Last-Modifeid 를 심어서 응답한다
-
재 요청시 Last-Modifed 를 확인한다. 변화가 없으면 데이터도 변화가 없다는 뜻이므로 응답을 할때는 헤더만 보내고 바디는(데이터가 똑같으니까) 보내지 않는다.
-
이 헤더를 받은뒤 캐쉬 생명주기가 자동으로 갱신되 다시 사용 가능하다.
검증헤더(Etag)
- 클라이언트 쪽이 아닌 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
ETag
-
캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다
-
데이터가 변경되면 이 이름을 바꾸어서 변경함(hash를 다시생성)(content가 같으면 같은 hash반환)
-
단순한게 Etag만 보내서 같으면 유지, 다르면 다시 받기
-
기본적인 원리는 lastModifed랑 비슷하다.
-
캐시 제어 로직을 서버에서 완전히 관리
-
클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
cashe-Control
1. cash-Control:max-age
-캐시 유효시간,초 단위
2. cashe-Control:no-cashe
-데이터는 캐시해도 되지만 ,항상 원(origin) 서버에서 검증 하고 사용
3.cashe-Control:no-store
-데이터에 민감한 정보가 있으므로 저장 x
4Cache-Control: public
-응답이 public 캐시에 저장되어도 됨
5Cache-Control: private
=응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
cashe-Control- 무효화
1.Cache-Control: no-cache
-데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
2.Cache-Control: no-store
-데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)
3.Cache-Control: must-revalidate
-캐시 만료후 최초 조회시 원 서버에 검증해야함
-원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
-must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
4.Pragma: no-cache
-HTTP 1.0 하위 호
프록시 캐시
-
보통 클라이언트와 원 서버 사이에 프록시 가 존재한다.
-
원서버의 대리인(?) 이라고 생각 하면 쉽다. 첫 데이터 요청시에 시간은 약간 걸리겠지만 그 다음으로는 중간 대리인이 데이터를 가지고있어 원 서버까지 가서 요청을 할 필요가 없다.
no-cache vs must-revalidate
- no-cache는 원 서버에서 검증 해야 하므로 프록시 객체말고 원서버에서 검증 한뒤 사용한다
둘다 원서버에서 검증 하는데 무슨 차이야??
-
프록시와 원서버 연결이 끊겼을때 no-cache는 오류말고 옛날 데이터라도 보여주자! 라는 식이고
-
must-revalidate는 아예 오류 페이지를 내버린다(통장 잔고 등)
