HTTP(Hypertext Transfer Protocol) 알아보기 (1)

HTTP

 

HTTP(Hypertext Transfer Protocol)은 사용자와 밀접하게 맞닿아있는 프로토콜로, 현대 웹 브라우징의 기반을 이루는 중요한 역할을 한다. 

 

이 HTTP에는 중요한 네 가지 특성이 있는데 첫째, 요청과 응답을 기반으로 동작하고, 둘째, 미디어 독립적이며, 셋쩨, 상태를 유지하지않고, 넷째, 지속 연결을 지원한다. 이 네 가지 특성이 대해서 알아보자. 

 

첫째, 요청-응답 기반 프로토콜

 

HTTP는 '클라이언트-서버 구조 기반의 요청-응답 프로토콜'이다. 호스트의 대표적인 종류에는 서버와 클라이언트가 있고, 클라이언트는 서버에게 요청을 전송하며, 서버는 클라이언트의 요청에 대한 응답을 전송한다. HTTP는 이와 같이 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작한다. 그렇기에 같은 HTTP 메시지일지라도 요청 메시지와 응답 메시지는 형태가 다르다.

브라우저에서 확인 가능한 요청/응답 메시지 형태

 

둘째, 미디어 독립적 프로토콜

 

클라이언트는 HTTP 요청 메시지를 통해 서버의 자원을 요청할 수 있고, 서버는 HTTP 응답 메시지로 요청받은 자원에 대해 응답할 수 있다. 그렇다면 HTTP로는 어떠한 자원을 주고받을 수 있을까? HTTP를 정의한 공식문서(RFC 9110)에서는 다음과 같이 이야기한다. 

 

RFC 9110

the target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resouces. Most resources are idetified by a Uniform Resource Identifier (URI).

 

직역하면 'HTTP가 요청하는 대상을 자원이라고 한다. HTTP는 자원의 특성을 제한하지 않으며, 단지 자원과 상호 작용하는 데 사용할 수 있는 인터페이스를 정의할 뿐이다. 대부분의 자원은 URI로 식별된다.' 라는 뜻이다.

 

다시 말해 HTTP는 주고받을 자원의 특성은 상관하지 않고, 그저 자원을 주고 받을 수단(인터페이스)의 역할만을 수행한다. 실제로 HTTP를 통해서 HTML, JPEG, PNG, JSON, XML, PDF 파일 등 다양한 종류의 자원을 주고받을 수 있다.

 

HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입(Media Type)이라 부른다. MIME 타입(Multipurpose Internet Mail Extensions Type)이라고도 부른다. 즉, HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 독립적으로 동작이 가능한 미디어 독립적인 프로토콜이라 할 수 있다. 

 

미디어 타입은 일종의 웹 세상의 확장자와 같은 개념이다. 일반적으로 파일의 종류를 .html, .png, .json, .mp4와 같은 확장자로 나타낼 수 있듯이, HTTP를 통해 송수신하는 정보의 종류는 미디어 타입으로 나타낼 수 있다. 다음 그림은 미디어 타입의 예시다 순서대로 HTML, 텍스트, PNG 이미지 인것을 나타낸다. 

미디어 타입의 예시

 

미디어 타입은 기본적으로 슬래시를 기준으로 하는 '타입/서브타입(subtype)' 형식으로 구성된다. 타입(type)은 데이터의 유형을 나타내고, 서브타입(subtype)은 주어진 타입에 대한 세부 유형을 나타낸다. 

type/subtype

 

미디어 타입의 종류는 매우 다양하며, 필요에 따라 새로운 미디어 타입을 등록할 수도 있다. 그렇기에 모든 타입을 암기할 필요는 없고 필요할 때마다 찾아보는 것이 일반적이다. 모든 타입을 확인하고 싶다면 다음의 URL로 들어가보자. 

 

https://www.iana.org/assignments/media-types/media-types.xhtml

Media Types

타입	타입 설명	서브 타입	서브타입 설명
text	일반 텍스트 형식의 데이터	text/plain	평문 텍스트
		text/html	HTML 문서
		text/css	CSS 문서
		text/javascript	Javascript 문서
image	이미지 형식의 데이터	image/png	PNG 이미지
		image/jpeg	JPEG 이미지
		image/webp	WebP 이미지
		image/gif	GIF 이미지
video	비디오 형식의 데이터	video/mp4	MP4 비디오
		video/ogg	OGG 비디오
		video/webm	WebM 비디오
audio	오디오 형식의 데이터	audio/midi	MIDI 오디오
		audio/wav	WAV 오디오
application	바이너리 형식의 데이터	application/octet-stream	알 수 없는 바이너리 데이터를 포함한 일반적인 바이너리 데이터
		application/pdf	PDF 문서 데이터
		application/xml	XML 데이터
		application/json	JSON 데이터
		applicaiton/x-www-form-urlencoded	HTML 입력 폼 데이터 (키-값 쌍의 입력값을 URL 인코딩한 데이터)
multipart	각기 다른 미디어 타입을 가질 수 있는 여러 구성 요소로 구성된 데이터	multipart/form-data	HTML 입력 폼 데이터
		multipart/encrypted	암호화된 데이터

 

참고로, 별표(*)는 여러 미디어 타입을 통칭하기 위해 사용된다. 예를 들어 text/*는 text 타입의 모든 서브타입을 나타내고, image/*는 image 타입의 모든 서브타입을 나타낸다. 또 */*는 모든 미디어 타입을 나타낸다. 

 

또한 미디어 타입에는 부가적인 설명을 위해 선택적으로 매개변수가 포함될 수도 있다. 매개변수는 '타입/서브타입;매개변수=값'의 형식으로 표현된다, 다음을 참고하면된다.

type/subtype;parameter=value

 

예를 들어, type/html;charset=UTF-8은 미디어 타입이 HTML 문서 타입이며, HTML 문서 내용에 사용된 문자는 UTF-8로 인코딩되었음을 의미한다. 

 

셋째, 상태를 유지하지 않는 프로토콜

 

HTTP는 상태를 유지하지 않는 스테이스리스(stateless) 프로토콜이다. 이는 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미다. 그렇기 때문에 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주된다. 

 

예를 들어 클라이언트가 실수로 특정 HTTP 요청 메시지를 서버에게 여러 번 전송했다고 가정해 보자. 서버는 이 요청들을 각기 다른 요청으로 간주한다. 따라서 클라이언트는 같은 응답 메시지를 여러 번 받을 수 있다. 

같은 요청을 여러 번 보내도 서버는 각기 다른 요청이라 보고 응답한다.

 

상태를 유지하지 않는 특성은 언뜻 효율적이지 않아 보일 수 있지만, 실제로는 장점이 명확하다. HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호 작용한다. 동시에 처리해야 할 요청의 메시지 수는 수천 개가 될 수도 있고, 많게는 수백만 개가 될 수도 있다. 이러한 상황에서 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담이다. 

 

또한, 서버는 하나가 아니라 여러 대로 구성될 수도 있다. 이런 상황에서 모든 서버가 모든 클라이언트의 상태를 유지할 경우 클라이언트는 여러 서버를 통시에 이용하기가 어려워진다. 모든 서버가 모든 클라이언트의 상태 정보를 공유하는 작업은 매우 번거롭고 복잡하기 때문이다

 

HTTP가 상태를 유지하는 프로토콜이었다면 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 상호 작용할 수 있게 되어, 클라이언트가 서버에 종속될 수 있다. 이러한 상황에서 어느 한 서버에 문제가 발생하면 해당 서버에 종속된 클라이언트는 직접까지의 HTTP 통신 내역을 잃어버리는 상황이 발생할 수도 있다.

 

HTTP가 처음 만들어졌을 때부터 오늘날까지 이어지는 중요한 설계 목표는 바로 확장성(scalability)와 견고성(robustness)다. 서버는 하나가 아니라 여러 개가 있을 수도 있다고 했다. 상태를 유지하지 않고 모든 요청을 독립적인 요청으로 처리하는 것은 특정 클라이언트가 특정 서버에 종속되지 않도록 하며, 서버의 추가나 문제 발생 시 대처가 용이하도록 한다. 즉, 상태를 유지하지 않는 스테이트리스한 특성은 필요하다면 언제든 쉽게 서버를 추가할 수 있기 때문에 확장성이 높고, 서버 중 하나에 문제가 생겨도 쉽게 다른 서버로 대체가 가능하기에 견고하다. 

 

물론 HTTP가 스테이트리스 프로토콜이라 할지라도 서버가 클라이언트의 요청을 매번 처음 보는 것처럼 동작하는 것만은 아니다. 이러한 특성을 보완하기 위한 여러 방법들이 있다. (추후 공부 예정)

 

넷째, 지속 연결 프로토콜

 

HTTP는 지속해서 발전 중인 프로토콜인 만큼, 여러 버전이 있다. 오늘날 많이 사용되는 HTTP 버전인 HTTP 1.1과 HTTP 2.0이 포함된다. 기본적으로 HTTP는 TCP상에서 동작하는데, HTTP는 비연결형 프로토콜이지만, TCP는 연결형 프로토콜이다. 따라서 초기 HTTP 버전(1.0 이하)은 3-way-handshake를 통해 연결을 확립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 식으로 동작했다. 추가적인 요청-응답을 하기 위해서는 다시 TCP 연결을 수립해야 했다. 이러한 방식을 비지속 연결이라고 한다. 

 

하지만 최근 대중적으로 사용되는 HTTP 버전(HTTP 1.1 이상)은 지속 연결(persistent connection)이라는 기술을 제공한다. 다른 표현으로는 킵 얼라이브(keep alive)라고도 부른다. 이는 하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수 있는 기술이다. 지속 연결을 지원하지 않는 HTTP와 지속 연결 기능을 지원하는 최근의 HTTP의 차이는 다음 그림과 같다. 그림의 내용처럼 지속 연결 기능을 지원하는 HTTP는 매번 새롭게 연결을 수립하고 종료해야 하는 비지속 연결에 비해 더 빠르게 여러 HTTP 요청과 응답을 처리할 수 있다. 

 

정리

 

HTTP의 정의와 네 가지 특성 

1. HTTP(Hypertext Transfer Protocol)의 정의 

• 정의 : 웹 브라우저(클라이언트)와 서버가 자원을 주고받기 위해 사용하는 통신 규약.
• 오늘날 쓰이는 모든 웹 기반 통신(웹 사이트, 앱 데이터 송수신 등)의 가장 기본이 되는 프로토콜.

2. HTTP의 4가지 특성 

① 요청-응답 (Request-Response) 기반 동작

• 클라이언트가 "이거 줘."라고 요청(Request) 메시지를 보내면, 서버가 이에 맞춰 "여기 있다."하고 응답(Response) 메시지를 보내는 형태로 동작.
• 같은 HTTP 메시지라도 요청이냐 응답이냐에 따라 메시지의 형태(구조)가 달라짐.

② 미디어 독립성

• HTTP는 자원을 주고 받는 인터페이스(도구)일 뿐, 어떤 데이터(자원) 형식이든 가리지 않고 다 주고받을 수 있음.
• 미디어 타입(Media Type / MIME Type) : 주고받는 자원의 유형을 구분하기 위한 명칭으로, '타입/서브타입' 형태로 표현.
  • 종류 예시 : text/html (HTML 문서), image/png (PNG 이미지), video/mp4 (MP4 영상), application/pdf (PDF 파일).
  • 전체표시(*) : text/*는 텍스트의 모든 서브타입, */*는 모든 미디어 타입을 의미함. 
  • 매개변수 : 타입에 대한 부가설명을 위해 선택적으로 붙일 수 있음. (예: 'text/html;charset=UTF-8' > UTF-8로 인코딩된 HTML 문서라는 뜻.)

③ 상태를 저장하지 않음 (Stateless)

• 특징 : 서버가 클라이언트의 이전 연결 상태를 기억하지 않는 무상태(Stateless) 프로토콜임. 요청이 10번 들어오면 각각 독립된 10개의 요청으로 간주.
• 왜 상태를 저장하지 않는가?
  1. 서버 부담 감소 : 수천 ~ 수백만 명의 상태를 일일히 기억하려면 서버 메모리가 버티질 못함.
  2. 서버 확장성(Scalability) : 상태를 저장하지 않으니 트래픽이 몰릴 때 서버를 쉽게 추가할 수 있음. 아무 서버나 요청을 받아도 똑같이 처리 가능. 
  3. 장애 견고성(Robustness) : Stateful 프로토콜이라면 클라이언트가 특정 서버에 종속될 수 있음. 해당 서버가 고장나면 클라이언트는 이전 상태를 다 잃어버리지만, Stateless 구조에서는 다른 서버가 바로 대체할 수 있어 견고함.

④ 지속 연결 (Persistent Connection) 

• HTTP는 네트워크 연결을 위해 TCP를 사용함. 
• 과거 (비지속 연결 - HTTP/1.0 이하) : 요청을 하나 보낼 때마다 TCP 연결을 맺고(3-way-handshake), 응답을받으면 바로 연결을 종료함. 추가적인 요청이 들어오면 이를 반복하여 효율이 떨어짐. 
• 현재 (지속 연결 - HTTP/1.1 이상) : Keep-Alive 라고도 부르며, 한 번 뚫어놓은 하나의 TCP 연결 통로를 끊지 않고 유지하면서 여러 개의 요청과 응답을 연속으로 주고받을 수 있음. 구버전보다 속도가 더 빨라짐.

3. 추가로 알면 좋은 점

3.1 Stateless 한계 극복 

HTTP는 무상태(Stateless)가 장점이나, 실제 웹 사이트에서는 "로그인 상태"를 유지함. 이때 무상태성을 해치지 않으면서 로그인 상태를 식별하기 위해 실무에선 아래의 기술들을 같이 사용함.

• 쿠키(Cookie) & 세션(Session)
• JWT (Token 기반 인증)
• 배달의 민족, 인스타그램 등이 로그인 상태를 유지하는 이유가 바로 이런 기술들을 활용해서임.

3.2 HTTP 버전별 차이 요약 

• HTTP/1.1 : 지속 연결(Keep-Alive) 도입. 하지만 요청을 한 줄로 세워서 처리하느라 앞의 요청이 막히면 뒤의 요청도 늦어지는 단점이 있음. 
• HTTP/2.0 : 한 통로에서 순서 상관 없이 동시에 여러 요청/응답(멀티플렉싱)을 처리하여 속도가 빨라짐.
• HTTP/3.0 : TCP를 사용하지 않고 UDP(QUIC)라는 빠른 프로토콜 기반으로 만들어짐. 연결 속도를 극대화함. (스마트폰이 데이터<>와이파이를 왔다갔다해도 덜 끊기는 이유.)