[Network] 네트워크 | Cookies

 

서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로 웹 사이트가 사용자를 확인하는 것이 바람직할 때가 있다. 이 목적으로 HTTP는 쿠키를 사용한다. 쿠키 기술은 네 가지 요소를 가지고 있다.

1. HTTP 응답 메시지 쿠키 헤더 라인

2. HTTP 요청 메시지 쿠키 헤더 라인

3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일

4. 웹 사이트의 백엔드 데이터 베이스를 갖고 있음

 

 

쿠키가 어떻게 작동하는 지 예시로 알아보자. 집에 있는 PC로 항상 웹 접속을 하는 수잔이 처음으로 아마존 닷컴에 접속했다고 가정하자. 과거에 그녀는 이미 이베이 사이트를 방문한 적이 있다고 가정한다. 아마존 웹 서버에 요청이 들어올 때 그 서버는 유일한 식별번호를 만들고 이 식별번호로 인덱스되는 백엔드 데이터베이스 안에 엔트리를 만든다. 그런 다음 아마존 웹 서버는 수잔의 브라우저에 응답하는데, 이 HTTP 응답에 식별번호를 담고 있는 Set-cookie: 헤더가 포함된다. 

 

 

 Set-cookie: 1678 의 헤더로 수잔의 브라우저에 응답을 하게 된다. 그 다음 브라우저는 관리하는 특정한 쿠키 파일에 그 라인을 덧붙이게 된다. 그 라인의 서버의 호스트 네임과 Set-cookie: 헤더와 식별번호를 포함한다. 특히 아마존 서버로의 각 HTTP 요청은 다음과 같은 헤더라인을 포함한다. Cookie: 1678.  아마존 웹 사이트는 사용자의 이름을 알 필요는 없지만 1678 사용자가 어느 페이지를 언제 어떤 순서로 열었는지 확인할 수 있다..

 

 

 

정리하자면 쿠키는 사용자 식별에 사용할 수 있음을 알 수 있다. 사이트에 처음으로 사용자가 방문하면 사용자는 사용자 확인을 제공한다. 다음 세션 동안에, 브라우저는 서버에 쿠키 헤더를 전달하여 서버에게 사용자를 확인한다. 비록 쿠키가 사용자를 위해 인터넷 쇼핑 경험을 간소화 하지만, 사용자 사생활에 대한 침해로 보일 수 있음에 따라 커다란 논쟁거리이다.

 

 

 

Web Cache는 기점 Web server를 대신하여 HTTP 요구를 충족시키는 네트워크 개체이며, 최근 호출된 객체의 사본을 저장 및 보존한다.위 그림처럼 브라우저는 사용자의 모든 HTTP 요구가 Web Cache에 가장 먼저 보내지도록 구성될 수 있다. 예를 들어 http://www.someschool.edu/campus.gif 를 요구한다고 생각해보자.

1. 브라우저는 Web Cache와 TCP 연결을 설정하고 Web Cache에 있는 객체에 대한 HTTP 요청을 한다.

2. Web Cache는 객체의 사본이 지역적으로 저장되어 있는지 확인한다. 만일 저장되었다면 Web Cache는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.

3. 만약 Web Cache가 객체를 가지고 있지 않다면 Origin Server에 TCP 연결을 설정한다. 그리고 나서 Web Cache는 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이런 Request를 받은 후 Origin server는 Web Cache로 HTTP 응답 메시지와 함께 객체를 보낸다.

 

 

 

일반적으로 Web Cache는 ISP가 구입하고 설치한다. Web Cache의 장점으로는 다음과 같은 것들이 존재한다. 첫째, 웹 캐시는 클라이언트 요구에 대한 응답 시간을 줄일 수 있다. 둘째, Web Cache는 인터넷으로의 기관 접속 회선상의 웹 트래픽을 실질적으로 줄일 수 있다. 셋째, Web Cache를 가진 고밀도 인터넷은 비록 콘텐츠 제공자가 저속도의 접속 회선을 가진 느린 서버에서 자신의 사이트를 운영하더라도 빠른 콘텐츠 분배를 위한 기반구조를 제공한다.

 

 

 

 

그림은 Public Network와 기관 Network를 보여준다. 기관 네트워크에 있는 라우터와 인터넷에 있는 라우터는 1.5Mbps 회선에 연결되어 있다. 웹 객체의 크기가 100K bit이므로 평균 요청 비율이 1초당 15라고 가정할 수 있다. 그러므로 HTTP의 요청이 무시할 만큼 작으므로 어떤 Traffic도 발생시키지 않는다고 가정하자. 또한 접속 회선의 인터넷 부분 라우터가 HTTP 요청을 전달하고 응답을 받을 때까지 평균 소요 시간은 2초라고 가정하자. (비공식적으로 Internet Delay라고 부른다)

 

총 요청 시간 (브라우저가  HTTP 요청을 하고 객체를 수신할 때까지 걸리는 시간) 은 LAN 지연 + 접속 지연 (Router Delay == Access link Delay) + 인터넷 지연의 합과 같다. Utilization을 살펴보면 트래픽의 강도가 1에 가까워지면 회선 지연이 매우 커지고 한없이 증가하게 된다. 따라서 평균 응답 시간이 몇 분이 걸리므로 기관 사용자에게 적합하지 않다.

 

 

 

한 가지 방법은 Access link rate를 크게 늘리는 것이다. 그러면 두 라우터 간의 전송 지연을 무시할 수 있는 수준이 0.15 까지 접속 회선의 트래픽 강도를 낮추게 된다. 이 경우에 총 응답 지연은 Internet delay에 해당하는 2초만 걸릴 수 있는 것이다. 하지만 이 해결책은 기관이 접속 회선을 100배 빠르게 개선해야 하므로 많은 비용이 들어간다.