HTTP 버전 비교
HTTP 1.0:
HTTP 1.0은 HTTP(하이퍼텍스트 전송 프로토콜)의 첫 번째 버전이다.
비지속적 연결을 사용했는데, 이는 각 요청/응답 교환에 대해 매번 새로운 TCP 연결이 설정되었음을 의미한다.
HTTP 1.0은 요청 파이프라인 지원이 부족하여 클라이언트가 다음 요청을 보내기 전에 응답을 기다려야 한다.
대용량 파일을 효율적으로 처리하기 위한 메커니즘이 포함되지 않아 여러 리소스가 있는 웹 페이지의 로딩 시간이 느려진다.
캐싱 메커니즘은 HTTP 1.0에서 제한적이고 잘 정의되지 않았다.
HTTP 1.1:
여러 요청/응답에 대해 단일 TCP 연결을 재사용하여 대기 시간을 줄이기 위해 지속적인 연결(커넥션 유지)을 도입했다.
HTTP 1.1은 클라이언트가 각 응답을 기다리지 않고 여러 요청을 보낼 수 있도록 요청 파이프라이닝을 도입했다.
호스트 헤더는 필수 항목이 되어 가상 호스팅을 활성화하고 동일한 IP 주소에서 여러 웹사이트를 허용한다.
청크 분할 전송 인코딩에 대한 지원을 추가하여 대용량 응답을 보다 효율적으로 전송한다.
"Cache-Control", "ETag"와 같은 캐시 제어 헤더의 도입으로 캐싱 메커니즘이 향상되었다.
호스트 헤더
HTTP 요청의 일부
클라이언트가 웹 서버에게 요청을 보낼 때 해당 요청이 어떤 도메인의 리소스를 타겟으로 하는지를 알려주는 역할
이를 통해 하나의 IP 주소에서 여러 개의 도메인 이름을 가진 웹 사이트를 동시에 호스팅 가능
host 필드를 통해 가상 사이트 식별
가상 호스팅 하나의 서버에 여러 개의 도메인 이름을 호스팅하는 방식
HTTP 1.0 VS HTTP 1.1
지속성
HTTP 1.0은 요청하고 수신할 때마다 새로운 TCP 세션을 맺어야 한다.
반면, HTTP 1.1부터는 TCP 세션을 한 번만 맺으면 여러 개의 요청을 보내고 응답을 수신할 수 있다.
결과적으로 TCP 세션을 처리하는 비용을 줄이고 응답속도를 개선할 수 있게 된다.
파이프라이닝
HTTP 1.0 환경에서는 요청에 대한 응답이 와야 다음 응답을 보낼 수 있다.
반면, HTTP 1.1에서는 요청을 병렬로 처리할 수 있는 파이프라이닝 기능을 지원한다.
결과적으로 HTTP 1.1에서는 여러 개의 요청을 처리하는 응답 속도가 훨씬 빨라지게 된다.
호스트 헤더
HTTP 1.0 환경에서는 하나의 IP에 하나의 도메인만 운영할 수 있다.
(도메인을 여러 개 사용하려면 서버를 늘려야 한다.)
HTTP 1.1 에서는 웹서버에서 요청 Header에 Host를 전달 받아 서버로 보내주는 가상 호스팅이 가능해졌다.
즉, 서버 1대가 여러 개의 Host를 담당할 수 있다.
HTTP/2.0:
HTTP/2.0은 다중화를 지원하여 단일 연결을 통해 동시에 여러 요청/응답을 보낼 수 있습니다. 이렇게 하면 HOL(head-of-line) 차단 문제가 제거되고 전체 처리량이 향상된다.
서버 푸시를 사용하여 명시적인 요청을 기다리지 않고 서버가 사전에 리소스를 클라이언트에 보내 대기 시간을 줄인다.
HTTP/2.0은 헤더 압축을 사용하여 요청 및 응답 헤더의 크기를 줄여 대역폭 활용도를 높였다.
HTTP/1.1에서는 요청 및 응답 헤더가 텍스트 형태로 전송 되어 많은 메타데이터와 중복된 정보 전송 됨
헤더 압축
헤더 필드의 이름과 값에 대한 딕셔너리 기반 인코딩을 사용하여 중복되는 정보를 인식하고 압축
압축된 헤더는 네트워크를 통해 전송, 수신측에서는 압축 해제로 원래 헤더 정보 복원
스트림 우선 순위 지정 및 흐름 제어와 같은 기능을 포함하여 데이터 전송을 관리하고 최적화한다.
HTTP/2.0은 HTTP 1.1과 역호환되므로 점진적으로 채택할 수 있다.
> 대역폭 활용도 : 네트워크에서 전송되는 데이터의 양을 효율적으로 활용하는 정도
HTTP 1.1 VS HTTP 2.0?
다중화(Multiplexed Streams)
HTTP 2.0에서는 다중화라는 기술을 도입했다.
1개의 세션으로 여러 개의 요청을 순서 상관없이 받아서 동시다발적으로 처리하고 응답할 수 있게 된다.
이는 특정 요청이 먼저 끝나면 해당 요청에 대해 먼저 응답한다.
따라서, HTTP 1.1의 HOLB(Head OF Line Blocking) 문제를 해결하게 된다.
2.스트림 우선 순위 지정(Stream Priorityzation)
HTTP 2.0에서는 각 요청에 Priority(우선 순위)를 부여한다.
예를 들어, HTML 문서와 해당 문서에서 사용할 Image를 요청한다고 가정하면, Image를 먼저 응답 받아도, 렌더링할 HTML 문서가 처리가 안되면 의미가 없다.
이때, HTML 문서의 우선순위를 높여서 먼저 응답하고, Image는 이후에 응답하면 더 효율적으로 동작한다.
3.서버 푸쉬(Server Push)
HTML 문서가 있고, 해당 문서에서 사용하는 CSS와 Images가 있다고 가정한다.
기존(HTTP 1.1)에서는 HTML 문서를 요청한 후, 해당 문서에서 필요한 CSS와 Images를 요청했었다.
HTTP 2.0부터는 HTML 문서를 요청하면, 클라이언트가 추가로 요청을 하지 않아도 서버가 필요한 리소스를 알아서 보낸다.
4.해더 압축(Header Compression)
HTTP 1.1 에서는 이전에 보냈던 요청과 중복되는 Header도 똑같이 전송하느라 자원을 낭비했다.
HTTP 2.0 부터는 허프만 코딩을 사용한 HPACK 압축 방식으로 이를 개선했습니다.
클라이언트와 서버는 각각 Header Table을 관리하고, 이전 요청과 동일한 필드는 table index만 보낸다.
변경되는 값은 Huffman Encoding 후 보냄으로써 Header의 크기를 경량화 하였다.
HOL 차단 문제
HTTP/1.1는 하나의 TCP 연결에서 한 번에 하나의 요청만 처리할 수 있음
이때, 여러 개의 요청이 동시에 서버로 보내지면, 먼저 보낸 요청의 응답이 뒤에 보낸 요청의 응답이 끝나기 전까지 기다려야 하는 현상
문제점
느린 요청이 빠른 요청의 처리를 지연시키는 문제 발생
전체적인 성능에 부정적인 영향
다중화(Multiplexing) 기능
단일 TCP 연결을 통해 여러 개의 요청과 응답을 동시에 처리할 수 있는 기능
하나의 연결 내에서 여러 스트림(stream)을 생성하여 각각의 스트림에 대한 요청과 응답을 병렬로 처리
서버와 클라이언트 사이 별도의 연결을 열지 않고도 여러 개의 요청과 응답을 교환 가능
다중화 기능을 통한 HOL차단 문제 제거
빠른 요청이 느린 요청의 처리를 기다릴 필요가 없어짐
웹 페이지 로딩 시간 단축
전체적인 성능이 향상
하나의 연결을 유지하면서 여러 요청과 응답을 주고받음
TCP 연결을 매번 새로 열고 닫는 데 드는 오버헤드 감소
네트워크 사용량과 지연 시간 감소
Head of Line Blocking
HTTP HOLB
HTTP/1.1 HOLB
HTTP/1.1 의 요청-응답 쌍은 항상 순서를 유지해야 한다. a,b,c 순으로 요청을 보낼 경우, 각 순서대로 응답을 받아야한다.
파이프라이닝으로 여러 요청을 보내더라도, 응답은 보낸 순서대로 받아야 한다.
처음 요청이 느리게 응답하면, 뒤의 응답도 느려지게 된다.
HTTP/2.0 HOLB
한 번의 연결에서 요청은 병렬적으로 보내질 수 있고, 응답도 병렬로 받는다.
1.1 의 HOL은 2.0에서는 발생하지 않는다.
TCP HOLB
HTTP 요청/응답을 TCP 패킷 레벨로 바꾼 것이라 생각하면 된다.
TCP 패킷을 전송할 때, 패킷이 손실되면 재전송을 거친다.
재전송이 발생하면 패킷의 순서가 역전되지 않도록 후속 패킷이 대기하게 된다. 즉 지연이 발생한다.
HTTP/3.0
등장 배경 : HTTP2.0 으로 성능이 향상되었지만, TCP 기반 위에서 동작하기에, 핸드쉐이크 과정에서의 지연시간과 패킷이 유실되거나 오류가 있을 때 패킷을 재전송하는 HOL이 발생한다. TCP로 인터넷 통신을 하는 것이 문제인 것이다.
프로토콜 변경 : HTTP/1.1 HTTP/2.0의 개념을 유지하지만, 전송 레이어에 TCP 가 아닌 UDP기반인 QUIC(Quick UDP Internet Connections) 프로토콜을 사용한다.
UDP(User Datagram Protocol)은 데이터그램 방식을 사용하는 프로토콜. 패킷의 목적지만 정해지면 중간 경로는 신경쓰지 않는다.
장점
연결 시 레이턴시 감소 (빠른 연결)
암호화와 핸드쉐이크를 동시에 수행해, HTTP/2.0에 비교해 속도 대폭 향상됨
HOLB (Head of Line Blocking) 해결
보안 강화
핸드쉐이크에 대한 QUIC의 새로운 접근 방식으로 기본적인 암호화를 제공하기 때문에 공격을 완화하는 데 도움됨
HTTP 2.0 VS HTTP 3.0?
가장 큰 특징은 TCP가 아닌 UDP(QUIC)를 사용한다는 것이다. QUIC은 Quick UDP Internet Connection의 약자로 UDP를 사용하는 프로토콜이다.
1.연결 레이턴시 감소
기존 TLS+TCP에서는 TLS 연결을 위한 핸드셰이크와 TCP를 위한 핸드셰이크가 각각 발생했다. QUIC에서는 이를 한단계로 줄였다.
TLS+TCP는 세션키를 주고 받고 암호화된 연결을 성립한 후에 세션키와 함께 데이터를 교환한다.
반면에 QUIC는 프로토콜 내에 TLS를 포함하여 데이터 전달과 암호화 절차가 동시에 수행된다.
2.패킷 손실 감지에 걸리는 시간 단축
TCP는 송신 측이 패킷을 보낸 후 타이머를 사용해 일정 시간 동안 응답이 오지 않으면 패킷이 손상되었다고 판단해 재전송 한다.
이때 문제는 TCP가 타임아웃을 언제 낼 것인가를 동적으로 계산해야 한다.
패킷 재전송 시 ACK를 받았을 때 첫 번째로 보낸 패킷의 ACK인지 두 번째로 보낸 패킷의 ACK인지 확인해야 한다.
이를 재전송 모호성이라고 한다. QUIC는 헤더에 별도의 패킷 번호 공간을 부여해 패킷 손실 감지에 걸리는 시간을 단축한다.
3.클라이언트의 IP가 바뀌어도 연결 유지
TCP는 발신지 IP, 발신지 port, 수신지 IP, 수신지 port로 연결을 식별해 클라이언트 IP가 바뀌면 연결이 끊어져 버린다.
이는 다시 연결을 생성하기 위해 3 way hand shake를 다시 해야하고, 레이턴시가 또 다시 발생된다.
요즘같이 모바일로 인터넷을 사용하는 경우 wifi에서 셀룰러로 전환될 때 클라이언트 IP 전환되는 경우가 많아 문제가 심각해진다.
QUIC는 connection ID사용해 서버와 연결을 생성한다.
이는 클라이언트 IP와는 전혀 무관하기 때문에 클라이언트 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다.
Last updated