CDN を使用しない[しないでください]

サイトの速度を最適化するためのほぼすべての記事やツールには、「CDN を使用する」という控えめな条項があります。 一般に、CDN はコンテンツ配信ネットワークまたはコンテンツ配信ネットワークです。 Method Lab では、このトピックに関するクライアントからの質問によく遭遇しますが、その中には独自の CDN を有効にするクライアントもいます。 この記事の目的は、サイトの読み込み速度に関して CDN が何を提供できるのか、どのような問題が発生する可能性があるのか​​、どのような場合に CDN の使用が正当化されるのかを理解することです。

図内の丸で囲まれた遅延は、CDN の使用によって発生します。

歴史を少し

多くのテクノロジーと同様、CDN は必然的に登場しました。 インターネット ユーザー間のインターネット チャネルの発展に伴い、オンライン ビデオ サービスが登場しました。 当然のことながら、ビデオ コンテンツは、通常の Web サイト コンテンツ (画像、テキスト、CSS または JS コード) に比べて桁違いに多くの帯域幅を必要とします。

XNUMX 台のサーバーから多くのクライアントにビデオ ストリームを並行してブロードキャストしようとすると、サーバーのインターネット チャネルがボトルネックになる可能性が高くなります。 一般に、一般的なサーバー チャネルが詰まるには、数千のスレッドで十分です。 もちろん、他にもリソースの制限がある可能性がありますが、現時点ではそれらは重要ではありません。 また、サーバー チャネルの拡張は費用がかかりすぎ (場合によっては不可能)、非現実的であることも重要です。 ブロードキャスト中のチャネルの負荷は周期的になります。

個々のサーバーのチャネルを制限するという問題は、CDN によって完全に解決されます。 クライアントはサーバーに直接接続するのではなく、CDN ネットワーク内のノードに接続します。 理想的な状況では、サーバーが XNUMX つのストリームを CDN ノードに送信し、ネットワークが独自のリソースを使用してこのストリームを多くのユーザーに配信します。 経済的な観点から見ると、実際に消費されたリソース (帯域幅やトラフィックなど) に対してのみ料金を支払うため、サービスの優れたスケーラビリティが得られます。 CDN を使用して重いコンテンツを配信することは完全に正当化され、論理的です。 ただし、この分野の最大手 (Netflix など) が、大規模な商用 CDN (Akamai、Cloudflare、Fastly など) を使用する代わりに独自の CDN を構築していることは注目に値します。

Web の進化に伴い、Web アプリケーション自体もますます複雑になってきました。 読み込み速度の問題が表面化しました。 Web サイトの速度を重視する人々は、Web サイトの読み込み速度を遅くする原因となるいくつかの大きな問題をすぐに特定しました。 その XNUMX つはネットワーク遅延 (RTT、ラウンド トリップ タイムまたは ping 時間) でした。 遅延は、TCP 接続の確立、TLS セッションの開始、個々のリソース (画像、JS ファイル、HTML ドキュメントなど) の読み込みなど、Web サイトの読み込みにおける多くのプロセスに影響します。

この問題は、HTTP/1.1 プロトコル (SPDY、QUIC、および HTTP/2 が登場する前は、これが唯一のオプションでした) を使用する場合、ブラウザーが 6 つのホストに対して XNUMX つまでの TCP 接続しか開かないという事実によってさらに悪化しました。 これらすべてが接続のダウンタイムとチャネル帯域幅の非効率的な使用につながりました。 この問題は、ドメイン シャーディング (接続数の制限を克服するために追加のホストを作成する) によって部分的に解決されました。

ここで、CDN の 200 番目の機能が現れます。ポイントの数が多く、ノードがユーザーに近いため、遅延 (RTT) が削減されます。 ここでは距離が決定的な役割を果たします。光の速度には制限があります (光ファイバーでは約 000 km/秒)。 これは、1000 km の移動ごとに 5 ミリ秒の遅延、または RTT に 10 ミリ秒が追加されることを意味します。 中間装置でも遅延があるため、これは送信に必要な最小時間です。 通常、CDN はサーバー上にオブジェクトをキャッシュする方法を知っているため、CDN を通じてそのようなオブジェクトを読み込むことで利点が得られます。 これに必要な条件は、キャッシュ内にオブジェクトが存在すること、Web アプリケーション サーバー (オリジン サーバー) と比較して CDN ポイントがユーザーに近いことです。 CDN ノードが地理的に近いからといって、低遅延が保証されるわけではないことを理解することが重要です。 クライアントと CDN の間のルーティングは、クライアントが別の国、場合によっては別の大陸のホストに接続するような方法で構築できます。 ここで、通信事業者と CDN サービス (ピアリング、接続、IX への参加など) との関係、および CDN 自体のトラフィック ルーティング ポリシーが関係します。 たとえば、Cloudflare が XNUMX つの初期プラン (無料と格安) を使用する場合、最も近いホストからのコンテンツの配信は保証されません。ホストは最小コストを達成するように選択されます。

多くの大手インターネット企業は、読み込み速度と Web サイトのパフォーマンスというテーマに一般 (Web 開発者やサービス所有者) の関心を集めています。 これらの企業の中には、Yahoo (Yslow ツール)、AOL (WebPageTest)、Google (Page Speed Insights サービス) があり、サイトを高速化するための独自の推奨事項を開発しています (主にクライアントの最適化に関連しています)。 その後、新しい Web サイト速度テスト ツールが登場し、Web サイトの速度を上げるためのヒントも提供されます。 これらのサービスまたはプラグインにはそれぞれ、「CDN を使用する」という一貫した推奨事項があります。 CDN の効果の説明として、通常、ネットワーク遅延の短縮が挙げられます。 残念ながら、誰もが CDN の加速効果がどのように達成され、どのように測定できるかを正確に理解する準備ができているわけではないため、この推奨事項は信じられ、公準として使用されています。 実際、すべての CDN が同じように作成されているわけではありません。

今すぐ CDN を使用する

CDN を使用する有用性を評価するには、CDN を分類する必要があります。 現在実際に見られることは次のとおりです (もちろん、括弧内の例はすべてを網羅したものではありません)。

1. JS ライブラリを配布するための無料の CDN (MaxCDN、Google. Yandex)。
2. クライアント最適化のためのサービスの CDN (フォントの場合は Google Fonts、画像の場合は Cloudinary、Cloudimage など)。
3. CMS での静的およびリソースの最適化のための CDN (Bitrix、WordPress などで利用可能)。
4. 汎用 CDN (StackPath、CDNVideo、NGENIX、Megafon)。
5. ウェブサイト高速化のための CDN (Cloudflare、Imperva、Airi)。

これらのタイプの主な違いは、CDN を通過するトラフィックの量です。 タイプ 1 ～ 3 は、4 つのリクエストから数十のリクエスト (通常は写真) まで、コンテンツの一部のみの配信です。 タイプ 5 と XNUMX は、CDN を介したトラフィックの完全なプロキシです。

実際には、これはサイトを読み込むために使用される接続の数を意味します。 HTTP/2 では、ホストへの単一の TCP 接続を使用して、任意の数のリクエストを処理します。 リソースをメイン ホスト (オリジン) と CDN に分割する場合、リクエストを複数のドメインに分散し、複数の TCP 接続を作成する必要があります。 最悪のケースは、DNS (1 RTT) + TCP (1 RTT) + TLS (2 ～ 3 RTT) = 6 ～ 7 RTT です。 この式では、デバイスの無線チャネル (アクティブでない場合) のアクティブ化のためのモバイル ネットワークの遅延や、携帯電話の塔での遅延は考慮されていません。

サイトの読み込みウォーターフォールでは次のようになります (CDN への接続の遅延は RTT 150 ミリ秒で強調表示されます)。

CDN がすべてのサイト トラフィック (サードパーティ サービスを除く) をカバーする場合は、単一の TCP 接続を使用して、追加のホストへの接続の遅延を節約できます。 もちろん、これは HTTP/2 接続にも当てはまります。

さらなる違いは、特定の CDN の機能によって決まります。最初のタイプでは静的ファイルをホストするだけですが、XNUMX 番目のタイプでは、最適化を目的としていくつかのタイプのサイト コンテンツを変更します。

Web サイト高速化のための CDN 機能

個々のタイプの CDN の機能に関係なく、サイトを高速化するための CDN 機能の全範囲を説明し、それぞれに何が実装されているかを見てみましょう。

1. テキストリソースの圧縮

最も基本的でわかりやすい機能ですが、実装が不十分であることがよくあります。 すべての CDN は、高速化機能として圧縮の存在を宣言しています。 しかし、さらに詳しく見てみると、次のような欠点が明らかになります。

• 動的圧縮には低い度数 (5 ～ 6) を使用できます (たとえば、gzip の場合、最大値は 9)。
• 静的圧縮 (キャッシュ内のファイル) は追加機能を使用しません (たとえば、次数 11 の zopfi または brotli)
• 効率的な Brotli 圧縮はサポートされていません (gzip と比較して約 20% の節約)。

CDN を使用する場合は、次のいくつかの点を確認する価値があります。CDN から取得したファイルを取得し、その圧縮サイズを記録し、比較のために手動で圧縮します (たとえば、brotli サポートを備えたオンライン サービスを使用できます)。 vsszhat.rf).

2. クライアント キャッシュ ヘッダーの設定

また、単純な高速化機能: クライアント (ブラウザー) によるコンテンツ キャッシュ用のヘッダーの追加。 最新のヘッダーはキャッシュ制御で、古いヘッダーは期限切れになります。 さらに、Etag を使用することもできます。 主なことは、キャッシュ制御の最大有効期間が十分に大きい (XNUMX か月以上) ということです。リソースを可能な限りキャッシュする準備ができている場合は、不変オプションを追加できます。

CDN は max-age 値を下げることができ、ユーザーは静的コンテンツをより頻繁にリロードする必要があります。 これが何に関係しているのかは明らかではありません。ネットワーク上のトラフィックを増やしたい、またはキャッシュをリセットする方法がわからないサイトとの互換性を高めたいという要望です。 たとえば、デフォルトのCloudflareヘッダーキャッシュ時間は1時間ですが、これは不変の静的データにとっては非常に短い時間です。

3. 画像の最適化

CDN は画像のキャッシュと提供の機能を担うため、CDN 側で画像を最適化し、この形式でユーザーに提供するのが合理的です。 この機能は CDN タイプ 2、3、5 でのみ利用可能であることを今すぐ予約しましょう。

高度な圧縮形式 (WebP など)、より効率的なエンコーダ (MozJPEG) を使用するか、単に不要なメタデータをクリーンアップするなど、さまざまな方法で画像を最適化できます。

一般に、このような最適化には、品質損失ありと品質損失なしの XNUMX つのタイプがあります。 CDN は通常、画質の変化に関する顧客からの苦情を避けるために、ロスレス最適化の使用に努めています。 このような状況では、ゲインは最小限になります。 実際には、多くの場合、JPEG 品質レベルは必要以上に高いため、ユーザー エクスペリエンスを損なうことなく、より低い品質レベルで安全に再圧縮できます。 一方で、考えられるすべての Web アプリケーションに対して一律に品質と設定のレベルを決定することは困難であるため、CDN はコンテキスト (画像の目的、Web アプリケーションの種類) を考慮して適用できる設定と比較して、より保守的な設定を使用します。 、など）

4. TLS接続の最適化

現在、ほとんどのトラフィックは TLS 接続を介して移動するため、TLS ネゴシエーションに余分な時間が費やされます。 最近、このプロセスを高速化するための新しいテクノロジーが開発されました。 たとえば、これは EC 暗号化、TLS 1.3、セッション キャッシュとチケット、ハードウェア暗号化アクセラレーション (AES-NI) などです。TLS を正しく設定すると、接続時間を 0 ～ 1 RTT に短縮できます (DNS と TCP はカウントしません)。

最新のソフトウェアを使用すれば、このような実践を自分で実装することは難しくありません。

すべての CDN が TLS のベスト プラクティスを実装しているわけではありません。これは、TLS 接続時間を測定することで確認できます (Webpagetest など)。 新しい接続に最適 - 1RTT、2RTT - 平均レベル、3RTT など - 悪い。

CDN レベルで TLS を使用する場合でも、サーバーと CDN 間のトラフィックはパブリック ネットワークを通過するため、Web アプリケーションを備えたサーバーも TLS を処理する必要がありますが、CDN 側から処理する必要があることにも注意してください。 最悪の場合、TLS 接続の遅延が XNUMX 倍発生します (XNUMX 回目は CDN ホストまで、XNUMX 回目は CDN ホストとサーバー間で発生します)。

一部のアプリケーションでは、セキュリティの問題に注意を払う価値があります。通常、トラフィックは CDN ノードで復号化され、これはトラフィック傍受の潜在的な機会となります。 トラフィック開示なしで動作するオプションは、通常、追加料金で最高料金プランで提供されます。

5. 接続遅延の削減

誰もが語る CDN の主な利点は、CDN ホストとユーザー間の待ち時間が短い (距離が短い) ことです。 ユーザーが集中するポイント (都市、トラフィック交換ポイントなど) にホストが配置される、地理的に分散されたネットワーク アーキテクチャを作成することによって実現されます。

実際には、さまざまなネットワークの優先順位が特定の地域にある場合があります。 たとえば、ロシアの CDN はロシアでより多くの拠点を持つことになります。 アメリカのものは、まずアメリカ国内でネットワークを展開します。 たとえば、最大の CDN の 2 つである Cloudflare は、ロシアにモスクワとサンクトペテルブルクの 10 つの拠点しかありません。 つまり、モスクワに直接配置する場合と比較して、最大約 XNUMX ミリ秒の遅延を節約できます。

ほとんどの西側 CDN はロシアではポイントをまったく持っていません。 これらに接続すると、ロシアの視聴者の遅延が増えるだけです。

6. コンテンツの最適化（縮小化、構造の変更）

最も複雑で技術的に進んだポイント。 配信中にコンテンツを変更することは非常に危険です。 たとえ縮小を行ったとしても、ソース コードを削減すると (余分なスペースや重要でない構造などにより)、パフォーマンスに影響する可能性があります。 JS コードを HTML の最後に移動したり、ファイルを結合したりするなど、より深刻な変更について言えば、サイトの機能が中断されるリスクはさらに高くなります。

したがって、これを行うのは一部のタイプ 5 CDN のみです。 もちろん、スピードアップに必要なすべての変更を自動化することは不可能です。手動による分析と最適化が必要です。 たとえば、未使用または重複したコードを削除するのは手動のタスクです。

原則として、このような最適化はすべて設定によって制御され、最も危険な最適化はデフォルトで無効になっています。

CDN タイプ別の高速化機能のサポート

それでは、さまざまな種類の CDN がどのような潜在的な高速化の機会を提供するかを見てみましょう。

便宜上、分類を繰り返します。

1. JS ライブラリを配布するための無料の CDN (MaxCDN、Google. Yandex)。
2. クライアント最適化のためのサービスの CDN (フォントの場合は Google Fonts、画像の場合は Cloudinary、Cloudimage など)。
3. CMS での静的およびリソースの最適化のための CDN (Bitrix、WordPress などで利用可能)。
4. 汎用 CDN (StackPath、CDNVideo、NGENIX、Megafon)。
5. ウェブサイト高速化のための CDN (Cloudflare、Imperva、Airi)。

CDNの特徴と種類を比較してみましょう。

機会
1タイプ
2タイプ
3タイプ
4タイプ
5タイプ

テキスト圧縮
+–
–
+–
+–
+

キャッシュヘッダー
+
+
+
+
+

写真
–
+–
+–
–
+

TLS
–
–
–
+–
+

遅れ
–
–
–
+
+

コンテンツ
–
–
–
–
+

この表では、「+」は完全なサポートを示し、「–」はサポートなし、「+–」は部分的なサポートを示します。 もちろん、実際にはこの表からの逸脱がある可能性があります (たとえば、一部の汎用 CDN は画像を最適化する機能を実装します) が、一般的なアイデアとしては役立ちます。

結果

この記事を読んだ後、サイトを高速化するための「CDN の使用」の推奨事項について、より明確なイメージが得られることを願っています。

他のビジネスと同様に、サービスのマーケティング上の約束を信じることはできません。 効果は実際の条件下で測定およびテストする必要があります。 すでに CDN を使用している場合は、この記事で説明されている基準を使用して CDN の有効性を確認してください。

現在 CDN を使用していると、サイトの読み込み時間が遅くなっている可能性があります。

一般的な推奨事項として、視聴者を調査し、その地理的範囲を決定することに重点を置くことができます。 主要な視聴者が半径 1 ～ 2 キロメートル以内に集中している場合、遅延の削減という主な目的のために CDN は必要ありません。 代わりに、サーバーをユーザーの近くに配置して適切に構成することで、この記事で説明されている最適化のほとんどを (無料かつ永続的に) 実現できます。

視聴者が本当に地理的に分散している場合 (半径 3000 キロメートル以上)、高品質の CDN を使用することが非常に役立ちます。 ただし、CDN によって正確に何が高速化できるのかを事前に理解する必要があります (機能の表とその説明を参照)。 ただし、Web サイトの高速化は依然として複雑なタスクであり、CDN の接続では解決できません。 上記の最適化に加えて、CDN の背後に最も効果的な高速化手段が残されています。それは、サーバー部分の最適化、クライアント部分への高度な変更 (未使用のコードの削除、レンダリング プロセスの最適化、コンテンツ、フォント、適応性などの操作) です。 )

出所： habr.com