[네트워크] Cookie & Session

📍 HTTP 프로토콜의 특징

 

Connectionless; 비연결성

클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징

 

클라이언트와 서버가 연결을 끊기 때문에, 불필요한 연결을 유지하지 않아 서버의 자원을 절약할 수 있다. 따라서 HTTP 프로토콜이 간단하고 효율적이라는 장점이 있다. 

 

Stateless; 무상태성

클라이언트와 서버가 통신을 할 때, 이전 통신의 상태를 유지하지 않는 것

 

무상태성은 HTTP 프로토콜이 확장 가능하고 유연하다는 장점이 있다. 클라이언트와 서버가 상태를 유지하지 않기 때문에, 서버는 클라이언트의 요청을 처리하기 위해 필요한 모든 정보를 요청마다 다시 받아야 한다. 따라서, 클라이언트가 요청하는 서비스가 변경되더라도, 서버는 별도의 변경 없이 요청을 처리할 수 있다.

 

 

 

쿠키와 세션은 위 무상태성을 해결하여 사용자에 대한 인증을 유지하게 하도록 사용한다. 

 

예를 들어, 로그인을 하고 새로 고침을 했을 때 로그인이 풀린 상태가 되지 않는 것이다. HTTP의 무상태성, 비연결성을 생각하면 응답이 끝나면 연결이 끝나기 때문에 이전 통신 상태가 남아있지 않을 것이다. 그러면 새로고침할 때마다 로그인 요청을 보내야하기 때문에 자원이 매우 낭비가 된다. 그렇게 동작하지 않는 것은 쿠키-세션이 있기 때문이다. 

 

---

📍Cookie와 Session의 차이점

이 둘의 가장 큰 차이점은 어디에 저장 되는 지이다. 

 

Cookie는 Client에 저장되고,

Session은 Server에 저장된다. 

 

쿠키는 웹 서버가 웹 브라우저에게 작은 기록 정보 파일을 주는 것이다. 그럼 다음에 브라우저에서 요청을 보낼 때 헤더의 Set-Cookie에 담아서 요청을 전달하게 된다. 하지만 이렇게 쿠키만 사용하는 방식은 보안에 취약하다. 이를 해결하기 위해서 등장한 것이 Session이다. 

 

Cookie와 Session을 이용해서 로그인을 유지시키는 방법은 밑 그림처럼 동작한다.

 

1. 세션은 기존에 쿠키에 저장되던 사용자 정보를 서버에 저장이 되고, 그때 생성되는 SessionId를 쿠키에 담아서 전달한다.(abcd)

2. 클라이언트가 이제 요청을 보낼 때 쿠키에 있는 id값을 전달한다. (abcd)

3. 서버는 이 id를 통해 클라이언트를 식별한다. 

 

---

이런 방식으로 저장하면, 쿠키를 포함한 요청이 외부에 노출되더라도 SessionID 자체는 유의미한 정보를 담고 있지 않는다. 따라서 보안에 좋다. 

 

하지만 이러한 Cookie와 Session을 이용하는 방식은 두 가지 문제점이 있다. 

 

📍보안적 문제 

 

---

📍서버 이중화 문제

서버가 부하가 온다면, 보통 부하 분산을 통해 해결한다. 서버 이중화를 통해 Session을 클러스터링을 하는 경우, 비효율적이라는 문제가 생긴다.

---

 

📍.. Cookie & Session 문제 해결 => Token 기반 인증 방식

이를 해결하기 위해서 토큰을 기반으로 하는 로그인 인증 방식을 사용한다. 

 

로그인할 때 서버가 클라이언트에게 토큰을 발급하고,

클라이언트는 발급받은 토큰으로 인증 받는 방식이다. 

 

세션을 모두 서버에 저장하는 것은 서버에 부하가 크기 때문에 클라이언트에 저장시키는 방식을 요즘은 더 많이 사용한다.