Nós também estamos experimentando o mesmo problema. Qualquer coisa maior do que o que pode ser transferido no estouro do download inicial (~ 3.7mb para nós), diminui para ~ 1-4kb por segundo, independentemente da largura de banda disponível.
Parece ser um problema específico e comum com o Firewall SonicWall PRO 2040 - link
A raiz do problema é o firewall e a melhor correção a longo prazo é encontrar uma configuração no firewall para permitir que a opção TCP Window Scaling seja ativada e também usar o fator de escala TCP Window da máquina iniciadora corretamente inicialização da conexão.
Embora este artigo se refira aos roteadores, a mesma lógica se aplica ao que está acontecendo com o SonicWall Pro 2040 Firewall, link :
The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.
Semelhante ao que foi mencionado acima, existem soluções alternativas para máquinas individuais - link , desativando o rfc1323 Extensão TCP, o firewall nunca tem a oportunidade de passar um Fator de Escala de Janela TCP de 0 e passa adiante que a extensão rfc1323 não está habilitada, presumivelmente usando o tamanho máximo permitido da janela por TCP sem a extensão rfc1323, que é 64kb.
Comandos que usamos em nossas várias máquinas como solução temporária:
Ubuntu 10.10:
A alteração entra em vigor imediatamente:
sudo sysctl -w net.ipv4.tcp_window_scaling=0
Mudança permanente após a próxima reinicialização:
sudo sh -c 'echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf'
Mac OSx:
A alteração entra em vigor imediatamente:
sudo sysctl -w net.inet.tcp.rfc1323=0
Mudança permanente após a próxima reinicialização:
sudo sh -c 'echo "net.inet.tcp.rfc1323=0" >> /etc/sysctl.conf'
Win7:
Veja as opções disponíveis:
netsh interface tcp show global
Desativar comando (persistente):
netsh interface tcp set global autotuning=disabled
Em resposta ao motivo pelo qual o Windows Server não estava tendo problemas, encontrei este artigo - link
TCP window scaling is negotiated on demand in Windows Server 2003, based on the value set for the SO_RCVBUF Windows Sockets option when a connection is initiated. Additionally, the Window Scale option is used by default on a connection if the received SYN segment for that connection as initiated by a TCP peer contains the Window Scale option. Windows Server 2003 TCP does not initiate connections with window scaling by default. To instruct the Windows Server 2003 TCP stack to attempt to negotiate a larger receive window size by making use of the Window Scale option, set the Tcp1323Opts registry value to 1.