Eseguo un programma particolare su Linux che a volte si blocca. Se lo apri rapidamente dopo, è in ascolto sul socket 49201 anziché 49200 come ha fatto per la prima volta. netstat rivela che 49200 è nello stato TIME_WAIT.
Esiste un programma che puoi eseguire per forzare immediatamente lo spostamento del socket dallo stato TIME_WAIT?
Risposte:
/etc/init.d/networking restart
Lasciami elaborare. Il protocollo TCP (Transmission Control Protocol) è progettato per essere un protocollo di trasmissione dati bidirezionale, ordinato e affidabile tra due punti finali (programmi). In questo contesto, il termine affidabile significa che ritrasmetterà i pacchetti se si perde nel mezzo. TCP garantisce l'affidabilità inviando indietro i pacchetti di riconoscimento (ACK) per un singolo o un intervallo di pacchetti ricevuti dal peer.
Lo stesso vale per i segnali di controllo come richiesta / risposta di terminazione. RFC 793 definisce lo stato TIME-WAIT come segue:
TIME-WAIT: rappresenta l'attesa del tempo sufficiente per assicurarsi che il TCP remoto abbia ricevuto il riconoscimento della sua richiesta di terminazione della connessione.
Vedi il seguente diagramma di stato TCP:
TCP è un protocollo di comunicazione bidirezionale, quindi quando viene stabilita la connessione, non c'è differenza tra client e server. Inoltre, uno può chiamare quits ed entrambi i peer devono concordare la chiusura per chiudere completamente una connessione TCP stabilita.
Chiamiamo il primo a chiamare le uscite come il più vicino attivo, e l'altro scruta il più vicino passivo. Quando il vicino attivo invia FIN, lo stato passa a FIN-WAIT-1. Quindi riceve un ACK per il FIN inviato e lo stato passa a FIN-WAIT-2. Una volta che riceve FIN anche dal più vicino passivo, il più vicino attivo invia l'ACK al FIN e lo stato passa a TIME-WAIT. Nel caso in cui il vicino passivo non abbia ricevuto l'ACK al secondo FIN, ritrasmetterà il pacchetto FIN.
RFC 793 imposta il TIME-OUT su due volte la durata massima del segmento o 2MSL. Poiché MSL, il tempo massimo che un pacchetto può spostarsi su Internet, è impostato su 2 minuti, 2MSL è 4 minuti. Poiché non esiste alcun ACK per un ACK, il dispositivo di chiusura attivo non può fare altro che attendere 4 minuti se aderisce correttamente al protocollo TCP / IP, nel caso in cui il mittente passivo non abbia ricevuto l'ACK nel proprio FIN (teoricamente) .
In realtà, i pacchetti mancanti sono probabilmente rari e molto rari se tutto accade all'interno della LAN o all'interno di una singola macchina.
Per rispondere alla domanda alla lettera, Come chiudere forzatamente un socket in TIME_WAIT ?, mi atterrò comunque alla mia risposta originale:
/etc/init.d/networking restart
In pratica, lo programmerei in modo che ignori lo stato TIME-WAIT usando l'opzione SO_REUSEADDR come menzionato WMR. Cosa fa esattamente SO_REUSEADDR?
Questa opzione socket dice al kernel che anche se questa porta è occupata (nello
stato TIME_WAIT), andare avanti e riutilizzarla comunque. Se è occupato, ma con un altro stato, otterrai comunque un indirizzo già in uso. È utile se il server è stato spento e quindi riavviato immediatamente mentre i socket sono ancora attivi sulla sua porta. Dovresti essere consapevole che se arrivano dati imprevisti, potrebbero confondere il tuo server, ma mentre ciò è possibile, è improbabile.
/etc/init.d/networkingè specifica della piattaforma (Debian?), Quindi la precisa riga di comando sarà diversa (a volte piuttosto radicalmente) per altri sistemi. Concordo con altri commentatori sul fatto che questo sembra un grave eccessivo e ovviamente distruttivo per qualsiasi servizio di rete non correlato.
Non so se hai il codice sorgente di quel particolare programma che stai eseguendo, ma in tal caso potresti semplicemente impostare SO_REUSEADDR tramite il setsockopt(2)quale ti consente di associare lo stesso indirizzo locale anche se il socket è nello stato TIME_WAIT (a meno che socket sta ascoltando attivamente, vedi socket(7)).
Per ulteriori informazioni sullo stato TIME_WAIT, consultare le Domande frequenti sul socket Unix .
SO_REUSEADDRnon "chiude" un socket. Ti consente semplicemente di riutilizzare quelli che sono già aperti. Quindi la domanda è ancora "Come chiudere forzatamente un socket TIME_WAIT?"
SO_REUSEADDRlasceremo bind()procedere; ma se poi vuoi ascoltare quel socket, listen()tornerà EADDRINUSElo stesso. In altre parole, questa risposta può aiutare il software client che utilizza porte effimere, ma non risolve il problema relativo al software server.
Per quanto ne so non c'è modo di chiudere forzatamente il socket al di fuori della scrittura di un gestore di segnale migliore nel programma, ma esiste un file / proc che controlla quanto tempo impiega il timeout. Il file è
/proc/sys/net/ipv4/tcp_tw_recycle
e puoi impostare il timeout su 1 secondo in questo modo:
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
Tuttavia, questa pagina contiene un avviso sui possibili problemi di affidabilità durante l'impostazione di questa variabile.
C'è anche un file correlato
/proc/sys/net/ipv4/tcp_tw_reuse
che controlla se i socket TIME_WAIT possono essere riutilizzati (presumibilmente senza alcun timeout).
Per inciso, la documentazione del kernel ti avverte di non modificare nessuno di questi valori senza "consigli / richieste di esperti tecnici". Non lo sono.
Il programma deve essere stato scritto per tentare un'associazione alla porta 49200 e quindi incrementare di 1 se la porta è già in uso. Pertanto, se si ha il controllo del codice sorgente, è possibile modificare questo comportamento in modo da attendere alcuni secondi e riprovare sulla stessa porta, invece di incrementare.
1funziona per connessioni future, ma per quanto riguarda quelle attuali che sono già aperte?
In realtà c'è un modo per uccidere una connessione: killcx . Sostengono che funziona in qualsiasi stato della connessione (che non ho verificato). È necessario conoscere l'interfaccia in cui avviene la comunicazione, tuttavia sembra presupporre eth0 per impostazione predefinita.
AGGIORNAMENTO: un'altra soluzione è il cutter che arriva nei repository di alcune distribuzioni di Linux.
Un'altra opzione è quella di utilizzare l'opzione SO_LINGER con un timeout di 0. In questo modo, quando si chiude il socket viene forzatamente chiuso, inviando un RST invece di entrare nel comportamento di chiusura FIN / ACK. Ciò eviterà lo stato TIME_WAIT e potrebbe essere più appropriato per alcuni usi.
Una soluzione alternativa sarebbe quella di avere un proxy affidabile o un software di port forwarding in ascolto sulla porta 49200, quindi inoltrare la connessione a una delle diverse istanze del programma meno affidabile usando porte diverse ... HAPROXY mi viene in mente.
Per inciso, la porta su cui ti connetti è piuttosto alta. Potresti provare a usarne uno inutilizzato appena sopra l'intervallo 0-1024. È meno probabile che il sistema utilizzi un numero di porta inferiore come porta effimera.
TIME_WAIT è il problema più comune nell'architettura del server client di programmazione socket. Attendere qualche secondo provando periodicamente è la soluzione migliore per questo. Per le applicazioni in tempo reale hanno bisogno che il server si alzi immediatamente C'è un'opzione SO_REUSEADDR per loro.
TIME_WAITsul server" , salta semplicemente le prime tre risposte che evitano la domanda invece di rispondere.