내용 출처
1. 우아한테크코스 - 🧃쿨라임의 HTTP/1.1, HTTP/2, 그리고 QUIC
2. HTTP의 진화
3. HTTP/1.x의 커넥션 관리
4. HTTP/2 소개
5. Does the QUIC handshake require compression to be fast?
HTTP
- 웹 상의 클라이언트와 서버 간 통신을 위한 프로토콜
- 어플리케이션 계층에 속하며, 통신을 위해 TCP 혹은 UDP를 활용
- 이론상으로 TCP 혹은 UDP 모두 활용 가능하지만, HTTP/0.9 ~ HTTP/2 까지는 TCP를 중심으로 활용
HTTP/0.9 - 원 라인 프로토콜
HTTP 초기버전에는 버전 번호가 없었지만 차후 버전과 구별하기 위해 0.9로 불리게 됨
- 요청
GET /mypage.html- 응답
<HTML>
A very simple HTML page
</HTML>요청 메시지가 한줄에 불과했으며, 메서드 또한 GET 밖에 없었음 따라서 이를 One-Line Protocol이라고 부르기도 했다. 심플했지만 그만큼 기능이 지나치게 제한적이었다.
HTTP/1.0 - 확장성 구축
- 요청 (HTML)
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
- 응답
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)
버전 정보가 각요청에서 전송되기 시작 (HTTP/1.0)상태 코드가응답의 시작 부분에 전송되어 브라우저가 요청의 성공, 실패 결과를 알 수 있게 됨헤더 개념이요청과응답모두에 도입되어, 메타데이터 전송과 프로토콜 유연화 및 확장이 가능하도록 함- 헤더의
Content-Type이 추가 되어 HTML 파일 외에 다른 문서 전송 기능이 추가됨
한계 1. 단기 커넥션: Connection 하나 당 요청 하나와 응답 하나만 처리 가능
: 매번 새로운 연결이 필요해서 성능이 저하되고 서버 부하 비용이 증가
HTTP/1.1 - 표준 프로토콜
1997년 1월 공개된 HTTP의 첫 번째 표준 버전, HTTP/1.0은 공식적 표준은 아니었다.
HTTP/1.1은 공개 이후 15년 넘게 안정성을 유지하며, 다양한 기능들을 시도함
- 요청
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
- 응답
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(content)
- HTTP/1.0의
Short-lived Connection의 단점을 보완하기 위해Persistent Connection과Pipelining을 도입 - 이외에도 추가적인 캐시 제어 매커니즘, 컨텐츠의 언어, 인코딩 타입 등이 헤더에 추가됨
Persistent Connection의 도입
- 지정한 Timeout 동안 Connection을 닫지 않음으로써, 한 개의 커넥션을 열어두면 여러 요청이 커네셕을 사용 가능함
- 이전 HTTP/1.0의 단기 커넥션과 비교해서 네트워크 사용시간이 줄어듬
Pipelining의 도입
- 하나의 Connection에서 요청에 대한 응답을 기다리지 않고 순차적으로 여러 요청을 보내고 그 순서에 맞춰 응답을 받는 방식
- 네트워크 지연시간을 줄이는 장점
- 하지만 파이프라이닝은 구현의 복잡도와 메시지의 중요도에 따른 처리가 어려운 단점을 가지고 있어서, HTTP/2 부터 도입된 Multiplexing에 대체되어 현재 대부분 브라우저에서 비활성화됨
한계 1. Head of Line Blocking
: 선행 요청이 서버에서 처리 시간이 오래걸릴 경우, 이후 요청은 계속 기다려야 하는 상황
한계 2. Header 구조의 중복
: Header 구조에 중복된 내용이 많음에도 같은 내용을 요청마다 다시 보내야함, 따라서 주고받는 데이터 양이 불필요하게 커지는 단점이 있음
HTTP/2 - 성능 개선에 초점
2015년 5월에 공식적으로 표준화됐으며, 기존 HTTP/1.1의 성능 향상을 통해 표준의 대체가 아닌 기능 확장을 중심으로 함, 2021년 3월 기준 약 50%의 웹사이트가 채택
메시지 전송 형태의 변화: 바이너리 프레이밍 계층
- 기존 하나의 텍스트로 메시지를 전송하던 방식에서 바이너리 프레이밍 계층을 사용하는 방식으로 변화
- HTTP/1.x 프로토콜은 줄바꿈으로 구분되는 일반 텍스트를 활용했으나, HTTP/2 통신은 내용을 프레임 단위로 분할하여, 분할된 각 프레임을 바이너리 형식으로 인코딩하여 전송
- 바이너리 데이터에 친화적인 컴퓨터의 특성 때문에 전송속도가 상승하고 오류 발생 가능성이 낮아짐
데이터 교환 방식의 변화: 스트림, 메시지, 프레임
용어 정리
1. 스트림: 연결 내에서 전달되는 바이트의 양방향 흐름으로, 하나 이상의 메시지가 전달될 수 있음
2. 메시지: 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스
3. 프레임: HTTP/2에서의 통신의 최소 단위로, 각 최소 단위에는 하나의 프레임 헤더가 포함되어서 프레임이 속하는 스트림을 식별
- 클라이언트와 서버 간 양방향 연결 스트림에서 프레임이 들어가 합쳐지며 요청/응답 메시지를 구성
요청 및 응답 Multiplexing
- 프레임 단위로 스트림을 통해 데이터가 교환되면서, 요청과 응답 순서의 의미가 약화
- 요청과 응답의 다중화가 가능해지며, HTTP/1.1의 Head of Blocking 문제가 해결됨
Stream Prioritization
- 스트림에 우선순위 가중치를 두어서, 먼저 응답하게끔 설정이 가능함
Header Compression
- 헤더 간 중복값을 검출해서 중복된 데이터는 인덱스만 뽑아내고, 중복되지 않은 데이터는 Huffman 코드로 인코딩
- 헤더를 위와 같이 압축 전송하여 헤더의 크기가 약 85% 줄어드는 효과가 있음
HTTP/3, QUIC
HTTP는 UDP를 기반으로하는 QUIC을 사용하여 UDP의 빠른 전송속도의 이점을 챙기며 신뢰성있는 통신을 추구한다.
전송속도의 극적인 향상
- 첫 연결 설정에서 필요한 정보와 데이터를 함께 전송함으로써 기존 TCP의 핸드쉐이크와 데이터 전송을 통합시킴
- 연결 성공시, Connection UUID라는 고유한 식별자를 캐싱하여 서버를 연결해두어서 커넥션 재수립이 필요가 없어지며, 다음 연결 때 바로 성립
독립 스트림을 통한 향상된 Multiplexing
- 기존 TCP의 Multiplexing은 여러 스트림이 이어져 전송되기 때문에, 일부 스트림 손실이 발생할 경우 후속 데이터가 대기 해야하는 문제가 있음
- Quic은 각 스트림이 독립적으로 전송되어서 일부 스트림에 문제가 생기더라도 다른 스트림은 지속적으로 데이터 전송이 가능함
