Por que o TCP TIME-WAIT State está presente em ambas as extremidades após o término da conexão?

Question

Estou lendo como os estados do TCP funcionam e especialmente a parte de finalização da conexão.

Todos os livros ou material on-line que eu li mostram que, para o procedimento de encerramento, esses estados são seguidos a partir do lado iniciado (ativo) no término da conexão:

ESTABELECIDO, FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT, FECHADO

E estes do lado de recepção (passivo):

ESTABELECIDO, PERTO DE ESPERA, ÚLTIMO ACK, FECHADO

Agora vem a pergunta: Eu modprobed o módulo nf_conntrack_ipv4 para ambos os lados para verificar os estados de conexão em / proc / net / ip_conntrack.

Para minha surpresa, quando a conexão é terminada, tanto o iniciador (ativo) quanto o receptor (passivo) vão para o estado TIME-WAIT.

Eu esperaria apenas que o iniciador passasse por este estado, e o receptor apenas feche a conexão.

Alguém pode explicar por que isso está acontecendo?

UPDATE: Como faço esse teste

Eu tenho uma máquina virtual com IP 10.0.0.1 (Ubuntu 12.04) e inicio duas conexões ssh com 10.0.0.2 (Debian 6) dele (10.0.0.2 também é uma VM). Eu verifico o ip_conntrack de ambas as extremidades e é isso que eu recebo.

root@machine1:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 431997 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 [ASSURED] mark=0 use=2
tcp      6 431944 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 [ASSURED] mark=0 use=2

root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 432000 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 packets=206 bytes=19191 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 packets=130 bytes=18177 [ASSURED] mark=0 secmark=0 use=2
tcp      6 431947 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 packets=16 bytes=4031 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 packets=17 bytes=3741 [ASSURED] mark=0 secmark=0 use=2

Até agora, tudo parece bem. Agora eu desconecto uma das conexões ssh da máquina2 e é isso que eu recebo:

root@machine1:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 431989 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 [ASSURED] mark=0 use=2
tcp      6 117 TIME_WAIT src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 [ASSURED] mark=0 use=2

root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 432000 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 packets=211 bytes=19547 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 packets=133 bytes=18925 [ASSURED] mark=0 secmark=0 use=2
tcp      6 115 TIME_WAIT src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 packets=31 bytes=5147 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 packets=25 bytes=4589 [ASSURED] mark=0 secmark=0 use=2

    

Answer 1

A pilha TCP e o conntrack do Linux têm duas visões diferentes da conexão TCP. O que você está vendo em /proc/net/ip_conntrack é diferente do que o kernel vê. O estado do kernel é armazenado em /proc/net/tcp e /proc/net/tcp6 e pode ser exibido com netstat .

Como pode ser visto aqui: link ambas as contagens são diferentes. Eu presumo que se você olhar para a saída de netstat você verá apenas uma extremidade em TIME-WAIT

    

Answer 2

Isso evita que uma nova conexão faça com que segmentos obsoletos continuem flutuando na rede a partir da conexão antiga, atrapalhando-a.