HTTP/1.0
1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어있다. 서버로부터 파일을 가져올 때마다 TCP의 3-WAY 핸드셰이크를 계속해서 열어야 한다.
-> RTT 증가를 야기함
RTT 란?
패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간. 즉, 패킷왕복시간이다.
HTTP/1.1
1.0 버전의 업그레이드 버젼. 매번 TCP 연결 하는 것이 아닌, 한번의 TCP 초기화를 한 이후 keep-alive라는 옵션으로 여러개의 파일을 송수신 할 수 있게 바뀜.
위 그림처럼 한번 3-way 핸드쉐이크가 발생하면 그 다음부터 발생하지 않는다. 하지만 문서 안에 포함된 다수의 리소스(이미지, css, script 등)을 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다.
HTTP/2
HTTP/2 는 SPDY 프로토콜에서 파생된 HTTP/1.1 보다 지연시간을 줄이고 응답시간을 더 빠르게 할 수 있으며, 멀티플렉싱, 헤더압축, 서버푸치, 요청의 우선순위 처리를 지원하는 프로토콜이다.
멀티플랙싱
멀티플렉싱이란 여러개의 스트림을 사용하여 송수신한다는 것이다. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있다.
-> HTTP/1.1 에서 발생하는 HOL Blocking 해결할 수 있다.
HOL Blocking 이란?
네트워크에서 같은 큐에 있는 패킷이 그 첫번 째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말한다.
헤더압축
HTTP/1.1 은 크기가 큰 헤더라는 문제가 있다. HTTP/2 에서는 헤더압축을 써서 해결하는데, 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가진다.
허프만 코딩이란?
문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트수를 사용해 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용해 전체 데이터의 표현에 필요한 비트양을 줄이는 원리이다.
서버푸시
HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드받을 수 있지만, HTTP/2 에서는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.
html 에는 css 나 js 파일이 포함되기 마련인데, html 을 읽으면서 그 안에 들어있는 css 파일을 서버에서 푸시하여 클라이언트에 먼저 줄 수 있다.
HTTP/3
TCP 위에서 돌아가는 기존의 HTTP 프로토콜과는 달리 QUIC 라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.
또한, HTTP/2 에서 장점이었던 멀티플렉싱을 가지고 있으며 초기 연결 설정 시 지연 감소라는 장점이 있다.
초기 연결 설정 시 지연 시간 감소
QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 3-WAY 핸드쉐이크 과정을 거치지 않아도 돼 RTT 소요가 감소한다.
- QUIC은 순방향 오류 수정 메커니즘(FEC)가 적용되어있다. 이는 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.
