HTTP

출처: 링크텍스트

하이퍼텍스트 전송 프로토콜

하이퍼텍스트 문서: 하이퍼링크(내부적으로 문서 간의 연결을 가진 문서)를 가진 문서

하나의 HTML 문서가 다른 여러 HTML 문서를 참조(링크)

HTTP/0.9

Get만 지원하고 헤더가 없다. 오직 HTML 파일만 전송했다.

HTTP/1.0

1996년에 등장



브라우저가 웹페이지를 요청하면 서버가 해당 페이지를 전송하는데, 각 요청마다 별도의 연결이 필요했기 때문에 그림처럼 많은 왕복이 필요했다.

3-Way Handshake

클라이언트와 서버가 TCP 연결을 만들기 위해 3번의 메시지를 주고받는 과정

SYN(Synchronize)

통신을 시작하기 위해 시퀀스 번호를 동기화하자는 신호

ACK(Acknowledge)

상대방의 데이터나 요청에 대해 정확히 받았음을 알림

• 데이터의 순서 보장

• 재전송 제어

• 중복 방지

HTTP/1.1

1999년에 등장

HTTP 1.0의 문제를 보완하였다. 모든 요청에 대해 별도의 연결을 하는 것이 아닌 지속적인 연결을 도입하여 연결을 끊기 전까지는 연결이 되도록 하였다.
-> 모든 요청 후에 닫을 필요가 없어짐
-> 여러 TCP 핸드쉐이크가 필요없음

파이프라인이 생겼기 때문에 하나의 TCP 연결을 통해 여러 요청을 보낼 수 있게 된다. 응답을 기다렸다가 요청할 필요가 없어진 것이다.

청크 전송 인코딩

더 작은 청크로 응답을 보낸다. 이를 통해 전체 응답을 기다렸다가 전송할 필요가 없어져 초기 페이지 렌더링이 빠르다.
-> 대용량 또는 동적 컨텐츠의 UX가 향상됨.

캐싱과 조건부 요청

캐싱

동일한 리소스를 다시 요청하지 않기 위해
브라우저나 프록시가 이전 응답을 저장하고 재사용하는 기술

정교한 캐시 제어를 위해 헤더를 통해 캐싱 정책을 직접 지정할 수 있게 되었다.

예를 들어 캐시 허용, 금지, 만료시간 설정 등이 있다.

HTTP 헤더
HTTP 요청이나 응답에 포함되는 메타데이터
즉, 본문(body) 이외의 추가 정보(제어 정보)**를 담는 텍스트 필드이다.

조건부 요청

클라이언트가 서버에 요청을 보낼 때
“이 리소스가 바뀌었을 경우에만 보내줘”라고 조건을 걸 수 있는 요청 방식이다.

이전에 받은 리소스를 다시 받아야 할지 말지 판단하기 위한 절차
-> 불필요한 데이터 전송을 줄임.

이들은 대역폭을 절약하고 성능을 향상 시켰다.

하지만 웹사이트들은 점점 더 크고 복잡해졌다.

파이프라인의 첫번째 요청이 지연되면 HOL블로킹(Head of line Blocking)이 발생하여 모든 요청이 지연된다. 이로 인해 파이프라인의 사용률이 감소했다.

HTTP/2

2015년에 등장

이진 프레이밍(Binary Framing)

텍스트 기반이었던 HTTP/1.1과 달리,
→ HTTP/2는 모든 메시지를 이진(binary) 형태의 프레임으로 전송

• 더 빠르고 안정적인 파싱

• 프로토콜 확장성 증가

• 중간 노드에서 처리 일관성 보장

멀티플렉싱(Multiplexing), 단일 연결 (Single TCP Connection)

하나의 TCP 연결에서 요청/응답을 동시에 병렬로 주고받을 수 있음

• 완전한 동시 처리

• 각 요청/응답은 stream ID로 식별

• HOL blocking 제거 (애플리케이션 레벨 기준)

스트림 우선순위(Stream Prioritization)

서버에 우선순위가 높은 자산을 알려주면 서버가 더 중요한 요청에 더 많은 프레임을 보낸다.

• 각 요청에 대해 중요도와 의존도(priority, dependency) 설정 가능

• 예: 이미지보다 JS/CSS를 먼저 처리

• 성능 최적화를 더 미세하게 제어 가능

서버 푸시(Server Push)

클라이언트가 요청하지 않은 리소스를 서버가 미리 전송 가능

• 클라이언트가 HTML 요청

• 서버는 HTML뿐만 아니라 그에 필요한 CSS, JS도 선제적으로 푸시

• 초기 로딩 속도 개선

헤더 압축 (HPACK)

• HTTP 헤더는 많고, 반복적이고, 커짐

• HTTP/2는 HPACK이라는 압축 방식을 사용해 헤더 크기 대폭 감소

• 성능 향상 + 네트워크 대역폭 절약

웹 앱이 더 복잡해지고 모바일 인터넷이 보편화 되면서 HTTP/2도 한계를 보임

HTTP/3

2022년에 등장

TCP 기반 탈피 → QUIC 기반

QUIC 프로토콜
(Quick UDP Internet Connections)

UDP (User Datagram Protocol)
→ 신뢰성 없는 비연결형 프로토콜
→ 빠른 전송이 중요하고, 약간의 데이터 손실은 감수할 수 있을 때 사용

QUIC 기반 멀티플렉싱

• 각 스트림이 완전히 독립적으로 전송됨

• TCP처럼 순서 보장 + UDP처럼 빠름

• 패킷 하나 유실돼도 나머지 스트림 영향 없음

TLS 1.3 내장 (암호화 기본값)

TLS (Transport Layer Security)

→ 인터넷 상에서 데이터를 암호화해서 안전하게 전송하게 해주는 보안 프로토콜
→ HTTPS, 이메일, VPN 등에서 널리 사용됨

• HTTPS 강제 → 암호화는 선택이 아닌 기본

• TLS 핸드쉐이크가 QUIC에 통합되어 있음
  → 더 빠름 + 더 안전함
  

0-RTT 연결 재개

• 기존 TLS는 최소 1~2회 왕복 시간(RTT) 필요

• HTTP/3는 과거 연결 이력 있으면, 데이터 전송을 즉시 시작 가능
  → 접속 속도 체감 향상
  

연결 지연 회복 속도 개선

• QUIC은 연결 상태를 애플리케이션이 직접 관리
  

현재 사용률