최근에는 웬만한 웹 서비스들은 대용량 트래픽 처리가 가능해야 기본이라 할 수 있다. 그만큼 여러대의 서버를 사용하는 방법으로 많은 요청을 감당하고 있을텐데, 이 클라이언트와 서버 간의 통신 상태가 유지되는가, 유지하지 않는가를 구분할 수 있다.

(서버 입장에서)

클라이언트의 상태를 유지하는 Stateful

하나의 클라이언트(요청)이 종료될 때까지 하나의 서버 내에서 처리할 때 이 상태를 Stateful(상태유지)라고 한다. 서버는 클라이언트의 요청을 기억(상태를 유지)하며이전 요청의 결과를 활용 가능 다음 요청을 처리한다.

그러나 이는 같은 서버에서 계속 처리해야 한다는 단점이 있다. 또한 상태 유지에 Resource가 많이 소모되고, 트래픽이 몰리면 Resource가 버티지 못할 수 있으므로 위험성이 높다. 동작하던 서버도 시스템 에러나 비즈니스 로직 이슈가 발생할 수도 있다.

반대로 클라이언트의 상태를 유지하지 않는 Stateless

그렇다면 여러 개의 서버에서 요청을 처리해도 동작을 수행하게 하려면 어떻게 해야 할까?
통신에 필요한 클라이언트의 상태 정보를 서버가 아니라 클라이언트가 요청과 함께 서버에 전달되도록 하면 된다. 그러면 서버는 단순하게 요청에 맞는 응답만 처리해 전송하면 된다. 상태 유지의 책임을 클라이언트가 갖는 것이다.
확장성도 올라가고(요청량이 많아지면 서버만 증설하면 된다) 하니 좋아보이지만 단점도 존재한다. 클라이언트가 통신 상태를 전송해야 하기 때문에 전송 데이터가 많아지고, 실제로 서비스를 이용할 때는 통신 상태를 유지해야 하는 경우가 다반수다.

어떻게 하면 Stateless의 장점을 가지면서 통신 상태를 유지할 수 있을까?
이를 도와주는게 Cookie → Session → Token(정확히는 JWT만 서술)이다.

Cookie

🍪 쿠키는 클라이언트에 저장할 목적으로 생성한 파일로 정보를 담아준다.
이 정보는 웹 브라우저에 저장되며 사용자의 상태나 세션을 유지해 사용자 경험을 개선하기 위해 주로 사용된다.

How to

Set-Cookie와 같이 처음에 인증-인가 과정을 진행한 뒤 → 인증이 필요한 새로운 요청이 들어왔을 때는 사용자 정보가 들어있는 쿠키를 조회해 그 값으로 인증-인가를 진행한다.

웹 페이지에서 개발자도구(단축키 F12)를 열면 상단 탭의 Application이 있다.
Application(상단 탭) - Storage - Cookies에서 현재 URL과 그 안에 담긴 쿠키를 확인할 수 있다.

그렇다면 이걸 구현하려면 어떻게 해야 할까?

위와 같이 실습을 통해 쿠키 생성(create-cookie)과 쿠키 조회(get-cookie)를 구현했다.

http://localhost:8080/api/create-cookie

Http 요청(res)를 변수로 받아 해당 요청과 쿠키 값으로 쿠키를 생성해내 return "createCookie"를 화면에 띄우는 로직이다.

http://localhost:8080/api/get-cookie

인증-인가 과정에서 쿠키의 값을 조회할 수 있도록 로직을 구현해 return "getCookie"를 화면에 띄우는 로직이다.

그러나 이런 쿠키도

• 클라이언트가 임의로 변경할 수 있다는 점
• 데이터가 탈취되기 쉽다는 점
  에서 보안 관점에서 개선될 필요가 있었다.

그래서 등장한

Session

💿 Session세션은 서버에서 중요한 정보를 보관하면서 통신 상태를 유지할 수 있는 방법이다.

How to

최초 인증-인가 과정이 성공하면 Server에서 임의로 Session ID를 생성한다. 그리고 생성된 세션 ID와 조회했던 사용자 정보를 서버의 세션 저장소에 따로 저장해둔다. 여기에는 사용자와 관련된 중요한 정보를 보관하고, 클라이언트가 (상태 유지에 필요한 최소한의 정보)전달받은 Session ID는 쿠키에 담긴다.

그 후 인증-인가가 필요한 요청이 전송되면(보낼 때 클라이언트는 쿠키의 세션 ID를 전달한다) 서버가 그 ID와 세션 저장소의 ID를 조회해 본다.

• 세션 ID에는 중요한 정보가 들어있지 않도록 하고, 문제(LIKE 해킹)가 의심될 경우 해당 세션만 제거하면 된다.
• 천년만년 임의로 생성된 ID를 보관하고 있으면 보안의 의미가 없기 때문에 일정 시간이 지나면 세션이 만료되도록 설정해야 한다.

그러나 위에서 언급한 것처럼 데이터가 한 서버에 저장될 경우 다른 서버가 그 정보를 알 수 없다는 단점이 똑같이 세션에도 적용된다. 그리고 인증을 처리할 때마다 서버에서 ID를 조회해야 하니 그만큼 시간이나 메모리가 소요된다.
(처리를 위해 소요되는 간접적인 처리시간이나 메모리를 '오버헤드'라고 한다.)