Fenêtre de réception TCP
Je suis en train d'essayer de comprendre comment la fenêtre du récepteur affecter le débit sur une connexion à latence élevée.
J'ai un client simple paire de serveurs d'applications sur les deux machines, de loin en loin, avec la connexion entre les deux 250mSec de latence de RTT. J'ai couru ce test avec Windows (XP, 7), Linux (Ubuntu 10.x), avec les mêmes résultats, donc, pour des raisons de simplicité, supposons le cas de:
Client de la réception de données: WinXP Pro
Serveur d'envoi des données: Win7 Pro
Encore une fois, le temps de latence est 250mSec RTT.
Je lance mon test TCP sans changer le récepteur taille de la mémoire tampon sur le client (la valeur par défaut est de 8 ko), et je vois sur le câble (à l'aide de Wireshark):
- au client d'envoyer les accusés de réception sur le serveur et les paquets TCP contient RWIN=65k
- serveur envoie des données et rapport RWIN=65k
À la recherche à la trace, je vois une des éclats de 3-4 paquets (avec une charge utile de 1460 octets), immédiatement suivie par l'accusé de réception envoyé à partir de l'ordinateur client au serveur, puis plus rien pendant environ 250mSec puis une nouvelle rafale de paquets à partir du serveur vers le client.
Donc, en conclusion, il apparaît que le serveur n'envoie pas de nouvelles données avant même qu'il ne se remplit que le récepteur de la fenêtre.
Faire plus d'essais, j'ai également fait le même test en changeant le récepteur de la taille de la mémoire tampon sur la machine client (sur Windows, changer le récepteur de la taille de la mémoire tampon finit par affecter la RWIN annoncés par la machine). Je m'attends à voir un grand éclat de paquets avant de les bloquer pour ACK... et au moins un débit plus élevé.
Dans ce cas, j'ai mis recv taille de la mémoire tampon à 100 000 000. Les paquets du client vers le serveur ont maintenant une RWIN=99,999,744 (eh bien, c'est joli), mais malheureusement, le modèle des données envoyées à PARTIR du serveur vers le client est toujours le même: une courte rafale suivie par une longue attente.
Pour confirmer ce que je vois sur le fil, j'ai aussi mesurer le temps d'envoyer un bloc de données à partir du serveur vers le client. Je ne vois pas de changements dans l'utilisation d'un grand RWIN ou utiliser la valeur par défaut.
Quelqu'un peut-il m'aider à comprendre pourquoi la modification de la RWIN n'a pas vraiment d'incidence sur le débit?
Quelques remarques:
- serveur envoie des données aussi vite que possible à l'aide de write() de blocs de 8 ko
- comme je l'ai dit avant, je vois des effets similaires à l'aide de Linux. changer le récepteur taille de buffer affecte la RWIN utilisé par un nœud, mais le débit reste le même.
- Je analyser le suivi après plusieurs centaines de paquets, pour donner suffisamment de temps pour le TCP démarrage lent mécanisme pour agrandir la CWIN taille.
Comme l'a suggéré, je vais ajouter une petite capture d'écran d'un fil de trace ici
No. Time Source Destination Protocol Length Info
21 2.005080 CCC.CCC.CCC.CCC sss.sss.sss.sss TCP 60 57353 > 21500 [ACK] Seq=1 Ack=11681 Win=99999744 Len=0
22 2.005109 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=19305 Ack=1 Win=65536 Len=1460
23 2.005116 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=20765 Ack=1 Win=65536 Len=1460
24 2.005121 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=22225 Ack=1 Win=65536 Len=1460
25 2.005128 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 946 21500 > 57353 [PSH, ACK] Seq=23685 Ack=1 Win=65536 Len=892
26 2.005154 CCC.CCC.CCC.CCC sss.sss.sss.sss TCP 60 57353 > 21500 [ACK] Seq=1 Ack=14601 Win=99999744 Len=0
27 2.007106 CCC.CCC.CCC.CCC sss.sss.sss.sss TCP 60 57353 > 21500 [ACK] Seq=1 Ack=16385 Win=99999744 Len=0
28 2.007398 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=24577 Ack=1 Win=65536 Len=1460
29 2.007401 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=26037 Ack=1 Win=65536 Len=1460
30 2.007403 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=27497 Ack=1 Win=65536 Len=1460
31 2.007404 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=28957 Ack=1 Win=65536 Len=1460
32 2.007406 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=30417 Ack=1 Win=65536 Len=1460
33 2.007408 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 946 21500 > 57353 [PSH, ACK] Seq=31877 Ack=1 Win=65536 Len=892
34 2.007883 CCC.CCC.CCC.CCC sss.sss.sss.sss TCP 60 57353 > 21500 [ACK] Seq=1 Ack=19305 Win=99999744 Len=0
35 2.257143 CCC.CCC.CCC.CCC sss.sss.sss.sss TCP 60 57353 > 21500 [ACK] Seq=1 Ack=22225 Win=99999744 Len=0
36 2.257160 CCC.CCC.CCC.CCC sss.sss.sss.sss TCP 60 57353 > 21500 [ACK] Seq=1 Ack=24577 Win=99999744 Len=0
37 2.257358 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=32769 Ack=1 Win=65536 Len=1460
38 2.257362 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=34229 Ack=1 Win=65536 Len=1460
39 2.257364 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=35689 Ack=1 Win=65536 Len=1460
40 2.257365 sss.sss.sss.sss CCC.CCC.CCC.CCC TCP 1514 21500 > 57353 [ACK] Seq=37149 Ack=1 Win=65536 Len=1460
Comme vous le voyez, le serveur d'arrêter d'envoyer des données à partir des paquets #33.
Client d'envoyer ACK au paquet #34 d'un vieux paquet (seq=19305, envoyé le paquet n ° 20, non représenté ici).
Avec une RWIN de 100mo, je m'attends à ce que le serveur de ne PAS bloquer pendant un certain temps.
Après 20 à 30 paquets, la fenêtre de congestion sur le côté serveur doit être suffisamment grand pour envoyer plus de paquets que je vois...
Je suppose que la fenêtre de congestion est éventuellement va croître jusqu'à la RWIN... mais encore, même après des centaines de paquets, le motif est le même: données les données de bloquer pour 250mSec...
OriginalL'auteur fabrizi0 | 2012-04-23
Vous devez vous connecter pour publier un commentaire.
Je peux deviner deux choses à partir de l'exemple que vous avez fournie:
Pour la fenêtre d'une connexion TCP à l'échelle d'une certaine taille, à la fois la mémoire tampon d'envoi de l'expéditeur et le tampon de réception sur le récepteur doit être assez grande.
La fenêtre réelle utilisée est le minimum de la fenêtre de réception offerte/demandé par le destinataire et l'expéditeur de l'OS-définir la taille du tampon d'envoi.
Longue histoire courte, vous devez configurer la taille du tampon d'envoi sur le serveur.
Pour clarifier les choses, nous allons analyser votre échantillon de paquet par paquet.
Le serveur envoie un autre tas de données:
Avis de la
PSH. C'est un drapeau indiquant à tout le houblon entre un bloc de données a été envoyé et s'il vous plaît envoyer à l'autre bout.("Complet" morceau en cours de votre 8ko dans ce cas)
Alors que le serveur est encore l'envoi, il obtient 2 accusés de réception:
Note en particulier les numéros:
Ack=14601etAck=16385. Ces chiffres sont les numéros de séquence des paquets le récepteur est reconnaissant.Ack=14601 signifie "j'ai reçu tout à seq pas 14601".
Remarque aussi ce sont des données les plus anciennes, pas dans l'exemple que vous avez donné.
De sorte que le serveur traite les accusés de réception et continue à envoyer des données:
Ici, nous avons un bloc complet de données: 1460*5+892 == 8192.
Puis, 0.443 ms après l'envoi de ce dernier paquet, il obtient une plus ACK:
Et puis il y a un retard de presque exactement les 250ms, au cours de laquelle le serveur envoie rien, avant la réception de ces:
Puis continue à envoyer:
Il y a deux choses très intéressantes à remarquer ici.
Tout d'abord, combien d'octets ont été envoyés par le serveur sans attendre un accusé de réception.
Te dernier accusé de réception seq pas reçu par le serveur avant que le retard
Ack=19305, et le seq pas du dernier paquet envoyé par le serveur à ce moment là estSeq=30417.Il y a donc au cours de cette pause, il y a 11112 octets que le serveur a envoyé qui n'ont pas encore été roupe animé par le client.
Deuxième, qui a été l'un accusé de réception reçue par le serveur, un instant après il a envoyé un tas de données, qui ne déclenchent pas d'envoyer plus. C'est comme si que l'accusé de réception n'était pas assez bon.
L'accusé de réception reçu avant qui a été
Ack=16385, donnant 30417-16385=14032 octets qui ont été envoyés par le serveur non reconnus à ce point. Seulement après avoir reçu un accusé de réception pour la seq pas 24577, la réduction du comte de 30417-24577=5840, ne le démarrage du serveur d'envoi de nouveau.Donc, le fait que la taille de la mémoire tampon de 8 k est grand par rapport à l'efficacité de la taille de la fenêtre de 16k signifie que le débit est de fait réduit un peu parce que le serveur n'enverra pas de la 8k bloc jusqu'à ce qu'il y a de la place pour tous.
Enfin, pour ceux qui se demandent, il y a une option TCP on appelle la fenêtre de mise à l'échelle qui permet à une extrémité d'une connexion à déclarer que la taille de la fenêtre est en fait un multiple du nombre dans l'en-tête TCP. voir RFC 1323. L'option est passé dans les paquets SYN de sorte qu'ils ne sont pas visibles à la mi-connexion - il ya seulement un soupçon que la fenêtre de mise à l'échelle est en effet parce que la taille de la fenêtre TCP en-tête est plus petite que la fenêtre qui est utilisé.
OriginalL'auteur Michael Slade
Vous ne pouvez pas définir une taille du tampon de réception de >= 64 ko une fois la socket est connecté. Vous devez faire en premier. Dans le cas d'un serveur, cela signifie que le réglage de la taille du tampon de réception sur la socket d'écoute: accepté sockets hériter de son support, ils sont acceptés à partir de. Si vous ne le faites pas, le TCP window scaling option ne peut pas être négocié pour que les camarades n'ont aucun moyen de dire à propos de la taille de plus de 64 ko.
OriginalL'auteur user207421
Au moment de l'envoi de la machine reçoit l'accusé de réception du récepteur, de la quantité de données n'est l'envoi de la machine, ont mis en file d'attente pour l'envoyer? Parce que le protocole TCP est un flux à base de protocole qui n'ont pas de paquet les pauses dans le flux de données, un protocole TCP expéditeur n'a aucun moyen de savoir quand il doit envoyer une partielles, et quand il doit attendre plus de données à arriver. En règle générale, si une application TCP reçoit un accusé de réception d'un paquet, il décide qu'il vaut la peine de transmettre ce qu'elle a jusqu'à ce que la mémoire tampon de transmission est vide, mais si les données sont mis en file d'attente pour la transmission après qu'il peut attendre jusqu'à ce qu'il reçoit un accusé de réception avant l'envoi d'un autre lot.
OriginalL'auteur supercat
Le récepteur de la taille de la fenêtre affecte directement le débit. Le débit de <= RWIN/RTT.
Quelques choses peut également diminuer le débit. Sont ECN bits dans l'en-tête valeur 1? Savez-vous si il n'y a aucune perte de paquets sur chaque côté? Il semble que le serveur est le moment de sortir. Pouvez-vous imprimer les numéros de séquence des paquets entrants et sortants, les accusés de réception sur le côté client et d'imprimer des informations similaires sur le côté serveur. Si le récepteur est le numéro de séquence est 5 et il reçoit 6,7,8,9 il sera accusé de réception 6,7,8,9. Mais si 6 est perdu, il sera accusé de réception 5 quand il reçoit des paquets 7,8,9. Les numéros de séquence peuvent révéler beaucoup d'informations.
La 250ms pause semble comme un délai d'attente.
Slow-Start
Ce qui peut se passer, c'est
Serveur envoie 1 paquet, obtient 1 ack
Le serveur envoie les 2 paquets, obtient 2 accusés de réception(2,3)
Serveur envoie 4 paquets, obtient 4 les accusés de réception(4,5,6,7)
Serveur envoie 8 paquets, obtient 4 les accusés de réception(paquets perdus avant le client a reçu les)(8,9,10,11)(délai d'attente de 12)
Serveur envoie 4 paquets, obtient 4 les accusés de réception(12,13,14,15)
Serveur envoie 5 paquets, obtient 4 les accusés de réception(16,17,18,19)(délai d'attente de 20)
Le serveur envoie 3 paquets, obtient 3 accusés de réception(20,21,22)
Serveur envoie 4 paquets, obtient 4 les accusés de réception(23,24,25,26)
Serveur envoie 5 paquets, obtient 4 les accusés de réception(27,28,29,30)(délai d'expiration 31)
Serveur continue 3,4,5 boucle
Les bits ECN pourraient être fixées par le routeur. Ce qui ralentirait la vitesse à laquelle les données sont envoyées. Le client peut envoyer 5 paquets et le routeur est le réglage de l'ECN peu ou rejeter le paquet. Les bits ECN est une manière de notifier chaque côté si le réseau est en train de devenir encombré. en.wikipedia.org/wiki/Explicit_Congestion_Notification
Si c'est un réseau à latence élevée, il est probable il ya de nombreux sauts le long du chemin. La fenêtre du récepteur peut être aussi grand que le goulot d'étranglement quelque part entre les deux. Mais si ce goulot d'étranglement est en baisse de paquets, le récepteur n'aurais jamais su qu'ils étaient envoyés. Donc ça va ack autant de paquets qu'il a obtenu, tandis que le serveur délai d'attente pour recevoir peut-être 10 accusés de réception plutôt que le 4 il a obtenu.
Je peux essayer de re-lancer le test et capturer une trace à la fois la fin et essayer de reconstruire manuellement ce qui se passe vraiment... mais qui va prendre un certain temps. Tous les outils que vous recommanderiez pour m'aider à retracer l'état interne?
Ok, RWIN peut être max 65k, mais il y a extension de la RFC 1323 que, fondamentalement, de permettre la transmission d'un facteur d'échelle dans le paquet SYN, dans l'option en-tête de paquet TCP. Que, fondamentalement, peut prolonger la RWIN au-delà de la traditionnelle 65Kb.
OriginalL'auteur JustinDanielson