Cookie & Session

📌 쿠키와 세션을 사용하는 이유

HTTP 프로토콜은 일반적으로 Connectionless, Stateless한 환경입니다.

이로써 server는 User가 누구인지 매번 확인해야 하는 상황이 생깁니다.

이를 보완하기 위해 Session과 Cookie를 이용합니다.

---

Connectionless (비연결성)

User와 Server간 통신을 할 때 request와 response를 주고받은 후 바로 연결이 끊기는 특징

• 연결을 유지하기 위해 resource를 줄여 더 많이 연결할 수 있으나 매번 연결 과정을 반복해야하므로 Overheading이 발생할 수 있습니다.
• 이에 대한 해결책으로 KeepAlive 속성을 HTTP1.1부터 Default로 가지고 있습니다.

  이는 지정된 시간동안 Packet 교환이 없을 경우, 접속을 끊기 전 어느 정도 Packet을 주기적으로 보내는 것을 의미합니다.

• 이를 통해 Client 상태 체크를 하나 서버에 과부하가 걸릴 경우 역시 한계가 존재합니다.

---

Stateless (무상태)

Server는 User를 식별할 수 없습니다. 즉, Client가 누군지 모릅니다.

---

🍪 Cookie

Client Browser 내에 저장되는 데이터 파일

• key, value, expired, ,domain, path로 정보가 이루어져 있다.
• 브라우저가 종료되어도 쿠키 만료시간이 지나지 않았다면, 데이터를 갖고 있어 인증이 유지된다.
• 하나의 Cookie는 4KB까지 저장이 가능하다.
• Client에 300개까지 저장할 수 있으며, 하나의 Domain당 20개의 값만 가질 수 있다.
• 쿠키는 사용자가 따로 요청하지 않아도 Browser가 Request시 Request Header에 넣어서 자동으로 서버에 전송한다.

구성요소

• key(name) : Cookie의 고유한 이름
• value : 쿠키와 관련된 값
• expired : 쿠키의 유지 시간
• domain : 쿠키를 전송할 도메인
• path : 쿠키를 전송할 요청 경로

동작 방식

1. Client가 Server에 Page를 요청
2. Server에서 Cookie를 생성

   Frontend Server/Backend Server 상관없이 Cookie 생성이 모두 가능하다.

3. HTTP Header에 Cookie를 포함하여 Response
4. Cookie 만료 기간이 지날 때까지 Client의 Browser에 보관
5. Client가 같은 Request를 할 경우 HTTP Header에 자동으로 Cookie를 함께 보냄

🔩 Session

Cookie 기반 Server 측에서 관리하는 데이터 파일

• Server 측에서는 Client를 구분하기 위해 각각 고유의 Session ID를 부여한다.

  Client가 Request를 보내면, Server에서 Session ID를 부여

• Browser가 종료되거나 Server에서 Session을 삭제하면 인증이 만료된다.
• Server에서 관리하므로 쿠키보다 보안이 좋으나, 사용자가 많아질수록 Server Memory에 부하가 걸린다.

동작 방식

1. Client가 Server에 접속 시 Session ID 발급
2. Client는 Session ID를 Cookie를 이용해 가지고 있음
3. Server에 요청할 때 Session ID를 같이 서버에 HTTP Header에 request
4. Server는 Session ID를 전달받아 Session에 있는 Client 정보를 사용
5. Server 요청을 처리 후 Client에 응답

주의

• 쿠키와 세션 둘의 과정을 비교한 것입니다.
• 세션 역시 쿠키를 사용하므로 종류를 구분하기보단 정보를 다루는 방식의 차이라고 보는 게 편합니다.