Manualmente forçando a conexão TCP a tentar novamente

Question

1. Eu tenho uma conexão TCP (sessão SSH para algum computador, por exemplo)
2. A rede cai repentinamente e descarta todos os pacotes (cabo desconectado, fora do intervalo).
3. O TCP reenvia pacotes repetidamente, tentando novamente com atrasos crescentes.
4. Eu vejo o problema e conecto o cabo de volta (ou restaure a rede de alguma forma).
5. A conexão TCP finalmente reenvia com sucesso algum pacote e continua.

O problema é que eu preciso esperar por um tempo limite no ponto 5. Eu quero usar minha sessão SSH aberta agora e não esperar por 5-10 segundos até descobrir que a conexão está funcionando novamente.

Como forçar todas as conexões TCP a reenviar dados sem atrasos no GNU / Linux?

    

Answer 1

Você sabe que a conexão IP foi estabelecida no momento (4)? Com DHCP / WiFi / WPA / ARP / Zeroconf, há uma renegociação de link de dados que pode levar 5 segundos entre a operadora e a capacidade de passar até mesmo um pacote IP.

Se for assim, a sessão SSH pode não ser a limitação e forçar uma reenvio TCP não ajudará em nada.

Atualização:

Não sei, não consigo reproduzir. Eu tinha uma conexão SSH aberta entre a máquina .2 e .3 com o .3 imprimindo o tempo para stdout a cada segundo. As duas máquinas estão executando o Ubuntu Lucid e conectadas através de um roteador / WAP / Switch. As máquinas são configuradas para DHCP. Puxei o cabo da máquina .3 e esperei um intervalo cientificamente preciso (olhei para o relógio) de 60 segundos. Aqui está o rastreamento de pacotes:

No.  Time        Source                Destination           Protocol Info
  18 8.479990    192.168.2.3           192.168.2.2           SSH      Encrypted response packet len=48
  19 8.480024    192.168.2.2           192.168.2.3           TCP      56670 > ssh [ACK] Seq=1 Ack=433 Win=1002 Len=0 TSV=2804876 TSER=44100246
  20 87.619215   AsustekC_f1:59:70     Broadcast             ARP      Who has 192.168.2.2?  Tell 192.168.2.3
  21 87.619221   AsustekC_24:9c:85     AsustekC_f1:59:70     ARP      192.168.2.2 is at 00:1a:92:24:9c:85
  22 87.619527   192.168.2.3           192.168.2.2           SSH      Encrypted response packet len=48
  23 87.619545   192.168.2.2           192.168.2.3           TCP      56670 > ssh [ACK] Seq=1 Ack=481 Win=1002 Len=0 TSV=2824661 TSER=44120031

Demorou cerca de 200 microssegundos para a sessão ser retomada. Eu usei o padrão Wireshark para o sniffing de pacotes.

    

Answer 2

Veja as seguintes entradas do proc

/ proc / sys / net / ipv4 /

tcp_keepalive

tcp_retries

tcp_keepalive:

O número de segundos que uma conexão precisa ficar inativa antes do TCP começa a enviar sondas keep-alive. Isto pode ser alterado executando o seguinte comando

echo 20 > /proc/sys/net/ipv4/tcp_keepalive_time.

O padrão o valor é 7200 segundos (2 horas).

tcp_retries:

O número de novas tentativas antes de fechar uma conexão TCP

echo 45 > /proc/sys/net/ipv4/tcp_retries2

Não tenho certeza se isso realmente ajudará quando se tratar de uma conexão SSH, pois isso pode realmente depender da velocidade do link e da configuração do tempo limite do SSH.

Felicidades Chris