[Network] 쿠키와 세션

해당 글은 VSFe 깃허브 레포를 참고하여 작성한 글입니다. (아래 출처에 표기)

 

✅ 쿠키와 세션의 차이에 대해 설명해 주세요.

• 쿠키(Cookie): 클라이언트(브라우저)에 저장되는 작은 데이터 조각이다. 서버가 클라이언트에게 보낸 후, 클라이언트가 서버에 재접속할 때마다 이를 다시 서버로 보낸다.
  • 저장 위치: 클라이언트(브라우저)에 저장된다.
  • 수명: 만료 날짜를 설정할 수 있으며, 설정에 따라 브라우저를 닫아도 유지될 수 있다.
  • 보안: 클라이언트에 저장되므로, 보안이 중요한 정보는 암호화해야 한다.
  • 용량: 일반적으로 4KB까지의 데이터만 저장이 가능하다.
• 세션(Session): 서버 측에서 사용자 정보를 유지하는 방법이다. 각 사용자는 고유한 세션 ID를 가지며, 이 세션 ID는 클라이언트와 서버 간의 요청에 포함되어 전달된다.
  • 저장 위치: 서버에 저장되고, 세션 ID만 클라이언트에 쿠키 형태로 저장된다.
  • 수명: 일반적으로 브라우저를 닫으면 종료된다. 서버에서 설정된 일정 시간이 지나면 자동으로 만료될 수 있다.
  • 보안: 서버에 저장되므로, 상대적으로 더 안전하다.
  • 용량: 서버에 저장되므로, 저장 용량에 제한이 없다.

 

✅ 세션 방식의 로그인 과정에 대해 설명해 주세요.

1. 사용자 로그인 시도: 사용자가 로그인 요청을 보낸다.
2. 서버에서 인증: 서버는 사용자 정보를 데이터베이스에서 확인하여 인증을 처리한다.
3. 세션 생성: 인증이 성공하면 새로운 세션을 생성하여 세션 저장소에서 관리하고, 세션 ID를 발급한다.
4. 세션 ID 전달: 서버는 세션 ID를 클라이언트에 쿠키로 전달한다.
5. 클라이언트의 요청: 클라이언트는 이후 데이터 요청마다 세션 ID를 포함한 쿠키를 서버로 전송한다.
6. 서버에서 세션 확인: 서버는 요청을 받을 때마다 세션 ID를 확인하여 세션 정보를 조회하고, 사용자 인증을 처리한다.

 

✅ HTTP의 특성인 Stateless에 대해 설명해 주세요.

• 클라이언트와 서버의 동작, 상태 정보를 저장하지 않는 형태이다.
• 클라이언트와 서버 간 모든 요청이 서로 독립적이고, 이전 요청의 정보를 저장하지 않는다.

Stateless에 대한 설명은 여기를 참고하면 좋을 것 같다.

 

✅ Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

• Stateless를 통해 멀티 쓰레드 환경에서 웹 애플리케이션이 보다 많은 요청과 응답을 할 수 있도록 하지만, 웹 애플리케이션에서는 로그인 같이 상태를 유지해야 하는 서비스가 존재한다.
• 이때 Stateless가 기본값인 HTTP에서 Stateful한 상태를 구현하려면 많은 비용이 드는데, 이때 세션을 사용하면 Stateless의 한계를 극복하여 서비스를 비교적 쉽게 구현할 수 있다.

 

✅ 규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

• 세션 스티키티즈(Session Stickiness): 특정 사용자의 요청을 항상 동일한 서버로 전달하는 방식으로, 로드 밸런싱(트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율을 증가, 부하량, 속도 저하 등을 고려하여 분산 처리하는 서비스)을 통해 관리한다.
  
  • 장점:
    • 간단한 구현: 로드 밸런스를 통해 쉽게 구현할 수 있으며, 세션 데이터를 서버 간에 공유할 필요가 없다.
    • 빠른 응답 시간: 세션 데이터가 항상 동일한 서버에 있으므로 세션 조회 시간이 빠르다.
  • 단점:
    • 서버 부하 불균형: 특정 서버에 요청이 몰리면, 해당 서버에 과부하가 발생할 수 있다.
    • 단일 장애점: 특정 서버가 다운되면 해당 서버에 할당된 세션이 모두 무효화될 수 있다. (로드 밸런서가 이를 감지하고 해당 서버로 향하는 트래픽을 다른 서버로 라우팅 하는데, 이럴 경우 기존 세션이 유실된다. 즉, 이용하던 유저는 재로그인을 해야 한다.)
• 세션 클러스터링(Session Clustering): 모든 서버가 세션 정보를 공유하도록 구성하는 방법이다. 이를 위해 세션 정보를 중앙 집중식 데이터베이스나 메모리 캐시(ex: Redis, Memcached)에 저장한다.
  • 장점:
    • 고가용성: 서버 중 하나가 다운되더라도 다른 서버가 세션 정보를 접근할 수 있어 지속적인 서비스가 가능하다.
    • 로드 분산: 요청이 균등하게 분산되므로 특정 서버에 과부하가 발생하지 않는다.
  • 단점:
    • 복잡한 구현: 세션 데이터를 중앙에서 관리해야 하므로 시스템이 복잡해질 수 있다.
    • 성능 이슈: 중앙 저장소에 세션 정보를 읽고 쓰는 과정에서 성능 저하가 발생할 수 있다. 특히, 요청이 많을 경우 병목 현상이 생길 수 있다.
• 토큰 기반 인증(Token-Based Authentication): 세션 대신 JWT(JSON Web Token) 같은 토큰을 사용하여 클라이언트 측에서 상태를 유지하는 방법이다. 토큰은 클라이언트에 저장되고, 각 요청 시 서버로 전달되어 인증을 처리한다.
  • 장점:
    • 서버 부담 감소: 세션 정보를 서버 메모리에 저장할 필요가 없어 서버 부담이 줄어든다.
    • 확장성: 디바이스 환경에서 유연하게 작동하며, 서버 간 세션 정보를 공유할 필요가 없다.
  • 단점:
    • 보안 이슈: 토큰이 탈취되면 해당 토큰을 통해 인증된 사용자인 것처럼 행동이 가능하다. 토큰 자체는 암호화되지 않아 토큰 내 데이터(payload)의 디코딩을 통해 데이터를 볼 수 있다.
    • 토큰 무효화 어려움: 서버에서 토큰을 무효화하는 것이 어렵다. 일반적으로 토큰의 유효 기간이 끝날 때까지 유효하다.

 

 

📍 문제 출처

Tech-Interview / 03-NETWORK.md

 

📍 참고 자료

• HTTP 는 Stateless 한데 로그인은 어떻게 구현할 수 있을까? (세션/쿠키를 이용한 인증)
• [란] Stateless / Stateful 란?
• 로그인방식에 대한 고찰(session ID, Token방식)
• 스티키 세션(Sticky Session), 세션 클러스터링(Session Clustering)이란? + 세션, 로드 밸런싱, Session Storage