<이 블로그 게시물은 지난 9월 샌프란시스코에서 열린 nginx.conf 2015에서 발렌틴 바르네프(Valentin V.">)의 프레젠테이션을 각색한 것입니다..
목차
| 0:20 | 프로토콜 개요 |
| 1:40 | HTTP/2의 주요 특징 |
| 3:08 | HTTP/2 인사이드 - 바이너리 |
| 4:26 | HTTP/2 인사이드 - 멀티플렉싱 |
| 7:09 | HTTP/2의 주요 기능 - 헤더 압축 |
| 8:40 | HTTP/2의 주요 기능 - 우선순위 지정 |
| 10:06 | HTTP/2의 역사 |
| 10:16 | 테스트 페이지 |
| 10:52 | 테스트 환경 |
| 11:02 | DOM 로드 |
| 11:48 | 첫 번째 페인팅 |
| 12:45 | 구성 |
| 14:20 | Q&A |
며칠 전 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.5바이트를 보내든
결국 하나의 패킷이 되기 때문에 크게 중요하지 않기 때문입니다.
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 첫 번째 페인팅
"첫 번째 페인팅" 시간은 어떨까요? 많은 경우 사용자가 실제로 화면에 무언가를 보는 시간이기 때문에
사용자 관점에서 가장 중요한 지표입니다.
대부분의 경우 페이지가 완전히 로드되는 데 걸리는 시간은 중요하지 않지만
사용자가 무언가를 보는 데 걸리는 시간은 매우 중요합니다.
이번 테스트에서 흥미로운 점은 30밀리초에서 250밀리초 사이의 중간 범위의 지연 시간에서 HTTP/2가 비록 차이는 매우 작지만
일반 HTTP보다 약간 더 빠르다는 것입니다.
12:45 구성
지금까지 벤치마크에 대해 알아보았으니 이제 HTTP/2와 NGINX를 구성하는 방법에 대해 이야기해 보겠습니다.
사실 매우 간단합니다. listen 지시어에 http2 파라미터를 추가하기만 하면 됩니다.
여기서 가장 복잡한 단계는 아마도 최신 버전의 OpenSSL을 구하는 것일 텐데,
HTTP/2에는 ALPN [애플리케이션 계층 프로토콜 협상] 확장이 필요하고 ALPN 확장은 OpenSSL 1.0.2에서만 지원되기 때문입니다.
또한 현재 대부분의 클라이언트에서 작동하는 HTTP/2용 NPN[다음 프로토콜 협상]을 구현했지만
2016년 초에 SPDY가 더 이상 지원되지 않으므로 NPN에 대한 지원은 제거될 예정입니다.
즉, 현재 많은 Linux 배포판의 일부인 OpenSSL 버전에서 HTTP/2를 사용할 수 있지만
가까운 장래에 지원이 중단될 것이라는 점을 염두에 두어야 합니다.
이상으로 HTTP/2를 위한 NGINX 구성에 대해 설명해 드렸습니다. 감사합니다.
[참조 문서 HTTP/2 module]
Q&A
Q: 업스트림 측에서도 HTTP/2를 지원하나요, 아니면 클라이언트 측에서만 지원하나요?
A: 현재로서는 클라이언트 측에서만 HTTP/2를 지원합니다. proxy_pass로 HTTP/2를 구성할 수 없습니다.
[편집자 주 - 이 글의 원본 버전에서는 이 문장이 " proxy_pass로 HTTP/2를 구성할 수 있습니다."로 잘못 표기되었습니다. 혼란을 드린 점 사과드립니다.]
하지만 백엔드 측에서 HTTP/2의 장점은 무엇일까요? 벤치마크에서 볼 수 있듯이
업스트림 연결과 같이 지연 시간이 짧은 네트워크에서는 HTTP/2의 이점이 크지 않기 때문입니다.
또한 NGINX에는 keepalive 모듈이 있으며, 킵얼라이브 캐시를 구성할 수 있습니다.
HTTP/2의 주요 성능 이점은 추가 핸드셰이크를 없애는 것이지만,
이미 킵얼라이브 캐시를 사용하는 경우 업스트림 측에서 HTTP/2가 필요하지 않습니다.
더 많은 HTTP/2 리소스
- 웹 애플리케이션 개발자를 위한 HTTP/2 - HTTP/2에 대해 알아야 할 모든 것을 다룬 백서(PDF)
- 고성능 브라우저 네트워킹 - Google의 Ilya Grigorik의 특별판 전자책
- HTTP/2의 새로운 기능 - 주요 기능을 설명하고 구현에 대한 조언을 제공하는 NGINX 웨비나
- 7가지 HTTP/2 성능 개선 팁 - 블로그 게시물
- HTTP/2를 지원하는 브라우저 목록 - 사용할 수 있나요? 웹사이트
여러분의 환경에서 NGINX Plus로 HTTP/2를 사용해 볼 준비가 되셨나요?
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
<이 블로그 게시물은 지난 9월 샌프란시스코에서 열린 nginx.conf 2015에서 발렌틴 바르네프(Valentin V.">)의 프레젠테이션을 각색한 것입니다..
목차
며칠 전 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.5바이트를 보내든
결국 하나의 패킷이 되기 때문에 크게 중요하지 않기 때문입니다.
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 첫 번째 페인팅
"첫 번째 페인팅" 시간은 어떨까요? 많은 경우 사용자가 실제로 화면에 무언가를 보는 시간이기 때문에
사용자 관점에서 가장 중요한 지표입니다.
대부분의 경우 페이지가 완전히 로드되는 데 걸리는 시간은 중요하지 않지만
사용자가 무언가를 보는 데 걸리는 시간은 매우 중요합니다.
이번 테스트에서 흥미로운 점은 30밀리초에서 250밀리초 사이의 중간 범위의 지연 시간에서 HTTP/2가 비록 차이는 매우 작지만
일반 HTTP보다 약간 더 빠르다는 것입니다.
12:45 구성
지금까지 벤치마크에 대해 알아보았으니 이제 HTTP/2와 NGINX를 구성하는 방법에 대해 이야기해 보겠습니다.
사실 매우 간단합니다. listen 지시어에 http2 파라미터를 추가하기만 하면 됩니다.
여기서 가장 복잡한 단계는 아마도 최신 버전의 OpenSSL을 구하는 것일 텐데,
HTTP/2에는 ALPN [애플리케이션 계층 프로토콜 협상] 확장이 필요하고 ALPN 확장은 OpenSSL 1.0.2에서만 지원되기 때문입니다.
또한 현재 대부분의 클라이언트에서 작동하는 HTTP/2용 NPN[다음 프로토콜 협상]을 구현했지만
2016년 초에 SPDY가 더 이상 지원되지 않으므로 NPN에 대한 지원은 제거될 예정입니다.
즉, 현재 많은 Linux 배포판의 일부인 OpenSSL 버전에서 HTTP/2를 사용할 수 있지만
가까운 장래에 지원이 중단될 것이라는 점을 염두에 두어야 합니다.
이상으로 HTTP/2를 위한 NGINX 구성에 대해 설명해 드렸습니다. 감사합니다.
[참조 문서 HTTP/2 module]
Q&A
Q: 업스트림 측에서도 HTTP/2를 지원하나요, 아니면 클라이언트 측에서만 지원하나요?
A: 현재로서는 클라이언트 측에서만 HTTP/2를 지원합니다. proxy_pass로 HTTP/2를 구성할 수 없습니다.
[편집자 주 - 이 글의 원본 버전에서는 이 문장이 " proxy_pass로 HTTP/2를 구성할 수 있습니다."로 잘못 표기되었습니다. 혼란을 드린 점 사과드립니다.]
하지만 백엔드 측에서 HTTP/2의 장점은 무엇일까요? 벤치마크에서 볼 수 있듯이
업스트림 연결과 같이 지연 시간이 짧은 네트워크에서는 HTTP/2의 이점이 크지 않기 때문입니다.
또한 NGINX에는 keepalive 모듈이 있으며, 킵얼라이브 캐시를 구성할 수 있습니다.
HTTP/2의 주요 성능 이점은 추가 핸드셰이크를 없애는 것이지만,
이미 킵얼라이브 캐시를 사용하는 경우 업스트림 측에서 HTTP/2가 필요하지 않습니다.
더 많은 HTTP/2 리소스
여러분의 환경에서 NGINX Plus로 HTTP/2를 사용해 볼 준비가 되셨나요?
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
'