netstat -oinclui algumas informações do temporizador na saída, mas não encontrei uma explicação da saída na Timercoluna em nenhum lugar.
Alguém pode explicar isso ou apontar para uma explicação?
Esta é a aparência da saída netstat -o (no Ubuntu 8.04).
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State Timer
tcp 0 0 192.168.22.1:443 111.111.11.210:5804 ESTABLISHEDkeepalive (6176.47/0/0)
tcp 0 0 192.168.22.1:443 192.168.22.253:48379 TIME_WAIT timewait (36.57/0/0)
tcp 0 924 192.168.22.1:47763 10.9.169.60:443 ESTABLISHEDon (0.34/0/0)
tcp 0 0 192.168.22.1:443 192.168.111.99:4059 ESTABLISHEDkeepalive (6963.60/0/0)
tcp 0 0 192.168.22.1:443 192.168.111.74:1729 ESTABLISHEDkeepalive (1393.60/0/0)
tcp 0 0 192.168.56.1:42204 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
tcp 0 0 192.168.56.1:42207 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
tcp 0 940 192.168.22.1:42186 10.9.169.60:443 ESTABLISHEDon (0.28/0/0)
tcp 0 0 192.168.22.1:443 192.168.22.253:48367 TIME_WAIT timewait (31.57/0/0)
tcp 0 0 192.168.22.1:42234 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
tcp 0 0 192.168.22.1:42209 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
Responder1
O primeiro número é claramente o cronômetro de contagem regressiva. Dependendo do tipo de status, quando o tempo expirar, ele tentará novamente e enviará outro FIN ou qualquer pacote necessário para tentar novamente. Portanto, o segundo número registra o número de novas tentativas. Observe que o cronômetro aumenta porque o TCP possui cronômetros de espera caso haja uma condição de tráfego. O temporizador de espera evita tentativas excessivamente frequentes. Cada falha resulta em uma espera cada vez maior. A espera pode ser de crescimento exponencial ou linear, dependendo da pilha TCP. Ainda não descobri para que serve o número 3. Sempre zero em meus displays.
Responder2
A coluna do cronômetro possui dois campos (do seu o/p acima):
keepalive (6176.47/0/0)
<1st field> <2nd field>
O 1st fieldpode ter valores:
keepalive- quando o temporizador keepalive está LIGADO para o soquete
on- quando o temporizador de retransmissão está LIGADO para o soquete
off- nenhuma das opções acima está LIGADA
O 2nd fieldtem TRÊS subcampos:
(6176.47/0/0) -> (a/b/c)
a=valor do temporizador (a=temporizador keepalive, quando 1º campo="keepalive"; a=temporizador de retransmissão, quando 1º campo="on")
b=número de retransmissões que ocorreram
c=número de sondagens keepalive que foram enviadas
Por exemplo, eu tinha dois soquetes abertos entre um cliente e um servidor (não loopback). A configuração de manutenção de atividade é:
KEEPALIVE_IDLETIME 30
KEEPALIVE_NUMPROBES 4
KEEPALIVE_INTVL 10
E desliguei a máquina cliente, então no lado do servidor executei um netstat e a saída foi:
Porta1:
netstat -c --timer | grep "192.0.0.1:43245 192.0.68.1:49742"
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.92/0/0)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.71/0/0)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (9.46/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (8.30/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.14/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.98/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.82/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (3.66/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (2.50/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.33/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.17/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (9.01/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.75/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (6.47/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.29/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.08/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (2.89/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.73/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.54/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (9.38/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (8.23/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.08/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.93/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.76/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (3.62/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (2.48/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.32/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.13/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (8.98/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.78/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (6.62/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.45/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.29/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (3.14/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.99/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.85/0/4)
Você pode ver acima que o servidor enviou QUATRO testes de manutenção de atividade, cada um após 10 segundos e, como não está obtendo nenhuma resposta, a contagem do número de testes enviados aumenta e, após 4, ele se desconecta do cliente.
Porta 2:
Para a segunda conexão, o soquete era idêntico, exceto que meu aplicativo no lado do servidor estava tentando enviar alguma mensagem depois que o cliente caiu e antes que o keepalive expirasse:
netstat -c --timer | grep "192.0.0.1:36483 192.0.68.1:43881"
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (8.18/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (7.00/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (5.86/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (4.71/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (3.55/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (2.40/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (1.21/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (0.05/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (8.91/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (7.75/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (6.56/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (5.39/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (4.14/0/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.21/2/2) // <---- retransmission timer kicks in
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.68/3/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.74/4/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.59/4/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.43/4/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.28/5/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.11/5/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.95/6/2)
. . . . .
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.65/249/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.58/250/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.48/250/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.36/250/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.26/251/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.15/251/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (3.01/252/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.92/252/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.84/252/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.72/253/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.64/253/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.55/253/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.47/254/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.39/254/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.31/254/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.19/255/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.12/255/2)
Como você pode ver, neste caso as coisas são um pouco diferentes. Quando o cliente caiu, meu servidor começou a enviar mensagens de keepalive, mas enquanto ainda estava enviando esses keepalives, meu servidor tentou enviar uma mensagem ao cliente. Como o cliente havia caído, o servidor não conseguiu obter nenhum ACK do cliente, então a retransmissão TCP foi iniciada e o servidor tentou enviar os dados novamente, cada vez aumentando a contagem de retransmissão (2º campo) quando o temporizador de retransmissão (1º campo) campo) expirou.
Espero que isso explique netstat --timerbem a opção.
Responder3
Primeiro campo:timewait/keepalive
Tempo em segundos desde o momento em que os últimos dados foram transferidos até o momento em que a próxima sonda de manutenção de atividade TCP será enviada.
Por padrão, isso começa em 7200 e é redefinido novamente sempre que mais dados são enviados. Se o valor for baixo, por exemplo. 4.000 segundos, significa que algumas das conexões keep alive estão suspensas ou não fazem nada por um longo período.
As conexões com o proxy interno ou outros processos internos podem travar por mais tempo, mas isso não deve acontecer com conexões baseadas na Web.