HTTP 완벽 가이드: 웹의 핵심 프로토콜, 알아야 할 모든 것

이 글에서는 월드 와이드 웹(World Wide Web)이 근본적으로 어떻게 작동하는지 차근차근 살펴보겠습니다.

그 핵심 기술이 바로 HTTP(Hypertext Transfer Protocol, 하이퍼텍스트 전송 프로토콜)입니다. 우리가 웹을 탐색할 때 사용하는 통신 프로토콜이 바로 이것입니다.

HTTP의 기본 동작 원리

웹사이트에 접속하면 브라우저는 서버에 HTTP 요청(request)을 보냅니다. 그러면 서버는 이미지, 동영상 또는 웹 페이지의 HTML 같은 리소스로 응답(response)하고, 브라우저는 그 결과를 화면에 표시해 줍니다.

이것이 HTTP의 메시지 기반 모델입니다. 모든 HTTP 상호작용은 요청과 응답으로 이루어집니다.

중요한 특징은 HTTP가 상태를 저장하지 않는(stateless) 프로토콜이라는 점입니다.

'Stateless'란 모든 요청이 서로 독립적이라는 의미입니다. 따라서 브라우저가 보내는 각 요청은 서버가 요청을 처리하는 데 필요한 충분한 정보를 스스로 담고 있어야 합니다. 즉, HTTP의 각 트랜잭션은 다른 트랜잭션과 별개로 처리됩니다.

URL(Uniform Resource Locator)이란?

URL은 아마도 웹에서 가장 널리 알려진 개념이자, 가장 중요하고 유용한 개념 중 하나일 것입니다. URL은 웹에서 리소스를 식별하기 위해 사용되는 '웹 주소'입니다.

웹의 개념 자체가 리소스를 중심으로 구성되어 있습니다. 초창기 웹은 텍스트/HTML 파일, 문서, 이미지 등을 공유하는 플랫폼이었으며, 따라서 웹을 하나의 거대한 리소스 모음으로 볼 수 있습니다.

URL 구조 예시

URL의 구성 요소

프로토콜(Protocol): 대부분 HTTP(또는 보안 버전인 HTTPS)가 사용됩니다. 그 외 주요 프로토콜로는 클라이언트와 서버 간 파일 전송에 사용되는 FTP(File Transfer Protocol), 이메일 전송 표준인 SMTP(Simple Mail Transfer Protocol)가 있습니다.
도메인(Domain): 리소스가 위치한 IP 주소를 식별하기 위한 이름입니다.
경로(Path): 서버 내 리소스의 위치를 지정합니다. 여러분이 이 글을 읽고 있는 기기에서 파일 위치를 나타내는 방식과 같은 논리입니다(예: /search/cars/VWBeetle.pdf 또는 C:/my cars/VWBeetle.pdf).
파라미터(Parameters): 서버에서 리소스를 식별하거나 필터링하는 데 사용되는 추가 데이터입니다.

참고: HTTP 관련 자료를 찾아보다 보면 URI(Uniform Resource Identifier)라는 용어를 만날 수 있습니다. URI는 때때로 URL 대신 쓰이지만, 대부분 공식 사양 문서나 전문적인 맥락에서 사용됩니다.

HTTP 요청(Request)

HTTP에서 모든 요청에는 URL 주소가 반드시 포함되며, 추가적으로 메서드(method)가 필요합니다. 네 가지 주요 HTTP 메서드는 GET, PUT, POST, DELETE이며, 각각 읽기(read), 업데이트(update), 생성(create), 삭제(delete) 작업과 직접 대응됩니다. 메서드에 대한 자세한 내용은 뒤에서 다루겠습니다.

모든 HTTP 메시지는 하나 이상의 헤더(header)와 선택적인 메시지 본문(body)으로 구성됩니다. 본문에는 요청과 함께 전송되거나 응답과 함께 수신되는 데이터가 담깁니다.

모든 HTTP 요청의 첫 번째 부분에는 세 가지 항목이 들어갑니다.

예시:

GET /adds/search-result?item=vw+beetle HTTP/1.1

URL에 '?' 기호가 있으면 쿼리(query)가 포함되었다는 뜻이며, 요청된 리소스의 파라미터를 전송한다는 의미입니다.

첫 번째 부분: 사용되는 HTTP 메서드입니다. 가장 많이 쓰이는 것은 GET 메서드로, 웹 서버에서 리소스를 가져옵니다. GET은 메시지 본문이 없으므로 헤더 뒤에 추가 데이터가 필요 없습니다.
두 번째 부분: 요청되는 URL입니다.
세 번째 부분: 사용 중인 HTTP 버전입니다. 대부분의 브라우저에서 1.1이 일반적이지만, 최근에는 2.0이 빠르게 확산되고 있습니다.

HTTP 요청에는 이 외에도 흥미로운 요소들이 있습니다:

Referer 헤더: 요청이 발생한 출처 URL을 알려줍니다.
User-Agent 헤더: 요청을 생성한 브라우저에 대한 추가 정보를 제공합니다.
Host 헤더: 호스트 이름을 고유하게 식별합니다. 하나의 서버에 여러 웹 페이지가 호스팅될 때 반드시 필요합니다.
Cookie 헤더: 클라이언트에 추가 파라미터를 전달합니다.

HTTP 응답(Response)

HTTP 요청과 마찬가지로, HTTP 응답 역시 세 가지 항목으로 구성됩니다.

예시:

HTTP/1.1 200 OK

첫 번째 부분: 사용 중인 HTTP 버전입니다.
두 번째 부분: 요청 결과를 나타내는 숫자 코드(상태 코드)입니다.
세 번째 부분: 두 번째 부분의 코드에 대한 텍스트 설명입니다.

HTTP 응답에서 눈여겨볼 요소들:

Server 헤더: 사용 중인 웹 서버 소프트웨어에 대한 정보입니다.
Set-Cookie 헤더: 브라우저에 쿠키를 발급합니다.
메시지 본문: HTTP 응답에는 메시지 본문이 포함되는 것이 일반적입니다.
Content-Length 헤더: 메시지 본문의 크기를 바이트 단위로 알려줍니다.

HTTP 메서드 종류

가장 많이 쓰이는 메서드는 GET과 POST지만, 그 외에도 여러 가지가 있습니다.

GET: 지정된 리소스에서 데이터를 요청합니다. 데이터를 어떤 방식으로도 수정하지 않으며, 리소스의 상태를 변경하지 않습니다.
POST: 서버에 데이터를 전송하여 새로운 리소스를 생성할 때 사용합니다.
PUT: 요청 본문의 내용을 사용해 서버의 기존 리소스를 업데이트합니다. 무엇인가를 '편집'하는 방식이라고 생각하면 됩니다.
HEAD: GET과 같은 방식으로 사용하지만, 응답에 본문이 포함되지 않고 GET을 사용했을 때와 동일한 헤더만 반환된다는 차이점이 있습니다. GET 요청 전에 리소스의 존재 여부를 확인할 때 유용합니다.
TRACE: 진단 목적으로 사용합니다. 응답 본문에 요청 메시지의 정확한 내용이 그대로 담겨 반환됩니다.
OPTIONS: 대상 리소스에 대해 사용 가능한 통신 옵션(HTTP 메서드)을 설명받을 때 사용합니다.
PATCH: 리소스에 부분적인 수정을 적용할 때 사용합니다.
DELETE: 지정된 리소스를 삭제할 때 사용합니다.

REST 아키텍처 스타일

REST(Representational State Transfer)는 요청과 응답이 시스템 리소스의 현재 상태를 표현(representation)하는 형태로 담고 있는 아키텍처 스타일입니다.

일반적인 방식:

https://carapp.com/search?make=vw&model=beetle

REST 스타일:

https://carapp.com/search/vw/beetle

REST에 대해 더 궁금하다면 관련 자료를 참고해 보시기 바랍니다.

HTTP 헤더

요청/응답 구조를 이루는 세 가지 주요 구성 요소는 다음과 같습니다.

첫 번째 줄(First line)
헤더(Headers)
본문(Body/Content)

앞에서 요청과 응답의 첫 번째 줄과 본문의 기능을 살펴보았으니, 이제 HTTP 헤더에 대해 알아보겠습니다.

HTTP 헤더는 첫 번째 줄 다음에 추가되며, 콜론(:)으로 구분된 이름:값(name:value) 쌍으로 정의됩니다. 헤더는 요청이나 응답과 함께 추가 파라미터를 전송하는 데 사용됩니다.

헤더는 용도에 따라 크게 4가지 범주로 분류됩니다.

General 헤더: 요청과 응답 양쪽 모두에서 사용될 수 있으며, 교환되는 데이터와 무관한 헤더입니다.
Request 헤더: 요청되는 데이터의 파라미터 또는 요청을 보내는 클라이언트에 대한 중요한 정보를 정의합니다.
Response 헤더: 수신되는 응답에 대한 정보를 담고 있습니다.
Entity 헤더: 메시지 본문을 구성하는 콘텐츠를 설명합니다.

헤더의 종류

HTTP 상태 코드

웹을 탐색하다 보면 "404 오류: 페이지를 찾을 수 없음" 또는 "500 오류: 서버가 응답하지 않음" 같은 페이지를 본 적이 있을 것입니다.

이것이 바로 HTTP 상태 코드입니다. 모든 HTTP 응답 메시지는 첫 번째 줄에 반드시 상태 코드를 포함하여 요청의 결과를 알려줍니다.

상태 코드는 첫 번째 숫자를 기준으로 다섯 그룹으로 분류됩니다.

1xx: 정보성 응답(Informational)
2xx: 요청 성공(Successful)
3xx: 클라이언트가 다른 리소스로 리디렉션됨(Redirection)
4xx: 요청에 오류가 있음(Client Error)
5xx: 서버가 요청을 처리하는 중 오류 발생(Server Error)

HTTPS(Hypertext Transfer Protocol Secure)

HTTPS는 HTTP 프로토콜의 보안 버전으로, 브라우저(클라이언트)와 웹사이트(서버) 간의 암호화된 통신을 제공합니다.

HTTPS에서는 통신 프로토콜이 TLS(Transport Layer Security) 또는 SSL(Secure Sockets Layer)을 사용해 암호화됩니다. 따라서 이 프로토콜은 'HTTP over TLS' 또는 'HTTP over SSL'이라고도 불립니다.

TLS와 SSL은 모두 비대칭 암호화 시스템을 사용합니다. 비대칭 암호화는 공개 키(암호화 키)와 개인 키(복호화 키)를 사용해 메시지를 암호화합니다.

누구나 공개 키로 메시지를 암호화할 수 있지만, 개인 키는 비밀로 유지되므로 의도된 수신자만 메시지를 복호화할 수 있습니다.

비대칭 암호화 시스템 예시

SSL/TLS 핸드셰이크

HTTPS 연결을 요청하면 해당 웹사이트는 브라우저에 SSL 인증서를 전송합니다. 브라우저와 웹사이트가 통신을 시작하는 이 과정을 'SSL/TLS 핸드셰이크'라고 부릅니다.

핸드셰이크는 브라우저와 웹사이트가 서로를 검증하고 SSL/TLS 터널을 통해 통신을 시작하는 일련의 단계로 이루어집니다.

HTTPS 연결에서 신뢰할 수 있는 보안 터널이 사용되면 브라우저 주소창에 초록색 자물쇠 아이콘이 표시되는 것을 보셨을 겁니다.

HTTPS의 장점

HTTPS의 주요 장점은 다음과 같습니다.

신용카드 번호 등 고객의 민감한 정보가 암호화되어 가로채기 어렵습니다.
방문자는 해당 사이트가 실제 등록된 사업체이며 도메인 소유권이 있는지 확인할 수 있습니다.
고객들은 HTTPS가 적용되지 않은 사이트를 신뢰하지 않는 경향이 있으므로, HTTPS를 사용하는 사이트에서 구매 완료율이 더 높습니다.

지금까지 HTTP의 핵심 개념들을 살펴보았습니다. 이 글이 웹의 기본 동작 원리를 이해하는 데 도움이 되길 바랍니다!