Почему очистка прослушивающего TCP-порта занимает несколько минут после смерти программы?

Если я убиваю программу, которая прослушивает порт TCP, потребуется несколько минут, пока порт не будет восстановлен системой и снова пригоден для использования. Я видел несколько вопросов и ответов, упоминающих этот феномен, но без объяснения причин. Почему это происходит, почему система не восстанавливает порт сразу? Это также происходит в других системах, таких как Windows или Mac?

networking tcp resources Петр Пудлак
источник

Ответы:

Идея заключается в том, чтобы вы не получали пакеты, предназначенные для предыдущей программы, прослушивающей этот порт. Это TIME_WAITсостояние определено в RFC793 как двукратное максимальное время жизни сегмента.

Я не знаю о других операционных системах, но я предполагаю, что все они имеют какое-то похожее поведение.

Обходной путь для этой проблемы должен установить SO_REUSEADDRна сокете, который должен игнорировать TIME_WAITсостояние.

Ульрих Дангел
источник

Проверяя мою достоверную диаграмму состояний TCP, я вижу, что TIME_WAIT является последним состоянием сокета и обычно сохраняется для 2MSL - что в два раза превышает максимальное время жизни сегмента. В спецификации (RFC793) указывается, что это 2 минуты, а всего 4 минуты. Это дает достаточно времени для обработки любых запросов и ответов, которые все еще «в полете», и запускается в нужной программе - или отбрасывается, если сокет находится в TIME_WAIT.

Faelkle

Я могу подтвердить, что это происходит и в Windows.

Томас Братт