web-dev-qa-db-ja.com

中国のウェブサイトからのビデオを見ることによるルームメイトの遅れているインターネット接続。 QoSは問題を修正できますか?

私のルームメイトは中国からの留学生で、その地域に拠点を置くWebサイトを使用してオンラインで中国のテレビ番組を見るのが好きです(私たちは米国東海岸にいます)。しかし、それは私たちのネットワークの待ち時間を途方もなく高くし、4.2.2.2にpingを実行すると約400msに達し、100から1000+の範囲になります(通常は20-40msの範囲です)。残念ながら、彼女は問題について馬鹿げたことをしたいので、私は彼女のコンプライアンスを必要としないこの問題を修正する方法を見つけなければなりません。

私の現在のルーター(Netgear N150 WPN824N)は、QoSまたはそれを備えた一般的なカスタムファームウェア(AFAIK)をサポートしていません。そこで、QoSが組み込まれたより高価なルーターか、Tomato、dd-wrtなどをサポートするより安価なルーターの購入を検討していました。しかし、問題が何であるか、またはQoSがそれを助けるかどうか(つまり、お金を使う前に理想的に知りたいこと)は正確にはわかりません。最も可能性の高い犯人のウェブサイトtv.sohu.comは英語ではなく、ほとんどの場合、地域が制限されたビデオコンテンツがあります。したがって、実際にテストできるのは、サイト自体への遅延(私が住んでいる場所から約350ミリ秒)だけです。それが帯域幅の問題なのか、サイトがなんらかの奇妙なカスタムプロトコルを使用しているのか、それとも他の何かがここでの潜在的な要因なのかはわかりません。私はネットワーク担当者ではないので、高帯域幅の消費以外では、このようにネットワークパフォーマンスに影響を与える可能性のある要因については本当に暗闇に包まれています。

とはいえ、そもそも私は平凡なインターネット接続を持っていることを知っています。 Steamからゲームをダウンロードしようとすると、約2.5メガバイト/秒でピークに達する可能性があり、これにより大きなラグが発生します。しかし、2.5 mbpsは多くの帯域幅であり、そのWebサイトがそれほど多くを消費しているとは想像できません。

7

中国のウェブサイトからのビデオを見ることによるルームメイトの遅れているインターネット接続。 QoSは問題を修正できますか?

私はあなたの話全体を読んでいませんでしたが、あなたが尋ねた質問に基づくと、答えは一般的に実際にはではありません。 QoSは、いくつかの理想的な状況では、特定の優先度の高いサービス(Voice over IPなど)を使用していて、パケットが適切である場合、部分的に問題に対処する場合がありますタグ付きで、アップストリームプロバイダーはQoSを尊重します。ただし、パケットとルームメイトのパケットの優先度が同じである場合は役に立ちません。

必要なのは、ある種のアクティブキュー管理です。

ルームメイトがビデオを見るとどうなりますか?さて、あなたの共有ルーター/モデムによって大量のデータが受信されます。モデムが受信できる速度で入ってくるこのデータの損失を防ぐために、モデム内にすべてのパケットデータをキューに入れるより大きな内部バッファを作成します。

これを行う必要があるのは、IPパケットを順不同で複数の場所(ダウンロード、ルームメイトのダウンロードなど)から受信し、ピースをまとめてTCPパケット全体を形成する必要があるためです。したがって、パケットの損失を回避するためにこの巨大なバッファを作成します。そうしないと、小さなバッファを使用すると、一部のパケットをドロップする必要があり、データの再送信が必要になる可能性があります。

残念ながら、バッファが特定のサイズを超えると、バッファを持つことの利点はその欠点よりも重要になります。 「肥大化した」バッファの主な欠点は、パケットの受信に伴う膨大なレイテンシがあることです。

レイテンシーとは、データを送信または受信するアプリケーションが、データが適切に送信または受信されたことを確認するために非常に長い時間待機する必要があることを意味します。 TCPソケットのデータは、「OK、わかりました!」を確認する方法として反対側で「確認」されているため、もう一方の端は仮定一定の待ち時間の後、パケットが失われ、とにかく再送信を試みます。したがって、大きなバッファの目的は再送信を防ぐことでしたが、そうすることを求めて、それ再送信が発生します!!!各再送信は、消費/浪費される帯域幅が増え、遅延が増えます。

アクティブキュー管理は、概念的には、バッファのサイズをインテリジェントに制限しようとするソリューションの一種です。バッファをできるだけ小さくし、ほとんどのデータが順不同のパケットを待つことによって失われるのを防ぐのに十分な大きさにすることで、バッファ膨張

研究者が何年にもわたって試みてきた(そして2012年5月に部分的にしか成功しなかった)のは、手動のユーザー設定や調整なしで適切なアクティブキュー管理(AQM)を実装するアルゴリズムを設計することです(時間と手間がかかります)。キューサイズのバランスを適切に取り、パケット損失を最小限に抑え、同時に遅延を最小限に抑える一種の「魔法の弾丸」です。

これまでのところ、ホームルーターで大成功を収めているのは、Linuxカーネルに最近追加されたControlled Delay(CoDel)Active QueueManagementだけです。

CoDelは、パケットの遅延(遅延)を制御するため、非常に便利です。 どのようにこれを行うかは、この質問には少し技術的すぎます。

あなたがそれを読むことができるようにCoDelのいくつかのリンク:

bufferbloat.netのCoDel

CeroWRT

codelに関するJim Gettysの記事

編集:QoSはソリューションの半分にすぎません。ポートベースのQoS(たとえば、パケットに高い優先度を与える)は、これまでのところしかかかりません。バッファの膨張はまったく減少せず、レイテンシは依然として高くなります。ただし、パケット損失はわずかに減少する可能性があります。

CoDelQoSの組み合わせ、ルーター上のlaCeroWRTは、本当に最良のアプローチです。

5
allquixotic

ルームメイトがビデオをストリーミングしているときにのみ問題が発生することを100%確信している場合は、QoSがこの問題の解決に役立ちます。

「中国からの不気味なプロトコル」や、待ち時間を台無しにする可能性のあるものはありません。これはすべて、接続を飽和させることです。接続が処理できるよりも多くのパケットがキューに入れられると、すべてのパケットは「順番を待つ」必要があり、これには明らかに400ミリ秒かかります。

QoSを使用することにより、(自分用に)十分なスペースを確保して、ストリーミングビデオ用の大量のパケットの横にキューイングすることなくパケットが通過できるようにすることができます。

0
Tanner Faulkner

まず、特定の習慣があなたの生活にどのように悪影響を及ぼしているかについて、ルームメイトと話してみます。それ以外では、はいQoSが問題を解決します。彼女のPC、特定のサイト、またはワイヤレスクライアントなどに帯域幅を制限することができます。 DD-WRTには、非常に詳細な構成を可能にする優れたQoSインターフェイスがあります。ただし、新しいファームウェアでルーターを構成/フラッシュする方法に関する技術的な知識が必要です。 DD-WRT Webサイトには詳細なチュートリアルがあり、このような状況での優れたリソースになります。

DDWRTルーターデータベース、購入したものがサポートされていることを確認してください。

0
CodeMonkey