65 535 портов — миф о потолке: сколько исходящих соединений вы откроете на самом деле

MAATRIX

Рано или поздно в любом обсуждении нагрузки всплывает фраза «у сервера всего 65 535 портов, больше соединений не откроешь». Она звучит убедительно и даже подкрепляется реальными авариями с TIME_WAIT — но описывает не тот предел, который вы думаете. Разберём, что именно ограничивает число 65 535, почему сервер под нагрузкой в 100 000 клиентов не нарушает никаких законов физики, и какой потолок исходящих соединений у вас есть на самом деле.

Откуда взялось число 65 535 и что оно ограничивает на самом деле

Поле номера порта в заголовке TCP и UDP — 16 бит. Это даёт 65 536 значений, от 0 до 65 535. Порт 0 зарезервирован и обычно не используется приложениями напрямую, отсюда и округление до «65 535 портов» в разговорах.

Дальше важный нюанс, который обычно теряется: этот диапазон — не общесистемный лимит соединений, а диапазон номеров портов на одном локальном IP-адресе. Порты 1–1023 исторически считаются привилегированными (на Linux и других Unix-подобных системах для биндинга на них нужны права root или capability CAP_NET_BIND_SERVICE), 1024–49151 — «зарегистрированные», а верхний диапазон IANA относит к динамическим/эфемерным — именно из него ядро берёт номер локального порта, когда ваш процесс сам инициирует исходящее соединение.

На Linux реальный эфемерный диапазон настраивается и отличается от IANA-рекомендации. Посмотреть свой:

cat /proc/sys/net/ipv4/ip_local_port_range
# например: 32768 60999

Это уже не 65 535, а обычно около 28 000 значений — именно эта цифра фигурирует в историях вида «через несколько минут кончились исходящие порты». Но это диапазон для соединений с одного локального IP к одному конкретному удалённому адресу — не абсолютный потолок сервера.

Сервер, принимающий соединения, использует один и тот же порт для всех клиентов

Здесь и рождается главная путаница. Когда nginx слушает 443, он не «раздаёт» клиентам разные порты одного за другим, пока не кончатся. Он слушает один порт — 443 — и принимает на него сколько угодно параллельных TCP-соединений. Проверить:

ss -tlnp | grep :443
# LISTEN 0 511 0.0.0.0:443 0.0.0.0:*

Один листенер, один порт, тысячи одновременных клиентов. Число открытых соединений на стороне сервера, принимающего трафик, порты вообще не ограничивают — ограничивают файловые дескрипторы, память под сокеты и буферы, размер очереди backlog, настройки таблицы conntrack, если трафик проходит через netfilter/NAT. Про упор именно в эти ресурсы на конкретных цифрах разговор отдельный — здесь важно только зафиксировать: входящая сторона в 65 535 не упирается никогда, потому что порт на ней один и тот же.

Четвёрка, которая определяет соединение — и почему один порт можно занимать многократно

Ядро идентифицирует TCP-соединение не номером порта, а четвёркой значений: (локальный IP, локальный порт, удалённый IP, удалённый порт). Уникальным должно быть именно сочетание всех четырёх, а не порт сам по себе.

Отсюда прямое следствие для исходящих соединений: если ваш сервер подключается к одному и тому же удалённому адресу и порту (скажем, к одной базе данных на 5432 или к одному upstream API), то на каждое такое соединение ядро обязано выделить уникальный локальный порт — потому что три остальных элемента четвёрки (локальный IP, удалённый IP, удалённый порт) у всех этих соединений одинаковые, различаться может только локальный порт. В этом случае вы действительно упираетесь в размер эфемерного диапазона на этом локальном IP — те самые ~28 000–64 000 значений.

Но если сервер подключается к разным удалённым адресам — к тысячам разных API, разным клиентским вебхукам, разным сайтам при обходе — то один и тот же локальный порт может использоваться одновременно в разных соединениях, потому что четвёрка в каждом случае разная за счёт разного удалённого IP или порта. Именно поэтому краулер или прокси-сервер, обслуживающий множество разных направлений, способен держать заметно больше 65 535 параллельных исходящих TCP-сессий с одного локального IP — предел здесь определяется не портами, а тем, сколько записей о соединениях вообще способна удержать система (память, дескрипторы, conntrack).

TIME_WAIT — реальный источник проблем с исходящими портами

Даже когда соединение закрыто, занятый им локальный порт не освобождается мгновенно. Сторона, инициировавшая закрытие, переводит сокет в состояние TIME_WAIT и держит его там в течение удвоенного MSL (Maximum Segment Lifetime) — на практике это нередко порядка 60 секунд, конкретное значение платформозависимо и на части систем настраивается. Пока сокет в TIME_WAIT, связанная с ним четвёрка (а с ней и локальный порт для этого направления) считается занятой.

Если сервер открывает много коротких исходящих соединений к одному и тому же адресу — типичный случай: без keep-alive дергаете один и тот же upstream API или один и тот же Redis новым соединением на каждый запрос — вы можете исчерпать доступные локальные порты для этого конкретного направления задолго до того, как упрётесь в память или дескрипторы. Именно этот сценарий подробно разбирается в материале про то, как заканчиваются исходящие порты и накапливаются десятки тысяч TIME_WAIT — там показано, как считать точный запас портов для одного направления и куда он утекает. Смежный разбор — откуда вообще берутся тысячи соединений в TIME_WAIT на практике одного сервиса.

Посмотреть, сколько у вас сейчас соединений висит в TIME_WAIT именно по одному направлению:

ss -tan state time-wait '( dst 10.0.0.5 )' | wc -l

Если число близко к размеру вашего ip_local_port_range — вы упёрлись не в абстрактный лимит порта, а в скорость, с которой освобождаются занятые TIME_WAIT-соединения к этому конкретному адресу.

Другие реальные пределы: дескрипторы, память, conntrack, NAT

Даже разобравшись с портами, полезно держать в голове, что именно раньше даст сбой на практике:

Отдельно стоит случай, когда ваш сервер выходит наружу не напрямую, а через NAT (например, все контейнеры на хосте используют один и тот же внешний IP через SNAT, или весь дата-центр отдаёт наружу через шлюз с ограниченным пулом публичных адресов). В этой ситуации настоящий потолок в районе 64 тысяч портов на пару (внешний IP, направление) — уже не миф, а буквальная реальность: NAT-устройство обязано транслировать каждое исходящее соединение в уникальный внешний порт для данного удалённого адреса, и если внешних IP мало, а направление одно, вы упрётесь именно в эфемерный диапазон на уровне NAT, причём раньше, чем в любой из лимитов на самом сервере. Это отдельно разбирается в материале про то, как один клиент открыл шестьдесят тысяч соединений и убил NAT — механика та же, что и с обычным TIME_WAIT, только упор происходит на уровне трансляции адресов, а не на конечном сервере.

Таблица conntrack заслуживает отдельного внимания: на многих дистрибутивах значение nf_conntrack_max по умолчанию исторически тоже стоит в районе 65536 — это совпадение с числом портов чисто историческое, значения независимы и настраиваются отдельно. Если у вас включён netfilter (а он включён почти всегда, как только в игру вступают Docker, iptables или nftables), переполнение именно этой таблицы часто наступает раньше, чем исчерпание портов. Подробный разбор — в материале о том, как переполняется таблица conntrack и соединения начинают рваться.

Как посчитать свой реальный потолок исходящих соединений

Абстрактной «единой цифры» не существует — потолок зависит от направления трафика (одно направление или много) и от того, какой ресурс кончится первым на вашей конкретной машине. Порядок проверки:

1. Диапазон эфемерных портов — актуален только для соединений к одному и тому же удалённому адресу:

cat /proc/sys/net/ipv4/ip_local_port_range

Ширина диапазона — это верхняя граница числа одновременных соединений к ОДНОМУ адресу с ОДНОГО локального IP, при условии что TIME_WAIT не съедает их быстрее, чем они закрываются.

1. tcp_tw_reuse — позволяет ядру повторно использовать сокет в TIME_WAIT для нового исходящего соединения при определённых условиях, что ослабляет упор в TIME_WAIT для одного направления:

sysctl net.ipv4.tcp_tw_reuse

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

1. Лимит дескрипторов процесса и системы:

ulimit -n
cat /proc/sys/fs/file-max

Для сервисов, поднятых через systemd, лимит процесса дополнительно проверьте в unit-файле (LimitNOFILE=), так как ulimit в интерактивной сессии может отличаться от лимита демона.

1. Размер и заполненность таблицы conntrack, если между сервером и внешним миром есть netfilter/NAT:

sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count

1. Фактическая картина по соединениям прямо сейчас:

ss -s
ss -tan state established | wc -l
ss -tan state time-wait | wc -l

1. Число уникальных удалённых адресов, если сомневаетесь, одно у вас направление или много:

ss -tan state established | awk '{print $5}' | cut -d: -f1 | sort -u | wc -l

Если это число большое — вы в сценарии «много направлений», где эфемерный диапазон одного локального порта не является лимитирующим фактором, и внимание нужно сместить на дескрипторы, память и conntrack.

Если после всех проверок именно эфемерный диапазон на одно направление оказался узким местом, а расширить его через tcp_tw_reuse и сокращение tcp_fin_timeout недостаточно, рабочий вариант — добавить серверу дополнительные локальные IP-адреса и явно биндить исходящие соединения на разные из них (через bind() перед connect() в приложении или через настройки исходящего IP в клиентской библиотеке). Каждый дополнительный локальный IP даёт свой собственный независимый эфемерный диапазон для того же удалённого адреса — де-факто умножая доступный пул портов на число IP.

Частые вопросы