[Network] 2-2. The Web and HTTP

초기에 인터넷은 연구하는 사람들, 대학생들이 주로 원격 호스트에 로그인하거나 파일을 전송하거나 뉴스, 이메일을 송수신하기 위해서 사용되었다.

그러던, 1990년대 초반, World Wide Web(WWW)이라는 응용 프로그램이 개발되었다.
이는 작업 환경 내외에서 사람들끼리 소통하는 방법을 바꿨고 인터넷을 단 하나의 데이터 네트워크로 승급시켰다.

많은 사람들이 웹을 사용하게 된 이유는 다음과 같을 것이다.

1. Web이 실시간(on demand)으로 동작한다는 점.
   ⇒ 사용자가 원하는 걸 원하는 시기에 받을 수 있다는 점이 큰 장점으로 다가왔을 것이다.
   기존의 라디오, TV는 사용자의 필요에 따라 컨텐츠를 제공한 게 아니라 컨텐츠를 제공하는 측이 강제적으로 사용자에게 컨텐츠를 제공하는 형식이었다는 점에서 달랐다.
2. Web을 통해서 많은 개인들이 정보를 쉽게 만들어서 배포할 수 있었다는 점.
3. Hyperlink와 검색 엔진을 통해 많은 정보를 접할 수 있게 됨
4. Forms, JavaScript, video 등을 통해 페이지와 사이트와 통신할 수 있도록 함
5. 웹과 웹의 프로토콜이 YouTube, 인스타그램, 구글맵과 같은 플랫폼을 제공함

1. Overview of HTTP

HTTP(HyperText Transfer Protocol)는 웹의 응용계층 프로토콜로 웹의 핵심이다. (이에 대해선 RFC 1945, RFC 7230, RFC 7540에 정의되어 있다)

HTTP는 client 프로그램과 server 프로그램에서 구현되어 있다.
client 프로그램과 server 프로그램은 HTTP 메시지를 교환하면서 대화를 주고받는다. HTTP는 여기서 메시지의 구조와 메시지를 교환하는 방식을 정의한다. HTTP에 들어가기 앞서 용어 정의를 먼저 해야 한다.

1. 웹 페이지, object, URL

• Web page(document) : object로 구성된 것
• object : HTML 파일, JPEG 이미지, JS 파일, CSS 시트 파일 등과 같은 파일들 ⇒ 각 object는 하나의 URL로 주소 지정을 할 수 있음

대부분의 웹 페이지는 기본 HTML 파일과 참고 object로 구성되어 있다. (ex. 하나의 웹 페이지 = 하나의 HTML text 와 4개의 이미지)

기본 HTML 파일은 object의 URL을 가지고 페이지에 있는 다른 object를 참조한다. URL은 object를 갖고 있는 서버의 호스트 이름과 object의 경로로 구성되어 있다.

ex) http://www.someSchool.edu/someDepartment/picture.gif

• www.someSchool.edu : 호스트 이름
• /someDepartment/picture.gif : object의 경로

2. 웹 브라우저, 웹 서버

• Web browser : 웹 브라우저는 HTTP의 클라이언트 부분을 구현하기 때문에 browser와 client라는 단어를 혼용해서 사용할 것이다.
• Web Server : 웹 서버는 HTTP의 서버 부분을 구현하는데 URL로 주소 지정이 가능한 Web object를 갖고 있다. ex. 아파치 서버

HTTP는 클라이언트가 서버에 웹 페이지를 요청하는 방법과 서버가 클라이언트에게 웹 페이지를 전달하는 방법을 정의했다. 구체적인 부분에서는 뒤에서 다루겠지만 개괄적인 내용은 아래 그림과 같다.

1) 사용자가 웹 페이지를 요청할 때
2) 브라우저가 페이지에 있는 object에 대한 HTTP 요청 메시지를 서버에게 전송한다.
3) 서버가 그 요청을 받아서 object를 포함한 HTTP 응답 메시지로 반응한다.

HTTP는 TCP를 사용한다.

1) HTTP client는 서버와 TCP 연결을 초기화한다.
2) 연결이 이뤄지면 브라우저와 서버가 소켓 인터페이스를 통해 TCP에 접근한다.
- 소켓 인터페이스가 client 입장에서는 client 프로세스와 TCP 연결사이의 문 역할을 한다.
- server 입장에서는 server 프로세스와 TCP 연결사이의 문 역할을 한다.
3) client는 소켓 인터페이스를 통해 HTTP 요청 메시지를 전송하고 HTTP 응답 메시지를 받는다.
4) server는 소켓 인터페이스를 통해 HTTP 응답 메시지를 전송하고 HTTP 요청 메시지를 받는다.
5) client가 소켓을 통해 메시지를 전송하면 메시지는 client에서 벗어나 TCP 영역에 들어간다.
- TCP는 HTTP에 신뢰성 있는 데이터 전송 서비스를 제공한다고 했다.
- 이는, 각각의 HTTP 요청 메시지와 HTTP 응답 메시지는 완전한 상태로 목적지에 도달하게 된다는 걸 의미한다.

이를 통해 HTTP는 아래 계층의 TCP 내부의 동작 과정을 몰라도 데이터가 손실될 걱정을 하지 않아도 된다.
이것이 바로 계층화 구조의 장점이다.

여기서 중요한 점은 server가 별도의 데이터 저장없이 client에게 요청받은 파일을 전송한다는 점이다.
때문에 짧은 시간안에 client가 똑같은 요청 2번 이상 할 때 서버는 각 요청에 대해 일일이 응답해줘야 한다.

이와 같이 HTTP는 client의 정보를 저장하고 있지 않기 때문에 stateless protocol이라고 불린다.

초기 HTTP 버전 HTTP/1.0은 RFC 1945에 정의되어 있고
2020년 들어서 대부분의 HTTP 트랜잭션이 HTTP/1.1을 통해 이뤄진다. RFC 7230
하지만, 새로운 HTTP/2를 지원하는 브라우저와 웹 서버가 늘고 있다. RFC 7540

2. Non-Persistent and Persistent Connections

인터넷 응용 프로그램에서 client가 요청을 연속적으로 또는 정기적으로 만들어낼 수 있다.
이 상황에 대해서 다음과 같은 고민이 발생한다.

- 각각의 요청을 별도의 TCP 연결 위에서 전송할 것인가? --- ①
- 각각의 요청을 동일한 TCP 연결 위에서 전송할 것인가? --- ②

①의 경우를 Non-persistent connections라 하고 ②의 경우를 persistent connection이라 한다.

이 방식을 깊게 이해하기 위해서 특정 응용 프로그램에서 동작하는 persistent connection의 장단점을 알아보자.
여기서 말하는 응용프로그램은 HTTP를 예로 들 것이고 HTTP는 Non-persisit와 persist를 둘 다 지원한다.
default로는 persistent connection을 사용하지만 Non-persistent connection으로 설정을 변경할 수 있다.

HTTP with Non-Persistent Connections

Non-persistent connection을 통해 server ⇒ client로 웹 페이지가 전송되는 과정을 살펴보자.

ex) 웹 페이지 = 1개의 base HTML + 10개의 JPEG 이미지로 구성되어 있다. 그리고 11개의 모든 object는 같은 서버에 존재한다.

URL은 다음과 같다.

http://www.someSchool.edu/someDepartment/home.index

• 과정
  1) HTTP client가 server (www.someSchool.edu:80) 와의 TCP 연결을 초기화 (80은 HTTP의 기본 포트 번호) & TCP 연결이 이뤄지면서 client와 server에 각각 socket이 존재할 것이다.
  2) HTTP client가 HTTP 요청 메시지를 소켓을 통해 server에 전송한다. 이때, 요청 메시지는 경로 정보 (/someDepartment/home.index)를 포함한다.
  3) HTTP server 프로세스는 소켓을 통해 요청 메시지를 전달받고 /someDepartment/home.index 경로에 있는 object를 가져와서 HTTP 응답 메시지에 해당 object를 캡슐화해서 소켓을 통해 client에게 응답 메시지로 전달한다.
  4) HTTP server는 TCP에게 TCP 연결을 종료하라고 얘기한다. (하지만, TCP는 client가 응답 메시지를 온전하게 받을 때 까지 연결을 종료하지 않는다.)
  5) HTTP client가 응답 메시지를 받으면 TCP 연결이 종료된다. 메시지는 캡슐화된 object가 HTML 파일이라는 걸 나타낸다. client는 응답 메시지에서 그 파일을 꺼내서 HTML 파일을 분석하고 10개의 JPEG object의 참조값을 찾아낸다.
  6) 참조된 JPEG object들을 받기 위해서 1) ~ 4) 과정을 반복한다.

브라우저가 웹 페이지를 받으면 그 페이지를 사용자에게 보여준다(웹 페이지를 해석한다).
HTTP는 웹 페이지가 어떻게 해석되는지와 관련이 없다. HTTP는 오직 client HTTP 프로그램과 server HTTP 프로그램 사이의 통신 프로토콜을 정의하기 때문이다.

위 예시를 보면 알겠지만 서버가 object를 보내고 나면 TCP 연결이 종료된다. 즉, connection이 다른 object를 전송할 때 까지 지속되지 않는다. 그러면 위 예시에서 만들어지는 TCP 연결은 1개의 base HTML 과 10개의 jpeg 이미지를 받아야 하니까 11번의 TCP 연결이 이뤄져야 한다.

cf) HTTP/1.0은 Non-persistent connection을 지원했다.

위 과정은 모호한 부분이 있다.

• 10개의 JPEG 이미지를 연속적으로 수행된 10개의 TCP연결을 통해서 얻어낸 건지 (serial TCP connections)
• 몇몇 JPEG 이미지는 동시에 수행된 TCP연결을 통해서 얻어낸 건지 (parallel TCP connections)

사용자는 동시에 수행할 수 있는 정도를 설정할 수 있다. 브라우저는 여러 개의 TCP 연결을 설정해서 각각 다른 부분에 대해 request를 보낼 수 있다. 이렇게 하면 필요한 모든 object를 받을 때 걸리는 응답 시간을 줄일 수 있다.

여기서 client가 요청 메시지를 보내서 필요한 모든 object를 받는데 걸린 시간을 계산해보자.
이 지점에서 Round-Trip Time(RTT)를 정의한다. RTT란 하나의 패킷이 client에서 server로 전송되어서 다시 client에게 돌아오는데 걸리는 총 시간을 의미한다.

RTT는 packet-propagation delay, packet-queing delay, packet-processing delay 시간을 포함한다. (1.4에서 다룬 내용)

이제, 사용자가 hyperlink를 클릭할 때 어떤 일이 벌어지는지 살펴보자.

1) 브라우저가 브라우저와 웹 서버 사이의 TCP 연결을 초기화한다.
- 이 과정은 three way handshake에 포함된 과정이다.
- three way handshake란 client가 TCP segment를 server에 전송하고 서버가 이에 응답한다. client는 server에게 확인(ack) 메시지를 보내는 과정을 통해 TCP 연결을 설정하는 과정을 말한다.
- 여기서 three way handshake의 1,2번째 과정을 통해 하나의 RTT가 만들어진다.

2) client가 요청 메시지를 보낸다. 이때, three way handshake의 3번째 과정인 확인(ack) 메시지도 같이 첨부한다.
3) 요청 메시지가 server에 도착하면 HTML 파일을 client에게 전송한다.

여기서 2), 3) 과정을 통해 또 하나의 RTT가 만들어진다.

시간을 대략 계산하면 2번의 RTT + 요청한 HTML 파일을 찾거나 만들어서 서버에서 전송하는 시간이 전체 응답 시간이 된다.

HTTP with Persistent Connections

Non-Persisten Connection은 단점이 있다.

1) 각각의 요청받은 object에 대해 새로운 연결을 반드시 만들어서 유지해야 한다.
- 각 연결에 대해 TCP 버퍼가 할당되어야 하고 TCP 변수 값이 client와 server에 모두 저장되어야 한다.
- 이는 수백개의 각기 다른 client로 부터 동시에 요청을 처리하는 웹 서버에게 큰 부담이 된다.
2) 각각의 object가 2번의 RTT 만큼의 delivery delay가 발생한다.

HTTP/1.1버전의 persistent connection에서 서버는 response를 전송한 이후에도 TCP 연결을 열어놓는다.
그러면, 똑같은 client와 server 사이의 request와 response를 같은 connection 위에서 전송할 수 있다.

이렇게 되면, 같은 서버에 있는 object에 대해 연속적인 요청이 가능해진다. 왜냐하면, 첫 요청을 하고 나서 그 이후의 요청에 대한 응답을 기다릴 필요가 없기 때문이다(이를 pipelining이라 함). 연속적인 요청을 받으면 그에 대한 object를 연속적으로 보내면 된다.

HTTP는 기본적으로 persistent connection을 사용한다. Non-persistent 와 persistent에 대한 비교는 chapter 2,3의 숙제 부분에서 비교해볼 것이다.

참고 문서

3. HTTP 메시지 형식

자세한 문서 RFC 1945, RFC 7230, RFC 7540

위 문서에 HTTP 메시지 형식의 정의에 대한 내용이 담겨있다.

HTTP 메시지는 요청 메세지 & 응답 메시지 로 2개의 유형이 존재한다. 각각에 대해서 살펴보자.

HTTP Request Message

ex) 대표적인 예시

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

하나씩 뜯어보자.

1) 메시지가 사람이 쉽게 읽을 수 있는 ASCII text로 작성되어 있다.
2) 메시지가 5개의 줄로 이뤄져 있는데 각 줄은 위와 같이 줄바꿈을 통해서 구분되어 있다.

• 맨 마지막 줄은 추가적인 줄 바꿈이 이뤄진 상황이다.

• HTTP 요청 메시지의 전체적인 구성
  1) Request Line : HTTP 요청 메시지의 첫 번째 줄

  • method field ⇒ GET, POST, HEAD, PUT, DELETE와 같은 여러 개의 값이 올 수 있다. 이 중에서 많이 사용하는 건 GET
    • GET은 브라우저가 object를 요청할 때 사용한다.
  • URL field : object가 위치한 경로
  • HTTP version field
  • ex) GET /somedir/page.html HTTP/1.1
  • 브라우저가 /somedir/page.html위치에 있는 object를 요청 & HTTP 버전은 1.1

  2) Header Lines : Request Line의 뒤에 따라오는 여러 줄의 내용

  • ex1) Host: [www.someschool.edu](http://www.someschool.edu) ⇒ object가 어디에 위치하는지를 지정한 내용 (자세한 내용은 아래 나올 2.2.5에서)
  • ex2) Connection : close ⇒ 브라우저가 서버에게 persistent connection을 원치 않는다는 걸 지정한 내용
  • ex3) User-agent : Mozilla/5.0 ⇒ 요청을 만들어서 서버에게 전송하는 브라우저의 유형을 지정한 내용. 이 헤더라인을 통해 똑같지만 다른 버전의 object를 전송할 수 있다.

• 위 예시들을 보면 알겠지만 header line은 정형화된 포맷을 갖고 있다는 걸 알 수 있다

헤더라인이 끝나면 위 그림과 같이 빈 칸(blank line)이 한 줄 있어야 한다. 빈칸이 있고나서 entity body가 존재한다.

GET 메소드를 사용할 때는 entity body가 없지만 POST 메소드를 사용할 때는 entity body를 사용한다.

HTTP client는 POST 메소드를 사용자가 원하는 내용을 채워서 전달할 때 종종 사용한다.
ex) 검색 엔진에서 검색하고자 하는 단어를 전달

POST 메소드를 사용해서 사용자가 전달한 내용을 가진 요청 메시지를 웹 서버에게 전달하고 그 내용과 관련된 웹 페이지를 응답받는다. 다시 말하면, method field 값이 POST라면 entity body는 사용자가 입력한 내용을 포함한다.

물론, HTML에서 GET 메소드를 사용하면서 입력값을 포함한 요청을 보낼 때가 있다.
ex) GET 메소드를 사용하면서 2개의 입력값을 field에 저장한 url ⇒ www.somesite.com/animalsearch?monkeys&bananas
보통 검색할 때 이런 형태의 URL을 자주 본다.

HEAD 메소드는 GET 메소드랑 유사하다.
서버가 HEAD 메소드를 포함한 요청을 받으면 서버는 HTTP 메시지로 응답하지만 요청받은 object를 빼고 응답한다.
보통 디버깅할 때 HEAD 메소드를 종종 사용한다.

PUT 메소드는 Web 퍼블리싱 도구와 같이 종종 사용된다. PUT 메소드는 사용자가 object를 웹 서버의 특정 경로에 업로드할 수 있도록 기능한다.

DELETE 메소드는 사용자 또는 응용프로그램이 웹 서버에 있는 object를 삭제하도록 한다.

HTTP Response Message

ex) 일반적인 HTTP 응답 메시지의 형태 ⇒ 이걸 주의깊게 살펴보도록 하자.

HTTP/1.1 200 OK - status line 
Connection: close - header lines
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
- blank
(data data data data data ...) - entity body 

크게 보면 3개의 부분으로 나뉘어져 있다. 하나의 status line, 6줄의 header lines, 그 다음 entity body.

1) status line : 3개의 필드로 구성되어 있다.
- 프로토콜의 버전 값
- 상태 코드
- 응답 상태 메시지
⇒ 여기서는 1.1버전의 HTTP 프로토콜을 사용했고 요청받은 object를 찾아내서 200 / OK 라는 응답 내용을 보냈다.

2) header lines

• Connection : close ⇒ client에게 메시지를 보내고 나서 TCP 연결을 종료하겠다고 얘기하는 내용
• Date 필드 ⇒ HTTP 응답을 만들어서 서버에 전송하는 날짜와 시간을 의미 (서버가 object를 검색해서 응답메시지에 object를 삽입하고 응답 메시지를 전송하는 날짜와 시간을 의미)
• Server 필드 : 메시지가 어떤 서버에 의해서 생성되었는지 나타낸다
• Last-Modified : 나중에 좀 더 자세히 다루겠지만 로컬 client와 네트워크 캐시 서버에서 object의 캐싱에 있어 중요한 역할을 한다.
• Content-Length : 전송된 object의 바이트 수
• Content-Type : entity body에 있는 object의 타입

response message의 일반적인 형태는 아래와 같다.

자주 사용되는 상태 코드와 관련 문구들

• 200 OK : 요청이 성공했고 정보가 response와 함께 전송되었음
• 301 Moved Permanently : 요청받은 object가 이동했다는 걸 의미. 새롭게 이동한 URL은 response 메시지의 헤더인 Location 헤더에 지정되어 있다. client는 자동으로 새로운 URL을 조회한다.
• 400 Bad Request : 서버가 요청을 이해하지 못했다는 걸 의미
• 404 Not Found : 요청받은 문서가 서버에 존재하지 않는다.
• 505 HTTP Version Not Supported : 있는 그대로임

3번 절에서, HTTP 요청 & 응답 메시지에서 사용되는 header lines에 대해 살펴봤다. 물론 실제로는 소개한 것 보다 더 많은 header lines 들이 존재한다.

4. User-Server Interaction: Cookies

앞서, HTTP 서버는 stateless(상태를 저장하지 않는 특성)이라고 했다. 이를 통해 서버 디자인을 단순화하고 수 천개의 동시 TCP 연결을 통해 개발자들이 고성능 웹서버를 개발할 수 있도록 한다.

하지만, 웹 사이트는 사용자를 식별하기를 바란다.
서버는 사용자 접근을 제한해야 하거나 사용자를 식별하는 기능을 통해 content를 제공해야 하기 때문이다.

이런 목적 때문에 HTTP는 Cookies를 사용한다. 관련 문서
쿠키는 사이트가 사용자를 추적하는데 사용되고 대부분의 상업용 웹 사이트에서 이 기술을 사용하고 있다.

아래 그림과 같이 쿠키 기술은 4가지 요소를 갖고 있다.

1) HTTP 응답 메시지에 있는 쿠키 헤더라인
2) HTTP 요청 메시지에 있는 쿠키 헤더라인
3) 사용자의 종단 시스템에서 유지되고 사용자의 브라우저에서 관리되는 쿠키 파일
4) 웹 사이트에 있는 백엔드 DB

아래 그림을 통해 쿠키가 어떻게 동작하는지 하나씩 살펴보자.

ex) 항상 Internet Explorer를 통해 웹에 접속하는 Susan이 Amazon.com에 처음으로 접속했다고 하자.
그리고 그녀는 과거에 eBay 사이즈에 방문했던 적이 있었다.

아마존 웹 서버에 요청이 들어왔을 때 그 서버는 유일한 ID 숫자를 만들고 그 ID 숫자로 인덱싱된 entry를 백엔드 DB에 저장한다. 그러고 나서 Susan의 브라우저에 Set-cookies: 헤더를 포함해서 응답 메시지를 보낸다. 그 헤더의 값에 유일한 ID 숫자를 포함한다. 예를 들면 Set-cookies: 1678을 포함한다고 생각하면 되겠다.

Susan의 브라우저가 HTTP 응답 메시지를 받으면 브라우저는 Set-cookies: 헤더를 확인한다.
그러고 나면, 브라우저는 쿠키 파일에 line 하나를 덧붙힌다. 그 line은 서버의 hostname과 Set-cookies 헤더에 포함되어 있던 id 숫자값이 포함되어 있다.

그렇다면 이전에 방문했었던 eBay에 대한 entry는 이미 쿠키 파일에 포함되어 있을 거다.

정리하면,

1) Susan이 Amazon site를 방문(웹 페이지를 요청)할 때 마다
2) 브라우저가 쿠키 파일을 파악해서
3) 해당 사이트에 대한 id 값을 추출하고
4) HTTP 요청 메시지를 보낼 때 마다
5) 추출한 id값을 포함한 HTTP 요청 메시지의 header line (Cookie :) 에 id값을 추가해서 전송한다.

일주일 후에 Susan이 Amazon site에 다시 돌아올 때 브라우저는 header line (Cookie: 1678)을 요청 메시지에 추가해서 전송한다.
Amazon은 과거에 그녀가 Amazon 웹 페이지에 방문했던 기록을 토대로 제품을 Susan에게 추천한다.
만약에 Susan이 회원가입이 되어있었다면, 회원가입된 정보와 쿠키값에 추가되어 있던 ID값을 연동할 수 있다.
(이 기술을 이용해서 susan이 이름, 신용카드 번호 등 자신의 정보를 지속적으로 입력하지 않아도 한 번에 결제할 수 있는 서비스를 이용할 수 있다 - one-click shopping)

지금까지의 논의를 통해 쿠키는 사용자를 식별하기 위해서 사용된다는 걸 파악했다.

• 처음에 사용자가 사이트에 방문하면, 사용자는 자신의 정보를 제공할 수 있다.
• 연속된 세션 동안, 브라우저는 쿠키 헤더를 서버에게 전달하고 서버는 그걸 가지고 사용자를 식별한다.

따라서, 쿠키는 stateless HTTP 위에서 사용자 세션 층을 만들어내기 위해서 사용될 수 있다.
ex) 사용자가 Web-based e-mail에 로그인하면, 브라우저가 쿠키 정보를 서버에 전송하고 서버는 사용자의 세션 동안 사용자를 식별해서 서비스를 제공한다.

하지만, 다르게 보면 쿠키는 개인정보의 침해로 볼 수 있다. 웹 사이트가 사용자에 대해서 많은 것을 알아낼 수 있기 때문에 이걸 제3자에게 팔아버릴 가능성 역시 존재하기 때문이다.

5. Web Caching(or Proxy Server)

웹 캐시(또는 프록시 서버)는 원래 웹 서버를 대표해서 HTTP 요청들을 받아내는 네트워크 entity이다.
프록시 서버는 자기만의 디스크 저장장치를 갖고 있고 가장 최근에 요청받은 object의 복사본도 저장하고 있다.

위 그림을 보면서 과정을 살펴보겠다.

1) 사용자의 브라우저는 모든 HTTP 요청이 먼저 웹 캐시로 전달되도록 구성할 수 있다. RFC 7234
2) 브라우저를 설정하면 각각의 브라우는 웹 캐시로 HTTP 요청을 보낸다. 예를 들어 http://www.someschool.edu/campus.gif 라는 object를 요청했다고 하자.

3) 브라우저가 웹 캐 시와 TCP 연결을 설정하고 해당 object에 대해 HTTP 요청을 웹 캐시에 전송한다.
4) 웹 캐시는 요청한 object의 복사본이 로컬로 저장되어 있는지 살펴본다. 있다면 해당 복사본을 응답 메시지로 전달한다.
5) 없다면 웹 캐시는 원래 서버와의 TCP 연결을 설정하고 똑같은 object에 대한 요청 메시지를 보낸다. 원래 서버는 해당 요청에 대한 object를 응답 메시지로 전달한다.
6) 웹 캐시가 그걸 받았다면 웹 캐시의 로컬 저장소에 복사본으로 저장하고 브라우저에게 응답 메시지를 보낸다.

여기서 주목할 점은 웹 캐시가 서버와 클라이언트의 역할을 동시에 수행한다는 점이다.

보통 웹 캐시는 ISP(Internet Service Provider)에 의해서 설치된다.
ex) 대학교 ⇒ 웹 캐시를 설치해서 대학교의 모든 브라우저가 해당 웹 캐시에 데이터를 전송하도록 설정할 수 있음

웹 캐시는 2가지 이유로 인터넷상에서 배포되었다.

1. 웹 캐시는 client의 요청에 대해 응답 시간을 줄일 수 있다. 특히 client와 원래 서버 간의 대역폭이 client와 웹 캐시 간의 대역폭보다 작을 경우 더욱 그렇다.

만약에 client와 웹 캐시가 빠른 속도로 연결되어 있고 웹 캐시가 요청받은 object를 갖고 있다면
당연히 원래 서버에 요청했을 때 보다 더 빨리 요청받은 object에 대해 응답을 줄 수 있는 거다.

2. 앞서 얘기한 대학교 처럼 웹 캐시는 기관 또는 단체의 인터넷 액세스 링크에서 트래픽을 상당히 줄일 수 있다.

트래픽을 줄임으로써 기관(ex. 대학, 회사)들은 대역폭을 빠르게 늘릴 필요가 없어져서 비용을 줄일 수 있게 된다. 뿐만 아니라 전체적인 인터넷의 웹 트래픽을 감소시키기 때문에 모든 응용프로그램에 대한 성능을 향상시킬 수 있다.

캐시의 장점을 좀 더 제대로 이해하기 위해 아래 그림을 통해서 살펴보자.

아래 그림은 2개의 네트워크를 보여준다. (공공 네트워크와 연구용 네트워크)
연구용 네트워크는 고속 LAN을 사용해서 구축되어 있고 연구소 네트워크의 라우터와 인터넷의 라우터는 15 Mbps 속도로 연결되어 있다.
Origin 서버들은 인터넷과 접속되어 있지만 전 세계에 위치하고 있다.

가정

• 평균적인 object의 크기가 1Mbits라고 한다
• 연구 네트워크에서 origin server로 전송되는 평균 요청은 1초당 15개의 요청이 전송된다고 하자
• HTTP 요청 메시지가 너무 작아서 별다른 부하를 발생시키지 않는다.
• 인터넷 부분의 라우터가 HTTP 요청을 전달하고 이에 대한 응답을 받는데 걸리는 시간은 평균 2초가 소요된다고 하자. 이를 Internet delay라고 부르겠다.

전체 응답 시간(object에 대해 browser가 요청하고 나서 이에 대한 응답을 받을 때 까지 걸린 시간)은 LAN delay + access delay(라우터 간의 delay) + Internet delay이다.

간단한 계산을 해보자.

traffic intensity

1) a = 패킷이 큐에 도착하는 평균 속도 (a는 packets/sec의 단위를 뜻함).
2) R = 전송 속도 (단위는 bits/초, 큐에서 나와서 push 되는 속도)
3) 단순함을 위해 모든 패킷은 L 비트로 이뤄져 있다고 하자.

traffic intensity = La/R

traffic intensity > 1 ==> 비트가 큐에 도착하는 평균 속도가 비트가 큐에서 전송되는 속도보다 크다는 것을 의미 (큐잉 딜레이 발생)

• 연구소에서 구축한 LAN에서 계산되는 traffic intensity (위 그림의 동그라미와 네모 사이)
  • (15 requests/sec) * (1 Mbits/request) / 100 Mbps = 0.15
  • 쉽게 말하면 연구소 컴퓨터 ⇒ 네모 라우터 에서는 1초당 15개의 요청이 전송된다.
  • 네모 라우터 ⇒ 동그라미 라우터 로 전송되는 속도는 100Mbps 이다.
  • 요청 하나당 1 Mbits를 갖는다고 할 때 traffic intensity 값이 0.15가 된다.
  • 0.15라는 값은 무시해도될 정도로 아주 작은 값이다.
• access link에서 계산되는 traffic intensity
  • (15 requests/sec) * (1 Mbits/request) / 15 Mbps = 1
  • 쉽게 말하면 연구소 컴퓨터 ⇒ 네모 라우터 에서는 1초당 15개의 요청이 전송된다.
  • 네모 라우터 ⇒ 동그라미 라우터 로 전송되는 속도는 15Mbps 이다.
  • 요청 하나당 1 Mbits를 갖는다고 할 때 traffic intensity 값이 1이 된다.
  • 1이라는 값은 굉장히 큰 값이고 별도의 제한이 없다면 이 값은 계속 커질 것이다.

따라서, 요청(request)을 만족시킬 수 있는 평균 응답 시간은 몇 분 이상이 될 것이며 이는 사용자들이 받아들일 수 없을 것이다.
반드시 조치가 필요하다.

1번째 조치. 15Mbps -> 100Mbps로 속도 증가. / 비용이 많이 든다는 단점이 존재

2번째 조치. Web cache를 설치하는 방법. 아래 그림과 같이 보자.

• 보통 cache를 통해 충족된 request의 비율 (Hit rates)는 0.2 ~ 0.7
  

  

hit rates가 0.4라고 하자.
그러면, client와 web cache는 똑같은 LAN으로 연결되어 있기 때문에 40%의 요청들은 web cache를 통해 성공적으로 요청을 수행해서 응답받고 60%의 요청들은 origin server에 의해 요청을 수행해서 응답받아야 한다.

60%의 요청만 남으면서 access link에서의 traffic intensity는 1.0에서 0.6으로 감소한다.
왜냐하면 (15 * 0.6 requests/sec) * (1 Mbits/request) / 15 Mbps = 1 * 0.6 = 0.6이 되기 때문이다.

보통 0.8보다 작은 traffic intensity는 15 Mbps 링크에서의 10 ms 만큼의 delay와 대응된다. 이는 2초 정도의 인터넷 delay와 유사하다. 그러면 다음과 같이 average delay를 계산할 수 있다.

0.4 * (0.01 seconds) + 0.6 * (2.01 seconds) > 1.2 seconds

1.2초 보다 약간 크다. 따라서, 2번째 조치는 1번째 조치보다 더 낮은 응답 시간을 제공한다. 물론 링크를 업그레이드 하기 위한 비용도 들지 않는다.

이러한 CDNs(Content Distribution Networks)을 통해서 Web Cache는 인터넷에서 더더욱 중요한 역할을 한다.
CDN 회사들은 많은 지역에 분산된 cache를 설치해서 traffic들을 localizing 한다. 이에 대한 자세한 내용은 2.6절에서 다루겠다.

The Conditional GET

Web Cache는 응답시간을 줄여줄 수 있지만 Web cache에 저장된 내용이 최신 데이터가 아닐 수 있다는 문제가 발생한다.

다행히도, HTTP는 cache가 해당 object가 최신 상태인지 확인하는 메커니즘을 갖고 있다. 이러한 메커니즘을 conditional GETRFC 7232이라고 한다.

HTTP 요청 메시지는 아래의 조건을 만족한다면 conditional GET 메시지이다.

1) GET 메서드를 사용하는 요청 메시지
2) If-Modified-Since: 헤더 라인을 포함한 요청 메시지

ex) 브라우저를 대표해서 proxy cache가 Web server에게 아래와 같은 request message를 전송했다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com

Web server에 이에 대한 response message을 아래와 같이 전송했다.

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)

proxy cache는 해당 object를 앞서 요청했던 browser에 전달하면서 local하게 캐싱한다. 여기서 cache가 last-modified date를 object와 함께 저장했다는 점이 중요하다.

1주일 후... 다른 브라우저가 cache를 통해 똑같은 object를 요청했고 해당 object는 여전히 cache에 저장되어 있다.
해당 object는 지난주에 수정되었기 때문에 cache는 conditional GET을 이용해서 최신 상태인지 체크한다.
이때 cache는 다음과 같이 전송한다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

여기서 If-modified-since 헤더 라인의 값이 Last-Modified 값과 동일하다는 걸 알 수 있다.
이와 같이 conditional GET은 서버에게 object가 지정한 날짜 이후에 변경되었을 경우에만 업데이트된 object를 전송하도록 요청하는 것이다.

object가 Wed, 9 Sep 2015 09:23:24 이후에 변경되지 않았다고 해보자. 그러면 web server는 아래와 같은 response message를 전송한다.

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)

conditional GET에 대한 응답 메시지에는 object가 변경되지 않았으니까 굳이 해당 요청에 대한 object를 반환할 필요가 없다.
이미 cache에 있는 데이터가 최신 데이터이기 때문이다. 그러면서 304 Not Modified라는 응답 메시지를 전송한다.

6. HTTP/2 - 필요하게 되면 별도로 정리 RFC 7540