[네트워크] HTTP 상태유지 기술

✅ 쿠키와 세션

: HTTP 프로토콜의 특성인 비연결성(connectionless)과 무상태성(stateless)을 보완하기 위해 만들어진 기술

 

ex) HTTP 특성상 매번 페이지를 이동할 때마다 로그인을 다시 해야 한다.
-> 이렇게 상태 정보를 저장할 필요가 있을 때 쿠키와 세션 사용

 

비연결성 : 한 번의 요청과 응답이 오간 후에 맺었던 연결을 끊어버림
무상태성: 통신이 끝나면 상태 정보를 기억하지 않음

 

---

📍 쿠키(Cookie)

: 클라이언트 PC에 저장되는 작은 기록 정보 파일

 

[특징]

• Key-Value 쌍으로 구성
• 이름, 값, 만료일, 경로 정보로 구성
• 도메인 당 20개의 쿠키를 가질 수 있음
• 하나의 쿠키는 4KB까지 저장 가능

 

[작동 방식]

1. 클라이언트가 서버에 HTTP 요청을 보냄
2. 서버는 요청을 처리한 후, 응답 헤더 `Set-Cookie`에 쿠키를 담아서 응답
3. 클라이언트는 받은 쿠키를 로컬에 저장
4. 클라이언트는 이후 서버에 요청할 때마다 쿠키를 자동으로 요청 헤더 `Cookie`에 추가하여 전송

 

[문제점]

`Cookie`는 `Javascript`를 사용하여 접근이 가능하다.

즉, 공격자가 Script를 작성해 사용자의 쿠키 정보를 탈취할 수 있으므로 XSS(Cross Site Script)에 매우 취약하다고 할 수 있다.

 

XSS (Cross-Site Scripting): 관리자가 아닌 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격

 

---

📍 세션(Session)

: 쿠키가 보안상 취약하다는 단점을 해결하기 위해, 서버 측에서 관리하는 사용자 정보 파일

 

[특징]

• 쿠키를 기반으로 하고 있음
• 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여
• 브라우저가 종료될 때까지 인증 상태 유지

 

[작동 방식]

1. 클라이언트가 서버에 HTTP 요청을 보냄
2. 서버는 요청 헤더의 `Cookie` 필드에 세션 ID가 포함되어 있는지 확인
3. 세션 ID가 없을 경우, 서버는 새로운 세션 ID를 생성하여 응답 헤더 `Set-Cookie`에 담아서 전송
4. 서버는 생성된 세션 ID를 저장하여 클라이언트의 상태를 관리
5. 클라이언트는 쿠키를 이용하여 세션 ID 값을 서버에 전달하여 이전 상태를 유지

 

[문제점]

세션은 서버에 저장되기 때문에, 세션이 많아질수록 부하 문제가 발생한다.

즉, 사용자가 많을수록 속도가 저하된다.

 

---

📍 쿠키 vs. 세션

쿠키와 세션의 가장 큰 차이는 “상태 정보의 저장 위치”

쿠키는 클라이언트에, 세션은 서버에 저장한다.

 

[왜 쿠키와 세션을 같이 사용할까?]

세션이 쿠키의 단점을 보완하기 위해 나왔음에도, 쿠키와 세션을 같이 사용한다.

 

세션은 서버에 저장되므로, 사용자가 많을 경우 소모되는 서버 자원이 상당하다.

따라서 자원관리 차원에서, 쿠키와 세션을 적절히 병행해서 사용하여 서버 자원의 낭비를 방지해야 한다.

• 속도: 쿠키 > 세션
• 보안: 쿠키 < 세션

---

✅ JWT (Json Web Token)

: 인증에 필요한 정보들을 Json 객체에 담은 후 비밀키로 서명한 토큰

 

세션 인증 방식의 서버가 부하된다는 문제점을 해결한다.

 

[작동 방식]

1. 클라이언트가 서버에 로그인 요청
2. 서버는 비밀키를 사용해 JWT 토큰 발급
3. JWT 토큰을 헤더에 담아 클라이언트에 전달
4. 클라이언트는 JWT 토큰을 로컬에 저장
5. 클라이언트는 API를 호출할 때마다 헤더에 JWT 토큰을 넣어서 전송
6. 서버는 헤더를 확인하여 JWT의 서명을 공개키로 인증하고 API에 대한 응답 반환 

[구조]

Header.Payload.Signature

 

: Header, Payload, Signature 3개로 구성

• Header : 알고리즘, 토큰 타입
• Payload : 사용자 정보의 한 조각인 클레임(claim)
• Signature(서명) : 헤더와 페이로드의 문자열을 합친 후에, 헤더에서 선언한 알고리즘과 비밀키를 이용해 암호화한 값

 

Header와 Payload는 단순히 Base64로 인코딩 되어 있어 누구나 쉽게 복호화할 수 있지만,

Signature는 비밀키가 없으면 복호화할 수 없다.

 

---

✨ 추가 질문

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

세션은 Stateless 원칙에 어긋나는 인증 방식이 맞다.

하지만 여전히 편의성과 서버 제어의 유리함 때문에 사용된다.

 

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

서버가 여러 대가 되면, 세션은 서버 내부가 아닌 외부 저장소에 저장하거나 요청을 항상 같은 서버로 보내도록 처리해야 한다.

가장 보편적이고 확장성 있는 방식은 Redis 같은 중앙 세션 저장소를 사용하는 방법이다