[Lecture 1] Application Layer (1) : HTTP

Client Server Communication

클라이언트와 서버가 서로 통신을 한다는 것은 결국 클라이언트의 프로세스와 서버의 프로세스가 통신을 한다는 것과 같은 말이다. 이를 IPC (Inter Process Communication) 이라 한다. 운영체제는 IPC를 위해서 Socket 인터페이스를 제공하고, 이 소켓을 통해 두 개의 서로다른 머신의 프로세스는 통신할 수 있다. 

 

다른 프로세스가 메시지를 받기 위해서는 주소를 정확히 알야아 한다. 이 주소는 상대의 소켓 인터페이스 주소로 IP 주소와 Port 번호로 이루어져 있다. https://www.naver.com 과 같은 주소를 브라우저에 치면 DNS 라는 프로토콜을 통해서 IP주소를 얻어오고, (IP주소는 사람이 읽기 어려운 32bit 숫자이다) https 라는 프로토콜은 Port 80 으로 고정을 해 두었으므로 80번 포트에 접근해 서버의 응답을 받아온다. 

HTTP 프로토콜은 내부적으로 TCP 소켓을 이용하도록 프로그래밍 되어 있어 data integrity (reliability)는 보장이 되지만 보안이나 성능적인 문제는 어플리케이션에서 처리해 주어야 한다.

 

HTTP (Hypertext Transfer Protocol)

Web 이라는 것은 HTTP의 별칭이다. 팀 버너가 발명한 것은 HTTP 프로토콜이고, 이를 우리가 현재 웹이라고 부를 뿐이다. HTTP 프로토콜을 이해하기 위해서는 이 이름에 대해서 잘 이해해야 한다. 

HTTP는 HyperText Transfer Protocol 이라는 것인데, 구체적으로 HyperText 는 텍스트 안에 어떤 링크들이 들어있는 텍스트이고, Transfer Protocol 은 이 텍스트를 전달하는 프로토콜이라는 뜻이다. 

HTTP프로토콜을 사용하면 클라이언트는 서버에 요청 (Request)를 보내게 되고, 서버는 이에 해당하는 응답(Response) 를 준다. HTTP는 Stateless 하여서 서버는 클라이언트에 대한 어떠한 정보도 기억해두지 않는다. 이렇게 응답 - 요청의 단순한 반복들로 이루어진 프로토콜이기에 매우 단순하고 빠르다는 장점이 있다. 

 

Persistent HTTP, Non-Persistent HTTP

한편 HTTP연결은 non-persistent, persistent 로 나눌 수 있는데, non-persistent 의 뜻은 서버로부터 응답을 받은 후 클라이언트와 서버 사이의 연결이 바로 끊어지는 것이고, persistent 한 것은 여러개의 객체들이 하나의 TCP 연결로 오갈수 있다는 뜻이다. Non-persistent 한 HTTP 커넥션의 경우 텍스트 안에서 참조하는 여러 다른 링크(객체)들에 대해서 그 수 만큼 계속해서 커넥션을 열고 응답을 받아야 하므로, propagation delay 가 객체의 수 만큼 발생한다. 반면 persistent 한 연결에서는 여러개의 객체들을 한꺼번에 전달했다가, 한꺼번에 받으므로 하나의 객체를 전달하는 것 만큼의 delay 가 발생하지 않아 더 빠르다. 

 

다음과 같은 조건 하에서 persistent HTTP 를 사용했을때 end-to-end delay 를 구해보자. 

* 컨트롤 메시지 (예를들어 TCP handshake, HTTP 요청 등) = K bits 

* Base HTML Object = L bits 

* N reference objects, each L bit long 

* Link bandwidth = R bps 

* Propagation delay = d seconds

 

클라이언트 - 서버 

1. 커넥션 오픈 요청 시간 : k/R + d (k 를 물의 양, R을 채널의 폭이라고 생각하면 쉽다)

2. 커넥션 오픈 응답 시간 : k/R + d

3. HTTP 요청 시간 : k/R + d 

4. HTTP 응답 시간 : L/R + d (돌아오는 base HTML 의 사이즈가 L이므로)

5. 참조 객체가 N개 이므로 (k/R + d + L/R + d) * N 

위의 1 ~ 5 전체의 시간을 다 더한게 end-to-end delay 이다. 

***하지만 참조 객체 N개에 대한 요청을 한개씩 보내지 않고 한 번에 다 보내버리면 

5 번째 단계에서의 시간은 N*k/R + d + N*L/R + d 로, propagation delay 의 시간을 절약할 수 있다. 

 

HTTP request & response format 

HTTP 요청 메시지의 형식은 request line, header line, carriage return 등으로 이루어져 있다. 

request line 에는 GET, POST, HEAD 커맨드 등을 이용해 요청하는 html 를 명시하고, 헤더라인에는 유저 에이전트와 같이 어떤 브라우저에서 요청을 보내는 것인지 등에 대한 정보를 명시한다. 

캐리지리턴은 해더 라인의 마지막 줄임을 명시하는 \r 이라는 캐릭터이다. 

구체적인 요청과 응답 형식에 대해서는 구체적으로 다루지 않겠다. 

 

Cookie : User-server state 

HTTP의 단점이자 장점인 Stateless 성격을 극복하기 위해서 등장한 것이 Cookie 이다. (다른 말로 User-server state 라고도 한다.) 서버는 클라이언트에서 요청이 왔을 때 해당 클라이언트에 쿠키 넘버가 있는지 확인한다. 만약 쿠키가 없으면(해당 사이트에 최초로 방문했을 경우) 쿠키 넘버를 서버의 DB에 저장하고, 해당 넘버를 set cookie 1678 과 같이 클라이언트에 전송한다. 클라이언트는 이후의 모든 요청에 쿠키 넘버를 명시하게 되고, 서버는 해당 정보를 활용해 클라이언트의 이전 상태를 반영하여 더욱 customizing 된 응답을 줄 수 있다. 

 

Proxy Server : Web Cache

쿠키 뿐만 아니라 Web cache (Proxy Server) 를 이용해 HTTP의 성능을 더욱 개선할 수 있다. 클라이언트는 서버에 요청을 보낼 때 곧장 서버로 가는 것이 아니라 프록시 서버를 먼저 확인한다. 만약 요청하는 객체가 프록시 서버에 존재한다면 서버까지 가지 않고 프록시 서버에서 (로컬 서버) 파일을 가져온다. 프록시를 사용하면 클라이언트 입장에서 속도 도가 빨라진다는 장점이 있다. 서버는 처리할 로드가 줄어들어서 좋다. 더 나아가 로컬에서 처리하는 것이기 때문에 나가는 트래픽이 줄어들어 인터넷 회선 사용료도 줄어든다는 장점이 있다. 하지만 여느 캐시가 그렇듯 Cache coherence 문제를 극복해야 하는 과제가 남는다. 

 

---

DNS(Domain Name System) 서버의 필요성 

호스트의 이름은 가변 길이의 알파뉴메릭 문자로 구성되어 있으므로 라우터가 처리하는 데 어려움이 있다. 이에 4byte로 길이가 고정된 IP 주소로 호스트 이름을 변환해주는 디렉터리 서비스가 필요하다. 이 서비스는 인터넷 DNS가 제공한다. 

 

DNS 서버 계층구조

DNS 는 (1) DNS 서버들의 계층구조로 구현된 분산 데이터베이스이고, (2) 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜이다. DNS 프로토콜은 UDP상에서 수행되고, 포트 번호 53을 이용한다. 

 

DNS 로 IP주소를 찾는 과정

DNS는 다른 애플리케이션 프로토콜들이 HTTP, SMTP, FTP등 사용자가 제공한 호스트 네임을 IP주소로 변환하기 위해 주로 이용한다. 예를 들어 어떤 사용자의 호스트에서 수행되는 브라우저(HTTP 클라이언트)가 URL www.naver.com/index.html 을 요청하면 이 주소에 해당하는 IP주소를 DNS 를 통해 얻어낸다. 이는 다음과 같은 단계에 걸쳐 수행된다. 

1. 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다. 

2. 브라우저는 URL로부터 호스트네임 (www.naver.com) 을 추출하고, 그 호스트 네임을 DNS 애플리케이션의 클라이언트 측에 넘긴다. 

3. DNS 클라이언트는 DNS서버로 호스트네임을 포함하는 질의를 보낸다. 

4. DNS 클라이언트는 호스트 네임에 대한 IP주소를 가진 응답을 받게 된다. 

5. 브라우저가 DNS로부터 IP주소를 받으면, 브라우저는 그 IP주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP연결을 초기화한다. 

 

---

프록시 서버에서 수정된 내용을 확인하는 방법 : 조건부 GET

 

조건부 GET 

HTTP 요청 메시지가 GET 방식을 사용하고, If-modified-since: 헤더 라인을 포함하고 있다면, 그것이 조건부 GET메시지이다.

 

1. 브라우저의 요청을 대신해 프록시 캐시는 요청 메시지를 웹서버로 보낸다. 

```

GET /fruit/kiwi.gif HTTP/1.1

Host : www.exotiquecuisine.com  

```

 

2. 웹 서버는 캐시에게 객체를 가진 응답 메시지를 보낸다 

```

HTTP/1.1 200 OK

Date : Sat, 8 Oct 2011 15:39:29 

Server : Apache/1.3.0 (Unix)

Last-Modified : Wed, 7 Sep 2011 09:23:24

Content-Type : image/gif

...

```

캐시는 요청하는 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다. 중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다는 것이다. 

 

3. 일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어 있다. 브라우저는 조건부 GET으로 갱신 조사를 수행한다. 

```

GET /fruit/kiwi.gif HTTP/1.1

Host : www.exotiquecuisine.com 

If-modified-since : Wed, 7 Sep 2011 09:23:24

```

Last-Modified 날짜와 If-modified-since 의 날짜가 정확히 일치한다. 이 조건부 GET은 서버에게 그 객체가 명시된 날짜 이후 수정된 경우에만 그 객체를 보낼 것을 말하고 있다. 만약 변경되지 않았다면 서버는 클라이언트에게 다음과 같은 응답을 보낸다. 

 

```

HTTP/1.1 304 Not Modified

Date : Sat, ...

Server : Apache/1.3.0 (Unix)

(Empty Body)

```

 

***Web cache (프록시 서버)는 보통 ISP(Internet Service Provider)가 구입하고 설치한다. 예를 들어, 대학교 캠퍼스 네트워크에 웹 캐시를 설치하고 모든 캠퍼스의 브라우저가 이 캐시로 요청을 보내도록 설정한다. 

 

 

 

 

참고: 한양대학교 이석복 교수님 KOCW 강의 영상