TCP ACK et delayed ACK dans Windows 11 25H2

Réponse courte

TcpAckFrequency et TcpDelAckTicks contrôlent les accusés de réception TCP au niveau d’une interface donnée. La lecture des paramètres et les plages sont confirmées ; la réduction du délai ACK ne garantit pas de gain et augmente le nombre de paquets retour.

Ce qui a été vérifié

Le chemin des paramètres pour l’interface réseau, les valeurs par défaut, les plages et l’effet sur les règles d’accusé de réception TCP ont été vérifiés.

Périmètre de l’étude

Windows 11 25H2 build 26200.9168, paramètres TCP d’interface. Les réseaux avec pertes, le Wi-Fi, les VPN et différents serveurs n’entraient pas dans les mesures contrôlées.

Méthodologie

Analyse des composants TCP et d’une trace système, vérification de la conversion des valeurs et recoupement avec la documentation publique de Microsoft.

Chemin canonique

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

Value	Type	Default	Plage effective	Rôle
TcpAckFrequency	REG_DWORD	2	0..255	nombre de full-sized segments avant ACK
TcpDelAckTicks	REG_DWORD	2	0..6	délai delayed ACK en 100-ms ticks

Comment fonctionne ACK policy

TcpAckFrequency=1 impose l’envoi d’un ACK pour chaque segment de taille pleine. La valeur 2 conserve les règles habituelles d’accusé de réception différé de TCP. TcpDelAckTicks se mesure par pas de 100 ms : la valeur par défaut 2 fixe une limite d’environ 200 ms, et 0 supprime l’attente supplémentaire du minuteur. D’autres règles TCP peuvent toujours provoquer un accusé de réception immédiat.

La pile TCP utilise les valeurs lues pour une interface réseau donnée. L’écriture dans la section globale du registre ne remplace pas le réglage de l’interface. Un nouveau VPN, vEthernet ou adaptateur temporaire reçoit son propre GUID et conserve les valeurs par défaut tant que les paramètres ne sont pas définis précisément pour lui.

Utilité

La réduction du délai ACK peut aider les applications sensibles au traitement des petits paquets et aux accusés de réception différés. En revanche, le nombre de paquets retour et la charge sur la carte réseau et le CPU augmentent. Le résultat dépend de la seconde partie de la connexion, du contrôle de congestion et du MTU, donc la diminution de la latence réseau n’est pas garantie.

Ce qui est confirmé

• Le chemin des paramètres pour l’interface avec son GUID.
• Les valeurs par défaut et les plages effectives de 0..255 et 0..6.
• La section globale du registre ne remplace pas le réglage d’une interface donnée.
• Un nouveau VPN ou adaptateur temporaire reçoit son propre GUID et les valeurs par défaut.

Ce qui n’est pas confirmé

• La baisse du ping ou de la latence des applications.
• Le comportement avec des serveurs, des routes et des pertes de paquets donnés.
• Le gain en Wi-Fi, en VPN et en jeu.

Conclusion pratique

Laissez les valeurs par défaut. Ne réduisez le délai ACK qu’en cas de problème reproductible avec les petits paquets, et surveillez le nombre de paquets retour et la charge sur le réseau.

Restauration de l’état

Rétablissez les valeurs d’interface 2 ou supprimez les entrées. Les modifications s’appliquent aux nouvelles connexions.

Limites

La vérification concerne Windows 11 25H2. La lecture des paramètres, les valeurs par défaut et les plages sont confirmées. Le gain final n’a pas été mesuré dans des tests contrôlés avec différents serveurs, Wi-Fi et Ethernet, MTU et pertes de paquets. Le transfert d’une partie du traitement à la carte réseau n’annule pas les règles d’accusé de réception TCP. Cependant, le traitement par lots, le VPN et le comportement de la seconde partie de la connexion peuvent masquer ou modifier l’effet observé.

L’article ne contient pas d’observations dynamiques propres : la lecture des valeurs par la pile réseau sur un système en fonctionnement et les intervalles réels d’accusé de réception dans un scénario contrôlé n’ont pas été mesurés. Les affirmations sur la lecture et les plages reposent sur l’analyse des composants TCP et la documentation publique de Microsoft, et non sur des mesures propres.

Pour savoir comment réaliser soi-même la partie dynamique de la vérification — voir Comment vérifier soi-même.

L’étude et les outils utilisés appartiennent au développeur de BoosterX, le développeur a donc un intérêt direct aux résultats. La méthodologie et les limites d’applicabilité sont décrites ci-dessus, et les conclusions peuvent être vérifiées à partir des données ouvertes et des sources publiques citées.

Sources

• TCP/IP registry values, Microsoft Learn, vérifié le 2026-09-01.
• TCP delayed acknowledgement, Microsoft Learn, vérifié le 2026-09-01.

Sources publiques vérifiées : 2026-09-02.

Historique des modifications

• 2026-09-20: ajout d’un avertissement sur le conflit d’intérêts et d’un lien vers la vérification dynamique autonome dans la méthodologie.
• 2026-09-19: ajout explicite dans les limites de l’absence d’observations dynamiques propres et de mesures des intervalles ACK.
• 2026-09-02: première publication ; chemin, defaults et plages confirmés, ajout des limites d’influence sur la latence.