13

クライアントの接続速度に基づいて、クライアントに送信するコンテンツの重みを動的に決定する必要があります。

つまり、クライアントが 3G (またはそれより遅い) 接続のモバイル デバイスを使用している場合、軽量のコンテンツをクライアントに送信します。彼/彼女がWiFiまたはより高速な接続を使用している場合、私は彼/彼女に完全なコンテンツを送信します.

クライアントにヘッダーを送信して、リロード間の時間を測定しようとしましたLocation: myurl.com（クライアントを識別するための情報を含む）。これは、デスクトップ ブラウザーと一部のフル モバイル ブラウザー (Obigo など) では機能しますが、Opera Mini や UCWeb などのミニ (プロキシ) ブラウザーでは機能しません。これらのブラウザは、モバイル デバイスではなく、サーバーとプロキシ サーバー間の接続時間を返します。

<meta>tag または Javascriptを使用してページをリロードしようとすると、同じことが起こりますdocument.location。

クライアント接続の速度を検出または測定する方法、またはクライアントが 3G または WiFi などを使用しているかどうか (ミニ ブラウザーで動作するかどうか) を検出または測定する方法はありますか (つまり、ミニ ブラウザーを介して低速の接続を識別できます)?

4

6 に答える 6

6

これは素晴らしい質問です。これまで、ブラウザからクライアントの速度を推定する手法に出くわしたことはありません。ただし、アイデアはあります。これについては数分しか考えていませんが、いくつかのアイデアが得られることを願っています. また、私の冗長性を許してください：

まず、クライアント/サーバーのパフォーマンスを扱う際には、スループットとレイテンシーという 2 つの点を考慮する必要があります。一般に、モバイル クライアントは、デスクトップ クライアントと比較して帯域幅が低くなります (したがって、スループットが低くなります)。さらに、モバイル クライアントの接続はエラーが発生しやすく、待ち時間が長くなる可能性があります。ただし、私の限られた経験では、レイテンシーが高いからといってスループットが低いわけではありません。逆に言えば、レイテンシーが低いからといってスループットが高いわけではありません。

したがって、レイテンシとスループットを区別する必要がある場合があります。クライアントが各 HTTP リクエストでタイムスタンプ (「A」としましょう) を送信し、サーバーが単純にそれをエコー バックするとします。クライアントは、返されたこのタイムスタンプを現在の時刻から差し引いて、リクエストが往復するのにかかった時間を見積もることができます。この時間には、ネットワーク遅延や、サーバーがリクエストを完全に受信するまでにかかった時間など、ほぼすべてが含まれます。

ここで、サーバーが応答本文全体を送信する前に、最初に応答ヘッダーでタイムスタンプ "A" を送り返すとします。また、サーバーの応答をインクリメンタルに読み取ることができると仮定します (例: ノンブロッキング IO。これにはさまざまな方法があります)。これは、サーバーの応答を読み取る前に、エコーされたタイムスタンプを取得できることを意味します。この時点で、クライアント時間「B」からリクエストのタイムスタンプ「A」を差し引いた値が、レイテンシの概算です。これをクライアント時間「B」とともに保存します。

応答の読み取りが完了したら、応答本文のデータ量を新しいクライアント時間「C」から前のクライアント時間「B」を差し引いた値で割った値が、スループットの概算になります。たとえば、C - B = 100ms で、100kb のデータを読み取ったとすると、スループットは 10kb/s になります。

ここでも、モバイル クライアント接続はエラーが発生しやすく、時間の経過とともに強度が変化する傾向があります。したがって、おそらくスループットを 1 回テストする必要はありません。実際、すべての応答のスループットを測定し、クライアントのスループットの移動平均を維持することもできます。これにより、1 つの要求で異常に悪いスループットが原因でクライアントの品質が低下する可能性が低くなり、逆の場合も同様です。

この方法が機能する場合は、クライアントが取得するコンテンツを決定するためのポリシーを決定するだけです。たとえば、「低品質」モードで開始し、一定期間クライアントのスループットが十分に高い場合は、高品質のコンテンツにアップグレードできます。その後、スループットが低下した場合は、低品質にダウングレードします。

編集:いくつかのことを明確にし、スループットの例を追加しました。

于 2011-06-21T18:11:43.563 に答える
4

まず第一に、SSL (HTTPS) を介して実行すると、多くのプロキシのナンセンスを回避できます。また、圧縮なども停止します (これにより、HTML、CSS などの読み込みが速くなる可能性がありますが、既に圧縮されているデータには役立ちません)。

ページをロードする時間は、待ち時間+ (帯域幅×サイズ) です。遅延が不明な場合でも、小さなファイルと大きなファイルを測定すると、帯域幅がわかります。

Let L be latency, B be bandwidth, both unknown.
Let t₁ and t₂ be the measured download times.
In this example, the two sizes are 128k and 256k.

t₁ = L + B × 128                             // sure would be nice if SO had Τεχ
t₂ = L + B × 256
t₂ - t₁ = (L + B × 256) - (L + B × 128)
        = L + B × 256 - L - B × 128
        = 256(B) - 128(B)
        = 128(B)

したがって、時間の差をページ サイズの差で割ると、帯域幅が得られることがわかります。遅延と帯域幅が一定ではないため、単一の測定を行うと、奇妙な結果が生じる場合があります。数回繰り返す (そして、外れ値やばかげた [たとえば、負の] 値を捨てる) と、真の平均帯域幅に収束します。

これらの測定は、任意の AJAX フレームワークを使用して、バックグラウンドで JavaScript で簡単に実行できます。応答を受信した時刻ではなく、現在の時刻を取得し、要求を送信します。リクエスト送信のオーバーヘッドがレイテンシの一部になるように、リクエスト自体は同じサイズにする必要があります。ただし、永続的な接続を無効にするために、おそらく別のホストを使用することをお勧めします。それか、永続的な接続を拒否するようにサーバーを構成しますが、テストファイルに対してのみです。

私は実際には遅延という言葉を少し乱用していると思います。これには、一定のオーバーヘッド (リクエストの送信など) のすべての時間が含まれます。まあ、ペイロードの最初のバイトを受信したいからのレイテンシ。

于 2011-06-23T18:47:19.417 に答える
3

速度やスループットを測定するべきではないと思います。

最初の推測は、クライアントのブラウザである可能性があります。コンピューター用のブラウザーにはさまざまなものがありますが、通常、モバイルデバイス用のブラウザーと同じではありません。

ユーザーが使用しているブラウザを簡単に確認できます。

それでも、推測が間違っている可能性があるため、軽量コンテンツと完全コンテンツを切り替えるオプションを提供する必要があります。

于 2011-06-23T10:42:36.870 に答える
0

これはクライアント側で発見できるものですか？プロキシをバイパスする必要がある場合は、いつでもクライアント側で接続タイプを検出して、それを送り返すことができます。もう1つの方法は、スクリプト化されたメカニズムを介してクライアント側でファイルをダウンロードし、1秒あたりのバイト数を記録して、その情報をサーバー側に返すことです。

于 2011-06-21T15:55:57.400 に答える
0

同じクライアントからの 2 つの要求のサーバー側の時間を比較します。

コンテンツの URL を要求する単純な ajax クエリはどうでしょうか? 最初のリクエストのサーバー側の時間を記録し、クライアントのIPをどこかに保存します（ファイルまたはデータベース）。次に、それをクライアント側のJavaScriptからのリクエストの時間と比較し、2つの時間を比較した後にURLを配信します任意の「速い」または「遅い」時間制限を設定し、適切な速度でコンテンツの URL を配信します。

于 2011-06-22T20:57:09.433 に答える