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"와 같은 캐시 제어 헤더의 도입으로 캐싱 메커니즘이 향상되었다.

호스트 헤더

Host: example.com

• HTTP 요청의 일부

• 클라이언트가 웹 서버에게 요청을 보낼 때 해당 요청이 어떤 도메인의 리소스를 타겟으로 하는지를 알려주는 역할

• 이를 통해 하나의 IP 주소에서 여러 개의 도메인 이름을 가진 웹 사이트를 동시에 호스팅 가능

  • host 필드를 통해 가상 사이트 식별

가상 호스팅
하나의 서버에 여러 개의 도메인 이름을 호스팅하는 방식

HTTP 1.0 VS HTTP 1.1

1. 지속성

• HTTP 1.0은 요청하고 수신할 때마다 새로운 TCP 세션을 맺어야 한다.
• 반면, HTTP 1.1부터는 TCP 세션을 한 번만 맺으면 여러 개의 요청을 보내고 응답을 수신할 수 있다.
• 결과적으로 TCP 세션을 처리하는 비용을 줄이고 응답속도를 개선할 수 있게 된다.

2. 파이프라이닝

• HTTP 1.0 환경에서는 요청에 대한 응답이 와야 다음 응답을 보낼 수 있다.
• 반면, HTTP 1.1에서는 요청을 병렬로 처리할 수 있는 파이프라이닝 기능을 지원한다.
• 결과적으로 HTTP 1.1에서는 여러 개의 요청을 처리하는 응답 속도가 훨씬 빨라지게 된다.

3. 호스트 헤더

• 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?

1. 다중화(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가 변경되더라도 기존의 연결을 계속 유지할 수 있다.