ForHosting KIT · Strumenti per sviluppatori

Calcolatore finestra TCP per throughput

100 Mbps con 50 ms di andata e ritorno richiedono 625.000 byte in transito, molto oltre la classica finestra TCP di 65.535 byte: indichi velocità e RTT e ottenga la finestra e il fattore di scala che riempiono il collegamento. Gratis nel suo browser.

Gratis
Funziona nel suo browser
Senza registrazione
I suoi dati restano sul dispositivo

Esegui gratis nel browser Vedi l'API

Usalo da WebAPIEmailTelegramApp presto

Esempio risolto

Se inserisce

Throughput (Mbps): 100
Rtt ms: 50

Ottiene

Finestra (byte): 625.000
Finestra (bit): 5.000.000
Finestra (KiB): 610,3515625
Finestra (MiB): 0,5960464478

Le reti lunghe e ad alta capacità —elevata banda per elevata latenza— affamano TCP se la finestra di ricezione non è abbastanza grande da tenere il canale pieno per un round-trip completo. Ingegneri di rete, SRE e studenti che dimensionano collegamenti WAN, percorsi satellitari o tunnel cloud tra regioni hanno bisogno del prodotto banda-ritardo, non di una regola empirica. Questo calcolatore della dimensione della finestra TCP per il throughput accetta il throughput obiettivo in megabit al secondo e l’RTT del percorso in millisecondi, li moltiplica per il fattore esatto che produce byte e restituisce la finestra richiesta in byte, bit, kibibyte e mebibyte. Segnala anche quando la finestra TCP classica di 65535 byte senza scale è troppo piccola, raccomanda lo shift minimo di Window Scale secondo RFC 1323 e mostra il throughput massimo ancora raggiungibile senza scale allo stesso RTT.

Perché la dimensione della finestra è banda per ritardo

TCP può avere dati in attesa di riconoscimento solo fino alla finestra annunciata dal ricevitore (e alla finestra di congestione del mittente). Su un percorso con capacità C bit al secondo e tempo di andata e ritorno R secondi, la quantità di dati che deve essere in volo per utilizzare appieno il collegamento è C per R — il prodotto banda-ritardo.

Dividete per otto per esprimere quel prodotto in byte; quel numero è la finestra di ricezione minima per un trasferimento a pieno regime se il controllo di congestione non è il limite. In unità di ingegneria comode, megabit al secondo per millisecondi per centoventicinque producono byte, perché un megabit al secondo sono centoventicinquemila byte al secondo e un millisecondo è un millesimo di secondo. Esempio: cento megabit al secondo a cinquanta millisecondi richiedono seicentoventicinquemila byte in volo.

Senza quella profondità di buffer, il mittente svuota la finestra, si ferma e attende gli acknowledgement, così il goodput misurato scende ben sotto la line rate anche se il collegamento fisico è sano.

Dove un calcolatore di finestra TCP e throughput conviene

I progettisti di WAN e data center usano un calcolatore della dimensione della finestra TCP prima di potenziare i circuiti affinché buffer di ricezione e default del SO corrispondano al nuovo BDP invece di indovinare. Gli architetti cloud che dimensionano la replica di database tra regioni o i trasferimenti di object storage convertono RTT pubblicato e megabit obiettivo in byte di buffer concreti per piani di load test.

I team di backhaul satellitare e mobile mostrano perché collegamenti multi-megabit strisciano ancora quando l’RTT è di centinaia di millisecondi e Window Scale è disattivato. Aule e laboratori di certificazione necessitano di un oracolo deterministico per i compiti sul prodotto banda-ritardo che rispetti le unità del manuale senza errori di foglio di calcolo. La validazione fallita non consuma saldo.

Casi d'uso

Pianificazione di capacità WAN e LFN

Convertite Mbps obiettivo e RTT misurato nella finestra di ricezione (e nello scale shift) necessaria per riempire un percorso di rete lunga e ad alta capacità.

Dimensionamento trasferimenti cloud inter-regione

Dimensionate i buffer di socket per replica di database, backup o oggetti affinché il throughput non sia limitato da una finestra non scalata di 64 KiB.

Domande frequenti

Che cos’è il prodotto banda-ritardo (BDP)?

Il BDP è la velocità del collegamento per l’RTT: i dati che devono essere in volo per tenere il percorso pieno. La finestra annunciata di TCP deve essere almeno di quei byte (in assenza di limiti di congestione).

Questo modello include perdita di pacchetti o controllo di congestione?

No. Dimensiona solo la finestra dal BDP affinché il canale possa riempirsi. Perdita, varianza di RTT e finestre di congestione sono separate; usate altri strumenti per quelle.

Come si calcola la dimensione della finestra TCP da Mbps e RTT?

Moltiplichi la velocità in megabit al secondo per il tempo di andata e ritorno in millisecondi e per 125 per ottenere i byte. Con 100 Mbps e 50 ms servono 625.000 byte in transito per riempire il collegamento.

Quando serve lo scaling della finestra TCP?

Quando il risultato supera 65.535 byte, il massimo che una finestra TCP può annunciare senza scaling. Per 625.000 byte lo spostamento minimo di Window Scale è 4, che porta il tetto a 1.048.560 byte.

Quanto può andare veloce un trasferimento senza scaling della finestra?

Al massimo 65.535 byte per andata e ritorno. Su un percorso di 50 ms il trasferimento si ferma quindi a 10,4856 Mbps, per quanto veloce sia il collegamento fisico: per questo le copie a lunga distanza rallentano senza scaling.

Strumenti correlati

Per sviluppatori — accesso via API

Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.

Endpoint

POSThttps://api.kit.forhosting.com/dev/tcp-window-for-throughput

Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.

Chiamala dal tuo 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)

Esempio di richiesta

{
  "throughput_mbps": 100,
  "rtt_ms": 50
}

Esempio di risposta

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.tcp_window_for_throughput",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.

Prezzi

per richiesta$0.002

Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.

Errori

HTTP	Codice	Significato
`401`	`unauthorized`	Chiave API mancante o non valida: controlla l'header Authorization.
`402`	`insufficient_balance`	Credito esaurito: ricarica per continuare a eseguire attività.
`404`	`unknown_type`	Tipo di attività sconosciuto: controlla il campo type della richiesta.
`429`	`rate_limited`	Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo.

Note tecniche

Gli input non positivi falliscono con invalid_input e non vengono addebitati.

Perché la dimensione della finestra è banda per ritardo

Questo endpoint dimensiona solo la finestra dal BDP; non modella perdita di pacchetti, slow start o bufferbloat, che sono leve separate nella pianificazione di capacità.

Contratto di ingresso, Window Scale e campi di risposta

Abbinate il risultato al sysctl o all’opzione di socket del vostro stack per il buffer di ricezione e Window Scale; questo calcolatore non spinge configurazione sugli host. Inviate un corpo JSON con POST con due numeri finiti positivi obbligatori: throughput_mbps, il goodput o la velocità di collegamento obiettivo in megabit al secondo, e rtt_ms, il tempo di andata e ritorno end-to-end in millisecondi. Ogni campo può arrivare come numero JSON o come stringa numerica. Campi mancanti, valori non finiti, zero e negativi falliscono con invalid_input e un messaggio che nomina il campo; tali fallimenti non sono addebitati. In caso di successo il corpo riecheggia gli input, restituisce window_bytes, window_bits, window_kib e window_mib per il BDP, classic_max_window_bytes pari a 65535, window_scale_needed true quando il BDP supera quel limite classico, window_scale_shift come lo shift RFC 1323 minimo che moltiplica abbastanza la finestra a sedici bit per coprire il BDP (massimo quattordici), scaled_max_window_bytes come 65535 per due elevato a quello shift, max_throughput_mbps_without_scale per lo stesso RTT se restiate senza scale, e una breve stringa di formula. Esempio: throughput_mbps cento e rtt_ms cinquanta producono seicentoventicinquemila window_bytes e window_scale_needed true.

Dove un calcolatore di finestra TCP e throughput conviene

Poiché l’implementazione è pure parse di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello e senza rete in uscita. Lasciate perdita, pacing e controllo di congestione nei vostri strumenti; usate questo endpoint come unica fonte di verità per l’aritmetica del BDP così che documentazione, runbook e worker di edge pianifichino allo stesso modo.

Casi di integrazione

Insegnamento del prodotto banda-ritardo

Offrite agli studenti un oracolo BDP deterministico che restituisce window_bytes e spiega quando Window Scale RFC 1323 è obbligatorio.

Domande tecniche

Come si calcola la dimensione della finestra TCP per un throughput obiettivo?

Inviate throughput_mbps e rtt_ms positivi. L’API restituisce window_bytes = throughput_mbps × rtt_ms × 125 (il prodotto banda-ritardo in byte), più bit, KiB e MiB.

Quando è richiesto Window Scale?

Quando window_bytes supera 65535, la finestra TCP classica non scalata. La risposta imposta window_scale_needed a true e fornisce il window_scale_shift minimo (RFC 1323).

Quanto costa il calcolatore di finestra TCP e throughput?

Lo strumento nel browser è gratuito. Le richieste API usano saldo KIT prepagato a $0.002 per chiamata riuscita; l’input non valido non viene addebitato.

Leggi la documentazione completa del KIT →

Esegui gratis nel browser

Esempio risolto

Perché la dimensione della finestra è banda per ritardo

Dove un calcolatore di finestra TCP e throughput conviene

Casi d'uso

Pianificazione di capacità WAN e LFN

Dimensionamento trasferimenti cloud inter-regione

Domande frequenti

Strumenti correlati

Per sviluppatori — accesso via API

Endpoint

Chiamala dal tuo stack

Esempio di richiesta

Esempio di risposta

Prezzi

Errori

Note tecniche

Perché la dimensione della finestra è banda per ritardo

Contratto di ingresso, Window Scale e campi di risposta

Dove un calcolatore di finestra TCP e throughput conviene

Casi di integrazione

Insegnamento del prodotto banda-ritardo

Domande tecniche

grazie