У меня есть серверное приложение, которое использует постоянно подключенные входящие порты в диапазоне, который W2k8 теперь использует в рекомендованном IANA диапазоне ~ 49000-65000. (По устаревшим причинам это очень сложно изменить, поэтому мне придется изменить диапазон окна, чтобы избежать моего диапазона, но это не вопрос).
Я исследовал, как избежать конфликтов с временными портами в Windows 2008 Server, но не могу найти подробностей о алгоритм Windows для выбора эфемерных портов.
Когда сетевой уровень Windows назначает «случайный» эфемерный порт для ответа на исходящее TCP / IP-соединение, тестирует ли предложенный порт чтобы узнать, используется ли он уже?
(Ядро Linux похоже, делает тест check_established но все еще может повторно использовать некоторые использованные соединения, поэтому мне интересно, какие решения Windows может принять при удалении, казалось бы, неиспользуемых или незанятых портов у другого процесса ...)
т.е. если мой сервер открывает winsocks на всех своих портах и сохраняет их в состоянии LISTENING, будет ли Windows уважать и пропускать их, потому что они используются? Или он проигнорирует тот факт, что они используются, и все равно назначит их другим процессам для временного использования, вызывая конфликты?
Я обнаружил, что иногда, когда мой сервер запускается, он не может выделить несколько своих портов, потому что они используются для случайных целей другими процессами - что имеет смысл, и я это понимаю. Но я еще не смог доказать, были ли порты, которые ему удалось открыть изначально, впоследствии «украдены» для эфемерных целей (это сложно проверить или принудительно из-за большого диапазона и случайного характера).
Как я уже сказал, я собираюсь перенастроить окна, чтобы в любом случае избегать моего сервера, поэтому этот вопрос больше из любопытства и для более ясного объяснения недавнего поведения (чтобы исключить / исключить другие возможные ошибки!)
заранее спасибо
Я бы ответил на это;
Для программы, которую вы написали с помощью Winsock API, она обрабатывает это примерно так; http://support.microsoft.com/kb/173619.
Когда вы закрываете дескриптор сокета, между клиентом и сервером происходит дополнительное согласование. Сокет будет ждать до двух раз больше максимального времени, в течение которого окна будут ждать получения подтверждения от другого конца сокета, который закрыл порт. По умолчанию этот параметр установлен на две минуты. Поэтому Windows может подождать до четырех минут, прежде чем порт действительно будет освобожден. Это делает этот конкретный порт недоступным, пока он не будет фактически освобожден.
Для службы Windows RPC;
* В этой статье не указывается, какие службы полагаются на другие службы для сетевой связи. Например, многие службы полагаются на функции удаленного вызова процедур (RPC) или DCOM в Microsoft Windows для назначения им динамических портов TCP. Служба удаленного вызова процедур координирует запросы других системных служб, которые используют RPC или DCOM для связи с клиентскими компьютерами. Многие другие службы полагаются на сетевую базовую систему ввода / вывода (NetBIOS) или протоколы SMB, которые предоставляются службой сервера. Другие службы полагаются на HTTP или защищенный протокол передачи гипертекста (HTTPS). Эти протоколы предоставляются Internet Information Services (IIS). Полное обсуждение архитектуры операционных систем Windows выходит за рамки данной статьи. Однако подробная документация по этому вопросу доступна на Microsoft TechNet и на веб-сайтах Microsoft Developer Network (MSDN). Хотя многие службы могут полагаться на определенный порт TCP или UDP, только одна служба или процесс может одновременно прослушивать этот порт.
Когда вы используете RPC с TCP / IP или UDP / IP в качестве транспорта, входящие порты часто динамически назначаются системным службам по мере необходимости; Используются порты TCP / IP и UDP / IP выше 1024. Они также неофициально известны как случайные порты RPC. В этих случаях клиенты RPC полагаются на сопоставитель конечных точек RPC, чтобы сообщить им, какой динамический порт или порты были назначены серверу. Для некоторых служб на основе RPC вы можете настроить конкретный порт вместо того, чтобы разрешать RPC динамически назначать порт. Вы также можете ограничить диапазон портов, которые RPC динамически назначает небольшим диапазоном, независимо от службы. Дополнительную информацию по этой теме см. В разделе «Ссылки». *