Quando uma conexão TCP é fechada em uma extremidade da conexão - a outra extremidade recebe um FINe responde com um ACK. Essa extremidade da conexão entra então no CLOSE_WAITestado. Uma vez close()chamado neste final, o TCP envia um FINpacote e entra no LAST_ACKestado. No entanto, nunca entra no TIME_WAITestado.
Agora, vamos supor que o Host A chame close()o soquete e envie um FINpacote para o Host B. O Host A entra no FIN_WAIT_1estado. O host B recebe o FINpacote, envia um ACKe então entra no CLOSE_WAITestado. No entanto, o ACK é descartado em algum lugar de um roteador upstream.
Enquanto isso, o Host B chama close()(lembre-se que o Host B está no CLOSE_WAITestado) e envia um FINpacote para o Host A. O Host B agora entra no LAST_ACKestado. O Host A recebe o FINpacote e responde com um arquivo ACK. Em seguida, entra no CLOSINGestado.
Na outra extremidade, o Host B ainda está no LAST_ACKestado. Em seguida, ele recebe o ACKdo Host A e entra no CLOSEDestado. Lembre-se de que o ACKhost B para o Host A foi descartado e que o Host A não reenviou seu FINpacote. O Host A reenvia seu FINpacote após o tempo limite - no entanto, o Host B fechou a conexão.
O Host A agora está preso no CLOSINGestado? A desmontagem da conexão pode continuar? O que acontece depois?
Responder1
Meu TCP está um pouco enferrujado mas acredito que funcione assim:
Quando o Host B chama close()e envia seu FIN, o número de sequência FINrevelará ao Host A que perdeu um pacote do Host B. Portanto, o Host A não confirmará o Host B FIN, ele continuará confirmando o último segmento TCP que ele recebido com sucesso do Host B. Isso solicitará que o Host B retransmita o arquivo ACK.
Portanto, o Host A não alcançará o CLOSINGestado, pois não considerará o fora de ordem FINcomo verdadeiramente recebido até receber a falta ACKque o precedeu.