HTTP/2
- 멀팅플렉싱 : 하나의 TCP 연결을 통해 여러 요청과 응답을 비동기적으로 주고받을 수 있음
-
이는 HTTP/1.1의
Head-Of-Line Blocking문제를 해결 -
단일 TCP 연결 내에서 여러 스트림을 독립적으로 생성하고 각 스트림은 고유한 스트림 ID를 가짐
-
데이터는 작은 프레임 단위로 나누어지며 순서와 상관없이 전송된 후 수신 측에서 재조립
-
- 헤더 압축 : 헤더 데이터를 압축하여 전송량을 줄임
- HPACK이라는 압축 방식을 사용
- 반복적인 헤더 정보를 압축하여 전송 오버헤드를 줄임
허프만 코딩(Huffman Coding) 알고리즘을 활용하여 압축 효율을 극대화함허프만 코딩(Huffman Coding) 알고리즘
- 문자열을 문자 단위로 쪼개어 각 문자의 빈도수를 계산한 후, 빈도가 높은 문자는 적은 비트수를 사용해 표현하고 빈도가 낮은 문자는 많은 비트 수를 사용하여 전체 데이터 표현에 필요한 비트 양을 줄임
1. 빈도수 계산:
- 문자열에서 각 문자의 출현 빈도를 계산
2. 우선순위 큐 생성:
- 각 문자를 빈도수에 따라 정렬하여 우선순위 큐에 삽입. 빈도가 낮은 문자가 높은 우선순위를 가짐
3. 트리 생성:
- 두 개의 빈도가 가장 낮은 노드를 선택하여 이들을 자식 노드로 하는 새로운 부모 노드를 생성. 이 부모 노드의 빈도수는 두 자식 노드 빈도의 합
- 이 과정을 반복하여 모든 노드가 하나의 트리로 결합될 때까지 계속. 최종적으로 생성된 트리가 허프만 트리
4. 코드 할당:
- 허프만 트리의 루트에서 리프 노드까지의 경로를 따라 각 문자에 대한 코드를 할당. 좌측 경로는 ‘0’, 우측 경로는 ‘1’로 할당하여 문자를 이진 코드로 변환
- 빈도가 높은 문자는 트리의 상위에 위치하게 되어 짧은 코드가 할당되고, 빈도가 낮은 문자는 트리의 하위에 위치하여 긴 코드가 할당
문자열: "this is an example for huffman encoding"
빈도수 계산:
t: 1, h: 2, i: 2, s: 2, a: 2, n: 3, e: 2, x: 1, m: 2, p: 1, l: 1, f: 2, o: 1, r: 1, u: 1, c: 1, d: 1, g: 1, ' ': 6
우선순위 큐:
빈도가 낮은 순서로 정렬: t, x, p, l, o, r, u, c, d, g, h, i, s, a, e, m, f, n, ' '
트리 생성 및 코드 할당:
트리를 구성하여 각 문자에 이진 코드를 할당합니다. 예를 들어:
' ': 11, t: 11010, h: 010, i: 011, s: 100, n: 101, ...
최종 허프만 코드:
"this is an example for huffman encoding" => 110100101100011011100010110000110011011011100010011100001010011011101011001000101101010110010101001011010111000111110100111010011010011011100101011011-
서버 푸시 : 서버가 클라이언트가 요청하지 않은 리소스를 미리 전송할 수 있음
-
예를들어, HTML 문서를 요청한 클라이언트에게 필요한 CSS 파일이나 JavaScript 파일을 미리 전송할 수 있음
-
이를 통해 페이지 로딩 시간을 단축할 수 있음
-
-
스트림 우선순위 : 클라이언트가 각 스트림에 우선순위를 부여하여 중요한 리소스를 먼저 받을 수 있게 함
- 스트림 간 의존성을 설정하여 중요도가 높은 스트림이 먼저 전송될 수 있도록 함
스트림(Stream)이란?
- 단일 TCP 연결 내에서 독립적으로 동작하는
가상의 채널을 의미
바이너리 포맷 계층
- 애플리케이션 계층과 전송 계층 사이에 바이너리 포맷 게층을 추가
- HTTP 1.0은 일반 텍스트 메시지를 전송하고 줄바꿈으로 데이터를 나눴다면 HTTP 2.0은 0과 1로 이루어진 바이너리 데이터로 변경되었고 더 작은 메시지가 프레임으로 캡슐화 되어 전송
HTTP/3
- QUIC(Quick UDP Internet Connection)라는 전송 프로토콜을 기반으로 함
-
전송 계층 : HTTP/2는 TCP를 기반으로 하지만, HTTP/3은 UDP를 기반으로 하는 QUIC을 사용
- QUIC는 TCP의 연결 설정과 전송 속도를 개선하기 위해 설계
-
연결 설정 시간 :
1-RTT: 새로운 연결을 설정할 때, QUIC는 한 번의 왕복 시간(1-RTT)만으로 보안 연결을 설정0-RTT: 이전에 연결된 상태라면, QUIC는 0-RTT(Zero Round Trip Time)를 지원하여 새로운 연결 설정 없이도 데이터를 즉시 전송할 수 있음- 이는 HTTPS 연결 설정 시간을 크게 단축시킴
-
멀티플렉싱 : HTTP/2와 마찬가지로 멀티플렉싱을 지원하지만 QUIC 기반이기 때문에 패킷 손실이 하나의 스트림에만 영향을 미침
- TCP 기반의 HTTP/2에서는 패킷 손실이 발생하면 전체 연결이 지연될 수 있음
-
보안 : QUIC는 TLS 1.3 암호화를 기본적으로 포함하고 있어 보안 설정이 간편하며 보안 연결이 더 빠르게 설정
TLS 1.3(Transport Layer Security 1.3)
-
인터넷 통신의 보안을 강화하기 위한 최신 프로토콜
-
TLS는 원래 SSL(Secure Sockets Layer)로 알려졌으며 데이터가 전송되는 동안 이를 암호화하여 안전하게 보호하는 역할을 함
TLS 1.3 핸드세이크 과정클라이언트 헬로(Client Hello) ↓ 클라이언트가 서버에 연결을 요청하며 지원하는 암호화 스위트 목록과 함께 클라이언트 랜덤 값을 보냄 ↓ 서버 헬로(Server Hello) ↓ 서버가 클라이언트의 요청에 응답하며 선택된 암호화 스위트와 서버 랜덤 값을 보냄 서버는 클라이언트와 서버가 공유하는 프리마스터 시크릿을 생성하기 위한 키 교환 메시지도 보냄 ↓ 키 교환 및 완료 ↓ 클라이언트와 서버는 키 교환 메시지를 기반으로 세션 키를 생성 이후 클라이언트와 서버는 “Finished” 메시지를 주고받으며 핸드세이크가 완료
- 헤더 압축 : HTTP/3에서도 헤더 압축을 지원하지만 QPACK이라는 방식으로 개선
HTTP 버전별 특징 요약
| 버전 | 특징 | 장점 | 단점 |
|---|---|---|---|
| HTTP/1.0 | - 최초의 HTTP 표준 - 단일 요청-응답 연결 | - 간단하고 구현이 쉬움 - 초기 웹 지원 | - 연결당 하나의 요청 - 비효율적인 연결 재사용 |
| HTTP/1.1 | - 지속 연결 - 청크 전송 인코딩 - 호스트 헤더 필드 | - 연결 재사용 - 더 나은 성능과 효율성 | - 헤드 오브 라인 블로킹 문제 - 제한된 멀티플렉싱 |
| HTTP/2 | - 이진 프로토콜 - 헤더 압축(HPACK) - 멀티플렉싱 - 서버 푸시 | - 성능 향상 - 효율적인 리소스 사용 - 빠른 페이지 로드 | - 복잡한 구현 - TCP의 한계(TCP HOL 블로킹) |
| HTTP/3 | - QUIC 기반(UDP 사용) - 헤더 압축(QPACK) - 0-RTT 지원 - 개선된 멀티플렉싱 | - 빠른 연결 설정(1-RTT, 0-RTT) - 향상된 성능과 보안 - 패킷 손실의 개별 스트림 영향 감소 | - 복잡한 프로토콜 - 방화벽 및 NAT 장비와의 호환성 문제 가능 |
HW + SW = 1