Linux Slow Start: la modification de l'itinéraire IP n'a aucun effet sur la fenêtre initiale

J'ai changé la fenêtre initiale TCP sur ma machine à 10 comme indiqué ci-dessous

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10

Et changé tcp_slow_start_after_idlecomme indiqué ci-dessous

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

une confirmation d'exposition de route ip est donnée ci-dessous

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

Maintenant, quand je fais un tcpdump sur le site Web, je ne semble pas voir de changement dans la fenêtre initiale avec le WIN / MSS restant 4 par défaut. 5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

Le curl hit que j'ai fait sur la page Web a demandé environ 30 Ko de données.

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

Quel pourrait être le problème dans mon approche?

Noyau

[user~]$ uname -r
3.0.4x86_64-linode21

En tant que mise à jour, voici les résultats lorsque j'essaie google.com

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

Comme vous pouvez le voir, WIN / MSS est 14600/1460 = 10 dans ce cas

J'ai essayé de frapper mon site depuis la machine serveur elle-même via curl et voici le résultat:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

WIN / MSS est 32792/16396 = 2 dans ce cas

linux networking tcp optimization tcp-slow-start Quintin Par
la source

gardez à l'esprit, si vous frappez cela à partir d'une machine Linux, vous devrez également être sur 3.0, fouillez la source / les balises pour confirmer la version 3 exacte qui a provoqué le changement

Sam Saffron

@QuintinPar Pourriez-vous ajouter une sortie tcpdump avec une connexion sortante de votre machine de test?

kupson

@kupson J'ai mis à jour la question

Quintin Par

Autant que je sache, vous ne pouvez pas influencer la fenêtre initiale sur les connexions entrantes. Votre connexion à Google montre que vous avez IW réglé sur 10. L'infface de bouclage est assez spéciale avec ce grand MTU, peut-être qu'il y a un plafond sur la fenêtre initiale dans la source du noyau.

kupson

gardez à l'esprit, 2 choses détermineront l'IW. Fenêtre de congestion initiale maximale des clients et IW des serveurs. Le plus petit gagne. Exécutez le test à partir de 2 machines, le serveur doit avoir l'IW défini par défaut dans 3.0 ... et les clients XP / Vista / Win7 ne restreignent pas l'IW, alors faites de bons clients pour le test. 3.0 Les clients Linux fonctionnent également, mais doivent être une machine distincte.

Sam Saffron

Réponses:

Je pense que vous comprenez mal le fonctionnement de TCP.

Chaque paquet envoyé annoncera toujours une fenêtre de récepteur (aka. RWIN) et un facteur d'échelle facultatif, voir RFC 1323

L'expéditeur n'est pas autorisé à envoyer plus que la quantité de données spécifiée dans le RWIN sans qu'il soit reconnu. Selon la fenêtre de congestion, l'expéditeur peut décider de remplir le RWIN ou non.

Ainsi, il y a deux bits d'informations qui sont publics dans les paquets TCP. Le RWIN sur le serveur et le RWIN sur le client. Ces deux chiffres dictent la taille maximale de la fenêtre de congestion aux deux extrémités.

Le RWIN sur le serveur est intéressant lorsque nous essayons d'optimiser les performances pour les téléchargements de fichiers.

Le RWIN sur le client est intéressant lorsque nous essayons de déterminer la vitesse de téléchargement.

Aucun de ces chiffres ne rend public la fenêtre de congestion à l'autre extrémité .

Donc, si j'ai un RWIN de 64k, la fenêtre de congestion sur le serveur peut être N'IMPORTE QUEL numéro inférieur à 64k.

La seule façon de déterminer la fenêtre de congestion réelle est de compter les paquets.

Si je sais:

Mon temps d'aller-retour (RTT) est d'environ 200 ms.
Je viens de demander une ressource de 100k.
J'ai un RWIN de 64k.

Si je récupère 2 paquets du serveur d'une longueur de 1452 octets dans ~ 200 ms, il est probable que la fenêtre de congestion sur le serveur soit inférieure à 4356, car s'il était plus grand, 3 paquets seraient envoyés. Si IW était réglé sur 10, je verrais une rafale de 10 paquets autour de la marque des 200 ms.

Si vous modifiez votre IW et souhaitez confirmer que la modification a fonctionné, vous devez compter les paquets pour obtenir une estimation de la taille de la fenêtre de congestion sur le serveur.

Gardez à l'esprit, vous voudrez probablement regarder la conversation directement après le SYN, SYN-ACK, ACK pour vous assurer que vous ne regardez pas au milieu d'une conversation (où la fenêtre de congestion aurait déjà pu s'agrandir).

Sam Saffron
la source

La différence entre la fenêtre d'encombrement et la fenêtre tcp est indiquée dans 20.6 (démarrage lent) de TCP / IP illustré: "Le démarrage lent ajoute une autre fenêtre au TCP de l'expéditeur: la fenêtre d'encombrement, appelée cwnd" (le gras est le mien). Il y a un diagramme de séquence en 20.7 qui montre cela lors du transfert en masse.

Kyle Brandt

La taille de la fenêtre sera la plus petite: taille de la fenêtre d'initialisation du serveur ou RWIN client. Étant donné que 5840 est le RWIN par défaut pour Linux 2.6, il semble que votre client soit le facteur limitant ici.

Essayez à partir d'une boîte Windows. Windows XP a un RWIN de 64k, une version plus récente 8k.

Source: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (La partie intéressante est en dessous de la vidéo)

Modifier: étendre la réponse pour la rendre plus claire:

Dans la négociation TCP, le client envoie un paquet SYN au serveur en envoyant sa taille de fenêtre maximale autorisée. (Comme le montre votre sortie tcpdump, ce sont 5840 octets)
Le serveur répond maintenant avec SYN ACK et la taille de la fenêtre sur laquelle il souhaite se mettre d'accord. Cette taille de fenêtre ne peut être plus petite que celle proposée par le client, pas plus grande. Quelle que soit la configuration du serveur, il ne peut jamais avoir des tailles de fenêtre supérieures à 5840 octets avec ce client.
Le client retourne ACK et il échange volontiers des données pour toujours.

Edit2: Les tcpdumps ajoutés à la question montrent le serveur ouvrant des connexions à Google et lui-même AGISSANT COMME CLIENT.

Quelqu'un
la source

La fenêtre initiale (proposée dans le paquet SYN) est 5840. C'est un premier paquet et la machine émettrice ne sait rien du récepteur pour le moment (je l'ai testé avec "ip route flush cache").

kupson

Euh, 17.255.209.0 est votre sous-réseau de serveur, non? Le paquet que vous voyez est DU 21.101.151.198.45873 AU 17.255.209.19.http. Je ne suis pas un expert de la sortie tcpdump, mais pour moi, cela se lit comme suit: Bonjour Server, je suis votre client, j'aime les fenêtres de 5840 octets. :) Le prochain paquet serait le serveur qui répondrait avec ACK, 5840 est super, cheers. :)

Quelqu'un

Juste pour souligner, je pense que vous vous êtes trompé: la première machine d'envoi est le client car elle ouvre la connexion, pas votre serveur. C'est le client qui propose la fenêtre de 5840 octets. Le serveur ne peut pas proposer une plus grande taille de fenêtre, seulement une plus petite.

Quelqu'un

Je ne suis pas l'auteur original de cette question. Je l'ai testé (avec des résultats similaires) sur mon propre environnement de test et je ne peux pas non plus le changer. La taille initiale de la fenêtre d'encombrement (initcwnd) n'a rien à voir avec l'autre côté de la connexion.

kupson

Je ne connais pas votre configuration. L'affiche originale a demandé pourquoi, malgré l'augmentation de la taille de la fenêtre initiale sur le serveur, sa connexion de test n'a qu'une taille de fenêtre de 5840 octets. La réponse est: parce que le client avec lequel il a testé ne permet pas une plus grande taille de fenêtre. Je ne peux pas commenter d'autres configurations ou éventuellement d'autres problèmes / bugs avec le concept en général.

Quelqu'un