[Network] HTTP 프로토콜의 발전 (HTTP 1.1 vs HTTP2) 그리고 구글(HTTP3, QUIC)

HTTP 의 성능개선이 어떤식으로 이루어졌는지 알아보자..! 🧐

 

[Network Layer]

HTTP 는 Application Layer(5th Layer) 의 프로토콜이며, TCP/UDP는 Transport Layer(4th Layer) 의 프로토콜이다.

자세한 내용은 아래의 포스팅을 참조하길 바란다.

 

[Network] 네트워크 통신의 기본 구조 ( OSI 7 Layer, TCP/IP)

 

---

 

# HTTP 1.0 의 핵심 (with TCP)

 # Short-lived Connection

   

   하나의 커넥션에는 하나의 요청과 하나의 응답만 있어야 함.   

   즉, Request 의 갯수만큼 매번 새로운 Connection을 해야함.

   

   Connection 마다 TCP 의 특징인 3-way, 4-way handshaking 의 로직이 발생 (성능저하)

   서버 또한 매번 Connection 로직을 실행하기에 서버에도 부하가 발생

 

---

 

# HTTP 1.1 의 핵심 (with TCP)

 # Persistent Connection

   timeout 헤더를 추가하여, 지정한 timeout 동안 Connection을 닫지 않는다.

 

 # Pipe-Lining

   HTTP 1.0 은 Request를 던졌으면 꼭 Response 를 받는 구조로 설계됨

   선행되는 Request의 응답시간이 길 때, 이어지는 Request 들은 기다리고 있었어야 됬음

 

   이를 해결하기 위해 응답을 기다려야만 하는 다음이 진행되는 로직을 제거하고, Request들을 바로바로 보내어 쌓아버림

   그러면 서버는 Request 의 순서에 맞게 Response 를 내려줌 (Head of Line Blocking 발생)

 

 

 

[문제점]

 ** Head of Line Blocking

  서버에서 순서대로 Response 를 내려주기 때문에

  선행되는 Request의 처리시간이 길면,

  이어지는 Request 들은 처리시간이 짧은데도 불구하고, 무작정 waiting

 

 ** Request 의 헤더 구조 중복

  특정 헤더만 다르고 다른 헤더는 다 같음에도 불구하고

  헤더구조를 전체 다 포함해야되서 데이터 크기가 컸었음

 

---

 

# HTTP 2의 핵심 (with TCP) from 2015

 

 # Binaray Framing & Mutil-plexed Stream (Head of Line Blocking 해결)

  하나의 Request 는 크게 Header 와 Data 의 두개의 Frame 으로 구성 (각각 여러개의 Frame으로 구성될 수 있음)

 

  Request 헤더와 데이터를 binary 형식으로 Frame 단위로 만들어 따로따로 전송 (파싱, 전송속도 up)

  Response 도 서버에서 Frame 단위로 전송

 

  Request를 먼저 분할된 Frame을 서버에 전송을 하여, 서버는 하나씩 먼저 도착하는 Frame을 처리하며 전체를 조립

 

Frame들을 하나의 Stream을 통하여 전송한다.

 

  ** TCP Head of Line Blocking

  하지만, TCP를 사용하기에 한 개의 연결당 한 개의 스트림만 존재하여

  하나의 Frame에 오류가 생겨 지연되면 뒤이은 Frame들도 작업을 하지 못한다

  

 # Stream Prioritization

  리소스의 우선 순위가 설정가능해져, 데이터를 우선순위대로 받아볼 수 있음 (리소스 의존관계를 해결)

 

 # Server Push 

  아직 클라이언트가 요청하지 않았음에도, 자체적으로 판단하여 리소스를 미리 클라이언트에게 내려줌

  (promise 를 이용해서 작동하는 듯 하다. 자세한 로직은 promise 키워드로 검색하시면 될 듯 하다.)

 

 # Header Compression

  중복을 검출하여, 변경된 부분만 detecting 후, 중복을 제거하여 헤더정보를 압축하여 보냄

  헤더의 크기가 85% 가량 줄어 듦.

 

 

---

 

# HTTP 1.1 과 HTTP 2 속도 차이를 눈으로 보여주는 유튜브 영상

 

 

 

---

# HTTP3 (with QUIC) by Google

 구글은 HTTP3 와 QUIC을 혼용하여 사용하고 있다.

 구글페이지 로딩시간 평균 3% 단축과 유튜브 시청 버퍼링 평균 30% 개선의 성능을 보이고 있다. 

 # QUIC (from UDP)

  # Connection UUID (식별자)

    Transport Layer 의 프로토콜인 UDP를 변형하여, 첫 연결에 성공하면 성공한 설정을 캐싱하여 다음연결때 식별자로 사용

   

    두번째 연결부터는 TCP 처럼 매번 Hand-shaking이 일어나지 않고 식별자 확인 후 바로 연결되는 것이 포인트..!

   

    인터넷환경의 변경(와이파이 -> LTE)에도 기존의 연결은 계속유지 (Connection UUID 때문) (TCP는 처음부터 다시 받아온다)

 

  # 각 Request 마다 독립 Stream 사용 (병렬적 Request 요청) 

   TCP 근본문제인 TCP Head of Line Blocking 해결 (향상된 멀티플렉싱) 

 

---

 

# Reference

HTTP의 진화 - HTTP | MDN