오늘 공부한 것
쿠키, 세션, 캐시
쿠키 세션 캐시를 알기 이전에
HTTP의 특징을 조금 알아보아야 한다.
1. stateless
상태 정보를 유지하지 않는다
=> 그니까, 클라이언트에서 서버에 요청을 보낸 후 응답이 다 끝나면, 서버는 그 클라이언트를 기억하지 않는다. (그러니까 쿠키, 세션이 필요한 것)
2. connectionless
클라이언트가 서버에 요청했을 때 그에 맞는 응답을 보낸 후 연결을 끊는다.
그런데, 이렇게 되면 사용자가 사이트를 이용하면서 로그인하고, 다음 페이지로 가거나 다른 사이트를 갔다가 오면 연결을 끊어버리기 때문에 이용이 불편해진다.
따라서, 데이터 유지가 필요한 것이고, 그 상태 데이터를 어디다가 저장하느냐에 따라 쿠키, 세션으로 나뉜다.
쿠키
사용자 브라우저에 저장된다. (그래서 모바일에는 없다)
중요한 정보는 세션이 가지고 있고, 그 세션은 user 의 정보를 가지고 있는데, 그 user의 정보와 일치하는지 안하는지 확인하려면 클라이언트도 어떤 매개체를 가지고 있어야 한다.
그것이 바로 쿠키. 쿠키는 세션 id를 가지며 그 id로 세션에 등록이 되어 있는 user를 확인하여 웹 사이트를 잘 돌아다닐 수 있도록 인증해줄 때 필요한 것이다.
한 마디로 내가 가지고 있는 데이터들(브라우저에 저장되어 있는).
내가 임의로 고치거나 지울 수도 있기 때문에 보안성이 낮다.
그래서 해커가 가로채가거나 파괴되어도 큰 일이 나지 않는 정보들을 저장한다.
HTTP 통신 시 헤더에 포함되는 텍스트 데이터 파일이다.
통신 방식
1) 처음 요청을 보내게 되면 쿠키가 없으므로 그냥 Request한다.
2) 서버에서 클라이언트가 보낸 Request Header에 쿠키가 없다는 것을 알게 되면 상태를 저장한 쿠키를 같이 Response 해준다.
3) 받은 쿠키를 사용자는 브라우저에 저장한다.
4) 다시 요청을 보내게 되면 HTTP 헤더에 쿠키를 포함해서 서버에 Request 하게 된다.
제약 조건
1) 총 300개의 쿠키 저장 가능
2) 도메인 하나 당 20개의 쿠키 저장, 많아지면 적게 사용되는 것 부터 삭제
3) 쿠키 하나 당 4KB 저장 가능
쿠키 사용 예시
1) 로그인의 아이디 자동생성
2) 로그인 안한 상태로 장바구니 담기
3) 팝업창 오늘 안보기
등등
세션
서버가 가지고 있는 내용들
쿠키는 임의로 수정이 가능하기 때문에 위험하므로 중요한 데이터들은 서버에서 세션에 저장해둔다.
브라우저가 종료될 때까지 유지된다.
사용자들이 이 사이트에서 어디, 어떻게 무엇을 하는지 저장해둔다
무엇을 할 때마다 저장되어 있는 쿠키와 세션에 있는 데이터를 판별.
세션은 사용자(컴퓨터)마다 쿠키 아이디 같은 것을 주는데, 그것을 가지고 사용자는 브라우저에 쿠키에 저장해두면서 그 사이트 돌아다닐 때 마다 세션 ID를 http 요청에 같이 실어 보내면
사이트의 다른 부분을 돌아다녀도 몇몇 정보들이(로그인 같은) 그대로 남아있게 되는 것이다.
만약 사용자가 로그인 해놓고, 쿠키를 다 지워버리면 http 요청을 다시 보낼 때 거기 안에는 세션에서 부여받은 아이디가 없으므로 세션은 이를 인증해 주지 않는 것.
인증과 인가?
인증: 인증은 Authentication으로 사용자가 이 웹 사이트를 사용해도 되는 사람인지 아닌지 판단하여 내주는 것. 로그인을 거쳐 DB에 있는 user인지 확인이 되면 인증해주는 것.
인가: 인가는 Authorization 이미 로그인으로 인증을 받은 user가 그 웹사이트 안에서 여러 페이지를 돌아다니거나 기능을 사용할 때 그때마다 로그인해서 인증을 받을 수 없으므로 사용이 편하기 쉽게 어떠한 것을 이용해서 "인가"해주는 것.통신 방식
1) 사용자가 서버에 접속 시, 세션 ID를 발급한다.
2) 서버에서는 발급한 세션 ID를 쿠키를 이용해서 저장한다.
3) 클라이언트는 다시 페이지에 접속할 때 쿠키에 저장된 세션 ID를 HTTP에 실어 보낸다.
4) 서버는 헤더에 쿠키 정보(세션 ID)로 클라이언트를 판별한다.
따라서, 쿠키에는 어떤 것을 저장하고, 세션(서버)에는 어떤 것을 저장할 것인지를 잘 판단해야한다. 쿠키에는 너무 민감한 정보는 들어가면 안되고, 그렇다고 또 세션에 많은 정보들을 담게 되면 접속자가 많아지면 서버가 터져버리는 현상이 발생할 수 있는 것이다.
그래서 나온 것이 JWT!
JWT
세션 DB에 user들의 정보를 저장해두고, 클라이언트 요청이 올 때마다 db를 뒤져서 일치하는 user 정보가 있는지 없는지 확인하고, 다시 전달해주고...
이게 웹사이트 안에서도 다른 페이지로 이동할 때마다 발생한다. 얼마나 비효율적이고, user가 많아지면 심지어 db 리소스를 많이 잡아먹으며 날라가면 답도 없어지는 것이다.
JWT는 이러한 단점을 보완해준다.
토큰(Token)이란 것은 인코딩된 string이다.
예를 들어 JWT가 User1_AA_Gildong_AA_11/1 라고 했을 때 이 값 자체를 복호화 해서 User1, Gildong, 11/1 이라는 정보를 얻어 유저를 구분하는 방식이라고 한다. 유저 정보와 토큰 만료 기간까지 정보들을 담고 있다.
자세히는 JWT는 헤더/header, 정보/payload, 사인 구조/sign signature로 정보(xxxx.yyyy.zzzz)를 담고 있다.
헤더와 정보는 비밀키없이 암호화되어 있다. => 누구나 바꿀 수 있어 보안에 취약하긴하다.
사인 키는 비밀키를 이용해 암호화 되어 있다.
좀 더 깊게 들어가자면, 정보만이 좀 아무나 디코딩해서 읽을 수 있는 값인데, 이러면 누가 막 바꾸고 그러면 위험하니까, 헤더와 사인구조 정보로 보호한다.
1번 헤더 정보에는 type(항상 JWT)가 들어가면 alg라는 것도 있는데, 이것이 3번 사인 구조를 만들 때 사용한 알고리즘(여러 암호화 방식)을 무엇으로 썼는지에 대한 정보를 담고 있다. 따라서, 헤더 정보에 있는 alg 방식에 사용자 정보와 서버가 가지고 있는 어떠한 비밀 값을 가지고 알고리즘을 돌리면, 3번 사인 구조가 나오게 되는 것이다.
이렇게 되면 서버에 있는 비밀값을 알기전까지 아무리 2번 정보를 바꾸어도 3번 사인 구조가 맞지 않게 되기 때문에 조금 안전해 질 수 있다는 것이다.
따라서, 첫 로그인이 실행되어 클라이언트에서 요청을 보내게 되면, 서버에서는 해당 클라이언트의 정보를 가지고 JWT를 발행하여 넘겨준다. (정보들을 ENCODE하여)
서버는 DB에 따로 저장을 할 필요도 없어 토큰이 유효한 클라이언트에 인증(토큰을 DECODE하여 확인)을 해주므로 사용자가 편하게 페이지를 돌아다닐 수 있게 되는 것이다.
이미 발급한 JWT는 서버에서 DB에 저장을 하고 있지 않기 때문에 서버에서 클라이언트 쪽으로 임의대로 만료시킬 수 없다.(클라이언트 쪽에서 만료되었다는 토큰을 담은 요청이 오기 전까지)
따라서, 로그인 한 정보를 계속 담고 있기가 위험하다(보통 만료일을 짧게는 30분 길게는 2시간 정도로 많이 사용하며 대신 자주 발급하는 방식)
캐시
한 번 가져온 데이터는 다시 메모리에 넣었다 뺐다 하는 비효율을 줄이기 위해서 사용되는 것.
웹 뿐만 아니라 안드로이드, 컴퓨터 메모리에도 비슷한 개념으로 사용이 된다.
웹에서는 사용자가 처음 요청하여 이미지들을 받아오면 이미지나 CSS, JS 등 재사용되거나 용량이 커서 왔다갔다하는데에 리소스가 많이 드는 파일들을 브라우저에 저장해두거나 중간 서버에 저장해놓는 것. 이것을 캐시라고 한다.
쿠키는 정보를 저장하는 것이고, 캐시는 렌더링 속도를 높이기 위한 목적.
