> (James F. Kurose, Keith Ross - Computer Networking- A Top Down Approach-Pearson (2020) 교과서 참고)
2.2.1 Overview of HTTP
HTTP(HyperText Transfer Protocol)은 웹의 핵심이 되는 애플리케이션 계층 프로토콜이다.
왜 HyperText일까?
HyperText: HTTP는 HyperText를 전송하기 위해 만들어진 프로토콜이이다.
HyperText는 단순한 텍스트가 아니라, 링크를 통해 다른 문서나 리소스로 쉽게 이동할 수 있는 텍스트를 말한다.
클라이언트 프로그램과 서버 프로그램은 HTTP 메시지를 서로 교환하는 방식으로 동작한다. 여기서 클라이언트는 웹 브라우저(예: 크롬, 인터넷 익스플로러)이고, 서버는 웹 서버(예: 아파치, 마이크로소프트 IIS)이다.
웹 페이지는 여러 개의 객체들로 구성된다.
객체는 HTML 파일, 이미지 파일(JPEG), 자바스크립트 파일, CSS 파일 등과 같이 하나의 URL로 접근할 수 있는 모든 파일이다.
일반적으로 웹 페이지는 하나의 기본 HTML 파일과 그 안에 참조된 여러 객체들로 이뤄져 있다. 예를 들어, 하나의 웹 페이지에 HTML 텍스트와 5개의 JPEG 이미지가 있다면, 총 6개의 객체를 가진 것이다.
HTTP는 웹 클라이언트가 서버에 웹 페이지를 요청하고 서버가 그 요청에 응답하는 방식을 정해준다.
Figure 2.6을 보면, 클라이언트(PC나 스마트폰)가 서버에 HTTP 요청을 보내고, 서버는 이에 대해 HTTP 응답을 보내는 과정이 나타나 있다.
이때, HTTP는 전송 계층 프로토콜로 TCP를 사용한다.
클라이언트와 서버 간에 TCP 연결이 먼저 이루어지고, 그 위에서 HTTP 요청과 응답이 오간다.
중요한 점은 HTTP는 '무상태 프로토콜(stateless)'이라는 것이다.
서버는 클라이언트에 대한 정보를 저장하지 않는다.
예를 들어, 클라이언트가 같은 객체를 몇 초 간격으로 두 번 요청하더라도, 서버는 이전 요청을 기억하지 않고 동일한 객체를 다시 전송한다.
HTTP에는 여러 버전이 있는데, 초기 버전인 HTTP/1.0은 1990년대에 도입되었다. 현재는 HTTP/1.1이 주로 사용되지만, 최근에는 HTTP/2도 많이 도입되고 있다.
2.2.2 Non-Persistent and Persistent Connections
많은 인터넷 애플리케이션에서 클라이언트와 서버는 오랜 기간 동안 통신하며, 클라이언트가 일련의 요청을 보내고 서버가 각 요청에 응답하는 경우가 많다. 애플리케이션과 그 사용 방식에 따라, 이 일련의 요청들은 연달아, 주기적으로, 또는 간헐적으로 이루어질 수 있다. 이러한 클라이언트-서버 상호 작용이 TCP를 통해 이루어질 때, 애플리케이션 개발자는 중요한 결정을 내려야 한다.
각 요청/응답 쌍을 별도의 TCP 연결로 보낼 것인가, 아니면 모든 요청과 해당 응답들을 동일한 TCP 연결로 보낼 것인가?
전자의 경우, 애플리케이션은 비지속 연결을 사용한다고 하며, 후자의 경우는 지속 연결을 사용한다고 한다. 이 설계 문제를 깊이 이해하기 위해, 비지속 연결과 지속 연결의 장단점을 HTTP라는 특정 애플리케이션을 통해 살펴보자. HTTP는 비지속 연결과 지속 연결 모두를 사용할 수 있다. 기본 모드에서는 지속 연결을 사용하지만, HTTP 클라이언트와 서버는 비지속 연결을 사용하도록 구성될 수 있다.
비지속 연결을 사용하는 HTTP
비지속 연결을 사용하는 경우 서버에서 클라이언트로 웹 페이지를 전송하는 과정을 단계별로 살펴보자. 여기서는 페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되어 있으며, 이 11개의 객체가 모두 동일한 서버에 있다고 가정한다. 또한, 기본 HTML 파일의 URL은
http://www.someSchool.edu/someDepartment/home.index
라고 가정해보자. 이때 일어나는 과정은 다음과 같다.
-
HTTP 클라이언트 프로세스는 서버
www.someSchool.edu의 80번 포트로 TCP 연결을 시작한다. 이 TCP 연결과 관련된 소켓이 클라이언트와 서버에 각각 생성된다. -
HTTP 클라이언트는 이 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 요청 메시지에는 경로 이름
/someDepartment/home.index가 포함된다. -
HTTP 서버 프로세스는 이 소켓을 통해 요청 메시지를 수신하고, 스토리지(RAM 또는 디스크)에서
/someDepartment/home.index객체를 가져와 HTTP 응답 메시지에 캡슐화한다. 그런 다음 이 응답 메시지를 소켓을 통해 클라이언트로 전송한다. -
HTTP 서버 프로세스는 TCP에 연결을 닫으라고 알린다.
하지만 TCP는 클라이언트가 응답 메시지를 정확히 수신했는지 확신할 때까지 실제로 연결을 종료하지 않는다.
-
HTTP 클라이언트는 응답 메시지를 수신한다. 이때 TCP 연결이 종료된다. 메시지에는 캡슐화된 객체가 HTML 파일이라는 내용이 포함되어 있다. 클라이언트는 응답 메시지에서 파일을 추출하고, HTML 파일을 분석하여 10개의 JPEG 객체에 대한 참조를 찾는다.
-
앞의 1~4단계를 참조된 각 JPEG 객체에 대해 반복한다.
위의 과정에서 브라우저는 웹 페이지를 수신하면서 이를 사용자에게 보여준다.
위 단계들은 비지속 연결을 사용한 예를 보여준다.
여기서 각 TCP 연결은 서버가 객체를 전송한 후에는 다른 객체를 위해 유지되지 않는다.
HTTP/1.0은 비지속 TCP 연결을 사용한다. 각 비지속 TCP 연결은 정확히 하나의 요청 메시지와 하나의 응답 메시지를 전송한다. 따라서 이 예에서 사용자가 웹 페이지를 요청할 때 총 11개의 TCP 연결이 생성된다.
소요 시간 계산
이제 간단한 계산을 통해 클라이언트가 기본 HTML 파일을 요청하고 전체 파일을 수신하기까지 걸리는 시간을 추정해보자. 이를 위해 우리는 RTT(Round-Trip Time)를 정의한다.
RTT는 작은 패킷이 클라이언트에서 서버로 이동한 다음 다시 클라이언트로 돌아오는 데 걸리는 시간이다.
RTT에는 패킷 전파 지연, 중간 라우터와 스위치에서의 패킷 대기 지연, 그리고 패킷 처리 지연이 포함된다. (이러한 지연에 대해서는 이전 글을 참고하자.)
사용자가 하이퍼링크를 클릭하면 그림 2.7과 같이 브라우저가 브라우저와 웹 서버 간에 TCP 연결을 시작한다. 이때 "three-way handshake"가 필요하다. 먼저 클라이언트가 작은 TCP 세그먼트를 서버로 보내고, 서버는 이를 확인하여 작은 TCP 세그먼트로 응답하며, 마지막으로 클라이언트가 서버에 다시 확인 응답을 보낸다.
이 three-way handshake의 처음 두 부분은 한 번의 RTT를 소요한다.
왜 three-way handshake라고 명명했을까:
three-way handshake는 클라이언트와 서버가 TCP 연결을 설정하는 과정에서 3번의 메시지 교환이 이루어지기 때문에 이런 이름이 붙었다.
간단히 이 3단계 과정을 살펴보면 다음과 같다.
- SYN (Synchronize) - 첫 번째 메시지: 클라이언트가 서버에 연결을 요청하는 메시지(SYN 패킷)를 보냄.
- SYN-ACK (Synchronize-Acknowledge) - 두 번째 메시지: 서버가 요청을 수락하고, 연결을 설정할 준비가 되었음을 알리는 메시지(SYN-ACK 패킷)를 클라이언트에게 응답함.
- ACK (Acknowledge) - 세 번째 메시지: 클라이언트가 서버의 응답을 확인하고, 연결이 설정되었음을 알리는 메시지(ACK 패킷)를 서버에 다시 보냄.
이처럼 연결을 설정하는 데 3번의 단계를 거치므로 3-방향 핸드셰이크(three-way handshake)라고 부르는 것이다. 이 과정을 통해 클라이언트와 서버는 서로의 존재를 확인하고 데이터 전송을 위한 안정적인 경로를 만들 수 있다.
three-way handshake의 처음 두 부분이 완료된 후, 클라이언트는 TCP 연결에 HTTP 요청 메시지와 three-way handshake의 세 번째 부분(확인 응답)을 함께 보낸다. 요청 메시지가 서버에 도착하면, 서버는 HTML 파일을 TCP 연결로 보낸다. 이 HTTP 요청/응답 과정은 또 다른 RTT를 소요한다.
따라서 대략적인 총 응답 시간은 2 RTT + 서버의 HTML 파일 전송 시간이 된다.
지속 연결을 사용하는 HTTP
비지속 연결에는 몇 가지 단점이 있다.
첫째, 각 요청된 객체마다 새로운 연결이 생성되고 유지되어야 한다.
이러한 각 연결에 대해 TCP 버퍼를 할당하고, 클라이언트와 서버 모두에서 TCP 변수를 유지해야 한다. 이는 동시에 수백 개의 다른 클라이언트로부터 요청을 처리할 수 있는 웹 서버에 상당한 부담을 줄 수 있다.
둘째, 앞에서 설명한 것처럼 각 객체는 두 번의 RTT 지연을 겪게 된다.
첫 번째 RTT는 TCP 연결을 설정하는 데, 두 번째 RTT는 객체를 요청하고 수신하는 데 사용된다.
HTTP/1.1의 지속 연결에서는 서버가 응답을 보낸 후에도 TCP 연결을 열어 둔다. 이후의 요청과 응답은 동일한 연결을 통해 이루어질 수 있다. 특히, 전체 웹 페이지(위 예에서는 기본 HTML 파일과 10개의 이미지)는 하나의 지속 TCP 연결을 통해 전송될 수 있다. 또한 동일한 서버에 있는 여러 웹 페이지도 동일한 클라이언트와의 하나의 지속 연결을 통해 전송될 수 있다. 이러한 객체에 대한 요청은 응답을 기다리지 않고 연속적으로(파이프라이닝) 이루어질 수 있다. 일반적으로 HTTP 서버는 일정 시간 동안 사용되지 않을 때(구성 가능한 타임아웃 간격) 연결을 닫는다. 서버가 연속적인 요청을 받으면 객체를 연속적으로 전송한다. HTTP의 기본 모드는 파이프라이닝을 사용하는 지속 연결이다.
