Om FIN_WAIT2

About Fin_wait2



La oss varme opp og huske situasjonen da TCP lukket forbindelsen gjennom et gammelt bilde:

TCP Lukk



TCP Lukk



I henhold til den normale tilstandsmigrasjonsstien, når FIN_WAIT2 mottar FIN-pakken, vil den flytte til TIME_WAIT-tilstand. Hvis du ikke mottar FIN-pakken, hvordan vil tilkoblingstilstanden migrere, kan vi like godt teste den:



#!/usr/bin/env python import socket import time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('127.0.0.1', 1234)) s.listen(1) c, _ = s.accept() time.sleep(1000) c.close()

Bruk som ovenfor Python En enkel serverdemokode implementert. Det skal bemerkes at jeg satte en enorm forsinkelse før jeg lukket, for å forsinke serveren fra å sende ut FIN-pakken. Tilsvarende implementerer vi en enkel klientdemokode, den har ingenting å si, den er direkte stengt etter tilkobling:

#!/usr/bin/env python import socket import time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 1234)) s.close()

Når du tester, start serveren for å lytte på port 1234, og start deretter klienten for å koble til port 1234. For å bekrefte om hele prosessen oppfyller våre forventninger, kan du bruke tcpdump til å overvåke kommunikasjonsprosessen:

tcpdump -t -nn -i hvilken som helst port 1234



tcpdump -t -nn -i hvilken som helst port 1234

Som vist i figuren: etter treveis håndtrykk lukket klienten forbindelsen, og serveren sendte ikke ut en FIN-pakke etter bekreftelse, så hele prosessen var i tråd med våre forventninger, og for å bestemme hvor lenge FIN_WAIT2 eksisterer, følgende kode ble skrevet:

#!/usr/bin/env python import socket import time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 1234)) s.shutdown(socket.SHUT_WR) time.sleep(1000) s.close()

Overvåkingen fant at i dette tilfellet eksisterer FIN_WAIT2 i omtrent ett minutt:

FIN_WAIT2

Hvor lenge FIN_WAIT2 eksisterer

Faktisk er denne tiden kontrollert av 'net.ipv4.tcp_fin_timeout', men det er funnet i testen at tiden FIN_WAIT2 ikke er akkurat lik innstillingen av tcp_fin_timeout, det er et visst avvik. I tillegg bør det bemerkes at etter_tcp_fin_timeout, FIN_WAIT2 ikke overføres til TIME_WAIT, men lukkes direkte.

For introduksjonen av tcp_fin_timeout, kan du se beskrivelsen av kjernen:

Hvor lang tid en foreldreløs (ikke lenger referert til av noen applikasjon) -forbindelse forblir i tilstanden FIN_WAIT_2 før den avbrytes ved den lokale enden. Mens en helt gyldig 'motta bare' -status for en ikke-foreldreløs tilkobling, kan en foreldreløs forbindelse i FIN_WAIT_2-tilstand ellers vente for alltid på at fjernkontrollen lukker forbindelsens slutt.
Jf. tcp_max_orphans
Standard: 60 sekunder

Begrepet foreldreløs nevnes i innledningen, noe som betyr at når en stikkontakt ikke lenger refereres til av noen applikasjon, blir den foreldreløs, og tcp_fin_timeout begrenser tiden den foreldreløse FIN_WAIT2 kan overleve.

Merk: Hvis det er for mange foreldreløse barn, vil det: Feilen “Out of socket memory” .

Noen mennesker kan spørre: Hva om FIN_WAIT2 ikke er foreldreløs?

|_+_|

I denne versjonen av klientkoden stenger vi ikke forbindelsen direkte, men lukker den ved å slå av. På dette tidspunktet vil klienten også sende en FIN-pakke, men forbindelsen blir ikke utgitt, så FIN_WAIT2 i dette eksemplet og FIN_WAIT2 i forrige eksempel Forskjellig blir den ikke foreldreløs. Gjennom testing er det funnet at tcp_fin_timeout vil være ugyldig på dette tidspunktet, og FIN_WAIT2 i dette tilfellet vil alltid eksistere til klienten stenger forbindelsen eller avslutter.

Faktisk, i forhold til andre TCP-stater, vil FIN_WAIT2 vanligvis ikke gi deg mye problemer. Hvis du teller TCP-statusen på serveren, vil du oppdage at de fleste av dem er svært få, hvis ikke, så må det være et problem på applikasjonsnivå. Når det gjelder tcp_fin_timeout, anbefaler jeg ikke at du setter den for liten, for som nevnt ovenfor, under normale omstendigheter, vil TCP-forbindelsen ikke forbli i FIN_WAIT2-tilstanden for lenge, forutsatt at FIN-pakketap og lignende virkelig oppstår, da Det er nødvendig å gi FIN_WAIT2-tilstanden en rimelig livssyklus. Tross alt kan den tapte FIN-pakken overføres på nytt. På dette tidspunktet er det den samme grunnen til at TIME_WAIT eksisterer 2MSL. Siden TIME_WAIT eksisterer som standard i 60 sekunder, er standardinnstillingen for tcp_fin_timeout til 60 også et rimelig valg.