HTTP/2 성능을 위한 6가지 팁
오래된 하이퍼텍스트 전송 프로토콜(HTTP) 표준이 이제 업데이트 되었습니다. HTTP/2 표준은 2015년 5월에 승인되었으며 현재 브라우저와 웹 서버(NGINX Plus 및 NGINX Open Source 포함)에서 구현되고 있습니다.
HTTP/2는 Google의 SPDY 프로토콜을 기반으로 구축되었으며, SPDY는 Google Chrome 브라우저에서 지원이 중단될 때까지 옵션으로 남아 있습니다. NGINX는 SPDY의 초창기 지원자였으며 이제 HTTP/2에서도 같은 역할을 하고 있습니다. NGINX팀이 제공하는 HTTP/2 for Web Application Developers (PDF) 백서에서는 HTTP/2에 대해 설명하며, 이것이 SPDY를 기반으로 어떻게 구축되었는지와 구현 방법에 대해 자세히 설명합니다.
HTTP/2의 주요 기능은 SPDY와 동일합니다.
- HTTP/2는 텍스트가 아닌 바이너리 프로토콜로 더 작고 효율적입니다.
- 각각 하나의 파일을 전달하는 다중 연결 대신 도메인당 단일 다중 연결을 사용합니다.
- 헤더는 특별히 제작된 HPACK 프로토콜(SPDY에서와 같이 gzip이 아닌)으로 압축됩니다.
- HTTP/2는 브라우저가 가장 필요한 파일을 먼저 요청할 수 있도록 복잡한 우선순위 지정 체계를 갖추고 있으며, 이는 NGINX에서 완벽하게 지원됩니다.
이제 HTTP/2로 진행할지 여부를 결정해야 합니다. 그 중 일부는 HTTP/2를 최대한 활용하는 방법을 아는 것입니다. 이 포스트는 의사결정 및 구현 프로세스의 성능 관련 측면을 안내합니다. HTTP/2 성능에 대한 다음 6가지 팁을 확인하십시오.
목차
1. 지금 HTTP/2가 필요한지 결정
2. HTTP/2 및 TLS 종료
3. HTTP/1.x 최적화 사용 식별
4. HTTP/2 배포
5. HTTP/1.x 최적화 검토
6. 스마트 샤딩 구현
7. 결론
1. 지금 HTTP/2 가 필요한지 결정
웹 애플리케이션 개발자를 위한 HTTP/2 (PDF)에 대해 설명하는 것처럼 HTTP/2 구현은 쉽습니다. 그러나 HTTP/2는 만병통치약이 아닙니다. 일부 웹 애플리케이션에는 유용하지만 다른 웹 애플리케이션에는 덜 유용합니다.
TLS(Transport Layer Security)를 사용하는 경우, HTTP/2를 사용하면 웹 사이트 성능이 개선될 가능성이 높습니다. 그러나 SSL/TLS를 사용하지 않은 경우, HTTP/2를 사용하기 전에 TLS 지원을 추가해야 합니다. 이 경우, TLS를 사용하는 것에 따른 성능 저하가 HTTP/2 사용의 성능 이점과 대략 상쇄될 것으로 예상할 수 있지만, 구현 결정을 내리기 전에 귀사의 사이트에 대해 이를 확인하는 것이 좋습니다.
다음은 HTTP/2의 5가지 주요 잠재적 이점입니다.
- 서버당 단일 연결 사용 – HTTP/2는 파일 요청당 하나의 연결 대신 서버당 하나의 연결을 사용합니다. 이것은 TLS 연결이 생성하는 데 특히 시간이 많이 걸리기 때문에 TLS에 특히 유용한 시간 소모적인 연결 설정의 필요성이 훨씬 적다는 것을 의미합니다.
- 더 빠른 TLS 성능 제공 – HTTP/2는 단 한 번의 값비싼 TLS 핸드셰이크만 필요하며 멀티플렉싱은 단일 연결을 최대한 활용합니다. HTTP/2는 또한 헤더 데이터를 압축하며 파일 연결과 같은 HTTP/1.x 성능 최적화를 피하면 캐싱 작업을 보다 효율적으로 수행할 수 있습니다.
- 웹 애플리케이션 단순화 – HTTP/2를 사용하면 앱 개발자와 클라이언트 디바이스가 더 열심히 작동하도록 만드는 HTTP/1.x “최적화”에서 벗어날 수 있습니다.
- 혼합 웹 페이지에 적합 – HTTP/2는 HTML, CSS, JavaScript 코드, 이미지 및 제한된 멀티미디어가 혼합된 기존 웹 페이지에서 빛을 발합니다. 브라우저는 파일 요청의 우선 순위를 지정하여 페이지의 주요 부분을 가장 먼저 빠르게 표시할 수 있습니다.
- 더 강력한 보안 지원 – HTTP/2는 TLS로 인한 성능 저하를 줄임으로써 더 많은 웹 애플리케이션이 TLS를 사용할 수 있도록 하여 사용자에게 더 큰 보안을 제공합니다.
그리고 다음과 같은 다섯 가지 단점이 있습니다.
- 단일 연결에 대한 더 큰 오버헤드 – HPACK 데이터 압축 알고리즘은 양쪽 끝에서 조회 테이블을 업데이트합니다. 이렇게 하면 연결이 상태 저장되고 단일 연결에는 추가 메모리가 필요합니다.
- 암호화가 필요하지 않을 수 있습니다 – 데이터에 보호가 필요하지 않거나 이미 DRM 또는 기타 인코딩으로 보호되는 경우 TLS 보안은 별 도움이 되지 않습니다.
- HTTP/1.x 최적화 문제 – HTTP/1.x 최적화는 실제로 HTTP/2를 지원하는 브라우저의 성능을 저하시키며 이를 해제하는 것은 추가 작업입니다.
- 대용량 다운로드는 이점이 없습니다 – 웹 애플리케이션이 주로 다운로드 가능한 대용량 파일 또는 미디어 스트림을 제공하는 경우 TLS를 원하지 않을 수 있으며 멀티플렉싱은 하나의 스트림만 사용 중일 때 이점을 제공하지 않습니다.
- 고객들이 관심이 없을 수도 있습니다 – 당신의 사이트에서 공유하는 고양이 동영상이 TLS와 HTTP/2로 보호받는지에 대해 관심이 없을 수도 있습니다. 하지만 이는 옳을 수 있습니다.
모든 것은 성능으로 귀결됩니다. 이러한 측면에서 좋은 소식과 나쁜 소식이 있습니다.
좋은 소식은 우리가 여기 NGINX에서 실행한 초기 내부 테스트에서 이론상 예측할 수 있는 결과를 보여주었다는 것입니다. 일반적인 인터넷 대기 시간이 있는 연결을 통해 요청된 혼합 콘텐츠 웹 페이지의 경우 HTTP/2가 HTTP/1.x 및 HTTPS보다 더 나은 성능을 보입니다. 결과는 연결의 일반적인 왕복 시간(RTT)에 따라 세 그룹으로 나뉩니다.
- 매우 낮은 RTT(0–20ms) – HTTP/1.x, HTTP/2 및 HTTPS 간에 사실상 차이가 없습니다.
- 일반적인 인터넷 RTT(30-250ms) – HTTP/2는 일반적으로 인터넷의 RTT(Round-Trip Time)가 30-250ms인 경우 HTTP/1.x보다 빠르며, HTTPS보다도 빠릅니다. 미국 내의 도시들 사이에서의 RTT는 약 30ms이고 해안에서 해안까지 약 70ms이며(약 3000마일), 도쿄와 런던 사이의 최단 경로에서의 RTT는 약 240ms입니다.
- 높은 RTT(300ms 이상) – HTTP/1.x는 HTTPS보다 빠른 HTTP/2보다 빠릅니다.
그림은 첫 번째 페인팅까지의 시간, 즉 사용자가 웹 페이지 콘텐츠가 화면에 처음 나타날 때까지의 시간을 보여줍니다. 이 측정은 웹 사이트의 응답성에 대한 사용자의 인식에 중요한 것으로 간주됩니다.
그러나 모든 웹 페이지는 다르며 실제로 모든 사용자 세션도 다릅니다. 스트리밍 미디어 또는 다운로드 가능한 대용량 파일이 있거나 HTTP/1.x 최적화에서 설탕을 과학적으로 분석한 경우(The Martian에 사과 포함) 결과가 다르거나 반대일 수도 있습니다.
요약하면, TLS 및 HTTP/2로 보호되는 사이트의 성능이 향상될 가능성이 높습니다. 그러나 아직 TLS를 지원하지 않는 경우, HTTP/2를 사용하기 전에 TLS 지원을 추가해야합니다. 이 경우, TLS 사용으로 인한 성능 저하가 HTTP/2 사용으로 인한 성능 이점과 거의 상쇄될 것으로 예상됩니다. 그러나 이 결정을 내리기 전에 자신의 콘텐츠에 대한 성능 테스트를 수행하고, 가능한 많은 정보를 수집한 후 결정하는 것이 좋습니다.
2. HTTP/2 및 TLS Termination
프로토콜 종료는 클라이언트가 TLS 또는 HTTP/2와 같은 원하는 프로토콜을 사용하여 프록시 서버에 연결함을 의미합니다. 그런 다음 프록시 서버는 그림과 같이 반드시 동일한 프로토콜을 사용하지 않고 애플리케이션 서버, 데이터베이스 서버 등에 연결합니다.
개별적인 서버를 사용하여 종료하는 방법은 다중 서버 아키텍처로 이동하는 것을 의미합니다. 이 서버는 별도의 물리 서버, 가상 서버 또는 AWS와 같은 클라우드 환경의 가상 서버 인스턴스일 수 있습니다. 이는 단일 서버 또는 애플리케이션 서버/데이터베이스 서버 조합에 비해 복잡도가 높은 단계입니다. 그러나 많은 이점을 제공하며 바쁜 사이트에 거의 필수적입니다.
서버 또는 가상 서버가 기존 설정 앞에 배치되면 많은 일이 가능합니다. 새 서버는 다른 서버에서 클라이언트 통신 작업을 오프로드(Offload)하며 부하 분산, 정적 파일 캐싱 및 기타 용도로 사용할 수 있습니다. 필요에 따라 애플리케이션 서버 및 기타 서버를 쉽게 추가하고 교체할 수 있습니다.
NGINX 및 NGINX Plus는 종종 TLS 및 HTTP/2 Termination, 로드 밸런싱 등의 모든 목적에 사용됩니다. 기존 환경은 NGINX 서버로 “frontending”하는 것 외에는 전혀 변경할 필요가 없습니다.
3. HTTP/1.x 최적화 사용 식별
HTTP/2 구현을 결정하기 전에 코드 기반이 HTTP/1.x에 얼마나 최적화되어 있는지 확인해야 합니다. 주의해야 할 네 가지 유형의 최적화가 있습니다.
- 도메인 샤딩 – 이미 파일을 다른 도메인에 놓아 웹 브라우저로 파일 전송을 병렬화하는 경우가 있을 수 있습니다. 콘텐츠 도메인 네트워크(CDN)는 이를 자동으로 수행합니다. 그러나 이는 HTTP/2에서는 성능을 향상시키지 않고 오히려 성능을 떨어뜨릴 수 있습니다. HTTP/1.x 사용자를 위해 HTTP/2-에 대응하는 도메인 샤딩을 사용할 수 있습니다(팁 7 참조).
- 이미지 스프라이트 – 이미지 스프라이트는 하나의 파일로 다운로드되는 이미지 집합입니다. 그런 다음 필요할 때 이미지를 검색하는 별도의 코드가 있습니다. 이미지 스프라이트의 장점은 HTTP/2에서는 덜 중요하지만 여전히 유용할 수 있습니다.
- 코드 파일 연결 – 이미지 스프라이트와 마찬가지로 일반적으로 별도의 파일로 유지 및 전송되는 코드 청크가 하나로 결합됩니다. 그런 다음 브라우저는 필요에 따라 연결된 파일 내에서 필요한 코드를 찾아 실행합니다.
- 인라인 파일 – CSS 코드, JavaScript 코드 및 이미지까지 HTML 파일에 직접 삽입됩니다. 이것은 초기 다운로드를 위해 부풀어 오른 HTML 파일을 희생시키면서 더 적은 파일 전송을 의미합니다.
마지막 세 가지 유형의 최적화는 모두 작은 파일을 더 큰 파일로 결합하여 TLS에 특히 비용이 많이 드는 새로운 연결 및 초기화 핸드쉐이킹을 줄입니다.
첫 번째 최적화인 도메인 샤딩은 그 반대입니다. 그림에 추가 도메인을 포함하여 더 많은 연결이 열리도록 합니다. 이러한 겉보기에 모순되는 기술을 함께 사용하면 HTTP/1.x 사이트의 성능을 높이는 데 상당히 효과적일 수 있습니다. 그러나 모두 설계, 구현, 관리 및 실행에 시간, 노력 및 리소스가 필요합니다.
HTTP/2를 구현하기 전에 이러한 최적화가 존재하는 위치와 현재 조직의 애플리케이션 디자인 및 워크플로에 어떤 영향을 미치고 있는지 파악하여 HTTP/2로 이동한 후 수정하거나 취소할 수 있습니다.
4. HTTP/2 배포
실제로 HTTP/2 를 배포하는 것은 그리 어렵지 않습니다. NGINX 사용자라면 NGINX 구성에서 프로토콜을 “켜기”만 하면 됩니다. 웹 애플리케이션 개발자용 HTTP/2(PDF) 에서 HTTP/2에 대해 자세히 설명합니다. 그런 다음 브라우저와 서버는 프로토콜을 선택하기 위해 협상하고 브라우저도 지원하는 경우(그리고 TLS가 사용 중인 경우) HTTP/2로 결정합니다.
서버 수준에서 HTTP/2를 구현하면 HTTP/2를 지원하는 브라우저 버전의 사용자는 HTTP/2에서 실행되는 웹 앱과의 세션을 갖게 됩니다. 이전 브라우저 버전의 사용자는 그림과 같이 세션이 HTTP/1.x에서 실행됩니다. 사용량이 많은 사이트에 대해 HTTP/2를 구현하는 경우 이전과 이후의 성능을 측정하고 중대한 부정적인 영향이 있는 경우 변경 사항을 되돌릴 수 있는 프로세스를 원할 것입니다.
참고: HTTP/2와 단일 연결을 사용하면 NGINX 구성의 일부 세부 정보가 더 중요해집니다. output_buffers, proxy_buffers 및 ssl_buffer_size와 같은 지시문의 설정을 조정하고 테스트하는 데 특별한 주의를 기울여 NGINX 구성을 검토합니다. 일반적인 구성 지침은 NGINX Plus 관리자 가이드의 NGINX SSL/TLS Termination를 참조하세요. 포스트 SSL Offloading, Encryption 그리고 NGINX 인증서 및 HTTPS 및 NGINX로 SEO를 개선하는 방법에서 더 구체적인 팁을 얻을 수 있습니다. NGINX SSL 성능 에서는 서버 key 크기, 서버 계약 및 대량 암호의 선택이 성능에 미치는 영향을 살펴봅니다.
참고: HTTP/2와 함께 사용하는 암호를 사용하려면 특별한 주의가 필요할 수 있습니다. HTTP/2용 RFC에는 피해야 할 암호 제품군 목록이 많이 있으며 암호 목록을 직접 구성하는 것이 좋습니다. NGINX 및 NGINX Plus에서 ssl_ciphers 지시문을 조정하고 ssl_prefer_server_ciphers를 활성화하고 널리 사용되는 브라우저 버전으로 구성을 테스트해 보십시오.
5. HTTP/1.x 최적화 검토
놀랍게도 HTTP/1.x 최적화를 실행 취소하거나 수정하는 것은 실제로 HTTP/2 구현에서 가장 창의적인 부분입니다. 고려해야 할 몇 가지 문제와 수행할 작업에 대한 많은 자유도가 있습니다.
변경을 시작하기 전에 이전 브라우저 사용자가 변경으로 인해 어려움을 겪을지 고려하십시오. 이를 염두에 두고 HTTP/1.x 최적화를 실행 취소하거나 수정하기 위한 세 가지 광범위한 전략이 있습니다.
- 이 부분은 특별한 내용이 없습니다 – 만약 HTTP/1.x를 위해 앱을 최적화하지 않았거나, 적당한 변경 사항을 적용하여 편안하다고 생각된다면, 앱에서 HTTP/2를 지원하기 위해 할 작업은 없습니다.
- 혼합 접근 방식 – 파일 및 데이터 연결을 줄이지만 완전히 제거하지는 않습니다. 예를 들어, 작은 이미지의 일관된 그룹에 대한 일부 이미지 스프라이트는 유지될 수 있지만 인라인 데이터가 있는 초기 HTML 파일을 대량으로 만들 수도 있습니다.
- HTTP/1.x 최적화의 완전한 역전(하지만 6번째의 도메인 샤딩 참고 사항 참조) – 이러한 최적화를 모두 제거하고 싶을 수 있습니다.
캐싱은 예측하기 어렵습니다. 이론적으로 캐싱은 많은 수의 작은 파일이 있는 곳에서 최적으로 작동합니다. 그러나 그것은 많은 파일 I/O를 의미합니다. 밀접하게 관련된 파일들의 일부를 연결하는 것은 워크플로 및 애플리케이션 성능을 위해 합리적일 수 있습니다. 자신의 경험과 다른 개발자들이 HTTP/2를 구현하면서 공유하는 것을 신중하게 고려하십시오.
6. 스마트 샤딩 구현
도메인 샤딩은 아마도 가장 극단적이고 가장 성공적인 HTTP/1.x 최적화 전략일 것입니다. 여전히 HTTP/1.x의 성능을 향상시키지만 기본적으로 무시되는 도메인 샤딩 버전을 사용할 수 있으며 HTTP/2의 경우 이점이 있습니다. (단일 연결을 사용하기 때문에 일반적으로 도메인 샤딩의 이점이 없습니다.)
HTTP/2 친화적인 샤딩의 경우 다음 두 가지가 발생합니다.
- 분할된 리소스의 도메인 이름이 동일한 IP 주소로 확인되도록 합니다.
- 인증서에 샤딩에 사용되는 모든 도메인 이름에 대해 유효한 와일드카드가 있는지 또는 적절한 다중 도메인 인증서가 있는지 확인하십시오.
자세한 내용은 RFC 7540, HTTP/2(Hypertext Transfer Protocol Version 2)를 참조하십시오.
이러한 조건이 충족되면 샤딩은 HTTP/1.x에 대해 발생합니다. 도메인은 HTTP/2가 아닌 추가 연결 세트를 생성하도록 브라우저를 트리거할 만큼 충분히 다릅니다. 별도의 도메인은 하나의 도메인으로 취급되며 단일 연결로 모든 도메인에 액세스할 수 있습니다.
7. 결론
HTTP/2 및 TLS는 사이트 성능을 개선하고 사용자에게 사이트와의 상호 작용이 안전하다는 것을 알릴 수 있습니다. HTTP/2를 처음으로 구현하거나 경쟁업체를 따라잡고 있든 관계없이 HTTP/2 지원을 빠르고 효과적으로 추가할 수 있습니다.
이러한 팁을 사용하면 최소한의 노력으로 최고의 HTTP/2 성능을 달성할 수 있으므로 유지 관리 및 실행이 쉽고 빠르고 효과적이며 안전한 애플리케이션을 만드는 데 집중할 수 있습니다.
NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.
사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.