Cache vs Cookie vs Session

 

 

Cahce

주어진 리소스의 복사본을 저장하고 요청 시에 그것을 서브하는 기술.

 

목적

변경되지 않은 리소스에 대해 서버에 요청하기 전에 이미지 등을 클라이언트(웹 브라우저) 단에서 처리하여 서버의 로드량 (부하) 감소 -> 성능 향상

 

private cache(browser) : 단일 사용자에게 초점 맞춰짐. HTTP를 통해 다운로드된 모든 문서를 가지고

앞으로,뒤로 가기 등을 위해 이용 가능한 방문했던 문서를 만드는데 사용됨.

 

public cache(proxy) : 해당 네트워크 내에 조회가 자주 되는 리소스를 몇 번이고 재사용하여 network traffic, latency 감소

 

예시

방문했던 페이지 접속시 css/js, jpg, png 등의 리소스 파일을 Client PC 에서 로드

---

Cookie

서버가 사용자의 웹 브라우저(클라이언트)에 전송하는 작은 데이터 조각.

일반적으로는 브라우저가 닫히면(클라이언트 종료시) 만료되고

영속적 쿠키가 있고 만료일(지속시간)이 명세되어 만료된 쿠키는 더이상 보내지지 않음.

목적

세션 관리(HTTP Stateless, Connectionless 를 보완), 개인화, 트래킹

HTTP Header 안에 포함되어 요청시마다 전송함.

 

 

예시

팝업창 '오늘 다시보지 않기' (duration 당일 자정) // Coockie의 Duaration은 Client-Side 시간 기준이다.

방문했던 사이트 재방문시 ID/PW 자동 입력

 

연결 과정

1. HTTP Request Header에 쿠키를 포함하여 요청 (없으면 요청)
2. 1에서 기존 쿠키가 없었다면 서버로부터 HTTP Response Header의 Set-Cookie 속성을 이용 받음.
3. 2에서 받은 쿠키를 명시된 만료기간 동안 보존 (없다면 브라우저 종료시 만료)
4. 만료 전까지 HTTP Header에 쿠키 정보를 담아 Request 

---

Session

서버에 저장되는 쿠키(세션 쿠키), 프로토콜에서의 세션은 통신간 연결 상태를 의미한다.

방문자가 웹 서버에 접속해 있는 상태도 하나의 세션이다.

 

 

예시

새 페이지를 요청하는 동안에도 로그인이 풀리지 않고 로그아웃 전까지 유지.

 

 

연결 과정

1. Client에서 HTTP Request 요청
2. Server는 해당 Client 에 대한 Session ID를 생성&저장
3. HTTP Response Header에 'Set-Cookie' 속성을 이용해 클라이언트에 쿠키 제공 // 여기에 Cookie 이름, 값,Duration, 경로 등이 저장됨
4. Client HTTP Request Header에 담긴 쿠키 정보(JSessionID)로 클라이언트를 판별.

서버 자체에 저장된 서버 쿠키와 클라이언트의 쿠키정보를 대조하여 각 클라이언트에 맞는 서비스를 제공한다.

 

---

[Coockie vs Session]

구분	Coockie	Session
위치	Client	Server
형식	Text	Object
만료 시점	일반적으로 클라이언트(웹 브라우저) 종료시 Persistent Cookie 의 경우 명시된 기간(Max-Age) 혹은 날짜(Expires) HTTP Header에 쿠키 만료 기간을 명시할 수 있다.	브라우저 종료시 삭제 // 클라이언트 단에서 Duration을 지정하지 않은 경우 Client Cookie와 Session Cookie의 생명 주기는 같다. (마찬가지로 기간 지정 가능)
용량 제한	총 300개 하나의 도메인 당 20개 쿠키당 4KB(4096byte)	X
속도	상대적으로 빠름	상대적으로 느림
보안	취약	상대적으로 강함

 

---

[HTTP Message 쿠키 분석 예제]

사용 툴: WireShark

테스트 서버 페이지 : testing-ground.scraping.pro/login (Destination IP : 204.15.135.8)

 

1. 테스트 서버 페이지에 접속한다.

서버에 GET메소드로 접속한 것 만으로도 서버에서 Set-Cooke를 담는다. 

메인 페이지에 접속으로 응답하는 Set-Cookie 값 tdsess=deleted (삭제됨) 이다.

따라서 클라이언트의 다음 request header에도 쿠키값이 포함되어 있지 않다.

 

2. 잘못된 아이디와 패스워드로 로그인을 시도한다

id와 pw 모두 test로 입력한다.

id와 pw를 모두 test로 입력했더니

 

해당 페이지는 admin/12345로 입력해야 정상적으로 로그인된다.

잘못된 값 입력으로 로그인 실패하니 서버로부터 응답 헤더에 역시나 Set-Cookie 값이 deleted 상태이다.

로그인에 실패하니 마찬가지로 server로부터 부여받은 jsessionID는 없다. (deleted)

 

3. 올바른 아이디와 패스워드로 로그인을 시도한다.

admin/12345

로그인 성공과 함께 쿠키 tdsess 값이 'TEST_DRIVE_SESSION'으로 지정되어 헤더에 포함되어있는 모습을 볼 수 있다.

 

4. 로그인된 상태로 새로고침 버튼을 눌러 해당 테스트 페이지를 재접속한다.

HTTP Request Header에 쿠키 정보 (tdess=TEST_DRIVE_SESSION) 가 들어있음을 확인할 수 있다.

클라이언트의 요청 메시지 헤더에는 서버로 부터 발급 받은 쿠키정보가 들어가있다.

 

Q. 그럼 서버는 응답 메시지 헤더에 쿠키정보를 포함할 것인가? 

A. X

그럴 필요가 없다. 서버는 내부적으로 클라이언트가 보낸 쿠키값과 비교해서 클라이언트를 식별할 뿐이다.

쿠키 값을 가지고 있지 않은 요청에 대해서만 세션 쿠키를 생성하고 쿠키 값을 헤더에 포함해 발급해줄 뿐이다.

 

 

 

이로써 쿠키-세션이 형성되는 과정과 

서버-클라이언트의 HTTP Message 속 쿠키값을 확인해보았다.

---

[Reference]

jeong-pro.tistory.com/80

ryusae.tistory.com/7

developer.mozilla.org/ko/docs/Web/HTTP/Caching

 

 

보통 개념들은 공식문서를 참조하는데

유독 캐시, 쿠키, 세션은 국내 기술블로그에 개발자 분들이 잘 정리해주셨다.

감사합니다요들~