콘텐츠 전송 네트워크 (CDN)

콘텐츠 전송 네트워크를 사용하여 성능을 개선합니다.

CDN (콘텐츠 전송 네트워크)은 사용자에게 리소스를 전송하기 위해 분산된 서버 네트워크를 사용하여 사이트 성능을 개선합니다. CDN은 서버 부하를 줄여주므로 서버 비용을 절감하며 트래픽 급증을 처리하는 데 적합합니다. 이 도움말에서는 CDN의 작동 방식에 대해 설명하고 CDN 설정의 선택, 구성, 최적화에 플랫폼에 구애받지 않는 지침을 제공합니다.

개요

콘텐츠 전송 네트워크는 사용자에게 콘텐츠를 신속하게 전송하는 데 최적화된 서버 네트워크로 구성됩니다. CDN은 캐시된 콘텐츠를 제공하는 것으로 가장 잘 알려져 있지만, CDN은 캐시할 수 없는 콘텐츠의 전송을 개선할 수도 있습니다. 일반적으로 CDN을 통해 전달되는 사이트가 많을수록 좋습니다.

CDN의 성능 이점은 몇 가지 원칙에서 비롯됩니다. CDN 서버가 원본 서버보다 사용자와 더 가까우므로 왕복 시간 (RTT) 지연 시간이 짧습니다. 네트워킹 최적화를 사용하면 콘텐츠가 원본 서버에서 '직접' 로드된 경우보다 CDN이 콘텐츠를 더 빠르게 전송할 수 있습니다. 마지막으로 CDN 캐시를 사용하면 요청이 원본 서버로 이동할 필요가 없습니다.

리소스 제공

직관적이지 않은 것처럼 보일 수 있지만, CDN을 사용하여 리소스 (캐시할 수 없는 리소스 포함)를 제공하는 것이 일반적으로 사용자가 서버에서 '직접' 리소스를 로드하는 것보다 빠릅니다.

원본에서 리소스를 전달하기 위해 CDN을 사용하면 클라이언트와 근처의 CDN 서버 사이에 새로운 연결이 설정됩니다. 나머지 여정 (즉, CDN 서버와 원본 간의 데이터 전송)은 CDN의 네트워크를 통해 이루어집니다. 네트워크에는 원본과의 기존 영구 연결이 포함되는 경우가 많습니다. 이렇게 하면 두 가지 이점이 있습니다. 즉, 새 연결을 가능한 한 사용자에게 가깝게 종료하면 불필요한 연결 설정 비용이 사라집니다 (새 연결을 설정하는 데는 비용이 많이 들고 여러 번의 왕복이 필요함). 예열 연결을 사용하면 가능한 최대 처리량으로 데이터를 즉시 전송할 수 있습니다.

일부 CDN은 인터넷 전반에 걸쳐 분산된 여러 CDN 서버를 통해 트래픽을 원본으로 라우팅함으로써 이를 더욱 개선합니다. CDN 서버 간 연결은 경계 게이트웨이 프로토콜 (BGP)에 의해 결정되는 경로가 아닌 안정적이고 최적화된 경로를 통해 이루어집니다. BGP가 인터넷의 사실상의 라우팅 프로토콜이지만 라우팅 결정이 항상 성능을 지향하는 것은 아닙니다. 따라서 BGP 결정 경로는 CDN 서버 간에 미세 조정된 경로보다 성능이 떨어질 수 있습니다.

캐싱

CDN 서버에서 리소스를 캐시하면 요청을 처리하기 위해 출처까지 이동할 필요가 없습니다. 그 결과, 리소스가 더 빠르게 전달되며, 원본 서버의 부하도 감소합니다.

캐시에 리소스 추가

CDN 캐시를 채우기 위해 가장 일반적으로 사용되는 방법은 필요에 따라 CDN '풀' 리소스를 갖는 것입니다. 이를 '원본 가져오기'라고 합니다. 특정 리소스가 캐시에서 처음 요청되면 CDN은 원본 서버에 이를 요청하고 응답을 캐시합니다. 이러한 방식으로 캐시되지 않은 추가 리소스가 요청됨에 따라 시간이 지남에 따라 캐시의 콘텐츠가 빌드됩니다.

캐시에서 리소스 삭제

CDN은 캐시 제거를 사용하여 유용하지 않은 리소스를 캐시에서 주기적으로 삭제합니다. 또한 사이트 소유자는 삭제를 사용하여 리소스를 명시적으로 삭제할 수 있습니다.

• 캐시 제거

  캐시의 스토리지 용량은 한정되어 있습니다. 캐시가 용량에 가까워지면 최근에 액세스하지 않았거나 많은 공간을 차지하는 리소스를 삭제하여 새 리소스를 위한 공간을 확보합니다. 이 프로세스를 캐시 제거라고 합니다. 리소스가 하나의 캐시에서 제거된다고 해서 반드시 CDN 네트워크의 모든 캐시에서 제거되었다는 의미는 아닙니다.

• 삭제

  삭제('캐시 무효화'라고도 함)는 리소스가 만료되거나 제거될 때까지 기다릴 필요 없이 CDN의 캐시에서 리소스를 제거하는 메커니즘입니다. 일반적으로 API를 통해 실행됩니다. 삭제는 콘텐츠를 철회해야 하는 상황 (예: 오타, 가격 오류 또는 잘못된 뉴스 기사 수정)에서 매우 중요합니다. 게다가 사이트의 캐싱 전략에도 중요한 역할을 할 수 있습니다.

  CDN에서 거의 즉각적인 삭제를 지원하는 경우 동적 콘텐츠의 캐싱을 관리하는 메커니즘으로 삭제를 사용할 수 있습니다. 긴 TTL을 사용하여 동적 콘텐츠를 캐시한 다음 업데이트될 때마다 리소스를 삭제합니다. 이렇게 하면 리소스가 언제 변경될지 미리 모르더라도 동적 리소스의 캐싱 기간을 극대화할 수 있습니다. 이 기법을 'Hold-To-Told 캐싱'이라고도 합니다.

  대규모로 영구 삭제할 때는 일반적으로 '캐시 태그' 또는 '서로게이트 캐시 키'라는 개념과 함께 사용됩니다. 이 메커니즘을 통해 사이트 소유자는 하나 이상의 추가 식별자('태그'라고도 함)를 캐시된 리소스와 연결할 수 있습니다. 그런 다음 이 태그를 사용하여 매우 세분화된 삭제를 수행할 수 있습니다. 예를 들어 사이트 바닥글이 포함된 모든 리소스 (예: /about, /blog)에 '바닥글' 태그를 추가할 수 있습니다. 바닥글이 업데이트되면 CDN에 'footer' 태그와 연결된 모든 리소스를 삭제하도록 지시합니다.

캐시 가능한 리소스

리소스의 캐시 여부 및 방법은 리소스가 공개인지 비공개인지, 정적인지 동적인지에 따라 다릅니다.

비공개 및 공개 리소스

• 비공개 리소스

  비공개 리소스에는 단일 사용자를 위한 데이터가 포함되어 있으므로 CDN에서 캐시하면 안 됩니다. 비공개 리소스는 Cache-Control: private 헤더로 표시됩니다.

• 공용 리소스

  공개 리소스는 사용자별 정보를 포함하지 않으므로 CDN에서 캐시할 수 있습니다. 리소스에 Cache-Control: no-store 또는 Cache-Control: private 헤더가 없는 경우 CDN에서 캐시 가능한 것으로 간주할 수 있습니다. 공개 리소스를 캐시할 수 있는 기간은 애셋 변경 빈도에 따라 다릅니다.

동적 및 정적 콘텐츠

• 동적 콘텐츠

  동적 콘텐츠는 자주 변경되는 콘텐츠입니다. API 응답과 스토어 홈페이지가 이 콘텐츠 유형의 예입니다. 하지만 이 콘텐츠가 자주 변경된다고 해서 반드시 캐시되는 것은 아닙니다. 트래픽이 많은 기간 동안 이러한 응답을 매우 짧은 시간 (예: 5초) 동안 캐시하면 원본 서버의 부하를 크게 줄이고 데이터 최신성에 미치는 영향을 최소화할 수 있습니다.

• 정적 콘텐츠

  정적 콘텐츠는 자주 변경되지 않습니다. 이미지, 동영상, 버전이 지정된 라이브러리가 일반적으로 이 콘텐츠 유형의 예입니다. 정적 콘텐츠는 변경되지 않으므로 긴 TTL(수명)으로 캐시되어야 합니다(예: 6개월 또는 1년).

CDN 선택

일반적으로 CDN을 선택할 때 성능을 가장 우선시합니다. 그러나 CDN을 선택할 때는 CDN이 제공하는 다른 기능 (예: 보안 및 분석 기능)과 CDN의 가격 책정, 지원, 온보딩을 모두 고려해야 합니다.

성능

개략적으로 설명하자면, CDN의 성능 전략은 지연 시간 최소화와 캐시 적중률 최대화 사이의 절충이라는 관점에서 볼 수 있습니다. 접속 지점 (PoP)이 많은 CDN은 지연 시간이 짧을 수 있지만 트래픽이 더 많은 캐시로 분할되어 캐시 적중률이 낮아질 수 있습니다. 반대로 PoP가 적은 CDN은 지리적으로 사용자로부터 더 멀리 떨어져 있을 수 있지만 캐시 적중률은 높을 수 있습니다.

이러한 절충의 결과로 일부 CDN은 계층화된 캐싱 접근 방식을 사용합니다. 사용자에게 가까운 PoP('에지 캐시'라고도 함)는 캐시 적중률이 더 높은 중앙 PoP로 보완됩니다. 에지 캐시는 리소스를 찾을 수 없으면 중앙 PoP를 찾습니다. 이 방식은 지연 시간을 약간 높여 CDN 캐시에서 리소스를 제공할 수 있는 가능성을 높입니다. 단, 에지 캐시일 필요는 없습니다.

지연 시간 최소화와 캐시 적중률 최대화 간의 균형은 스펙트럼입니다. 보편적으로 더 나은 접근 방식은 없습니다. 하지만 사이트의 특성과 사용자층에 따라 어느 방법이 더 우수한 실적을 가져다 주는지 알 수 있습니다.

CDN 성능은 지역, 시간, 시사에 따라 크게 달라질 수 있습니다. 항상 CDN의 성능을 직접 조사하는 것이 좋지만 CDN에서 얻게 될 정확한 성능을 예측하기 어려울 수 있습니다.

최대 콘텐츠 렌더링 시간 (LCP)에 미치는 영향

이 문서에서 앞서 설명한 것처럼 CDN의 주요 목적은 지리적으로 사용자와 더 가까운 서버에 리소스를 분산하여 지연 시간을 줄이는 것입니다. 따라서 CDN의 주요 이점은 로드 성능을 개선한다는 것입니다. 특히 웹사이트의 서버 측 아키텍처에 CDN을 도입하면 리소스의 첫 바이트 소요 시간 (TTFB)을 크게 개선할 수 있습니다.

TTFB는 사용자 중심 성능 측정항목은 아니지만 최대 콘텐츠 렌더링 시간(LCP) 사용자 중심 측정항목인 최대 콘텐츠 렌더링 시간(LCP) 관련 문제를 진단하기 위한 중요한 측정항목입니다.

CDN은 문서 전송 (연결 설정 및 문서 캐싱 시 TTFB를 줄임)과 LCP 요소를 렌더링하는 데 필요한 정적 리소스의 전달을 모두 개선할 수 있으므로 LCP를 개선하는 데 특히 효과적입니다.

추가 기능

CDN은 일반적으로 핵심 CDN 제품 외에도 다양한 기능을 제공합니다. 일반적으로 제공되는 기능으로는 부하 분산, 이미지 최적화, 동영상 스트리밍, 에지 컴퓨팅, 보안 제품이 있습니다.

CDN 설정 및 구성 방법

CDN을 사용하여 전체 사이트를 제공하는 것이 가장 좋습니다. 개략적으로 설정 프로세스는 CDN 제공업체에 가입한 다음 CDN 제공업체를 가리키도록 CNAME DNS 레코드를 업데이트하는 것입니다. 예를 들어 www.example.com의 CNAME 레코드는 example.my-cdn.com를 가리킬 수 있습니다. 이러한 DNS 변경으로 인해 사이트로 유입되는 트래픽이 CDN을 통해 라우팅됩니다.

CDN을 사용하여 모든 리소스를 제공할 수 없다면 리소스 하위 집합(예: 정적 리소스)만 제공하도록 CDN을 구성할 수 있습니다. 이를 위해서는 CDN에서 제공해야 하는 리소스에만 사용할 별도의 CNAME 레코드를 만들어야 합니다. 예를 들어 example.my-cdn.com을 가리키는 static.example.com CNAME 레코드를 만들 수 있습니다. 또한 만든 static.example.com 하위 도메인을 가리키도록 CDN에서 제공하는 리소스의 URL을 다시 작성해야 합니다.

이 시점에서 CDN이 설정되지만 구성에 비효율성이 있을 수 있습니다. 이 도움말의 다음 두 섹션에서는 캐시 적중률을 높이고 성능 기능을 사용 설정하여 CDN을 최대한 활용하는 방법을 설명합니다.

캐시 적중률 개선

효과적인 CDN 설정은 캐시에서 최대한 많은 리소스를 제공합니다. 이는 일반적으로 캐시 적중률 (CHR)로 측정됩니다. 캐시 적중률은 특정 시간 간격 동안 캐시 적중 횟수를 총 요청 수로 나눈 값으로 정의됩니다.

새로 초기화된 캐시의 CHR은 0이지만 캐시가 리소스로 채워질수록 이 값이 증가합니다. 대부분의 사이트에서는 CHR이 90% 인 것이 좋습니다. CDN 제공업체는 CHR에 관한 분석 및 보고를 제공할 것입니다.

CHR을 최적화할 때 가장 먼저 확인해야 할 사항은 캐시 가능한 모든 리소스가 올바른 기간 동안 캐시되고 캐시되고 있는지 확인하는 것입니다. 이 평가는 모든 사이트에서 수행해야 하는 간단한 평가입니다.

광범위하게 말해서, 다음 수준의 CHR 최적화는 논리적으로 동일한 서버 응답이 별도로 캐시되지 않도록 CDN 설정을 미세 조정하는 것입니다. 이는 쿼리 매개변수, 쿠키, 요청 헤더와 같은 요소가 캐싱에 미치는 영향으로 인해 발생하는 일반적인 비효율성입니다.

초기 감사

대부분의 CDN은 캐시 분석을 제공합니다. 또한 WebPageTest 및 Lighthouse와 같은 도구를 사용하여 페이지의 모든 정적 리소스가 올바른 기간 동안 캐시되고 있는지 신속하게 확인할 수도 있습니다. 이 작업은 각 리소스의 HTTP 캐시 헤더를 확인하여 수행할 수 있습니다. 적절한 최대 TTL (수명)을 사용하여 리소스를 캐시하면 향후에 불필요한 출처 가져오기를 방지하여 CHR이 증가합니다.

리소스가 CDN에 의해 캐시되도록 하려면 일반적으로 다음 헤더 중 최소 하나를 설정해야 합니다.

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

또한 CDN에 의해 리소스가 캐시되는지 여부나 방법에 영향을 미치지는 않지만 Cache-Control: immutable 지시어도 설정하는 것이 좋습니다.Cache-Control: immutable는 리소스가 '최신 상태 유지 기간 동안 업데이트되지 않음'을 나타냅니다. 따라서 브라우저 캐시에서 리소스를 제공할 때 브라우저는 리소스의 유효성을 재확인하지 않으므로 불필요한 서버 요청이 제거됩니다. 이 명령어는 Firefox와 Safari에서만 지원되며 Chromium 기반 브라우저에서는 지원되지 않습니다. 이 문제는 Cache-Control: immutable에 관한 Chromium 지원을 추적합니다. 이 문제에 별표를 표시하면 이 기능에 대한 지원을 받는 데 도움이 될 수 있습니다.

HTTP 캐싱에 관한 자세한 내용은 HTTP 캐시로 불필요한 네트워크 요청 방지하기를 참고하세요.

미세 조정

CDN 캐시의 작동 방식을 약간 단순화하면 리소스의 URL이 캐시에서 리소스를 캐시하고 검색하기 위한 키로 사용된다는 점입니다. 실제로 이는 여전히 압도적으로 사실이지만 요청 헤더 및 쿼리 매개변수와 같은 요소의 영향으로 인해 약간 복잡합니다. 따라서 요청 URL을 재작성하는 것은 CHR을 극대화하고 사용자에게 올바른 콘텐츠를 제공하는 데 중요한 기법입니다. 제대로 구성된 CDN 인스턴스는 지나치게 세분화된 캐싱 (CHR에 악영향을 줌)과 불충분하게 세분화된 캐싱 (사용자에게 잘못된 응답이 제공됨) 사이에서 올바른 균형을 유지합니다.

쿼리 매개변수

기본적으로 CDN은 리소스를 캐시할 때 쿼리 매개변수를 고려합니다. 그러나 쿼리 매개변수 처리를 약간 조정해도 CHR에 상당한 영향을 미칠 수 있습니다. 예를 들면 다음과 같습니다.

• 불필요한 쿼리 매개변수

  기본적으로 CDN은 example.com/blog 및 example.com/blog?referral_id=2zjk가 기본 리소스일 가능성이 높더라도 별도로 캐시합니다. 이 문제는 referral\_id 쿼리 매개변수를 무시하도록 CDN 구성을 조정하여 해결합니다.

• 쿼리 매개변수 순서

  CDN은 example.com/blog?query=dogs&id=123와 별도로 example.com/blog?id=123&query=dogs를 캐시합니다. 대부분의 사이트에서는 쿼리 매개변수 순서가 중요하지 않습니다. 따라서 쿼리 매개변수를 정렬하도록 CDN을 구성하면 (따라서 서버 응답을 캐시하는 데 사용되는 URL을 정규화) CHR이 증가합니다.

변경

Vary 응답 헤더는 특정 URL에 해당하는 서버 응답이 요청에 설정된 헤더 (예: Accept-Language 또는 Accept-Encoding 요청 헤더)에 따라 달라질 수 있음을 캐시에 알립니다. 따라서 CDN에 이러한 응답을 별도로 캐시하도록 지시합니다. Vary 헤더는 CDN에서 광범위하게 지원되지 않으며, 그렇지 않으면 캐시 가능한 리소스가 캐시에서 제공되지 않을 수 있습니다.

Vary 헤더는 유용한 도구가 될 수 있지만, 부적절한 사용은 CHR에 해를 끼칩니다. 또한 Vary를 사용하는 경우 요청 헤더를 정규화하면 CHR을 개선하는 데 도움이 됩니다. 예를 들어 정규화를 사용하지 않으면 요청 헤더 Accept-Language: en-US와 Accept-Language: en-US,en;q=0.9의 내용이 동일하더라도 두 개의 개별 캐시 항목이 생성됩니다.

쿠키

쿠키는 Cookie 헤더를 통해 요청에 설정되고, Set-Cookie 헤더를 통해 응답에 설정됩니다. 캐시는 일반적으로 이 헤더를 포함하는 서버 응답을 캐시하지 않으므로 Set-Cookie 헤더를 불필요하게 사용하지 않아야 합니다.

성능 기능

이 섹션에서는 CDN에서 핵심 제품의 일부로 일반적으로 제공하는 성능 기능에 대해 설명합니다. 많은 사이트가 이러한 기능을 사용 설정하지 않고 쉽게 실적을 얻을 수 있는 기회를 놓치고 있습니다.

압축

모든 텍스트 기반 응답은 gzip 또는 Brotli로 압축되어야 합니다. gzip 대신 Brotli를 선택합니다. Brotli는 최신 압축 알고리즘이며 gzip보다 더 높은 압축 비율을 달성할 수 있습니다.

Brotli 압축을 위한 CDN 지원에는 'Brotli from 원본'과 '자동 Brotli 압축'이라는 두 가지 유형이 있습니다.

브로틀리 원작

원본에서 Brotli로 압축된 리소스를 CDN에서 제공하는 경우를 말합니다. 이는 모든 CDN이 처음부터 지원할 수 있어야 하는 기능처럼 보일 수 있지만, 이를 위해서는 CDN이 주어진 URL에 해당하는 리소스의 여러 버전 (즉, gzip 압축 및 Brotli 압축 버전)을 캐시할 수 있어야 합니다.

자동 Brotli 압축

자동 Brotli 압축은 리소스가 CDN에 의해 Brotli로 압축된 경우에 해당합니다. CDN은 캐시 가능한 리소스와 캐시할 수 없는 리소스를 모두 압축할 수 있습니다.

리소스가 처음 요청되면 '충분한' 압축(예: Brotli-5)을 사용하여 제공됩니다. 이러한 유형의 압축은 캐시 가능한 리소스와 캐시할 수 없는 리소스에 모두 적용할 수 있습니다.

한편 리소스를 캐시할 수 있는 경우 CDN은 오프라인 처리를 사용하여 리소스를 더 강력하면서도 훨씬 느린 압축 수준(예: Brotli-11)으로 압축합니다. 이 압축이 완료되면 더 압축된 버전이 캐시되어 후속 요청에 사용됩니다.

압축 권장사항

성능을 극대화하려는 사이트는 원본 서버와 CDN에 모두 Brotli 압축을 적용해야 합니다. 원본에서 Brotli 압축은 캐시에서 제공할 수 없는 리소스의 전송 크기를 최소화합니다. 요청 처리의 지연을 방지하려면 출처가 상당히 보수적인 압축 수준을 사용하여 동적 리소스를 압축해야 합니다(예: Brotli-4). 정적 리소스는 Brotli-11을 사용하여 압축할 수 있습니다. 출처가 Brotli를 지원하지 않는 경우 gzip-6을 사용하여 동적 리소스를 압축할 수 있고, gzip-9를 사용하여 정적 리소스를 압축할 수 있습니다.

TLS 1.3

TLS 1.3은 HTTPS에서 사용하는 암호화 프로토콜인 전송 계층 보안 (TLS)의 최신 버전입니다. TLS 1.3은 TLS 1.2에 비해 더 나은 개인 정보 보호 및 성능을 제공합니다.

TLS 1.3은 TLS 핸드셰이크를 2회 왕복에서 1회로 단축합니다. HTTP/1 또는 HTTP/2를 사용하는 연결의 경우 TLS 핸드셰이크를 1회 왕복으로 단축하면 연결 설정 시간이 33% 단축됩니다.

HTTP/2 및 HTTP/3

HTTP/2와 HTTP/3는 모두 HTTP/1에 비해 성능상의 이점을 제공합니다. 이 두 가지 중에서 HTTP/3는 잠재적인 성능상의 이점이 더 많습니다. HTTP/3는 아직 완전히 표준화되지 않았지만 표준화가 되면 광범위하게 지원됩니다.

HTTP/2

CDN에서 아직 HTTP/2를 기본으로 사용 설정하지 않았다면 사용 설정하는 것이 좋습니다. HTTP/2는 HTTP/1에 비해 여러 가지 성능상의 이점을 제공하며 모든 주요 브라우저에서 지원합니다. HTTP/2의 성능 기능에는 다중화, 스트림 우선순위 지정, 헤더 압축 등이 있습니다.

• 다중화

  다중화는 아마도 HTTP/2의 가장 중요한 기능입니다. 다중화를 사용하면 단일 TCP 연결로 여러 요청-응답 쌍을 동시에 제공할 수 있습니다. 이렇게 하면 불필요한 연결 설정의 오버헤드가 사라집니다. 즉, 브라우저가 지정된 시간에 열 수 있는 연결 수가 제한된다는 점을 감안할 때 브라우저가 이제 더 많은 페이지 리소스를 동시에 요청할 수 있다는 의미도 있습니다. 다중화를 사용하면 이론적으로 연결 및 스프라이트 시트와 같은 HTTP/1 최적화의 필요성이 사라집니다. 하지만 실제로 이러한 기술은 큰 파일이 더 잘 압축된다는 점을 감안할 때 관련성이 높습니다.

• 스트림 우선순위 지정

  멀티플렉싱은 여러 개의 동시 스트림을 지원합니다. 스트림 우선순위는 이러한 각 스트림의 상대적 우선순위를 통신하기 위한 인터페이스를 제공합니다. 이렇게 하면 가장 중요한 리소스가 먼저 요청되지 않은 경우에도 서버에서 가장 중요한 리소스를 먼저 보낼 수 있습니다.

스트림 우선순위 지정은 종속 항목 트리를 통해 브라우저에 의해 표현되며 선호도를 나타낼 뿐입니다. 즉, 서버는 브라우저에서 제공하는 우선순위를 충족하거나 고려할 의무가 없습니다. CDN을 통해 더 많은 사이트가 제공될 때 스트림 우선순위 지정이 더욱 효과적입니다.

HTTP/2 리소스 우선순위 지정의 CDN 구현은 매우 다양합니다. CDN이 HTTP/2 리소스 우선순위 지정을 완전하고 적절하게 지원하는지 알아보려면 HTTP/2가 아직 빠르나요?를 확인하세요.

CDN 인스턴스를 HTTP/2로 전환하는 것은 대부분 스위치만 변경하면 되지만 프로덕션에서 사용 설정하기 전에 이 변경사항을 철저히 테스트하는 것이 중요합니다. HTTP/1과 HTTP/2는 요청 및 응답 헤더에 동일한 규칙을 사용하지만 이러한 규칙을 준수하지 않으면 HTTP/2는 훨씬 용납되지 않습니다. 따라서 HTTP/2가 사용 설정되면 ASCII가 아닌 문자 또는 대문자를 헤더에 포함하는 등 사양에서 벗어난 방식으로 오류가 발생할 수 있습니다. 이 경우 브라우저에서 리소스를 다운로드하려는 시도가 실패합니다. 실패한 다운로드 시도는 DevTools의 '네트워크' 탭에 표시됩니다. 또한 콘솔에 'ERR_HTTP2_PROTOCOL_ERROR' 오류 메시지가 표시됩니다.

HTTP/3

HTTP/3은 HTTP/2의 뒤를 잇습니다. 2020년 9월부터 모든 주요 브라우저에서 HTTP/3가 실험용 지원되며 일부 CDN에서 지원됩니다. 성능은 HTTP/2에 비해 HTTP/3의 주요 이점입니다. 특히 HTTP/3는 연결 수준에서 대기 행렬 막힘을 없애고 연결 설정 시간을 줄여줍니다.

• 대기열 차단 제거

  HTTP/2는 멀티플렉싱 기능을 도입했습니다. 다중화는 단일 연결을 사용하여 여러 데이터 스트림을 동시에 전송할 수 있도록 하는 기능입니다. 그러나 HTTP/2에서는 단일 드롭 패킷이 연결의 모든 스트림을 차단합니다 (헤드 오브 라인 차단으로 알려진 현상). HTTP/3에서는 삭제된 패킷이 단일 스트림만 차단합니다. 이러한 개선은 주로 TCP가 아닌 UDP (HTTP/3에서 QUIC를 통해 UDP를 사용함)를 사용하는 HTTP/3의 결과입니다. 따라서 HTTP/3는 혼잡하거나 손실이 있는 네트워크를 통한 데이터 전송에 특히 유용합니다.

• 연결 설정 시간 단축

  HTTP/3는 TLS 1.3을 사용하므로 새로운 연결을 설정하는 데 한 번의 왕복만 필요하고 기존 연결을 재개할 때 왕복이 필요하지 않습니다.

HTTP/3는 네트워크 연결 상태가 좋지 않은 사용자에게 가장 큰 영향을 미칩니다. HTTP/3가 이전 버전보다 패킷 손실을 더 잘 처리할 뿐만 아니라, 지연 시간이 긴 네트워크에서 0-RTT 또는 1-RTT 연결 설정으로 인한 절대적 시간 절약이 더 많기 때문입니다.

이미지 최적화

CDN 이미지 최적화 서비스는 일반적으로 이미지 전송 크기를 줄이기 위해 자동으로 적용할 수 있는 이미지 최적화에 중점을 둡니다. 예: EXIF 데이터 제거, 무손실 압축 적용, 이미지를 최신 파일 형식 (예: WebP)으로 변환 이미지는 웹페이지에서 전송 바이트의 약 50% 를 차지하므로 이미지를 최적화하면 페이지 크기를 크게 줄일 수 있습니다.

축소

축소는 자바스크립트, CSS, HTML에서 불필요한 문자를 삭제합니다. CDN보다는 원본 서버에서 축소를 수행하는 것이 좋습니다. 사이트 소유자는 축소할 코드에 대한 배경 정보를 더 많이 알고 있으므로 CDN에서 사용하는 기법보다 더 적극적인 축소 기법을 사용할 수 있는 경우가 많습니다. 그러나 원본에서 코드를 축소할 수 없다면 CDN을 통한 축소가 좋은 대안입니다.

결론

• CDN 사용: CDN은 리소스를 빠르게 제공하고 원본 서버의 부하를 줄이며 트래픽 급증에 대처하는 데 유용합니다.
• 최대한 적극적으로 콘텐츠 캐시: 기간이 다양하긴 하지만 정적 콘텐츠와 동적 콘텐츠는 모두 캐시할 수 있으며 캐시되어야 합니다. 정기적으로 사이트를 감사하여 콘텐츠를 최적으로 캐시하고 있는지 확인합니다.
• CDN 성능 기능 사용 설정: Brotli, TLS 1.3, HTTP/2, HTTP/3와 같은 기능으로 성능이 더욱 향상됩니다.