TCPウィンドウサイズ計算
100 Mbpsで往復50 msの経路には625,000バイトの送信中データが必要で、従来のTCPウィンドウ65,535バイトを大きく超えます。速度と往復時間から必要なウィンドウとスケール値が分かります。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- スループット (Mbps)
- 100
- Rtt ms
- 50
- ウィンドウ (バイト)
- 625,000
- ウィンドウ (ビット)
- 5,000,000
- ウィンドウ (KiB)
- 610.3515625
- ウィンドウ (MiB)
- 0.5960464478
帯域が高く遅延も大きいロングファットネットワークでは、往復遅延のあいだパイプを満たせるほど受信ウィンドウが大きくなければTCPは飢餓状態になります。WAN回線、衛星経路、リージョン間クラウドトンネルを設計するネットワーク技術者、SRE、学生には経験則ではなく帯域遅延積が必要です。このTCPウィンドウサイズ対スループット計算は、目標スループット(メガビット毎秒)と経路RTT(ミリ秒)を受け取り、バイトに換算する正確な係数を掛け、必要なウィンドウをバイト・ビット・キビバイト・メビバイトで返します。また、スケールなしの古典的TCPウィンドウ65535バイトでは不足する場合を示し、RFC 1323の最小Window Scaleシフトを提案し、同じRTTでスケールなしでも到達可能な最大スループットを示します。演算は純粋で決定的です。
ウィンドウサイズが帯域と遅延の積になる理由
TCPが未確認のまま送信できるデータ量は、受信側が広告するウィンドウ(および送信側の輻輳ウィンドウ)までです。容量Cビット毎秒、往復時間R秒の経路で回線を使い切るには、飛行中にC×Rのデータが必要です。これが帯域遅延積です。 8で割るとバイト単位になり、輻輳制御が上限でない限り定常状態でフルレート転送に必要な最小受信ウィンドウになります。
実務単位では、メガビット毎秒×ミリ秒×125がバイトになります。1メガビット毎秒は1秒あたり12万5000バイト、1ミリ秒は1000分の1秒だからです。例:100メガビット毎秒で50ミリ秒なら、飛行中に62万5000バイトが必要です。
このバッファ深さがないと送信側はウィンドウを使い切り停止して確認応答を待ち、物理回線が健全でも測定goodputは回線レートを大きく下回ります。パケット損失、slow start、bufferbloatは容量計画の別ノブであり、ここではモデル化しません。
TCPウィンドウスループット計算が役立つ場面
WANやデータセンター設計者は回線増強前にTCPウィンドウサイズ計算を使い、受信バッファとOS既定値を新しいBDPに合わせます。リージョン間のデータベース複製やオブジェクト転送を設計するクラウドアーキテクトは、公開RTTと目標メガビットを負荷試験計画用の具体的バッファバイトに変換します。
衛星・モバイルバックホールチームは、RTTが数百ミリ秒でWindow Scaleが無効だとマルチメガビット回線でも遅い理由を示せます。教室や資格ラボは、教科書単位に一致し表計算ミスのない帯域遅延積の決定的オラクルを必要とします。検証失敗は残高を消費しません。
活用例
WAN・LFNの容量計画
目標Mbpsと測定RTTを、ロングファットな経路を満たすのに必要な受信ウィンドウ(およびスケールシフト)に変換します。
リージョン間クラウド転送のサイジング
データベース複製・バックアップ・オブジェクト用ソケットバッファを決め、64 KiBの非スケールウィンドウでスループットが頭打ちにならないようにします。
よくある質問
帯域遅延積(BDP)とは何ですか?
BDPは回線レート×RTTで、経路を満たすために飛行中であるべきデータ量です。輻輳上限がなければ、TCPの広告ウィンドウはそのバイト数以上であるべきです。
パケット損失や輻輳制御もモデル化しますか?
いいえ。 パイプが満たせるようBDPからウィンドウだけを見積もります。損失、RTT変動、輻輳ウィンドウは別です。それらには他のツールを使ってください。
MbpsとRTTからTCPウィンドウサイズはどう計算しますか?
メガビット毎秒の速度に往復時間のミリ秒を掛け、さらに125を掛けるとバイト数になります。100 Mbpsで50 msなら、回線を埋めるには625,000バイトが必要です。
ウィンドウスケールが必要になるのはいつですか?
結果がスケールなしの上限である65,535バイトを超えるときです。625,000バイトなら最小のシフト値は4で、上限は1,048,560バイトまで広がります。
ウィンドウスケールなしではどこまで速度が出ますか?
1往復あたり最大65,535バイトしか送れません。往復50 msの経路では、回線がどれほど速くても10.4856 Mbpsが上限になり、遠距離の転送が遅くなる原因になります。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/dev/tcp-window-for-throughput \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"throughput_mbps":100,"rtt_ms":50}'const res = await fetch("https://api.kit.forhosting.com/dev/tcp-window-for-throughput", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"throughput_mbps": 100,
"rtt_ms": 50
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/tcp-window-for-throughput",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"throughput_mbps": 100,
"rtt_ms": 50
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/tcp-window-for-throughput", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"throughput_mbps":100,"rtt_ms":50}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"throughput_mbps":100,"rtt_ms":50}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/tcp-window-for-throughput", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"throughput_mbps": 100,
"rtt_ms": 50
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.tcp_window_for_throughput",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
正でない入力はinvalid_inputで失敗し、課金されません。
ウィンドウサイズが帯域と遅延の積になる理由
本エンドポイントはBDPからウィンドウだけを見積もります。
入力契約、Window Scale、応答フィールド
結果は受信バッファとWindow Scale用のsysctlやソケットオプションと組み合わせてください。本計算はホストへ設定を書き込みません。POSTするJSON本体には、正の有限数が2つ必須です。throughput_mbpsはメガビット毎秒の目標goodputまたは回線レート、rtt_msはエンドツーエンドの往復時間(ミリ秒)です。各フィールドはJSON数値でも数値文字列でも構いません。欠落、非有限、ゼロ、負の値はinvalid_inputとフィールド名付きメッセージで失敗し、課金されません。成功時は入力をエコーし、BDPとしてwindow_bytes・window_bits・window_kib・window_mibを返し、classic_max_window_bytesは65535、BDPがこの古典上限を超えるとwindow_scale_neededがtrue、window_scale_shiftはBDPを覆う最小のRFC 1323シフト(上限14)、scaled_max_window_bytesは65535×2のそのシフト乗、max_throughput_mbps_without_scaleは同一RTTでスケールなしの最大スループット、短いformula文字列も返します。例:throughput_mbpsが100、rtt_msが50ならwindow_bytesは625000でwindow_scale_neededはtrueです。
TCPウィンドウスループット計算が役立つ場面
実装はpure parseティアAのため、成功呼び出しは公開の基本価格$0.002で、モデルトークンも外向き通信もありません。損失・ペーシング・輻輳制御は自前ツールに任せ、BDP算術の単一の真実源として本エンドポイントを使い、ドキュメント・ランブック・エッジワーカーが同じ計画になるようにしてください。
連携の活用例
帯域遅延積の教育
window_bytesを返し、RFC 1323 Window Scaleが必須になるタイミングを説明する決定的BDPオラクルを学生に提供します。
技術的な質問
目標スループットに対するTCPウィンドウサイズはどう計算しますか?
正のthroughput_mbpsとrtt_msを送ってください。APIはwindow_bytes = throughput_mbps × rtt_ms × 125(バイト単位の帯域遅延積)とビット、KiB、MiBを返します。
Window Scaleはいつ必要ですか?
window_bytesが古典的な非スケールTCPウィンドウ上限65535を超えるときです。応答はwindow_scale_neededをtrueにし、最小のwindow_scale_shift(RFC 1323)を示します。
TCPウィンドウスループット計算の料金は?
ブラウザツールは無料です。APIリクエストは成功1回あたり$0.002の前払いKIT残高を使います。無効な入力は課金されません。