일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- server
- Shell
- 테라폼 기본 문법
- 파이썬
- terraform 문법
- nosql
- python
- iterm2 shortcuts
- customize
- minikube mac 설치
- 컨테이너
- DynamoDB
- sftp란
- zshrc
- linux
- 도커
- 빅오노테이션
- BIG-O NOTATION
- minikube 설치 방법
- iterm2 단축키
- zsh
- AWS
- 테라폼 문법
- terraform
- Bash
- Django
- 도커컴포즈
- test
- docker-compose
- docker
- Today
- Total
sklass의 s-class 프로그래밍 blog
쿠키와 세션의 개념 본문
개발 직군에서 일을 하다보면, 쿠키와 세션이라는 단어를 손쉽게 접할 수 있습니다만, 이를 정확하게 설명할 수 없다는 것을 깨달았고, 이 글을 작성하려고 합니다.
우선 쿠키와 세션을 사용 하는 이유부터 살펴보겠습니다.
쿠키와 세션을 사용하는 이유
쿠키와 세션은 HTTP 프로토콜의 특징이자 약점인 Connectionless(비연결성) 와 Stateless(무상태성) 한 특성을 보완하고자 사용됩니다.
HTTP 특성
HTTP는 인터넷 상에서 서버와 클라이언트가 데이터를 주고 받기 위해 따르는 규약입니다. 위에서 설명했듯, HTTP는 요청에 대한 응답을 처리하게 되면 연결을 끊어버리고(Connectionless), 클라이언트에 대한 이전의 상태 정보 및 현재 통신의 상태가 남지 않는(Stateless) 특성이 있습니다.
서버가 다수의 클라이언트와 연결을 계속 유지한다면, 이에 따른 자원 낭비가 심해지기 때문에, Connecitonless와 Stateless의 특성을 가지고 불필요한 자원 낭비를 줄일 수 있는 것 입니다.
하지만, 서버가 클라이언트와의 연결을 끊고 상태를 저장하지 않음으로써, 클라이언트를 식별할 수 없다는 단접도 있는데요, 이를 보완하고자, 쿠키와 세션이 사용되는 것 입니다.
쿠키 ( Cookie )
쿠키란?
- 클라이언트(브라우저) 로컬에 저장되는 Key-value 형태의 작은 데이터 파일입니다.
- 유효 시간이 정해져 있고, 해당 시간이 지나지 않는다면, 브라우저를 종료해도 쿠키값이 유지됩니다.
- 클라이언트에 저장되는 정보이기 때문에, 민감하지 않은 데이터만 쿠키에 저장해야 합니다. (Ex. 장바구니)
- 클라이언트에 최대 300개까지 쿠키 저장이 가능하며, 하나의 도메인당 20개의 값만 가질수 있고, 하나의 쿠키값은 4KB까지 저장 가능합니다.
- 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 request 시 Request Header에 넣어서 자동으로 서버에 전송됩니다.
동작 방식
- 클라이언트가 서버에 페이지를 요청
- 서버에서 쿠키 생성
- 서버가 HTTP 헤더에 쿠키를 포함시켜 클라이언트로 응답
- 브라우저가 종료되어도 쿠키 유효 시간이 지나지 않았다면 클라이언트에서 보관하고 있음
- 클라이언트가 같은 요청을 할 경우, HTTP 헤더에 쿠키를 함께 서버로 보냄
사용 예시
- 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
- 쇼핑몰의 장바구니 기능
- 자동 로그인, 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크
단점
- 보안에 취약
- 요청 시 쿠키의 값을 그대로 보냄
- 유츨 및 조작 당할 위험이 존재
- 용량 제한이 있어 많은 정보를 담을 수 없음
- 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능
- 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해짐
세션 ( Session )
세션이란?
- 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저가 아닌, 서버에 저장합니다.
- 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다.
- 물론 접속 시간에 제한을 두어, 일정 시간 응답이 없다면 정보가 유지되지 않게 설정도 가능합니다.
- 사용자 정보를 서버에 저장하기 때문에 쿠키보다 보안이 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 되므로 서버에 부하가 심해집니다.
- 즉, 동시 접속자가 많은 웹 사이트의 경우, 서버에 과부하를 주게 되므로 성능 저하의 요인이 됩니다.
동작 방식
- 클라이언트가 서버 접속 시, 세션 ID를 발급 받음
- 클라이언트는 세션 ID를 쿠키를 사용하여 저장함
- 클라이언트는 서버에 요청할 때, 세션 ID를 서버에 전달해서 사용함.
- 서버는 세션 ID를 전달 받고, 해당 세션 ID와 일치하는 클라이언트 정보를 클라이언트에 전달
사용 예시
- 로그인 같이 보안상 중요한 작업을 수행할 때 사용
단점
- 서버에 데이터를 저장하므로 세션 양이 많아질수록 서버에 부하가 커짐
쿠키와 세션의 차이점
쿠키(Cookie) | 세션(Session) | |
저장 위치 | 클라이언트(=접속자 PC) | 웹 서버 |
저장 형식 | Text | Object |
만료 시점 | 쿠키 저장 시 설정 (브라우저가 종료되도, 만료시점이 지나지 않으면 자동 삭제되지 않음) |
브라우저 종료시 삭제 (기간 지정 가능) |
사용하는 자원 (리소스) | 클라이언트 리소스 | 웹 서버 리소스 |
용량 제한 | 총 300개 하나의 도메인 당 20개 하나의 쿠키 당 4KB(=4096 byte) |
서버가 허용하는 한 용량 제한 없음 |
속도 | 세션보다 빠름 | 쿠키보다 느림 |
보완 | 세션보다 안좋음 | 쿠키보다 좋음 |
쿠키와 세션의 병합 사용
위의 글을 살펴보면, 세션이 쿠키보다 장점이 많아서 쿠키를 언제 그리고 왜 사용해야하는지 잘 이해가 안가는 분들이 계실겁니다.
세션이 쿠키에 비해 보안도 높은 편이나, 쿠키를 사용하는 이유는 세션은 서버에 저장되고, 서버 자원을 사용하기 때문에 사용자가 많은 경우, 소모되는 자원이 상당합니다.
따라서, 실전에서는 이러한 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있습니다.
쿠키와 세션 도식화
쿠키와 세션 병합 사용에 대한 설명
- 세션 ID를 서버가 발급해서 클라이언트에 넘겨주면, 클라이언트는 해당 세션 ID를 쿠키에 저장하고, 다음 요청 시에 해당 세션 ID를 Request 헤더에 포함시켜 서버에 요청하게 됩니다.
- 그러면 서버는 세션 ID를 DB에서 찾고, 있으면 해당 정보를 없으면, 401 에러를 클라이언트에 전달하게 됩니다.
쿠키/세션 과 캐시는 다릅니다!
- 캐시는 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해 놓고 사용하는 것입니다.
- 한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도, 사용자는 변경되지 않게 보일 수 있는데, 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용해서 해결할 수 있습니다.
이상으로 쿠키와 세션에 대한 설명과 차이점을 알아보았습니다.
쿠키와 세션을 병합 사용한다 해도, 세션 ID 자체는 서버에 저장되기 때문에 서버 메모리에 무리가 가는건 개선되지 않았습니다.
최근에는 이러한 문제를 보완한 토큰 기반의 인증방식을 사용하는 추세이며, 대표적으로 JWT(JSON Web Token)라는 것이 있습니다.
'network' 카테고리의 다른 글
Sticky Session (0) | 2021.12.05 |
---|---|
[SSH] known_hosts와 authorized_keys (0) | 2021.12.05 |
Forward Proxy와 Reverse Proxy (0) | 2021.11.14 |
SSH (Secure Shell) (0) | 2021.11.07 |
IP 주소 & 서브넷 마스크(Subnet Mask) 정리 (0) | 2021.10.31 |