Warum dauert es einige Minuten, um einen empfangsbereiten TCP-Port zu bereinigen, nachdem ein Programm abgestorben ist?

Wenn ich ein Programm beende, das einen TCP-Port überwacht, dauert es einige Minuten, bis der Port vom System wiederhergestellt und wieder verwendet werden kann. Ich habe mehrere Fragen / Antworten gesehen, die dieses Phänomen erwähnen, aber ohne eine Erklärung. Warum passiert das, warum fordert das System den Port nicht sofort zurück? Kommt es auch auf anderen Systemen wie Windows oder Mac vor?

networking tcp resources

— Petr Pudlák
quelle

Die Idee dahinter ist, sicherzustellen, dass Sie keine Pakete erhalten, die für das vorherige Programm bestimmt sind, das diesen Port überwacht. Dieser TIME_WAITStatus wird in RFC793 als das Zweifache der maximalen Segmentlebensdauer definiert.

Ich kenne keine anderen Betriebssysteme, gehe aber davon aus, dass sich alle ähnlich verhalten.

Eine Problemumgehung für dieses Problem besteht darin, SO_REUSEADDRfür den Socket festzulegen, der den TIME_WAITStatus ignorieren soll .

— Ulrich Dangel
quelle

Wenn ich mein vertrauenswürdiges TCP-Statusdiagramm überprüfe, kann ich feststellen, dass TIME_WAIT der letzte Status eines Sockets ist und im Allgemeinen für 2MSL besteht - das ist das Doppelte der maximalen Segmentlebensdauer. Die Spezifikation (RFC793) gibt dies als 2 Minuten an, was insgesamt 4 Minuten ergibt. Auf diese Weise bleibt genügend Zeit, um Anfragen und Antworten, die sich noch im "Flug" befinden, zu verarbeiten und im richtigen Programm zu landen - oder zu verwerfen, wenn sich der Socket in TIME_WAIT befindet.

— Faelkle

Ich kann bestätigen, dass dies auch in Windows passiert.

— Thomas Bratt