HTTP

2023. 02.02 15:30 복습 시작

HTTP

웹의 애플리케이션 계층 프로토콜인 HTTP는 HyperText Transfer Protocol의 줄임말이다.

Http는 웹의 중심이며, HTTP는 요청과 응답으로 이루어진다.

Http는 Text 기반 프로토콜이다.

 

그럼 반대는 무엇일까? Binary 기반 프로토콜들이다. 

Binary 기반 프로토콜은 UDP, TCP, IP, 이더넷, FTP, telnet 등이 있다.

이 프로토콜들의 장점은 사이즈가 작다는 점이다. 단점으로는 데이터 내용을 확인하기 위해 Binary를 변환할 툴이 필요하다. 

 

Text 기반 프로토콜로는 HTTP가 있다.

장점으로는 사람이 확인을 바로 할 수 있다. 즉 변환이 필요 없다. 단점은 데이터 사이즈가 크다는 것이다.

OSI 7 계층에서 물리 계층으로 갈수록 데이터 사이즈가 작아진다. 효율적인 전송을 위해 압축할 필요가 있다고 한다. 

초기 프로토콜은 모두 Binary 기반이다.

Stateless

HTTP의 큰 특징으로는 Stateless가 있다. 한글로 직역하자면 무상태다.

즉 이전의 요청과 그 어떠한 요청과도 연관이 없는 독립적인 상태다.

자신이 이전에 파일을 전달했는지 안 했는지 모르며 데이터를 보낸 후 데이터가 loss해도 신경 쓰지 않는다.

즉 쉽게 말해 데이터를 보내면 나는 상관없다는 마인드다. 또한 이를 통해 어떠한 남아있는 정보도 없다.

그럼에도 웹 상태를 유지하기 위해 쿠키라는 기능을 이용한다.

흔히 로그인 기능을 구현할 때 쿠키를 많이 사용한다. 쿠키는 조금 있다가 알아보겠다.

비지속 연결 HTTP와 지속 연결 HTTP

많은 인터넷 애플리케이션에서 클라이언트와 서버는 클라이언트가 요구를 하고 서버가 각 요구에 대해 응답하면서 상당한 기간 동안 통신한다.

애플리케이션과 그 애플리케이션이 어떻게 이용되는지에 따라 일련의 요구가 계속해서, 일정한 간격으로 주기적으로 혹은 간헐적으로 만들어질 수 있다.

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

각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내져야 하는가?

혹은 모든 요구와 해당하는 응답들이 같은 TCP 연결상으로 보내져야 하는가?

전자의 방식의 경우 애플리케이션은 비지속 연결이라고 하고 후자 방식의 경우 지속 연결이라고 한다.

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

비지속 연결 HTTP

웹 페이지를 서버에서 클라이언트로 전송하는 단계를 살펴보자.

페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정하자.

기본 HTML 파일의 URL은 다음과 같다.

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

연결 수행 과정은 다음과 같다. (HTTP는 TCP를 베이스로 연결된다.)

 

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

앞 단계는 서버가 객체를 보낸 후에 각 TCP 연결이 끊어지므로 비지속 연결을 사용하고 있다. (연결이 다른 객체를 위해 유지되지 않는다.) 각 TCP 연결은 하나의 요청 메시지와 하나의 응답 메시지만 전송한다.

그래서 이 예에서는 사용자가 웹 페이지를 요청할 때 11개의 TCP 연결이 만들어진다.

 

이번에는 클라이언트가 기본 HTML 파일을 요청하고 그 파일이 클라이언트로 수신될 때까지의 시간을 측정해 보겠다.

이를 위해 RTT (round-trip time)을 정의했다.

즉 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 시간을 말한다. 

RTT는 패킷 전파 지연, 중간 라우터와 스위치에서의 패킷 큐잉 지연, 패킷 처리 지연 등을 포함한다.

 

이제 위 그림을 보고 사용자가 하이퍼링크를 클릭하면 어떤 일이 발생하는지 생각해보자.

먼저 클릭은 브라우저가 브라우저와 웹 서버 사이에서 TCP 연결을 시도하게 한다. 이는 "세 방향 핸드 셰이크"를 포함한다.

클라이언트가 작은 TCP 메시지를 서버로 보내고, 서버는 작은 메시지로 응답하고 마지막으로 클라이언트가 다시 서버에게 응답한다.

세 방향 핸드 셰이크 중 처음 두 부분이 경과하면 한 RTT가 계산된다.

핸드 셰이크의 처음 두 과정이 끝난 후에 클라이언트는 HTTP 요청 메시지를 TCP 연결로 보내면서 핸드 셰이크의 세 번째 부분(응답)을 함께 보낸다. 일단 요청 메시지가 서버에 도착하면 서버는 HTML 파일을 TCP 연결로 보낸다.

이 HTTP 요청/응답은 또 하나의 RTT를 필요로 한다.

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

지속 연결 HTTP

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

 

1. 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다. TCP 버퍼가 많이 할당되어야 하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다. 이는 수많은 다른 클라이언트의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담을 줄 수 있다.
2. 앞서 언급한 대로 각 객체는 2 RTT를 필요로 한다. TCP 연결 설정에 1 RTT, 객체를 요청하고 받는데 1 RTT.

 

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

같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.

특히 전체 웹페이지 (앞 예에서 기본 HTML 파일과 10개 이미지)를 하나의 지속 TCP 연결을 통해 보낼 수 있다.

또한 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있다.

이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있다. (파이프라이닝)

일반적으로 HTTP 서버는 일정 기간 (타임아웃 기간) 사용되지 않으면 연결을 닫는다.

서버가 연속된 요구를 수신할 때, 서버는 객체를 연속해서 보낸다. HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다. 

지속 연결은 1 RTT를 필요로 한다.

 

이제 정리해보겠다. 지속 연결은 TCP 커넥션을 열면 계속 재사용한다.

비 지속 연결은 객체를 요청하고 받을 때마다 TCP 커넥션을 만든다.

즉 비지속 연결은 클라이언트만큼 TCP 커넥션이 필요하다.

이는 지속 연결보다 원래 비효율적이지만 클라이언트가 많아지면 더욱 비효율적이다.

또한 비 지속 연결은 열어두고 요청을 하지 않을 시 낭비가 심하다. 왕복 시간 또한 당연히 지속 연결이 훨씬 빠르다.

지속 연결이 더 좋다.

HTTP Request

• HTTP의 요청 메시지다.
• 먼저 아스키 텍스트로 쓰여 있어 사람들이 읽을 수 있다.
• HTTP 첫 줄은 요청 라인이라고 부르고, 이후 줄 들은 헤더 라인이라고 부른다.
• 헤더 라인 아래는 공백 라인과 개체 몸체로 이루어진다.
• 개체 몸체에 우리가 전달할 데이터가 담겨있다. 몸체는 주로 POST 메서드 때 채워있고 GET 메서드 때는 비워져 있다.
• 요청 라인은 3개의 필드 즉 메서드 필드, URL 필드, HTTP 버전 필드를 가진다.
• 헤더 라인은 호스트를 명시하고 지속 연결 사용에 대한 정보를 나타내고 브라우저 타입 등 다양한 정보를 명시한다.
• Method는 GET, POST, DELETE, PUT, PATCH 등 다양한 메서드가 있다.

HTTP Response

• HTTP 응답 메시지다
• 응답 메시지는 3개의 섹션으로 구성된다. 상태 라인, 6개의 헤더 라인, 개체 몸체로 이루어진다.
• 개체 몸체는 요청 객체를 포함한다.
• 상태 라인 3개 필드, 즉 프로토콜 "버전 필드", "상태 코드", "해당 상태 메시지"를 갖는다.
• 헤더 라인들을 살펴보자.

헤더 라인

1. Connection : close : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫는 데 사용한다.
2. Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.
3. Server : 메시지가 어떤 서버에 의해 만들어졌음을 나타낸다. HTTP request 메시지의 User-agent와 유사하다.
4. Last - Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.
5. Content-Length : 송신되는 객체의 바이트 수를 나타낸다.
6. Content-Type : 개체 몸체 내부의 객체가 어떤 데이터인지 나타낸다. 예를 들어 text/html이면 HTML 텍스트인 것을 나타낸다.

Status Code

한국말로 상태 코드라고 한다. HTTP 응답 상태를 알려주는 코드다.

간단히 유명한 몇 가지만 알아보겠다.

 

• 200 - 요청이 성공되었고, 정보가 응답으로 보내졌다.
• 301 - 요청 객체가 영원히 이동되었다.
• 400 - 서버가 요청을 이해할 수 없다는 일반 오류 코드다.
• 404 - 요청 문서가 서버에 존재하지 않는다.
• 505 - 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.

Cookie 

HTTP 서버는 상태를 유지하지 않는다고 했다.

그러나 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로 웹사이트가 사용자를 확인하는 것이 바람직할 때가 있다. 즉 로그인 기능이다.

이 목적으로 HTTP는 쿠키를 사용한다. 쿠키 기술은 네 가지 요소로 구성된다.

 

• HTTP 응답 메시지 쿠키 헤더 라인.
• HTTP 요청 메시지 쿠키 헤더 라인.
• 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일.
• 웹 사이트의 백엔드 데이터 베이스를 갖고 있다.

Web Cache

웹 캐시 (프록시 서버(proxy-server)라고도 함)는 원출처의 웹 서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체이다.

웹 캐시는 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존한다.

아래 그림처럼 브라우저는 사용자의 모든 HTTP 요구가 웹 캐시에 가장 먼저 보내지도록 구성될 수 있다.

일단 브라우저가 설정되면 객체에 대한 각각의 브라우저 요청은 웹 캐시에 가장 먼저 보내진다.

예를 들어 http://www.someschool.edu/campus.gif라는 객체를 요구한다고 생각해보자.

이때 어떤 일이 발생하는지 알아보면 다음과 같다.

웹 캐시를 통한 클라이언트의 객체 요청

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다.
   만일 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
3. 만약 웹 캐시가 객체를 가지고 있지 않다면, 웹 캐시는 원출처의 서버인 www.someschool.edu로 TCP 연결을 설정한다.
   그러고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다.
   이러한 요청을 받은 후에 기점 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다.
4. 웹 캐시가 객체를 수신할 때, 객 체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을(클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP 연결을 통해) 보낸다.

캐시는 서버이면서 클라이언트라는 점을 유의해야 한다.

브라우저로부터 요구를 받고 응답을 보내는 것은 서버이고, 출처 서버에게 요구를 보내거나 응답을 받는 것이 클라이언트이다.

 

웹 캐싱은 다음과 같은 이유로 즐겨 사용되어 왔다.

1. 웹 캐시는 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다.
2. 웹 캐시는 한 기관에서 인터넷으로 접속하는 링크 상의 웹 트래픽을 대폭 줄일 수 있다.

이상으로 포스팅을 마칩니다. 감사합니다.

 

2023. 02.02 16:05 정리

 

참고자료

컴퓨터 네트워킹 하향식 접근 제 7판