HTTP 1.1과 HTTP 2.0

목차

1. HTTP 1.0의 문제점
2. HTTP 1.1
   • HTTP 1.0 문제점 해결 방식
   • 문제점
3. HTTP 2.0

1. HTTP 1.0의 문제점

• 하나의 연결당 하나의 요청만을 처리하였다.
• → 이것의 문제점은 하나의 요청을 하고 응답을 받을 때 연결이 끊어지고, 다시 요청을 하려면 서버와 다시 연결해야 한다는 것이다. → 요청마다 연결을 해야하는 것이고, 연결을 하기 위해선 TCP 3-handshake를 수행해야 했기 때문에 RTT(Round Trip Time)가 증가하고 그로 인한 네트워크 지연이 생긴다.

2. HTTP 1.1

1. HTTP 1.0 문제점 해결 방식

• Persistent Connection
  • 한번 3 way handshake를 통해 연결된 TCP 연결을 재활용하는 원리이다.
  • 연결을 끊지 않고 재활용하여 요청시마다 발생하는 비용을 아낄 수 있게 되었다.
  • 만약 연결을 해제하고 싶다면 Connection: close라는 명시적 헤더를 이용해 특정 연결에 대한 해제를 진행할 수 있다.
  → 이로 인해 하나의 연결로 다수의 요청과 응답을 처리할 수 있게 만들어 준다.

 

• HTTP Pipelining
  • Persistent Connection을 전제로 한다.
  • 클라이언트와 서버간 매번 발생하는 요청과 응답의 효율성을 개선하기 위해 만들어진 기능
  • Pipelining은 모든 요청에 대한 응답을 기다리지 않고, 여러 개의 HTTP요청을 이미 연결된 하나의 TCP를 통해 계속해서 다음 요청을 하는 원리로 작동된다.

1. HTTP 1.1 문제점

• HOL(Head Of Line) Blocking
  • 요청하는 데이터의 크기는 제각각인데, 첫 번째로 요청한 데이터가 용량이 큰 데이터라면, 두 번째, 세 번째 데이터가 아무리 빨리 처리되어도 우선순위 원칙에 따라 첫 번째 데이터의 응답 속도가 늦어지면 후 순위에 있는 데이터 응답속도도 덩달아 늦어지게 되는 것이다.
  • pipelining을 통해 동시 요청을 하여 시간을 감축 시켰지만, FIFO(선입선출) 원칙으로 인한 문제점이 발생하는 것이다.

• RTT(Round Trip Time)
  • RTT란, 요청(SYN)을 보낼 때부터 요청에 대한 응답(SYN+ACK)을 받을 때까지의 왕복 시간을 말한다.
  • 아무리 헤더에 keep-alive를 추가해 연결을 유지해도 결국 TCP상에서 동작하는 HTTP특성상 Handshake가 반복적으로 일어나게 되어 불필요한 RTT가 증가할 수 밖에 없고 그로 인해 네트워크 지연을 초래한다.
• 무거운 헤더 구조와 중복
  • HTTP 1.1의 헤더에는 많은 메타정보들이 저장되어 있다. 도메인에 설정된 cookie정보도 매 요청시 마다 헤더에 포함되어 전송된다. 그렇기에 헤더는 많은 데이터를 차지하고 있고, 그래서 전송하려는 값보다 헤더 값이 더 큰 경우가 많았다.
  • Persistent Connection 내에서 주고 받는 연속된 요청 데이터가 중복된 헤더 값을 가지고 있는 경우가 많아서 쓸데없는 메모리 자원도 낭비하게 되는 문제가 있다.

3. HTTP 2.0

• HTTP 2.0은 기존 HTTP 1.1 버전의 성능 향상에 초점을 맞춘 프로토콜이다.
• HTTP 1.1은 한번에 하나의 파일만 전송이 가능하였다. 비록 Pipelining기술이 있었지만, 여러 파일을 전송할 경우 HOL문제가 발생하였다.
• 그래서 HTTP 2.0에서는 여러 파일을 한번에 병렬로 전송하는 방식으로 문제를 해결하였다.

1. Binary Framing Layer
   • HTTP 메시지가 1.1에서는 text로 전송되었던 것과 달리, 2.0에서는 binary frame로 인코딩되어 전송된다는 점이다.
   • 기존 text방식으로 HTTP메시지를 보내는 방식은, 본문은 압축이 되지만 헤더는 압축이 되지 않고, 헤더 중복값이 있다는 문제 때문에 binary로 변경하였다.
   • 앞서 HTTP 헤더에 대해서 Header와 Body를 \\r 혹은 \\n 과 같은 개행문자로 구분했는데 이번 HTTP 2.0에서 부터는 Layer로 구분된다.
   → 이로 인해 데이터 파싱 및 전송 속도가 증가하였고 오류 발생가능성이 줄어들었다.
2. Stream과 Frame 단위
   • 기존 HTTP 요청과 응답은 모두 Text로 된 메시지 단위로 구성되어 있었다.
   • HTTP 2.0이 되면서 메시지라는 단위 외에 Frame, Stream이라는 단위가 추가되었다.
     • Frame : HTTP 2.0에서 통신의 최소 단위이며, Header 혹은 Data가 들어있다.
     • Message : 기존 HTTP와 마찬가지로 요청 혹은 응답의 단위이다. 다수의 Frame으로 이루어져 있다.
     • Stream : 연결된 Connection 내에서 양방향으로 Message를 주고 받는 하나의 흐름이다.
   → HTTP 요청을 여러 개의 Frame들로 나누고, 이 Frame들이 모여 요청/응답 Message가 되고, Message는 특정 Stream에 속하게 되고, 여러 개의 Stream은 하나의 Connection에 속하게 되는 구조이다.

→ 하나의 Connection에서 여러 개의 Stream이 병렬적으로 처리된다. 그렇기에 동시에 Stream이 열리는 것이므로 속도가 빠르다.

 

3. Multiplexting

• 위에서 설명한 그림과 같이 HTTP 헤더 메시지를 binary형태의 프레임으로 나누고 하나의 커넥션으로 동시에 여러 개의 메시지 스트림을 응답 순서에 상관 없이 주고 받는 것을 말한다.
• 요청 순서에 상관없이 먼저 완료된 순서대로 클라이언트에 전달이 가능하게 만들어 준다.

→ HTTP 1.1의 문제인 HOL을 개선하였다.

→ 네트워크 지연만을 줄여주고, 더욱 효율적으로 사용할 수 있게 만들어 그 결과로 네트워크 비용을 줄여주게 된다.

 

4. HTTP Header Data Compression

• HTTP 메시지의 헤더를 압축하여 전송한다.
• 이전 Message의 헤더의 내용 중 중복되는 필드를 재전송하지 않도록 하여 데이터를 절약할 수 있게 되었다.

→ 위의 그림처럼 Static/ Dynamic table 개념을 사용하여 중복 헤더를 검출하고, 중복된 헤더는 Index 값만 전송하고 중복되지 않은 Header 정보의 값은 호프만 인코딩(Huffman Encoding)기법을 사용하는 HPACK 압축 방식으로 인코딩 처리 하여 전송한다.

[Reference]

https://velog.io/@tnehd1998/HTTP-1.1-vs-HTTP-2.0

https://inpa.tistory.com/entry/WEB-🌐-HTTP-09-HTTP-30-까지-알아보는-통신-기술

https://inpa.tistory.com/entry/WEB-🌐-HTTP-20-통신-기술-이제는-확실히-이해하자