Pourquoi les retransmissions TCP bloquent la communication d'une caméra industrielle, et comment isoler la cause

Dans la communication avec des caméras industrielles et le contrôle d’équipements, le symptôme le plus gênant est une liaison rapide en moyenne mais qui se bloque occasionnellement pendant plusieurs secondes. Le taux de reproduction est faible et rien ne se passe la plupart du temps, si bien que l’UI, les threads, le GC, le SDK de la caméra, la carte réseau et le commutateur commencent tous à paraître légèrement suspects.

Cet article traite d’un cas où la communication TCP entre un hôte et une application pilotant une caméra industrielle s’arrêtait occasionnellement pendant quelques secondes. À l’investigation, le coupable n’était pas le gel de l’application, mais une attente de retransmission TCP causée par une perte de paquet. De plus, activer la fonctionnalité de timestamps de la famille RFC1323 (dans le classement actuel des normes, la RFC 7323) a permis de réduire ce temps d’attente au minimum dans ce système.

Les noms d’équipements, les configurations et les chiffres ont été généralisés, mais la démarche s’applique directement en pratique.

Table des matières

1. La conclusion d’abord (en une ligne)
2. Comment le symptôme se manifeste
   • 2.1. L’application est vivante, mais seules les réponses se bloquent pendant quelques secondes
   • 2.2. La faible fréquence rend le phénomène difficile à voir dans les seuls journaux
3. Ce qui se passait réellement (schémas)
   • 3.1. La perte de paquet mène à une attente de retransmission
   • 3.2. Les blocages de plusieurs secondes correspondaient à la forme du RTO
4. Ce que nous avons examiné pendant l’investigation
   • 4.1. Écarter d’abord les causes de blocage internes à l’application
   • 4.2. Confirmer les retransmissions avec une capture de paquets
   • 4.3. Examiner les options TCP négociées
5. Pourquoi les timestamps RFC1323 aident
   • 5.1. Les timestamps existent pour le RTTM et le PAWS
   • 5.2. Ils suppriment l’ambiguïté de la mesure du RTT lors d’une retransmission
   • 5.3. Pourquoi nous avons pu resserrer le temps d’attente dans ce cas
6. Ce que nous avons réellement fait
   • 6.1. Activer les timestamps
   • 6.2. Vérifier TSopt dans le SYN / SYN-ACK
   • 6.3. Où regarder quand ça n’aide toujours pas
7. Ce qu’il faut vérifier dans Wireshark
8. Un guide de décision sommaire
9. Résumé
10. Références

1. La conclusion d’abord (en une ligne)

• Une communication TCP qui se bloque occasionnellement pendant plusieurs secondes peut être causée non pas par le gel de l’application, mais par une attente de retransmission consécutive à une perte de paquet
• Si une capture de paquets montre Retransmission avec un grand écart de temps, et que la durée du blocage correspond au comportement des attentes de RTO, c’est très suspect
• L’option TCP timestamps est un mécanisme pour la mesure du RTT et le PAWS, et elle supprime aussi l’ambiguïté de la mesure du RTT lors d’une retransmission
• Dans ce cas, l’activation de la fonctionnalité de timestamps de la famille RFC1323 a réduit le temps pendant lequel l’estimation du RTO restait ancienne et prudente, limitant les blocages de plusieurs secondes au minimum
• Cependant, ce n’est pas une solution magique qui fait disparaître la perte elle-même. Revoir la couche physique, la carte réseau, les commutateurs, les équipements intermédiaires, les pilotes et la conception des buffers reste nécessaire séparément

En bref, si la vraie nature de « ça se bloque occasionnellement pendant quelques secondes » est un temps d’attente à l’intérieur de TCP, alors travailler dur uniquement sur les tentatives de réessai côté application manque la cible. Il est plus rapide de regarder d’abord le fil et de confirmer si l’on est bien dans une attente de retransmission.

2. Comment le symptôme se manifeste

2.1. L’application est vivante, mais seules les réponses se bloquent pendant quelques secondes

La première chose déroutante est que l’application dans son ensemble ne paraît pas gelée.

• L’UI n’est pas complètement morte
• Le processus n’a pas planté
• Le CPU n’est pas saturé
• Pourtant, les réponses aux commandes de contrôle de la caméra manquent occasionnellement pendant plusieurs secondes

Des symptômes comme celui-ci sont difficiles à distinguer d’un deadlock interne à l’application ou d’une boucle infinie. De plus, dans le contrôle d’équipements, un seul blocage de plusieurs secondes crée directement l’impression d’un arrêt de ligne. Même si les moyennes paraissent propres, la perception sur le terrain est nettement plus mauvaise.

2.2. La faible fréquence rend le phénomène difficile à voir dans les seuls journaux

Ce qui rend ce type de défaut pénible, c’est le faible taux d’occurrence. Il se comporte comme s’il survenait une fois par heure, une fois par demi-journée, ou seulement quand certaines conditions se combinent par hasard.

Si l’on ne suit le phénomène qu’à travers les journaux, cela donne généralement ceci.

• Le journal de l’application s’arrête sur « envoyé » et « aucune réponse reçue »
• Le journal côté récepteur donne l’impression que « rien n’est arrivé »
• Un autre événement se produit par hasard dans la même fenêtre de temps, dispersant les suspects

Dans ce genre de situation, essayer de reconstruire la causalité à partir des seuls journaux applicatifs est un excellent moyen de s’enliser. Il est plus rapide de descendre d’un cran, jusqu’à la couche communication.

3. Ce qui se passait réellement (schémas)

3.1. La perte de paquet mène à une attente de retransmission

Le scénario cette fois est simple. Un paquet a été perdu quelque part en chemin, l’émetteur a attendu un ACK, aucun n’est arrivé, il a donc attendu l’expiration du RTO avant de retransmettre.

sequenceDiagram
    participant Host as Application hôte
    participant Net as Réseau
    participant Cam as Côté caméra

    Host->>Net: Commande de contrôle (Seq=N)
    Note over Net: Perdu ici
    Note over Host: Aucun ACK n'arrive, donc attente
    Note over Host: Récupérer cette requête nécessite d'attendre l'expiration du RTO
    Host->>Net: Retransmission de la commande de contrôle
    Net->>Cam: La commande retransmise arrive
    Cam-->>Net: ACK
    Net-->>Host: ACK
    Note over Host: La communication reprend ici

Du point de vue de l’application, on dirait que « ça s’est bloqué pendant quelques secondes », mais du point de vue de TCP, c’est simplement « aucun ACK n’est encore arrivé, donc j’attends l’expiration du minuteur de retransmission ». C’est peu spectaculaire, mais ce genre de blocage arrive tout le temps.

Le trafic de contrôle dans ce cas consistait surtout en de petits échanges request/response, et un seul échange ne mettait pas en vol une grande quantité de données non acquittées. Résultat, c’était une configuration où l’attente de RTO avait tendance à apparaître avant que suffisamment d’ACK dupliqués aient pu s’accumuler pour déclencher un fast retransmit.

3.2. Les blocages de plusieurs secondes correspondaient à la forme du RTO

L’attente de retransmission de TCP, bien qu’elle varie selon l’implémentation, se comporte de manière prudente. Selon la RFC 6298, le RTO initial a une base de 1 seconde ; si la valeur calculée est plus petite, elle est arrondie à 1 seconde, et lorsqu’une expiration se produit, le RTO double.

flowchart LR
    A[Perte de paquet] --> B[Aucun ACK n'arrive]
    B --> C[Attente du RTO]
    C --> D[Retransmission]
    D --> E{ACK reçu ?}
    E -- Oui --> F[La communication reprend]
    E -- Non --> G[Doublement du RTO]
    G --> C

Ainsi, même dans des situations où l’on voudrait que tout se résolve en quelques centaines de millisecondes, dans de mauvaises conditions, les attentes peuvent ressembler à 1 seconde, 2 secondes, 4 secondes. Le « ça se bloque occasionnellement pendant quelques secondes » de ce cas s’alignait assez naturellement avec cette forme.

4. Ce que nous avons examiné pendant l’investigation

4.1. Écarter d’abord les causes de blocage internes à l’application

Plutôt que d’accuser directement TCP, nous avons d’abord écarté les causes typiques côté application.

Ce qui compte ici, c’est de ne pas désigner un coupable en se basant uniquement sur les horodatages des journaux applicatifs. Dans les applications de contrôle d’équipements, une attente au niveau supérieur n’est parfois que le reflet d’une attente au niveau inférieur.

4.2. Confirmer les retransmissions avec une capture de paquets

En effectuant une capture de paquets, nous avons pu voir TCP Retransmission dans la fenêtre temporelle du blocage, et constater en outre qu’aucun ACK n’était revenu juste avant.

Voici les points à examiner.

• Le même Seq est-il retransmis ?
• L’écart de temps jusqu’à la retransmission correspond-il à la durée du blocage ?
• Cela ressemble-t-il à une attente d’expiration du RTO plutôt qu’à un Dup ACK ou une Fast Retransmission ?
• La connexion problématique apparaît-elle toujours sous le même tcp.stream ?

Quand ces éléments concordent, l’hypothèse « TCP attend une retransmission » devient bien plus probable que « l’application est gelée ».

4.3. Examiner les options TCP négociées

L’élément suivant que nous avons examiné était le SYN / SYN-ACK à l’établissement de la connexion. Les timestamps sont négociés lors de la poignée de main en trois temps (3-way handshake) de TCP, donc si TSopt n’apparaît pas à ce moment-là, il n’est pas utilisé sur cette connexion.

sequenceDiagram
    participant Host as Hôte
    participant Cam as Côté caméra

    Host->>Cam: SYN + TSopt ?
    Cam-->>Host: SYN/ACK + TSopt ?
    Host->>Cam: ACK
    Note over Host,Cam: Ce n'est qu'après cette négociation que TSopt peut être utilisé sur les segments suivants

Si l’on bricole les paramètres du système d’exploitation sans regarder cela, on finit avec un autre incident peu spectaculaire : « je suis pourtant sûr de l’avoir activé, mais ça ne fait aucun effet ». Les faits observés sur le fil pèsent plus lourd que les valeurs configurées.

5. Pourquoi les timestamps RFC1323 aident

En pratique, on continue d’appeler cela « les timestamps RFC1323 », mais la norme actuelle est la RFC 7323. Cet article suit l’usage habituel et écrit RFC1323, tout en désignant l’option TCP timestamps.

5.1. Les timestamps existent pour le RTTM et le PAWS

L’option timestamps de TCP est utilisée principalement pour deux objectifs.

• Le RTTM (Round-Trip Time Measurement)
• Le PAWS (Protect Against Wrapped Sequences)

Ce qui a aidé dans ce cas, c’est le côté RTTM. En faisant renvoyer par le pair le TSval d’un segment transmis dans le TSecr de l’ACK, l’émetteur peut mesurer le RTT de façon plus fine et plus précise.

5.2. Ils suppriment l’ambiguïté de la mesure du RTT lors d’une retransmission

Une fois qu’une retransmission se produit, sans timestamps, il devient ambigu de savoir si « cet ACK répond à l’émission originale ou à la retransmission ». C’est précisément le point auquel s’intéresse l’algorithme de Karn.

La RFC 6298 indique qu’il ne faut pas prendre d’échantillon de RTT sur un segment retransmis. La raison est qu’on ne peut pas savoir à quelle émission l’ACK répond. Avec l’option timestamps, en revanche, cette ambiguïté disparaît : en regardant le TSecr de l’ACK entrant, on peut identifier quel segment, avec quel TSval, est réellement parvenu.

sequenceDiagram
    participant Host as Émetteur
    participant Cam as Récepteur

    Host->>Cam: Seq=N, TSval=1000
    Note over Host,Cam: Ce segment est perdu
    Note over Host: Aucun ACK n'arrive, donc attente
    Host->>Cam: Retransmission de Seq=N, TSval=2000
    Cam-->>Host: ACK, TSecr=2000
    Note over Host: On peut identifier à quelle émission cela répond

C’est le cœur de l’amélioration dans ce cas.

5.3. Pourquoi nous avons pu resserrer le temps d’attente dans ce cas

Dans ce cas, la perte de paquets se produisait de temps à autre, et à chaque occurrence, elle poussait les estimations RTT / RTO vers le côté prudent. Activer les timestamps facilite la mise à jour de l’estimation du RTT même dans des scénarios impliquant des retransmissions, ce qui limite le temps pendant lequel l’estimation du RTO continue de gonfler alors qu’elle est obsolète.

Autrement dit, ce que nous avons fait n’est pas une solution magique qui rend TCP plus rapide, mais réduire le temps pendant lequel TCP continue de surveiller et d’attendre plus longtemps que nécessaire.

Bien sûr, la RFC 7323 ne prétend pas que « davantage d’échantillons de RTT résolvent proprement tout ». Le degré auquel elle aide l’optimisation du RTO reste limité à certains égards. Néanmoins, le fait qu’elle supprime l’ambiguïté lors d’une retransmission peut aider assez naturellement dans un système comme celui-ci.

Il y a des mises en garde.

• Une partie de cela dépend de l’implémentation de la pile TCP
• Les timestamps seuls ne font pas disparaître la perte de paquets elle-même
• Si la couche physique ou des équipements intermédiaires sont en cause, la cause racine se trouve ailleurs
• SACK, les pilotes de carte réseau, les paramètres de déchargement (offload) et les problèmes côté commutateur sont mieux examinés séparément

Cela dit, dans un système comme celui-ci — où « la perte n’est pas nulle » mais où « ce qui fait vraiment mal, c’est l’attente de plusieurs secondes » — cela peut être assez efficace.

6. Ce que nous avons réellement fait

6.1. Activer les timestamps

Comme mesure corrective, nous nous sommes assurés que l’option timestamps pouvait être négociée aux deux extrémités de la connexion. Sous Windows, cela est parfois traité comme l’option RFC 1323, et cela est affecté par les paramètres du système d’exploitation et du réseau.

En pratique, cependant, ce qui compte n’est pas « c’est activé dans l’écran de configuration » mais « TSopt est réellement présent sur les paquets SYN / SYN-ACK observés sur le fil ». Ceci est vraiment vrai.

6.2. Vérifier TSopt dans le SYN / SYN-ACK

Après l’activation, nous avons vérifié trois choses.

• Le SYN de la connexion en question porte-t-il TSopt ?
• Le côté SYN/ACK renvoie-t-il également TSopt ?
• Les segments de données et les ACK suivants continuent-ils de porter TSopt ?

Ce n’est qu’une fois ces points confirmés que l’on peut dire que « les timestamps sont réellement utilisés sur cette connexion ».

6.3. Où regarder quand ça n’aide toujours pas

Même avec les timestamps activés, l’amélioration peut être lente dans des cas comme ceux-ci.

• Le taux de perte lui-même est élevé
• Un équipement intermédiaire casse, supprime ou altère les options TCP
• Il existe un problème distinct autour de la carte réseau / du pilote / du déchargement (offload)
• L’application fait dépendre tout d’un seul appel synchrone, si bien qu’une seule attente ressemble à un arrêt total
• La cause principale n’est en réalité pas TCP, mais un arrêt de traitement côté caméra ou une file interne engorgée dans l’équipement

Il est donc plus clair de faire avancer les mesures dans cet ordre.

1. Confirmer d’abord l’attente de retransmission sur le fil
2. Vérifier si TSopt est négocié
3. Activer les timestamps et mesurer l’écart d’amélioration
4. Si des problèmes subsistent, traiter séparément la source de la perte et la conception de l’application

7. Ce qu’il faut vérifier dans Wireshark

Voici des filtres d’affichage pratiques pour l’isolement.

tcp.stream eq <flux cible>
tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.lost_segment
tcp.options.timestamp.tsval
tcp.options.timestamp.tsecr

Voici quelques astuces pour interpréter les résultats.

• Réduire le champ d’observation à la connexion cible avec tcp.stream
• Afficher Time delta from previous displayed packet pour voir directement les secondes de blocage
• Confirmer si Retransmission apparaît au moment problématique
• Confirmer si TSopt est négocié dans le SYN / SYN-ACK à l’établissement de la connexion
• Vérifier si TSecr est bien renvoyé dans les ACK

Lors de la mise en correspondance des journaux avec les paquets, il faut aussi surveiller le décalage entre l’horloge de l’application et l’horloge de la capture. S’ils sont désynchronisés, on a tendance à accuser un événement sans rapport.

8. Un guide de décision sommaire

Cette dernière ligne est vraiment fréquente. La satisfaction d’avoir modifié un paramètre et le fait qu’il soit réellement utilisé sur le fil sont deux choses différentes.

9. Résumé

Points clés cette fois-ci :

• « Ça se bloque occasionnellement pendant plusieurs secondes » peut être l’attente de retransmission de TCP, et non le gel de l’application
• Si la durée du blocage correspond au comportement des attentes de RTO et que Retransmission est visible, on est sur une bonne piste
• L’option TCP timestamps est un mécanisme pour le RTTM et le PAWS, et elle supprime l’ambiguïté de la mesure du RTT lors d’une retransmission
• Dans ce cas, l’activation des timestamps de la famille RFC1323 a limité le temps pendant lequel le RTO restait excessivement prudent

Approches à éviter :

• Désigner le coupable d’un blocage de communication à partir des seuls journaux applicatifs
• Ne regarder que les paramètres du système d’exploitation sans examiner les paquets réels
• Supposer qu’activer les timestamps élimine aussi la cause de la perte

Approches efficaces en pratique :

• Regarder d’abord le fil
• Confirmer la forme des retransmissions et des temps d’attente
• Confirmer la négociation de TSopt
• Même après l’amélioration, traiter séparément la source de la perte et la conception de l’application

Autrement dit, pour ce type de défaut, « localiser où ça attend » passe avant « rendre ça plus rapide ». Rien qu’en ne manquant pas ce point, l’investigation devient considérablement plus courte.

10. Références

• RFC 1323 - TCP Extensions for High Performance
• RFC 7323 - TCP Extensions for High Performance
• RFC 5681 - TCP Congestion Control
• RFC 6298 - Computing TCP’s Retransmission Timer

• [Description of Windows TCP features - Windows Server

  Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/description-tcp-features)

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Études de cas associées

Ces études de cas présentent une démarche proche d’analyse, de priorisation ou de refonte.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi ma connexion TCP se bloque-t-elle occasionnellement pendant plusieurs secondes ?

Une cause fréquente est une attente de retransmission consécutive à une perte de paquet, et non le gel de l'application. Quand un paquet est perdu, l'émetteur attend un ACK qui n'arrive jamais et doit patienter jusqu'à l'expiration du délai de retransmission (RTO) avant de renvoyer les données. Selon la RFC 6298, le RTO initial a une base de 1 seconde et double à chaque expiration ; dans de mauvaises conditions, les attentes ressemblent donc à 1, 2, puis 4 secondes — ce qui correspond exactement au symptôme « ça se bloque occasionnellement pendant quelques secondes ».

Comment confirmer dans Wireshark que des retransmissions TCP sont à l'origine des blocages ?

Réduisez d'abord le champ d'observation à la connexion concernée avec le filtre tcp.stream, puis recherchez tcp.analysis.retransmission dans la fenêtre temporelle du blocage. Vérifiez si le même numéro de séquence est retransmis, si l'écart de temps avant la retransmission correspond à la durée du blocage, et si la forme correspond à une attente d'expiration du RTO plutôt qu'à une retransmission rapide. Examinez aussi le SYN/SYN-ACK pour voir si l'option timestamps (TSopt) a été négociée, et affichez le delta de temps par rapport au paquet précédent pour voir directement les secondes de blocage.

Que fait réellement l'option TCP timestamps (RFC 1323) ?

L'option timestamps sert deux objectifs : le RTTM (Round-Trip Time Measurement) et le PAWS (Protect Against Wrapped Sequences). Pour les blocages liés aux retransmissions, c'est le côté RTTM qui compte : le pair renvoie le TSval de l'émetteur dans le TSecr de l'ACK, ce qui supprime l'ambiguïté sur le fait qu'un ACK réponde à l'émission originale ou à la retransmission. Cela permet à TCP de continuer à mettre à jour son estimation du RTT même dans des scénarios impliquant des retransmissions, ce qui limite la durée pendant laquelle le RTO reste gonflé et excessivement prudent. La norme actuelle est la RFC 7323, même si l'on continue par habitude à parler de RFC 1323.

Activer les timestamps TCP corrige-t-il la perte de paquets ?

Non. Activer les timestamps n'est pas une solution magique qui fait disparaître la perte elle-même — cela réduit seulement le temps pendant lequel TCP continue d'attendre plus longtemps que nécessaire. Si le taux de perte est élevé, ou si la cause racine se situe dans la couche physique, les pilotes de la carte réseau, les paramètres de déchargement (offload), les commutateurs ou des équipements intermédiaires qui altèrent les options TCP, ces points doivent être traités séparément. Vérifiez aussi sur le fil que TSopt apparaît bien dans le SYN et le SYN-ACK, car un paramètre activé mais jamais négocié n'a aucun effet.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.