HTTP(2)

---

HTTP response

HTTP(1)의 request message에 대한 response message이다. 이 또한 ASCll 코드로 전송된다.

Status code는 server-to-client response message의 첫번째 줄에 전송된다.

 

Sample codes

200 OK - 확인, 전송해줄게.

301 Moved Permanently - 해당 내용이 여기에 있었는데 데이터가 옮겨져서 이젠 없어.

400 Bad Request - 어떤 걸 요청하는지 모르겠어.

404 Not Found - 요청을 이해하긴 했는데 해당 내용이 없어.

505 HTTP Version Not Supported - 버젼이 맞지 않아.

 

---

Cookies

우리가 web site에서 자주 보는 메세지에 포함된 쿠키라는 것은 user의 접속 이력을 저장하는 file이다.

이는 stateless의 성질을 갖고 있는 HTTP가 state를 keep하도록 만든다.

 

쿠키의 네가지 요소

1) cookie header line of HTTP response message

2) cookie header line in next HTTP request message

3) cookie file kept on user ’s host, managed by user’s browser

4) back-end database at Web site

 

위처럼 회원가입을 하지 않아도 자체적으로 ID를 만들어서 Backend Database에 해당 user에 대한 데이터를 저장해두고 추후에 추천시스템과 같은 곳에 활용하여 서비스를 제공한다.

---

Web caches(proxy server)

프록시 서버는 진짜인척하는 가짜 서버이다.

client들이 자주 접근하는 web page를 캐싱해두었다가 추후에 client가 같은 web page를 요청하면 실제 origin server에 접근하지 않고 client에게 보내줘서 network 사용량을 줄이기 위해 프록시 서버를 이용한다.

client가 origin server에 요청을 하면 proxy server가 origin server인척 request를 가로채고 저장해둔 page면 origin server인척 response를 보내고 없다면 origin server에 client인 것처럼 client가 request한 HTTP를 request하고 response를 받아 client에 전달한다.

예를 들어 대학교에서 프록시 서버를 구축해서 학생들이 많이 접속하는 naver, google과 같은 페이지를 저장해둘 수 있다.

 

프록시 서버를 구축함으로써 대학교에서는 core server 접속비를 아낄 수 있다.

이때 KT와 같은 인터넷 회사는 직접 접속하는 고객이 줄어서 손해가 발생하긴 하지만 그들 또한 프록시 서버를 이용하여 naver, google의 서버에 접속하는 비용을 아낄 수 있다. 특히 해저 케이블에 연결하여 글로벌 서버에 연결해야할 때는 적은 양의 케이블 사용료를 내도 되기 때문에 이득을 본다. 또한 고객들이 자체적으로 프록시 서버를 이용하여 인터넷 지연등의 현상이 방지되어 고객 서비스 품질 향상에는 도움이 된다.

Naver와 같이 서버를 제공하는 회사들 또한 서버 증설비용을 아낄 수 있어서 모두가 win-win하는 훌륭한 기술이라고 볼 수 있다.

 

다음 예시를 통해 Caching의 효율성을 계산보자.

문제 상황은 browser들로 전송되는 데이터가 평균 1.5Mbps인데 acces link rate가 1.54 Mbps여서 99%가 차있는 상황이다.

acces link를 증설하는 방식으로 해결을 하면 아래와 같이 된다.

access link를 10배로 증설하니 access link utilizaion이 10%이하로 내려가 access link speed가 매우 증가했지만 그 비용이 너무 많이든다.

아래는 Caching을 이용한 방법이다.

이때 프록시 서버의 성능은 cache hit rate로 평가하는데 hit rate가 0.4라고 했을때 아래와 같이 계산이 된다.

access link를 통해 전송되는 데이터 = 0.6 * 1.50 Mbps = .9 Mbps -> utilization = 0.9/1.54 = .58

access link 사용량이 58%이고 이때 total delay를 계산하면 아래와 같다.

 

total delay = 0.6 * (delay of origin servers) +0.4 * (delay in proxy server) = 0.6 * 2.01 + 0.4 * ~msecs = ~ 1.2 secs

이는 15.4Mbps로 증설하였을 때보다 빠르고 훨씬 경제적이다.

---

Local cache update

Local 캐시는 client의 요청사항을 origin server에서 확인하지 않고 자체적으로 보내주기 때문에 local web cache의 freshness 즉 update가 굉장히 중요하다.

이에는 두가지 방법이 존재한다. 우선 아래와 같이 conditional GET을 이용하여 update가 된 경우에만 origin server로 부터 새로운 데이터를 받아오는 방식을 이용할 수 있다.

두번째로는 server에서 response를 줄때 해당 page의 life-time을 포함시켜서 보내주는 방법이다.

---