HTTP/2 성능 향상을 위한 7가지 팁

HTTP/2에 대해 자세히 알아보려면 인기 웨비나 What's New in HTTP/2? 녹화본을 시청하세요.

유서 깊은 하이퍼텍스트 전송 프로토콜, 즉 HTTP 표준이 이제 업데이트되었습니다. 

HTTP/2 표준은 2015년 5월에 승인되었으며 현재 브라우저와 웹 서버에서 구현되고 있습니다

(NGINX Plus 및 NGINX 오픈 소스 포함). 

HTTP/2는 현재 사용 중인 모든 웹 브라우저의 약 3분의 2에서 지원되고 있으며, 

그 비율은 매달 몇 퍼센트씩 증가하고 있습니다.

HTTP/2는 Google의 SPDY 프로토콜을 기반으로 하며, 

2016년 초에 Google의 Chrome 브라우저에서 지원이 종료되기 전까지는 

여전히 SPDY가 옵션으로 제공됩니다. 

NGINX는 SPDY의 선구적인 지지자였으며 현재 HTTP/2에서도 동일한 역할을 하고 있습니다. 

당사의 종합 백서인 웹 애플리케이션 개발자를 위한 HTTP/2(PDF)에서는 HTTP/2에 대해 설명하고, 

SPDY를 기반으로 구축하는 방법을 보여주며, 구현 방법을 설명합니다.

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

• HTTP/2는 텍스트가 아닌 바이너리 프로토콜로, 더 간결하고 효율적입니다.
• 각각 하나의 파일을 전달하는 여러 연결이 아닌 도메인당 하나의 멀티플렉스 연결을 사용합니다.
• 헤더는 특수 제작된 HPACK 프로토콜로 압축됩니다(SPDY에서와 같이 gzip이 아닌).
• HTTP/2는 브라우저가 가장 필요한 파일을 먼저 요청할 수 있도록 복잡한 우선순위 지정 체계를 가지고 있으며, 
• 이는 NGINX에서 완벽하게 지원됩니다(SPDY는 더 간단한 체계를 가지고 있었습니다).

이제 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를 구현하는 것은 쉽습니다. 

하지만 HTTP/2는 마법의 총알이 아니며, 

일부 웹 애플리케이션에는 유용하지만 다른 웹 애플리케이션에는 유용하지 않습니다.

SSL/TLS(여기서는 TLS라고 함)를 사용하는 경우 HTTP/2를 사용하면 웹사이트 성능이 향상될 수 있습니다.

그러나 그렇지 않은 경우 HTTP/2를 사용하려면 먼저 TLS 지원을 추가해야 합니다. 

이 경우 TLS 사용으로 인한 성능 저하가 HTTP/2 사용으로 인한 성능 이점으로 어느 정도 상쇄될 것으로 예상되지만, 

구현을 결정하기 전에 사이트에 실제로 해당하는지 테스트해 보세요.

다음은 HTTP/2의 다섯 가지 주요 잠재적 이점입니다:

1. 서버당 단일 연결 사용 - HTTP/2는 파일 요청당 하나의 연결이 아니라 서버당 하나의 연결을 사용합니다. 
2. 따라서 연결 설정에 많은 시간이 소요되는 TLS 연결이 훨씬 덜 필요하며, 특히 TLS 연결은 만드는 데 시간이 많이 걸리기 때문에 이점이 있습니다.
3. 더 빠른 TLS 성능 제공 - HTTP/2는 단 한 번의 고비용 TLS 핸드셰이크만 필요하며 멀티플렉싱은 단일 연결을 최대한 활용할 수 있습니다. 또한 HTTP/2는 헤더 데이터를 압축하고 파일 연결과 같은 HTTP/1.x의 성능 최적화를 피함으로써 캐싱이 더 효율적으로 작동합니다.
4. 웹 애플리케이션을 간소화 - HTTP/2를 사용하면 앱 개발자와 클라이언트 디바이스의 작업을 더 힘들게 만드는 HTTP/1.x '최적화'에서 벗어날 수 있습니다.
5. 혼합형 웹 페이지에 적합 - HTTP/2는 HTML, CSS, JavaScript 코드, 이미지, 제한된 멀티미디어가 혼합된 기존 웹 페이지에서 빛을 발합니다. 브라우저는 파일 요청의 우선순위를 지정하여 페이지의 주요 부분이 가장 먼저 빠르게 표시되도록 할 수 있습니다.
6. 보안 강화 지원 - HTTP/2는 TLS로 인한 성능 저하를 줄임으로써 더 많은 웹 애플리케이션이 이를 사용할 수 있도록 하여 사용자에게 더 큰 보안을 제공합니다.

그리고 여기에 해당하는 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-20 ms) - HTTP/1.x, HTTP/2, HTTPS 간에는 사실상 차이가 없습니다.
• 일반적인 인터넷 RTT(30-250 ms) - HTTP/2가 HTTP/1.x보다 빠르며, 둘 다 HTTPS보다 빠릅니다. 서로 가까운 미국 도시의 경우 RTT는 약 30밀리초이며, 해안에서 해안까지는 약 70밀리초(약 3000마일)입니다. 도쿄와 런던 사이의 최단 경로에서 RTT는 약 240밀리초입니다.
• 높은 RTT(300 ms 이상) - HTTP/1.x가 HTTPS보다 빠른 HTTP/2보다 빠릅니다.

이 그림은 첫 번째 페인팅까지의 시간, 

즉 사용자가 웹 페이지 콘텐츠가 화면에 처음 표시될 때까지의 시간을 보여줍니다. 

이 측정값은 종종 웹사이트의 응답성에 대한 사용자의 인식에 중요한 요소로 간주됩니다.

테스트에 대한 자세한 내용은 2015년에 제가 발표한 프레젠테이션인 NGINX의 HTTP/2 모듈에서 확인할 수 있습니다.

그러나 모든 웹 페이지는 다르며 실제로 모든 사용자 세션이 다릅니다. 

스트리밍 미디어나 다운로드 가능한 대용량 파일이 있거나 

HTTP/1.x 최적화를 잘못한 경우 결과가 달라지거나 심지어 정반대의 결과가 나올 수도 있습니다.

결론은 비용 대비 이익의 균형이 불분명할 수 있다는 것입니다. 

그렇다면 최대한 많은 정보를 습득하고 자체 콘텐츠에 대한 성능 테스트를 수행한 다음 문의하세요. 

(지침은 웨비나 What's New in HTTP/2?에서 확인하세요.)

팁 2 - HTTP/2 및 TLS 종료하기

프로토콜을 종료한다는 것은 클라이언트가 TLS 또는 HTTP/2와 같은 원하는 프로토콜을 사용하여 프록시 서버에 연결한다는 의미입니다. 

그러면 프록시 서버는 그림과 같이 반드시 동일한 프로토콜을 사용하지 않고 애플리케이션 서버, 데이터베이스 서버 등에 연결합니다.

종료 시 별도의 서버를 사용한다는 것은 멀티서버 아키텍처로 이동한다는 의미입니다. 

서버는 별도의 물리적 서버, 가상 서버 또는 클라우드 환경의 가상 서버 인스턴스(예: AWS)일 수 있습니다. 

이는 단일 서버 또는 애플리케이션 서버/데이터베이스 서버 조합에 비해 복잡성이 한 단계 높아집니다. 

하지만 많은 이점을 제공하며 사실상 - 말장난은 아니지만 - 바쁜 사이트에는 필수입니다.

서버 또는 가상 서버가 기존 설정 앞에 배치되면 많은 일이 가능합니다. 

새 서버는 다른 서버의 클라이언트 통신 작업을 오프로드하고 로드 밸런싱, 정적 파일 캐싱 및 기타 목적으로 사용할 수 있습니다. 

필요에 따라 애플리케이션 서버 및 기타 서버를 쉽게 추가하고 교체할 수 있습니다.

NGINX와 NGINX;Plus는 TLS 및 HTTP/2 종료, 로드 밸런싱 등 이러한 모든 용도로 자주 사용됩니다. 

기존 환경은 NGINX 서버로 '프런트엔드'하는 것 외에는 전혀 변경할 필요가 없습니다.

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

편집자 주 - 이 블로그 게시물이 게시된 이후 SPDY는 주요 브라우저에서 지원이 종료되었습니다. 

따라서 더 이상 SPDY를 광범위하게 배포할 수 없습니다.

SPDY는 HTTP/2의 전신 프로토콜로, 전반적인 성능은 거의 동일합니다. 

몇 년 전부터 사용되어 왔기 때문에, 

지원하는 웹 브라우저 지원하는 HTTP/2보다 SPDY가 더 많습니다. 

하지만 현재 웹 브라우저의 약 3분의 2가 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에 익숙한 도메인 샤딩(Tip 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 백서(HTTP/2(PDF)에서 

자세히 설명한 대로 NGINX 구성에서 프로토콜을 '켜기'만 하면 됩니다. 

그런 다음 브라우저와 서버가 프로토콜을 선택하기 위해 협상하여 

브라우저에서도 HTTP/2를 지원하는 경우(그리고 TLS가 사용 중인 경우) HTTP/2로 결정합니다.

서버 수준에서 HTTP/2를 구현하면 

HTTP/2를 지원하는 브라우저 버전을 사용하는 사용자는 웹 앱과의 세션이 HTTP/2에서 실행됩니다. 

이전 브라우저 버전을 사용하는 사용자는 그림과 같이 HTTP/1.x에서 세션이 실행됩니다. 

바쁜 사이트에 HTTP/2 또는 SPDY를 구현하는 경우, 변경 전과 후의 성능을 측정하고 

부정적인 영향이 큰 경우 변경을 되돌릴 수 있는 프로세스를 마련하는 것이 좋습니다.

주: HTTP/2와 단일 연결을 사용하면 NGINX 구성의 일부 세부 사항이 더 중요해집니다. 

출력_버퍼, 프로xy_버퍼, ssl_buffer_size 등의 지시어 설정 조정 및 테스트에 특히 주의하면서 NGINX 구성을 검토하세요. 

일반적인 구성 지침은 NGINX 플러스 관리자 가이드의 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 서버 테스트는 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의 도메인 샤딩 노트 참조)- 이러한 최적화를 완전히 제거할 수도 있습니다.

캐싱은 약간의 와일드카드입니다. 이론적으로 캐싱은 작은 파일이 많은 곳에서 최적으로 작동합니다.

 하지만 이는 파일 입출력이 많은 경우입니다. 

워크플로와 애플리케이션 성능 모두에서 밀접하게 관련된 파일을 일부 연결하는 것이 합리적일 수 있습니다. 

자신의 경험과 다른 개발자들이 HTTP/2를 구현하면서 공유한 내용을 신중하게 고려하세요.

팁 7 - 스마트 샤딩 구현하기

도메인 샤딩은 아마도 가장 극단적이면서도 가장 성공적인 HTTP/1.x 최적화 전략일 것입니다. 

도메인 샤딩 버전을 사용하면 HTTP/1.x의 성능을 개선할 수 있지만 

기본적으로 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)를 참조하세요.
• 사용 가능 웹사이트에서는 SPDY 및 HTTP/2를 비롯한 다양한 프론트엔드 웹 기술에 대한 브라우저 지원을 보여줍니다.
• 2016년 1월 기준, 6% 이상의 웹사이트가 HTTP/2를 사용했습니다.