[네트워크] 애플리케이션 계층(4) - 웹과 HTTP(비지속, 지속 연결)

 

서론

[네트워크] 애플리케이션 계층(3) - 애플리케이션이 이용 가능한 트랜스포트 서비스(TCP, UDP)

이전 게시글에서 간단하게 UDP와 TCP에 대해서 살펴보고, 이들이 제공하는 신뢰적 데이터 전송, 처리율, 시간, 그리고 보안이라는 네 가지 차원의 분류에 대해서 살펴보았습니다. 

이번 게시글에서는 웹과 HTTP에 대해 알아보고, HTTP의 비지속 연결과 지속 연결에 대해 정리해 보겠습니다.

목차
1. HTTP 개요
2. 비지속 연결과 지속 연결

 

HTTP 개요

웹의 애플리케이션 계층 프로토콜인 HTTP(HyperText Transfer Protocol)는 웹의 중심입니다. HTTP는 클라이언트 프로그램과 서버 프로그램 두 가지 프로그램으로 구현됩니다. 서로 다른 종단 시스템에서 수행되는 클라이언트 프로그램과 서버 프로그램은 서로 HTTP 메시지를 교환하여 통신합니다. HTTP는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의하고 있는데, HTTP를 자세히 설명하기 전에 몇 가지 웹 전문 용어를 살펴보겠습니다.

1. 웹 페이지(web page, 문서라고도 한다)는 객체들로 구성됩니다.
2. 객체(object)는 단순히 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지, GIF 이미지, 자바 애플릿, 오디오 클립)등 입니다.
3. 대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성됩니다.
4. 예를 들어, 웹 페이지가 HTML 텍스트와 5개의 JPEG 이미지로 구성되어 있으면, 이 웹 페이지는 6개의 객체를 갖고 있는 것입니다(기본 HTML 파일과 5개의 이미지).
5. 기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조합니다.
6. 각 URL은 2개의 요소, 즉 객체를 갖고 있는 서버의 호스트 네임과 객체의 경로 이름을 갖고 있습니다.

다음 URL을 예로 한번 살펴봅시다. 

http://www.naver.com/test/picture.gif

www.naver.com은 호스트 네임이고, /test/picture.gif는 경로 이름입니다. 브라우저는 요구한 웹 페이지를 보여 주고 여러 가지 인터넷 구성 특성을 제공합니다. HTTP의 서버 측을 구현하는 웹 서버(Web server)는 URL로 각각을 지정할 수 있는 웹 객체를 갖고 있습니다. 

HTTP는 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언트로 어떻게 웹 페이지를 전송하는지를 정의합니다. (아래 이미지)

HTTP의 요청-응답 관계

사용자가 웹 페이지를 요청할 때(하이퍼 링크를 클릭할 때), 브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메시지를 서버에게 보냅니다. 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답 메시지로 응답합니다.

1. HTTP는 TCP를 전송 프로토콜로 사용합니다. 
2. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작합니다.
3. 일단 연결이 이루어지면, 브라우저와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속합니다.
4. 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고 소켓 인터페이스로부터 HTTP 응답 메시지를 받습니다.
5. 마찬가지로 HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보냅니다.

일단 클라이언트가 메시지를 소켓 인터페이스로 보내면 메시지는 TCP가 관리하게 됩니다(이전 게시글에서 TCP의 신뢰적 전송을 떠올리자). 이것은 클라이언트 프로세스가 발생시킨 모든 HTTP 요청 메시지가 궁극적으로 서버에 잘 도착한다는 것을 의미합니다. 마찬가지로 서버 프로세스가 발생시킨 각 HTTP 응답 메시지도 클라이언트에 잘 도착한다는 것을 의미합니다.

여기서 계층구조의 중요한 장점 중 하나를 볼 수 있는데 아래와 같습니다.

• HTTP는 데이터의 손실 또는 TCP가 어떻게 손실 데이터를 복구하고 네트워크 내부에서 데이터를 올바른 순서로 배열하는지 걱정할 필요가 없습니다.
• 이유는 TCP와 프로토콜 스택의 하위 계층들이 하는 일이기 때문입니다.

서버가 클라이언트에게 요청 파일을 보낼 때, 서버는 클라이언트에 관한 그 어떠한 상태 정보도 저장하지 않는다는 것에 매우 유의해야 합니다. 만약 특정 클라이언트가 몇 초 후에 같은 객체를 두 번 요청한다면, 서버는 이전에 한 일을 기억하지 않으므로 그 객체를 또 보냅니다. HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로 HTTP를 비 상태 프로토콜(stateless protocol)이라고 합니다.

 

비지속 연결과 지속 연결

많은 인터넷 애플리케이션에서 클라이언트와 서버는 클라이언트가 일련의 요구를 하고 서버가 각 요구에 대해 응답하면서 상당한 기간 동안 통신합니다. 애플리케이션과 그 애플리케이션이 어떻게 이용되는지에 따라 일련의 요구가 계속해서, 일정한 간격으로 주기적으로 혹은 간헐적으로 만들어질 수 있습니다.

클라이언트 - 서버 상호작용이 TCP상에서 발생할 때 애플리케이션 개발자는 두 가지의 중요한 결정을 할 필요가 있습니다.

1. 비지속 연결(non-persistent connection): 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내져야 하는가?
2. 지속 연결(persistent connectioon): 모든 요구와 해당하는 응답들이 같은 TCP 연결상으로 보내져야 하는가?

비록 HTTP가 디폴트 모드로 지속 연결을 사용하지만 HTTP 클라이언트와 서버는 비지속 연결을 사용하도록 설정될 수 있습니다.

 

비지속 연결 HTTP

웹 페이지를 서버에서 클라이언트로 전송하는 단계를 한번 살펴봅시다. 페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정해 봅시다. 기본 HTML 파일의 URL은 다음과 같습니다.

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

연결 수행 과정은 다음과 같습니다.

1. HTTP 클라이언트는 HTTP의 기본 포트 번호 80을 통해 www.someschool.edu  서버로 TCP 연결을 시도한다. TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 된다.
2. HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이 요청 메시지는 /someDepartment/home.index 경로 이름을 포함한다.
3. HTTP 서버는 1단계에서 설정된 연결 소켓을 통하여 요청 메시지를 받는다. 저장장치로부터 /someDepartment/home.index 객체를 추출한다. HTTP 응답 메시지에 그 객체를 캡슐화한다. 그리고 응답 메시지를 소켓을 통해 클라이언트로 보낸다.
4. HTTP 서버는 TCP에게 연결을 끊으라고 한다.(그러나 실제로 TCP 클라이언트가 응답 메시지를 올바로 받을 때까지 연결을 끊지 않는다.)
5. HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다. 클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하고 10개의 JPEG 객체에 대한 참조를 찾는다.
6. 그 이후에 참조되는 각 JPEG 객체에 대하여 처음 네 단계를 반복한다.

앞 단계에서 서버는 객체를 보낸 후에 각 TCP 연결이 끊어지므로 비지속 연결을 사용하고 있습니다(연결이 다른 객체를 위해 유지되지 않음). 각 TCP 연결은 하나의 요청 메시지와 하나의 응답 메시지만 전송합니다. 그래서 이 예에서는 사용자가 웹 페이지를 요청할 때 11개의 TCP 연결이 만들어집니다.

클라이언트가 기본 HTML 파일을 요청하고 그 파일이 클라이언트로 수신될 때까지의 시간을 측정해 봅시다. 이를 위해서 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간이 RTT(round trip time)을 정의합니다.

RTT는 패킷 전파 지연, 중간 라우터와 스위치에서의 패킷 큐잉 지연, 패킷 처리 지연 등을 포함합니다. (해당 관련 지식은 아래 게시글에서 정리했습니다.)

[네트워크] 패킷 교환 지연- 처리(proc), 큐잉(queue), 전송(trans), 전파(prop)

이제 사용자가 하이퍼링크를 클릭하면 어떤 일이 발생하는지 생각해 봅시다.

HTML 파일을 요청하고 수신하는 데 걸리는 시간 계산

위 이미지처럼 이 클릭은 브라우저가 웹 서버 사이에서 TCP 연결을 시도하게 됩니다. 이는 "3-Way Handshake"를 포함합니다.

1. 클라이언트가 작은 TCP 메시지를 서버로 보내고, 서버는 작은 메시지로 응답하고 마지막으로 클라이언트가 다시 서버에게 응답합니다.
2. 3-Way Handshake 중 처음 두 부분이 경과하면 한 RTT가 계산됩니다.
3. 핸드 셰이크의 처음 두 과정이 끝난 후에 클라이언트는 HTTP 요청 메시지를 TCP 연결로 보내면서 핸드셰이크의 세 번째 부분(응답)을 함께 보냅니다.
4. 일단 요청 메시지가 서버에 도착하면 서버는 HTML 파일을 TCP 연결로 보냅니다.
5. 이 HTTP 요청/응답은 또 하나의 RTT를 필요로 합니다.

따라서 대략 총 응답 시간은 2 RTT와 HTML 파일을 서버가 전송하는 데 걸리는 시간을 더한 것입니다.

 

지속 연결 HTTP

비지속 연결은 몇 가지 단점이 있습니다.

첫째, 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 합니다.

• TCP 버퍼가 할당되어야 하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 합니다.
• 이는 수많은 다른 클라이언트의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담을 줄 수 있습니다.

둘째, 앞서 언급한 대로 각 객체는 2 RTT를 필요로 했습니다.

• TCP 연결 설정에 1 RTT
• 객체를 요청하고 받는데 1 RTT

HTTP1.1 지속 연결에서 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지합니다.

• 같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내집니다.
• 특히, 전체 웹 페이지(앞 예에서 기본 HTML 파일과 10개 이미지)를 하나의 지속 TCP 연결을 통해 보낼 수 있습니다.
• 또한 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있습니다.
• 이들  객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있습니다.(파이프라이닝)

일반적으로 HTTP 서버는 일정 기간(타임아웃 기간) 사용되지 않으면 연결을 닫습니다. 서버가 연속된 요구를 수신할 때, 서버는 객체를 연속해서 보냅니다. HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용합니다.

최근에, HTTP/2와 같은 연결상에서 다중 요청(request)과 응답(reply)이 가능하고 이 연결 내에서 HTTP 메시지 요청과 응답의 우선순위 기법이 가능하도록 HTTP1.1을 기반으로 제안되었습니다.

 

다음글

[네트워크] 애플리케이션 계층(5) - 쿠키와 웹 캐싱