Dlaczego wyczyszczenie nasłuchującego portu TCP zajmuje kilka minut po śmierci programu?

Jeśli zabiję program nasłuchujący na porcie TCP, może upłynąć kilka minut, zanim port zostanie odzyskany przez system i ponownie użyty. Widziałem kilka pytań / odpowiedzi dotyczących tego zjawiska, ale bez wyjaśnienia. Dlaczego tak się dzieje, dlaczego system nie odzyskuje portu natychmiast? Czy dzieje się tak również w innych systemach, takich jak Windows lub Mac?

networking tcp resources

— Petr Pudlák
źródło

Chodzi o to, aby nie otrzymywać pakietów skierowanych do poprzedniego programu nasłuchującego na tym porcie. Ten TIME_WAITstan jest zdefiniowany w RFC793 jako dwukrotność maksymalnego okresu użytkowania segmentu.

Nie wiem o innych systemach operacyjnych, ale zakładam, że wszystkie mają podobne zachowanie.

Obejściem tego problemu jest ustawienie SO_REUSEADDRgniazda, które powinno zignorować TIME_WAITstan.

— Ulrich Dangel
źródło

Sprawdzając mój zaufany diagram stanu TCP, widzę, że TIME_WAIT jest ostatnim stanem gniazda i generalnie utrzymuje się przez 2MSL - co stanowi dwukrotność maksymalnego okresu użytkowania segmentu. Specyfikacja (RFC793) określa to jako 2 minuty, co daje w sumie 4 minuty. Pozwala to na wystarczającą ilość czasu na przetworzenie żądań i odpowiedzi „w locie” i wylądowanie w odpowiednim programie - lub odrzucenie, jeśli gniazdo znajduje się w TIME_WAIT.

— Faelkle,

Mogę potwierdzić, że dzieje się tak również w systemie Windows.

— Thomas Bratt