[네트워크] HTTP 역사
Updated: Categories: CS버전별 HTTP 프로토콜에 대해 알아보자
HTTP/0.9, 1,0
- TCP 기반
- HTTP 헤더 도입으로 HTML 이외 다른 문서 타입도 지원
문제점 1 : RTT 증가
- 하나의 연결에서 요청-응답 한쌍밖에 처리하지 못함
- 요청별로 커넥션을 생성하고 이때마다 3-way Handshaking이 발생함
문제점 2 : 동시전송 불가
- 커넥션당 하나의 요청밖에 처리하지 못하니 당연히 동시전송도 불가함
HTTP/1.1
- TCP 기반
- 이전 HTTP 버전 문제를 해결함
해결 1 : Persistent Connection
- RTT 증가 문제를 해결함
- TCP 커넥션을 한번 열고 재사용하여 3-way Handshaking 과정을 줄인다
- 지정한 시간동안 TCP 커넥션을 닫지 않는다
해결 2 : Pipelining
- 동시전송 불가 문제를 해결
- 요청에 대한 응답을 기다리지 않고 여러개의 요청을 보내는 방식
문제점 1 : HOLB(Head Of Line Blocking)
- 패킷이 순서대로 도착해야하므로 패킷이 도착할때까지 그 이후 패킷은 전송되지 못하는 것
- 또한 패킷이 정상적으로 도착하지 못할때마다 재요청이 일어남
- 재요청 시간만큼 통신이 지연됨
문제점 2 : 무거운 Header 구조
- http1.1은 다수의 http 요청이 발생할때마다 중복된 헤더값을 전송하게 됨
- 쿠키 정보도 헤더에 담겨 요청되므로 헤더가 매우 무거워짐
- 해결방법
- 헤더 정보를 직접 압축하기
HTTP/2.0
- HTTP1.1의 문제를 해결하기 위해 고안됨
Multiplexing
- HOLB 문제를 해결
- 바이너리 프레임 계층을 사용
- 파싱, 전송속도 증가 / 오류발생 가능성 낮춤
- 한번의 요청만으로 모든 데이터를 전송
- 응답은 순서에 상관없이 스트림으로 주고받음
- http1.1의
Pipelining과Persistent Connection을 개선
Stream Prioritization
- 리소스간 우선 순위를 설정할 수 있음
- ex) 렌더링을 위해서 이미지 파일보다 CSS 파일의 우선순위가 높아야함
Server Push
- 서버는 요청하지 않은 리소스도 맘대로 보내줄 수 있음
- HTTP/1.1은 클라이언트가 HTML 응답을 받은 후 이를 분석해 CSS, JS 등을 재요청
- Server Push를 사용하면 서버가 알아서 보내줌
Header Compression
- http1.1의 무거운 헤더 구조를 해결하기 위한 기술
- 헤더 정보를 압축하는 방식
- 요청간 중복되는 헤더는 index값만 전송함
사용방법
- HTTPS가 필수적으로 요구됨
- HTTP2의 표준 요구사항은 아니지만, 대부분의 브라우저에서 요구함
- 적용과정
- 브라우저에서 백엔드로 요청을 보낼 때, 웹서버에서 HTTP2를 지원하는지 먼저 확인함
- HTTP2를 지원한다면 HTTP2로 요청보냄
- 웹서버에서는 HTTP2 요청을 받고 WAS로 전달
HTTP 3
- HTTP1.1과 HTTP2는 TCP 기반 프로토콜이므로 자체적인 한계가 있음
- 따라서 HTTP3은 이를 개선하기 위해 UDP 프로토콜(QUIC)을 사용
- 매우 빠른 속도로 유튜브 및 여러 CDN 서비스에서 사용됨
UDP Header
- 무거운 TCP 헤더와 달리 UDP 헤더는 매우 가벼운 구조
- 데이터 전송에만 집중된 프로토콜이기 때문
- 필요한 기능을 직접 헤더로 구현할 수 있음
No 3-way Handshake
- UDP 기반이므로 3-way Handshake와 같은 과정이 없고, 이는 RTT 단축으로 이어짐
- 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송하고, 이런 정보를 캐싱
- Connection UUID라는 식별자를 통해 커넥션 정보를 저장해 연결을 유지
향상된 Multiplexing
- 스트림을 독립적으로 유지하여 TCP Multiplexing의 HOLB 문제 해결
참고 : https://kooku.netlify.app/web/http1.1-vs-http2/