TCP-соединение, принадлежащее pid zero

Я пытаюсь обеспечить, чтобы служебная программа Windows (работающая поверх .NET) правильно освобождала свои сетевые подключения.

При запуске службы локально я знаю, что он создаст много HTTP-соединений с localhost на порту 57300. Я использую netstat для контроля того, выпущены ли они должным образом.

Я был удивлен, увидев, что многие подключения к этому порту принадлежат "Системному Idle process" (PID = 0).

Здесь мы видим, что только три из этих подключений принадлежат сервисной программе (PID = 5012). Все остальные принадлежат PID 0.

Мои основные вопросы: Почему это происходит? и Нужно ли мне заботиться?

Но я также хотел бы знать:

Означает ли это, что сервисная программа действительно освободила соединение, или нет?
Будут ли такие соединения повторно использоваться при необходимости?
Сделайте такое подключение "зарезервируйте слот" в .NET ServicePointManager?

Ответ 1

После закрытия TCP-соединения он переходит в состояние TIME_WAIT в течение фиксированного периода. Это делается для того, чтобы любые пакеты, связанные с соединением, которые все еще могут стоять в очереди в сети, не будут мешать новым соединениям.

Так как это должно произойти, даже если исходный процесс вышел, я предполагаю, что Windows автоматически передает право собственности на системный процесс.

Итак, я считаю, что ответы на ваши последние четыре вопроса:

Нет, вам, вероятно, не нужно беспокоиться об этом.
Да, служебная программа правильно освободила соединение.
Связи TIME_WAIT будут закрыты раньше если в системе заканчиваются TCB. В конфигурации по умолчанию это произойдет до того, как вы закончите работу с портами, поэтому, по сути, да, соединения будут повторно использоваться, если они понадобятся.
Я не знаком с менеджером точек обслуживания, но нет причин для отслеживания соединений в состоянии TIME_WAIT, поэтому, вероятно, нет.

В Windows XP значение по умолчанию для задержки TIME_WAIT составляло две минуты. Я не могу найти более новую информацию, но, похоже, она не изменилась с тех пор.