Cookie란?
cookie는 내 컴퓨터 하드디스크에 저장되어있으며, 빈번하게 로그인을 할 때 하드디스크에 저장되어있는 정보로 따로 로그인을 하지 않아도 Server가 자동으로 기억을 할 수 있게 해준다.
만약 다른 컴퓨터로 접속하면 로그인을 진행하지 않아도 쿠키로 로그인이 가능할까?
내 컴퓨터 하드디스크에 정보가 저장되어있기 때문에 Server가 알아 볼 수 없기에 자동으로 로그인이 불가능하다.
4가지 Component
- 쿠키값을 server가 response메시지에 실어서 보낸다.
- 그 값이 하드디스크에 저장되어있고 다음 그 사이트에 접속 시 request 메시지에 실어서 보내기 때문에 server는 사용자가 누구인지 알 숭 있다.
- Server는 쿠키ID를 기반으로 해서 Cilent가 서버에 접속해서 어떤 action을 취했는지 기록하고 그 기록을 기반으로 cilent에게 맞춤형 서비스를 제공할 수 있다.
위에 그림에서 볼 수 있듯이 쿠기는 다음과 방법으로 로그인을 진행 할 수 있게 된다.
- cilent에서 서버로 request 메시지를 보낸다.
- server에서는 응답메시지에 set-cookie header에 cookie번호를 실어서 cilent쪽으로 보내준다.
- 2번째 요청 메시지를 보낸 경우는 cookie header에 cookie번호를 실어서 Server쪽으로 보내준다.
- Server쪽에는 backend database부분에 cookie번호에 각각 대응 되는 공간에 사용자의 기록들을 저장해둔다.
- 1주일 후에 접속을 하여도 별다른 로그인없이 cookie번호를 request 메시지에 실어서 보내기 때문에 server는 cilent가 누구인지 알 수 있게 된다.
HTTP Protocol은 Stateless한 프로토콜이지만 쿠키를 사용하면서 server는 사용자의 기록을 저장 할 수 있게 되었다.
옛날에는 쿠키를 많이 자동으로 사용하였지만 요즘에는 보안상의 문제로 웹사이트에서 쿠키를 사용할 것인지 확인 후 진행을 하게 된다.
Web Caches
cilent의 요청 메시지를 original Server까지 거치지 않고 응답을 받을 수 있는 것을 목표로 한다.
Cache란?
컴퓨터구조 수업시간에도 배울 수 있듯이 CPU의 빠른 속도를 메모리가 따라잡기 위해 Cache라는 임시 저장소를 만들어 미리 원하는 데이터를 빠르게 가져 올 수 있도록 설계 되어있는 것이 바로 Cache이다.Web cahce도 비슷한 개념으로 이용 될수 있다.
위에 그림에서는 proxy server(가짜 서버)를 두어 웹 cache를 하고 있는 모습이다. client가 proxy서버에게 요청을 보내고 만약 proxy서버의 데이터가 존재하지 않는다면 proxy서버가 cilent입장이 되어 original server에게 다시 request 메시지를 보내고 받아온 데이터를 다시 client에게 보내준다. 만약 proxy 서버에 object file이 존재한다면 바로 cilent쪽으로 응답메시지를 보내 줄 것 이다.
Web cache는 언제 사용하는 것이 좋을까?
- proxy server가 RTT가 짧을 경우
- Original server의 RTT가 클 경우
- 동일한 데이터를 자주 Server로 부터 가져오는 경우
- cilent의 요청메시지에 대한 응답메시지가 다시 돌아오는 시간을 줄이기 위해서
간단하게 Web caching이 왜 필요하지에 대한 과정을 시나리오로 확인해보자
각각의 Host들이 browser를 통하여 하나의 orginal server에만 요청 메시지를 보내는 경우에는 요청메시지는 작은 패킷이기에 별로 시간이 오래 걸리지 않지만 server에서 object file을 보낼 시 access link의 데이터 전송속도가 느리기 때문에 Router의 queue에서 대기를 하는 시간이 너무 오래걸려 문제가 발생한다.
그래서 위와 같은 문제를 해결하기 위한 첫번째 방법은 바로 acces link의 데이터 전송속도를 빠르게 증가 시키는 방법이 있다.
첫번째 방법의 경우 속도를 증가시키면 빠르게 데이터를 보낼 수 있기에 queue에서 대기하는 시간이 줄어 들 것이다. 하지만 단점으로 비용적인 측면에서 비효율적이다라는 것이다.
두번째 해결방안으로는 Web Cache방법이 있다. 이런 경우 access link를 거치지 않고 바로 local web cache서버로 가기 때문에 속도측면에서 응답메시지를 보내는 것이 빨라 질 수 밖에 없고 access link를 비싼것을 설치하는 것보다 비용적인 측면에서 훨씬 더 효율적이다.
하지만 만약 모든 cilent들이 서로 다른 서버에게 요청메시지를 보낸다면 web cache는 별로 효율적이지 않을 수도 있다.
그러므로 얼마나 많은 cilent들이 서로 동일한 서버에게 요청을 할 때 web cache가 효율적인지 알려주는 cache hit rate에 대한 개념을 이해 해야된다.
Cache hit rate
Cache hit rate는 원하는 데이터가 local web cache에 있어 그곳에서 응답메시지를 받는 확률이다.
cache hit rate로 시나리오 확인해보기
만약 cahce hit rate가 40%라면 web cache쪽에서 응답을 받아오는 것이 전체 중 40%라는 것이고 나머지 요청메시지들은 original server에서 응답을 받아올 것이다. 이런 경우 40%의 개별 사용자가 자기가 요청을 보내서 응답을 받는 시간은 access link를 통과하지 않기 때문에 속력이 굉장히 빠를 것이고 원래는 cache가 존재하지 않았다면 모두 original server에서 응답메시지가 왔어야 하는 것을 60%로 줄어들었기 때문에 queue에서 대기하는 시간도 줄어든다.
그러므로 전체적인 평균시간을 확인헸을 때 더 시간을 단축시킬 수 있다.
cache의 단점은 존재하지 않는 것일까?
단점이 물론 존재한다. original server에서 원본이 업데이트가 된 경우에는 cache server에 존재하는 파일이 원본과 다를 수 있기 때문에 문제가 발생한다. 그래서 이러한 문제를 해결하기 위해서 original server에게 데이터가 변경되었는지를 확인 메시지를 별도의 요청메시지를 보내 응답메시지를 받아야 된다. 이런 경우에는 작은 packet으로 요청 메시지를 보내고 응답 메시지를 받기 때문에 오랜 시간이 걸리지는 않는다. 그리고 만약 original server에게 object file이 변경되었다는 메시지가 도착하면 original 서버에서 파일을 바로 넘겨주는 방식으로 구성된다.
'Network' 카테고리의 다른 글
컴퓨터네트워크_P2P application (0) | 2022.05.17 |
---|---|
컴퓨터네트워크_DNS (0) | 2022.05.10 |
컴퓨터네트워크_Web, HTTP (0) | 2022.05.04 |
컴퓨터네트워크_Application layer (0) | 2022.05.04 |
컴퓨터네트워크_Protocol Layers (0) | 2022.05.02 |