컴퓨터 네트워크/응용계층

HTTP의 특성

iOS Developer 2025. 1. 4. 14:57

HTTP의 특성

HTTP(Hypertext Transfer Protocol)는 애플리케이션 계층(Application Layer)에서 작동하며, 클라이언트와 서버 간에 하이퍼텍스트(HTML 등)를 포함한 다양한 자원을 주고받기 위해 설계된 프로토콜이다. 이 프로토콜은 각종 웹 서비스와 API 통신의 핵심 기술로, 신뢰할 수 있는 통신을 위해 전송 계층의 TCP(Transmission Control Protocol)를 기반으로 동작한다.

본 문서에서는 HTTP가 가진 대표적인 네 가지 특성에 대해 상세하게 살펴본다. 각각의 특성은 서로 연관되어 있으며, 조합되어 웹 환경에서 높은 확장성, 견고성, 그리고 유연성을 제공한다.

참고

  • HTTP 공식 문서: RFC 9110
  • 이미지 자료: 《혼자 공부하는 컴퓨터 네트워크》

1. 요청-응답 기반 프로토콜

HTTP는 클라이언트-서버 구조에서 동작하는 요청-응답 기반 프로토콜이다.

  • 클라이언트: 브라우저, 앱 등 요청을 전송하는 주체
  • 서버: 요청을 받아 처리 후 결과를 응답하는 주체

요청-응답 흐름

  1. 클라이언트가 서버에게 HTTP 요청 메시지 전송
    • 요청 라인 (예: GET /index.html HTTP/1.1)
    • 요청 헤더 (예: Host, User-Agent, Accept 등)
    • (선택 사항) 바디 (POST, PUT 등의 경우 전송 내용 포함)
  2. 서버가 요청을 처리
    • 요청된 자원(HTML, 이미지, 데이터 등)을 확인
    • 작업 수행(데이터베이스 조회, 파일 읽기 등)
  3. 서버가 HTTP 응답 메시지 전송
    • 상태 라인 (예: HTTP/1.1 200 OK)
    • 응답 헤더 (예: Content-Type, Content-Length 등)
    • (선택 사항) 바디 (요청된 자원 데이터 또는 에러 메세지 등)

이러한 프로세스가 끝나면 하나의 요청-응답 사이클이 완결된다.

2. 미디어 독립적 프로토콜

HTTP는 전달하는 자원의 형태에 제한을 두지 않는다. HTML 문서부터 이미지, 동영상, JSON, XML, PDF 등 다양한 형식의 데이터를 전송할 수 있는 미디어 독립성을 가진다.

image

(출처: 혼자 공부하는 컴퓨터 네트워크)

미디어 타입(Media Type)

클라이언트와 서버는 데이터를 교환하기 위해 미디어 타입(Media Type)(혹은 MIME 타입)을 활용한다. 이는 웹에서 파일 확장자에 대응되는 개념으로, 데이터를 받아들이거나 보낼 때 정확한 형식을 식별하는 데 사용한다.

  • 형식: type/subtype
  • 예시:
    • text/html : HTML 문서
    • text/plain : 일반 텍스트
    • application/json : JSON 포맷
    • image/png : PNG 이미지

와일드카드(Wildcard) 사용

  • text/* : 모든 텍스트 계열
  • image/* : 모든 이미지 계열

와일드카드를 통해 서버 혹은 클라이언트가 수용할 수 있는 포맷에 대한 범위를 넓게 지정할 수 있다.

image

(출처: 혼자 공부하는 컴퓨터 네트워크)

매개변수(Parameters)

미디어 타입 뒤에는 세미콜론(;)을 붙여 인코딩이나 압축 형식 등 세부 정보를 추가로 명시할 수 있다.

  • 형식: type/subtype; parameter=value
  • 예시: text/html; charset=UTF-8

이를 통해 콘텐츠가 어떤 인코딩을 사용하고 있는지 등을 쉽게 파악할 수 있다.

image

(출처: 혼자 공부하는 컴퓨터 네트워크)

3. 스테이트리스 프로토콜

HTTP는 스테이트리스(stateless) 프로토콜이다. 즉, 서버는 이전 요청에 대한 정보를 저장하거나 클라이언트의 상태를 기억하지 않는다. 모든 요청은 독립적인 요청으로 취급된다.

image

(출처: 혼자 공부하는 컴퓨터 네트워크)

스테이트리스의 장점

  • 확장성(Scalability)
    • 서버는 클라이언트의 세부 상태를 몰라도 되므로, 부하가 많아지면 서버를 단순히 추가하여 스케일 아웃(scale-out)하기 쉽다.
  • 견고성(Robustness)
    • 특정 서버에 문제가 생기더라도, 클라이언트는 다른 서버로 손쉽게 요청을 보낼 수 있다. 한 서버에 클라이언트 상태가 종속되지 않으므로 장애 대응이 빠르다.
  • 단순성(Simplicity)
    • 서버가 불필요한 세션 정보를 저장할 필요가 없으므로 구현이 단순해진다.

image

(출처: 혼자 공부하는 컴퓨터 네트워크)

상태 유지가 필요한 경우

실제 서비스에서는 로그인을 유지하거나 장바구니를 관리하는 등 사용자 상태를 추적해야 하는 상황이 많다. 이를 위해 쿠키(Cookie), 세션(Session), 토큰(Token) 등의 기법을 사용한다.

  • 쿠키: 클라이언트 로컬에 상태 정보를 저장
  • 세션: 서버가 상태 정보를 추적하되, 세션 식별자는 쿠키로 관리
  • 토큰(JWT): 클라이언트가 인증 정보를 포함한 토큰을 보관해 매 요청 시 제출

HTTP 자체는 스테이트리스이지만, 이러한 추가적인 기술을 조합해 상태를 유지하는 효과를 만들어낸다.

image

(출처: 혼자 공부하는 컴퓨터 네트워크)

4. 지속 연결 프로토콜

초기의 HTTP(HTTP/1.0 이하)에서는 비지속 연결(Non-Persistent Connection) 방식을 사용했다. 이는 한 번의 요청-응답이 끝나면 TCP 연결을 끊고, 새로운 요청마다 다시 연결을 맺어야 하는 방식이다.

비지속 연결의 문제점

  • 연결 오버헤드: 매 요청마다 3-way-handshake로 TCP 연결을 새로 맺어야 하므로 비효율적
  • 지연 증가: 요청이 많은 웹 페이지일수록 지연(Latency)이 커짐

지속 연결(Keep-Alive)

현재 널리 쓰이는 HTTP/1.1 이상에서는 한 번 TCP 연결을 맺은 뒤, 여러 요청-응답을 연속적으로 처리할 수 있는 지속 연결(Persistent Connection)(킵 얼라이브) 방식을 기본적으로 지원한다.

image

(출처: 혼자 공부하는 컴퓨터 네트워크)

장점

  1. 성능 향상: 한 번 연결을 맺은 후, 여러 요청-응답을 재사용하므로 네트워크 오버헤드 감소
  2. 빠른 전송: 연결 재수립에 필요한 지연 없이 곧바로 요청 가능
  3. HTTP/2와 HTTP/3: 더 나아가 다중화(Multiplexing)와 헤더 압축 등 추가 기능으로 성능이 더욱 개선됨

마무리

HTTP는 단순한 텍스트 기반 프로토콜이지만, 위에서 살펴본 것처럼 요청-응답 기반, 미디어 독립적, 스테이트리스, 지속 연결이라는 특성을 통해 대규모의 분산 웹 환경에서 높은 유연성과 확장성, 견고성을 보장한다. 이러한 특성들은 오늘날의 수많은 웹, 모바일, API 서비스들이 안정적으로 작동할 수 있도록 하는 근간이 된다.