web-dev-qa-db-fra.com

Comprendre [Segment TCP non accusé de réception] [Segment TCP précédent non capturé]

Nous effectuons des tests de charge sur nos serveurs et j'utilise tshark pour capturer des données dans un fichier pcap, puis j'utilise l'interface graphique de wirehark pour voir quelles erreurs ou avertissements apparaissent en allant dans Analyser -> Info expert avec mon pcap chargé dans ..

Je vois diverses choses que je ne suis pas sûr ou que je ne comprends pas encore complètement ..

Sous Avertissements, j'ai: 779 Avertissements pour TCP: segment ACKed qui n'a pas été capturé (commun au début de la capture) 446 TCP: segment précédent non capturé (commun au début de la capture)

Un exemple est: 40292 0,000 xxx xxx TCP 90 [TCP segment non identifié ACKed] [TCP segment précédent non capturé] 11210> 37586 [PSH, ACK] Seq = 3812 Ack = 28611 Win = 768 Len = 24 TSval = 199317872 TSecr = 4506547

Nous avons également exécuté le fichier pcap via une commande Nice qui crée une colonne de données en ligne de commande

commander

tshark -i 1 -w file.pcap -c 500000

essentiellement vu quelques choses dans la colonne tcp.analysis.lost_segment mais pas beaucoup .. \

Quelqu'un éclaire ce qui pourrait se passer? tshark n'est pas en mesure de suivre l'écriture des données, un autre problème? Faux positif?

tcpwiresharktshark
8
Steve

Cela peut très bien être un faux positif. Comme le dit le message d'avertissement, il est courant qu'une capture démarre au milieu d'une session TCP. Dans ces cas, il ne dispose pas de ces informations. S'il vous manque vraiment des accusés de réception, il est temps de commencer à chercher en amont de votre hôte où ils disparaissent. Il est possible que tshark ne puisse pas suivre les données et il supprime donc certaines mesures. À la fin de votre capture, il vous dira si le "paquet a chuté du noyau" et combien. Par défaut, tshark désactive la recherche DNS, tcpdump ne le fait pas. Si vous utilisez tcpdump, vous devez passer le commutateur "-n". Si vous rencontrez un problème de disque IO alors vous pouvez faire quelque chose comme écrire dans la mémoire/dev/shm. .

Je parie que vous avez des sessions TCP très longues et que lorsque vous démarrez votre capture, il vous manque simplement certaines parties de la session TCP à cause de cela. Cela dit, voici quelques-unes des choses que j'ai vues provoquer des doublons/manquants.

  1. Commutateurs - (très peu probable mais parfois ils tombent malades)
  2. Routeurs - plus susceptibles que les commutateurs, mais pas beaucoup
  3. Pare-feu - Plus probable que les routeurs. Les choses à rechercher ici sont l'épuisement des ressources (licence, processeur, etc.)
  4. Logiciel de filtrage côté client - antivirus, détection de logiciels malveillants, etc.
4
dtorgo

Une autre cause de "TCP ACKed Unseen" est le nombre de paquets qui peuvent être abandonnés lors d'une capture. Si j'exécute une capture non filtrée pour tout le trafic sur une interface occupée, je verrai parfois un grand nombre de paquets "abandonnés" après l'arrêt de tshark.

Lors de la dernière capture que j'ai faite en voyant cela, 2893204 paquets ont été capturés, mais une fois que j'ai appuyé sur Ctrl-C, j'ai reçu un message de perte de 87581 paquets. C'est une perte de 3%, donc lorsque wirehark ouvre la capture, il est probable qu'il manque des paquets et signale des paquets "invisibles".

Comme je l'ai mentionné, j'ai capturé une interface très occupée sans filtre de capture, donc tshark a dû trier tous les paquets, lorsque j'utilise un filtre de capture pour supprimer une partie du bruit, je ne reçois plus l'erreur.

2
Nathan

Echantillon Acked Unseen

Salut les gars! Juste quelques observations de ce que je viens de trouver dans ma capture:

À de nombreuses reprises, la capture de paquets signale "segment ACKed qui n'a pas été capturé" du côté client, qui signale la condition selon laquelle le PC client a envoyé un paquet de données, le serveur accuse réception de ce paquet, mais la capture de paquets effectuée sur le client n'inclut pas le paquet envoyé par le client

Au départ, je pensais que cela indique un échec du PC à enregistrer dans la capture un paquet qu'il envoie parce que "par exemple, la machine qui exécute Wireshark est lente" ( https: // osqa-ask. cableshark.org/questions/25593/tcp-previous-segment-not-captured-is-that-a-connectivity-issue )
Cependant, à chaque fois que je vois cette alerte "Segment ACK non capturé", je peux voir un enregistrement d'un paquet "invalide" envoyé par le PC client.

  • Dans l'exemple de capture ci-dessus, l'image 67795 envoie un ACK pour 10384

  • Même si WireShark signale une longueur IP fausse (0), la trame 67795 aurait une longueur de 13194

  • Le cadre 67800 envoie un ACK pour 23524
  • 10384 + 13194 = 23578
  • 23578 - 23524 = 54
  • 54 est en fait la longueur des en-têtes Ethernet/IP/TCP (14 pour Ethernt, 20 pour IP, 20 pour TCP)
  • Donc, en fait, la trame 67796 représente un gros TCP (13194 octets) que le système d'exploitation a essayé de mettre sur le port
    • Le pilote NIC le fragmentera en plus petits morceaux de 1500 octets afin de transmettre sur le réseau
    • Mais Wireshark exécuté sur mon PC ne parvient pas à comprendre qu'il s'agit d'un paquet valide et à l'analyser. Je crois que Wireshark fonctionnant sur le serveur Windows 2012 lit correctement ces captures
  • Donc, après tout, ces alertes "Longueur IP fausse" et "Segment ACK non capturé" étaient en fait de faux positifs dans mon cas
0
Stan Strijakov