프로젝트를 진행하면서 당연하듯이 사용하고 있던 쿠키와 세션인데 정작 원리를 제대로 이해하고 사용하지 않았다. 대충 감만 잡은 상태로 사용하는 것은 그다지 어렵지 않았는데 이것들을 사용자 인증, 인가의 목적으로 사용하게 되니까 굉장히 복잡했던 경험이 떠오른다. 그러다 보니 면접 때 질문이 들어왔는데 긴가민가한 상태로 대답을 하게 되었고 결과는 뭐.. 눈물만 나네. 다시는 이런 일이 없도록 정리하면서 온전히 내 것으로 만들어보자!
💡 cookie와 session을 다루기 전에 먼저 HTTP의 특징에 대해 알아보자.
📌 HTTP의 특징
HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다.
1. 비연결성 (Connectionless)
- 클라이언트가 요청을 한 후 서버에서 응답을 보내면 연결을 끊는 특성
- HTTP의 이러한 특성은 여러 클라이언트의 접속을 원활하게 하기 위해서 연결을 유지하지 않는다.
- 하지만 매번 똑같은 주소로 통신할 때마다 새로운 연결을 설정하며 데이터를 주고받는 것은 비용이 많이 발생
- header에 keep-alive 옵션을 부여하면 커넥션을 유지하게 된다. (HTTP 1.1부턴 이 옵션이 dafault)
- 단, keep-alive옵션을 사용하면 유저가 많을 경우 커넥션이 늘어나 새로운 유저를 받아들일 수 없는 경우가 발생하기 때문에 성능의 하락을 야기한다.
2. 무상태 (Stateless)
- 요청에 대한 응답 후 연결이 끊기며 과거에 대한 상태(정보)를 전혀 담지 않는다.
📌 cookie와 session
위와 같은 HTTP 통신의 특성으로 인해 특정 웹사이트에 로그인을 했어도 이후의 요청의 경우 과거의 유저 인증정보를 가지고 있지 않기 때문에 사용자가 매번 서버에 요청을 보낼 때마다 계속 로그인을 시도해야 한다. (과거의 내 정보가 담겨 있는 HTTP 요청과 이후의 HTTP 요청은 전혀 관계가 없다.)
때문에 로그인 정보를 유지시키기 위한 방법이 필요했고 비연결성과, 무상태의 특징을 가진 HTTP 통신을 보완하기 위해 cookie와 session을 사용하여 인증을 유지할 수 있다.
Cookie
- HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 키(key), 벨류(value) 형태의 작은 데이터 파일이다.
- 쿠키는 상태 정보를 클라이언트의 로컬에 텍스트 형태로 저장했다가 필요시 정보를 참조하거나 재사용할 수 있다.
- 저장된 쿠키는 요청 시 브라우저가 자동으로 request header에 cookie 정보를 담아 서버에 전송한다.
- 유효 날짜/시간을 지정할 수 있으며, 유효 날짜/시간 동안은 브라우저를 종료해도 쿠키가 유지된다. (사용자 인증 유지 가능)
Cookie 동작순서
1. 클라이언트가 서버에 Resource를 요청
2. 서버에서 쿠키를 생성
3. 요청한 리소스와 함께 쿠키를 응답헤더에 담아 클라이언트로 응답
4. 클라이언트는 이후 서버에 요청할 때 전달받은 쿠키를 자동으로 요청헤더에 추가하여 요청 (브라우저가 자동으로 헤더에 쿠키를 추가함)
Cookie 사용예시
- 사용자 ID 저장
- 쇼핑몰 장바구니 기능
- 팝업에서 오늘 더 이상 보지 않음, 일주일간 보지 않음
Cookie의 한계
- 쿠키의 경우 로컬에 저장되기 때문에 탈취, 변조의 위험이 있어 민감한 정보(사용자 식별 및 인증 관리)를 포함한 경우 보안성(암호화 과정 등)을 고려해야 한다.
- 쿠키를 폐기해도 해당 값을 알고 있으면 재사용이 가능한 문제점 존재.
Session
쿠키의 탈취, 변조 등 보안적 이슈를 해결하기 위해 등장
- 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술이다.
- 즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.
- 쿠키를 기반으로 동작하지만 해당 세션에 대한 정보를 클라이언트가 아닌 접속한 서버의 메모리, 파일 시스템, DB에 정보를 저장한다.
- 각 클라이언트 고유 Session ID를 부여한다. Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공
- 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
- 통신시 세션 ID(Key)에 해당하는 정보(Value) 값을 활용하여 사용자를 인증한다.
Session 동작 순서
1. 클라이언트가 서버에 Resource를 요청
2. 서버는 Request header의 Session id쿠키를 확인 후 없으면 Set-Cookie를 통해 생성한 Session id를 클라이언트로 응답
3. 클라이언트는 Request header에 Session id를 포함하여 원하는 Resource를 요청
4. 서버는 Session id를 통해 해당 세션을 찾아 클라이언트 상태 정보를 유지하며 적절한 응답을 함
Session 사용 예시
로그인 상태 유지 (사용자 인증, 인가)
Session의 한계
- 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지
- 동접자 수가 많은 경우 서버에 과부하를 주게 되므로 성능 저하의 요인
📌 cookie와 session의 차이점
저장 위치
쿠키 : 클라이언트 로컬
세션 : 서버
보안
쿠키 : 클라이언트 로컬에 저장되므로 탈취, 변조 등 보안이 취약하다.
세션 : 쿠키를 이용해 Session ID를 저장하고 이것을 식별자로 서버에서 처리하므로 비교적 보안성이 좋다.
라이프사이클
쿠키 : 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있다.
세션 : 만료시간을 정할 수 있지만 브라우저가 종료시 만료시간에 상관없이 삭제된다.
속도
쿠키 : 클라이언트에 로컬에 저장되어서 서버에 요청 시 request header를 참조하면 되기 때문에 속도면에서 유리하다.
세션 : Session id를 활용해 서버에서 데이터를 참조해야하므로 비교적 속도가 느릴 수 있다.
리소스
쿠키 : 클라이언트 리소스 사용 (하드 디스크, 메모리)
세션 : 세션은 서버에 저장되고 서버의 메모리로 로딩이 되기 때문에 세션이 생길때마다 리소스를 차지한다.
참고 링크
https://sdevstudy.tistory.com/27
https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies
'TIL' 카테고리의 다른 글
| REST API + RESTful API (0) | 2023.05.02 |
|---|---|
| 'module' is not defined. eslint (0) | 2023.05.01 |
| [TIL] git remote update (0) | 2021.10.24 |
| [TIL] npm package의 @ 접두사는 뭐지..? (0) | 2021.10.22 |
| [TIL] JWT (JSON WEB TOKEN) (0) | 2021.10.14 |
