TCP window size for throughput
100 Mbps over a 50 ms round trip needs 625,000 bytes in flight, far beyond the classic 65,535-byte TCP window: enter your target speed and RTT to get the window size and the scaling shift that keep the link full. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Throughput mbps
- 100
- Rtt ms
- 50
- Window bytes
- 625,000
- Window bits
- 5,000,000
- Window kib
- 610.3515625
- Window mib
- 0.5960464478
Long fat networks—high bandwidth times high latency—starve TCP unless the receive window is large enough to keep the pipe full for a full round trip. Network engineers, SREs, and students sizing WAN links, satellite paths, or cross-region cloud tunnels need the bandwidth-delay product, not a rule of thumb. This TCP window size for throughput calculator accepts target throughput in megabits per second and path RTT in milliseconds, multiplies them by the exact conversion factor that yields bytes, and returns the required window in bytes, bits, kibibytes, and mebibytes. It also flags when the classic 65 535-byte unscaled TCP window is too small, recommends the minimum RFC 1323 Window Scale shift, and shows the maximum throughput you could still achieve without scaling at the same RTT.
Why window size equals bandwidth times delay
TCP can only have outstanding unacknowledged data up to the receiver’s advertised window (and the sender’s congestion window). On a path with capacity C bits per second and round-trip time R seconds, the amount of data that must be in flight to fully utilize the link is C times R—the bandwidth-delay product. Divide by eight to express that product in bytes; that number is the minimum receive window needed for steady-state full-rate transfer if congestion control is not the limiter.
In convenient engineering units, megabits per second times milliseconds times one hundred twenty-five yields bytes, because one megabit per second is one hundred twenty-five thousand bytes per second and a millisecond is one thousandth of a second. Example: one hundred megabits per second at fifty milliseconds needs six hundred twenty-five thousand bytes in flight. Without that buffer depth, the sender empties its window, stops, and waits for acknowledgments, so measured goodput falls far below line rate even though the physical link is fine.
Where a TCP window throughput calculator earns its keep
WAN and data-center designers use a TCP window size calculator before upgrading circuits so receive buffers and OS defaults match the new BDP instead of guessing. Cloud architects sizing cross-region database replication or object storage transfers convert published RTT and target megabits into concrete buffer bytes for load-test plans. Satellite and mobile backhaul teams show why multi-megabit links still crawl when RTT is hundreds of milliseconds and Window Scale is off.
Classroom and certification labs need a deterministic oracle for bandwidth-delay product homework that matches textbook units without spreadsheet errors. Failed validation does not consume balance.
What you can do with it
WAN and LFN capacity planning
Convert target Mbps and measured RTT into the receive window (and scale shift) required to fill a long fat network path.
Cross-region cloud transfer sizing
Size socket buffers for database, backup, or object replication so throughput is not capped by a 64 KiB unscaled window.
FAQ
What is the bandwidth-delay product (BDP)?
BDP is link rate times RTT: the data that must be in flight to keep the path full. TCP’s advertised window should be at least that many bytes (absent congestion limits).
Does this model packet loss or congestion control?
No. It only sizes the window from BDP so the pipe can fill. Loss, RTT variance, and congestion windows are separate; use other tools for those.
How do I calculate the TCP window size from Mbps and RTT?
Multiply the speed in megabits per second by the round-trip time in milliseconds and by 125 to get bytes. At 100 Mbps and 50 ms, that is 625,000 bytes that must be in flight to keep the link full.
When do I need TCP window scaling?
Whenever the result is larger than 65,535 bytes, the most a TCP window can advertise without scaling. For 625,000 bytes the smallest Window Scale shift is 4, which raises the ceiling to 1,048,560 bytes.
How fast can a transfer go without window scaling?
At most 65,535 bytes per round trip. On a 50 ms path that caps the transfer at 10.4856 Mbps, however fast the physical link is, which is why long-distance copies crawl when scaling is off.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
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)Example request
{
"throughput_mbps": 100,
"rtt_ms": 50
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.tcp_window_for_throughput",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Non-positive inputs fail with invalid_input and are not billed.
Why window size equals bandwidth times delay
This endpoint only sizes the window from BDP; it does not model packet loss, slow start, or bufferbloat, which are separate knobs in capacity planning.
Input contract, Window Scale, and response fields
Pair the result with your stack’s sysctl or socket option for receive buffer and Window Scale; this calculator does not push configuration to hosts. POST a JSON body with two required positive finite numbers: throughput_mbps, the target goodput or link rate in megabits per second, and rtt_ms, the end-to-end round-trip time in milliseconds. Each field may arrive as a JSON number or as a numeric string. Missing fields, non-finite values, zero, and negative values fail with invalid_input and a message that names the field; those failures are not billed. On success the body echoes the inputs, returns window_bytes, window_bits, window_kib, and window_mib for the BDP, classic_max_window_bytes equal to sixty-five thousand five hundred thirty-five, window_scale_needed true when the BDP exceeds that classic limit, window_scale_shift as the smallest RFC 1323 shift that multiplies the sixteen-bit window enough to cover the BDP (capped at fourteen), scaled_max_window_bytes as sixty-five thousand five hundred thirty-five times two to that shift, max_throughput_mbps_without_scale for the same RTT if you stay unscaled, and a short formula string. Example: throughput_mbps one hundred and rtt_ms fifty yields six hundred twenty-five thousand window_bytes and window_scale_needed true.
Where a TCP window throughput calculator earns its keep
Keep loss, pacing, and congestion control in your own tools; use this endpoint as the single source of truth for the BDP arithmetic so docs, runbooks, and edge workers all plan the same way.
Integration use cases
Teaching bandwidth-delay product
Give students a deterministic BDP oracle that returns window_bytes and explains when RFC 1323 Window Scale is mandatory.
Technical questions
How do I calculate TCP window size for a target throughput?
Send positive throughput_mbps and rtt_ms. The API returns window_bytes = throughput_mbps × rtt_ms × 125 (the bandwidth-delay product in bytes), plus bits, KiB, and MiB.
When is Window Scale required?
When window_bytes exceeds 65535, the classic unscaled TCP window. The response sets window_scale_needed true and gives the minimum window_scale_shift (RFC 1323).
What does the TCP window throughput calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.