1. Cookie의 개념
쿠키의 개념을 확인하기 전 쿠키의 등장 배경부터 알아보자.
기존의 HTTP 통신은 Stateless(비연결성, 무상태성)의 속성을 가지고 있었다. 이것은 동일한 웹 브라우저가 동일한 웹 서버에 보낼 때 자신의 정보를 매번 보내야 했으므로 효율적이지 못했다.
이러한 HTTP 통신의 Stateless한 속성을 더 효율적인 Stateful한 통신을 위해 등장하였다.
쉽게 말해 쿠키는 웹 사이트 재방문 시 효율적으로 서비스를 제공하기 위해 등장하였다.
- 쿠키 : 웹 브라우저와 웹 서버의 상태성을 표시할 수 있는 브라우저에 저장되는 <Key, Value>로 이루어진 작은 데이터 파일
그렇다면 Stateless와 Stateful의 차이와 정의를 웹 통신을 예시로 간단하게 알아보자.
- Stateless : 무상태성
- 웹 서버가 웹 브라우저의 상태를 보존하지 않음
- 웹 브라우저의 요청이 서버에 전달되었을 때, 클라이언트의 다음 요청과 이어지지 않아 매번 웹 브라우저는 자신의 정보를 웹 서버에게 전달해야 함
- Stateful : 상태 유지(상태성)
- 웹 서버가 웹 브라우저의 상태를 보존하고 있음
- 클라이언트 요청이 서버에 전달되었을 때, 클라이언트의 다음 요청이 이전 요청과 관계가 이어져 자신을 매번 증명하지 않아도 된다.
2. Cookie의 저장 장소 및 사용 기준
- 기본적으로 쿠키는 웹 브라우저의 쿠키 스토리지에 저장되어 있다.
- 또한, 쿠키에는 웹 브라우저의 상태를 알기 위해 (Key, Value, Domain, Path, Max-age, Secure)등 다양한 정보가 포함되어 있다.
- 쿠키를 사용할 기준은 Domain + Path로 이루어져 있다.
- 이 기준(Domain + Path)은 웹 브라우저가 쿠키를 웹 서버에 전송하는지 여부를 결정한다.
- 만약 웹 브라우저 내 저장되어 있는 쿠키의 리스트가 아래와 같다고 가정해보자
- 1번 쿠키 : h1 = w1 (Domain : a.com, Path : *)
- 2번 쿠키 : h2 = w2 (Domain : a.com, Path : /)
- 3번 쿠키 : h3 = w3 (Domain : b.com, Path : /hello)
- 4번 쿠키 : h4 = w4 (Domain : c.com, Path : /world)
- 위 리스트 기반으로 아래 웹 서버에 대한 요청을 따라 전송되는 쿠키 예
- 웹 브라우저에서 a.com/user/name 호출 시 1번 쿠키 전송
- 웹 브라우저에서 a.com/ 호출 시 1번 + 2번 쿠키 전송
- 웹 브라우저에서 b.com/hello 호출 시 3번 쿠키 전송
- 웹 브라우저에서 c.com/ 호출 시 어떤 쿠키도 전송하지 않음
- 만약 웹 브라우저 내 저장되어 있는 쿠키의 리스트가 아래와 같다고 가정해보자
- 이 기준(Domain + Path)은 웹 브라우저가 쿠키를 웹 서버에 전송하는지 여부를 결정한다.
3. Cookie 생성과 동작 과정
- 클라이언트(웹 브라우저)가 서버에 첫 요청과 자신의 데이터를 넘겨주며 통신을 시작한다.
- 서버는 클라이언트에 대한 상태 데이터를 웹 브라우저로 보낸다.
- 이때 웹 브라우저에게 전달되는 데이터를 Cookie라고 한다.
- 클라이언트가 동일한 서버에 다른 요청을 할 때 Cookie를 함께 보내 서버에게 자신을 증명한다.
- 서버는 클라이언트가 보낸 Cookie를 통해 클라이언트의 정보와 전에 어떤 요청을 했는지 알고 그에 맞는 응답을 보내준다.
4. Cookie의 유효 시간
쿠키의 유효 시간은 쿠키 내 데이터에 Max-age, Expries가 명시되어 있는지 여부에 따라 나뉜다.
- Persistent Cookie : 영구적인 쿠키라는 Persistent Cookie는 Expires 속성에 명시된 날짜에 삭제되거나 Max-Age가 명시된 기간 이후에 삭제된다. 영구적인 속성이라고 하는 이유는 명시된 시간 전에는 브라우저나 탭을 꺼도 계속 남아있는 쿠키이기 때문이다.
- Session Cookie : 현재 세션(탭, 브라우저)가 끝날 때 삭제되는 쿠키로 따로 유효 시간이 명시되지 않았을 때 Session이라고 명시된다.
5. Cookie 보안
쿠키의 보안에는 HttpOnly, Secure, SameSite 세가지 방법이 있다.
- HttpOnly : 자바 스크립트에서 접근 여부를 설정하는 방법
- XSS(공격자가 악성 스크립트를 삽입하여 브라우저에서 실행) 공격을 방지하기 위해 HttpOnly 옵션을 통해 자바스크립트의 API에 접근할 수 없게 한다.
- 서버에 전송하기만 하는 Cookies
- Secure : HTTPS를 활용한 암호화된 요청일 경우에만 쿠키 전송하도록 여부 결정
- SameSite : Same-Site에서만 전송 여부 설정
- cross-site 요청과 함께 전송되지 않았음을 요구하게 만들어 CSRF 공격에 대해서 방어한다.
6. Cookie 단점
쿠키의 단점은 쿠키의 두가지 특징으로 생긴다.
- 쿠키 정보가 웹 브라우저에 저장되어 생기는 단점
- 민감정보들이 안전하지 않은 채로 저장되어 있다.
- 웹 브라우저 간 공유가 불가능하다(웹 브라우저 단위의 저장소이기에 지역성 문제 발생)
- 쿠키는 Domain + Path만 일치한다면 해당 웹 서버로 모든 쿠키를 보내기 때문에 생기는 단점
- 쿠키로 저장하려는 정보가 많아질수록 요청의 크기가 커진다.
- 불필요한 네트워크 오버헤드가 발생한다.
7. Cookie 활용 예시
- 로그인 후 로그인 상태 유지
- N일동안 보지 않기
- 장바구니
8. Session의 개념
Session의 사전적 정의는 (특정한 활동을 위한)시간(or기간)을 의미한다.
기본적인 Session의 정의의 세가지 예시가 있다.(열고 -> 닫힘이 하나의 쌍)
- 로그인 세션 : 로그인 성공 -> 로그아웃 할 때 까지
- HTTP 세션 : TCP/UDP 연결 후 Request 전송 후 Response가 올 때까지
- 브라우저 세션 : 하나의 탭(or 창)이 열리고 닫힐 때 까지
하지만 쿠키 / 세션을 비교할 때의 세션은 서버에서 클라이언트와 Stateful한 통신을 위한 서버 저장소로 생각할 수 있다.
9. Session의 저장 장소
Session은 웹 브라우저와의 통신에서 Stateful한 상태를 저장하기 위한 상태 데이터(이름, 로그인, 아이디, 패스워드 등)을 웹 서버에 저장한다.
- 이때 저장되는 저장소를 Session Store라 하고 Session Store는 Session-ID를 저장하여 ID에 따른 상태 데이터를 저장한다.
- 클라이언트와 통신 할 때 Session_ID를 쿠키에 담아 봗아 서버는 Session ID를 찾아 클라이언트와 통신의 Stateful한 상태를 유지한다.
10. Session의 동작 과정
- 클라이언트(웹 브라우저)가 서버에 처음 요청을 보낸다.
- 서버는 클라이언트에 대한 상태 데이터(이름, 아이디, 패스워드 등)를 Session Store에 저장하고 클라이언트의 정보를 Session-ID로 구분하여 클라이언트에게 보낸다.
- 웹 브라우저는 서버에서 보낸 Session-ID를 Cookie에 저장한다.
- 후에, 클라이언트가 동일한 서버에 다른 요청을 보낼 때 Cookie(Session-ID)를 함께 보내 자신을 증명한다.
- 서버는 Cookie(Session-ID)를 통해 Session Store에 저장된 정보를 찾아 클라이언트의 정보를 확인하고 요청에 맞는 응답 데이터를 보내준다.
'Web 개요' 카테고리의 다른 글
[Web] HTTP Stateless 해결을 위한 웹 저장소 및 웹 보안 (0) | 2024.01.11 |
---|---|
[Web] Forward Proxy / Reverse Proxy (0) | 2024.01.10 |
[WEB] HTTP / HTTPS (1) | 2024.01.08 |
[Web] 웹 브라우저 성능 개선 및 웹 서버 부하 완화 (2) | 2024.01.07 |
[WEB] Cache / HTTP Cache (1) | 2024.01.06 |