[컴퓨터 네트워크] 18. 쿠키(Cookies)와 웹 캐싱(Web Caching)

■ 온라인에서의 사용자 경험 향상

 인터넷 쇼핑몰을 이용하다보면 접속만 했는데도 로그인이 되는 경우가 있다. 심지어 아직 로그인을 하지 않았는데도 이전에 접속해서 쇼핑 카트에 담아두었던 물건 목록들이 그대로 남아있을 때도 있다. 로그인한 상태라면 로그인 했었던 정보를 가지고 쇼핑 카트의 정보를 남겨놓을 수도 있겠지만 로그인을 하지도 않았는데 어떻게 이런 일이 가능한 것일까? 앞에서 공부한 HTTP의 특성을 살펴보면 더더욱 이해가 되지 않는다. 왜냐하면 HTTP는 클라이언트의 상태를 저장하지 않는 stateless(무상태) 성질을 갖기 때문이다.

 그래서 HTTP는 기본적으로 이러한 상태 저장 기능을 제공하지 않기 때문에 쿠키(Cookies)라는 것이 새로 개발되었다.

 

■ 상태를 저장하는 쿠키(Cookies)

 위의 그림을 살펴보자. 왼쪽은 클라이언트 컴퓨터이고 오른쪽은 서버 컴퓨터이다. 클라이언트 쪽을 보면 쿠키 파일이라는 것이 있다. 현재 쿠키 파일에는 ebay 8734라는 것이 들어있다. 아마 이전에 ebay라는 사이트에 접속했다가 만들어진 정보로 추측된다. 하지만 이제는 클라이언트가 amazon에 접속하는 상황을 살펴볼 것이다.

 클라이언트는 HTTP request message를 가지고 amazon 서버에 접속을 시도한다. amazon 서버는 새로 접속한 클라이언트에게 자동으로 ID를 만들어서 임의의 번호를 할당한다. 위의 그림에서는 1678이라는 번호를 할당하고 그것을 자신의 데이터베이스에 저장해두었다. 그리고 request에 대한 응답으로 response message를 보낼 때 set-cookie라는 필드에다 1678이라는 서버가 생성한 쿠키 아이디를 담아서 전송한다. response message를 받은 클라이언트의 브라우저가 set-cookie라는 명령을 발견하면 자신의 쿠키 파일에다가 amazon에서 부여받은 쿠키 아이디 1678을 저장한다.

 클라이언트가 amazon 사이트를 돌아다니다가 접속을 종료한 후 다음에 다시 amazon 서버에 접속하게 되면 브라우저는 자신의 쿠키 파일을 살펴본다. 지난번에 amazon에 접속한 기록이 있는지, amazon에서 쿠키 아이디를 받은 기록이 있는지 찾는다. 쿠키 파일에 amazon에서 1678이라는 쿠키 아이디를 받은 기록이 있기 때문에 이번에 접속할 때는 request message를 보낼 때 쿠키 아이디를 같이 담아서 보낸다.

 그러면 쿠키 아이디가 담겨진 request message를 받은 amazon 서버는 자신의 데이터베이스에서 이전에 1678이라는 쿠키 아이디를 사용했던 사람의 저장되어있던 활동 정보를 꺼내온다. 그래서 따로 로그인을 하지 않더라도 쇼핑 카트에 이전에 담아두었던 물건 목록들을 확인할 수 있는 것이다.

 

■ 브라우저에서의 쿠키

 쿠키는 클라이언트의 상태 정보를 서버가 유지하기 때문에 프라이버시를 침해한다고도 볼 수 있다. 그래서 사용자가 쿠키를 사용하고 싶지 않은 경우 위의 그림처럼 각 브라우저마다 쿠키를 삭제할 수 있는 기능을 제공한다. 쿠키가 삭제되면 클라이언트 측의 쿠키 파일이 사라지기 때문에 request message를 보낼 때 쿠키 아이디가 같이 담지 않는다.

 

■ 웹 캐싱과 프록시 서버

 어떤 한 기관에서 많은 사람들이 같은 사이트에 접속을 할 경우 request와 response와 같은 메시지들이 클라이언트와 서버 사이를 계속 오간다면 오버헤드가 굉장히 클 것이다. 그런데 해당 기관에서 중간에 프록시 서버(porxy server)를 하나 설치할 경우를 살펴보자.

 어떤 사람이 특정 사이트에 접속하기 위해 request message를 보내면 처음에는 해당 사이트의 서버가 있는 오리진 서버(origin server)에 갔다가 response message를 받아올 것이다. 그러면 여기서 받아온 정보를 그냥 클라이언트에 전달해주고 끝나는 것이 아니라 중간의 프록시 서버가 보관해둔다. 그리고 이전에 접속했었던 클라이언트나 다른 클라이언트가 같은 사이트에 대한 접속 요청을 하면 프록시 서버에 저장되어 있는 정보를 response 해준다. 이미 프록시 서버에 오리진 서버에서 받아 온 데이터가 저장되어 있기 때문에 굳이 오리진 서버까지 request message를 보낼 필요가 없는 것이다.

 결국 프록시 서버는 첫 번째 request에 대해서는 오리진 서버에 전달해주고 response를 받음으로써 클라이언트로 동작을 했다고 볼 수 있다. 두 번째 request에 대해서는 클라이언트에 대해서 서버로 동작을 했다고 볼 수 있다.

 

■ 웹 캐싱의 효과

 웹 캐싱을 하게 되면 좋은 점들이 있다. 클라이언트 입장에서는 자신이 보낸 request가 진짜 오리진 서버에 갔다 올 필요가 없기 때문에 응답 시간이 매우 짧아지는 장점이 있다. 서버 입장에서는 매번 자신에게 날아왔어야 할 request message들을 프록시 서버가 대신 해결을 해주니까 처리해야 하는 용량이 적어진다.

 로컬 네트워크를 운영하는 입장에서는 로컬 ISP에서 인터넷으로 연결되는 부분이 request와 response가 너무 많이 생기면 병목 현상이 일어날 수 있다. 그렇게 되면 전체적으로 인터넷 서비스 품질이 낮아진다. 하지만 중간에 프록시 서버를 설치하여 대부분의 request를 처리하게 만든다면 외부 인터넷과 로컬 인터넷을 연결하는 링크의 용량을 쓸 필요가 적어진다. 그러면 전체적으로 서비스가 원활해지는 장점이 생기게 된다.

 

 

 

※ 본 정리 내용은 부산대학교 유영환 교수님의 컴퓨터 네트워킹 수업을 정리한 것입니다.

※※ 강의에 사용된 교재 : [Computer Networking A Top-Down Approach 7th edition / Jim Kurose, Keith Ross]