NGINX의 HTTP/2 모듈

이 블로그 게시물은 2015년 9월 샌프란시스코에서 개최된 nginx.conf에서 Valentin V. Bartenev가 발표한 프레젠테이션 을 개작한 것입니다.

목차

며칠 전에 우리는 NGINX의 HTTP/2 모듈을 출시했습니다. 이번 강연에서는 새로운 모듈에 대한 간략한 개요를 설명드리겠습니다.

0:20 프로토콜 개요

우선, 새로운 프로토콜을 둘러싼 몇 가지 오해를 풀고 싶습니다.

많은 사람들은 HTTP/2를 HTTP/1의 뛰어나고 뛰어난 후속 버전으로 생각합니다. 저는 이런 의견에 동의하지 않습니다. 그 이유는 다음과 같습니다. HTTP/2는 실제로 HTTP/1을 위한 또 다른 전송 계층일 뿐입니다. 이는 나쁘지 않은데, 그 이유는 애플리케이션을 변경하지 않고도 HTTP/2를 사용할 수 있기 때문입니다. 동일한 헤더로 작동하기 때문입니다. NGINX에서 HTTP/2를 켜면 NGINX가 모든 프로토콜 관련 작업을 대신 처리해줍니다.

하지만 HTTP/2는 마법이 아닙니다. 장점도 있고 단점도 있죠. 잘 동작하는 사용 사례도 있고, 잘 동작하지 않는 시나리오도 있습니다.

1:40 HTTP/2의 주요 특징

HTTP/2는 SPDY에 기반을 두고 있고 매우 유사한 프로토콜이기 때문에 SPDY의 새로운 버전이라고 생각할 수 있습니다. SPDY는 몇 년 전 Google에서 웹 콘텐츠 전송을 가속화하기 위해 개발한 프로토콜입니다.

NGINX는 이미 2년 동안 SPDY를 지원해 왔으므로 SPDY 모듈을 사용하여 HTTP/2의 장점을 확인할 수 있습니다. 일부 사람들은 HTTP/2가 SPDY 3.1의 세련된 버전일 뿐이라고 말합니다.

SPDY에 대해 잘 모르시는 분들을 위해 몇 가지 핵심 사항을 설명드리겠습니다. 이러한 주요 사항은 HTTP/2에도 해당합니다. 왜냐하면 이 둘은 기본적으로 동일한 프로토콜이지만 세부 사항에는 약간의 차이가 있기 때문입니다.

첫 번째 핵심은 프로토콜 자체가 이진법이라는 것입니다. 저는 바이너리 프로토콜을 좋아합니다. 코딩하기 쉽고 좋은 바이너리 프로토콜은 성능상 이점이 있기 때문입니다. 하지만 저는 이러한 접근 방식의 단점도 알고 있습니다.

3:08 HTTP/2 내부 – 바이너리

HTTP/2 요청은 다음과 같습니다. 꽤 멋진 것 같고, 보시다시피 디버깅하기가 매우 쉽습니다. 아니, 농담이에요. 디버깅하기 어려워요. 이것이 이진 프로토콜의 단점 중 하나입니다.

요청을 디코딩하기 위해 도구를 사용해야 할 수도 있고... 때로는 도구가 손상되었거나 도구가 비트에 숨겨진 모든 세부 정보를 표시하지 못할 수 있으므로 바이너리를 수동으로 디버깅해야 할 수도 있습니다.

다행히도 대부분의 경우 NGINX에 HTTP/2를 넣어두면 바이너리 특성을 전혀 다룰 필요가 없습니다. 다행히도 대부분의 요청은 기계가 처리하게 될 겁니다. 기계는 사람보다 이진 프로토콜을 읽는 데 훨씬 능숙합니다.

4:26 HTTP/2 내부 – 멀티플렉싱

HTTP/2의 다음 핵심 포인트는 멀티플렉싱입니다. 여러 연결을 통해 응답과 요청을 별도의 데이터 스트림으로 보내고 받는 대신, HTTP/2는 이를 하나의 바이트 스트림이나 하나의 데이터 스트림으로 다중화합니다. 다양한 요청과 응답에 맞게 데이터를 조각화하고, 각 조각에는 고유한 식별자와 크기 필드가 있습니다. 이를 통해 엔드포인트에서 어떤 데이터가 어떤 요청에 속하는지 판별할 수 있습니다.

여기서 단점은 각 데이터 청크가 자체 식별자, 자체 필드를 가지고 있기 때문에 실제 데이터 외에도 일부 메타데이터가 전송된다는 것입니다. 그래서 약간의 오버헤드가 발생합니다. 결과적으로, 예를 들어 영화를 보는 경우와 같이 데이터 스트림이 하나뿐인 경우 HTTP/2는 좋은 프로토콜이 아닙니다. 왜냐하면 얻는 것이 추가 오버헤드뿐이기 때문입니다.

멀티플렉싱의 이점은 무엇인가요? 멀티플렉싱의 주요 이점은 단 하나의 연결만 사용하므로 새로운 요청을 만들어야 할 때 HTTP/1.x에서 핸드셰이크에 소요되는 시간을 절약할 수 있다는 것입니다.

특히 TLS를 사용하는 경우 이러한 지연은 매우 큰 문제가 됩니다. 이것이 대부분의 클라이언트가 이제 TLS를 통해서만 HTTP/2를 지원하는 이유입니다. 제가 아는 한, 일반 TCP를 통한 HTTP/2 지원 계획은 없습니다. 그만한 이점이 없기 때문입니다. TCP 핸드셰이크는 TLS 핸드셰이크만큼 비용이 많이 들지 않기 때문에 여러 연결을 피함으로써 많은 비용을 절감할 수 없습니다.

7:09 HTTP/2의 주요 기능 – 헤더 압축

HTTP/2의 다음 핵심은 헤더 압축입니다. 매우 큰 쿠키가 있는 경우 요청이나 응답당 수백 바이트를 절약할 수 있지만 일반적으로 대부분의 경우 헤더 압축의 이점을 크게 얻지 못할 것입니다. 왜냐하면, 별도의 요청에 대해 생각하더라도 결국 네트워크에서 패킷 계층을 처리하게 되고, 100바이트를 보내든 100반바이트를 보내든 결국 하나의 패킷으로 끝나기 때문에 크게 문제가 되지 않기 때문입니다.

HTTP/2 헤더 압축의 단점은 상태가 있다는 것입니다. [ 편집기 - 압축/압축 해제 정보를 저장하는 데 사용되는 테이블의 경우] 결과적으로 각 연결에 대해 서버와 클라이언트는 어떤 종류의 상태를 유지해야 하며 이는 HTTP/1 연결에 대한 상태를 유지하는 것보다 훨씬 많은 메모리를 차지합니다. 그러므로 결과적으로 각 HTTP/2 연결은 훨씬 더 많은 메모리를 사용하게 됩니다.

8:40 HTTP/2의 주요 기능 – 우선순위 지정

HTTP/2의 마지막 핵심 사항은 우선 순위 지정 방식입니다. 이는 멀티플렉싱으로 인해 발생하는 문제를 해결합니다. 연결이 하나뿐인 경우 파이프도 하나뿐이며, 이 파이프에 다음에 어떤 응답을 넣을지 신중하게 결정해야 합니다.

HTTP/2에서는 우선순위 지정이 선택 사항이지만, 우선순위 지정이 없으면 성능 면에서 큰 이점을 얻을 수 없습니다. NGINX의 HTTP/2 모듈은 우선 순위 지정을 완벽하게 지원하며, 가중치 기반 우선 순위와 종속성 기반 우선 순위를 지원합니다. 지금까지 살펴본 바에 따르면 현재 우리는 HTTP/2를 가장 빠르게 구현한 상태입니다. HTTP/2의 핵심은 다음과 같습니다.

10:06 HTTP/2의 역사

HTTP/2의 역사를 간략하게 설명한 슬라이드입니다. 매우 간단하죠. HTTP/2가 실제로 어떻게 작동하는지 살펴보겠습니다.

10:16 테스트 페이지

다양한 네트워크 조건에서 HTTP/2가 어떻게 작동하는지 이해하기 위해 일반적인 웹 페이지에서 몇 가지 벤치마크를 수행했습니다. 이건 제가 Github에서 찾은 HTTP/2 페이지입니다. 리소스가 얼마나 많은지 볼 수 있고, 각 리소스의 크기도 볼 수 있습니다. 저는 이것이 전형적인 장소를 잘 대표한다고 생각합니다.

10:52 테스트 환경

테스트를 재현하고 싶으시다면, 여기에 제 테스트 환경이 있습니다.

11:02 DOM 로드

그리고 제가 얻은 결과는 다음과 같습니다. X축에는 다양한 네트워크 지연 시간이 밀리초 단위의 왕복 시간(RTT)으로 시뮬레이션되었고, Y축에는 다운로드 시간도 밀리초 단위로 측정되었습니다. 그리고 이 테스트는 페이지의 모든 리소스가 완전히 로드될 때의 페이지 로딩 시간을 측정하는 것입니다.

그래프에서 낮은 대기 시간의 경우 HTTP, HTTPS, HTTP/2 간에 큰 차이가 없다는 확실한 추세를 볼 수 있습니다. 대기 시간이 길어질수록 일반 HTTP/1.x가 가장 빠른 선택임을 알 수 있습니다. HTTP/2는 두 번째이고 HTTPS는 가장 느립니다.

11:48 첫 번째 그림

"첫 번째 그림" 시간은 어떻게 되나요? 많은 경우, 이는 사용자 관점에서 가장 중요한 지표입니다. 이는 사용자가 화면에서 실제로 무언가를 볼 때이기 때문입니다. 많은 경우, 페이지가 완전히 로드되는 데 걸리는 시간은 그다지 중요하지 않지만 사용자가 무언가를 보는 데 걸리는 시간은 매우 중요합니다.

여기에서도 우리는 같은 추세를 볼 수 있지만, 우리 테스트에서 흥미로운 점은 30ms에서 250ms의 중간 범위의 지연 시간에서 HTTP/2가 일반 HTTP보다 약간 빠르다는 것입니다. 하지만 차이는 아주 작습니다.

12:45 구성

그럼, 이것이 우리의 벤치마크였고, 이제 HTTP/2와 NGINX를 구성하는 방법에 대해 이야기해 보겠습니다.

실제로는 매우 간단하죠. listen 지시문에 http2 매개변수를 추가하기만 하면 됩니다. 아마도 여기서 가장 복잡한 단계는 최신 버전의 OpenSSL을 얻는 것입니다. HTTP/2에는 ALPN [ Application‑Layer Protocol Negotiation ] 확장이 필요하고 ALPN 확장은 OpenSSL 1.0.2에서만 지원되기 때문입니다.

또한 우리는 현재 대부분 클라이언트에서 작동하는 HTTP/2용 NPN[ Next Protocol Negotiation ]을 구현했지만, SPDY가 2016년 초에 지원 중단됨에 따라 NPN에 대한 지원이 제거될 예정입니다. 즉, 현재 많은 Linux 배포판에 포함된 OpenSSL 버전과 함께 HTTP/2를 사용할 수 있지만, 가까운 미래에 작동이 중단될 것이라는 점을 염두에 두어야 합니다.

그럼, HTTP/2를 위한 NGINX 구성에 대한 내용은 모두 끝났고 제 프레젠테이션은 여기서 마무리하겠습니다. 감사합니다.

[ HTTP/2 모듈 에 대한 참조 문서 ]

질문과답변

큐: 업스트림 측에서도 HTTP/2를 지원하실 건가요, 아니면 클라이언트 측에서만 HTTP/2를 지원하실 건가요?

에이: 현재 클라이언트 측에서는 HTTP/2만 지원합니다. proxy_pass를 사용하여 HTTP/2를 구성할 수 없습니다. [ 편집자 - 이 게시물의 원래 버전에서는 이 문장이 " proxy_pass를 사용하여 HTTP/2를 구성할 수 있습니다."로 잘못 표기되었습니다. 이로 인해 혼란이 생겨 죄송합니다. ]

하지만 백엔드 측에서 HTTP/2의 요점은 무엇입니까? 벤치마크에서 볼 수 있듯이 업스트림 연결과 같은 저지연 네트워크의 경우 HTTP/2에는 큰 이점이 없습니다.

또한 NGINX에는 keepalive 모듈이 있으며, keepalive 캐시를 구성할 수 있습니다. HTTP/2의 주요 성능 이점은 추가 핸드셰이크를 제거하는 것이지만, Keepalive 캐시로 이미 이 작업을 수행하는 경우 업스트림 측에 HTTP/2가 필요하지 않습니다.

추가 HTTP/2 리소스

• 웹 애플리케이션 개발자를 위한 HTTP/2 – HTTP/2에 대해 알아야 할 모든 것을 다루는 백서(PDF)
• 고성능 브라우저 네트워킹 - Google의 Ilya Grigorik이 쓴 전자책 특별판
• HTTP/2의 새로운 기능은 무엇입니까? – NGINX 웨비나에서 주요 기능을 설명하고 구현 조언을 제공합니다.
• HTTP/2 성능 개선을 위한 7가지 팁 – 블로그 게시물
• HTTP/2를 지원하는 브라우저 목록 – 사용할 수 있나요? 웹사이트

귀하의 환경에서 NGINX Plus와 함께 HTTP/2를 시도할 준비가 되셨습니까? 오늘 무료 30일 체험판을 시작하거나, 사용 사례에 대해 논의하기 위해 저희에게 문의하세요 .