네트워크 (7) HTTP 헤더 - 2 - 쿠키와 캐시

쿠키 ㅎ

 

 

쿠키 ( Cookie )

Cookie: <cookie-list>
Cookie: name=value Cookie: name=value;
name2=value2; name3=value3

 

쿠키란?

HTTP 쿠키는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각이다.

브라우저는 이 데이터 조각들을 저장해놨다가 동일한 서버에 재요청 시 저장된 데이터를 함께 전송한다.

무상태(statless)프로토콜에서 상태 정보를 기억시켜주는 역할을 한다.

* 쿠키는 네트워크 트래픽을 추가적으로 유발할 수 있다.

* 쿠키는 최소한으로 사용되고, 최소한의 정보만 입력되어야 한다.

* 서버에 전송하지 않고 localStoreage, sessionStorage라는 웹 스토리지를 이용하는 방법도 있다.

 

 

쿠키의 주 사용처는?

> 세션 관리 : 서버에 저장해야 할 로그인 상태, 장바구니, 게임 스코어 등의 정보 관리.

> 개인화 : 사용자 선호, 테마 등의 세팅.

> 트래킹 : 사용자 행동을 기록하고 분석하는 용도.

 

 

쿠키의 생명 주기는?

1. Set-Cookie

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

> 만료일이 되면 쿠키 삭제

2. Set-Cookie

Set-Cookie: max-age=60 ( 가장 권장되는 방법이다. )

> 해당 시간이 만료되면 쿠키 삭제(sec)

3. 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료 시까지만 유지.

4. 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지.

 

 

쿠키의 스코프?

> Domain 속성으로 호스트를 명시할 경우 : 명시한 문서 기준 도메인과 서브 도메인까지 쿠키가 적용된다.

예시 ) domain = myblog.com .. sub.myblog.com에도 적용된다.

> Domain 속성을 사용하지 않았을 경우 현재 문서 위치의 호스트를 기본값으로 한다.

예시 ) myblog.com에만 적용

> path 속성을 사용하면 해당 경로를 포함한 하위 페이지만 접근 가능.

예시 ) path=/category 해당 페이지 및 하위 페이지에서만 접근 가능하다.

예시2 ) path=/category 가능 path=/category/notice 가능 path=/category/notice/123 가능 path=/page 불가능

 

 

쿠키의 보안?

! 기밀 혹은 민감한 정보는 전체 메커니즘이 본질적으로 위험하기 때문에 HTTP 쿠키 내에 저장되거나 전송되어서는 안됩니다.

1. 세션 하이재킹과 XSS

> 쿠키는 주로 사용자와 그들의 세션을 식별하기 위해 사용되기 때문에 쿠키를 가로채서 하이재킹을 시도할 수 있음.(XSS 취약점)

> HttpOnly=true 값을 넣어주면 자바스크립트가 쿠키를 가로채지 못하게 만들 수 있다.

 

2. Secure Cokkies

> 기본적으로 HTTPS 프로토콜을 사용하면 쿠키 또한 암호화되어 전송된다.

> 그러나 개발자 부주의로 HTTP를 통해 유출되는 경우가 있다.

> 따라서 Set-Cokie: 쿠키명=쿠키값; path=/ secour 같이 마지막에 secure라는 접미사를 붙이면, 브라우저는 반드시 HTTPS 프로토콜을 통해서만 쿠키를 전송한다.

 

3. Same Site

> 쿠키의 보안적 문제를 해결하기 위해 만들어진 기술로써 크로스 사이트로 전송하는 요청의 경우 제한을 둔다.

> None: 크로스 사이트 요청의 경우에도 항상 전송된다. ( 기본값, 보안 문제 발생 )

> Strict: 가장 보수적인 정책. 크로스 사이트 요청에 절대로 전송되지 않는다.

> Lax: Strictd에 비해서는 느슨한 정책. 대체로 전송되지 않으나 몇가지 예외적인 요청에는 전송된다.

 

 

 

캐시 ( Cache )

 

캐시란?

캐싱이란 주어진 리소스의 복사본을 저장하고 있다가 필요 시 제공하는 것.

웹 캐시가 저장소 내에 리소스를 가지고 있다면 서버로부터 리소스를 받는 것이 아니라 복사본을 반환한다.

> 모든 클라이언트를 서비스할 필요가 없어지므로 서버의 부하를 완화한다.

> 빠른 사용자 경험.

예시) 특정 사이트에 처음 접속할 때보다 다시 접속할 때 더 빠르게 로드된다.

 

 

캐시 검증과 조건부 설정

1. 검증 헤더

> 캐시 데이터와 서버 데이터가 같은지 검증하는 헤더.

> Last-Modified와 Eta 중 하나로 검사한다.

 

2. 조건부 헤더

> 검증 헤더로 조건에 따라 어떻게 할지 결정을 내린다.

 

2-1. 검증 방식이 Last Modified인 경우

> 날짜 기반 검증 (최종 수정일)

> 조건이 만족한다면 200 OK

> 조건이 만족하지 않는다면 304 Not Modified

> 304 Not Modified가 캐시가 유효하다는 의미이다. 헷갈리면 300번대 상태코드는 리다이렉션이라는 사실을 상기해보자.

예시 )

if-Modified-Since == LastModified?

-> 304 Not Modified 데이터 없이 헤더만 응답한다.

> 내용이 바뀐 것 없이 수정 작업으로 인해 LastModified만 변경되어도 리소스를 다시 보내야한다는 단점이 있다.

> 주석이나 공백 같은 경우 캐시를 유지하고 싶다면 아래의 Etag 방식을 채택해야 한다.

 

2-2. 검증 방식이 Etag인 경우

> 캐시 데이터에 임의의 버전 이름을 달아둔다.

> 데이터가 변경된다면 이 이름을 변경한다. (HashCode를 사용한다)

> 클라이언트는 캐시가 어떤 로직으로 관리되는지 전혀 알 수 없고, 서버에서 원하는대로 캐시를 제어할 수 있다.

예시) Etag: "v1.0" -> 변경될 경우 Etag: "v1.1"

 

 

캐시 제어 헤더의 종류

1. Cache-control

> Cache-control: max-age

: 캐시의 유효시간을 초 단위로 설정한다.

> Cache-control: no-cache

: 캐시 복사본을 사용자에게 보여주기 전에 재검증을 위한 요청을 원서버(origin server)로 보내도록 강제한다.

> Cache-control: no-store

: (민감한 정보이기 때문에) 캐시는 클라이언트 요청 혹은 서버 응답에 관해 어떤 것도 저장해서는 안됨.

> Cache-control: public

: 응답이 어떤 캐시에 의해서든 캐싱되어도 된다는 것을 의미.

> Cache-control: private(기본값)

: 응답이 해당 사용자만을 위한 것이며 공유 캐시에 의해 저장되지 않아야 한다는 것을 의미. 단 사설 캐시는 응답을 저장할 수도 있음.

> Cache-Control: s-maxage

: (프록시 같은) 공유 캐시에만 적용되며 사설 캐시에 의해서는 무시되는 max-age 값.

 

2. Pragma

> HTTP/1.1버전에서 Cache-control 헤더가 생기기 전 1.0버전에서 사용되던 하위호환 헤더.

 

3. Expires

> 캐시의 만료일을 나타내는 제어 헤더.

> max-age와 달리 연, 월, 일을 기준으로 캐시 만료일을 지정함.

> Cache-control의 하위 호환으로 max-age 값이 주어진다면 Expires의 값은 무시됨.

 

 

프록시 캐시

공유 캐시는 한 명 이상의 사용자에 의해 재사용되는 응답을 저장한다.

예를 들어 특정 사이트에서 사람들이 많이 보는 컨텐츠는 프록시 캐시를 저장해놓기 때문에 조회수가 낮은 컨텐츠보다 로딩이 빠른 것이 프록시 캐시의 대표적인 예시이다.

첫번째 유저는 느리지만 유저가 많고 자주 조회될수록 속도가 빨라지는 이점이 존재한다.

참고로 우리가 사용하는 KT나 SKT 등의 인터넷 사업들이 각 지역의 네트워크를 프록시 서버로 묶어 인터넷에 연결시키고 있기 때문에 우리는 항상 지속적으로 프록시 캐시를 이용하고 있다.

 

 

캐시를 무효화하기 위한 방법

Cache-control : no-cache, no-store, must-revalidate
Pragma: no-cache

> 웹 브라우저가 임의로 캐싱하는 경우가 있기 때문에 정말 캐시에 저장하지 않아야할 데이터는 강제로 지정해서 캐시를 막아야한다.

(위의 모든 코드를 다 넣어줘야 한다. )

> Cache-control: no-cache 데이터 사용 전 항상 원서버에 검증

> Cache-control: no-store 해당 응답은 캐시에 저장되면 안됨

> Cache-control : must-revalidate 캐시 만료 후 최초 조회시 원서버에 검증 받고, 검증 실패 시 반드시 상태코드 504 발생.

> Pragma : HTTP 1.0 하위 호환을 위한 코드

 

* no-cache에 이미 원서버 검증 조건이 있는데 must-revalidate를 추가하는 이유는 no-cache로 보냈어도 원서버에 접근할 수 없는 경우 프록시 캐시에서 처리하는 경우가 있다. 이렇게 될 경우 아예 504 응답 코드로 접속 자체를 차단해버리려는 것이다.