Come termina la connessione TCP se una delle macchine muore?

Question

Se viene stabilita una connessione TCP tra due host (A & B), e consente di dire che l'host A ha inviato 5 ottetti all'host B, e quindi l'host B si arresta in modo anomalo (a causa di motivi sconosciuti). L'host A attenderà i riconoscimenti, ma non riuscendo a riceverli, invierà nuovamente gli ottetti e ridurrà anche la dimensione della finestra del mittente. Questo si ripeterà un paio di volte finché la dimensione della finestra si riduce a zero a causa della perdita di pacchetti. La mia domanda è, cosa succederà dopo?

Answer 1

In questo caso, il protocollo TCP si interrompe inaspettatamente in attesa dell'ack e restituisce un errore all'applicazione. L'applicazione deve leggere/recv dal socket TCP per conoscere l'errore, anche una successiva chiamata di scrittura/invio fallirà. Fino al punto in cui TCP ha stabilito che la connessione è andata, le chiamate di scrittura/invio non avranno esito negativo, avranno successo come visto dall'applicazione o dal blocco se il buffer del socket è pieno.

Nel caso in cui l'host B scompaia dopo che ha inviato i suoi ACK, l'host A non verrà a conoscenza di ciò fino a quando non invia qualcosa a B, che alla fine si interrompe anche o genera un errore ICMP. (In genere, la prima chiamata di scrittura/invio non fallirà poiché TCP non fallirà immediatamente la connessione e si tenga presente che le chiamate di scrittura/invio non attendono gli ACK finché non vengono completati).

Si noti inoltre che la ritrasmissione non riduce le dimensioni della finestra.

Answer 2

Si prega di seguire questa link

ora una risposta molto semplice alla tua domanda a mio avviso è, La connessione sarà scaduta e verrà chiuso. un'altra possibilità che esiste è che alcuni errori ICMP potrebbero essere generati a causa di una macchina priva di risposta.

Inoltre, se la macchina arrestata è di nuovo online, verrà osservata la procedura descritta nel collegamento appena incollato sopra.

Answer 3

Dipende dall'implementazione del sistema operativo. In breve attenderà ACK e rispedirà i pacchetti fino a quando scade. Quindi la tua connessione verrà abbattuta. Per vedere esattamente cosa succede in Linux, guardiamo allo here altri algoritmi simili.

Answer 4

nel tuo caso, verrà generato un FIN (dal nodo superstite) e la connessione alla fine passerà allo stato CHIUSO. Se si mantiene grep-in per l'output netstat sull'indirizzo ip di destinazione, si guarderà la migrazione dallo stato ESTABLISHED a TIMED_WAIT e infine scomparirà.

Nel tuo caso, questo accadrà poiché TCP mantiene un timer per ottenere l'ACK per il pacchetto che ha inviato. Questo timer non è abbastanza lungo quindi il rilevamento avverrà abbastanza rapidamente.

Tuttavia, se la macchina B muore dopo che A ottiene ACK e dopo che A non invia nulla, allora il timer di cui sopra non può rilevare lo stesso evento, tuttavia un altro timer (chiamate in pausa) rileverà quella condizione e la connessione si chiuderà allora. Questo periodo di timeout è alto per impostazione predefinita. Ma normalmente questo non è il caso, la macchina A proverà a inviare cose nel mezzo e rileverà la condizione di errore nel percorso di invio.

In breve, TCP è abbastanza intelligente da chiudere la connessione da solo (e lasciare che l'applicazione lo sappia) tranne per un caso (Timeout di inattività: che per impostazione predefinita è molto alto).

cforfun

Answer 5

In casi normali, ogni lato terminando la sua fine della connettività con l'invio di un messaggio speciale con un FIN (finitura) bit impostato. Il dispositivo che riceve questo FIN risponde con un riconoscimento alla FIN per indicare che è stato ricevuto. La connessione nel suo complesso non viene considerata terminata finché entrambi i dispositivi non completano la procedura di spegnimento inviando un FIN e ricevendo un riconoscimento.