Linux Slow Start: A alteração da rota ip não tem nenhum efeito na janela inicial

Question

Alterei a janela inicial do tcp na minha máquina para 10, conforme mostrado abaixo

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

Alterou tcp_slow_start_after_idle conforme mostrado abaixo

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

uma confirmação de show ip route é dada abaixo

[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

Agora, quando faço um tcpdump no site, não vejo uma alteração na janela inicial com o WIN / MSS restante 4 como padrão. 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

O hit do curl que fiz na página da web solicitada em torno de 30 KB de dados.

[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

O que poderia estar errado na minha abordagem?

Kernel

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

Como atualização, aqui estão os resultados quando tento 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 você pode ver, o WIN / MSS é 14600/1460 = 10 neste caso

Eu tentei acessar meu site da própria máquina do servidor por meio de curl e aqui está o 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 é 32792/16396 = 2 neste caso

    

Answer 1

Acho que você está entendendo mal o funcionamento do TCP.

Cada pacote enviado sempre anunciará uma janela do receptor (aka. RWIN) e um fator de escala opcional, veja RFC 1323

O remetente não tem permissão para enviar mais que a quantidade de dados especificada no RWIN sem que ele seja reconhecido. Dependendo da janela de congestionamento, o remetente pode decidir encher o RWIN ou não.

Portanto, existem dois bits de informação que são públicos nos pacotes TCP. O RWIN no servidor e o RWIN no cliente. Ambas as figuras ditam que o tamanho máximo da janela de congestionamento pode estar em ambas as extremidades.

O RWIN no servidor é interessante quando estamos tentando otimizar o desempenho para os uploads de arquivos.

O RWIN no cliente é interessante quando estamos tentando determinar a velocidade de download.

Nenhum desses números torna a janela de congestionamento na outra extremidade pública .

SO se eu tiver um RWIN de 64k, a janela de congestionamento no servidor pode ser QUALQUER número menor que 64k.

A única maneira de determinar qual é a janela de congestionamento real é contar os pacotes.

Se eu souber:

1. Meu tempo de ida e volta (RTT) é de ~ 200 ms.
2. Acabei de solicitar um recurso de 100k.
3. Eu tenho um RWIN de 64k.

Se eu obtiver 2 pacotes de volta do servidor que tem 1452 bytes em ~ 200ms, é provável que a janela de congestionamento no servidor seja menor que 4356, porque se fossem 3 pacotes maiores seriam enviados. Se o IW fosse definido como 10, eu veria uma sequência de 10 pacotes em torno da marca de 200 ms.

Se você alterar seu IW e quiser confirmar a alteração, será necessário contar os pacotes para obter uma estimativa do tamanho da janela de congestionamento no servidor.

Lembre-se, você provavelmente vai querer olhar para a conversa diretamente após o SYN, SYN-ACK, ACK para garantir que você não esteja olhando para o meio de uma conversa (onde a janela de congestionamento já poderia ter crescido).

    

Answer 2

O tamanho da janela será o menor, o tamanho da janela do init do servidor ou o RWIN do cliente. Como 5840 é o padrão RWIN para Linux 2.6, parece que seu cliente é o fator limitante aqui.

Tente em uma caixa do Windows. O Windows XP tem um RWIN de 64k, versão mais recente 8k.

Fonte: link (A parte interessante está abaixo do vídeo)

Editar: expandindo a resposta para torná-la mais clara:

• No handshake TCP, o cliente envia um pacote SYN para o servidor enviando seu tamanho máximo de janela permitido. (Como mostra a saída do seu tcpdump, estes são 5840 bytes)
• O servidor agora responde com SYN ACK e o tamanho da janela com o qual gostaria de concordar. Esse tamanho de janela só pode ser menor do que o proposto pelo cliente, não maior. Não importa como o servidor esteja configurado, ele nunca poderá ter tamanhos de janela maiores que 5840 bytes com esse cliente.
• O cliente retorna ACK e eles trocam dados com satisfação.

Edit2: Os tcpdumps adicionados à pergunta mostram o servidor abrindo as conexões para o Google e para si próprio ACTING AS THE CLIENT.