3 votes

codexmonkey avatar

tcp ack delay almost 600ms， is this all right？

Demandé el 11 de Septembre, 2014
Quand la question a-t-elle été
1363 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Pour autant que je sache, tcp delay ack toujours 200ms mais maintenant dans mon environnement de production, il retarde de presque 600ms mon environnement est en dessous d'ubuntu 11.04 48G de mémoire 16 core load not heavy ; j'attrape un paquet dans le serveur (6380 est le port du serveur), le paquet est ci-dessous, comme nous pouvons le voir au temps 16:29:24. 036999 le serveur reçoit un paquet du client, mais le client ne répond pas ack jusqu'à 16:29:24.634244, il dure presque 600ms, et le timeout du client est de 500ms, donc il ferme la connexion.

600ms+ delay ack packet
16:29:12.458770 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11504, win 1107, length 0
16:29:15.070423 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9756:9790, ack 11504, win 1107, length 34
16:29:15.070497 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11504:11514, ack 9790, win 848, length 10
16:29:15.070568 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11514, win 1107, length 0
16:29:16.951893 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9790:9842, ack 11514, win 1107, length 52
16:29:16.951983 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11514:11620, ack 9842, win 848, length 106
16:29:16.952100 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11620, win 1107, length 0
16:29:18.469622 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9842:9894, ack 11620, win 1107, length 52
16:29:18.469761 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11620:11721, ack 9894, win 848, length 101
16:29:18.469839 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11721, win 1107, length 0
16:29:20.202913 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9894:10710, ack 11721, win 1107, length 816
16:29:20.203026 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11721:11726, ack 10710, win 863, length 5
16:29:20.203157 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11726, win 1107, length 0
16:29:21.893243 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 10710:10744, ack 11726, win 1107, length 34
16:29:21.893354 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11726:11736, ack 10744, win 863, length 10
16:29:21.893487 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11736, win 1107, length 0
16:29:24.036999 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 10744:10796, ack 11736, win 1107, length 52
16:29:24.240657 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 10744:10796, ack 11736, win 1107, length 52
16:29:24.536929 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [F.], seq 10796, ack 11736, win 1107, length 0
16:29:24.634244 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11736:12057, ack 10796, win 863, length 321
16:29:24.634410 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [F.], seq 10796, ack 11736, win 1107, length 0
16:29:24.634470 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [R], seq 554218496, win 0, length 0

800ms delay ack packet
16:37:01.921951 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40135:40187, ack 42430, win 1081, length 52
16:37:01.922029 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [P.], seq 42430:42655, ack 40187, win 1345, length 225
16:37:01.922097 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [.], ack 42655, win 1081, length 0
16:37:04.569001 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40187:40239, ack 42655, win 1081, length 52
16:37:04.770636 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40187:40239, ack 42655, win 1081, length 52
16:37:05.069588 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [F.], seq 40239, ack 42655, win 1081, length 0
16:37:05.178638 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40187:40239, ack 42655, win 1081, length 52
16:37:05.442263 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [P.], seq 42655:42832, ack 40239, win 1345, length 177
16:37:05.443329 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [.], ack 40239, win 1345, options [nop,nop,sack 1 {40187:40239}], length 0
16:37:05.443484 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [F.], seq 40239, ack 42655, win 1081, length 0
16:37:05.445463 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [F.], seq 42832, ack 40240, win 1345, options [nop,nop,sack 1 {40239:40240}], length 0
16:37:05.448999 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [R], seq 4279187611, win 0, length 0
Demandé el 11 de Septembre, 2014 par codexmonkey

0 votes

Avatar de David Schwartz

De quel délai d'attente du client parlez-vous ?

Commenté el 11 de Septembre, 2014 par David Schwartz

0 votes

Avatar de codexmonkey

@DavidSchwartz maintenant mon doute est pourquoi le délai d'ack 600ms ? (comme je sais que le délai maximum de tcp est de 200ms, ai-je tort ?) pas le timeout du client, le client a fixé le SO_RCVTIMEO 500ms, donc il timeout.

Commenté el 11 de Septembre, 2014 par codexmonkey

0 votes

Avatar de David Schwartz

Il semble qu'un paquet ait été perdu et retransmis. Le destinataire ne savait pas que le paquet avait été perdu et retransmis, et a donc lancé un délai de 200 ms lorsqu'il a reçu la retransmission. Un délai d'attente de 500 ms sur TCP est une idiotie.

Commenté el 11 de Septembre, 2014 par David Schwartz
Afficher 1 autres commentaires

Réponses

Trop de publicités?

2voto

David Schwartz avatar
David Schwartz Points 31009

La section 4.2.3.2 de la RFC 1122 précise qu'un ACK peut être retardé jusqu'à 500 millisecondes :

        A TCP SHOULD implement a delayed ACK, but an ACK should not
        be excessively delayed; in particular, the delay MUST be
        less than 0.5 seconds, and in a stream of full-sized
        segments there SHOULD be an ACK for at least every second
        segment.

Il n'y a pas d'urgence à envoyer un ACK. Il y a cependant quelque chose de bizarre ici, la retransmission semble terriblement rapide.

Répondu el 11 de Septembre, 2014 par David Schwartz (31009 Points )

0 votes

Avatar de codexmonkey

Mais le délai de mon paquet est de 600 ms, et j'ai également capturé un paquet dans le délai côté serveur de presque 900 ms.

Commenté el 11 de Septembre, 2014 par codexmonkey

0 votes

Avatar de David Schwartz

Vous semblez attendre un niveau de précision déraisonnable des minuteries TCP. Il ne s'agit pas d'un service en temps réel et à faible latence.

Commenté el 11 de Septembre, 2014 par David Schwartz

0 votes

Avatar de codexmonkey

Quand je teste le délai d'acceptation dans cette machine, il est correct, 200 ms.

Commenté el 11 de Septembre, 2014 par codexmonkey

0voto

Steffen Ullrich avatar
Steffen Ullrich Points 11972

Si vous voyez un paquet dans tcpdump, cela signifie seulement que le paquet est arrivé sur la machine. Mais, l'ACK n'est créé par le noyau que s'il a pu délivrer le paquet dans le socket buffer de l'application. Cela peut échouer parce que le paquet a été bloqué par le filtre de paquets ou parce que le système n'a pas assez de mémoire, mais le cas le plus probable est que le socket buffer de l'application est plein parce qu'il a reçu un grand nombre de données en peu de temps et qu'il n'a pas encore été capable de les traiter toutes.

Dans ce cas, le paquet est perdu même s'il est arrivé au système, donc aucun ACK ne sera généré et le paquet devra être retransmis par l'expéditeur. Si l'application est prête et qu'il y a de la place dans la mémoire tampon de la socket, le paquet peut être livré, sinon il sera perdu et aucun ACK ne sera envoyé.

Répondu el 11 de Septembre, 2014 par Steffen Ullrich (11972 Points )

0 votes

Avatar de codexmonkey

La charge de mon serveur n'est pas lourde, et la connexion est une connexion persistante, vous pouvez voir le paquet au temps 16:37:01.921951 est la réponse ok, donc les données dans le socket buff doivent déjà être livrées à l'application, il ne peut pas être socket buff plein.

Commenté el 11 de Septembre, 2014 par codexmonkey

0 votes

Avatar de Steffen Ullrich

Je vois seulement qu'il y a un ACK à ce paquet et que le paquet du serveur contient des données. Cela signifie seulement que le paquet a été placé avec succès dans le tampon de la socket et que le serveur a renvoyé des données (avec l'ACK). Cela ne dit pas que les données envoyées par le serveur sont en réponse au paquet qu'il vient de recevoir, elles peuvent être une réponse à des données antérieures. Vous ne pouvez en être sûr que si vous pouvez faire correspondre directement la demande et la réponse en examinant le contenu des données ou des techniques similaires.

Commenté el 11 de Septembre, 2014 par Steffen Ullrich

0 votes

Avatar de codexmonkey

À partir du paquet au temps 16:37:01.922029 nous pouvons voir que la taille de tcp Windows est de 1345, donc le tampon de la socket tcp ne doit pas être plein, n'est-ce pas ?

Commenté el 12 de Septembre, 2014 par codexmonkey
Afficher 2 autres commentaires

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X