Qual é o objetivo do TIME WAIT na conexão TCP desmontar?


12

Descobri que a razão pela qual o ativo mais próximo entra no TIME WAIT é garantir que o ACK final não seja perdido. Mas como saber se o ACK final está perdido? O passivo mais próximo reenviará o FIN e, em seguida, o ativo mais próximo saberá que o ACK foi perdido? Aqui está uma imagem do TCP FSM.

TCP FSM



1
Esta publicação no blog tem uma ótima resposta: vincent.bernat.im/en/blog/…
Chimpanzee

Respostas:


5

O passivo mais próximo reenviará o FIN e, em seguida, o ativo mais próximo saberá que o ACK foi perdido?

Sim. Citando a partir do volume ilustrado TCP / IP 1 , na seção Gerenciamento de conexão TCP:

  1. Para concluir o fechamento, o segmento final contém um ACK para o último FIN. Observe que, se um FIN for perdido, ele será retransmitido até que um ACK seja recebido.

Há um tempo limite. Quando ativado LAST_ACK, o passivo mais próximo será reenviado FINquando houver um tempo limite, supondo que ele tenha sido perdido. Se foi realmente perdido, o ativo mais próximo acabará recebendo o retransmitido FINe entrando TIME_WAIT. Se o FINnão foi perdido, mas a final ACKfoi perdida, o ativo mais próximo está dentro TIME_WAITe recebe FINnovamente. Quando isso acontece - recebendo um FINin TIME_WAIT- o ACKé retransmitido.

O valor do tempo limite in NÃOTIME_WAIT é usado para fins de retransmissão. Quando há um tempo limite , presume-se que a final tenha sido entregue com êxito porque o passivo mais próximo não retransmitiu pacotes. Portanto, o tempo limite é apenas um período de tempo após o qual podemos assumir com segurança que, se a outra extremidade não enviou nada, é porque ele recebeu a final e fechou a conexão.TIME_WAITACKFINTIME_WAITACK


1

Mas como saber se o ACK final está perdido?

Porque não o recebeu dentro do período de tempo limite. Eu sei que é uma resposta "duh", mas é exatamente por isso que esses estados e tempos limites existem.

O passivo mais próximo reenviará o FIN

Não. A menos que outros pacotes cheguem para esse fluxo, e isso resultaria no envio de "RST" (redefinição).

Todo o processo é uma máquina de estado complicada para executar um desligamento ordenado, apesar da possibilidade de falhas na rede. As redes quebram, os links experimentam erros, os links ficam saturados e precisam eliminar pacotes, os dispositivos falham, etc. Como exercício, execute a árvore de estados para uma conexão ativa quando um dos pontos de extremidade simplesmente desaparecer (por exemplo, falha de energia).

TL; DR Essa árvore de estado foi projetada para lidar com todos os modos de falha possíveis.


Obrigado, mas ainda estou confuso sobre a primeira parte. Eu quis dizer como o ativo mais próximo sabe que o ACK não foi recebido pelo passivo mais próximo? Quando o passivo mais próximo recebe o ACK, ele apenas rasga o lado da conexão e, se não recebe o ACK, permanece no ÚLTIMO ACK, então como o ativo mais próximo sabe se o ACK foi recebido?
Czhao 01/07/2015

porque existem temporizadores anexados a todos os estados.
Ricky Beam

Desculpe, eu não estou entendendo. Como esses cronômetros informam ao ativo mais próximo que o passivo mais próximo não recebeu o ACK final? ou seja, como o ativo mais próximo sabe se precisa reenviar o ACK final?
Czhao 01/07/2015

0

O objetivo de TIME_WAIT é permitir que a rede diferencie os pacotes que chegam como pertencentes à conexão 'antiga e existente' de uma nova. A recomendação é definir o timer TIME_WAIT para o dobro da Vida útil máxima do segmento (MSL), no meu sistema a MSL é de 1 minuto, para que as conexões permaneçam no estado TIME_WAIT por 2 minutos.

Após esse período, os pacotes que chegam não são mais associados à conexão antiga.

TIME_WAIT não é esperado diretamente para enviar pacotes ACK; conduzido pelos estados CLOSE_WAIT e FIN_WAIT. Quando você chega ao estado TIME_WAIT, o soquete já está fechado.

Referências: http://www.tcpipguide.com/free/t_TCPConnectionTermination-3.htm https://en.wikipedia.org/wiki/Maximum_segment_lifetime http://www.lognormal.com/blog/2012/09/27/ sintonia-linux-tcpip /

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.