[금오공대 BOSS] 웹 멘토링(3)-쿠키와 세션

[수정] 20.05.11 - stateful, stateless 관련 내용 추가

 

 

쿠키가 뭔지 알려면 HTTP가 뭔지부터 알아야 할 것 같다.

 

HTTP (HyperText Trasfer Protocol)?

- Connectionless하고 Stateless하다. 

 

HTTP는 모든 사용자의 요청마다 연결과 해제의 과정을 거치면서 연결 상태를 유지하지 않는다.

물론 연결 해제 후에도 상태 정보를 저장하지 않는다. 

 

이는 서버의 자원을 크게 절약할 수 있지만, 사용자를 식별 할 수 없어서 같은 사용자가 요청을 여러번하더라도 매번 새로운 사용자로 인식하게 한다. (Stateless한 성격)

 

하지만 실제로는 어떨까?

우리가 사용하는 웹사이트를 보면 로그인을 최초로 하고 나면 그 이후로부터 다시 로그인할 필요가 없는 경우도 있다.(Stateful해짐)

 

HTTP임에도 불구하고 어떻게 이런 게 가능할까?

 

바로 쿠키와 세션 때문이다.

(쿠키와 세션이 HTTP를 Stateful하게 만들어준다.)

 

Stateful과 Stateless란?

Stateful : 이전의 상태 기록(기억)

Stateless : http처럼 이전의 상태를 기록(기억)을 안함

 

쿠키(Cookie)

그림1

 

- 웹 서버가 웹 브라우저로 전송하는 작은 텍스트 정보 파일

(ex: 네이버가 크롬으로 전송)

- 한번 저장된 쿠키는 유효기간이 경과하지 않았다면 해당 도메인에 접속하면 브라우저가 자동으로 탑재하여 전송

→ 일정 시간동안 데이터를 저장할 수 있어 로그인 상태를 유지할 수 있음

- 제한

• 데이터 형식: 문자열
• 크기: 4KB 이하
• 변수 개수: 쿠키 파일 하나 당 20개

# 동작 순서

1. 클라이언트가 웹 페이지를 요청한다.
2. 서버는 쿠키를 생성한다.
3. 생성한 쿠키에 정보를 담아 HTTP화면을 돌려줄 때 같이 클라이언트에게 돌려준다.
4. 넘겨 받은 쿠키는 클라이언트가 가지고 있다가 다시 서버에 요청 할 때(ex로그인을 할때) 요청과 함께 전송한다.
5. 이때 웹 서버는 정보를 변경할 필요가 있으면 쿠키를 업데이트하여 응답과 함께 변경된 쿠키를 클라이언트에게 돌려준다.
6. 재 방문 시 클라이언트의 메모리에 저장되어 있다면 요청 페이지와 함께 쿠키를 전송한다.

# 쿠키의 용도

• ID 저장, 로그인 상태 유지
• 7일간 다시 보지 않기. (쿠키에 체크한 날짜를 기록하여 다시 방문했을 때의 시간과 시차를 이용하여 계산)
• 최근 검색한 상품들을 광고에서 추천
• 쇼핑몰 장바구니 기능

# 쿠키의 단점

• 쿠키에 대한 정보를 매 헤더(HTTP Header)에 추가하여 보내기 때문에 상당한 트래픽을 발생 시킴
• 결제정보등을 쿠키에 저장하였을 때 쿠키가 유출되면 보안에 대한 문제점도 발생..
• 개인 소유가 아닌 컴퓨터에서 사용할 경우 누구나 그 사용자의 비밀번호를 확인할 수 있음. HTTP로 개인 정보를 주고 받는 것은 매우 위험하다.

트래픽이란?

전송량이라고 하며 어떤 통신장치나 시스템에 걸리는 부하를 말한다. 트래픽 양이 지나치게 많으면 서버에 과부하가 걸려 전체적인 시스템 기능에 장애를 일으킨다.

출처 : 네이버 지식백과

 

 

세션(Session)

그림2

- 쿠키의 트래픽 문제와 보안적 이슈를 해결하기 위해 등장

- 웹 서버가 해당 웹 서버에 접근한(요청한) 클라이언트(사용자)(웹 페이지)를 식별하는 방법

- 일정 시간동안 같은 사용자(웹 페이지)로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술

- 일정 시간: 방문자가 웹 페이지를 통해 웹 서버에 접속한 시점으로부터 웹 페이지를 종류하여 연결을 끝내는 시점

- 즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라 함

→ 통신할 때만 발동이 되는 쿠키

- 두 컴퓨터 간 활성화 된 접속을 의미한다.(특정 접속자 식별 도구)

- 서버에 저장되어 현재 사용자만이 인증 받을 수 있다.

- Sesstion은 비밀번호와 같은 인증 번호를 쿠키에 저장하지 않고 대신에 사용자의 식별자인 Session id를 저장함

- 인증번호와 더불어 이 ID에 해당하는 로그인 상태, 마지막 로그인 시간, 닉네임, 만료기한 등의 정보를 저장함

- 용량에 제한이 없음

 

# 동작 순서

1. 클라이언트가 서버로 접속(요청)을 시도한다.
2. 서버는 접근한 클라이언트의 Request-Header field인 Cookie를 확인하여 클라이언트가 해당 session-id를 보냇는 지 확인한다. (첫 요청은 session-id가 존재하지 않음)
3. 만약 session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에게 돌려준다.(쿠키 이름은 JSESSIONID)
4. 이후 클라이언트는 전달받은 session-id값(JSESSIONID)을 매 요청마다 헤더쿠키에 넣어서 요청한다.
5. 서버는 session-id를 확인하여 사용자를 식별한다.
6. 클라이언트가 로그인을 요청하면 서버는 session을 로그인한 사용자 정보로 갱신하고 새로운 session-id를 발급하여 응답한다.
7. 이후 클라이언트는 로그인 사용자의 session-id쿠키(JSESSIONID)를 요청과 함께 전달하고, 서버에서도 로그인 된 사용자로 식별 가능하다.
8. 클라이언트 종료(웹 페이지 종료) 시 session id는 제거되고, 서버에서도 그 세션이 제거된다.

# 세션의 장점

• 클라이언트의 정보를 서버에 저장하기 때문에 쿠키보다 보안이 우수하다.

# 세션의 단점

• 서버에 저장하기 때문에 저장공간이 필요하며 서버가 처리함으로서 부하가 발생할 수 있다.

 

 

흐음 근데 쿠키나 세션이나 비슷한데, 왜 보안상 취약한 쿠키를 사용할까?

서버에 무리한 부담을 주는 것을 피하기 위함이다.

세션은 서버에 저장되어 메모리를 많이 차지하여 많은 자료가 쌓이면 과부하가 걸린다.

그래서, 로그인에는 보안에 취약한 쿠키 대신 세션을 사용하고,

보안과 관련없는 쇼핑몰 장바구니나 웹페이지의 팝업 등에는 주로 쿠키를 사용한다.