ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • TIL.10 쿠키_세션_캐시 그리고 토큰_2
    TIL 2020. 10. 18. 23:48
    728x90

    ## 캐시 ##

    캐시(cache)는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다. 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있다. (출처 : ko.wikipedia.org)

    캐시는 시스템의 효율성을 위해 여러 분야에서 두루 쓰이고 있다.

    캐시란 개념은 웹 뿐만이 아닌 컴퓨터의 메모리 부분, 안드로이드 등 다양한 곳에서 쓰이며,

    공통적인 의미로는 가져오는데 비용(_시간?) 이 드는 데이터를 한 번 가져온 뒤에는 임시로 저장할때 사용한다.

    이처럼 한번 받아온 데이터를 사용자의 컴퓨터 또는 중간 역할을 하는 서버에 저장해둔다.

    쿠키/세션은 캐시와 다르다!

    • 캐시는 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것이다.
    • 한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있다.

    출처: https://interconnection.tistory.com/74 [라이언 서버]

    https://www.youtube.com/channel/UC2nkWbaJt1KQDi2r2XclzTQ(출처 : youtube_얄팍한 코딩사전)

    1. Memory 관련 캐시 (CPU 캐시 메모리)

    대용량의 메인 메모리 접근을 빠르게 하기 위해 CPU 칩 내부나 바로 옆에 탑재하는 작은 메모리이다.

    아래 컴퓨터의 CPU - Memory - DIsk 가 있다.

    Disk에 저장되어있는 File 들의 일부(노란Box)가 메모리에 올라오고

    CPU에 의해 실행이 되고 명령어가 실행이되고 파일이 열린다.

    중요한 것은

    CPU 안에 작은 고속의 메모리가 들어있는데, (회색 Box) 

    들어 있는 이유 : 메모리는 고가 및 빠른속도를 가지고 있는데, 그것보다도 더 빠르게 데이터를 처리하기 위해

    메모리 중 일부를 CPU 안에 탑재 시킨다. (내부 구조에 관한 이야기)

    이때 이 일부의 데이터를 미리 가져오거나, 사용되고 있는 자체를 캐시 메모리에  데이터가 있다고 말할 수 있다.

    이때 CPU는 캐시 메모리를 바로 사용하므로써 빠르게 데이터를 처리할 수 있다.

     

    2. File 관련 캐시

    사용자가 브라우저를 통해 서버에 요청을 보내면 응답이 오는 구조에서

    브라우저         ====================> (url)        ==========>      서버

                       <================= (html, img..) <=========== 

    이중 img의 경우 Text보다 크기가 크고, img를 다시 불러올 가능성이 있기때문에

    이 브라우저가 구동되는 어느 특정 공간에 이 img를 저장하는데 

    이러한 File들이 저장되어 있는것들을 캐시 되어있다 라고 표현할 수 있다. (목적 또한 캐시 메모리와 동일하다)

    그렇기에 처리 속도가 빠르지만, 단점으로 img 같은 파일을 서버에서 바꾸었는데 브라우저에서 해당 파일을 바꾸는 주기가 아니라면 최근 서버의 img와 다른 경우가 종종 발생하며 이 경우 캐시를 지우면 다시 데이터를 받아 일부 저장한다. (상단 내용 재확인 가능)

    3. CDN 관련 캐시 (Contents Delivery Network) // 특히 개발자에게 필요한 정보

    브라우저      ==============> HTTP : url ===============>      서버

                     <================= (html, img..) <=========== 

    여기서 만약 서버를 (미국 등 물리적으로 멀리 떨어져있는 기업이라 가정해보자)

    클라이언트(브라우저) 와 서버 사이에

    서버에 있는 html. img. music 등의 파일들을 미리 중간 지점에 네트워크망을 구축 및 데이터 저장을 해 놓는다.

    브라우저에서 요청이 올 경우 중간 지점의 네트워크망에서 빠르게 정보를 받아 올 수 있으며

    해당 네트워크망 안에 저장되어 있는 정보들을 가르켜 해당 파일이 캐시 되어 있다고 표현이 가능하다

    https://www.youtube.com/watch?v=jXLeXgIWNbQ(출처 : youtube_기술노트 with 알렉)

    출처

    https://www.youtube.com/watch?v=jXLeXgIWNbQ(출처 : youtube_기술노트 with 알렉

    https://www.youtube.com/channel/UC2nkWbaJt1KQDi2r2XclzTQ(출처 : youtube_얄팍한 코딩사전)

    참고

    m.post.naver.com/viewer/postView.nhn?volumeNo=15948884&memberNo=36916118

     

    ## 토큰 ##

    일반적으로 지금까지 웹에서의 인증은 쿠기 - 세션을 많이 사용해왔다.

    쿠키는 보안에 취약하고 세션은 비교적 보안에 안정적이라는 인식이 강했다 하지만 최근들어

    더 안정적이고 모바일 환경에 적합한 인증밥법으로 토큰 기반 인증이 많이 사용되고 있다.

    토큰의 정의는 소프트웨어 또는 하드웨어에서의 어떤 작업을 수행할 수 있는 권한을 나타내는 객체이다. 인증, 암호화 등 중요 작업에 많이 사용된다. (by Wikipedia)

    세션의 문제점으로 나왔던 '서버의 확장성'을 토큰기반 인증을 하게되면 많은 문제가 해소된다. 토큰 기반은 일단 Stateless 서버로 상태를 유지하지 않는다. 세션에 유저의 인증 정보를 저장해놓지 않는다. 세션 대신에 토큰 기반 인증은 서버에서 토큰을 생성하여 클라이언트에게 signed토큰(정상적으로 발급된 토큰)을 발급해준다. 이 때, 서버는 HTTP 요청의 헤더에 토큰값을 포함시켜 전달한다. 클라이언트는 발급받은 토큰을 저장해두고, 서버에 요청할 때마다 함께(요청+토큰) 서버에 전달한다. 서버는 토큰을 검증하고 요청에 응답한다.

    https://m.blog.naver.com/dmswjd93/221284561424(출처)


    이런 과정을 거치는 토큰 기반 인증은 무상태 stateless이기 때문에 확장성scalability이 있다.
    또, 쿠키를 전달하지 않음으로 쿠키로 인한 보안에 대한 불안을 해소할 수 있다. 또, 토큰을 사용하여 다른 서비스에서도 권한을 공유할 수 있다. 예를 들어, 잡코리아에서 naver, google 계정 로그인을 가능해지는 경우이다.  

     

    (토큰 기반)Stateless 서버 vs (세션 기반)Stateful 서버
    Stateful 서버 : 클라이언트에게서 요청을 받을 때 마다, 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스 제공에 이용한다. 예로는 세션을 유지하는 웹서버. 여기서 이 세션은 서버 컴퓨터의 메모리에 담을 때도 있고 데이터베이스 시스템에 담을 때도 있다.
    Stateless 서버 : 상태정보를 저장하지 않으면, 서버는 클라이언트측에서 들어오는 요청으로만 작업을 처리하며 클라이언트의 상태를 유지하지않는다. 이렇게 상태를 유지하지 않는 경우에는 클라이언트-서버의 연결고리가 없기 때문에 확장성이 높아진다.
     위의 차이를 근거로 토큰 기반과 세션 기반은 여러 차이가 존재한다. 세션 기반 인증을 하게된다면 유저가 인증을 할 때, 서버는 이 정보를 서버에 저장해야 하며 이를 세션이라 한다. 유저의 수가 많아지게 되면 서버의 메모리 또는 데이터베이스 성능에 무리가 오게 된다. 따라서 서버 확장이 어렵다. 

    출처 : m.blog.naver.com/dmswjd93/221284561424

    728x90
Designed by Tistory.