Web Storage와 Session이란?

Storage

• WB내 저장
• WB의 DB같은 느낌
• Storage 등장전에는 Cookie만 섰어야 했다
• Storage: WB의 저장소
  • 유저에 의한 변겅된 옵션 상태 등 필요에 따른 조회가 필요할 때 (진짜 저장소)
  • WB에서만 사용 가능한 큰 정보를 담는다 (만료시간이 없다!)
  • 저장 가능 용량: 10MB
  • 범위: 지정된 Domain내에서 모두 유효
  • 보안: WB내에서만 접근 가능
    • Script로도 접근 가능하다
  • 브라우저간 공유 불가능
  • ex.) 마지막에 어떤 계정으로 로그인 했는지 저장하고, 1년 뒤 로그인할때 표시가능
• Cookie: WS에게 WB가 매번 전달할 특정 정보를 위하 저장소 (Stateful)
  • 로그인 인증 정보 등, WS가 매번 요청할때마다 필요한 정보를 WB에 넣어두고 전달받아 쓰기 가능하다
  • WS에게 반복적으로 전달하기 위한 작은 정보 (만료시간을 가진다)
  • 저장 가능 용량: 4KB
  • 범위: 지정된 Domain + Path에 대해서만 유효
  • 보안: 웹 서버에게 Non-HTTPS 요청 시 노출
    • Script로 접근 여부 제어 가능
  • 브라우저간 공유 불가능
  • 조회 -> 처리 -> 반환
  • Cookie와 Cookie + Session이 Stateuful인 이유:
    • Cookie는 정보가 Client-side에 있다
      • 로그인 정보는 Server의 DB에서 조회가 필요하고 ID + 만료시간을 알아야한다
    • Cookie + Session은 정보가 Server-Side에 있다
      • 만료시간과 ID를 DB에 함께 저장한다
    • 만료 + ID가 어디에 있는지로 구분한다 = Stateful
      • JWT는 정보가 아닌 인증이 완료된 토큰이다
        • 가져오는 순간 의심하지 않고 바로 허용한다
        • 서버 DB에서 가져오지 않는다 = Stateless

---

Session

• 웹 서버 내 저장, 단 SESSION_ID는 웹 브라우저 내 저장 및 전송한다
• 쿠키에 저장하던 값을 웹 서버측에 저장하기 위해 별개의 저장소 DB가 필요하다
  • Cookie vs. Session + Cookie
    • Session을 사용할때 Cookie도 같이 사용한다
      • 여기서 Cookie는 어떤 세션인지 알기위한 ID 값 (SESSION_ID) 저장이 필요하다
    • ex.) WB로부터 Cookie에 SESSION_ID를 받아서 해당 요청 유저의 정보를 조회할 수 있다
• 속도가 매우 중요하다: 수천번의 API 호출마다 Session 조회가 필요하기 때문
  • 요청 -> 조회 -> 처리 -> 반환
    • 조회 시간이 길어질수록 반환값을 받는데 걸리는 시간이 늘어난다
      • 메모리 기반의 DB를 쓰면 빨라진다!
        • Redis를 많이 사용하는데 비싸다...
• Session의 장점 = Cookie의 단점
  1. Session은 정보를 WS에 저장하다보니
     • 민감한 정보들이 WS에 안전하게 저장된다
     • WB간의 공유가 가능하다
       • 여러 WB를 돌아다니며 행동해도 모두 서버에 중앙기록 된다
  2. Session은 정보를 WS에 저장하기에 아무리 많은 정보를 저장하더라도 요청을 방해하지 않는다