TCP / IP用語で、オフィスのダウンロード速度リミッターはどのように機能しますか?


8

人々のオフィスを想定し、他のトラフィックをブロックしないように、HTTPダウンロードをインターネット接続速度の最大40%の帯域幅に制限したいと考えています。

「ファイアウォールではサポートされていません」とあり、「以前はNetgear / DLink / DrayTekでそれを行うことができました」という不可避の行があります。

考えてみると、ダウンロードは次のようになります。

HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.

速度は、サーバーがデータを送信する速度と、データを確認する速度によって決まります。

したがって、ダウンロード速度を制限するには、2つの選択肢があります。

1)サーバーにデータをゆっくり送信するように指示します。TCPまたはHTTPでそれを要求するプロトコル機能はないと思います。

2)アップロード速度を制限することで、パケットの確認速度を遅くし、アップロード速度を台無しにします。

デバイスはどのようにこの制限を行いますか?標準的な方法はありますか?


ファイアウォールからLANへの受信パケットの許可速度を制限すると、確認応答が遅くなり、送信側サーバーのTCPスタックでの輻輳処理によって送信速度が遅くなります。ありがとう。私はそれをテスティングでそのように機能させることができます。いくつかの回答に賛成していますが、回答としてマークできるのは1つだけです。
TessellatingHeckler

回答:


11

TCP自体が輻輳制御を実装します。

これらのレートリミッターは、単に制限を超えてパケットを破棄します。TCPはこれを処理し、パケットがすべて到着し、すべて順番に到着するようにします。クライアントはドロップされたパケットに対してACKを送信せず、サーバーによって再送信されます。

サーバーのTCPスタックはパケットを再送信します。また、サーバーとクライアントの間で輻輳が発生していると考えられるため、サーバーは送信レートを少しだけダイヤルバックします。レートリミッターが再びパケットをドロップするまで速度が上がります。


それで、ファイアウォールが/ LAN /インターフェースでHTTPトラフィックを吐き出す速度を制限するQoSポリシーレートを適用する必要がありますか?そして、TCPにそれを処理させます。「それはまた、その送信レートで少しダイヤルバックします」は、私が欠けていた別の部分です。
TessellatingHeckler

2
うん、そうだね。サーバーリンクにデータを投げ続け、QoSが適用される前にデータを飽和させることができます。ただし、適切なTCP市民である限り、その送信速度は、データが実際に通過する速度とおおよその平衡を確立します。レート制限。
シェーンマッデン

はい、TCPは独自の輻輳制御を実装していますが、必ずしもそれほど効果的ではありません。トレントの経験がある人なら誰でもこれを知っています。基本的に、TCP輻輳制御のほとんどの実装は、ネットワーク上に数百のアクティブな接続がある場合に機能しなくなります。
user606723 '30 / 11/11

1
@ user606723トレントに問題がある場合は、出口でパケットシェーパーを使用してそのトラフィックを破棄する必要があります。これにより、torrenterがトラッカーから切り離され、同じtorrentをダウンロードしている他の人々があなたのイングレスを接続で溢れるのを防ぎます。問題が解決しました。
MDMarra

1
@ user606723なぜそうなのか、新しい接続は構築中の接続の状態を何も知らないため、何千もの接続がクイックスタートTCPで常に開始されている場合、輻輳制御は困難な困難を伴います。しかし、何百ものアクティブな接続がありますか?たぶんそれは、低速のホームリンクを行き詰まらよ...
シェーン・マッデンに

5

私が今まで聞いた中で、TCPの固有のスロットリング方法を理解した最も良い説明は、最近のSecurity Nowポッドキャストでした。スティーブギブソンを引用するには:

したがって、普遍的な合意により、TCPはこの非常に賢いプロトコルであり、「スロースタート」と呼ばれる処理を行います。通常、確認応答なしにいくつかのパケットを送信する許可が与えられます。つまり、アイデアをここに移動させましょう。通常、その数は2です。TCPが開始すると、2つのパケットを次々に送信できます。最初の1つが確認されることなく、2番目が送信されます。しかし、それは待ちます。そして、スロットルのルールは、受信した確認ごとに未確認のパケットの数を1つずつ増やすことです。

それについて考えてみましょう。受信した確認応答ごとに、未確認パケットの数を1つ増やすことができます。したがって、合意した開始として、最初に2つのパケットを送信します。彼らは認められます。最初の謝辞です。私たちは自分自身に2つ送信することを許可していました。この最初の確認を受け取ったので、これを1から3増やします。そのため、これ以上の確認応答なしで、さらに3つのパケットを送信できます。以前に送信したものに対する確認が返ってきたら、それを4に増やします。これは「輻輳ウィンドウ」と呼ばれます。これは、回線上で送信されるウィンドウではありません。つまり、受信ウィンドウとは異なります。これは、先に送信できるデータ量を示すTCPヘッダーの16ビットです。これは窓です。それ'

確認応答を受信するたびに送信を許可される未確認パケットの数を増やし続けると、ある時点で制限に達します。このシステムの優れている点は、ルーター間で文字通りリンクする最も弱いリンクよりも速くパケットを送信しようとすると、ある時点で最も弱いリンクが壊れるポイントが見つかるということです。送信しようとしているパケットが速すぎるため、送信しようとしているパケットがドロップされます。そのため、もう一方の端からの確認は、データが送信されなくなったために停止します。

そして、TCPが行うのは、それが受信に失敗した場合です-これは戦略によって異なります。時間の経過とともに、戦略、実際の輻輳回避戦略は大きく異なります。TahoeやRenoのような名前があります。また、動作が何であるかを特定しているグーグルやWikipediaを実行すると、他にもたくさんの名前が表示されます。しかし、アイディアは、送信者が確認が欠落しているためにデータが送信されなくなったことに気づくと、送信レートを素早く削減するというものです。通常、それはそれを半分に分割します。したがって、それは劇的に縮小し、それから増加に戻ります。

つまり、本質的にこれが意味することは、パケットを失うことは「データをこれ以上速く送信することはできません」のシグナリング機能であり、インターネットのすべての接続の両端にあるTCP送信者は常に一種であるということです。 2つのエンドポイント間で利用可能な最大速度、つまり、どこにいても最も弱いリンクよりも速くなるように試み、それらは常にそれを限界まで押し上げています。したがって、パケットを送信する能力よりも弱い場所がどこかにあるとすると、彼らはパケットを送り出すのでそれを見つけるでしょう。送信するデータがあり、高帯域幅の接続が確立されている限り、送信者は送信レート、つまり未処理のパケットの数、確認としてオンザフライで送信できるパケットの数を増やします。戻って、それが押し過ぎるまで積極的にその数を上に動かし続けます。その後、それはかなり後退し、その後再び前進します。

つまり、これはTCP接続間で実際に起こっていることです。たとえば、おそらく何パーセントかはわかりませんが、インターネット上のトラフィックの非常に大きな割合はTCP接続を介しています。カーネル内のすべてのオペレーティングシステム、いわゆるTCPスタックには、これらのカウンターがあります。また、ファイルを送信するとき、大きなファイルをアップロードするとき、またはWebページを受信するときも、反対側のサーバーが同じことを行います。これは、個々の接続ベースで、まだ確認されていないパケットをできるだけ多く押して、失敗または途切れ始めるポイントに到達するまでパケットレートを上げています。その後、それは後退し、物事が回復できるようにしてから、再び動作を再開します。

そして、それは結局のところ、制約を考えると、一種の自己抑制的なシステムになってしまうのです。


3

したがって、ダウンロード速度を制限するには、2つの選択肢があります。

1)サーバーにデータをゆっくり送信するように指示します。TCPまたはHTTPでそれを要求するプロトコル機能はないと思います。

2)アップロード速度を制限することで、パケットの確認速度を遅くし、アップロード速度を台無しにします。

3)ルーター/ファイアウォールデバイスは、受信データをQoSバケットに入れ、要求されたレートでのみそのバケットを空にします。内部のコンピュータはその速度でのみ確認応答を受信するため、受信データはその速度に適応します。また、ときどき(意図的に)ドロップされたパケットは、接続の速度を低下させるのに非常に適しています。

これを処理するデバイスを探す場合は、構成/ドキュメントでQoS(サービスの品質)を探してください。Linux(またはBSD)ボックスもこれに便利です。


これはほとんど理にかなっています。つまり、確認応答の速度を制限し、サーバーが実際よりも遅い速度でLANデバイスに送信しているように見せかけることによって、この方法は制限されますか?それで、最初に接続を埋めるバーストがあり、その後ではないでしょうか?
TessellatingHeckler

1
@TessellatingHecklerはい、それだけです。また、「バースト」は、en.wikipedia.org / wiki / Slow-startの厚意による非常に大きなバーストであってはなりません。
Jeff Ferland

2

QoS(サービス品質)制限をサポートするファイアウォールまたはデバイスを使用している。

Linuxシステムを構築してオフィスゲートウェイとして機能させ、トラフィックシェーピングを使用してこれを実現できます。複数のNICをインストールするだけで、すべてのマシンがゲートウェイとしてポイントします。

おまけとして、トラフィックを軽減するためにプロキシサーバーを構成することもできます。イカのようなもの。これを実行できるターンキールーティングアプライアンスのディストリビューションもあるかもしれません。


QoSはどのように役立ちますか?デバイスがダウンロードにQoSを適用できるようになるまでに、着信トラフィックはすでにインターネット接続を介して到着しており、そうしている間はブロックされる可能性があります。QoSは発信トラフィックに適用できますが、着信トラフィックについては何もできません。なぜなら、トラフィックを確認するまでには遅すぎるからです。
TessellatingHeckler

3
それはあなたがそれを制御できる場所でトラフィックを形作ることができます。データを取得する速度を制限するようにリモートサーバーに指示する方法はありませんが、入力ポイントでそれを下げることができます。それ以外の場合は、ネットワークのフィードへのトラフィックシェーピングについてプロバイダーに相談する必要があります。
Bart Silverstrim

また、プロキシサーバーは一部の輻輳を緩和するのにも役立ちます。しかし、それ以外の場合は、入口点でそれを形成する必要があります。
Bart Silverstrim

私の元の質問は、トラフィックがボトルネックを通過した後に適用できる制御が発生するため、イングレスポイントでは形成できないようです。どのような量のテクノロジーがそれをどのように処理しますか?「LinuxなどでQoSを適用する」や「トラフィックシェーピングを使用する」というのは実際には何をすべきかですが、それがどのように役立つかについての説明を探していました。(そして現在、他の返信にいくつかあります)。
TessellatingHeckler

@TessellatingHeckler:私が好む方法では、パケットをドロップせずに送信サーバーにスローダウンするように実際に通知するECNの使用も有効にます。この方法は、WANインターフェースで入力フィルターを使用する代わりに、LANインターフェースから出るパケットにREDなどのレートリミッターを適用することです。
Zan Lynx

2

HTTPプロトコルは、使用される帯域幅を制限する機能を提供していません。制限する場合でも、それはクライアント側の設定であり、ネットワーク管理者が制御することはできません。

帯域幅制限(「Quality Of Service」とも呼ばれます)は通常、ルーターとファイアウォールで管理され、ネットワークとの間のすべての送受信トラフィックを処理します。これをサポートするものを使用すると、通常、「1台のクライアントコンピューターで使用可能なすべての帯域幅の最大10%を使用させる」、または「FTPよりもSMTPに優先順位を付けて、誰かが大量のダウンロードを実行している場合でもメールが流れるようにする」などのポリシーを設定できます。 」

これがどの程度正確に行われるかは、使用するルーター/ファイアウォールによって異なりますが、最も基本的な方法は、構成された制限を超えるパケットを破棄することです。TCPは確実に再送信され、最終的にはボトルネックを通過できるようになります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.