Inicio lento de Linux: cambiar la ruta de IP no tiene ningún efecto en la ventana inicial

Cambié la ventana inicial de tcp en mi máquina a 10 como se muestra a continuación

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

Y cambiado tcp_slow_start_after_idlecomo se muestra a continuación

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

a continuación se muestra una confirmación de la ruta ip

[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

Ahora, cuando hago un tcpdump en el sitio web, parece que no veo un cambio en la ventana inicial con el WIN / MSS restante 4 por defecto. 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

El golpe de rizo que hice a la página web solicitó alrededor de 30 KB de datos.

[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

¿Qué podría estar mal en mi enfoque?

Núcleo

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

Como actualización, aquí están los resultados cuando pruebo 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

Como puede ver, WIN / MSS es 14600/1460 = 10 en este caso

Intenté acceder a mi sitio desde la máquina del servidor a través de curl y aquí está el resultado:

[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 es 32792/16396 = 2 en este caso

Creo que no entiendes cómo funciona TCP.

Cada paquete enviado siempre anunciará una ventana del receptor (también conocido como RWIN) y un factor de escala opcional, consulte RFC 1323

El remitente no puede enviar más de la cantidad de datos especificada en el RWIN sin que se reconozca. Dependiendo de la ventana de congestión, el remitente puede decidir llenar el RWIN o no.

Por lo tanto, hay dos bits de información que son públicos en los paquetes TCP. El RWIN en el servidor y el RWIN en el cliente. Ambas figuras dictan cuál puede ser el tamaño máximo de la ventana de congestión en ambos extremos.

El RWIN en el servidor es interesante cuando estamos tratando de optimizar el rendimiento de dichas cargas de archivos.

El RWIN en el cliente es interesante cuando intentamos determinar la velocidad de descarga.

Ninguno de estos números hace pública la ventana de congestión en el otro extremo .

Entonces, si tengo un RWIN de 64k, la ventana de congestión en el servidor puede ser CUALQUIER número inferior a 64k.

La única forma de determinar cuál es la ventana de congestión real es contar los paquetes.

Si supiera:

1. Mi tiempo de ida y vuelta (RTT) es de ~ 200 ms.
2. Acabo de solicitar un recurso que es 100k.
3. Tengo un RWIN de 64k.

Si recibo 2 paquetes del servidor que tienen una longitud de 1452 bytes dentro de ~ 200 ms, es probable que la ventana de congestión en el servidor sea menor que 4356, porque si fuera más grande, se enviarían 3 paquetes. Si IW se estableció en 10, vería una explosión de 10 paquetes alrededor de la marca de 200 ms.

Si cambia su IW y desea confirmar que el cambio funcionó, debe contar los paquetes para obtener una estimación del tamaño de la ventana de congestión en el servidor.

Tenga en cuenta que probablemente desee ver la conversación directamente después de SYN, SYN-ACK, ACK para asegurarse de que no está mirando a la mitad de una conversación (donde la ventana de congestión ya podría haber crecido).

El tamaño de la ventana será el menor: tamaño de la ventana de inicio del servidor o RWIN del cliente. Dado que 5840 es el RWIN predeterminado para Linux 2.6, parece que su cliente es el factor limitante aquí.

Probar desde una caja de ventanas. Windows XP tiene un RWIN de 64k, versión más nueva 8k.

Fuente: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (La parte interesante está debajo del video)

Editar: Expandir la respuesta para que quede más clara:

• En el protocolo de enlace TCP, el cliente envía un paquete SYN al servidor enviando su tamaño máximo de ventana permitido. (Como muestra la salida de tcpdump, estos son 5840 bytes)
• El servidor ahora responde con SYN ACK y el tamaño de la ventana que le gustaría acordar. Este tamaño de ventana solo puede ser más pequeño que el propuesto por el cliente, no más grande. No importa cómo esté configurado el servidor, nunca puede tener tamaños de ventana más grandes que 5840 bytes con ese cliente.
• El cliente devuelve ACK y felizmente intercambian datos para siempre.

Edit2: Los tcpdumps agregados a la pregunta muestran que el servidor abre conexiones a google y que ACTÚA COMO EL CLIENTE.