• [10분 테코톡] 🧃쿨라임의 HTTP/1.1, HTTP/2, 그리고 QUIC
• [10분 테코톡] 🎃손너잘의 HTTP1.1, HTTP2, 그리고 QUIC
• https://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/
• http://ktword.co.kr/abbr_view.php?m_temp1=3391

---

✅ Overview

HTTP
웹 상에서 클라이언트와 서버 간 통신을 위한 어플리케이션 계층 프로토콜

• 통신을 하기위해서 전송계층을 거쳐야 한다.
• 이론상 HTTP프로토콜은 신뢰성만 보장해주면 전송 계층의 프로토콜로 TCP, UDP를 사용하던 상관 없다고 한다.

대역폭 보다는 레이턴시를 줄이는 방향이 성능향상에 더 중요하다.

---

✅ TCP & UDP

HTTP의 특성을 이해하기 앞서 전송 프로토콜인 TCP, UDP에 대해 살펴보자.

👏 TCP

TCP
3 way handshake를 통해 신뢰성있는 connection을 수립한다.

• 📌 3 way handshake
  • 클라이언트와 서버가 상호간에 데이터를 주고 받을 준비가 되어있다는 합의를 하는 과정
    
• 3 way handshake를 통해 connection을 수립하면 클라이언트는 data를 전송하고 서버는 잘 받았다는 의미로 ack 패킷을 보낸다.
  • 신뢰성 구축에 신경을 많이 쓴 프로토콜이다.

👏 UDP

UDP
받는 쪽에서 데이터를 제대로 받고 있는지조차 고려하지 않은 통신 프로토콜이다.

---

✅ HTTP

HTTP/0.9 ~ HTTP/2.0은 전송 계층의 TCP를 사용한다.

👏 HTTP/0.9

HTTP/0.9
원라인 프로토콜이라고 불린다.

• 매우 간단한 프로토콜이지만 확장하기 어렵다

👏 HTTP/1.0

HTTP/1.0

• 📢 헤더가 생겼다.
  • 응답 메시지, 상태 코드
  • Content-Type이 생김 👉 html 이외의 다른 타입의 파일도 전송이 가능해짐
    
• 📢 하나의 connection에서 1개의 요청과 1개의 응답만 처리할 수 있다.
  • 여러 개의 리소스를 요청하기 위해서 여러 번의 connection을 생성하고 끊는 작업을 반복해야 했다.
    👉 중복 connection 수립 과정으로 인한 레이턴시 발생 (성능 저하)
    👉 서버 부하 비용 증가

✍ TCP의 Slow Start

처음 연결이 수립된 tcp connection이 전송할 수 있는 최대 데이터 크기에 제한을 두고 여러 번 데이터 송수신하면서 한 번에 보낼 수 있는 데이터의 최대 크기를 찾아가는 과정이다.

• 혼잡(Congestion)을 피하기 위한 TCP 알고리즘 중의 하나이다.
• Slow Start을 통해 혼잡한 네트워크 환경에서 패킷 손실을 최소화하며 안전한 데이터 전송이 가능해짐.
• 📢 Slow Start으로 인해 연결 초기에 레이턴시가 발생한다.
  👉 이 문제를 해결하기 위해 tcp connection을 재활용하는 keep alive 헤더를 사용

✍ HTTP/1.0의 Keep Alive 헤더

tcp connection을 서버와 클라이언트가 한번만 사용하고 끊지 않고 연결을 계속 유지하겠다는 의미이다.

• 이를 통해 tcp connection 재활용이 가능하게 되었다.
  • handshake 문제, 느린 연결 문제
• 📢 하지만, HTTP/1.0의 표준이 아니므로 표준 벤더사마다 지원여부가 달랐다. (완벽한 해결방안이 아님)
  👉 dumb proxy 문제 발생

👏 HTTP/1.1

HTTP/1.1
HTTP/1.0의 한계를 극복하기위해서 keep alive 헤더를 사용하지 않고 Persistent Connection 개념을 도입하였다.

• 📌 Persistent Connection
  • 지정한 timeout 시간동안 connection을 닫지 않는 방식이다.
  • 하나의 connection을 열어 두면, 여러 요청이 하나의 connection 안에서 이뤄진다.
    👉 tcp connection을 재활용하는 이점을 가지고 3 way handshake 비용을 감소시켜 HTTP/1.0버전보다 네트워크 사용시간이 줄어들었다.

✍ Pipelining

Pipelining
HTTP의 특성상 서버는 클라이언트에게 받은 요청을 FIFO 방식으로 처리하여 (순서대로 응답하여) 대기 시간이 길어지는 단점이 생긴다. 이를 해결하기 위해 Pipelining 개념이 도입되었다.

• 클라이언트에게서 받은 요청 순서대로 서버가 응답한다.
  (AB 순서로 요청을 보냈을 때, B의 작업이 먼저 완료되어도 응답 순서를 지키기위해 A의 작업이 끝나기 전까지 B의 작업을 응답할 수 없다.)

📢 Pipelining의 문제점

• 📌 Head of Line Blocking 문제점
  • 1번째 요청에 대한 처리 시간이 매우 길어지면 2,3번째 요청은 대기해야한다.
• 📌 Header 구조의 중복 문제점
  • 주고 받는 데이터의 크기가 불필요하게 커졌다..

📢 Multiplexing 흉내

이로 인해 Pipelining 이 아닌 tcp connection을 여러개(6개) 생성하여 Multiplexing을 흉내내는 방식을 고안하여 데이터를 병렬적으로 받을 수 있게 되었다.

• 👉 하지만 다수의 connection을 사용하면서 클라이언트와 서버에 오버헤드가 발생하게 되었다. (대역폭 경쟁 심화)
• 📌 Multiplexing
  • Pipelining과 다르게 요청과 응답의 순서에 구해받지 않고 병렬적 처리가 가능한 방식이다.
  • 단일 tcp connection 안에서 여러 데이터가 섞이지 않게 보내는 기법이다.

👏 HTTP/2.0

HTTP/2.0
기존 HTTP/1.X 버전의 성능 향상에 초점을 맞춘 프로토콜이다.

• 표준의 대체가 아닌 확장 개념이다.
• 2015년도에 등장하여 네이버, 페이스북, 인스타그램에서 사용하는 프로토콜이다.

✍ HTTP/2.0의 특징

📢 #1) HTTP 메시지 전송 방식 변화

어플리케이션 계층에서 바이너리 프레이밍 계층이 생김

• 메시지를 frame 단위로 2개 분할
• 이 2개의 frame을 바이너리로 인코딩하여
  데이터 파싱, 전송속도 향상 및 오류 발생 가능성이 줄어들게 되었다.

클라이언트와 서버의 connection 속에 stream (데이터 양방향 흐름) 안에 frame들로 이뤄진 요청, 응답 메시지가 전송된다.

• 전송되는 데이터에 특별한 식별자를 붙여주었다고 생각하면 된다.
• 이를 통해 HTTP/2.0 에서 진정한 Multiplexing이 가능하게 되었다.

데이터가 frame 단위로 쪼개져 메시지간의 순서가 사라지게 되었다.

• 먼저 도착한 frame부터 조립되어 요청과 응답의 순서가 무의미해졌다
  👉 이를 통해 Head of Line Blocking 문제가 해결되었다.

📌 TCP Head of Line Blocking 현상

네트워크에서 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상이다.

• tcp 프로토콜 자체에 존재하는 현상이다.
• 발생하는 이유
  • tcp 는 안전성있는 데이터 송수신을 지향하기 때문에 손실된 데이터를 재송신해야한다.
    하지만 그 뒤 순서의 데이터는 앞 데이터의 재송신 전까지 대기해야한다.

📢 #2) Stream Prioritization

먼저 전송하고 싶은 stream에 가중치를 두어 리소스의 전송 우선순위를 설정할 수 있다.

📢 #3) Server Push

클라이언트가 요청하지 않은 파일을 알아서 서버가 응답해준다.

• 클라이언트가 html 파일만 요청했지만, 서버는 js, css파일까지 응답해준다.

📢 #4) Header Compression

헤더의 크기를 줄여 페이지 로드 시간이 감소 되었다.

• 📌 static dynamic table 개념
  • 중복된 정보는 table의 index만 남기고 중복되지 않은 정보는 Huffmann 인코딩을 하여 헤더를 압축하였다.
    👉 헤더 크기가 85% 감소하고 페이지 로드시간이 HTTP/1.X버전보다 눈에 띄게 감소하였다.

---

✅ QUIC

구글에서 만든 전송 계층 프로토콜로 udp를 기반으로 두고 있다.

✍ udp를 택한 이유

tcp는 신뢰성을 확보하지만, 기능이나 구조가 이미 가득 차있기에, 그 상태에서 발생하는 지연을 줄이기 힘든 구조이다.

udp는 tcp에 비해 별도 기능이 없다

• 개발자가 원하는 기능을 구현할 여지가 충분하다.
• 이를 바탕으로 tcp의 지연을 줄이면서 신뢰성을 확보하는 quic 프로토콜을 만들게 되었다.
  • 구글은 데이터 전송의 신뢰성 기능을 어플리케이션 계층에 구현하였다.

✍ quic의 이점

📢 #1) 데이터 전송 속도 향상

첫 connection 설정에서 필요한 정보와 함께 데이터를 같이 전송하여 connection 성공시, 설정을 캐싱하여 다음 connection때 handshake 없이 바로 데이터 전송이 가능해진다.

• 📌 Connection UUID
  
• 클라이언트가 Connection UUID를 가지고 있으면 connection을 재수립할 필요가 없어진다.
  • ip가 변경되거나 wifi에서 LTE로 변경되어도 기존의 connection이 계속 유지된다.

📢 #2) 보안 측면 강화

• TLS
  👉 데이터 암호화 프로토콜이 기본적으로 적용되어있다
• Source Address Token 을 필요에 따라 발급
  👉 IP Spoofing / Replay Attack을 방지

📢 #3) 향상된 Multiplexing

• tcp 를 이용한 http/2.0 stream은 하나의 tcp chain에서 데이터들이 엮인 상태에서 전송이 된다
• quic을 이용한 http/3.0 stream은 하나의 connection 안의 독립 stream으로 인해 Multiplexing이 향상되었다.
  👉 하나의 stream에서 병목현상이 생기더라도 문제가 발생한 stream만 멈추고 다른 stream에 영향을 미치지 않는다.
  👉이를 통해 head of line blocking 문제를 해결하고 레이턴시를 줄여 성능향상을 이뤄내었다.
  

👏 HTTP/3.0

2018년 10월에 quic 프로토콜을 바탕으로 한 HTTP/3.0 버전이 나왔다.

• 구글, 유투브는 이미 사용중이다.

---

✅ 정리