TIME_WAIT использует дескрипторы файлов?

Проверьте административные средства удаленного сервера для Windows 7

http://www.microsoft.com/downloads/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en

Кавычка: Административные средства Удаленного сервера для Windows 7 позволяют системным администраторам управлять ролями и функциями, которые установлены на удаленных компьютерах, которые выполняют Windows Server 2008 R2 (и, для некоторых ролей и функций, Windows Server 2008 или Windows Server 2003) от удаленного компьютера, который запускает Windows 7. Это включает поддержку удаленного управления компьютерами, которые выполняют или Сервер опции Базовой или полной установки Windows Server 2008 R2, и для некоторых ролей и функций, Windows Server 2008. Некоторыми ролями и функциями на Windows Server 2003 можно управлять удаленно при помощи Административных средств Удаленного сервера для Windows 7, хотя опция инсталляции Server Core не доступна с операционной системой Windows Server 2003.

Эта функция сопоставима в функциональности с Административными средствами Пакета и Удаленного сервера Средств администрирования Windows Server 2003 для Windows Vista с Пакетом обновления 1 (SP1).

7
задан 10 September 2010 в 18:30
2 ответа

TIME_WAIT является состоянием TCP и не использует дескрипторы файлов persay. Однако сокеты в TIME_WAIT используют дескрипторы файлов. Сокет является файлом как примерно все остальное в Unix. Если это - Linux, можно настроить истечь время сокетов (сколько времени они, вовремя ожидают), а также включите переработку сокета в /proc/sys/net/ipv4/.

Два особенно интересных объекта, вероятно:

sysctl -w net.ipv4.tcp_tw_recycle=1
sysctl -w net.ipv4.tcp_tw_reuse=1

Как всегда, тест они заранее, если Вы можете.

3
ответ дан 2 December 2019 в 23:36

Файловый дескриптор используется приложением для чтения/записи из сокета. Таким образом, если приложение вызывает функцию close(), файловый дескриптор немедленно освобождается.

С другой стороны, если приложение вызывает функцию shutdown(), файловый дескриптор останется работоспособным, так что приложение все равно сможет читать/записывать из/в сокет.

Цитаты из https://oroboro.com/file-handle-leaks-server/:

Миф: Сокеты в TCP TIME_WAIT держат файловые дескрипторы Hostage

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

Но это не держит открытой файловую оболочку. Когда вы закрываете файловый дескриптор сокета, закрывается сам файловый дескриптор. Вы не получите ошибку "Открыто слишком много файлов". Если у вас открыто слишком много сокетов, то ваш сервер может перестать принимать новые соединения. Есть способы справиться с этим ( разрешить повторное использование сокетов или снизить TCP TIME_WAIT )- но повышение лимита на обработку файлов не является одним из них.

Миф: Для освобождения файловых дескрипторов требуется время

Это связано с мифом о TCP TIME_WAIT. Ошибочное убеждение, что когда вы закрываете файловый handle, вы должны подождать некоторое время, пока операционная система освободит этот handle.

Закрытие файлового handle вызовет любой метод os, который освободит ресурс, и операционная система освободит этот ресурс либо немедленно, либо иногда позже, как в случае с сокетами, но close() немедленно освободит файловый handle в таблице файловых handle. Ваш процесс полностью контролирует свою таблицу файловых дескрипторов, и ему не нужно ждать, пока что-нибудь освободит слот в его собственной таблице файловых дескрипторов.

5
ответ дан 2 December 2019 в 23:36

Теги

Похожие вопросы