TCP ACK e delayed ACK in Windows 11 25H2

Risposta breve

TcpAckFrequency e TcpDelAckTicks controllano le conferme TCP a livello di interfaccia specifica. La lettura dei parametri e gli intervalli sono confermati; ridurre il ritardo ACK non garantisce un guadagno e aumenta il numero di pacchetti inversi.

Cosa è stato verificato

È stato verificato il percorso dei parametri per l’interfaccia di rete, i valori predefiniti, gli intervalli e l’effetto sulle regole di conferma TCP.

Ambito della ricerca

Windows 11 25H2 build 26200.9168, parametri TCP a livello di interfaccia. Reti con perdite, Wi-Fi, VPN e server diversi non sono stati inclusi nelle misurazioni controllate.

Metodologia

Analisi dei componenti TCP e della traccia di sistema, verifica della conversione dei valori e confronto con la documentazione pubblica Microsoft.

Percorso canonico

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface-GUID}

Value	Type	Default	Эффективный диапазон	Роль
TcpAckFrequency	REG_DWORD	2	0..255	число full-sized segments до ACK
TcpDelAckTicks	REG_DWORD	2	0..6	задержка delayed ACK в 100-ms ticks

Come funziona ACK policy

TcpAckFrequency=1 imposta l’invio di un ACK per ogni segmento a dimensione piena. Il valore 2 mantiene le normali regole di conferma ritardata TCP. TcpDelAckTicks si misura in passi da 100 ms: il valore predefinito 2 imposta un limite di circa 200 ms, mentre 0 elimina l’attesa aggiuntiva del timer. Altre regole TCP possono comunque causare una conferma immediata.

Lo stack TCP utilizza i valori letti per l’interfaccia di rete specifica. La scrittura nella sezione globale del registro non sostituisce la configurazione dell’interfaccia. Una nuova VPN, vEthernet o un adattatore temporaneo riceve il proprio GUID e mantiene i valori predefiniti finché i parametri non vengono impostati proprio per esso.

Utilità

Ridurre il ritardo ACK può aiutare le applicazioni sensibili all’elaborazione di pacchetti piccoli e alle conferme ritardate. Allo stesso tempo aumentano il numero di pacchetti inversi e il carico sulla scheda di rete e sulla CPU. Il risultato dipende dalla seconda parte della connessione, dal controllo della congestione e dall’MTU, quindi la riduzione del ritardo di rete non è garantita.

Cosa è confermato

• Il percorso dei parametri per l’interfaccia con il suo GUID.
• I valori predefiniti e gli intervalli effettivi di 0..255 e 0..6.
• La sezione globale del registro non sostituisce la configurazione dell’interfaccia specifica.
• Una nuova VPN o un adattatore temporaneo riceve il proprio GUID e i valori predefiniti.

Cosa non è confermato

• La riduzione del ping o del ritardo delle applicazioni.
• Il comportamento con server, route e perdite di pacchetti specifici.
• Il guadagno su Wi-Fi, VPN e nei giochi.

Conclusione pratica

Lasciare i valori predefiniti. Ridurre il ritardo ACK solo in presenza di un problema riproducibile con pacchetti piccoli e monitorare il numero di pacchetti inversi e il carico sulla rete.

Ripristino dello stato

Ripristinare i valori dell’interfaccia 2 o eliminare le voci. Le modifiche si applicano alle nuove connessioni.

Limitazioni

La verifica riguarda Windows 11 25H2. La lettura dei parametri, i valori predefiniti e gli intervalli sono confermati. Il guadagno finale non è stato misurato in test controllati con server diversi, Wi-Fi ed Ethernet, MTU e perdite di pacchetti. Il trasferimento di parte dell’elaborazione alla scheda di rete non annulla le regole di conferma TCP. Tuttavia l’elaborazione a pacchetti, la VPN e il comportamento della seconda parte della connessione possono nascondere o modificare l’effetto osservato.

L’articolo non contiene osservazioni dinamiche proprie: la lettura dei valori da parte dello stack di rete su un sistema in esecuzione e gli intervalli effettivi di conferma in uno scenario controllato non sono stati misurati. Le affermazioni sul lettore e sugli intervalli si basano sull’analisi dei componenti TCP e sulla documentazione pubblica Microsoft, non su misurazioni proprie.

Come eseguire autonomamente la parte dinamica della verifica — vedi Come verificare autonomamente.

La ricerca e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, quindi lo sviluppatore ha un interesse diretto nei risultati. La metodologia e i limiti di applicabilità sono descritti sopra, e le conclusioni possono essere verificate tramite i dati aperti e le fonti pubbliche elencate.

Fonti

• TCP/IP registry values, Microsoft Learn, verificato 2026-09-01.
• TCP delayed acknowledgement, Microsoft Learn, verificato 2026-09-01.

Fonti pubbliche verificate: 2026-09-02.

Cronologia delle modifiche

• 2026-09-20: aggiunto il disclaimer sul conflitto di interessi e il link alla verifica dinamica autonoma nella metodologia.
• 2026-09-19: nelle limitazioni è stata aggiunta esplicitamente l’assenza di osservazioni dinamiche proprie e di misurazioni degli intervalli ACK.
• 2026-09-02: prima pubblicazione; confermati percorso, defaults e intervalli, aggiunti i limiti dell’effetto sul ritardo.