쿠키(cookie) vs 세션(session)

아현·2021년 10월 14일

web

Web

목록 보기

8/10

참고, 참고2, 참고3, 참고4

정리

공통점 : 웹 통신간 유지하려는 정보(ex:로그인 정보 등)를 저장하기 위해 사용하는 것
차이점 : 저장위치, 저장형식, 용량제한, 만료시점 등

쿠키 : 개인 PC에 저장됨.
세션 : 접속중인 웹 서버에 저장됨.

일반적으로 HTTP 통신은 Stateless/Connectionless입니다
그런데 이제 State가 필요한 경우를 위해 세션과 쿠키라는걸 사용합니다.
쿠키는 쿠키 만료시간이 있고, 세션은 세션 타임아웃이 있습니다.
쿠키는 만료시간이 지나면 더이상 소용이 없어지고, 세션은 해당 세션과 연결되는 클라이언트의 연결이 없으면 timeout시간이 지난 후 해제가 됩니다.
그리고 Connectionless이기때문에 원래는 연결조차 매 연결마다 새로 TCP 연결을 수립하고 해제하고 반복합니다
그런데 이게 오버헤드가 생각보다 큽니다.
그래서 Keep-Alive라는게 HTTP 1.1에서 생깁니다
Keep-Alive, HTTP-Alive등 뭐 이것저것 개념이 있긴 하지만 Persistent Connection으로 통합해 이야기하면, Persistent Connection이 설정되면 하나의 연결을 재활용하게 됩니다.
즉, 원래는 클라이언트 -> 웹서버 모든 요청마다 새로운 소켓을 연결하고 통신하고 바로종료였는데, 이제는 같은 클라이언트 -> 같은 서버에 Persistent Connection이 설정되어있으면 재활용하게 됩니다

결론은 원래 HTTP는 Connectionless에 Stateless인데 저런식으로 Connection과 State가 필요한 경우 유지를 하면서 성능 및 서비스를 개선했습니다

쿠키는 말하신대로 expire로 만료시간을 설정하고 세션은 서버에서 설정한대로 timeout이 적용됩니다

1. HTTP

HTTP(HyperText Transfer Protocol)는 W3 상에서 정보를 주고받을 수 있는 프로토콜이다.
주로 HTML 문서를 주고받는 데에 쓰인다.
주로 TCP를 사용하고 HTTP/3 부터는 UDP를 사용하며, 80번 포트를 사용한다.
HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있다.

HTTP의 특징

HTTP 통신의 특징은 Connectionless와 Stateless라고 할 수 있습니다.

Connectionless (비 연결지향)
- 클라이언트에서 서버에 요청을 보내면 서버는 클라이언트에 응답을 하고 접속을 끊는 특성이 있습니다.
  - HTTP1.1에서 Connection 헤더에 keep-alive라고 설정하면 컨넥션을 유지할 수 있습니다
Stateless (상태정보 유지 안 함)
- HTTP 통신은 요청을 응답하고 접속을 끊기 때문에 클라이언트의 상태정보를 알 수 없습니다. 이를 Stateless하다고 합니다.
- 만약 로그인을 하고 그 상태를 유지한 채로 웹 서비스를 제공하려면 어떻게 해야할까요?
  - HTTP프로토콜에서 상태를 유지하기 위해 쿠키와 세션이라는 방법이 존재합니다.

2. 쿠키

쿠키는 클라이언트 로컬에 저장되는 Key-Value쌍의 작은 데이터 파일입니다.
구성요소
- 쿠키이름, 쿠키값, 만료시간, 전송할 도메인명, 전송할 경로, 보안연결여부, HttpOnly여부

동작 방식

클라이언트가 서버에 로그인 요청을 합니다
서버는 클라이언트의 로그인 요청의 유효성을 확인하고(아이디와 비밀번호 검사) 응답헤더에 set-cookie: user=chrisjune 를 추가하여 응답합니다.
클라이언트는 이후 서버에 요청할 때 전달받은 cookie: user=chrisjune 쿠키를 자동으로 요청헤더에 추가하여 요청합니다.
- 헤더에 쿠키값을 자동으로 추가하여 주는데 이는 브라우저에서 처리해주는 작업입니다.

쿠키의 기한이 정해져 있지 않고 명시적으로 지우지 않는다면 반 영구적으로 쿠키가 남아있게 됩니다.

3. 세션

브라우저가 종료되기 전까지 클라이언트의 요청을 유지하게 해주는 기술입니다.
- 기본 유지 시간: 30분
- 세션ID는 세션 객체를 구분하기 위한 ID이고 세션 생성시 간은 세션 객체가 생성된 시점이기 때문에 매번 새로고침하여 호출하여도 변하지 않습니다.
  - 세션 최근 접근 시간은 이전에 세션에 접근했던 시간이므로 새로고침시마다 바뀌는 것을 볼 수 있습니다.

동작 방식

클라이언트가 서버에 로그인 요청을 합니다
서버는 클라이언트의 로그인 요청의 유효성을 확인하고(아이디와 비밀번호 검사) unique한 id를 sessionid라는 이름으로 저장합니다.
서버가 응답할 때 응답헤더에 set-cookie: sessionid:a1x2fjz를 추가하여 응답합니다.
클라이언트는 이후 서버에 요청할 때 전달받은 sessionid:a1x2fjz쿠키를 자동으로 요청헤더에 추가하여 요청합니다.
서버에서는 요청헤더의 sessionid 값을 저장된 세션 저장소에서 찾아보고 유효한지 확인후 요청을 처리하고 응답합니다.

세션의 내용은 서버에 저장되기 때문에 계속하여 늘어날 경우 서버에 부하가 발생합니다.

4. Keep-Alive

HTTP/1.1부터는 이미 연결되어 있는 TCP 연결을 재사용하는 Keep-Alive라는 기능을 Default로 지원한다.
- 즉 TCP의 Handshake 과정이 생략되므로 성능 향상을 기대 할 수 있다.

특징

Keep Alive의 유지 시간은 연결된 Socket에 I/O Access가 마지막으로 종료된 시점부터 정의된 시간까지 Access가 없더라도 세션을 유지하는 구조이다.
- 즉 정의된 시간내에 Access가 이루어진다면 계속 연결된 상태를 유지할 수 있게 된다.

Q. Keep Alive Timeout 설정은 왜 필요한가?

서버 자원은 무한정이 아니다. 그렇기 때문에 이러한 접속을 계속 유지하는 것은 Server에 손실을 발생시킨다.

즉 서버와 연결을 맺을 수 있는 Socket은 한정되어 있고 연결이 오래 지속되면 다른 사람들이 연결을 못하게되는 상황이 닥친다.

장단점

장점
- 위 이미지는 4개의 트랜잭션에 대해 연속적으로 4개의 커넥션을 생성하여 처리하는 방식과 하나의 지속 커넥션으로만 처리하는 방식을 비교한 이미지이다.
- 후자에서는 커넥션을 맺고 끊는 데 작업이 없어졌기 때문에 시간이 단축되었다.
- 정적 자원(HTML, 이미지 파일 등)으로만 구성된 웹 서버에 Keep Alive을 사용할 경우 약 50%의 성능 향상을 보인다고 한다.
단점
- 성능 향상을 보이려면 서버가 바쁘지 않아야 하는데 바쁜 서버 환경에서 Keep Alive 기능을 사용할 경우 모든 요청 마다 연결을 유지해야 하기 때문에 프로세스 수가 기하급수적으로 늘어나 MaxClient값을 초과하게 된다.
- 메모리를 많이 사용하게 되며 이는 곧 성능 저하의 원인이 된다.
  - 즉 대량 접속 시 효율이 떨어지게 된다.

문제점

Keep-Alive 기능은 설계상 문제가 있었다. 그리고 그 설계상 문제를 100% 해결하지 못하였고 때문에 HTTP/1.1 명세에서는 제외되었다.
- 하지만 한번 생성된 커넥션을 재사용한다는 개념은 유지되었다.
멍청한(Dumb) 프록시
- 일반적으로 HTTP는 클라이언트와 서버 사이에 프록시 서버, 캐시 서버 등과 같은 중개 서버가 놓이는 것을 허락한다.
- 그런데 여기서 프록시 서버가 멍청할 경우 문제가 발생한다. 멍청한 프록시는 Connection 헤더를 이해하지 못하고 해당 헤더들을 삭제하지 않고 요청 그대로를 다음 프록시에 전달한다.

Proxy-Connection

멍청한 프록시가 무조건 전달하는 문제를 해결하기 위해 개발자들은 Proxy-Connection이라는 헤더를 사용하는 차선잭을 제시하였다.

브라우저에서 일반적으로 전달하는 Connection 헤더 대신에 비표준인 Proxy-Connection 확장 헤더를 프록시에 전달한다.
프록시가 Proxy-Connection 헤더를 무조건 전달하더라도 웹 서버는 그것을 무시하기 때문에 문제가 되지 않는다.
하지만 Keep-Alive를 이해하는 프록시는 Proxy-Connection 헤더를 Connection 헤더로 변경하여 지속 커넥션을 유지할 수 있게 된다.