FreeBSD lentidão transferências - RFC 1323 problema de dimensionamento?

Question

Acho que estou tendo um problema com o dimensionamento de janelas (RFC 1323) e espero que alguém possa me esclarecer sobre o que está acontecendo.

• Servidor: FreeBSD 9, apache22, servindo um arquivo zip estático de 100MB. 192.168.18.30
• Cliente: Mac OS X 10.6, Firefox 192.168.17.47
• Rede: Apenas um switch entre eles - a sub-rede é 192.168.16 / 22 (neste teste, também tenho a filtragem dummynet simulando um tempo de ping de 80ms em todo o tráfego IP. Vi traços quase idênticos com uma configuração "real", com tráfego real de internet / latência também)

Perguntas:

• Isso parece normal?
• O pacote nº 2 está especificando um tamanho de janela de 65535 e uma escala de 512?
• O pacote nº 5 diminui o tamanho da janela para que ele possa usar a escala 512 e ainda manter o tamanho total da janela calculado próximo a 64K?
• Por que a escala da janela é tão alta?

Aqui estão os primeiros 6 pacotes da wireshark. Para os pacotes 5 e 6, incluí os detalhes que mostram o tamanho da janela e o fator de escala usados na transferência de dados.

No. Time Source Destination Protocol Length Info

108 6.699922 192.168.17.47 192.168.18.30 TCP 78 49190 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=945617489 TSecr=0 SACK_PERM=1

115 6.781971 192.168.18.30 192.168.17.47 TCP 74 http > 49190 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=512 SACK_PERM=1 TSval=2617517338 TSecr=945617489

116 6.782218 192.168.17.47 192.168.18.30 TCP 66 49190 > http [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSval=945617490 TSecr=2617517338

117 6.782220 192.168.17.47 192.168.18.30 HTTP 490 GET /utils/speedtest/large.file.zip HTTP/1.1

118 6.867070 192.168.18.30 192.168.17.47 TCP 375 [TCP segment of a reassembled PDU]

Detalhes:

Transmission Control Protocol, Src Port: http (80), Dst Port: 49190 (49190), Seq: 1, Ack: 425, Len: 309
Source port: http (80)
Destination port: 49190 (49190)
[Stream index: 4]
Sequence number: 1 (relative sequence number)
[Next sequence number: 310 (relative sequence number)]
Acknowledgement number: 425 (relative ack number)
Header length: 32 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 130
[Calculated window size: 66560]
[Window size scaling factor: 512]
Checksum: 0xd182 [validation disabled]
Options: (12 bytes)
No-Operation (NOP)
No-Operation (NOP)
Timestamps: TSval 2617517423, TSecr 945617490
[SEQ/ACK analysis]
TCP segment data (309 bytes)

    

Answer 1

Eu recebi a notícia da equipe do administrador de sistema de que esse problema estava sendo causado por algum problema com o driver de rede VMWare, que não respeitava / reproduzia os sintetizadores sysctl. A taxa de transferência com a mesma configuração no hardware físico tem taxa de transferência com uma porcentagem razoável para o tubo, em vez de 1/10 ou menos que vimos com o VMware.

    

Answer 2

1.) 512 não é realmente uma escala de janela alta - é só dizer para mudar o tamanho da janela oferecida para a esquerda por 9 bits. Configurar o tamanho da janela para 130 (caso contrário, um valor muito, muito baixo) e, em seguida, aplicar um fator de escala de 512 leva você a 66560 (130 < < 9).

2.) 100M é provavelmente um arquivo muito pequeno. O fato de a escala ter sido negociada sugere que tudo está funcionando bem. Tente um arquivo maior para observar melhor o comportamento. Se nada mais, você terá uma noção melhor do rendimento real.

3.) Lembre-se também que o comportamento de determinados clientes pode substituir especificamente o comportamento do sistema operacional - o cliente FTP embutido no Solaris, por exemplo, usado para limitar o tamanho da janela a 64K, independentemente de como o sistema operacional era configurado.