Debian 13 : les retransmissions TCP tuent les performances — localisez l’endroit réel des pertes

novembre 17, 2025 • février 3, 2026 • Lecture : 27 min • Views: 8

Cet article vous a aidé ?

Ça commence toujours de la même façon : l’équipe applicative jure « le réseau est lent », l’équipe réseau jure « les serveurs laissent passer des paquets », et vous êtes coincé à regarder un tableau de bord qui affiche « TCP Retransmits » comme si c’était un diagnostic. Ce n’en est pas un. C’est un symptôme.

Sur Debian 13, des retransmissions peuvent signifier une vraie perte de paquets, l’effondrement de files d’attente, des problèmes de PMTU, des bizarreries d’offload, une surcharge de conntrack, du réordonnancement de paquets, ou une appliance intermédiaire qui fait quelque chose de « utile » à votre trafic. L’astuce n’est pas de prouver que les retransmissions existent. L’astuce est de localiser où la perte (ou l’illusion de perte) se produit réellement — sur l’hôte, l’hyperviseur, la carte réseau, le commutateur, le pare-feu ou l’extrémité distante.

Ce que signifient vraiment les retransmissions (et ce qu’elles ne signifient pas)

Les retransmissions TCP se produisent lorsque l’émetteur croit qu’un segment n’est pas arrivé au récepteur. L’élément important est « croit ». TCP déduit une perte à partir d’accusés de réception (ACK) manquants, d’ACKs dupliqués, de blocs SACK et de minuteries. Cet ACK manquant peut être dû à :

Le segment de données a été perdu en chemin.
L’ACK a été perdu sur la voie de retour.
Le segment est arrivé mais est resté coincé derrière une file d’attente géante (bufferbloat), arrivant « assez tard » pour déclencher la récupération de perte.
Des paquets ont été réordonnés et ont temporairement « paru perdus ».
Le récepteur était tellement surchargé qu’il n’a pas ACKé à temps.
Une middlebox a altéré MSS/MTU/ECN, provoquant un blackholing ou un blocage.

Donc « les retransmissions sont élevées » revient à dire « l’alarme incendie est forte ». Oui. Et maintenant vous devez trouver le feu, le toast brûlé ou la personne qui vapote sous le détecteur.

Sur Linux moderne, la pile TCP du noyau est excellente. Quand vous voyez des retransmissions qui « tuent les performances », c’est généralement le système qui vous dit que quelque chose sous ou à côté de TCP se comporte mal : anneaux NIC, bugs de pilote, interactions d’offload, famine d’IRQ, ou perte en rafale sur le chemin réseau.

Vérité nue : votre application peut être correcte. Vos disques peuvent être corrects. Votre CPU peut être correct. Vos retransmissions restent réelles et ralentissent toujours. Corrigez le chemin.

Mode opératoire pour un diagnostic rapide

Ceci est l’ordre qui gagne les incidents. Il ne prouve pas tout ; il trouve le goulot d’étranglement suffisamment vite pour arrêter l’hémorragie.

Première étape : décider si c’est un hôte, un lien ou le chemin

Comparez plusieurs clients/serveurs. Si un hôte Debian 13 est l’exception, commencez par lui. Si chaque hôte observe le problème vers la même destination, suspectez le chemin ou la destination.
Vérifiez les compteurs d’interface. Si la NIC montre des erreurs RX/TX, des drops, des missed, ou « no buffer », vous avez probablement un problème de perte côté hôte.
Vérifiez les statistiques TCP. Si les retransmissions augmentent mais que les drops d’interface restent stables, suspectez la congestion en amont, le réordonnancement, les blackholes MTU ou la perte d’ACK sur le chemin de retour.

Deuxième étape : localiser la direction de la perte (chemin des données vs ACK)

tcpdump sur les deux extrémités (ou une extrémité plus un span/mirror) et vérifiez : est-ce que les segments de données manquent à l’ingress, ou est-ce que les ACKs manquent à l’egress ?
Vérifiez l’asymétrie. La perte sur la voie d’ACK ressemble à « l’émetteur retransmet, le récepteur a reçu les données ».

Troisième étape : tester les suspects habituels dans la boucle la plus courte possible

MTU/PMTUD (surtout VLANs, tunnels, jumbo frames, réseaux overlay).
Offloads (GRO/LRO/TSO/GSO) quand la capture de paquets paraît « étrange » ou quand une combinaison NIC/pilote est connue pour être capricieuse.
Famine IRQ/softirq (CPU élevé dans ksoftirqd, drops avec « no buffer »).
Pare-feu/conntrack (drops, timeouts, « invalid », ou pression sur la table conntrack).
Bonding/LACP (réordonnancement entre liens, surtout avec certaines politiques de hash).

Une règle : ne touchez pas au TCP avant d’avoir prouvé que c’est la faute de la pile TCP. La plupart des « réglages TCP » sont des superstitions coûteuses avec un joli tableur.

Faits et contexte utilisables en salle d’astreinte

La logique de retransmission TCP précède votre datacenter. Le fast retransmit et le fast recovery classiques ont été formalisés dans les années 1990 à mesure que l’Internet grandissait et que la perte devenait normale.
SACK (Selective Acknowledgment) a changé la donne. Il permet aux récepteurs d’indiquer précisément quels blocs sont arrivés, réduisant les retransmissions inutiles sur des chemins bruités.
Linux est une implémentation TCP sérieuse depuis des décennies. Beaucoup de fonctionnalités réseau haute performance — comme des options modernes de contrôle de congestion — ont été éprouvées sur Linux avant de devenir des « standards ».
CUBIC est devenu le contrôle de congestion par défaut de Linux parce que l’Internet est devenu plus rapide. Le comportement de type Reno était trop conservateur pour des liens à haute bande passante et forte latence.
RACK (Recent ACK) a amélioré la détection de perte. Il tente de mieux distinguer le réordonnancement de la perte que les heuristiques plus anciennes, réduisant les retransmissions inutiles.
GRO/TSO ont modifié l’apparence des captures de paquets. tcpdump peut montrer des paquets « géants » ou une segmentation étrange parce que la NIC/le noyau effectue du travail que vous voyiez auparavant « sur le fil ».
L’Ethernet n’a pas de fiabilité bout en bout intégrée. Les pertes sont un comportement autorisé en cas de congestion ; TCP est la couche de fiabilité, pas le commutateur.
Les microbursts ne sont pas une mode. Les liens rapides et les tampons peu profonds peuvent perdre des pics très courts même quand l’utilisation moyenne semble correcte.
La défaillance de PMTUD est un classique récurrent. Le filtrage ICMP + tunnels/overlays = blackholes qui ressemblent à des « retransmissions aléatoires ».

Une idée paraphrasée qui tient encore vient de Werner Vogels : « Tout échoue, tout le temps ; concevez et opérez en conséquence. » (idée paraphrasée)

Obtenir la vérité terrain : mesurer retransmissions, pertes et leur localisation

« TCP retransmits » apparaît dans la supervision parce que cela corrèle avec une mauvaise expérience utilisateur. Mais corrélation n’est pas localisation. Vous voulez répondre à trois questions :

La perte est-elle réelle ou apparente ? (Le réordonnancement/les paquets en retard peuvent déclencher une récupération sans vraie perte.)
Ça arrive sur l’hôte ? (Pilote/NIC/IRQ/compteurs de file.)
Ça arrive sur le chemin réseau ? (Congestion de commutateur, blackhole MTU, drops de pare-feu.)

Debian 13 fournit un noyau et un userland modernes. C’est une bonne nouvelle. Cela signifie aussi que vous pouvez facilement mal interpréter les outils si vous n’intégrez pas les offloads, namespaces, couches de virtualisation et réseaux overlay. Votre tcpdump n’est pas une confession ; c’est un témoignage.

Blague n°1 : La perte de paquets, c’est comme la politique de bureau : ce n’est presque jamais là où la personne la plus bruyante le dit.

Tâches pratiques : commandes, sorties, décisions (12+)

Ce sont des tâches de terrain : exécutez-les pendant un incident et vous réduirez l’espace de recherche sans lancer une « initiative performance réseau » d’une semaine. Chaque tâche inclut : commande, que signifie une sortie typique, et quelle décision prendre ensuite.

Task 1 — Confirmer les retransmissions et qui en souffre (ss)

cr0x@server:~$ ss -ti dst 10.20.30.40
ESTAB 0 0 10.20.30.10:54322 10.20.30.40:443
	 cubic wscale:7,7 rto:204 rtt:5.2/0.8 ato:40 mss:1460 pmtu:1500 rcvmss:1460 advmss:1460 cwnd:10 bytes_acked:1453297 segs_out:12094 segs_in:11820 send 22.5Mbps lastsnd:12 lastrcv:12 lastack:12 pacing_rate 45.0Mbps unacked:3 retrans:57/1034 reordering:3

Sens : retrans:57/1034 affiche des segments retransmis. Si les retransmissions montent pendant l’effondrement du débit, vous avez un problème de récupération TCP, pas seulement une « application lente ».

Décision : Si les retransmissions sont concentrées vers une destination ou une interface, circonscrivez la zone. Si c’est global, suspectez un élément de chemin partagé (commutateur, pare-feu, hyperviseur, uplink).

Task 2 — Statistiques TCP système (nstat / netstat)

cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|TcpTimeouts|TcpExtTCPSynRetrans|TcpExtTCPFastRetrans'
TcpRetransSegs                 18933              0.0
TcpTimeouts                    412                0.0
TcpExtTCPFastRetrans           12080              0.0
TcpExtTCPSynRetrans            55                 0.0

Sens : Une montée de TcpTimeouts implique des retransmissions basées RTO (pire) plutôt que fast retransmit (souvent congestion ou réordonnancement). Les retransmissions SYN pointent vers des problèmes de chemin/filtrage.

Décision : Si les timeouts augmentent, vérifiez immédiatement MTU/blackholes et les pertes sévères. Si ce sont surtout des fast retransmits, concentrez-vous sur la congestion, les microbursts ou le réordonnancement.

Task 3 — Vérifier les compteurs d’erreur et de drop de la NIC (ip -s link)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456  0       1432     980     12034
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  7456123  0       0       0       0

Sens : Une augmentation de dropped et missed en RX signifie que l’hôte n’a pas pu traiter les paquets entrants assez vite (overflow d’anneau, famine d’IRQ, pression CPU).

Décision : Si les drops/missed RX augmentent, priorisez le côté hôte : stats pilote, tailles d’anneaux, affinité IRQ, RPS/XPS, offloads, contention CPU.

Task 4 — Compteurs profonds niveau pilote (ethtool -S)

cr0x@server:~$ sudo ethtool -S eno1 | egrep -i 'drop|miss|err|timeout|buffer|fifo' | head
     rx_dropped: 1432
     rx_missed_errors: 980
     rx_no_buffer_count: 975
     rx_fifo_errors: 0
     tx_timeout_count: 0

Sens : rx_no_buffer_count signifie que la NIC dit « j’ai eu des trames, mais pas d’endroit où les mettre ». C’est un indice fort pour des problèmes d’anneaux/IRQ/softirq.

Décision : Augmentez les anneaux (Task 9), répartissez les interruptions, vérifiez la charge softirq CPU (Task 6), et assurez-vous que vous n’effectuez pas un filtrage coûteux sur cette machine.

Task 5 — Valider la vitesse/duplex et l’auto-négociation (ethtool)

cr0x@server:~$ sudo ethtool eno1 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Sens : Un serveur bloqué à 1Gb/s alors que vous attendez 10/25/100Gb/s n’est pas une « perte TCP », c’est une machine à remonter le temps vers 2009.

Décision : Corrigez le câblage/SFP/config switch. Ne compensez pas une négociation dégradée par un tuning TCP.

Task 6 — Vérifier la pression softirq et la contention CPU (mpstat / top)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.12.0 (server)  12/29/2025  _x86_64_  (32 CPU)

12:03:11 PM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
12:03:12 PM  all  12.1  0.0   8.2   0.3    0.0  18.4   0.0   61.0
12:03:12 PM   7   5.0  0.0   6.1   0.0    0.0  72.3   0.0   16.6

Sens : Un CPU coincé dans %soft alors que les autres sont inactifs crie « déséquilibre interruptions/softirq ». Les paquets arrivent, mais un cœur suffoque.

Décision : Inspectez la distribution IRQ (Task 7). Envisagez d’activer/modifier RPS/XPS ou d’ajuster l’affinité IRQ.

Task 7 — Vérifier la distribution IRQ pour la NIC (procfs)

cr0x@server:~$ grep -E 'eno1|eth0|ixgbe|i40e|mlx|ens' /proc/interrupts | head -n 5
  88:  12000342        0        0        0  IR-PCI-MSI 262144-edge  eno1-TxRx-0
  89:         3        0        0        0  IR-PCI-MSI 262145-edge  eno1-TxRx-1
  90:         1        0        0        0  IR-PCI-MSI 262146-edge  eno1-TxRx-2

Sens : La file 0 gère quasiment toutes les interruptions. Cela crée des drops RX sous charge, qui se transforment en retransmissions TCP.

Décision : Corrigez l’affinité (irqbalance, masques manuels), vérifiez que RSS est activé, confirmez que plusieurs queues sont actives.

Task 8 — Chercher des drops à l’intérieur du qdisc (tc -s)

cr0x@server:~$ tc -s qdisc show dev eno1
qdisc mq 0: root
qdisc fq_codel 8001: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
 Sent 8123456789 bytes 7456123 pkt (dropped 0, overlimits 0 requeues 2)
 backlog 0b 0p requeues 2

Sens : Si le qdisc montre des drops significatifs, vous vous infligez peut-être des pertes en sortie (shaping, fq_codel mal dimensionné, ou txqueuelen trop petit).

Décision : Si des drops en egress existent, corrigez le shaping et les paramètres de queue avant de blâmer le réseau. Sinon, passez à autre chose.

Task 9 — Vérifier et ajuster la taille des anneaux NIC (ethtool -g / -G)

cr0x@server:~$ sudo ethtool -g eno1
Ring parameters for eno1:
Pre-set maximums:
RX:	4096
TX:	4096
Current hardware settings:
RX:	512
TX:	512

Sens : Un petit anneau RX peut déborder lors de rafales. Cela produit des drops RX, qui ressemblent à des « retransmissions TCP aléatoires ».

Décision : Si vous voyez rx_no_buffer_count et des missed drops, augmentez RX/TX rings prudemment et retestez.

cr0x@server:~$ sudo ethtool -G eno1 rx 2048 tx 2048

Task 10 — Confirmer le MTU de bout en bout et repérer les mismatches (ip link, ping -M do)

cr0x@server:~$ ip link show dev eno1 | head -n 1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

cr0x@server:~$ ping -c 3 -M do -s 1472 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
1472 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=0.412 ms
1472 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.398 ms
1472 bytes from 10.20.30.40: icmp_seq=3 ttl=63 time=0.405 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Sens : Ceci teste DF (ne pas fragmenter). Si ça échoue sur un chemin que vous pensez supporter 1500/9000, vous avez trouvé un problème PMTU.

Décision : Si les pings DF échouent aux tailles attendues, arrêtez tout. Corrigez la cohérence MTU ou le filtrage ICMP « fragmentation needed ». Les retransmissions sont un symptôme en aval.

Task 11 — Capturer sur l’hôte et étiqueter les retransmissions (tcpdump)

cr0x@server:~$ sudo tcpdump -i eno1 -nn 'host 10.20.30.40 and tcp port 443' -vv
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:05:01.101010 IP 10.20.30.10.54322 > 10.20.30.40.443: Flags [P.], seq 12001:13461, ack 8801, win 501, length 1460
12:05:01.104444 IP 10.20.30.10.54322 > 10.20.30.40.443: Flags [P.], seq 12001:13461, ack 8801, win 501, length 1460 (retransmission)
12:05:01.105000 IP 10.20.30.40.443 > 10.20.30.10.54322: Flags [.], ack 13461, win 8192, length 0

Sens : tcpdump annotera « (retransmission) » selon ce qu’il observe. Mais souvenez-vous : le point de capture compte. Capturer sur l’émetteur ne prouve pas que le paquet n’a pas quitté la NIC.

Décision : Si possible, capturez aux deux extrémités. Si une seule extrémité : corrélez avec les drops NIC et les compteurs de commutateur pour éviter de blâmer des fantômes.

Task 12 — Vérifier les offloads quand la capture paraît erronée (ethtool -k)

cr0x@server:~$ sudo ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload|large-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]

Sens : TSO/GSO/GRO peuvent rendre les captures trompeuses et interagir mal avec certains pilotes ou tunnels, surtout en virtualisation overlay.

Décision : Si vous suspectez une bizarrerie liée aux offloads, testez en basculant temporairement sur un hôte (pas sur l’ensemble du parc) et mesurez à nouveau les retransmissions.

cr0x@server:~$ sudo ethtool -K eno1 gro off gso off tso off

Task 13 — Vérifier la pression conntrack et les drops nftables

cr0x@server:~$ sudo nft list ruleset | head -n 20
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		tcp dport { 22, 443 } accept
		counter packets 189234 bytes 120934234 drop
	}
}

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 258901
net.netfilter.nf_conntrack_max = 262144

Sens : Si conntrack est proche du maximum, de nouveaux flux peuvent être dropés ou retardés. Cela produit des retransmissions SYN et des blocages « aléatoires ».

Décision : Si vous faites du firewalling stateful sur un hôte occupé, augmentez les limites en tenant compte de la mémoire, réduisez le trafic suivi, ou déplacez le filtrage hors de la machine.

Task 14 — Rechercher réordonnancement et indices DSACK (ss -i, nstat)

cr0x@server:~$ ss -ti src 10.20.30.10:54322
ESTAB 0 0 10.20.30.10:54322 10.20.30.40:443
	 cubic rtt:5.1/1.0 rto:204 mss:1460 cwnd:9 unacked:2 retrans:22/903 reordering:18

cr0x@server:~$ nstat -az | egrep 'TcpExtTCPDSACKRecv|TcpExtTCPDSACKOfoRecv|TcpExtTCPSACKReorder'
TcpExtTCPDSACKRecv             3812               0.0
TcpExtTCPDSACKOfoRecv          1775               0.0
TcpExtTCPSACKReorder           2209               0.0

Sens : Des compteurs liés au réordonnancement qui augmentent suggèrent que le réseau ne perd pas tant de paquets qu’il les mélange. Le réordonnancement peut néanmoins nuire au débit parce que TCP réagit défensivement.

Décision : Examinez le hashing LACP/bonding, les chemins ECMP, et tout dispositif faisant du load balancing par paquet. Corriger le réordonnancement résout souvent les retransmissions sans changer le taux de perte.

Task 15 — Confirmer la PMTU vue par le noyau (ip route get)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 dev eno1 src 10.20.30.10 uid 1000
    cache mtu 1500

Sens : Le MTU du cache de route est ce que le noyau pense être sûr. Si vous attendez 9000 et voyez 1500, quelque chose a appris une PMTU plus petite.

Décision : Si la PMTU est anormalement basse, vérifiez tunnels/VPN/VXLAN/GRE, et si les messages ICMP « frag needed » sont reçus et pris en compte.

Task 16 — Valider l’état du bonding/LACP (si pertinent)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.12.0

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
Slave Interface: eno1
MII Status: up
Slave Interface: eno2
MII Status: up

Sens : LACP en soi ne garantit pas la livraison dans l’ordre si l’amont est mal configuré ou si le hash change. Certaines configurations provoquent du réordonnancement selon certains patrons de flux.

Décision : Si les compteurs de réordonnancement montent et que vous êtes en bonding, testez avec un lien unique ou ajustez la politique de hash et la configuration du port-channel en amont.

Schémas de pertes qui induisent en erreur les plus malins

1) « Pas de drops d’interface, mais beaucoup de retransmissions »

C’est le stalemate classique en salle d’astreinte. L’hôte dit qu’il ne droppe pas. TCP dit qu’il retransmet. Les deux peuvent avoir raison.

Pertes sur le chemin : tampons de switch qui débordent, policing/shaping en amont, optiques défectueuses, ou pare-feu qui droppe sous charge.
Perte sur la voie d’ACK : votre émetteur voit des ACKs manquants, retransmet, mais le récepteur a effectivement reçu les données.
Retards de mise en file : les paquets arrivent tard (bufferbloat), déclenchant fast retransmit ou timeouts même s’ils n’ont pas été perdus.

Comment le prouver : capturez aux deux bouts (ou émetteur + SPAN). Si le récepteur voit le segment original et que l’émetteur retransmet quand même, il s’agit probablement d’un problème de voie d’ACK ou d’un retard extrême.

2) Microbursts : l’utilisation moyenne ment

Les microbursts expliquent pourquoi des liens à 20% peuvent quand même dropper. Les systèmes modernes peuvent émettre du trafic par rafales : coalescence d’interruption, batchs dans le noyau, GRO, écritures applicatives, ou réplication de stockage poussant un gros lot. Les tampons peu profonds des ToR peuvent dropper ces rafales en microsecondes. Votre graphe SNMP à 60 secondes affichera joyeusement « tout va bien ».

Que faire : demandez les compteurs de discard et de buffers de l’interface du switch, idéalement à haute résolution. Sur l’hôte, cherchez RX no-buffer et pression softirq. Si vous ne pouvez pas obtenir la télémétrie du switch, vous pouvez encore inférer des microbursts à partir de « pas de drops évidents côté hôte » + retransmissions sous fort fan-in ou des émetteurs synchronisés.

3) Blackholes PMTUD : ce n’est pas une perte, c’est un mismatch MTU silencieux

Si ICMP « fragmentation needed » est filtré ou mal géré, les gros paquets disparaissent. TCP retransmet. Finalement les connexions se bloquent ou traînent avec un comportement MSS étrange. Ceci est très courant avec les tunnels, VPN et réseaux overlay.

Ne devinez pas. Testez avec ping -M do. Si cela échoue à des tailles raisonnables, arrêtez le « tuning TCP ». Vous envoyez des paquets que le chemin ne peut pas transporter.

4) Réordonnancement : les paquets arrivent, simplement pas poli

TCP suppose que le réordonnancement est moins fréquent que la perte, bien que Linux se soit amélioré pour le détecter. Si votre réseau effectue du load balancing par paquet (intentionnel ou accidentel) vous pouvez induire du réordonnancement. Des mauvais réglages de bonding peuvent aussi le provoquer.

Le résultat : ACKs dupliqués, fast retransmits, DSACKs. Le débit chute. Tout le monde accuse la « perte de paquets » parce que c’est le graphe qu’ils ont.

5) « On a activé la fonctionnalité X et c’est pire » (parce que ça change le timing)

Offloads, ECN, pacing, disciplines de queue — beaucoup de choses sont bénéfiques. Mais les activer au mauvais endroit peut changer le comportement de rafale et le timing suffisamment pour exposer un lien faible. Cela ne signifie pas que la fonctionnalité est mauvaise. Cela signifie que votre environnement est fragile.

Blague n°2 : Désactiver GRO pour « réparer le réseau » revient à débrancher le détecteur de fumée pour réduire le bruit.

Trois mini-histoires d’entreprise (ce qui casse réellement)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait un nouveau parc Debian 13 en production derrière une paire de pare-feux. Le déploiement s’était bien passé jusqu’à ce qu’un service — des exports massifs — commence à expirer. Les retransmissions ont grimpé, les RTO ont augmenté, et les exports devenaient « non fiables ». Le propriétaire applicatif insistait que c’était une régression du noyau.

L’équipe réseau pointait des compteurs d’interface propres sur les serveurs. Pas de drops RX. Pas d’erreurs CRC. « Ce n’est pas nous. » L’SRE de garde a fait la chose la plus ennuyeuse possible : tester la PMTU avec ping -M do entre les hôtes exporteurs et l’API en aval. Ça échouait à des tailles qui auraient dû fonctionner dans ce VLAN.

Tous avaient supposé que le VLAN était un domaine Ethernet standard de 1500 octets. Il ne l’était pas. Il y avait un segment tunnel au milieu, et les pare-feux étaient configurés pour dropper les ICMP « fragmentation needed » entrants comme « bruit indésirable ». PMTUD ne fonctionnait pas, et le chemin mettait effectivement les gros paquets dans le trou noir.

La réparation n’a pas nécessité un rollback Debian, un nouveau pilote NIC ou un feu de joie de sysctl TCP. Ils ont autorisé les types ICMP pertinents et ajusté le MSS sur le pare-feu pour le tunnel. Les retransmissions ont chuté, le débit est revenu, et la salle d’astreinte s’est terminée avant le déjeuner.

La mauvaise hypothèse n’était pas « Debian 13 est bugué ». La mauvaise hypothèse était « notre réseau a le MTU que nous croyons avoir ». Voilà comment on se fait appeler la nuit.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation voulait extraire plus de débit pour le trafic de réplication. Quelqu’un a lu que « des tampons plus gros améliorent les performances », alors ils ont augmenté les tailles d’anneaux NIC et modifié les paramètres de qdisc sur un cluster de stockage pendant une fenêtre de maintenance. Les tests initiaux semblaient excellents : moins de drops, pics de débit plus élevés sur des benchmarks synthétiques.

Puis la production est arrivée. Les services sensibles à la latence partageant les mêmes uplinks ont commencé à signaler des timeouts. Les retransmissions ont monté partout, pas seulement sur la réplication. Les graphiques ne montraient pas de saturation de lien, donc la faute rebondissait entre équipes.

Le problème n’était pas que des anneaux plus gros étaient « mauvais ». Le problème était que des anneaux plus grands plus un comportement de qdisc modifié augmentaient la latence de mise en file sous charge rafaleuse. Le réseau a commencé à tamponner davantage sur l’hôte, le switch a tamponné davantage, et la variation RTT est devenue suffisante pour déclencher RTO et le comportement de récupération. Ça ressemblait à de la perte. Une partie était en fait une livraison retardée.

La correction a été de revenir sur les changements brutaux, puis de les réintroduire sélectivement. La réplication a obtenu une classe d’interface dédiée avec pacing contrôlé, et le trafic général est revenu à une gestion de file raisonnable. Les retransmissions ont chuté parce que le réseau a cessé de se comporter comme un stockage cherchant à gagner un benchmark.

C’est pourquoi vous n’« optimisez » pas sans un modèle de vos charges. Rapide n’est pas synonyme de stable.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Dans une troisième entreprise, un seul rack a commencé à montrer des retransmissions TCP élevées sur des nœuds Debian 13 après un renouvellement hardware. Rien n’était complètement en panne, juste assez lent pour que les clients s’en rendent compte. L’instinct premier a été de poursuivre les versions de noyau, le firmware NIC, et « peut-être IPv6 ».

Mais l’équipe avait une pratique ennuyeuse : chaque rack avait une capture « golden » et un snapshot de compteurs pris quand le rack était connu bon. Pas de sophistication — juste ethtool -S, ip -s link, ss -s, et un tcpdump court. Ça vivait dans un repo à côté des notes de montage du rack.

Comparer les compteurs actuels au baseline a montré une différence claire : des erreurs CRC et d’alignement sur le port switch connecté à un uplink leaf montaient régulièrement. Sur les hôtes, les erreurs n’étaient pas encore visibles (le switch voyait le problème physique en premier).

Ils ont remplacé l’optique suspecte et nettoyé un connecteur fibre. Les retransmissions ont baissé en quelques minutes. Pas de changement de noyau, pas de tuning de performance, pas de doigt-pointing. Juste de la physique.

Les pratiques ennuyeuses ne font pas de bons talks de conférence. Elles résolvent les incidents.

Erreurs courantes : symptôme → cause racine → correction

Cette section est volontairement spécifique. Ce sont les schémas qui font perdre du temps parce qu’ils ressemblent à autre chose.

1) Retransmissions TCP élevées, drops RX NIC en hausse

Symptôme : Les retransmissions augmentent avec le débit. ip -s link montre RX dropped/missed en hausse.
Cause probable : L’hôte ne peut pas traiter les RX assez vite (IRQ collé, anneaux trop petits, problèmes de pilote, contention CPU, nftables chargé, surcharge virtualisation).
Correction : Équilibrer IRQs/RSS, augmenter tailles d’anneaux, vérifier RPS/XPS, réduire charge firewall/conntrack, éloigner charges des cœurs softirq, mettre à jour firmware/driver NIC si indiqué.

2) Retransmissions élevées, pas de drops hôte, retransmissions SYN en hausse

Symptôme : TcpExtTCPSynRetrans augmente ; les connexions sont lentes à s’établir.
Cause probable : Drops de pare-feu, table conntrack pleine, routage asymétrique via un dispositif stateful, ou destination surchargée/refusant.
Correction : Vérifier conntrack count/max, compteurs/logs de pare-feu, assurer un routage symétrique, réduire le trafic suivi, adapter la capacité du pare-feu ou contourner pour le trafic interne sûr.

3) Retransmissions après activation des jumbo frames

Symptôme : Ça marche pour de petites réponses, bloque sur de grands transferts ; les pings DF échouent.
Cause probable : Mismatch MTU quelque part (switch, pare-feu, tunnel overlay), PMTUD bloqué.
Correction : Rendre le MTU cohérent de bout en bout ou clamer MSS aux bords ; autoriser ICMP frag-needed ; valider avec des pings DF sur le chemin réel.

4) Retransmissions avec compteurs « reordering » élevés

Symptôme : reordering dans ss -i et compteurs DSACK en hausse.
Cause probable : Changements de hashing ECMP/LACP, load balancing par paquet, liens de vitesses mixtes, ou un bond/port-channel mal configuré.
Correction : Assurer un hashing par flux, valider la config LACP, éviter la distribution par paquet, tester le comportement sur un lien unique pour confirmer.

5) Retransmissions « seulement pendant les backups » ou « seulement à l’heure pile »

Symptôme : Pics périodiques de retransmissions avec jobs planifiés.
Cause probable : Microbursts et congestion d’émetteurs synchronisés, pression des tampons du switch, ou effondrement de file côté hôte.
Correction : Échelonner les horaires, appliquer pacing/shaping pour les flux massifs, séparer les classes de trafic, et demander/inspecter les compteurs de discard du switch.

6) tcpdump montre des retransmissions, mais le récepteur indique que les données sont arrivées

Symptôme : L’émetteur retransmet ; l’application réceptrice voit des doublons ou des données hors ordre (ou juste un CPU élevé).
Cause probable : Perte d’ACK sur la voie de retour ou point de capture trompeur à cause des offloads/du virtual switching.
Correction : Capturer aux deux extrémités ; vérifier les offloads et les points de capture ; enquêter sur la voie de retour et le routage asymétrique.

Listes de vérification / plan pas à pas

Étapes : trouver où se situe la perte en 60–90 minutes

Choisissez un flux impacté (source, dest, port). Ne courez pas après des graphiques agrégés. Exécutez ss -ti dst <ip> et enregistrez retransmissions, RTT, cwnd.
Vérifiez les compteurs d’interface hôte aux deux bouts : ip -s link, ethtool -S. Si RX drops/missed/no-buffer montent sur l’un ou l’autre, vous avez un problème côté hôte à corriger avant de blâmer le réseau.
Vérifiez l’équilibre softirq CPU : mpstat et /proc/interrupts. Si un cœur est submergé, corrigez IRQ/RSS.
Validez MTU et PMTUD avec des pings DF à des tailles réalistes. Si ça échoue, corrigez MTU/ICMP/MSS. Ne continuez pas tant que ça ne passe pas.
Capturez les paquets pendant un pic de retransmission. Si possible, capturez aux deux extrémités pour la même fenêtre. Confirmez si les segments originaux apparaissent au récepteur et si les ACKs reviennent.
Vérifiez pare-feu/conntrack si applicable : compteurs nft, conntrack count/max, logs. Si les tables sont proches du max ou que les drops augmentent, corrigez cette couche.
Enquêtez sur le réordonnancement si les compteurs montent : bonding, ECMP, overlays multipath. Essayez un test contrôlé en contournant le bond ou en pinning sur un chemin.
Engagez l’équipe réseau avec des éléments précis : « drops sur port switch X », « erreurs CRC sur uplink », « PMTU échoue à 1472 », « pics de réordonnancement quand le bond est actif ». « retransmissions élevées » de façon vague amène des réponses vagues.

Checklist opérationnelle : éviter de revivre ça

Conserver des baselines ethtool -S, ip -s link, ss -s pour hôtes connus bons.
Journaliser les erreurs/discards de ports switch et corréler avec les fenêtres d’incident.
Standardiser le MTU par domaine ; documenter où il change (tunnels, overlays, WAN).
Préférer un hashing par flux ; éviter le load balancing par paquet pour le trafic TCP dense.
Dimensionner intentionnellement conntrack ; ne laissez pas des valeurs par défaut gouverner des pare-feux critiques.
Exiger une « carte des points de capture » en environnements virtualisés (hôte, VM, vSwitch, physique).

FAQ

1) Les retransmissions TCP sont-elles toujours une perte de paquets ?

Non. Ce sont des réactions de l’émetteur à des ACKs manquants. La perte réelle est fréquente, mais le réordonnancement et les délais excessifs de mise en file sont également courants.

2) Pourquoi les retransmissions détruisent-elles tant le débit ?

TCP réduit sa fenêtre de congestion quand il croit qu’une perte est survenue. Cela réduit le débit d’envoi. Sur des chemins à haut BDP, la récupération peut être lente.

3) Si mes compteurs NIC ne montrent pas de drops, l’hôte peut-il quand même être en faute ?

Oui. Les pertes peuvent se produire dans des couches que vous ne regardez pas : virtual switching, hooks de pare-feu, conntrack, ou en amont. De plus, tous les pilotes n’exposent pas proprement chaque compteur de perte.

4) tcpdump affiche « retransmission ». Est-ce définitif ?

C’est indicatif, pas définitif. C’est basé sur ce que tcpdump observe au point de capture. Avec les offloads et la virtualisation, vous pouvez observer du trafic post-traité.

5) Dois-je désactiver GRO/GSO/TSO pour corriger les retransmissions ?

Uniquement comme diagnostic sur un hôte. Si ça aide, vous avez appris quelque chose sur une interaction pilote/offload, mais vous n’avez pas prouvé la configuration « correcte » pour l’état stable.

6) Comment discerner un problème MTU/PMTUD ?

Des tests ping DF échouant à des tailles de charge attendues sont un signal fort. Cherchez aussi des blocages sur grands transferts et un comportement MSS étrange. Corrigez le traitement ICMP frag-needed et la cohérence MTU.

7) Pourquoi les retransmissions montent-elles pendant des backups ou des jobs de réplication ?

Les flux massifs créent des rafales et de la congestion. Vous pouvez avoir des pertes microburst même si l’utilisation moyenne est modeste. Envisagez pacing, échelonnement ou séparation du trafic.

8) Est-ce que conntrack peut provoquer des retransmissions même si le serveur « n’est pas un pare-feu » ?

Oui. Si nftables suit le trafic par défaut (fréquent), la table conntrack peut se remplir ou devenir coûteuse CPU, provoquant drops et délais — surtout lors d’un fort churn de connexions.

9) Quelle est la preuve la plus rapide que le chemin réseau droppe des paquets ?

Des captures simultanées sur émetteur et récepteur montrant des segments manquants sur le récepteur, plus des compteurs hôtes propres, plaident fortement pour des pertes sur le chemin. Les compteurs de discard du switch scellent le diagnostic.

10) Dois-je tuner des sysctls comme tcp_rmem/tcp_wmem en premier ?

Non. Si vous avez de vraies pertes, des tampons plus grands peuvent amplifier la mise en file et aggraver la latence. Corrigez la perte et le réordonnancement d’abord ; tunez ensuite, avec mesures.

Prochaines étapes à faire aujourd’hui

Arrêtez de traiter « TCP retransmits » comme une cause racine. Traitez-le comme une piste à suivre.

Choisissez un flux impacté et capturez la sortie ss -ti pendant le problème.
Vérifiez ip -s link et ethtool -S aux deux bouts pour drops, missed, no-buffer, CRC.
Validez le MTU avec des pings DF sur le chemin réel.
Vérifiez l’équilibre softirq CPU et la distribution IRQ.
Si toujours flou, capturez les paquets aux deux extrémités et comparez ce qui est parti et ce qui est arrivé.
Ce n’est qu’ensuite que vous ajustez anneaux/offloads/qdisc — et faites-le chirurgicalement, avec possibilité de retour en arrière.

Si vous appliquez cette méthode de façon méthodique, la dispute sur « à qui la faute » devient ennuyeuse. L’ennui est bon. L’ennui signifie que vous êtes sur le point de corriger le problème.