Windows server 2019 ограничение tcp подключений
Обновлено: 01.07.2024
Полезный блог для начинающих пользователей компьютера и не только..
6/20/2019
Как снять ограничение TCP/IP - соединений
Попытка подключения
Для установления TCP соединения локальный компьютер сперва посылает удалённому
компьютеру приглашение к соединению (так называемый SYN пакет).
Состояние, в котором при этом находится локальный компьютер, называют
полуоткрытым соединением (англ. half-open connection) или попыткой подключения
(англ. connection attempt).
Далее в зависимости от ответа удалённого компьютера полуоткрытое соединение либо
закрывается, либо переходит в нормальное установленное TCP соединение.
В чем суть ограничения
Ограничение заключается в том, что компьютеру не разрешается иметь более 10
одновременных полуоткрытых исходящих соединений. При достижении предела
новые попытки подключений ставятся в очередь .
Таким способом, фактически ограничена скорость подключения к другим компьютерам.
На количество установленных соединений жесткого предела в системе нет. Кроме
того, ограничение никак не затрагивает входящие соединения .
Ограничение введено компанией Microsoft в попытке замедлить распространение
вирусов с зараженного компьютера, а также ограничить возможности участия
компьютера в DoS - атаках.
Как проверить срабатывание ограничения
Как снять ограничение
Для того чтобы увеличить до максимума число возможных сессий в виндовой сетке, следует сделать следующее: запустить глобальные политики: CTRL+R - gpedit.msc
-Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности - Интерактивный вход в систему - выставляем его в 0 (отключение ограничения)
Значение этого параметра "0" отключает кэширование данных входа. При любом значении большем 50 кэшируется, только 50 попыток входа в систему .
или же внести правки в следующий ключ реестра:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\CachedLogonsCount
изменив значение CachedLogonsCount на 50 или 0
В Vista SP2 и Windows 7 это ограничение уже было убрано из драйвера протокола, но в системе имеется ограничение на использование сетки для шаринга и печати, установленное в 20 соединений.
Также максимальное число входящих подключений к IIS, которое можно настроить через ключ реестра:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpNumConnections (тип: DWORD, задав его от 5000 до 65536).
или же с помощью программы: EventID 4226 Patcher Version 2.23d , которая увеличит это число до 50.
От чего зависит скорость TCP/IP - соединения, Вы можете узнать здесь
Как устранить ошибки в TCP/IP - сетях читайте далее
Надеюсь эта статья поможет разобраться Вам с количеством одновременных подключений TCP/IP соединений. Подписывайтесь на обновления блога.
Несколько раз встречался с тем, что скорость копирования файлов по сети с/на виртуальные машины на Hyper-V в Windows Server 2019 намного ниже, чем в ВМ аналогичной конфигурации на хосте с Windows Server 2016. В некоторых тестах скорость записи/чтения данных по сети на ВМ в Windows Server 2019 почти в три раза ниже, чем в WS2016 (тестировалось копирование по SMB, SSH/SCP). Эта статья не претендует на абсолютную истину, но в ней я попытался собрать различные методики улучшения производительности сети в виртуальных машинах Hyper-V на Windows Server 2019 (и последних билдах Windows 10).
Receive Segment Coalescing в Hyper-V 2019
В первую очередь нужно вспомнить про технологии Receive Segment Coalescing (RSC), которая появилась в Hyper-V на Windows Server 2019/2022 (и в Windows 10 начиная с билда 1809). Receive Segment Coalescing используется на уровне виртуального коммутатора (vSwitch), позволяет снизить нагрузку на CPU и увеличить пропускную способность сети за счет объединения нескольких TCP сегментов в меньшее количество более крупных сегментов. Увеличение производительности сети достигается за счет того, что несколько больших сегментов обрабатывают быстрее множества мелких.
В предыдущих версиях Hyper-V на Windows Server 2016/2012R2 поддерживалась только аппаратная версия Receive Segment Coalescing на уровне сетевой карты.Наличие включенной поддержки RSC часто бывает источником дополнительной сетевой задержки в некоторых комбинациях железа.
Проблема проявляется как в полноценной Windows Server 2019 с графическим интерфейсом, так и в бесплатной редакции Windows Hyper-V Server.По умолчанию в Windows Server 2019 RSC включен для всех внешних (External) vSwitches.
Проверить, включен ли RSC для виртуальных коммутаторов можно командой:
Get-VMSwitch | Select-Object *RSC*
Можно запретить использовать RSC для IPv4 трафика на уровне клиентского сетевого адаптера:
Disable-NetAdapterRsc -Name "Ethernet" -IPv4
Проверьте, увеличится ли скорость копирования в ВМ на Hyper-V при отключении RSC. Если скорость сети увеличилась, можно отключить RSC на виртуальном коммутаторе, к которому подключена ВМ.
Пропускную способность сети можно замерить с помощью утилиты iperf.Чтобы отключить программный RSC для определенного виртуального коммутатора, выполните команду:
Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false
Либо можно полностью отключить RSC на хосте:
netsh int tcp set global rsc=disabled
Режим VMQ в драйвере сетевого адаптера
В некоторых случаях наличие включенной опции VMQ (Virtual Machine Queue) в драйвере сетевого адаптера физического хоста Hyper-V может привести к плохой производительности сети в виртуальных машинах Hyper-V. Связано это с тем, что VMQ это аппаратная функция, и, если она не поддерживается железом, но включена в драйвере это вызывает потерю пакетов и увеличивает сетевую задержку. Эта проблема характерна для сетевых карточек Broadcom Gigabit и встречается во всех версиях Hyper-V на Windows 2012 R2/2016/2019.
VMQ предназначен для повышения производительности сети за счет передачи пакетов от физического сетевого адаптера напрямую виртуальным машинам.Вы можете отключить VMQ в свойствах драйвера сетевого адаптера.
Либо вы можете вывести список сетевых адаптеров с поддержкой VMQ и их статус с помощью PowerShell:
Чтобы отключить VMQ для определенного адаптера, выполните команду (сетевой адаптер будет недоступен в течении пары секунд):
Set-NetAdapterVmq -Name “NICName” -Enabled $False
После отключения VMQ лучше перезагрузить хост и проверить сетевую производительность.
Оптимизация параметров протокола TCP для Windows Server 2019 Hyper-V
Сохраните текущие настройки TCP на хосте Hyper-V и примените новые настройки, которые сделают настройки протокола TCP в Windows Server 2019 максимально похожими на Windows Server 2016.
Сохраните текущие настройки:
Get-NetTCPSetting -SettingName Datacenter,DatacenterCustom,InternetCustom,Internet|select SettingName,CongestionProvider,CwndRestart,ForceWS|Export-csv c:\ps\nettcp_backup.csv
Примените новые настройка для LAN сети:
Set-NetTCPSetting -SettingName DatacenterCustom,Datacenter -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName DatacenterCustom,Datacenter -CwndRestart True
Set-NetTCPSetting -SettingName DatacenterCustom,Datacenter -ForceWS Disabled
Set-NetTCPSetting -SettingName InternetCustom,Internet -CongestionProvider CTCP
Set-NetTCPSetting -SettingName InternetCustom,Internet -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName InternetCustom,Internet -ForceWS Disabled
Отключите методики оптимизации сетевого RSS и RSC на уровне стека TCP:
netsh int tcp show global
netsh int tcp set global RSS=Disabled
netsh int tcp set global RSC=Disabled
или на уровне сетевых адаптеров:
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Recv Segment Coalescing (IPv4)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Recv Segment Coalescing (IPv6)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Receive Side Scaling" -DisplayValue "Disabled" –NoRestart
Отключите vRSS для всех ВМ:
Get-VM | Set-VMNetworkAdapter -VrssEnabled $FALSE
Отключите функцию Large Send Offload (LSO) на сетевых картах:
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Large Send Offload Version 2 (IPv4)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Large Send Offload Version 2 (IPv6)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Restart-NetAdapter
- Recv Segment Coalescing (IPv4/IPv6) = Disabled
- Large Send Offload V2 (IPv4/IPv6) = Disabled
Данные настройки стека TCP максимально приблизят настройки сетевых протоколов Windows Server 2019 к предыдущим версиям Windows Server.
используйте сведения в этом разделе для настройки сетевых адаптеров производительности для компьютеров под управлением Windows Server 2016 и более поздних версий. Если сетевые адаптеры предоставляют параметры настройки, эти параметры можно использовать для оптимизации пропускной способности сети и использования ресурсов.
Правильные параметры настройки для сетевых адаптеров зависят от следующих переменных.
- сетевой адаптер и набор его функций;
- Тип рабочей нагрузки, выполняемой сервером
- аппаратные и программные ресурсы сервера;
- задачи настройки сервера.
В следующих разделах описывается ряд параметров настройки производительности.
Включение функций разгрузки
Включение функций разгрузки на сетевом адаптере обычно имеет положительный эффект. Однако сетевой адаптер может оказаться недостаточно мощным для обработки возможностей разгрузки с высокой пропускной способностью.
Не используйте разгрузку задач IPSec функции разгрузки или разгрузку TCP Chimney. эти технологии являются устаревшими в Windows Server 2016 и могут негативно сказаться на производительности сервера и сети. Кроме того, эти технологии могут не поддерживаться корпорацией Майкрософт в будущем.
Например, рассмотрим сетевой адаптер с ограниченными аппаратными ресурсами. В этом случае включение возможности разгрузки сегментации может снизить максимальную устойчивую пропускную способность адаптера. Однако если приемлема пропускная способность, следует включить функции сегментирования разгрузки.
Для некоторых сетевых адаптеров требуется включить разгрузку компонентов независимо для путей отправки и получения.
Включение масштабирования на стороне приема (RSS) для веб-серверов
RSS способно повысить веб-масштабируемость и производительность, когда число сетевых адаптеров меньше количества логических процессоров на сервере. Когда весь веб-трафик проходит через сетевые адаптеры, поддерживающие RSS, сервер может обрабатывать входящие веб-запросы с разных соединений одновременно на разных процессорах.
Чтобы определить, поддерживает ли сетевой адаптер RSS, можно просмотреть сведения RSS на вкладке Дополнительные свойства в свойствах сетевого адаптера.
Профили RSS и очереди RSS
стандартный профиль RSS по умолчанию — нумастатик, который отличается от используемого по умолчанию предыдущих версий Windows. Прежде чем приступить к использованию профилей RSS, ознакомьтесь с доступными профилями, чтобы понять, когда они полезны и как они применяются к сетевой среде и оборудованию.
Например, если открыть диспетчер задач и проверить логические процессоры на сервере и они будут недостаточно загружены для приема трафика, можно попробовать увеличить число очередей RSS по умолчанию, равное двум, до максимума, поддерживаемого сетевым адаптером. В используемом сетевом адаптере могут быть параметры для изменения числа очередей RSS в драйвере.
Увеличение ресурсов сетевого адаптера
Для сетевых адаптеров, позволяющих вручную настраивать ресурсы, такие как буферы приема и отправки, следует увеличить выделенные ресурсы.
В некоторых сетевых адаптерах устанавливаются небольшие буферы приема для экономии выделенной памяти от узла. Это ведет к потере пакетов и снижению производительности. Поэтому для сценариев с интенсивным приемом рекомендуется увеличить буфер приема до максимума.
Если сетевой адаптер не предоставляет настройки ресурсов вручную, он динамически настраивает ресурсы, или для ресурсов задано фиксированное значение, которое нельзя изменить.
Включение контроля прерываний
Для управления прерываниями прерываний некоторые сетевые адаптеры предоставляют различные уровни управления прерываниями, различные параметры объединения буфера (иногда отдельно для буферов отправки и получения) или и то, и другое.
Следует рассмотреть возможность контроля прерываний для рабочих нагрузок, привязанных к ЦП. При использовании управления прерываниями учитывайте компромисс между экономией ЦП узла и задержкой, а также увеличением экономии ресурсов узла из-за большего количества прерываний и снижения задержки. Если сетевой адаптер не выполняет контроль прерываний, но он предоставляет объединение буферов, можно повысить производительность, увеличив число Объединенных буферов, чтобы освободить больше буферов на отправку или получение.
Настройка производительности для обработки пакетов с низкой задержкой
Многие сетевые адаптеры позволяют настраивать параметры для оптимизации системной задержки. Задержка — это время между обработкой входящего пакета сетевым драйвером и отправкой этого пакета обратно. Обычно это время измеряется в микросекундах. Для сравнения время передачи пакетов на длинные дистанции обычно измеряется в миллисекундах (это на порядок дольше). Эта настройка не сокращает время прохождения пакета.
Ниже приведены некоторые советы по настройке производительности для загруженных сетей, в которых на счету каждая микросекунда.
В BIOS компьютера установите значение High Performance (Высокая производительность) и отключите C-состояния. Однако имейте в виду, что это зависит от системы и BIOS, и некоторые системы обеспечивают большую производительность, если операционная система управляет электропитанием. проверить и настроить параметры управления питанием можно в Параметры или с помощью команды powercfg . Дополнительные сведения см. в разделе Параметры Powercfg Command-Line.
Установите в операционной системе профиль управления электропитанием Высокая производительность.
Этот параметр не работает должным образом, если BIOS системы имеет значение отключить управление питанием в операционной системе.
Включить статические разгрузки. Например, включите контрольные суммы UDP, контрольные суммы TCP и отправку параметров большой разгрузки (LSO).
Если трафик проходит через несколько потоков, например при получении многоуровневого трафика многоадресной рассылки, включите RSS.
Отключите Управление прерываниями в драйверах сетевых адаптеров, которым требуется самая низкая задержка. Помните, что эта конфигурация может использовать больше времени ЦП и представляет компромисс.
Обрабатывайте прерывания сетевого адаптера и DPC на основном процессоре, который совместно использует процессорный кэш с ядром, которое используется программой (пользовательским потоком), обрабатывающей пакет. Для передачи процесса конкретным логическим процессорам можно использовать настройку фиксации ЦП вместе с настройкой RSS. Использование одного ядра для прерываний, DPC и пользовательского потока ведет к снижению производительности из-за увеличения нагрузки, поскольку ISR, DPC и поток будут конкурировать за ядро.
Прерывания управления системой
SMI — это прерывание с наивысшим приоритетом в системе и помещает ЦП в режим управления. Этот режим загружает все остальные действия, в то время как SMI запускает подпрограммы службы прерываний, обычно содержащиеся в BIOS.
К сожалению, такое поведение может привести к скачкам задержки 100 микросекунд или более.
Когда необходимо обеспечить минимальную задержку, следует запросить у поставщика оборудования версию BIOS, в которой прерывания SMI имеют наименьший возможный приоритет. Эти версии BIOS часто называются "BIOS с низкой задержкой" или "SMI Free BIOS". В некоторых случаях аппаратная платформа не может полностью исключить активность SMI, так как она используется для управления важными функциями (например, вентиляторами).
Операционная система не может управлять SMIs, так как логический процессор работает в специальном режиме обслуживания, что предотвращает вмешательство пользователя операционной системы.
Настройка производительности TCP
Для настройки производительности TCP можно использовать следующие элементы.
Автоматическая настройка окна приема TCP
в Windows Vista, Windows Server 2008 и более поздних версиях Windows Windows сетевой стек использует функцию, именуемую режимом автонастройки окна приема tcp , для согласования размера окна приема tcp. Эта функция может согласовать определенный размер окна приема для каждого подключения TCP во время подтверждения TCP.
в более ранних версиях Windows сетевой стек Windows использовал окно приема фиксированного размера (65 535 байт), которое ограничивает общую возможную пропускную способность для подключений. Общая пропускная способность подключений TCP может ограничивать сценарии использования сети. Автоматическая настройка окна приема TCP позволяет этим сценариям полностью использовать сеть.
Для окна приема TCP, имеющего определенный размер, можно использовать следующее уравнение для вычисления общей пропускной способности отдельного соединения.
Общая пропускная способность в байтах Размер окна приема TCP в байтах * (1/ Задержка подключения в секундах)
Например, для соединения с задержкой 10 мс общая пропускная способность составляет только 51 Мбит/с. Это значение целесообразно для большой корпоративной сетевой инфраструктуры. Однако с помощью автонастройки для настройки окна приема подключение может обеспечить полную скорость линии для подключения 1 Гбит/с.
Некоторые приложения определяют размер окна приема TCP. Если приложение не определяет размер окна приема, скорость связи определяется следующим образом:
- Менее 1 мегабит в секунду (Мбит/с): 8 килобайт (КБ)
- от 1 Мбит/с до 100 Мбит/с: 17 КБ
- от 100 Мбит/с до 10 гигабит в секунду (Гбит/с): 64 КБ
- 10 Гбит/с или более: 128 КБ
Например, на компьютере с установленным сетевым адаптером с 1 Гбит/с размер окна должен быть 64 КБ.
Эта функция также обеспечивает полное использование других функций для повышения производительности сети. Эти функции включают остальные параметры TCP, определенные в RFC 1323. используя эти функции, компьютеры на базе Windows могут согласовать размеры окна приема TCP, которые меньше, но масштабируются по определенному значению в зависимости от конфигурации. Такое поведение упрощает обработку размеров для сетевых устройств.
Может возникнуть проблема, при которой сетевое устройство не соответствует параметру TCP Window Scale, как определено в RFC 1323 и, следовательно, не поддерживает коэффициент масштабирования. в таких случаях обратитесь к этой статье KB 934430, если вы пытаетесь использовать Windows Vista за устройством брандмауэра или обратитесь в службу поддержки для поставщика сетевых устройств.
Проверка и настройка уровня автонастройки окна приема TCP
для просмотра или изменения уровня автонастройки окна приема TCP можно использовать команды netsh или командлеты Windows PowerShell.
в отличие от версий Windows, которые предварительно устарели Windows 10 или Windows Server 2019, вы больше не можете использовать реестр для настройки размера окна приема TCP. Дополнительные сведения об устаревших параметрах TCPсм. здесь.
Подробные сведения о доступных уровнях автонастройки см. в разделе уровни автонастройки.
Использование команды Netsh для просмотра или изменения уровня автонастройки
Чтобы проверить текущие параметры, откройте окно командной строки и выполните следующую команду:
Выходные данные этой команды должны выглядеть следующим образом:
Чтобы изменить этот параметр, выполните в командной строке следующую команду:
В предыдущей команде <<> представляет новое значение для уровня автоматической настройки.
Использование PowerShell для просмотра или изменения уровня автонастройки
Чтобы проверить текущие параметры, откройте окно PowerShell и выполните следующий командлет.
Выходные данные этого командлета должны выглядеть следующим образом.
Чтобы изменить этот параметр, выполните следующий командлет в командной строке PowerShell.
В предыдущей команде <<> представляет новое значение для уровня автоматической настройки.
Дополнительные сведения об этих командлетах см. в следующих статьях:
Уровни автонастройки
Можно настроить автоматическую настройку окна приема на любой из пяти уровней. Уровень по умолчанию — Обычная. В следующей таблице описаны уровни.
| Level | Шестнадцатеричное значение | Комментарии |
|---|---|---|
| Normal (по умолчанию) | 0x8 (коэффициент масштабирования 8) | Задайте для окна приема TCP значение рост в соответствии с практически всеми сценариями. |
| Выключено | Коэффициент масштабирования недоступен | Задайте для окна приема TCP значение по умолчанию. |
| С ограниченным доступом | 0x4 (коэффициент масштабирования 4) | Задайте размер окна приема TCP, превышающего значение по умолчанию, но ограничьте такой рост в некоторых сценариях. |
| С высоким уровнем ограничений | 0x2 (коэффициент масштабирования 2) | Задайте размер окна приема TCP, превышающего значение по умолчанию, но это очень консервативно. |
| Экспериментальный | 0xE (коэффициент масштабирования 14) | Задайте для окна приема TCP значение рост в соответствии с экстремальными сценариями. |
Если для записи сетевых пакетов используется приложение, приложение должно сообщить данные, аналогичные приведенным ниже, для различных параметров автонастройки окна.
Уровень автонастройки: нормальный (состояние по умолчанию)
Уровень автонастройки: отключен
Уровень автонастройки: ограниченный
Уровень автонастройки: очень ограниченный
Уровень автонастройки: экспериментальный
Устаревшие параметры TCP
следующие параметры реестра из Windows Server 2003 больше не поддерживаются и не учитываются в более поздних версиях.
Все эти параметры были расположены в следующем подразделе реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Платформа фильтрации Windows
Windows в Vista и Windows Server 2008 появилась платформа фильтрации Windows (WFP). WFP предоставляет интерфейсы API независимым поставщикам программного обеспечения (ISV) для создания фильтров обработки пакетов. Например, для брандмауэров и антивирусного ПО.
Плохо написанный фильтр WFP может значительно снизить производительность сети сервера. дополнительные сведения см. в разделе перенос Packet-Processing драйверов и приложений в WFP в Windows Центр разработки.
Ссылки на все разделы данного руководства см. в разделе Настройка производительности сетевой подсистемы.
Собственно лимит TCP подключений в обычной винде == 20. Есть какие-то грязные хаки, как это отключить, не переходя на Windows Server и всё же, как же тогда работает тот же торрент клиент в обычной винде, ведь там может быть кол-во коннектов намного больше 20-и ?
-=MASTER=-
> лимит TCP подключений в обычной винде == 20
Только в home edition примерно столько, в остальных - порядка 1000, на сервере еще больше.
> как же тогда работает тот же торрент клиент в обычной винде
Эта винда не обычная, очень мало у кого home версия. И торент в ней вот так и работает, хреново. TCP он не использует, кстати, иначе бы не смог перекидывать данные p2p, когда оба клиента за натами.
Хакнуть наверное можно, но не разу не слышал, чтобы так делали. Если уж нарушать лицензию, гораздо проще другую версию винды поставить.
0iStalker
> Возьми Linux/Freebsd
Да это я чисто любопытства спрашивал, сервак то всё равно не Linux-е, где этих ограничений нет вообще вроде как. Странная политика винды.
Zab
> TCP он не использует, кстати, иначе бы не смог перекидывать данные p2p, когда
> оба клиента за натами.
Так а как он работает, через UDP что ли?
-=MASTER=-
Zab
Вы там бухаете что ли?
В винде лимит на 10 или 20 полуоткрытых tcp соединений. Иными словами 10 или 20 попыток одновременных соединений.
Есть еще какой-то мелкий лимит на количество smb и ms-rdp сессий.
К количеству одновременных установленных tcp соединений это не имеет никакого отношения.
Какой-то лимит есть конечно, но чтобы его достигнуть, надо очень постараться.
youtube
Вы не видели home-версии, видимо.
На самом деле, я не знаю какой лимит у домашней десятки, но у всех остальных количество доступных сокетов в системе было очень маленьким, а соответственно и число соединений. Могу предположить, что в десятке принципиально ничего не изменилось. 20 сокетов вместо 10, которые были в XP home. Должны же они в винде что-то урезать, если эту версию распространяют едва ли не бесплатно. иначе нормальную покупать не будут.
Zab
> XP home
Это был вообще огрызок, каких еще поискать нужно благо, после SP2 он перестал существовать вообще. Нет смысла сравнивать его с любой другой версией винды.
Zab
> Вы не видели home-версии, видимо.
Видел. Там как раз ограничение на smb и ms-rdp. На количество tcp сессий вообще такого ограничения нет.
youtube, Zab, не, конечно же речь о нормальной винде, а не какой-то home или хз какой, я их никогда и не ставил, да и смысл ставить не топовую, если всё равно всё с торрентов заливаешь :)
Так что, если сервер TCP коннекты по возможности не рвёт, то проблемы могут быть только в случае одновременных попыток подключиться толпы пользователей? Хмм. вообще это хорошо, хотя и это странно, это ж надо так загадить ОС. А вообще конечно, если сервер - то линукс однозначно, т.к. к винде доверия ноль, особенно к последним версиям, которые напрямую в соглашениях пишут, что они твои данные стягивают ) Даже если все эти шпионские штуки патчем поотрубать, не факт, что отключишь их все.
youtube
> Какой-то лимит есть конечно
65535
MrShoor
> 65535
это кол-во портов, а на один порты ты можешь приконнектить много TCP соединений
MrShoor
> Ты эти порты нигде не задаешь и в принципе их не видишь, но они есть.
хмм, не слышал, думал, что при коннекте к серверу на определённый порт, просто инициализируется сокет и передаётся серверу его дескриптор, который типа int, то есть сокетов в теории может быть очень много. А что, реально на один порт может только 65535 TCP приконнектится? Что-то на гон похоже )
-=MASTER=-
Представь, что ты, разработчик ОС. Вот пользователь открывает 10 соединений на один и тот же порт на один и тот же сервер. Как ты определишь какие пакеты в какое соединение рассылать? Для этого и существует локальный порт. Открываешь Resource Monitor в винде, и на вкладке Network смотришь раздел TCP Connections. Там есть колонка с локальными портами, которые назначаются случайным образом на каждое открытое соединение.
Можно получить самому список этих локальных портов через GetTcpTable. А если сходишь и посмотришь параметры, которые возвращает тебе эта функция, то увидишь там в MIB_TCPROW параметр dwLocalPort для которого черным по белому написано:
Читайте также: