Eu uso um laptop Mac OS em uma rede doméstica sem fio típica (ou seja, de baixa qualidade) e me conecto para trabalhar por meio de uma VPN. Eu ssh no desktop Linux (ubuntu) que tenho no meu escritório no trabalho. (Quando digo "Eu ssh": clico em um botão que informa que usará 'ssh' e uma janela "Terminal" é aberta e faz login na minha área de trabalho.)
Frequentemente (até algumas vezes por dia) quando estou usando o 'vim', o 'vim' para de responder e, um ou dois minutos depois, a conexão com a minha área de trabalho será interrompida e o Terminal me informará que a conexão foi interrompida . Freqüentemente, tenho várias janelas do Terminal abertas na minha área de trabalho ao mesmo tempo, e apenas a janela do Terminal onde estou usando o 'vim' será quebrada. As outras janelas permanecem conectadas e utilizáveis.
Recentemente, eu estava usando o tcpdump para rastrear os pacotes indo e voltando e capturei um rastreamento onde minha sessão do vim foi interrompida e encerrada. Alguns minutos antes da interrupção, os pacotes da minha área de trabalho chegaram com tamanhos de janela cada vez menores até chegarmos a zero e a conexão foi interrompida um pouco mais tarde.
Eu quase pude entender que, digamos, entrei no modo de inserção e comecei a digitar caracteres enquanto a área de trabalho estava travada e preenchi a janela digitando enquanto minha área de trabalho estava bagunçada. O tamanho inicial da janela era de cerca de 12.500 e cada caractere digitado parece gerar um pacote de 48 bytes, portanto, algo em torno de 250 caracteres pode preencher um buffer tcp.
No entanto, quando o vim trava, é mais como se eu fizesse uma página para baixo (control-f), entrasse no modo de inserção e começasse a digitar alguns caracteres. Meus comandos e caracteres são repetidos indicando que o vim está recebendo e processando os caracteres.
Não estou claro onde o buffer tpc fica entre o soquete e o 'vim'. Presumivelmente, um driver tty está na verdade pegando caracteres do buffer tcp, ecoando-os de volta para mim e entregando-os ao vim, e entregando a saída do vim de volta para mim. Mas todas essas ações retirariam bytes do buffer tcp e o tamanho da janela não chegaria a zero.
O que não estou entendendo sobre como funciona a pilha de software e por que o tamanho da minha janela chegaria a zero e como posso contornar ou corrigir o problema?
Perguntas bônus:
1) Por que minha área de trabalho define o tamanho da janela para cerca de 12.500 em vez de 64K?
2) Ao usar o tcpdump no Mac, não obtenho saída se usar as expressões "host hostname", "host ipaddress" ou "port 22" (onde 'hostname' e 'ipaddress' são substituídos pelo nome ou endereço IP da minha área de trabalho). Se eu não especificar uma dessas expressões, recebo muitos resultados, e a saída contém claramente o nome do host, o endereço IP ou a porta que especifiquei na linha de comando. Existe algo especial no Mac onde o tcpdump não funciona? Existe uma maneira padrão de bagunçar a linha de comando e estou confuso sobre o que estou pedindo para o tcpdump fazer?
obrigado, Cs
Responder1
Em primeiro lugar, o tamanho da janela TCP não é um buffer, é um limite de confirmação. O nó que recebe tráfego enviará apenas um pacote ACK a cada x pacotes. Em uma rede confiável, esse número deve ser o maior possível para a taxa de transferência - a desvantagem é que, se alguns dados forem perdidos, a janela inteira deverá ser retransmitida... Isso geralmente faz com que a pilha TCP reduza o tamanho da janela gradativamente para evitar ter retransmitir tantos dados no caso de uma perda futura de pacotes. Existe um componente relacionado à memória disponível (buffers de recepção), mas em sistemas modernos isso é irrelevante.Wikipédia
A causa subjacente desse problema é provavelmente uma conexão de rede ruim. As VPNs podem frequentemente ter alta latência e/ou perda de pacotes, assim como as redes sem fio. Como experiência, o problema melhora/resolve se você se conectar via linha dura em vez de sem fio?