Front-end
[Front-end] 쿠키와 세션(Cookie, Session)
byolee
2020. 5. 13. 09:53
Cookie - Session
쿠키와 세션을 사용하는 이유?
- HTTP 프로토콜의 장점이자 단점인 특징
stateless를 보완 - 서버가 클라이언트가 누구인지 확인하는 목적
Conectionless 비연결성 : 클라이언트가 서버에게 request를 보내고 response를 받으면 해당 connection을 끊음, connection을 유지하기 위해서는 Header에 keep-alive 값이 있어야 함
Stateless 무상태성 : 서버와 클라이언트 간의 통신이 끝나면 서버는 클라이언트의 상태를 유지하지 않음
Cookie 쿠키
클라이언트 로컬에 저장되는 데이터 파일 (key-value 구조)
- 브라우저가 종료되어도 명시한 유효 시간이 지나지 않았다면 인증 유지
- 하나의 쿠키 값은 최대 4KB까지 저장 가능
- Response 헤더에 Set-Cookie 속성을 사용하여 쿠키 생성
- 사용자가 요청하지 않아도 자동으로 브라우저가 Request Header에 넣어서 서버에 전송
- example : 아이디, 비밀번호 저장, 장바구니 기능, 자동로그인, 팝업 ‘오늘 더 이상 이 창을 보지 않음’
Cookie의 구성요소
- 이름 : 쿠키를 구별하는 데 사용
- 값
- 유효시간
- 도메인 : 쿠키를 전송할 도메인
- 경로 : 쿠키를 전송할 요청 경로
Cookie의 동작
- 클라이언트가 페이지 요청
- 서버에서 쿠키 생성
- HTTP 헤더에 쿠키를 포함하여 response
- 브라우저가 종료되어도
쿠키 만료 기간이 있다면 클라이언트에서 보관 - 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
- 서버에서 쿠키를 읽어 이전 상태 정보를 변경할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답
Session 세션
웹 브라우저를 통해 웹 서버에 접속한 이후로 브라우저를 종료할 때까지 유지되는 상태와 유지하는 기술
- 쿠키와 비슷하지만 브라우저가 아니라
서버에서 관리함 - 클라이언트 구분을 위해 unique한
세션 ID를 부여하고 서버에 접속해서 브라우저를 종료할 때까지 인증 상태 유지 - 일정 시간 응답이 없는 경우 유지되지 않게 설정할 수도 있음
- 쿠키보다
보안성이 좋으나 서버 메모리 차지 부담이 큼 - example : 로그인 정보 유지
Session의 동작
- 클라이언트가 서버에 접속
- 서버는 클라이언트에게 고유한 세션 ID를 발급
- 서버는 발급한 ID를
쿠키(Set-cookie 헤더)를 사용해서 저장 - 클라이언트가 다시 접속할 때 쿠키를 이용해서 세션 ID값을 서버에게 전달
요약
| 차이점 | 쿠키 | 세션 |
|---|---|---|
| 저장위치 | 브라우저 로컬에 저장, 브라우저 별로 다름 | 서버에 저장 |
| 보안성 | Sniffing의 우려, 보안성 취약 | ID를 서버에서 처리하므로 보안성 좋음 |
| 메모리 차지 | 거의 없음, 하나의 도메인에서 20개 이상 저장 시 사용량이 적은 것 부터 삭제 | 서버의 메모리 부담 있음 |
| Life Cycle | 파일로 저장되므로 브라우저를 종료해도 쿠키는 남아있을 수 있음 | |
| 만료기간이 긴 경우 쿠키를 삭제하기 전까지 남아 있음 | 브라우저가 종료되면 세션 만료시간에 상관없이 삭제 | |
| 속도 | 빠름 | 서버의 처리가 필요하므로 상대적으로 느림 |