[네트워크] Chap 2.3 -Cookies, Web caches(proxy server), HOL blocking

Cookies🍪

• HTTP is a stateless protocol which does not keep status of a HTTP client at a server.
• However, using cookie a server can maintain information about its clients.

HTTP는 이전 상태의 정보를 저장해두지 않는 stateless한 프로토콜이다.

그러나, cookie를 사용하면 client에 대한 정보를 서버가 유지시킬 수 있다.

 

client가 어떤 사이트에 처음 접속할 때, client는 HTTP request msg를 보내고, 해당 사이트의 server는 접속한 client에 대한 unique한 ID (cookie)를 세팅해주고 back-end database에 저장해놓는다. 

 

쿠키의 4가지 구성요소

1. cookie header line of HTTP response msg (

2. cookie header line in next HTTP request msg (다음 HTTP request msg의 coockie 헤더라인)

3. cookie file (user의 browser가 관리하며 user의 host에 의해 보관)

4. back-end database at Web site

 

 

 

1st-party cookie (자사 쿠키)의 example

 

1. client가 Web server에게 HTTP request msg를 보냄
2. server는 client에게 HTTP response msg를 보냄과 동시에 set-cookie를 알려줌.
   client는 이 쿠키 파일을 보관 & server는 cookie를 만든 후 back-end databse에 entry를 생성하여 저장.
3. client가 이후 똑같은 웹사이트의 server한테 HTTP request msg를 보낼 때, cookie 정보도 header에 넣어서 보냄.
   => server는 cookie 정보를 이용하여 database에 접근하여 cookie가 존재하는지 확인
4. server가 client에게 HTTP response msg를 보냄.
5. 일주일 후, client가 같은 웹사이트에 접속하여 server한테 HTTP request msg를 보냄 (cookie정보도 헤더에 넣어서)
6. server는 back-end database를 조회 & response msg를 보냄

일주일이 지나고, 컴퓨터를 껐다가 다시 켜도 이 cookie 값으로 다시 요청하는 것이 가능

 

 

cookie가 사용되는 예시

• authorization - 인증 정보 저장 → 로그인 유지
• shopping carts - 페이지에서 나가도 장바구니 유지
• recommendations - 맞춤형 추천 콘텐츠
• user session state (Web e-mail)

 HTTP의 stateless하다는 성질을 cookie를 이용하면 statefull하게 만드는 것이 가능하다

 

third-party cookie (타사쿠키)

내가 접속한 웹서버(A)가 아닌 다른 회사(B)에서 발행한 쿠키를 이용함. 회사 B는 이를 이용하여 나의 cross-site 이력을 추적(tracking)하여 필요한 광고를 노출시켜 이득을 취함 & A를 이를 허용하고 B 로부터 광고 수익을 얻는 구조. 최근 privacy 이슈로 apple/firefox 회사는 이미 safari/mozilla에 타사 쿠기사용을 blocking 하였으며, 90%의 수익을 광고에서 얻고 있는 google은 좀 늦게 blocking 하고있는 추세.

 

---

Web caches (proxy server)

origin server를 거치지 않고 client의 request를 수행하는 것이 목적

 

• Why does HTTP get message include URL of the original server although TCP already has connection?

TCP connection 후에도 clinet가 HTTP request msg에 server host의 URL을 넣어서 보내는 이유

 

proxy server는 보통 client들과 같은 LAN, 같은 Access ISP 내에 있다. 하나의 LAN에 있는 client들이 똑같은 웹페이지를 방문할 확률이 높기 때문에 proxy server를 사용한다. (proxy server도 같은 LAN 안에 있음)

만약 client가 요청한 웹페이지가 proxy server에 없는 경우 (= miss) origin server에게 요청해야 한다.

=> HTTP client가 origin web server의 URL을 request msg에 포함하는 이유

 

 

proxy server는 주로 같은 ISP내에 설치한다.

 

 

- Hit (object가 cache에 있는 경우)
: proxy server에서 해결 가능. cache가 client에게 object를 리턴

 

- Miss (obejct가 cache에 없는 경우)
: cache가 origin server에 요청을 보내 object를 받은 후, client에게 리턴
→ origin server에 요청을 보낼 때, Web cache가 client가 되고, origin server는 server가 된다.

 

 

 

Web cache는 client와 server 양쪽 모듈을 다 가지고 있다.

- original requesting client에게는 server의 역할

- miss여서 origin server에 요청을 보낼 때는 client의 역할

 

일반적으로 cache는 ISP에 의해 설치된다

 

 

 

Web caching의 장점

• reduces the average dealy (good for clients)
  : client의 요청에 대한 response time이 줄어든다. (hit인 경우! cache는 client와 더 가까우므로)
• reduces access link BW utilization (good for access ISP)
  : institution's access link의 traffic 감소
  ex) KT한테 나가는 link에 필요한 용량이 줄어들면 비용을 절감할 수 있다.
• reduces (poor) server overhead (good for web servers)
  : poor content providers에게 효율적으로 컨텐츠를 전달 가능
• can be used for auditing or controlling access to external web servers
• P2P caching 주의점
  : 만일 ISP가 P2P caching을 지원한다면, peer들이 저작권침해 파일을 주고받을 수 있으므로 자칫 ISP가 법을 위반할 수도있어 주의가 필요함.

 

Web caching의 단점

• The web contents stored at Web servers may be out-of-date.
• The web cache may transform the original image(inconsistency between an original server and a web server). "cache-control: no-transform"

---

Caching Motivation

 

- access link rate : 1.54 Mbps

 

- RTT (router ~ origin server) : 2 sec

- avg object size (패킷 길이) : 100K bit (= L)

 

- avg request rate from browser to origin server (초당 queue에 얼만큼 들어오는지) : 15 req / sec  (= a)

 

- avg data rate to browsers(유입률) : 1.5 Mbps (= L*a)

 

 

• LAN utilization = 1.5 Mbps / 1 Gbps = 0.015
• Acces link utilization = L*a / R = 1.5 Mbps / 1.54 Mbps = 0.97 (99%)
• end-to-end delay = (Internet delay) + (Access link delay) + (LAN delay)

Access link delay를 줄이는 방법은?

1. 분모 늘리기 (Access Link transmission rate 늘리기)

2. 분자 줄이기 (Data rate 줄이기 → Web cache)

 

 

 

 

sol1) faster access link

 

 

sol2) web cache

 

---

Conditional GET

cache가 최신 cached 버전을 가지고 있다면, object를 보내지 않는다. (불필요한 transmissiond delay 방지, lower access link utilization을 위해)

proxy server - origin server의 client가 됨

 

cache

If-modified-since: <data>  =>HTTP request에 캐시된 copy의 날짜를 지정

 

server

304 Not Modified => cache copy가 최신일 경우 response에는 object가 포함되지 않음.

200 OK => 데이터가 수정된 경우 object를 줌. proxy server는 last-modified 필드의 날짜를 갱신

---

HTTP/1.1 (Persistent HTTP)

server는 나한테 들어오는 client의 request 순서대로 처리함 (FCFS, First Come First Serve)

FCFS 스케줄링으로 인해, 굉장히 큰 object 뒤의 작은 object는 큰 객체 때문에 전송되지 못하고 오래 기다리기도 함.

→ User perceived delay가 늘어난다.

response time이 긴 요청에 대해서 뒤따라오는 후속 요청이 처리되지 못하고 delay 발생
=> HTTP HOL blocking : HTTP/2 에서 해결한다. (framing)

 

 

O1 request가 처리될 때까지 작은 object들인 O2, O3, O4는 기다려야함!

=> HTTP HOL blocking

 

 

 

 

HTTP/2

HTTP HOL blocking을 해결하기 위한 HTTP/2의 두가지 방법 : framing하는 방법 / priority를 주는 방법

objects divided into frames, frame transmission interleaved (HTTP가 직접 framing을 한다)

HTTP/2 는 HTTP HOL blocking을 해결할 수 있지만 (User-perceived dealy가 좋아진다), 여전히 문제점이 있다.
TCP는 서로 다른 object들을 하나의 connection에서 동일한 sequence number로 rdt를 하므로 특정 object의 frame 한개가 도착을 안하면 그 뒤로 모두 잘 도착한 object들이 receiver의 buffer에서 대기하게 된다.
=> TCP HOL blocking : QUIC으로 해결한다.

만약 segment 1 (O1꺼)에서 miss가 난 경우, TCP는 order에 맞게 주는것이 목표이므로 2, 3, 4 번째 segment를 못준다. 즉 O2, O3, O4가 다 와서 host의 메모리에 있는데도 불구하고 display를 시키지 않는다. (TCP HOL blocking)

이러한 문제를 해결할 수 있는 방법이 HTTP non-persistent with parallel인데, 이 방법은 불공평하기 때문에 나오게 된 것이 Framing & Multiplexing과 QUIC이다.

 

QUIC

(TCP HOL blocking 해결)

TCP-like function이다.

같은 object끼리 rdt를 함 (앞의 예제에서는, 같은 색깔끼리인 O2, O3, O4에 대한건 다 왔으니까 먼저 올려보내고, O1에 해당하는 초록색들만 대기시킨다. (앞에 segment 1이 안왔으므로)) => per stream rdt

Unlike TCP (rdt service per connection), QUIC provides rdt service per stream(object)
=> 즉 하나의 UDP 연결에 전송되는 작은 단위의 프레임들을 object 별로 구별하여 retransmission. 이로써 이미 도착한 작은 크기 object에 해당하는 프레임이 앞서 loss된 다른 object 프레임을 기다릴 필요가 없어지므로 TCP로 인한 HoL blocking이 해결됨.

 

 

 

HTTP/3

QUIC을 통합함.