kimyenac
techblog
cs
HTTP 그리고 HTTPS
2026-04-02

HTTP

HTTP 는 기본적으로 상태없는 (stateless) 요청/응답 프로토콜 입니다.

Client → Request → Server
Client ← Response ← Server

핵심 포인트는 연결 자체는 TCP 위에서 동작하고, HTTP 는 데이터 "형식" 만 정의한다는 점입니다.


HTTP/1.1

텍스트 기반이고 Keep-Alive 로 연결 재사용하는 게 특징인 1.1은 구조적 한계가 만든 병목으로 실무에서 체감되는 아래와 같은 문제들이 있었습니다.

  • Head-of-Line Blocking (애플리케이션 레벨) -> 느린 API 하나가 전체 성능을 잡아먹음
  • Connection Limit (브라우저는 도메인당 ~6개 연결 제한) -> 그래서 나온 게 bundle (webpack), domain sharding 등
  • 헤더 중복 전송 (Cookie: ..., User-Agent: ...) -> 요청마다 반복 (특히 모바일에서 치명적)

HTTP/2 - 연결 하나로 다 처리하자

HTTP/2의 핵심은 "TCP 연결 하나에서 병렬 처리하자" 입니다.
핵심기능으론 Multiplexing -> 요청 순서와 응답 순서가 분리됨, Header Compression (이전 헤더 재사용, 인덱스 기반 압축) -> 네트워크 비용 크게 감소, Binary Framing (텍스트에서 바이너리로) -> 파싱 비용 감소가 있습니다.

하지만 TCP HOL BLOCKING 으로 패킷 하나 유실할 경우 전체 스트림이 멈추는 문제가 있습니다.


HTTP/3 - TCP를 버리고 QUIC 으로

HTTP/3의 핵심은 "TCP가 문제면 TCP를 버리자" 입니다.

Quic 의 특징은 (UDP 기반) 스트림 독립성이여서 진짜 Multiplexing 이고, 빠른 핸드 셰이크가 가능하여 연결 지연을 감소하고, Connection Migration 으로 모바일 환경에서 큰 장점이 있습니다.




HTTPS

HTTP + TLS 조합이 HTTPS 로, 전송 데이터를 암호화 하는 게 특징입니다.

TLS 는 보안 + 신뢰 레이어로서 Confidentiality (기밀성), Integrity (무결성), Authentication (인증) 을 제공합니다.

TLS Handshake 를 개발자 관점에서 봤을 때 흐름은 아래와 같습니다.

1. ClientHello (지원 암호 목록)
2. ServerHello (암호 선택)
3. Certificate (서버 인증)
4. Key Exchange
5. Finished → 암호화 통신 시작

중요한 포인트는 공개키는 초기 인증에 쓰이고, 대칭키는 실제 데이터 통신으로 사용함으로 성능 + 보안 균형을 맞췄습니다. 또한 TLS 1.3 개선으로 handshake RTT 가 감소하고, 불필요한 알고리즘이 제거되었습니다.




마무리

HTTP 의 진화는 단순히 버전 업이 아니라 네트워크 병목을 제거하는 과정이였습니다.
정리하면, HTTP/1.1 은 연결 기반 병목, HTTP/2 는 TCP 한계 노출, HTTP/3 는 전송 계층까지 재설계, TLS -> 보안을 기본값으로.





Reference