HTTP 프로토콜의 발전과 주요 특징
HTTP(Hyper Text Transfoem Protocol)는 웹에서 데이터를 교환하기 위한 기반 프로토콜로, 애플리케이션 계층에서 동작합니다. 1990년대 초 HTTP/1.0부터 시작하여 성능과 효율성을 개선하며 HTTP/1.1, HTTP2를 겨쳐 현재 UDP 기반의 HTTP/3까지 발전해왔습니다.
HTTP/1.0의 한계
초기 버전인 HTTP/1.0은 요청 하나당 TCP 연결 하나를 새로 맺는 방식으로 동작했습니다. 이는 각 요청마다 TCP 3-way 핸드셰이크 과정이 필요하여 RTT(왕복 시간) 증가를 유발하는 비 효율성을 가졌습니다. 이를 완하하기 위해 이미지 병합(스플리팅), 코드 압축, 이미지 Base64 인코딩 등의 기법이 사용되었습니다.
HTTP/1.1의 주요 개선 사항 및 한계
HTTP/1.1은 HTTP/1.0의 단점을 개선하며 등장했으며, 현재도 널리 사용됩니다(2025년 기준 약 78% 추정).
지속적 연결 (Persistent Connections):
Connection: Keep-Alive(기본 동작)을 통해 한 번 맺은 TCP 연결을 여러 요청/응답에 재 사용하여 핸드셰이크 오버헤드를 줄였습니다.파이프라이닝 (Pipelining): 클라이언트가 이전 응답을 기다리지 않고 여러 요청을 보낼 수 있게 했으나, 서버는 요청 순서대로 응답해야 해서 먼저 보낸 요청 처리가 늦어지면 후속 응답이 모두 지연되는 HOL Blocking(Head-Of-Line Blocking) 문제가 발생하여 실제 성능 향상은 제한적이었습니다.
가상 호스팅 (Virtual Hosting):
Host헤더를 의무화하여 하나의 IP 주소에서 여러 도메인 운영을 가능하게 했습니다.메소드 확장: GET, POST 외에 PUT, DELELTE 등을 추가하여 RESTful API의 기반을 마련했습니다.
향상된 캐싱:
ETag헤더를 도입하여 콘텐츠 기반 캐시 유효성 검증을 가능하게 함으로써 캐시 효율성을 높였습니다.전송 최적화:
Transfer-Encoding: Chunked로 동적 콘텐츠 전송 및 스트리밍을 용이하게 했습니다.오류 처리:
Expect: 100-continue헤더로 큰 데이터 전송 전 서버 처리 가능 여부 확인 메커니즘을 제공했습니다.
하지만 HTTP/1.1은 여전히 HOL Blocking 문제와 압축되지 않은 무거운 헤더 구조라는 한계를 가졌습니다.
HTTP/2의 혁신과 TCP의 과제
HTTP/2는 구글의 SPDY 프로토콜을 기반으로 웹 성능 향상에 초점을 맞춰 개발되었습니다.
멀티플렉싱 (Multiplexing): 하나의 TCP 연결 내에서 여러개의 스트림(Stream)을 통해 요청과 응답을 병렬로 처리하여 HOL Blocking 문제를 에플리케이션 계층에서 해결했습니다. 특정 스트림의 패킷 손실이 다른 스트림에 영향을 미치지 않습니다.
헤더 압축 (Header Compression): HPACK 압축 방식을 사용하여 헤더 크기를 줄여 효율성을 높였습니다.
서버 푸시 (Server Push): 클라이언트 요청 없이 서버가 필요한 리소스(CSS, JS 등)을 미리 보낼 수 있게 했습니다.
보안 강화: 사실상 HTTPS 사용이 강제되어 보안이 강화되었습니다. SSL/TLS 핸드셰이크 비용도 단일 연결 사용으로 줄었습니다.
그러나 HTTP/2도 전송 계층에서는 TCP를 사용하기 때문에, TCP 패킷 손실 발생 시 해당 연결을 사용하는 모든 스트림이 지연되는 TCP 레벨의 HOL Blocking 문제는 여전히 존재했습니다.
HTTPS와 SSL/TLS
HTTPS는 HTTP 통신 내용을 SSL/TLS 프로토콜로 암호화하는 방식입니다. SSL/TLS는 CA 발급 인증서를 통한 서버 인증, 키 교환 알고리즘(예: 디피-헬만 방식)을 이용한 안전한 세션 키 생성, 해싱 알고리즘(예: SHA-256)을 통한 데이터 무결성 보장 증의 보안 기능을 제공합니다. 보안 외에도 검색 엔진 최적화(SEO) 측면에서 이점을 가집니다.
HTTP/3와 QUIC 프로토콜
HTTP/3는 TCP의 근본적인 한계를 극복하기 위해 UDP 기반의 QUIC(Quick Internet Connections) 프로토콜 위에서 동작합니다.
QUICK 프로토콜: UDP의 유연성을 바탕으로 TCP의 신뢰성 있는 기능(오류 제어, 흐름 제어 등)과 TLS 1.3 기반 보안 기능을 통일한 전송 프로토콜입니다. TCP 확장성 한계(헤더 옵션 공간 부족 등)을 극복하기 위해 개발되었습니다.
주요 장점
연결 설정 시간 단축: TCP 핸드셰이크와 TLS 핸드셰이크를 통합하여 초기 연결 설정에 필요한 RTT 감소 (1-RTT 또는 0-RTT).
TCP 레벨 HOL Blocking 해결: QUIC의 스트림은 독립적으로 처리되어 한 스트림의 패킷 손실이 다른 스트림에 영향을 주지 않습니다.
향상된 오류 복구: FEC(Forward Error Correction) 등으로 패킷 손실 복구 능력 향상.
HTTP 프로토콜은 성능과 보안을 향상시키는 방향으로 계속 진화하고 있으며, 각 버전의 특징과 장단점을 이해하는 것이 중요합니다.
핵심 포인트
HTTP는 웹 통신을 위한 애플리케이션 계층 프로토콜로, 1.0 -> 1.1 -> 2 -> 3 순서로 발전했습니다.
HTTP/1.1은 지속적 연결, 가상 호스팅 등으로 효율성을 높였으나 HOL Blocking 한계가 있었습니다.
HTTP/2는 멀티플렉싱, 헤더 압축 등으로 성능을 크게 개선했지만, TCP 레벨의 HOL Blocking 문제는 남았습니다.
HTTPS는 SSL/TLS를 통해 HTTP 통신을 암호화하여 보안을 강화합니다.
HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용하여 연결 설정 시간을 줄이고 UCP 레벨의 HOL Blocking 문제를 해결하는 등 성능을 더욱 향상시켰습니다.
출처
면접을 위한 CS 전공지식 노트