Session, Cookie

---

Cookie, Session 등장 배경

HTTP 통신은 요청(Request) -> 응답(Response)이 종료되면 stateless(상태가 유지되지 않은) 한 특징 때문에 연결을 끊는 처리 방식이다.
로그인과 같은 일을 할 때, '누가' 로그인 중인지 상태를 기억하기 위해 쿠키, 세션, 토큰을 사용한다.

1. Connectionless 프로토콜 (비연결 지향)
   클라이언트가 서버에 요청을 했을 때, 요청에 맞는 응답을 보낸 후 연결을 끊는 처리방식이다.
2. Stateless 프로토콜 (상태정보 유지 안함)
   클라이언트의 상태 정보를 가지지않는 서버 처리 방식이다. 클라이언트와 첫번재 통신에 데이터를 주고 받았다 해도, 두버재 통신에 이전 데이터를 유지하지않는다.

 Cookie

쿠키는 일종의 서버와 클라이언트가 대화하기 위한 수단.

HTTP 웹 사이트에 해당 페이지의 HTML을 요청하면, 응답을 받는 순간 연결이 끊어진다.

=> 계속해서 사용자의 정보를 들고 있는게 아님

 예를 들어 사용자가 쇼핑몰에서 랭킹을 보고 있는데, 5위 옷이 괜찮아보여서 상품상세를 클릭하고 다시 랭킹 페이지로 나왔을 경우 컴퓨터는 사용자가 5위까지 봤다는걸 모르기에 1위부터 랭킹을 보여준다. 이 때 사용자가 불편함을 느끼는 것을 방지하고자 나타난게 Cookie이다. 로그인 정보 같이 유저가 굳이 다시 서버에 다시 요청하기에는 비효율적인 정보를 로컬에 저장해둠으로써 생산성을 높인다.

Cookie 통신 방법

1. 최초 통신에서는 Cookie 값이 없으므로, 클라이언트는 서버에 Request
2. 서버에서 클라이언트가 보낸 Requset Header에 쿠키가 없을을 판별하고, 통신 상태(User ID, Password, 조작상태, 방문횟수 등)을 저장한 Cookie를 Response
3. 클라이언트의 브라우저가 받은 쿠키를 생성/보존
4. 두 번째 연결부터, HTTP Header에 쿠키를 실어서 서버에 Requset

Cookie 제약 조건

• Cookie는 1개의 도메인에 한정. ex) 네이버에 의해 생성된 Cookie가 구글로 보내질 수 없다
• Cookie는 자동으로 보내질 수 없다 ex) 서버는 원하는 만큼 Cookie를 보낼 수 있고, 브라우저는 자동으로 Cookie를 저장 '쿠키를 저장하시겠습니까?'와 같은 팝업창을 보지 못한 이유
• Cookie는 자동으로 세팅, 유저가 세팅 할 수 없다
• 클라이언트는 총 300개의 쿠키를 저장할 수 있다.
• 하나의 도메인당 20개의 쿠키를 가질 수 없다 -> 20개가 넘으면 가장 적게 사용되는 것부터 삭제된다.
• 하나의 쿠키는 4KB저장 가능하다

Cookie 장점

• 다시 서버에 Request할 필요가 없기에 속도가 빠르다.

Cookie 단점

• 로그인 정보 등 사용자의 정보가 저장되는 경우가 많아 보안이 취약한다.

Cookie 사용 예시

• 팝업 보지 않기, 사용자 이전 스크롤링이나 뷰 설정 값 등

---------------------------------------------------------------------------------------------------------------------------

• 한번 쿠키가 생성된이후 클라이언트가 재요청 할 때마다 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.
• 특정 호스트에서 생성된 쿠키는 이후 모든 요청마다 서버로 전송됨
• 요청 헤더의 Set-Cookie 속성에 정보를 담을 수 있음
• 쿠키에 담긴 데이터는 브라우저에서 관리됨
• 이름, 값, 만료 날짜, 경로 정보로 구성

---

쿠키는 공개 가능한 정보를 사용자의 브라우저에 저장시킨다. ( 유출되도 된다?  ㅡ> X )

 Session

• 서버와 클라이언트의 연결이 활성화된 상태.

Session 통신 방법

1. 클라이언트가 서버와 통신을 시작하면 서버는 해당 클라이언트에 대해 유일한 값인 세션ID를 부여, 세션 스토리지에 세션 정보를 저장함.
2. 클라이언트는 이 세션ID를 쿠키를 통해 기억함.
3. 이후 클라이언트가 어떤 요청을 보낼 때마다 헤더의 쿠키에 세션ID를 담아서 전송함.
4. 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 세션 id와 세션 스토리지에 담긴 세션 id를 대조해 인증 상태를 판단함.
5. (즉, 세션과 쿠키는 완전히 분리된 개념이 아니며 세션은 쿠키를 기반으로 함)
6. 각 클라이언트마다 유니크한 세션 객체가 주어지고, 이 세션 객체에 데이터를 담아 관리할 수 도 있음.
7. (세션 객체가 자물쇠로 잠긴 상자라면 세션 id 가 열쇠인 셈)
8. 세션을 사용하지 않고 쿠키만으로 어떤 데이터를 주고받는다면, 클라이언트는 이미 모든 데이터를 알고 있다는 것.

Session 장점

• 클라이언트는 세션ID만 알고 있고, 서버가 정보를 저장하기 때문에 보안성이 좋다

Session 단점

• 서버에 거쳐서 정보를 받아야하기 때문에 속도가 느리다.

Session 사용 예시

• 로그인 정보 유지
• 예를들어 사용자의 로그인 상태를 유지하는 기능을 위해 쿠키에 아이디와 비밀번호를 담아두고 있다.
• 이렇게 된다면 개인 소유가 아닌 컴퓨터에서 사용할 경우 사용자의 개인정보가 유출, HTTP로 개인정보를 주고 받다보면 쿠키가 유출, 조작이 될 수 있는 보안상 큰 문제를 야기
• Session은 비밀번호와 같은 인증 정보를 쿠키에 저장하지 않고 대신에 사용자의 식별자인 Session ID를 저장합니다. 서버에는 인증 정보와 더불어 이 ID에 해당하는 사용자의 정보를 저장
• 세션은 서버에 저장하기 때문에 사용자가 수백, 수천, 수만으로 늘어난다면 해당 유저의 정보를 찾고 데이터 매칭에 오랜 시간이 걸리면서 서버에 부하가 가해지게 됩니다.

 

<계정 정보를 요청 Header 에 넣는 방식>

 보통 앱에서는 서버로 HTTP 요청을 할 때 따로 암호화 되지 않으므로, 해커가 HTTP 요청을 가로채서 사용자의 계정 정보를 알 수 있기에 위의 방법으로는 절대 해서는 안된다.

Session / Cookie 방식

Session/Cookie 방식 인증은 기본적으로 세션 저장소를 필요로 하며, 세션 저장소는 로그인시 사용자 정보를 저장하고, 열쇠로 사용할 수 있는 세션 ID 를 만든다. 그리고 HTTP 헤더에 실어 클라이언트에게 보낸다. 브라우저는 세션 ID를 포함하는 쿠키를 저장하고있으며, 인증이 필요한 요청에 해당 쿠키를 끼워 서버에 Request 를 보냅니다.