웹에 날개를 달아주는 웹 성능 최적화 기법 Chapter8

웹에 날개를 달아주는 웹 성능 최적화 기법

  • 본 책을 읽고 책의 내용을 간략하게 정리한 글입니다.

Chapter 8. 웹 프로토콜 최적화

HTTP의 발전

HTTP/1.1
  • GET, POST 외에도 PUT, DELETE 메서드 추가됨
  • Via 헤더를 사용해 중계 서버 정보를 공유하고 Accept 헤더로 클라이언트가 어떤 형식의 컨텐츠를 지원하는지 미리 서버에 알려줄 수 있게 됨
  • 하나의 TCP 연결을 재사용해 많은 컨텐츠를 전달할 수 있는 지속적 연결 기술 추가
    • 파이프라이닝 기술
  • 서버가 하나의 요청에 응답을 지연하면 나머지 모든 요청 역시 지연되는 문제
    • HOL (Head-Of-Line blocking) 문제
HTTP/2
  • HTTP/1.1의 헤더와 페이로드가 HTTP/2부터 이진 형태의 프레임으로 추상화됨
  • HTTP/1.1의 기능에 멀티플렉싱, 스트림 우선순위 설정, 헤더 압축 (HPACK), 서버 푸시 같은 새로운 프로토콜 최적화 기능 추가
  • HTTP/2 에서는 HOL 문제를 해결할 수 있었지만 HTTP의 상위 프로토콜인 TCP의 HOL 문제는 해결하지 못함
HTTP/3
  • 새로운 인터넷 프로토콜인 QUIC 사용
    • QUIC의 가장 큰 특징은 UDP (User Datagram Protocol)을 사용한다는 점
  • HTTP/3은 아직까지는 실험적인 프로토콜이지만 HTTP의 가장 최근 버전인 만큼 강력한 기능과 최적화가 추가됨

HTTP/2의 최적화 기술

  • HTTP/2의 가장 큰 목표는 클라이언트와 서버가 컨텐츠를 주고받는 시간을 줄이고, 서버 응답이 느린 컨텐츠가 다른 정상적인 컨텐츠의 전달을 방해하지 않도록 하는 것
  • 기존 문자열 방식의 프로토콜을 이진 프레임으로 바꾸어 프로토콜을 좀 더 가볍고 유연하게 만듬
  • HTTP 요청과 응답에 포함된 중복 헤더 값들을 걸러내고, 전송해야 하는 값을 기존과 다르게 압축해 해더의 크기를 최소화
HTTP/2의 이진 프레임
$ curl -s -v www.example.com
(중략)
> GET / HTTP/1.1
> Host: www.example.com
> User-agent: curl/7.67.0
> Accept: */*

< HTTP/1.1 200 OK
< Date: Wed, 08 Jan 2020 11:17:38 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=ISO-8859-1
< Server: gws
(중략)
< Accept-Ranges: none
< Vary: Accept-Encoding
< Transfer-Encoding: chunked

<html>
(중략)
</html>
  • 위 예제를 보면 응답에 사용된 HTTP 버전 및 RFC에 정의된 응답 코드, 응답 내용에 대한 정보가 담긴 헤더, 실제 HTML이 있는 페이로드로 구성됨
  • HTTP/2에는 기존 HTTP/1.1 버전의 메시지 단위 외에도 프레임(frame), 스트림(stream) 이라는 단위 추가
    • 프레임: HTTP/2 통신망 제일 작은 정보 단위이며 헤더나 데이터 중 하나
    • 메시지: HTTP/1.1 마찬가지로 요청 또는 응답 단위이며 다수의 프레임으로 이루어져 있음
    • 스트림: 클라이언트와 서버 사이 맺어진 연결을 통해 양방향으로 주고받는 하나 또는 복수의 메시지
  • HTTP/2에서는 스트림이라는 단위를 통해 요청과 응답이 하나의 단위로 묶일 수 있는 구조가 만들어짐
  • 스트림에는 고유 번호가 있는데 하나의 요청이 스트림으로 보내지면 그 응답은 요청 스트림과 같은 스트림 번호를 가지며, 클라이언트는 응답 스트림의 번호를 통해 어떤 요청에 대한 응답인지 구분
  • HTTP/2에서 하나의 스트림이 다수의 요청을 포함하고 이에 대한 다수의 응답 정보를 포함하는 구조로, HTTP/1.1 버전보다 동시 요청 및 응답할 수 있는 오브젝트의 개수가 많아짐
  • HTTP/2에서는 하나의 TCP 연결을 통해 다수의 클라이언트 요청과 서버 응답이 비동기 방식으로 이루어지는 멀티플렉싱이 사용됨
    • 이를 통해 HTTP/1.1의 HOL 문제 해결
멀티플렉싱
  • HTTP/1.1의 파이프라이닝 기능을 개선한 것
  • 하나의 TCP 연결상에서 다수의 클라이언트 요청과 서버의 응답이 비동기 방식으로 이루어지는 기술
  • 멀티플렉싱은 스트림을 사용하여 웹 서버에서 나중에 요청받았더라도, 전달할 수 있는 경우 클라이언트에게 먼저 전달하는 구조
헤더 압축
  • 헤더는 클라이언트와 서버가 자신의 정보를 주고받는 값인데 모든 웹 컨텐츠를 요청하고 받을 때마다 같은 정보 값들을 의미없이 반복해서 주고받는 구조적인 문제
  • HTTP/2는 클라이언트와 서버 사이에 가상 테이블을 만들어 동일하고 중복되는 헤더 값들을 테이블에 저장하고 참고하는 방식을 사용해 중복 전달 문제 제거
  • 가상 테이블은 정적 테이블과 동적 테이블로 나눌 수 있음
    • 정적 테이블에는 미리 정의된 자주 사용되는 헤더 필드를 저장
    • 동적 테이블은 클라이언트와 서버가 통신하며 주고받는 값들을 업데이트함
  • 헤더 압축 알고리즘인 HPACK을 사용해 허프만 알고리즘 방식으로 헤더를 압축하여 경량의 데이터를 주고받을 수 있게 됨
서버 푸시
  • HTTP/2에는 클라이언트의 요청이 없어도 서버가 여러 응답을 알아서 보내는 서버 푸시 기능 추가
  • 일반적으로 HTML을 호출한 후 해당 페이지가 호출하는 CSS, 자바스크립트, 이미지 파일 대상이 고정되어 있다면 HTTP/2를 지원하는 웹 서버에 서버 푸시 대상으로 미리 설정할 수 있음

HTTP/3의 최적화 기술

QUIC
  • QUIC은 구글이 개발한 OSI 레이어 중 네 번째 계층에 해당하는 전달 계층 프로토콜
  • QUIC은 UDP를 채택해 TCP의 성능을 개선하려는 기술
  • 전달 속도와 향상과 더불어 클라이언트와 서버의 연결 수를 최소화하고 대역폭을 예상해 패킷 혼잡을 피하는 것이 QUIC의 주요 특징
  • QUIC은 이전에 클라이언트가 한 번이라도 접속했던 서버라면 별도의 정보 교환 없이 바로 데이터를 보내는 기술 (Zero RTT)
HTTP/3의 등장 배경
  • TCP는 성능보다 기능에 초점을 둔 프로토콜
    • 멀티미디어 컨텐츠를 다양한 기기에 빠르게 전달해야 하는 상황에서 TCP의 한계를 극복하고 최적화하는 것이 많은 기업들의 도전 과제
  • HTTP/2에서 프레임을 사용한 멀티플렉싱은 HOL 문제를 해결했지만, TCP 프로토콜 자체의 HOL을 완벽히 해결하지 못함
  • HTTP/3은 새로운 기능 추가보단 QUIC 프로토콜을 사용해 TCP가 가지고 있는 HTTP/2의 단점을 보완하는데 중점을 둠
HTTP/3의 특징
  • HTTP/3의 가장 큰 특징은 TCP/IP 기반 애플리케이션 레이어 프로토콜인 HTTP를 QUIC 위로 위치시켰다는 점
    • 이를 “HTTP over QUIC” (HQ) 라고 함
HTTP/3를 지원하는 제품군
  • LiteSpeed
  • mvfst 라이브러리
  • Cloudflare
새로운 프로토콜 적용 시 고려할 점
  • 보안 취약점과 사례의 부족
    • 넷플릭스와 구글 엔지니어가 HTTP/2의 여러 보안 취약점을 발견, 보안 패치 적용 사례
  • HTTP/1.1이나 HTTP/2 기반 프론트엔드 최적화를 적용한 기업의 최적화 방안 수정
    • 기업에서 도메인 분할 기법을 적용했다면 멀티플렉싱 기반의 HTTP/2나 HTTP/3을 사용했을 때 오히려 성능이 반감될 수 있음
    • 브라우저의 프리페치 기능을 적용한 경우에는 이를 서버 푸시 기능으로 변경해야 할지 기술적으로 판단하고 충분한 성능 비교 테스트를 해야 함
  • 시장의 래퍼런스 부족
    • QUIC와 HTTP/3은 대부분 구글 서비스에 한정되어 있음

웹에 날개를 달아주는 웹 성능 최적화 기법, 강상진, 윤호성 저, 루비페이퍼 출판