블로그 | NGINX

더 빠른 HTTP/2 성능을 위한 7가지 팁

NGINX-F5-수평-검정-유형-RGB의 일부
발렌틴 바르테네프 썸네일
발렌틴 바르테네프
2015년 10월 26일 게시

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

오래된 하이퍼텍스트 전송 프로토콜, 즉 HTTP 표준이 이제 업데이트되었습니다. HTTP/2 표준은 2015년 5월에 승인되었으며 현재 브라우저와 웹 서버( NGINX Plus 와 NGINX Open Source 포함)에 구현되고 있습니다. HTTP/2는 현재 사용 중인 모든 웹 브라우저의 약 3분의 2 에서 지원되며 그 비율은 매달 수 퍼센트씩 증가하고 있습니다.

HTTP/2는 Google의 SPDY 프로토콜을 기반으로 구축되었으며, 2016년 초 Google의 Chrome 브라우저에서 SPDY 지원이 종료될 때까지 SPDY는 여전히 옵션으로 제공됩니다. NGINX는 SPDY를 선구적으로 지원했으며, 이제는 HTTP/2에서도 동일한 역할을 수행하고 있습니다. 웹 애플리케이션 개발자를 위한 HTTP/2 (PDF)라는 포괄적인 백서에서는 HTTP/2에 대한 설명과 SPDY 기반으로 구축된 방식, 그리고 구현 방법을 설명합니다.

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

  • HTTP/2는 텍스트가 아닌 바이너리 프로토콜이어서 더욱 컴팩트하고 효율적입니다.
  • 각각 하나의 파일을 전달하는 여러 연결이 아닌 도메인당 하나의 다중화 연결을 사용합니다.
  • 헤더는 SPDY의 gzip이 아닌 특수 목적으로 구축된 HPACK 프로토콜로 압축됩니다.
  • 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를 사용하면 웹사이트 성능이 향상될 가능성이 높습니다. 하지만 아직 그렇지 않은 경우 HTTP/2를 사용하려면 먼저 TLS 지원을 추가해야 합니다. 그런 경우 TLS를 사용함으로써 발생하는 성능 저하가 HTTP/2를 사용함으로써 얻는 성능 이점으로 대략 상쇄될 것으로 예상되지만, 구현 결정을 내리기 전에 이것이 귀하의 사이트에서 실제로 그런지 테스트하세요.

HTTP/2의 5가지 주요 잠재적 이점은 다음과 같습니다.

  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는 더 많은 웹 애플리케이션에서 사용할 수 있게 되면서 사용자에게 더욱 강화된 보안을 제공합니다.

다음은 당신이 마주하게 될 5가지 단점입니다.

  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~20ms) – HTTP/1.x, HTTP/2, HTTPS 사이에는 사실상 차이가 없습니다.
  • 일반적인 인터넷 RTT(30~250ms) – HTTP/2는 HTTP/1.x보다 빠르고, 둘 다 HTTPS보다 빠릅니다. 서로 가까운 미국 도시의 경우 RTT는 약 30ms이고, 해안에서 해안까지(약 3,000마일)는 약 70ms입니다. 도쿄와 런던을 잇는 가장 짧은 경로의 RTT는 약 240ms입니다.
  • 높은 RTT(300ms 이상) – HTTP/1.x는 HTTP/2보다 빠르고, HTTP/2는 HTTPS보다 빠릅니다.

그림은 첫 번째 페인팅에 걸리는 시간, 즉 사용자가 처음으로 웹 페이지 콘텐츠가 화면에 나타나는 것을 볼 때까지의 시간을 보여줍니다. 이러한 측정은 사용자가 웹사이트의 반응성을 인식하는 데 중요한 것으로 간주되는 경우가 많습니다.

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

그러나 모든 웹 페이지는 다르고, 실제로 모든 사용자 세션도 다릅니다. 스트리밍 미디어나 다운로드 가능한 대용량 파일이 있거나 HTTP/1.x 최적화를 과학적으로 수행한 경우( The Martian 에게 사과드립니다) 결과가 다르거나 심지어 반대일 수도 있습니다.

결론은 비용-편익 균형이 불분명하다고 느낄 수도 있다는 것입니다. 그렇다면 최대한 많이 배우고, 본인의 콘텐츠에 대한 성능 테스트를 실시한 후 결정을 내리세요. (지침을 얻으려면 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는 출시된 지 몇 년이 되었기 때문에 HTTP/2를 지원하는 웹 브라우저보다 SPDY를 지원하는 웹 브라우저가 더 많습니다. 하지만 이 글을 쓰는 시점에서는 그 격차가 줄어들고 있습니다. 웹 브라우저의 약 2/3가 HTTP/2를 지원하고, 5개 중 4개는 SPDY를 지원합니다.

새로운 스타일의 웹 전송 프로토콜을 구현하기 위해 서두르고 현재 가능한 한 많은 사용자를 지원하려는 경우 SPDY를 제공하는 것으로 시작할 수 있습니다. 그런 다음 2016년 초에 SPDY 지원이 제거되기 시작하면 HTTP/2로 전환할 수 있습니다. 최소한 NGINX에서는 빠른 변경입니다. 그 시점까지 더 많은 사용자가 HTTP/2를 지원하는 브라우저를 사용하게 되므로 이 전환 중에 가장 많은 사용자에게 최상의 작업을 수행하게 됩니다.

팁 4 – HTTP/1.x 최적화 사용 식별

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

  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 사용자라면 당사의 백서인 웹 애플리케이션 개발자를 위한 HTTP/2(PDF)에서 HTTP/2 에 대해 자세히 설명한 대로 NGINX 구성에서 프로토콜을 "켜기"만 하면 됩니다. 그런 다음 브라우저와 서버는 프로토콜을 선택하기 위해 협상하며, 브라우저가 HTTP/2를 지원하고 TLS를 사용 중인 경우 HTTP/2를 선택합니다.

HTTP/2를 서버 수준에서 구현하면 HTTP/2를 지원하는 브라우저 버전을 사용하는 사용자는 HTTP/2에서 실행되는 웹 앱과의 세션을 갖게 됩니다. 이전 버전의 브라우저를 사용하는 사용자는 그림에서 볼 수 있듯이 HTTP/1.x에서 세션을 실행합니다. 바쁜 사이트에 HTTP/2 또는 SPDY를 구현하는 경우 구현 전후에 성능을 측정하고, 상당한 부정적 영향이 있는 경우 변경을 되돌리는 프로세스를 마련해야 합니다.

메모 : HTTP/2와 단일 연결을 사용하면 NGINX 구성의 일부 세부 사항이 더욱 중요해집니다. output_buffers , proxy_buffers , ssl_buffer_size 와 같은 지시어의 설정을 조정하고 테스트하는 데 특히 주의하면서 NGINX 구성을 검토하세요. 일반적인 구성 지침은 NGINX Plus 관리자 가이드의 NGINX SSL/TLS 종료를 참조하세요. 블로그 SSL Offloading, Encryption, and Certificates with NGINX 와 How to Improve SEO with HTTPS and NGINX 에서 더 구체적인 팁을 얻을 수 있습니다. 백서 NGINX SSL Performance 에서는 서버 키 크기, 서버 계약 및 대량 암호의 선택이 성능에 어떤 영향을 미치는지 살펴봅니다.

메모 : HTTP/2에서 사용하는 암호를 사용할 경우 특별한 주의가 필요할 수 있습니다. HTTP/2 RFC에는 피해야 할 암호화 제품군 이 많이 나열되어 있으며, 암호화 목록을 직접 구성하는 것이 좋을 수도 있습니다. NGINX 및 NGINX Plus에서 ssl_ciphers 지시어를 조정하고 ssl_prefer_server_ciphers를 활성화하고 인기 있는 브라우저 버전에서 구성을 테스트해 보세요. Qualys SSL 서버 테스트는 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 친화적인 샤딩을 위해 다음 두 가지를 실행하세요.

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

자세한 내용은 RFC 7540 , Hypertext Transfer Protocol Version 2(HTTP/2)를 참조하세요.

이러한 조건이 충족되면 HTTP/1.x에서는 샤딩이 발생합니다. 즉, 도메인이 서로 다르기 때문에 브라우저가 추가 연결 세트를 생성하게 되고 HTTP/2에서는 그렇지 않습니다. 별도의 도메인은 하나의 도메인으로 처리되고 단일 연결로 모든 도메인에 액세스할 수 있습니다.

결론

HTTP/2와 TLS는 사이트 성능을 향상시키고 사용자에게 사이트와의 상호작용이 안전하다는 것을 알려줍니다. HTTP/2를 구현하는 데 있어 선두주자이든 경쟁자를 따라잡고 있든, HTTP/2 지원을 빠르고 훌륭하게 추가할 수 있습니다.

이러한 팁을 활용하면 최소한의 노력으로 최고의 HTTP/2 성능을 달성할 수 있습니다. 이를 통해 빠르고 효과적이며 보안이 강화된 애플리케이션을 만드는 데 집중할 수 있으며, 유지 관리와 실행이 쉽습니다.

리소스

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."