Vivo ショートビデオ ユーザー アクセス エクスペリエンスの最適化の実践

著者: Vivo インターネット運用チーム - Hu Tao

この記事では、vivo ショート ビデオのユーザー アクセス エクスペリエンスの最適化に関する実践的なアイデアを紹介し、実践の背後にあるいくつかの原則について簡単に説明します。

1. 背景

Douyin Kuaishou のビデオを通常視聴する場合、特定のビデオ画面にスワイプして数秒間動かないと、そのビデオがスワイプされてしまう可能性が高いため、短いビデオ プロジェクトでは、画面のフリーズが発生します。ユーザーエクスペリエンスに大きく影響します。起動速度が速ければ速いほど、より多くのユーザーを維持できます。

簡単に言えば、起動速度は、呼び出しの開始から画面の最初のフレームまでの時間であり、大まかに次の 2 つの部分に分けることができます。

• 時間のかかる動画ファイルのダウンロード

• 時間のかかるビデオのデコード

この記事は、主に運用と保守のトラブルシューティングの観点から始まり、ネットワークの各リンクから始まり、最適化プロセスを共有するために、vivo の短いビデオの特定のケースを組み合わせます。

2. ユーザーアクセスリンク

次の図に示すように、クライアントの観点を例に挙げて、最初に次の完全なネットワーク要求プロセスを整理しましょう。

CDN へのアクセスの場合、いくつかの段階に分けることができます。

1. DNS ドメイン名解決: サーバーの IP アドレスを取得します。

2. TCP 接続の確立: サーバー IP との接続、つまり tcp スリーウェイ ハンドシェイクを確立します。

3. TLS ハンドシェイク: クライアントがサーバーの公開鍵をサーバーに要求して検証し、両者がネゴシエートして「セッション キー」を生成し、暗号化された通信を行います。

4. CDN レスポンス: 地理的に複数の場所にあるサーバーにコンテンツ リソースを配布し、それらをクライアントに返します。

上記の段階では、vivo ショートビデオがどのように最適化されるかについて話しましょう。

3. DNS ドメイン名の解決

インターネットをサーフィンするとき、通常、IP アドレスの代わりにドメイン名を使用します。これは、ドメイン名が人間の記憶にとって便利であるためです。そしてこの技術を実現するのがDNSドメイン名解決で、DNSはドメイン名のURLを特定のIPアドレスに自動変換することができます。

3.1 ドメイン名の階層関係

DNS のドメイン名は、 www.server.comのようにドットで区切られ ます。ドットは、異なるレベル間の境界を表します。ドメイン名では、右に行くほどレベルが高くなります。ルート ドメインはトップ レベルにあり、その次のレベルは com トップレベル ドメインであり、その下に server.comがあります。

したがって、ドメイン名の階層関係はツリー構造に似ています。

• ルート DNS サーバー

• トップレベル ドメイン DNS サーバー (com)

• 権威 DNS サーバー ( server.com )

ルート ドメインの DNS サーバー情報は、インターネット上のすべての DNS サーバーに格納されます。このようにして、どの DNS サーバーもルート ドメインの DNS サーバーを見つけてアクセスできます。

したがって、クライアントが任意の DNS サーバーを見つけることができる限り、クライアントはそれを介してルート ドメインの DNS サーバーを見つけることができ、さらに下位層にあるターゲット DNS サーバーをずっと見つけることができます。

3.2 ドメイン名解決の流れ

ブラウザは、まず自身のキャッシュに存在するかどうかを確認します.存在しない場合は、オペレーティング システムのキャッシュに問い合わせます.存在しない場合は、ローカル ドメインの名前解決ファイル ホストをチェックします.存在しない場合は、DNS サーバーに問い合わせます.クエリのプロセスは次のとおりです。

1. クライアントは最初に DNS 要求を送信し、  www.server.comの IP を尋ね、それをローカル DNS サーバー (つまり、クライアントの TCP/IP 設定に入力された DNS サーバー アドレス) に送信します。

2. ローカル ドメイン ネーム サーバーがクライアントの要求を受信した後、キャッシュ内のテーブルが www.server.comを見つけることができれば、IP アドレスを直接返します。そうでない場合、ローカル DNS はそのルート ドメイン ネーム サーバーに尋ねます:「ボス、 www.server.com の IP アドレスを教えてもらえますか ?」 ルート ドメイン ネーム サーバーは最上位レベルであり、ドメイン名には直接使用されません。解像度ですが、道路を指定できます。

3. ルート DNS はローカル DNS からのリクエストを受け取ると、サフィックスが .com であることを発見し、「ドメイン名www.server.com は .com 領域によって管理されています」と言って、アドレスを提供します。 .com のトップレベル ドメイン ネーム サーバーの "

4. ローカル DNS がトップレベル ドメイン ネーム サーバーのアドレスを受信すると、要求を開始して「2 番目の子、 www.server.comのIP アドレスを教えてもらえますか   ?」と尋ねます。

5. トップレベルのドメイン名サーバーは、「 www.server.comゾーンを担当する権限のある DNS サーバーのアドレスを提供します  。質問があれば、それを確認できるはずです」と述べています。

6. ローカル DNS は権限のある DNS サーバーに問い合わせます: 「私の 3 番目の子供、www.server.comに対応する IP は ?」 server.comの権限のある DNS サーバー は、ドメイン名解決結果の元のソースです。なぜそれは権威と呼ばれるのですか？それは私のドメイン名であり、私はショットを呼び出します.

7. 権威 DNS サーバーは、クエリを実行した後、対応する IP アドレス XXXX をローカル DNS に通知します。

8. その後、ローカル DNS はクライアントに IP アドレスを返し、クライアントはターゲットとの接続を確立します. 同時に、ローカル DNS は IP アドレスをキャッシュするので、同じドメイン名の次の解決は行う必要がありません. DNS 反復クエリ。

これまでのところ、DNS 解決プロセスは完了しています。要約すると、プロセス全体が絵に描かれています。

DNS ドメイン名の解決のプロセスは非常に興味深いもので、このプロセス全体は、道を示すだけで先導するわけではなく、日常生活で誰かに道を尋ねてもらうプロセスに似ています。

3.3 vivo ショートビデオの最適化

ドメイン名解決のワークフローを明らかにし、vivoドメイン名とトップメーカーのドメイン名を比較・分析したところ、時間がかかり不安定なvivoショート動画のドメイン名解決は変動幅が大きいことが疑われています。一部の地域ではユーザー数が少なく、ローカル DNS サーバーのキャッシュ ヒット率が低いため、最適化のアイデアは ローカル DNS キャッシュ ヒット率を改善することです。

上記の図に示すように、DNS キャッシュのヒット率を向上させる簡単な方法は、全国規模のダイヤルアップ テスト タスクを追加してDNS ヒーティングを実行することです。

調整前後のDNS解決時間を比較すると、消費時間が約30ms短縮されていることがわかります。

4. HTTP パフォーマンス

HTTP/1、HTTP/2、および HTTP/3 のパフォーマンスの簡単な比較を次に示します。

HTTP プロトコルはTCP/IPに基づいており、「要求と応答」の通信モードを使用するため、パフォーマンスの鍵はこの2 点にあります。

1.長い接続

初期の HTTP/1.0 のパフォーマンスにおける大きな問題は、リクエストが開始されるたびに新しい TCP 接続 (スリーウェイ ハンドシェイク) を作成する必要があり、それがシリアル リクエストであるため、不要な TCP 接続の確立と切断が行われることです。これにより、通信オーバーヘッドが増加します。

上記の TCP 接続の問題を解決するために、HTTP/1.1 では持続接続とも呼ばれる長時間接続の通信方式が提案されています。この方法の利点は、TCP 接続の確立と切断を繰り返すことによる追加のオーバーヘッドを減らし、サーバー側の負荷を軽減することです。

永続的な接続の特徴は、どちらかの端が明示的に切断を要求しない限り、TCP 接続状態を維持することです。

2. パイプラインネットワーク伝送

HTTP/1.1はロングコネクション方式を採用しており、パイプラインネットワーク伝送が可能です。

つまり、同じ TCP 接続で、クライアントは複数の要求を開始できます. 最初の要求が送信されている限り、2 番目の要求は、それが戻ってくるのを待たずに送信できるため、全体的な応答時間を短縮できます.

たとえば、クライアントは 2 つのリソースを要求する必要があります。以前の方法では、最初に同じ TCP 接続で A 要求を送信し、次にサーバーが応答するのを待ち、受信後に B 要求を送信していました。パイプライン メカニズムは、ブラウザが A リクエストと B リクエストを同時に発行できるようにすることです。

ただし、サーバーは引き続き A 要求に順番に応答し、完了後に B 要求に応答します。前の応答が特に遅い場合は、後で多くの要求が並んで待機することになります。これは「行頭ブロッキング」と呼ばれます。

3. ヘッドオブラインブロッキング

「リクエスト-レスポンス」モデルは、HTTP パフォーマンスの問題を悪化させます。

連続して送信されるリクエスト シーケンス内のリクエストが何らかの理由でブロックされると、後でキューに入れられたすべてのリクエストも一緒にブロックされ、クライアントがデータを要求しなくなります。これが「ヘッド オブ ライン ブロッキング」です。通勤途中の渋滞のようです。

4.1 HTTP/1.0 と比較した HTTP/1.1 のパフォーマンスの向上:

• TCP の長い接続を使用する方法は、HTTP/1.0 の短い接続によって引き起こされるパフォーマンスのオーバーヘッドを改善します。

• パイプライン ネットワーク伝送をサポートし、最初の要求が送信されている限り、2 番目の要求が戻ってくるのを待たずに送信できるため、全体の応答時間が短縮されます。

しかし、HTTP/1.1 にはまだパフォーマンスのボトルネックがあります。

• リクエスト/レスポンス ヘッダー (Header) は圧縮せずに送信され、ヘッダー情報が多いほど遅延が大きくなります。圧縮できるのは本体部分のみです。

• 長いヘッダーを送信します。毎回同じヘッダーを送信すると無駄が増えます。

• サーバーは要求の順序で応答します. サーバーの応答が遅い場合, クライアントはデータを要求できません. つまり, キューの先頭がブロックされています.

• リクエストの優先度制御なし。

• リクエストはクライアントからのみ開始でき、サーバーは受動的にしか応答できません。

上記の HTTP/1.1 のパフォーマンスのボトルネックに対して、HTTP/2 はいくつかの最適化を行いました。また、HTTP/2 プロトコルは HTTPS に基づいているため、HTTP/2 のセキュリティも保証されます。

4.2 HTTP/1.1 と比較した HTTP/2 のパフォーマンスの向上:

1.頭部圧迫

HTTP/2 はヘッダーを圧縮します (ヘッダー). 同時に複数のリクエストを送信し、それらのヘッダーが同じまたは類似している場合、プロトコルは重複部分を排除するのに役立ちます.

これは、いわゆる HPACK アルゴリズムです。クライアントとサーバーで同時にヘッダー情報テーブルを維持すると、すべてのフィールドがこのテーブルに格納され、インデックス番号が生成され、同じフィールドは送信されません。今後、インデックス番号のみが送信されるようになり、速度が向上します。

2. バイナリ形式

HTTP/2 は、HTTP/1.1 のようなプレーン テキスト メッセージではなくなりましたが、バイナリ形式が完全に採用されています。

ヘッダー情報とデータ本体はどちらもバイナリであり、まとめてフレーム (ヘッダー情報フレームとデータ フレーム)と呼ばれます。

これは人には優しくありませんが、コンピューターには非常にフレンドリーです。コンピューターはバイナリしか理解できないため、メッセージを受信した後、平文メッセージをバイナリに変換する必要はなく、バイナリ メッセージを直接解析することで、データ転送が増加します。効率化。

3. データの流れ

HTTP/2 データ パケットは順番に送信されず、同じ接続内の連続するデータ パケットが異なる応答に属する場合があります。したがって、パケットがどの応答に属しているかを示すために、パケットをマークする必要があります。

各要求または応答のすべてのデータ パケットは、データ ストリーム (ストリーム) と呼ばれます。

各データ ストリームには、クライアントから送信されるデータ ストリームの数が奇数で、サーバーから送信されるデータ ストリームの数が偶数であることを規定する一意の番号が付けられます。

クライアントは、データ ストリームの優先度も指定できます。優先度の高いリクエストの場合、サーバーは最初にリクエストに応答します。

4. 多重化

HTTP/2 では、1 対 1 で順番に対応するのではなく、1 つの接続で複数の要求または応答を同時に送信できます。

HTTP/1.1 のシリアル リクエストが削除され、列に並んで待つ必要がなくなり、「ヘッド オブ ライン ブロッキング」の問題が発生しなくなり、遅延が減少し、接続の使用率が大幅に向上します。

たとえば、TCP 接続で、サーバーはクライアント A と B から 2 つの要求を受け取ります。A の処理プロセスに非常に時間がかかることがわかった場合、A の要求の処理された部分に応答し、次に B の要求に応答します。 . 完了後、A の残りの要求に応答します。

5.サーバープッシュ

HTTP/2 はまた、従来の「要求応答」動作モードをある程度改善します. サービスはもはや受動的に応答しませんが、クライアントに積極的にメッセージを送信することもできます.

たとえば、ブラウザーが HTML を要求するだけの場合、遅延待機を減らすために事前にクライアントに使用できる JS ファイルや CSS ファイルなどの静的リソース、つまりサーバー プッシュ (サーバー プッシュ、キャッシュ プッシュとも呼ばれます) を積極的に送信します。

4.3 HTTP/2 の欠点は何ですか? HTTP/3 はどのような最適化を行いましたか?

HTTP/2 は、ヘッダー圧縮、バイナリ エンコーディング、多重化、サーバー プッシュなどの新機能によって HTTP/1.1 のパフォーマンスを大幅に向上させますが、HTTP/2 プロトコルは TCP に基づいて実装されているため、 3つの欠陥：個別。

• TCP と TLS 間のハンドシェイクの遅延。

• 行頭ブロッキング;

• ネットワーク移行には再接続が必要です。

1. TCP と TLS 間のハンドシェイクの遅延

HTTP/1 および HTTP/2 プロトコルでは、TCP と TLS が階層化されており、それぞれカーネルによって実装されるトランスポート層と openssl ライブラリによって実装されるプレゼンテーション層に属しているため、それらをマージすることは困難であり、ハンドシェイクする必要があります。バッチで、最初に TCP ハンドシェイク、次に TLS ハンドシェイク。

HTTP リクエストを開始するとき、TCP の 3 ウェイ ハンドシェイクと TLS の 4 ウェイ ハンドシェイク (TLS 1.2) のプロセスを通過する必要があるため、リクエスト データを送信するために合計 3 つの RTT 遅延がかかります。

さらに、TCP には「輻輳制御」の特性があるため、接続を確立したばかりの TCP は「スロー スタート」プロセスを実行し、TCP 接続に「スロー ダウン」効果をもたらします。

2. ヘッドオブラインブロッキング

HTTP/2 はストリームの同時実行性を実現し、複数のストリームが 1 つの TCP 接続を多重化するだけで済み、TCP と TLS のハンドシェイク時間を節約し、トラフィックに対する TCP スロー スタート フェーズの影響を軽減します。フレームが順不同で送信されても​​問題はありませんが、同じストリーム内のフレームは厳密な順序である必要があります。さらに、ストリームの優先順位は、リソースのレンダリング順序に従って設定できるため、ユーザー エクスペリエンスが向上します。

HTTP/2 は、Stream の同時実行機能によって HTTP/1 の行頭ブロッキングの問題を解決します。これは完璧に思えますが、HTTP/2 にはまだ「行頭ブロッキング」の問題がありますが、問題は HTTP のレベルではなく、TCP 層です。

複数の HTTP/2 リクエストが 1 つの TCP 接続で実行されるため、TCP パケットが失われると、TCP 全体が再送信を待つ必要があり、TCP 接続のすべてのリクエストがブロックされます。

TCP はバイト ストリーム プロトコルであるため、TCP 層は、受信したバイト データが完全で順序どおりであることを確認する必要があります. ネットワーク転送中にシーケンス番号の小さい TCP セグメントが失われた場合は、シーケンス番号の大きい TCP セグメントが失われたとしても、受信後、アプリケーション層はカーネルからデータのこの部分を読み取ることができず、HTTP の観点からは、要求はブロックされます。

たとえば、次のようになります。

この図では、送信側が多くのパケットを送信し、各パケットには独自のシーケンス番号があり、これは TCP のシーケンス番号と見なすことができます. そのうち、パケット 3 は、パケット 4-6 が受信された後も、ネットワークで失われました.カーネルが原因で受信側の TCP データは連続的ではないため、受信側のアプリケーション層はカーネルからそれを読み取ることができません. パケット 3 が再送信された後でのみ、受信側のアプリケーション層はカーネルからデータを読み取ることができます. これは HTTP/ 2 では、行頭ブロッキングの問題が TCP レベルで発生します。

3. ネットワークの移行には再接続が必要です

TCP 接続は 4 つのタプル (送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート) によって決定されます。つまり、IP アドレスまたはポートが変更されると、TCP と TLS の間で再ハンドシェイクが行われます。これは、4G ネットワーク環境から WIFI への切り替えなど、モバイル デバイスがネットワークを切り替えるシナリオを助長しません。

これらの問題は TCP プロトコルに固有のものであり、HTTP/2 がアプリケーション層でどのように設計されていても、回避することはできません。

この問題を解決するために、HTTP/3 はトランスポート層プロトコルを TCP から UDP に置き換え、UDP プロトコル上に QUIC プロトコルを開発して信頼性の高いデータ転送を保証しました。

4.4 QUIC プロトコルの特徴

• There is no head-of-line blocks , there is no dependency between multiple Streams on the QUIC connection, they are all independent, and there will be no base protocol definitions. 特定のストリームでパケット損失が発生し、このストリームのみが影響を受けます、および他のストリームは影響を受けません。

• QUIC は内部に TLS1.3 を含んでいるため、接続の確立は高速です。そのため、接続の確立と TLS キーのネゴシエーションを「同時に」完了するのに必要な RTT は 1 つだけであり、2 回目の接続でも、アプリケーション データ パケットは情報をハンドシェイクできます。 0-RTT の効果を得るために、QUIC (接続情報 + TLS 情報) が一緒に送信されます。

• Connection migration , the QUIC protocol does not use a quadruple to "bind" the connection, but to mark the two endpoints of the communication through the connection ID. クライアントとサーバーはそれぞれ一連の ID を選択して自分自身をマークできるので、ネットワークの変更後、IP アドレスが変更された場合、コンテキスト情報 (接続 ID、TLS キーなど) が保持されている限り、元の接続を「シームレスに」再利用して、接続のコストを削減できます。再接続。

さらに、HTTP/3 の QPACK は、HTTP/2 の HPACK のヘッドオブキュー ブロッキングの問題を解決する 2 つの特別な単方向ストリームを介して、両当事者の動的テーブルを同期します。

ただし、QUIC は UDP 伝送プロトコルを使用するため、UDP は「二流市民」です. ほとんどのルーターは、ネットワークがビジー状態になると UDP パケットをドロップし、TCP パケットに「スペース」を与えます. したがって、QUIC の推進は難しくありません。 . とてもシンプルです。HTTP/3 が正式にリリースされる日を楽しみにしています。

4.5 vivo ショートビデオの最適化

さまざまな時期の vivo ショート ビデオの開発に伴い、さまざまな最適化を行いました。

1. HTTP/1.1 を使用します。クライアントは、最初のフレーム画像のドメイン名とコメント アバターのドメイン名をマージします。TCP リンクの再利用率は 4% 増加し、画像の平均読み込み時間は約 40 ミリ秒減少します。

2. HTTP/2 を使用: クライアントは一部のドメイン名でグレースケールの H2 を使用し、フリーズ率は 0.5% 低下します

3. QUIC を使用する: 弱いネットワーク シナリオでは、クライアントは QUIC プロトコルの使用を優先し、同時に、短いビデオ サービスの特性に合わせて QUIC のパフォーマンスを特に最適化します。

5. CDN アクセラレーション

CDN のフルネームは Content Delivery Network、中国名は「Content Distribution Network」で、長距離によるネットワーク アクセスの遅延の問題を解決します。

簡単に言えば、CDN は、コンテンツ リソースにアクセスするときにソース サーバーにアクセスする必要がないように、地理的に複数の場所にあるコンピューター ルームにあるサーバーにコンテンツ リソースを配布します。代わりに、最も近い CDN ノードに直接アクセスします。これにより、長距離移動の時間コストが節約され、ネットワークの高速化が実現します。

CDN が加速するのは、コンテンツ リソースが静的リソースであることです。

いわゆる「静的リソース」とは、データの内容が静的で変更されておらず、写真や音声など、いつでも同じアクセスが可能であることを意味します。反対に、「動的リソース」とは、ユーザー情報など、データの内容が動的に変化し、訪問ごとに異なることを意味します。ただし、動的リソースもキャッシュして高速化したい場合は、動的 CDN を使用する必要があり、その方法の 1 つは、エッジ コンピューティングと呼ばれる CDN ノードにデータの論理計算を配置することです。

CDN アクセラレーション戦略には、「プッシュ モード」と「プル モード」の 2 つの方法があります。

ほとんどの CDN 高速化戦略は「プル モード」を採用しています。要求されたデータが、ユーザーがアクセスした最も近い CDN ノードにキャッシュされていない場合、CDN はソース サーバーからデータを積極的にダウンロードし、CDN ノードのキャッシュに更新します。プル モードはパッシブ キャッシング方式であり、反対の「プッシュ モード」はアクティブ キャッシング方式であることがわかります。ユーザーがリソースにアクセスする前に CDN ノードにリソースをキャッシュする場合は、CDN プレヒートとも呼ばれる「プッシュ モード」を使用できます。CDN サービスが提供する API インターフェースを介して、予熱が必要なリソースのアドレスや予熱が必要な領域などの情報を送信し、CDN がそれを受信すると、これらの領域の CDN ノードが移動するようにトリガーします。ソースに戻ってリソースの予熱を達成します。

5.1 ユーザーに最も近い CDN ノードを見つける方法は?

ユーザーに最も近い CDN ノードを見つけるのは、 CDN のグローバル ロード バランサー(グローバル サーバー ロード バランス、GSLB)の役割です。GSLB はいつ機能しますか? この質問に答える前に、CDN なしでドメイン名にアクセスするとどうなるか見てみましょう。CDN がない場合、ドメイン名にアクセスすると、DNS サーバーは最終的にオリジン サーバーのアドレスを返します。たとえば、ブラウザにwww.server.comドメイン名を入力し、ローカル ホスト ファイルにドメイン名が見つからない場合、クライアントはローカル DNS サーバーにアクセスします。

この時点で:

• ローカル DNS サーバーが Web サイトのアドレスをキャッシュしている場合、Web サイトのアドレスを直接返します。

• そうでない場合は、最初に再帰クエリを介してルート ; ) と、ルート DNS は最上位 DNS (.com DNS   www.server.com に対応する IP アドレスをクエリし、この IP アドレスを返します。同時に、ローカル DNS は IP アドレスをキャッシュするため、同じドメイン名の次の解決で DNS 反復クエリを実行する必要がありません。

でも、CDNに入会してからは違います。

CNAME エイリアスが DNS サーバーserver.comに設定さ れ、別のドメイン名www.server.cdn.com を指し 、ローカル DNS サーバーに返されます。次に、ドメイン名の解決を続けます。この時点で、 server.cdn.com は CDN 専用の DNS サーバーです。このサーバーでは、別のドメイン名を指すように CNAME が設定されます。今回は、  CDN の GSLB。次に、ローカル DNS サーバーは CDN の GSLB のドメイン名を要求し、GSLB は適切な CDN ノードを選択してユーザーにサービスを提供します. 選択基準には主に次の点が含まれます:

• ユーザーの IP アドレスを確認し、テーブルを参照して地理的な場所を確認し、比較的近い CDN ノードを見つけます。

• ユーザーがいるオペレーター ネットワークを見て、同じネットワークの CDN ノードを見つけます。

• ユーザーが要求した URL を調べて、ユーザーが要求したリソースを持つサーバーを特定します。

• CDN ノードの負荷ステータスを照会し、負荷が軽いノードを見つけます。

GSLB は上記の条件に基づいて包括的な分析を行い、最適な CDN ノードを見つけて、CDN ノードの IP アドレスをローカル DNS サーバーに返し、ローカル DNS サーバーは IP アドレスをキャッシュして IP アドレスを返します。 client に対して、クライアントはこの CDN ノードにアクセスし、リソースをダウンロードします。

5.2 vivo ショートビデオの最適化

分析の結果、CDN に接続されている一部のドメイン名は、全国のいくつかの州で近くにアクセスされておらず、CDN エッジ ノードの地域間カバレッジの問題が比較的深刻であることがわかりました。そのため、CDN メーカーに的を絞った調整を依頼したところ、平均的なリクエスト時間の消費は約 300 ミリ秒に短縮され、最初のパケットの消費時間も 100 ミリ秒以上に短縮されました。

6. まとめと展望

ビジネスの発展に伴い, ユーザーエクスペリエンスの改善はますます重要になります. ユーザーアクセスエクスペリエンスの最適化は終わりのないプロセスになります. 上記の方法に加えて, 私たちが試したいくつかの最適化もあります. 例:

• 接続の最適化: ビデオの再生中に上下にスライドすると、頻繁に接続が切断され、接続を再利用できなくなります。

• ファイルの事前キャッシュ: 起動時間を短縮します。

• コンテンツの最適化: ファイル転送サイズを減らします。

この記事が、日常業務におけるユーザー アクセス エクスペリエンスの最適化に役立つことを願っています。

{{o.name}}

{{m.name}}