1. HTTP/1.1의 구조적 한계
- 요청/응답 구조
; 하나의 TCP 커넥션에서 요청과 응답이 순서대로 처리됨
; 브라우저는 도메인당 최대 6개의 병렬 커넥션을 열어 우회
- HOL Blocking
; 앞 요청이 막히면 뒤 요청이 모두 대기
; HTTP 레벨과 TCP 레벨 두 층에서 발생
; HTTP 레벨: 응답 순서 보장
; TCP 레벨: 패킷 손실 시 전체 대기
- 우회 기법들: 요청 수 자체를 줄이는 방향으로 대응
; 파일 번들링: JS/CSS를 하나로 합쳐 요청 수 감소
; CSS Sprite: 여러 이미지를 하나로 묶어 요청 수 감소
; 도메인 샤딩: 리소스를 여러 도메인에 분산해 병렬 커넥션 확보
2. HTTP/2
- 멀티플렉싱
; 단일 TCP 커넥션 위에서 독립적으로 번호가 붙은 스트림을 사용해 여러 요청과 응답을 동시에 처리
. 애플리케이션 레벨 HOL Blocking 해소
- 헤더 압축 (HPACK)
; 반복되는 헤더를 압축해 전송
; 요청이 많을수록 효과적
- Binary Framing Layer
; 텍스트 기반이던 HTTP/1.1과 달리 바이너리로 데이터를 프레임 단위로 분할해 전송
- Server Push
; 서버가 요청 전에 리소스를 먼저 보내는 기능
→ 실제 성능 이점이 불분명하고 사용률이 낮아 Chrome106(2022년)에서 기본 비활성화, FireFox 132(2024)에서 지원 제거
3. HTTP/2가 F/E 리소스 전략에 미친 영향
- 번들링·CSS Sprite·도메인 샤딩이 더 이상 유효하지 않은 이유
; 멀티플렉싱으로 단일 커넥션에서 병렬 처리가 가능해짐
; 도메인 샤딩은 오히려 도메인마다 DNS 쿼리·TCP 커넥션·TLS핸드셰이크 비용 추가 발생
- 번들러의 역할 변화
; tree-shaking과 코드 스플리팅으로 실제로 필요한 코드만 전달하는데 집중
- 개발 환경 vs 프로덕션 환경
; Vite는 개발 서버에서 번들링 없이 native ESM으로 파일을 그대로 서빙
; 프로덕션에서는 중첩된 임포트로 인한 추가 네트워크 왕복 문제 때문에 번들링을 유지
4. HTTP/2환경에서의 캐시 전략
- Cache-Control - 리소스 유형에 따라 디렉트브를 다르게 적용
; no-chache: 저장은 하되 매번 서버에 재검증 요구
; no-store: 저장 자체를 차단, 매 요청마다 서버에서 새로 수신
; max-age=31536000, immutable: 1년간 캐시, 재검증 없음
- ETag와 조건부 요청
; 리소스가 변경되지 않았으면 서버는 본문 없이 '304 Not Modified'만 반환해 대역폭 절약
- 리소스 유형별 TTL 설계 - HTML과 정적 자산을 분리 설계
; HTML: Cache-control: no-cache (매번 재검증)
; JS/CSS: 빌드 시 파일명에 해시 포함 후 Cache-Control: max-age=31536000, immutable (캐시 무효화 자동 처리)
5. HTTP/3 / QUIC
- TCP의 한계
; HTTP/2는 HTTP 레벨 HOL Blocking은 해결했지만 TCP 레벨은 미해결
; 패킷 손실이 발생시 HTTP 레이어 입장에서는 단순한 지연으로만 감지
; 다른 스트림에 필요한 데이터가 이미 도착했어도 대기
- QUIC
; UDP 기반으로 스트림별 독립적인 손실 복구를 제공
; 패킷 손실이 해당 스트림에만 영향을 주고 전체 커넥션을 막지 않음
; 0-RTT 연결 재개와 TLS 1.3 통합으로 연결 수립 속도 개선
⭐발표자 : 이현주님
1. HTTP/1.1의 구조적 한계
- 요청/응답 구조
; 하나의 TCP 커넥션에서 요청과 응답이 순서대로 처리됨
; 브라우저는 도메인당 최대 6개의 병렬 커넥션을 열어 우회
- HOL Blocking
; 앞 요청이 막히면 뒤 요청이 모두 대기
; HTTP 레벨과 TCP 레벨 두 층에서 발생
; HTTP 레벨: 응답 순서 보장
; TCP 레벨: 패킷 손실 시 전체 대기
- 우회 기법들: 요청 수 자체를 줄이는 방향으로 대응
; 파일 번들링: JS/CSS를 하나로 합쳐 요청 수 감소
; CSS Sprite: 여러 이미지를 하나로 묶어 요청 수 감소
; 도메인 샤딩: 리소스를 여러 도메인에 분산해 병렬 커넥션 확보
2. HTTP/2
- 멀티플렉싱
; 단일 TCP 커넥션 위에서 독립적으로 번호가 붙은 스트림을 사용해 여러 요청과 응답을 동시에 처리
. 애플리케이션 레벨 HOL Blocking 해소
- 헤더 압축 (HPACK)
; 반복되는 헤더를 압축해 전송
; 요청이 많을수록 효과적
- Binary Framing Layer
; 텍스트 기반이던 HTTP/1.1과 달리 바이너리로 데이터를 프레임 단위로 분할해 전송
- Server Push
; 서버가 요청 전에 리소스를 먼저 보내는 기능
→ 실제 성능 이점이 불분명하고 사용률이 낮아 Chrome106(2022년)에서 기본 비활성화, FireFox 132(2024)에서 지원 제거
3. HTTP/2가 F/E 리소스 전략에 미친 영향
- 번들링·CSS Sprite·도메인 샤딩이 더 이상 유효하지 않은 이유
; 멀티플렉싱으로 단일 커넥션에서 병렬 처리가 가능해짐
; 도메인 샤딩은 오히려 도메인마다 DNS 쿼리·TCP 커넥션·TLS핸드셰이크 비용 추가 발생
- 번들러의 역할 변화
; tree-shaking과 코드 스플리팅으로 실제로 필요한 코드만 전달하는데 집중
- 개발 환경 vs 프로덕션 환경
; Vite는 개발 서버에서 번들링 없이 native ESM으로 파일을 그대로 서빙
; 프로덕션에서는 중첩된 임포트로 인한 추가 네트워크 왕복 문제 때문에 번들링을 유지
4. HTTP/2환경에서의 캐시 전략
- Cache-Control - 리소스 유형에 따라 디렉트브를 다르게 적용
; no-chache: 저장은 하되 매번 서버에 재검증 요구
; no-store: 저장 자체를 차단, 매 요청마다 서버에서 새로 수신
; max-age=31536000, immutable: 1년간 캐시, 재검증 없음
- ETag와 조건부 요청
; 리소스가 변경되지 않았으면 서버는 본문 없이 '304 Not Modified'만 반환해 대역폭 절약
- 리소스 유형별 TTL 설계 - HTML과 정적 자산을 분리 설계
; HTML: Cache-control: no-cache (매번 재검증)
; JS/CSS: 빌드 시 파일명에 해시 포함 후 Cache-Control: max-age=31536000, immutable (캐시 무효화 자동 처리)
5. HTTP/3 / QUIC
- TCP의 한계
; HTTP/2는 HTTP 레벨 HOL Blocking은 해결했지만 TCP 레벨은 미해결
; 패킷 손실이 발생시 HTTP 레이어 입장에서는 단순한 지연으로만 감지
; 다른 스트림에 필요한 데이터가 이미 도착했어도 대기
- QUIC
; UDP 기반으로 스트림별 독립적인 손실 복구를 제공
; 패킷 손실이 해당 스트림에만 영향을 주고 전체 커넥션을 막지 않음
; 0-RTT 연결 재개와 TLS 1.3 통합으로 연결 수립 속도 개선
⭐발표자 : 이현주님