HTTP란?

본 내용은 "HTTP 완벽 가이드" 내용을 참고하여 기록한 정리본입니다.

 

• 게시할 내용
  • 리소스란 무엇인가?
  • 리소스는 어디서 오는가?
  • 웹 트랜잭션의 동작 원리
  • HTTP 메시지의 기본 형식
  • HTTP 기저의 TCP 네트워크 전송
  • 여러 종류의 HTTP 프로토콜
  • HTTP 버전 종류
  • 웹의 구성요소

HTTP란?

HTTP는 신뢰성 있는 데이터 전송을 위해 설계된 프로토콜이다. 데이터의 파괴, 중복, 왜곡을 방지하는 여러 메커니즘이 내재되어 있어, 웹 상에서 정보가 안정적으로 주고받을 수 있도록 한다.

웹 클라이언트와 서버

• 웹 클라이언트
  • 리소스를 요청하는 주체로, 사용자가 브라우저를 통해 웹 페이지에 접근할 때 역할을 수행한다.
• 웹 서버
  • 클라이언트의 요청에 따라 리소스를 제공하는 시스템이다.
• 웹 콘텐츠
  • 웹 서버가 제공하는 다양한 형태의 리소스를 의미한다.

리소스: 리소스는 어디서 오는가?

리소스는 웹에서 사용자에게 제공되는 데이터나 서비스를 의미하며, 그 출처와 성격에 따라 다음과 같이 분류할 수 있다.

• 리소스의 분류
  • 정적 리소스
    • 이미 형태가 정해져 있으며, 모든 사용자에게 동일하게 제공되는 데이터(예: 이미지, CSS 파일 등)를 의미한다.
  • 동적 리소스
    • 현재의 상태나 조건에 따라 출력 형식이 달라지는 데이터로, 사용자나 상황에 따라 내용이 변한다.
• 데이터 타입 분류
  • 리소스의 종류는 MIME type으로 식별할 수 있다. MDN 등에서 제공하는 자료를 참고하면 데이터 타입에 관한 정리가 명료하다.
• 리소스의 명명 방식
  • URI
    • URL (Uniform Resource Locator)
      • 위치 기반 명명 방식으로, 리소스의 실제 위치 정보를 포함한다.
    • URN (Uniform Resource Name)
      • 이름 기반 명명 방식으로, 리소스의 위치를 파악하기 위해 추가 인프라가 필요하며, 실제 사용은 제한적이다.
  • 리소스를 식별하는 기본 체계로, 두 가지 방식이 있다.

웹 트랜잭션: 동작 원리

웹 트랜잭션은 클라이언트와 서버 간의 정보 교환 과정을 설명한다. 클라이언트-서버 모델, HTTP 메소드, 상태 코드 등의 요소를 통해 요청과 응답의 흐름을 체계적으로 관리한다.

메시지: HTTP 메시지의 형식

HTTP 메시지는 아래와 같은 형식으로 구성되며, 향후 상세하게 다룰 예정이다.

• 시작줄
  • 요청 시에는 메소드, 응답 시에는 상태 코드가 기록된다.
• 헤더
  • 한 줄에 하나의 헤더가 기록되며, 빈 줄을 통해 헤더의 종료가 표시된다.
• 바디
  • 메시지의 본문으로, 요청이나 응답에 필요한 데이터를 담는다.

TCP 커넥션: HTTP 기저의 TCP 전송 방식

HTTP는 TCP 프로토콜을 기반으로 데이터를 전송한다. TCP를 사용하는 주된 이유는 다음과 같다.

• 오류 없는 데이터 전송
  • 전송 과정에서 발생할 수 있는 데이터 손실이나 오류를 방지한다.
• 순서에 맞는 데이터 전달
  • 데이터가 올바른 순서로 도착하도록 보장한다.
• 연속적인 데이터 스트림
  • 데이터의 연속성이 유지되도록 한다.

HTTP/3.0은 UDP 기반 전송 방식을 채택하나, 본 내용에서는 다루지 않는다.

브라우저의 HTTP 메시지 전송 과정

1. 웹 브라우저는 URL에서 호스트명을 추출한다.
2. 추출된 호스트명을 IP 주소로 변환하는 과정에서 DNS 쿼리가 발생한다.
3. URL에 포함된 포트 번호(존재할 경우)를 확인한다.
4. 웹 브라우저는 웹 서버와 TCP 커넥션을 수립한다.
5. 수립된 연결을 통해 HTTP 요청 메시지를 서버에 전송한다.
6. 서버는 요청에 대한 HTTP 응답 메시지를 반환한다.
7. 웹 브라우저는 수신한 응답을 바탕으로 문서를 렌더링한다.
8. TCP 연결의 종료 여부는 Keep Alive, 스트리밍 방식, Progressive 렌더링 등의 설정에 따라 달라진다.
   (HTTP/1.0 시절에는 TCP 연결이 종료되어야 브러우저가 렌더링을 시작했지만, HTTP/1.1 이후부턴 Keep-Alive가 기본값이 됨에 따라, 렌더링 설정 방식에 따라 달라지게 되었다.)

텔넷을 이용한 TCP 연결

텔넷은 TCP 연결 상태를 확인하고, 서버와 통신을 수행할 수 있는 대화형 도구이다.

텔넷을 이용해 HTTP 메시지를 전송해보자.

• 텔넷은 23번 포트를 사용하여 TCP 연결을 수행한다.
  • 하지만, 포트 번호를 직접 명시하면, 해당 포트로 TCP 연결을 수행한다.
  • 80번 HTTP 포트로 연결 후, HTTP 메시지를 직접 작성하여 웹 서버에 HTTP 요청을 보낼 수 있다.
• 텍스트 형태로 HTTP 메시지를 작성하여 서버에 전송해보자.

telnet으로 http 요청 보내기

• 대화 형식으로 응답을 받을 수 있다.

받을 수 있는 응답

• 텔넷을 통해 직접 HTTP 메시지를 보내보는 것은 프로토콜의 동작 원리를 이해하는 데 큰 도움이 되니, 직접 해보는 것을 추천한다.

프로토콜 버전: HTTP 프로토콜 종류

• HTTP/0.9
  • HTTP 프로토타입이다.
  • 심각한 디자인 결함이 다수 존재했다.
    • GET 메소드만 지원한다.
  • 간단한 구조와 최소 기능을 갖추고 있으며, 이후 HTTP/1.0으로 빠르게 대체되었다.
• HTTP/1.0
  • HTTP 헤더와 메소드 등의 기본 개념이 도입되었다.
  • 잘 정의된 명세라기보다 당시 상업적, 학술적으로 급성장하던 웹 환경에서 작동한 용례들의 모음에 가깝다.
  • 다양한 웹 애플리케이션의 요구를 충족시키는 기초를 마련했다.
• HTTP/1.0+
  • “keep-alive” 커넥션, 가상 호스팅 지원, 프록시 연결 지원 등 추가 기능이 도입되었다.
  • 공식적인 표준은 아니지만, 실질적으로 HTTP/1.0의 한계를 보완하며 사실상의 표준으로 자리잡았다.
• HTTP/1.1
  • 가장 널리 채택되어 사용되는 HTTP 버전으로, 성능과 효율성을 대폭 향상시켰다.
  • 기본적으로 지속 연결(persistent connection)을 지원하며, 파이프라이닝을 통해 요청을 병렬로 처리할 수 있다.
  • 추가적인 캐시 제어, 가상 호스팅, 그리고 더 정교한 오류 처리 메커니즘이 도입되었다.
• HTTP/2.0
  • 구글의 SPDY 프로토콜을 기반으로 개발되었으며, 이진 프로토콜로 전환하여 효율성을 높였다.
  • 단일 연결 내에서 다중 요청을 동시에 처리할 수 있는 멀티플렉싱 기능을 제공한다.
  • 헤더 압축과 서버 푸시 기능을 통해 네트워크 지연 시간을 최소화하고 전송 효율을 향상시켰다.
• HTTP/3.0
  • 기존 TCP 대신 UDP 기반으로 새로운 4계층 프로토콜인 QUIC 프로토콜을 설계 및 사용하여,
    연결 수립 및 데이터 전송의 속도를 개선하였다.
  • 지연 시간 감소와 패킷 손실에 대한 회복력을 강화하여 불안정한 네트워크 환경에서도 성능을 보장한다.
  • 현대 웹 환경에서의 빠른 연결과 안정적인 데이터 전송을 목표로 설계되었다.

웹의 구성요소

현대 웹은 단순한 클라이언트-서버 모델을 넘어 다양한 중개자와 보조 시스템이 함께 작동한다.

• 프록시
  • 클라이언트와 서버 사이에서 HTTP 통신을 중개하는 역할을 수행한다.
  • 포워드 프록시: 클라이언트 앞에 위치하여 클라이언트의 요청을 감추고, 서버의 응답을 필터링한다.
  • 리버스 프록시: 서버 앞에 위치하여 WAS를 감추고, 클라이언트의 요청을 대신 처리하며 로드 밸런싱과 보안 강화를 수행한다.
• 캐시
  • 자주 요청되는 웹 페이지나 데이터를 클라이언트에 가까운 곳에 저장하여 빠른 응답을 제공한다.
• 게이트웨이
  • 다른 애플리케이션과 연결되어 HTTP 트래픽을 다른 프로토콜로 변환하는 특수한 웹 서버이다.
• 터널
  • HTTP 통신을 단순히 전달만 하는 역할을 수행하는 특별한 프록시이다.
• 에이전트
  • 자동화된 HTTP 요청을 수행하는 준-지능적 클라이언트로, 다양한 자동화 작업에 활용된다.

 

자세한 내용은 RFC 9110, RFC9111, RFC 9112 를 참고하자.