쿠키

웹 사이트에 접속시 정보가 접속자 즉, 클라이언트의 로컬에 저장되는 작은 텍스트 파일이다

ex) 쇼핑몰 사이트에 로그인 하지 않고 장바구니에 상품을 등록해놓은 후 나갔다가 다시 들어와도 상품이 여전히 등록될 수 있게 하는 역할을 해준다

쿠키 동작 순서

1. 클라이언트가 페이지를 요청한다
2. 웹 서버가 요청을 받은 후 쿠키를 생성한다
3. 생성한 쿠키에 정보를 담아서 클라이언트에게 응답할때 함께 보낸다
4. 쿠키를 받은 클라이언트가 다시 서버에 요청할때 함께 전송한다
5. 웹 서버는 업데이트할 정보가 있으면 쿠키를 업데이트하여 다시 응답과 함께 전송한다

클라이언트가 브라우저에 자신의 정보를 담고 있기 때문에 데이터를 요청할때 쿠키를 생성하고 브라우저를 종료할때 쿠키를 삭제한다

(이때 쿠키는 최대 400개의 쿠키를 저장할 수 있고 몇몇개의 제약 조건이 존재한다)

세션

쿠키를 기반으로 하고 있지만 사용자의 정보를 브라우저에 저장하는 쿠키와는 달리 세션은 서버측에서 관리하고 있다. 일정시간동안 같은 사용자로부터 들어오는 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시켜주는 기술이다.

세션 동작 순서

1. 클라이언트가 서버로 접속을 시도한다
2. 서버는 접근한 클라이언트의 쿠키를 확인하여 클라이언트가 해당 세션 id를 보냈는지 확인한다
3. 세션 id가 존재하지 않으면 서버는 세션id를 생성해 클라이언트에게 돌려준다
4. 서버에서 클라이언트로 돌려준 세션id를 쿠키를 사용해 서버에 저장한다
5. 클라이언트는 재접속시 해당 쿠키를 서버에 보내 세션 id를 서버에 전달한다

쿠키 vs 세션

쿠키와 세션은 보안과 저장위치, 라이프 사이클의 차이가 있다. 쿠키는 브라우저에 저장되어 있기 때문에 서버에 접근할 필요가 없어 응답 속도가 빠른 반면에 데이터가 변질되거나 스니핑 당할 위험이 있어 보안에 취약하다. 세션은 서버에 저장되어 있기 때문에 서버의 접근이 필요하다. 그렇기에 쿠키에 비해 응답 속도가 느린 편이다. 하지만 서버에서 처리하기 때문에 비교적 보안성이 좋다.

쿠키와 세션 둘 다 만료시간을 정할 수 있다. 세션의 경우에는 만료시간에 상관없이 브라우저가 종료되면 정보가 삭제가 된다. 쿠키의 경우 브라우저를 종료해도 만료시간이 남아 있는 경우 정보가 삭제되지 않는다.

캐시

필요해 하는 데이터를 로컬등에 미리 저장해두어 보다 빠르게 데이터를 받아볼 수 있게 해주는 역할을 한다. (페이지 로딩 속도 개선)
캐시를 이용해 cdn같은 서비스도 할 수 있다. cdn은 컨텐츠 즉, 데이터를 배달, 딜리버리해주는 서버이다. 다른 지역에서 데이터를 요청하는 경우 지역 중간의 서버에 미리 올려놓은 데이터에 접근하게 해주어 보다 빠르게 응답을 해줄 수 있다.

단점
캐시로 인해 저장된 데이터 공간은 영구적인 메모리 공간이 아니기 때문에 데이터가 지워질 수 있다는 것을 유념해야한다. 캐시에 저장되어 있던 파일들이 업데이트가 된 경우 바로바로 업데이트 된 파일을 가져올 수 없을 수 있다는 단점이 있다.

ex) 종종 변경되어야 하는 데이터가 업데이트 되지 않을때가 있다면 캐시가 이유일 수 있다. (캐시는 서버의 캐시클라우드라는 저장공간에 사용자의 의지와 상관없이 자동 저장되기 때문이다) 웹개발시 css가 업데이트 되지 않는 원인 중 하나가 된다.

Session based auth vs Token based auth(JWT)

대표적으로 로그인을 할때 로그인이 유지되는 방식은 위의 2가지가 존재한다.

session based auth 동작 방식

1. 클라이언트가 서버에게 id, pwd를 post요청으로 보낸다
2. 서버에서 받은 id,pwd가 db와 일치하게 되면 클라이언트에게 알맞은 응답을 보낸다
3. 로그인에 성공하게 되면 서버에서 세션을 생성한다(세션id, 유저id, timeout등의 정보가 담긴다)
4. 클라이언트에게 쿠키안에 세션id를 담아서 보낸다
5. 이후 클라이언트가 요청을 보낼때 쿠키를 함께 보낸다
6. 세션id가 서버안에 존재하면 로그인이 되어졌을때의 페이지를 보여준다

session방식의 한계

해당 작업은 I/O가 상당히 높은 작업이 된다. 서버 내부에 세션을 RAM이라는 공간에 DB형식으로 저장해 놓는데 이렇게 저장이 되는 경우 사용자가 많아지면 하나의 서버로 해결하기에는 한계가 있다

세션 전용 DB를 만들어 해당 DB에 세션ID를 저장해두어 사용할 수 있지만 (로드밸런싱의 단점 보완) 모든 트래픽이 DB에 몰리는 문제가 발생한다

DB를 분배형식으로 나누어 해결할 수 있다

JWT 토큰 방식을 사용하여 효율적으로 해결 할 수 도 있다

token based auth 동작 방식

1. 클라이언트가 id와 pwd를 서버에 보내고 서버는 해당 값을 받아 인증 한 후 토큰을 발급한다
2. 이후 클라이언트는 요청을 할때 해당 토큰을 가지고 데이터를 요청한다
3. 서버에서는 해당 토큰이 맞다고 확인되면 그에 맞는 권한을 클라이언트에게 준다 (세션과는 달리 서버에서 내부적으로 세션을 관리하지 않는다)
4. 서버에서 토큰이 올바른지만 확인하여 권한을 할당해준다 (오로지 요청안에 들어있는 토큰만을 보고 권한을 준다)

대표적으로 JWT 토큰이 사용된다. (jwt의 포맷은 header(어떤 알고리즘으로 암호화 할것인지) - payload(data등을 넣어준다, Ex) 언제 토큰이 끝나는지 원하는 정보를 넣을 수 있다, 네트워크에 정보가 올라가기 때문에 최소한의 정보를 넣는게 좋다) - signiture(이부분만 암호화 된다.))

Q1. 다수의 서버를 이용한다는 것은 무엇을 의미하는가

Q2. 쿠키 헤더에 존재하는 도메인과 경로는 무엇을 말하는가 A2. HTTP 프로토콜의 쿠키헤더에는 Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure]리소스들이 존재한다

• expires : 쿠키의 만료일 문자열이다. 쿠키의 유효한 날자가 날짜 형식으로 써져있다.

• domain : 쿠키가 적용되야하는 호스트를 지정한다. 지정하지 않으면 현재 URI를 기준으로 적용된다

호스트란 ?
네트워크에 연결되어 있는 컴퓨터들

호스트 설정이란 ?
도메인을 호스트의 ip에 연결하는 행위이다 ```

• path : 쿠키 헤더를 서버에서 보내기 전에 요청된 리소스에 있어야하는 url경로를 나타낸다. 즉 path에 지정된 값과 일치하는 url요청에 대해 쿠키를 전송하도록 만드는 옵션이다

• secure : 보안 쿠키를 적용하는 옵션으로 서버에서 요청은 ssl을 사용하며 https를 상용할때만 전송할 수 있다