TCP-соединения, принадлежащие пид ноль

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

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

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

выход netstat

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

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

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

  • Означает ли это, что служебная программа выпустила соединение правильно или нет?

  • Будут ли такие соединения использоваться повторно в случае необходимости?

  • Сделайте такое соединение "зарезервируйте слот" в .NET ServicePointManager ?

1 15
.net tcp windows netstat

1 ответ:

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

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

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

  • Нет, ты наверное, не стоит об этом беспокоиться.

  • Да, служебная программа правильно освободила соединение.

  • Соединения TIME_WAIT будут закрыты рано , Если в системе закончится TCBs . В конфигурации по умолчанию это произойдет до того, как у вас закончатся порты, поэтому в действительности, да, соединения будут использоваться повторно, если они необходимы.

  • Я не знаком с менеджером точек обслуживания, но у него нет причин отслеживать соединения в состоянии TIME_WAIT, так что, вероятно, нет.

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

18