È possibile che una connessione TCP rimanga aperta quando il client si è disconnesso?

Abbiamo un'applicazione server che sta affrontando problemi di esaurimento TCP a circa 4000 connessioni. Ciò si verificherà ogni 3 o 4 settimane (circa). Il venditore, che ha creato questa applicazione server, ci dice dopo aver esaminato l'output di netstat -b che alcune connessioni rimangono aperte anche se i client sono caduti.

Mi è stato assegnato il compito di indagare sul motivo per cui una particolare applicazione client non sta chiudendo correttamente la connessione TCP. Sono convinto che se un computer client viene spento, non può POSSIBILMENTE segnalare dal server che una connessione TCP è ancora stabilita con quel client. Purtroppo, non riesco a trovare alcuna informazione per convalidare la mia vista. Non voglio perdere altro tempo a indagare su un potenziale problema che non credo possa essere nemmeno un problema.

TLDR;

Un server può segnalare una connessione stabilita a un computer spento?

windows-server-2008 tcp

— Josh Smeaton
fonte

Risposte:

TCP non si impegna a rilevare una connessione non funzionante se non su un lato che sta trasmettendo dati. È responsabilità del codice dell'applicazione richiamare nello stack TCP per fare ciò. Quale protocollo è coinvolto qui? (Quello in cima a TCP.)

È una "soluzione" orribilmente brutta, ma puoi abilitare i keepalive TCP . C'è di più in questo articolo .

— David Schwartz
fonte

Probabilmente intendevi layer ed è il livello di sessione sopra il livello di trasporto, che è dove risiede TCP.

— Rilindo,

@Rilindo: in pratica, e in questo caso particolare, hai un'applicazione che effettua chiamate allo stack TCP. Il protocollo in cima a TCP (HTTP, POP o altro) in genere specifica come farlo, perché i progettisti di quei protocolli sapevano che TCP non poteva farlo da solo.

— David Schwartz,

Spiacenti, errore mio. Il suo strato 7, quindi.

— Rilindo,

A questo punto non abiliterò keepalive, ma è utile sapere che esiste l'opzione. L'articolo sembra suggerire che esiste già un timeout di 2 ore. AFAIK, le connessioni vengono mantenute aperte per giorni / settimane.

— Josh Smeaton,

Molto probabilmente, keepalive non sono abilitati. Alcuni frammenti di codice devono abilitarli. Sembra che l'applicazione sia semplicemente rotta se non abilita nemmeno keepalive e non ha alcun meccanismo di timeout / reap. Di quale protocollo stiamo parlando? (HTTP? SMTP? FTP?)

— David Schwartz

Sì, è possibile. Come hanno affermato David e Paul nelle loro risposte, non esiste alcun meccanismo in TCP (tranne i keep-alive TCP, che sono opzionali) per rilevare una connessione semi-aperta. Spetta al fornitore dell'applicazione determinare lo stato della connessione e intraprendere le azioni appropriate di conseguenza.

Per quanto riguarda TCP, non è possibile rilevare o distinguere tra una connessione semiaperta e una connessione inattiva lunga.

Dovrai iniziare a risolvere questo problema dal livello 1 (fisico) del modello OSI fino al livello 7 (applicazione) per capire dove si sta verificando il problema. Il mio consiglio sarebbe di installare ed eseguire un programma di acquisizione di pacchetti su uno dei client interessati fino a quando non si verifica il problema, quindi analizzare l'acquisizione per provare a determinare cosa sta causando la chiusura della connessione da parte del client.

— joeqwerty
fonte

Oppure fai in modo che il fornitore attui un timeout ragionevole :)

— Shane Madden

Quando una workstation vuole chiudere una connessione con un server, invia un TCP FIN. Se il client non si sta comportando correttamente e non sta chiudendo le sue connessioni, potrebbe in effetti rimanere stabilito sul server. È possibile impostare i timeout per le connessioni aperte sul server per ripulirle, anche se sarebbe meglio trovarne la causa. In quale porta entrano le connessioni aperte? Una volta che sai a quale servizio si accede potresti essere in grado di identificare l'app client che sta colpendo il server.

— Paul Ackerman
fonte

Conosciamo il cliente che è il problema apparente. È un'app desktop che centinaia di utenti usano quotidianamente. Suppongo che il problema sia l'arresto anomalo dell'applicazione, un hard reset o un end-task. Ho pensato in tutte quelle situazioni che il server sarebbe stato consapevole della connessione interrotta.

— Josh Smeaton,

Per quanto riguarda il server, la connessione è aperta a meno che non riceva un FIN o un RST dal client. Senza questo, il server presuppone che la connessione sia ancora stabilita ma che il client non ha dati da inviare. Non c'è differenza tra una connessione semi-aperta e una connessione inattiva per quanto riguarda il server.

— joeqwerty,

@joeqwerty: vero, tuttavia il server potrebbe decidere di non voler mantenere una connessione indefinitamente aperta e potrebbe implementare un meccanismo di timeout / chiusura. Questo è ciò che David Schwartz intendeva nella sua risposta "è la responsabilità del codice dell'applicazione". Quindi il server può fare la differenza tra una connessione semiaperta e una connessione inattiva, se lo desidera. Tuttavia, per TCP non esiste alcuna differenza tra una connessione semiaperta e una connessione inattiva.

— sleske il

@sleske: ha convenuto che il codice dell'applicazione potrebbe farlo, ma TCP non può farlo a meno che non siano abilitati gli keep-alive.

— joeqwerty,