HTTP/2 성능을 더 빠르게 만드는 7가지 팁

Valentin Bartenev

HTTP/2에 대해 자세히 알아보려면 인기 웨비나 녹화 영상을 시청하세요. HTTP/2의 새로운 기능은 무엇인가요?

유서 깊은 하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol), 즉 HTTP 표준이 새롭게 업데이트되었습니다. HTTP/2 표준은 2015년 5월에 승인되었으며, 현재 브라우저와 웹 서버(여기에는 NGINX Plus와 NGINX Open Source가 포함됨)에 구현되고 있습니다. 현재 사용 중인 전체 웹 브라우저의 약 3분의 2가 HTTP/2를 지원하며, 그 비율은 매달 몇 퍼센트포인트씩 증가하고 있습니다.

HTTP/2는 Google의 SPDY 프로토콜을 기반으로 하며, Google Chrome 브라우저의 SPDY 지원이 종료되는 2016년 초까지는 SPDY도 계속 사용할 수 있습니다. NGINX는 SPDY를 선도적으로 지원했으며, 이제 HTTP/2에서도 같은 역할을 하고 있습니다. NGINX의 종합 백서인 웹 애플리케이션 개발자를 위한 HTTP/2(PDF)에서는 HTTP/2를 소개하고, HTTP/2가 SPDY를 어떻게 기반으로 하는지 살펴보며, 구현 방법을 설명합니다.

HTTP/2의 주요 기능은 SPDY와 동일합니다:

• HTTP/2는 텍스트가 아닌 바이너리 프로토콜이므로 더 간결하고 효율적입니다.
• 파일마다 별도의 연결을 여러 개 사용하는 대신, 도메인별로 하나의 다중화된 연결을 사용합니다
• 헤더는 전용으로 설계된 HPACK 프로토콜을 사용해 압축됩니다(SPDY에서처럼 gzip을 사용하는 대신).
• HTTP/2에는 브라우저가 가장 필요한 파일을 먼저 요청할 수 있도록 지원하는 복잡한 우선순위 지정 체계가 있으며, NGINX는 이를 완벽하게 지원합니다(SPDY는 더 단순한 체계를 사용했습니다).

이제 HTTP/2를 도입할지 결정해야 합니다. 이때 HTTP/2를 최대한 활용하는 방법을 아는 것도 중요합니다. 이 블로그 게시물에서는 의사 결정 및 구현 과정에서 성능과 관련된 측면을 안내합니다. HTTP/2 성능을 위한 다음 7가지 팁을 확인해 보세요.

1. 지금 HTTP/2가 필요한지 결정하세요
2. HTTP/2 및 TLS 종료
3. SPDY로 시작하는 것을 고려하세요
4. 코드에서 HTTP/1.x 최적화 요소 식별하기
5. HTTP/2 또는 SPDY 구현
6. HTTP/1.x 최적화 수정
7. 스마트 샤딩 구현

참고: 엄밀히 말하면 SPDY와 HTTP/2 모두 TLS가 필수는 아니지만, SSL/TLS와 함께 사용할 때 주로 이점을 얻을 수 있으며 브라우저는 SSL/TLS를 사용하는 경우에만 SPDY 또는 HTTP/2를 지원합니다.

팁 1 – 지금 HTTP/2가 필요한지 결정하기

HTTP/2 구현은 간단합니다. 자세한 내용은 백서 웹 애플리케이션 개발자를 위한 HTTP/2(PDF)에서 설명합니다. 하지만 HTTP/2가 만능 해결책은 아닙니다. 일부 웹 애플리케이션에는 유용하지만, 그렇지 않은 경우도 있습니다.

SSL/TLS(이하 TLS)를 사용 중이라면 HTTP/2를 사용하여 웹사이트 성능을 개선할 수 있습니다. 아직 TLS를 사용하고 있지 않다면 HTTP/2를 사용하기 전에 TLS 지원을 추가해야 합니다. 이 경우 TLS 사용으로 인한 성능 저하는 HTTP/2 사용에 따른 성능 향상으로 대체로 상쇄될 것으로 예상되지만, 구현 여부를 결정하기 전에 실제로 해당 사이트에서도 그런지 테스트해 보세요.

HTTP/2의 주요 잠재적 이점 다섯 가지는 다음과 같습니다:

1. 서버당 단일 연결 사용 – HTTP/2는 파일 요청마다 별도의 연결을 사용하는 대신 서버당 하나의 연결을 사용합니다. 따라서 시간이 많이 걸리는 연결 설정의 필요성이 크게 줄어듭니다. 특히 TLS 연결은 생성하는 데 많은 시간이 걸리므로 TLS를 사용할 때 더욱 유용합니다.
2. 더 빠른 TLS 성능 제공 – HTTP/2에서는 비용이 많이 드는 TLS 핸드셰이크가 한 번만 필요하며, 멀티플렉싱을 통해 단일 연결을 최대한 활용합니다. 또한 HTTP/2는 헤더 데이터를 압축하며, 파일 연결과 같은 HTTP/1.x 성능 최적화를 사용하지 않으므로 캐싱이 더 효율적으로 작동합니다.
3. 웹 애플리케이션을 간소화합니다 – HTTP/2를 사용하면 앱 개발자와 클라이언트 기기에 더 많은 부담을 주는 HTTP/1.x의 ‘최적화’ 방식에서 벗어날 수 있습니다.
4. 혼합형 웹 페이지에 적합 – HTTP/2는 HTML, CSS, JavaScript 코드, 이미지 및 제한적인 멀티미디어가 혼합된 기존 웹 페이지에서 특히 뛰어난 성능을 발휘합니다. 브라우저는 파일 요청의 우선순위를 지정하여 페이지의 핵심 부분이 먼저 빠르게 표시되도록 할 수 있습니다.
5. 보안 강화 지원 – TLS로 인한 성능 저하를 줄여 HTTP/2를 더 많은 웹 애플리케이션에서 사용할 수 있게 함으로써 사용자에게 더욱 강력한 보안을 제공합니다.

그리고 이에 따라 겪게 될 다섯 가지 단점은 다음과 같습니다:

1. 단일 연결의 오버헤드 증가 – HPACK 데이터 압축 알고리즘은 양쪽 끝의 조회 테이블을 업데이트합니다. 이로 인해 연결이 상태를 유지하게 되며, 단일 연결에 추가 메모리가 필요합니다.
2. 암호화가 필요하지 않을 수도 있습니다 – 데이터에 보호가 필요하지 않거나 이미 DRM 또는 기타 인코딩으로 보호되고 있다면 TLS 보안은 별다른 도움이 되지 않을 수 있습니다.
3. HTTP/1.x 최적화는 오히려 해가 됩니다 – HTTP/1.x 최적화는 실제로 HTTP/2를 지원하는 브라우저의 성능을 저하시키며, 이를 되돌리는 데에도 추가 작업이 필요합니다.
4. 대용량 다운로드에는 이점이 없음 – 웹 애플리케이션이 주로 다운로드 가능한 대용량 파일이나 미디어 스트림을 제공한다면 TLS를 사용하고 싶지 않을 가능성이 높으며, 하나의 스트림만 사용 중일 때는 멀티플렉싱도 아무런 이점을 제공하지 않습니다.
5. 고객은 신경 쓰지 않을 수도 있습니다 – 고객은 사이트에서 공유하는 고양이 동영상이 TLS와 HTTP/2로 보호되는지 여부에 관심이 없다고 생각할 수도 있으며, 실제로 그럴지도 모릅니다.

결국 모든 것은 성능에 달려 있습니다. 이와 관련해 좋은 소식과 나쁜 소식이 있습니다.

좋은 소식은 NGINX에서 실시한 초기 내부 테스트에서 이론적으로 예상되는 결과가 나왔다는 것입니다. 일반적인 인터넷 지연 시간이 발생하는 연결을 통해 혼합 콘텐츠 웹 페이지를 요청할 경우, HTTP/2가 HTTP/1.x 및 HTTPS보다 더 나은 성능을 보였습니다. 결과는 연결의 일반적인 왕복 시간(RTT)에 따라 세 그룹으로 나뉩니다:

• 매우 짧은 RTT(0~20 ms) – HTTP/1.x, HTTP/2, HTTPS 간에는 사실상 차이가 없습니다.
• 일반적인 인터넷 RTT(30~250 ms) – HTTP/2는 HTTP/1.x보다 빠르며, 둘 다 HTTPS보다 빠릅니다. 미국에서 서로 가까운 도시 간 RTT는 약 30 ms이고, 해안에서 반대편 해안까지(약 3,000마일)는 약 70 ms입니다. 도쿄와 런던 사이의 최단 경로에서 RTT는 약 240 ms입니다.
• 높은 RTT(300 ms 이상) – HTTP/1.x가 HTTP/2보다 빠르고, HTTP/2는 HTTPS보다 빠릅니다.

이 그림은 최초 페인팅까지 걸리는 시간, 즉 사용자가 화면에 웹 페이지 콘텐츠가 나타나는 것을 처음 확인할 때까지의 시간을 보여 줍니다. 이 측정값은 사용자가 웹 사이트의 응답성을 인식하는 데 매우 중요한 요소로 여겨지는 경우가 많습니다.

테스트에 대한 자세한 내용은 nginx.conf 2015에서 발표한 제 프레젠테이션 NGINX의 HTTP/2 모듈을 참조하세요.

하지만 모든 웹 페이지는 서로 다르며, 실제로 모든 사용자 세션도 서로 다릅니다. 스트리밍 미디어나 다운로드할 대용량 파일이 있거나 HTTP/1.x 최적화를 과학적으로, 그러니까, 끝까지 쥐어짰다면(마션에 사과를 전하며), 결과가 다르거나 심지어 정반대일 수도 있습니다.

결론적으로 비용과 이점 사이의 절충점이 명확하지 않다고 느낄 수 있습니다. 그렇다면 가능한 한 많이 알아보고, 자체 콘텐츠로 성능 테스트를 수행한 다음 결정하세요. (자세한 지침은 웨비나 HTTP/2의 새로운 기능은 무엇인가요?를 시청하세요.)

팁 2 – HTTP/2 및 TLS 종료

프로토콜을 종료한다는 것은 클라이언트가 TLS 또는 HTTP/2와 같은 원하는 프로토콜을 사용하여 프록시 서버에 연결하는 것을 의미합니다. 그러면 그림과 같이 프록시 서버는 반드시 동일한 프로토콜을 사용하지 않아도 애플리케이션 서버, 데이터베이스 서버 등에 연결할 수 있습니다.

종단 처리를 위해 별도의 서버를 사용한다는 것은 다중 서버 아키텍처로 전환한다는 의미입니다. 서버는 별도의 물리적 서버나 가상 서버일 수도 있고, AWS와 같은 클라우드 환경의 가상 서버 인스턴스일 수도 있습니다. 이는 단일 서버는 물론 애플리케이션 서버와 데이터베이스 서버를 조합한 구성보다도 복잡성이 한 단계 높습니다. 하지만 많은 이점을 제공하며, 트래픽이 많은 사이트에는 사실상 필수적입니다.

기존 구성 앞단에 서버나 가상 서버를 배치하면 다양한 작업이 가능해집니다. 새 서버는 다른 서버를 대신해 클라이언트 통신을 처리하며, 부하 분산, 정적 파일 캐싱 등의 용도로 사용할 수 있습니다. 필요에 따라 애플리케이션 서버와 기타 서버를 손쉽게 추가하거나 교체할 수 있습니다.

NGINX와 NGINX Plus는 TLS 및 HTTP/2 종료, 부하 분산 등 이러한 모든 용도로 자주 사용됩니다. 기존 환경은 NGINX 서버를 프런트엔드로 배치하는 것 외에는 전혀 변경할 필요가 없습니다.

팁 3 – SPDY로 시작하는 것을 고려하세요

편집자 주 – 이 블로그 게시물이 게시된 이후 주요 브라우저의 SPDY 지원이 종료되었습니다. 이제 SPDY로 시작하는 방식은 광범위한 배포에 적합한 선택지가 아닙니다.

SPDY는 HTTP/2의 전신 프로토콜이며 전반적인 성능은 거의 동일합니다. SPDY는 수년 전부터 사용되어 왔기 때문에 더 많은 웹 브라우저가 SPDY를 지원하며, HTTP/2를 지원하는 브라우저는 그보다 적습니다. 하지만 이 글을 작성하는 시점에는 그 격차가 줄어들고 있습니다. 웹 브라우저의 약 3분의 2가 HTTP/2를 지원하는 반면, SPDY는 약 5분의 4가 지원합니다.

새로운 방식의 웹 전송 프로토콜을 서둘러 구현하면서 현재 최대한 많은 사용자를 지원하고 싶다면, 우선 SPDY를 제공하는 것으로 시작할 수 있습니다. 그런 다음 SPDY 지원이 중단되기 시작하는 2016년 초에 HTTP/2로 전환하면 됩니다. 적어도 NGINX에서는 빠르게 변경할 수 있습니다. 그때쯤이면 HTTP/2를 지원하는 브라우저를 사용하는 사람이 더 많아질 것이므로, 이 전환 기간 동안 최대한 많은 사용자에게 가장 적합한 선택을 한 셈이 됩니다.

팁 4 – HTTP/1.x 최적화 사용 현황 파악

HTTP/2를 구현하기로 결정하기 전에 코드베이스가 HTTP/1.x에 얼마나 최적화되어 있는지 파악해야 합니다. 확인해야 할 최적화 유형은 다음 네 가지입니다:

1. 도메인 샤딩 – 웹 브라우저로 파일을 전송할 때 병렬성을 높이기 위해 이미 파일을 서로 다른 도메인에 배치했을 수 있습니다. 콘텐츠 전송 네트워크(CDN)는 이 작업을 자동으로 수행합니다. 하지만 HTTP/2에서는 성능 향상에 도움이 되지 않으며 오히려 성능을 저하시킬 수 있습니다. HTTP/2를 고려한 도메인 샤딩을 사용하면(팁 7 참조) HTTP/1.x 사용자에게만 샤딩을 적용할 수 있습니다.
2. 이미지 스프라이트 – 이미지 스프라이트는 여러 이미지를 하나의 파일로 묶어 다운로드하는 방식으로, 이후 별도의 코드가 필요할 때마다 이미지를 불러옵니다. HTTP/2에서는 이미지 스프라이트의 이점이 줄어들지만, 여전히 유용할 수 있습니다.
3. 코드 파일 연결 – 이미지 스프라이트와 마찬가지로, 일반적으로 별도의 파일로 관리되고 전송되는 코드 조각을 하나로 결합합니다. 그러면 브라우저는 필요할 때 결합된 파일에서 필요한 코드를 찾아 실행합니다.
4. 파일 인라인화 – CSS 코드, JavaScript 코드, 심지어 이미지까지 HTML 파일에 직접 삽입합니다. 이렇게 하면 파일 전송 횟수는 줄어들지만, 처음 다운로드할 HTML 파일의 용량이 커집니다.

마지막 세 가지 최적화 방식은 모두 작은 파일을 더 큰 파일로 결합하여 새로운 연결과 초기 핸드셰이크를 줄입니다. 이러한 과정은 특히 TLS에서 많은 비용이 듭니다.

첫 번째 최적화 기법인 도메인 샤딩은 이와 반대로 추가 도메인을 활용하여 더 많은 연결을 강제로 열도록 합니다. 이처럼 서로 모순되어 보이는 기법들을 함께 사용하면 HTTP/1.x 사이트의 성능을 높이는 데 상당한 효과를 거둘 수 있습니다. 하지만 이러한 기법을 설계하고 구현하며 관리하고 운영하려면 모두 시간과 노력, 리소스가 필요합니다.

HTTP/2를 구현하기 전에 이러한 최적화가 적용된 부분과 현재 조직의 애플리케이션 설계 및 워크플로에 어떤 영향을 미치고 있는지 파악해야 합니다. 그래야 HTTP/2로 전환한 후 이를 수정하거나 되돌릴 수 있습니다.

팁 5 – HTTP/2 또는 SPDY 배포

실제로 HTTP/2 또는 SPDY를 배포하는 것은 그리 어렵지 않습니다. NGINX 사용자라면 NGINX 구성에서 해당 프로토콜을 간단히 “활성화”하면 됩니다. HTTP/2에 관한 자세한 내용은 백서 웹 애플리케이션 개발자를 위한 HTTP/2(PDF)에서 확인할 수 있습니다. 그러면 브라우저와 서버가 사용할 프로토콜을 협상하며, 브라우저도 HTTP/2를 지원하고 TLS를 사용하는 경우 HTTP/2를 선택합니다.

서버 수준에서 HTTP/2를 구현하면 HTTP/2를 지원하는 브라우저 버전을 사용하는 사용자는 HTTP/2를 통해 웹 앱 세션을 이용하게 됩니다. 이전 버전의 브라우저를 사용하는 사용자는 그림과 같이 HTTP/1.x를 통해 세션을 이용하게 됩니다. 트래픽이 많은 사이트에 HTTP/2 또는 SPDY를 구현할 경우에는 구현 전후의 성능을 측정하고, 성능에 상당한 부정적 영향이 발생하면 변경 사항을 되돌릴 수 있는 프로세스를 마련해야 합니다.

참고: HTTP/2는 단일 연결을 사용하므로 NGINX 구성의 일부 세부 사항이 더욱 중요해집니다. NGINX 구성을 검토하되, 특히 output_buffers, proxy_buffers, ssl_buffer_size 등의 지시문 설정을 조정하고 테스트하는 데 주의를 기울이십시오. 일반적인 구성 지침은 NGINX Plus 관리자 가이드의 NGINX SSL/TLS 종료를 참조하십시오. 더 구체적인 팁은 블로그 게시물 NGINX를 사용한 SSL 오프로딩, 암호화 및 인증서 및 HTTPS와 NGINX를 사용하여 SEO를 개선하는 방법에서 확인할 수 있습니다. 백서 NGINX SSL 성능에서는 서버 키 크기, 서버 키 교환 방식 및 대칭키 암호화 알고리즘의 선택이 성능에 미치는 영향을 살펴봅니다.

참고: HTTP/2에서 사용하는 암호화 방식은 각별한 주의가 필요할 수 있습니다. HTTP/2 RFC에는 피해야 할 암호화 스위트가 많이 나열되어 있으므로 암호화 목록을 직접 구성하는 것이 좋을 수 있습니다. NGINX 및 NGINX Plus에서는 ssl_ciphers 지시문을 조정하고 ssl_prefer_server_ciphers를 활성화한 다음, 널리 사용되는 브라우저 버전에서 구성을 테스트하는 것이 좋습니다. Qualys SSL Server Test는 SSL 웹 서버의 구성을 분석하지만, 2015년 11월 기준으로 HTTP/2 핸드셰이크에 대해서는 신뢰할 수 없습니다.

팁 6 – HTTP/1.x 최적화 재검토

놀랍게도 기존의 HTTP/1.x 최적화를 되돌리거나 수정하는 작업은 사실 HTTP/2 구현에서 가장 창의적인 부분입니다. 고려해야 할 문제가 여러 가지이며, 어떤 조치를 취할지 선택할 수 있는 폭도 매우 넓습니다.

변경을 시작하기 전에 구형 브라우저 사용자가 그로 인해 불편을 겪지는 않을지 고려하세요. 이를 염두에 두고 HTTP/1.x 최적화를 되돌리거나 수정하는 방법은 크게 세 가지로 나눌 수 있습니다:

• 여기서는 신경 쓸 것이 없습니다 – 애플리케이션을 HTTP/1.x에 맞게 최적화하지 않았거나, 그대로 유지해도 괜찮을 정도로만 변경했다면 애플리케이션에서 HTTP/2를 지원하기 위해 별도로 해야 할 작업은 없습니다.
• 혼합 접근 방식 – 파일 및 데이터 연결을 줄이되 완전히 없애지는 않는 방식을 선택할 수 있습니다. 예를 들어, 서로 연관된 작은 이미지 그룹에 대한 이미지 스프라이트는 유지하는 반면, 데이터를 인라인으로 삽입해 초기 HTML 파일의 크기를 키우는 방식은 없앨 수 있습니다.
• HTTP/1.x 최적화의 완전한 철회(단, 팁 7의 도메인 샤딩 관련 참고 사항 참조) – 이러한 최적화를 모두 제거하는 것이 좋을 수 있습니다.

캐싱은 다소 예측하기 어려운 요소입니다. 이론적으로 캐싱은 작은 파일이 아주 많을 때 가장 효율적으로 작동합니다. 하지만 그만큼 파일 I/O도 많이 발생합니다. 워크플로와 애플리케이션 성능을 모두 고려하면, 서로 밀접하게 관련된 일부 파일을 하나로 합치는 것이 합리적일 수 있습니다. HTTP/2를 구현하면서 얻은 자신의 경험과 다른 개발자들이 공유하는 내용을 신중하게 검토하세요.

팁 7 – 스마트 샤딩 구현

도메인 샤딩은 아마도 가장 극단적이면서도 가장 성공적인 HTTP/1.x 최적화 전략일 것입니다. HTTP/1.x의 성능은 계속 향상하면서도 HTTP/2에서는 사실상 무시되도록 하는 도메인 샤딩 방식을 사용할 수 있으며, 이는 HTTP/2에 오히려 유리합니다. (HTTP/2는 단일 연결을 사용하므로 일반적으로 도메인 샤딩의 이점을 얻지 못합니다.)

HTTP/2에 적합한 샤딩을 구현하려면 다음 두 가지 조건을 충족해야 합니다:

• 샤딩된 리소스의 도메인 이름이 동일한 IP 주소로 확인되도록 합니다.
• 인증서에 와일드카드가 포함되어 있어 샤딩에 사용되는 모든 도메인 이름에 유효한지, 또는 적절한 다중 도메인 인증서가 있는지 확인하세요.

자세한 내용은 RFC 7540, 하이퍼텍스트 전송 프로토콜 버전 2(HTTP/2)을 참조하십시오.

이러한 조건이 충족되면 HTTP/1.x에서는 도메인이 서로 충분히 달라 브라우저가 추가 연결 세트를 생성하므로 샤딩이 발생하지만, HTTP/2에서는 발생하지 않습니다. 서로 다른 도메인이 하나의 도메인으로 취급되어 단일 연결로 모든 도메인에 액세스할 수 있기 때문입니다.

결론

HTTP/2와 TLS를 사용하면 사이트 성능을 개선하고 사용자가 사이트와 안전하게 상호작용할 수 있다는 확신을 줄 수 있습니다. 주변에서 가장 먼저 HTTP/2를 도입하든 경쟁업체를 따라잡기 위해 도입하든, 빠르고 원활하게 HTTP/2 지원을 추가할 수 있습니다.

다음 팁을 활용하면 지속적인 관리 부담을 최소화하면서 HTTP/2 성능을 극대화할 수 있으므로, 유지 관리와 운영이 간편하면서도 빠르고 효과적이며 안전한 애플리케이션을 만드는 데 집중할 수 있습니다.

리소스

• HTTP/2에 대한 자세한 내용은 NGINX의 백서를 참조하세요(PDF).
• The Can I use 웹사이트에서는 SPDY 및 HTTP/2를 비롯한 다양한 프런트엔드 웹 기술의 브라우저 지원 현황을 확인할 수 있습니다.
• 2016년 1월 기준, 웹사이트의 6% 이상이 HTTP/2를 사용했습니다.

• 테스트에 대한 자세한 내용은 nginx.conf 2015의 HTTP/2 프레젠테이션을 참조하세요.
• NGINX에서 제공하는 웨비나인 HTTP/2의 새로운 기능은 무엇인가요?에서는 주요 기능을 설명하고 구현에 관한 조언을 제공합니다.
• NGINX 성능 향상 팁에 대한 개요는 블로그 게시물 애플리케이션 성능을 10배 높이는 10가지 팁에서 확인하세요.

작성자 소개

Valentin Bartenev

Valentin Bartenev의 다른 블로그 게시물