TCP では、受信側は送信されたパッケージの受信を定期的に確認します。したがって、特定のダウンストリーム帯域幅を実現するには、常に最低限のアップストリーム帯域幅が必要です。
私が探しているのは、特定のダウンストリーム帯域幅に必要なアップストリームを計算するための要素です。さまざまなウィンドウ サイズがあり、TCP にはおそらくこの計算を困難にする他の要素があることは承知しています。しかし、少なくとも近似値を取得できるデフォルトのシナリオがあるかもしれません。
答え1
それは他の多くの要因に依存するため、答えるのが難しい質問です。非常に具体的な答えを得ようとするのは難しく、少なくとも私にとっては、説明しようとするのはさらに困難です。
エンドツーエンドのリンクがウィンドウを最大に拡大できるほど安定していると仮定すると、最大ウィンドウ サイズごとに 1 つの ACK が必要であると言えます。一般的な最大ウィンドウ サイズは 64 KB です。少なくとも Windows のデフォルトは 64 KB だと思います。これはレジストリ キーによって設定されます。
それを知った上で、ラウンドトリップ時間を知る必要があります。なぜなら、RTT ごとに受信するデータの最大ウィンドウ サイズは 1 つだけであり、データが届く方法とそれを確認する方法が 1 つしかないからです。ここで、衛星経由の 1 つの TCP ソケットに必要なアップストリームを計算しようとしているかのように考えてみましょう。
RTT = ~500ms
最大ウィンドウサイズ = 64KB
(64KB * 8)/.5 = 最大ダウンロード速度は 1Mbps になります。8 を掛けるのは、もちろんバイト値をビットに変換するためです。
ところで、ウィンドウ サイズはバッファと呼ばれることが多く、TCP スループットの計算は (RxBuffer/RTT = Througput) として与えられます。次に、アップストリームを計算する必要があります。上記のすべての情報から答えは明らかです。送信者に返すには、1 秒あたり 2 つの ACK が必要です。これらの ACK は、20Bs + 20Bs * 8 (IP + TCP ヘッダー)、1 つあたり 320bps です。したがって、500ms の RTT と最大 RxBuffer 64KB の接続では、ダウンロードは 1Mbps、アップロードは 640bps 以下を期待する必要があります。
これで、正しい方向に進んでいただければ幸いです。読み返してみれば、私自身も混乱してしまいました...