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

— Quintin Par
fuente

tenga en cuenta que si está accediendo a esto desde una máquina Linux, también necesitará estar en 3.0, buscará en la fuente / etiquetas para confirmar la versión exacta 3 que instaló el cambio

— Sam Saffron

@QuintinPar ¿Podría agregar salida tcpdump con conexión saliente desde su máquina de prueba?

— Kupson

@kupson He actualizado la pregunta

— Quintin Par

Que yo sepa, no puede influir en la ventana inicial en las conexiones entrantes. Su conexión a Google muestra que tiene IW configurado en 10. El inferface de bucle invertido es bastante especial con esa gran MTU, tal vez haya algún límite en la ventana inicial en la fuente del núcleo.

— Kupson

tenga en cuenta que 2 cosas determinarán el IW. Ventana de congestión inicial máxima de los clientes y Servidores IW. El más pequeño gana. Ejecute la prueba desde 2 máquinas, el servidor debe tener el IW configurado de forma predeterminada en 3.0 ... y los clientes XP / Vista / Win7 no restringen el IW, por lo tanto, sean buenos clientes para la prueba. Los clientes de Linux 3.0 también funcionan, pero deben ser una máquina separada.

— Sam Saffron

Respuestas:

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:

Mi tiempo de ida y vuelta (RTT) es de ~ 200 ms.
Acabo de solicitar un recurso que es 100k.
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).

— Sam Azafrán
fuente

La diferencia entre la ventana de congestión y la ventana de TCP se establece en 20.6 (inicio lento) de TCP / IP ilustrado: "Inicio lento agrega otra ventana al TCP del remitente: la ventana de congestión, llamada cwnd" (negrita es mía). Hay un diagrama de secuencia en 20.7 que muestra esto en juego durante la transferencia masiva.

— Kyle Brandt el

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.

— Alguien
fuente

La ventana inicial (propuesta en el paquete SYN) es 5840. Es un primer paquete y la máquina de envío no sabe nada sobre el receptor en este momento (lo probé con "ip route flush cache").

— Kupson

Uh, 17.255.209.0 es la subred de tu servidor, ¿verdad? El paquete que está viendo es DE 21.101.151.198.45873 A 17.255.209.19.http. No soy un experto en la salida de tcpdump, pero para mí esto dice: Hola servidor, soy su cliente, me gustan las ventanas de 5840 bytes. :) El siguiente paquete sería el servidor que responde con ACK, 5840 es genial, saludos. :)

— Alguien

Solo para enfatizar, creo que entendiste esto al revés: la primera máquina de envío es el cliente, ya que abre la conexión, no tu servidor. Es el cliente que ofrece la ventana de 5840 bytes. El servidor no puede proponer un tamaño de ventana más grande, solo uno más pequeño.

— Alguien

No soy el autor original de esta pregunta. Lo probé (con resultados similares) en mi propio entorno de prueba y tampoco puedo cambiarlo. El tamaño inicial de la ventana de congestión (initcwnd) no tiene nada que ver con el otro lado de la conexión.

— Kupson

No conozco tu configuración. El póster original preguntaba por qué a pesar de aumentar el tamaño inicial de la ventana en el servidor, su conexión de prueba solo tiene un tamaño de ventana de 5840 bytes. La respuesta es: porque el cliente con el que probó no permite un tamaño de ventana más grande. No puedo comentar sobre otras configuraciones o posiblemente otros problemas / errores con el concepto en general.

— Alguien