Сетевой порт — это "точка входа" с номером от 0 до 65535, по которому операционная система передаёт пришедшие данные нужной службе или программе. IP-адрес указывает устройство, а порт — получателя внутри него. TCP обеспечивает передачу упорядоченного потока данных с подтверждениями и повторной отправкой потерянного; UDP передаёт отдельные сообщения без этих механизмов. Для сервера важно знать и номер порта, и протокол: открыть 443/TCP и 443/UDP — два разных действия.
Что такое сетевой порт
Порт — логический адрес службы, а не отдельная деталь сервера. В этой статье речь именно о таких портах, а не о физических разъёмах RJ-45 или SFP.
Удобная аналогия — многоквартирный дом. IP-адрес помогает найти дом, номер порта — нужную квартиру. Веб-сервер может принимать обращения на порту 443, служба SSH — на 22, а база MySQL — на 3306. Устройство одно, получатели разные.
Чтобы принимать обращения, программа привязывается к локальному адресу и порту. Про TCP-сервер говорят, что он «слушает порт»: ожидает входящие соединения. UDP-служба принимает датаграммы на привязанном порту, хотя соединения в смысле TCP не устанавливает.
IP-адрес, порт и сокет
Запись 192.0.2.10:443 объединяет IP-адрес и номер порта. Так обозначают конечную точку обмена; в терминологии TCP комбинацию адреса и порта называют сокетом. В программировании сокетом также называют объект, через который приложение работает с сетью.
У соединения есть две стороны. Допустим, браузер обращается к сайту:
- сервер принимает TCP-соединения на
192.0.2.10:443; - компьютер пользователя получает локальную точку
198.51.100.20:53124; - ответы сервера возвращаются на адрес пользователя и порт 53124.
Номер 53124 здесь выбран для примера: исходный порт обычно назначает операционная система. Клиенту не нужно открывать у себя службу на 443, чтобы читать сайт по HTTPS.
TCP-соединение определяется парой конечных точек: адресом и портом каждой стороны. Один серверный порт обслуживает множество клиентов: различаются их адреса или исходные порты.
Номер не закрепляет программу навсегда: веб-сервер можно перенести с 443 на 8443. Но клиент должен знать и адрес обращения, и протокол приложения.
Сколько всего портов и какие диапазоны
Под номер порта отведено 16 бит. Это 65 536 значений для TCP и столько же для UDP, от 0 до 65535 включительно. Порт 0 зарезервирован и используется с существенными ограничениями: рассчитывать на него как на обычный порт службы не следует, "слушать" его протоколом TCP не получится.
В реестре IANA, по правилам RFC 6335, выделены три диапазона:
- 0–1023 — системные порты. Здесь находятся многие общеизвестные службы: SSH, DNS, HTTP, HTTPS.
- 1024–49151 — пользовательские, часто называемые зарегистрированными. Номера из этого диапазона регистрируют для приложений; например, 3306 связан с MySQL. При этом зарегистрирован не каждый номер диапазона.
- 49152–65535 — динамические и частные порты. IANA не закрепляет их за конкретными службами. Они подходят, в частности, для временных клиентских точек обмена.
Диапазон временных портов зависит от операционной системы и настроек. Высокий номер не запрещает использовать его для серверной службы.
Регистрация также не подтверждает безопасность трафика. Если в журнале указан порт 443, это ещё не доказывает, что по нему работает обычный сайт, соединение заслуживает доверия и использует SSL для шифрования.
Что такое TCP и UDP
TCP и UDP — транспортные протоколы. В модели OSI они относятся к четвёртому, транспортному уровню; в стеке TCP/IP — к транспортному уровню над IP. Их задача — обеспечить обмен между приложениями на разных устройствах.
IP отвечает за передачу пакетов между узлами сети. TCP или UDP добавляет порты отправителя и получателя, а дальше их подходы расходятся. Устройства второго и третьего уровней решают другие задачи: передачу внутри сети и маршрутизацию между сетями. Подробнее это разобрано в статье Сервер Молл об уровнях коммутаторов L1, L2 и L3.
Как работает TCP: соединение и подтверждения
TCP — протокол управления передачей. Пока соединение работоспособно, он передаёт приложению поток байтов в исходной последовательности.
Обычное установление соединения проходит в три шага:
- SYN. Клиент запрашивает соединение и сообщает начальный номер последовательности.
- SYN-ACK. Сервер подтверждает запрос и сообщает свой начальный номер.
- ACK. Клиент подтверждает ответ сервера. После этого стороны могут обмениваться данными по установленному соединению.
Эту процедуру называют трёхсторонним рукопожатием. Механизм описан в RFC 9293 — спецификации TCP, которая заменила RFC 793.
При передаче TCP отслеживает номера байтов в сегментах, принимает подтверждения и повторно отправляет потерянные данные. Управление потоком не даёт перегрузить получателя, а управление перегрузкой помогает подстроить отправку под состояние сети.
За это приходится платить временем: соединение нужно установить, а при потере сегмента — дождаться восстановления пропуска. Следующие байты в том же потоке нельзя передать приложению раньше недостающих. Такое ожидание называют блокировкой очереди.
«Гарантия доставки» не означает, что TCP справится с отключённым кабелем или бесконечно недоступным сервером, это значит что при доставке пакета до сокета клиент получит подтверждение (и сможет отправить повторно данные если они не дошли). Соединение может оборваться. При этом подтверждение TCP не означает, что приложение обработало запрос или сохранило файл: нужен его собственный ответ.
Как работает UDP
UDP — протокол пользовательских датаграмм. Датаграмма представляет собой отдельное сообщение: приложение отправляет его указанному адресу и порту без предварительного рукопожатия UDP.
В RFC 768 — спецификации UDP определён короткий заголовок из четырёх полей: порт отправителя, порт получателя, длина и контрольная сумма. Его размер — 8 байт. Заголовок TCP занимает от 20 до 60 байт без учёта заголовка IP.
UDP сам по себе:
- не подтверждает получение сообщений;
- не повторяет потерянные датаграммы;
- не восстанавливает исходный порядок;
- не устраняет дубликаты и не управляет перегрузкой.
Поэтому приложение должно учитывать потери и перестановку сообщений. Если нужны подтверждения или повторная отправка, их реализуют уже выше UDP, как правило приложением. Контрольная сумма помогает обнаруживать повреждение данных, но не заменяет контроль доставки.
При этом это не значит что UDP плохой протокол и TCP лучше. UDP менее требователен к каналу и расходует меньше ресурсов. Также он хорошо подходит для медиа-трафика, например в разговоре запоздавший фрагмент иногда выгоднее пропустить. При передаче документа потеря части файла недопустима. Выбор транспорта зависит от этих требований.
Чем TCP отличается от UDP
TCP берёт на себя восстановление упорядоченного потока. UDP оставляет приложению отдельные сообщения и меньше встроенных механизмов. У UDP ниже накладные расходы на заголовок и нет собственного установления соединения, но скорость канала от этого не увеличивается.
| Критерий | TCP | UDP |
|---|---|---|
| Соединение | Устанавливается перед обычным обменом | У протокола нет установления соединения |
| Доставка | Подтверждения и обнаружение потерь; при невозможности продолжать соединение завершается ошибкой | Встроенного подтверждения доставки нет |
| Порядок | Приложению передаётся упорядоченный поток байтов | Порядок датаграмм не восстанавливается |
| Повторная передача | Есть на уровне TCP | Если нужна, её обеспечивает приложение или протокол поверх UDP |
| Заголовок | 20–60 байт | 8 байт |
| Задержка | Есть затраты на соединение и ожидание пропущенных данных | Нет этих механизмов самого UDP; итог зависит от приложения и сети |
| Примеры | SSH, HTTP/1.1, HTTP/2, SMTP | Обычные DNS-запросы, многие голосовые и игровые потоки, транспорт для QUIC |
Фраза «UDP всегда быстрее TCP» вводит в заблуждение. Приложение поверх UDP тоже может устанавливать защищённый сеанс, подтверждать сообщения и повторять потерянное. А плохо организованная отправка способна вызвать перегрузку и увеличить потери.
Некоторые межсетевые экраны и публичные сети строже фильтруют UDP. Это тоже учитывают при выборе транспорта.
TCP или UDP: что используют SSH, DNS и VPN
- SSH использует TCP. Команды и ответы должны приходить без пропусков и в правильном порядке. SFTP работает через SSH и обычно использует тот же TCP-порт 22.
- Обычный DNS использует UDP и TCP. Небольшие запросы и ответы чаще передаются по UDP. TCP нужен, в частности, при повторе запроса после усечённого ответа и для полной передачи зоны. Поддержка TCP для DNS закреплена в RFC 7766.
- OpenVPN поддерживает оба транспорта. В документации OpenVPN рекомендуют UDP, когда сеть его пропускает. TCP внутри TCP-туннеля создаёт два уровня повторной передачи и управления перегрузкой, что при потерях может ухудшать работу. TCP остаётся вариантом для сетей, где UDP недоступен.
- Интернет-телефония и игры часто используют UDP для данных реального времени. При этом авторизация, управление сеансом и загрузка материалов могут идти по TCP. Называть весь сервис исключительно «UDP-приложением» не всегда правильно.
Почему современный HTTPS работает и по UDP
HTTP/1.1 и HTTP/2 используют TCP. HTTP/3 работает через QUIC поверх UDP — это закреплено в RFC 9114.
Здесь нет противоречия: UDP служит основой, а QUIC добавляет защищённое соединение, подтверждения, восстановление потерь и управление перегрузкой. Надёжность обеспечивает протокол поверх UDP, а не сам UDP.
QUIC разделяет обмен на независимые потоки: потеря в одном не обязана останавливать доставку остальных. Внутри затронутого потока пропуск всё равно восстанавливается.
Для HTTPS с HTTP/3 обычно разрешают 443/TCP и 443/UDP. При блокировке UDP клиент может перейти на HTTP поверх TCP. Поэтому работающий сайт ещё не подтверждает доступность HTTP/3.
Популярные порты
Ниже — распространённые назначения по умолчанию. Фактический порт проверяют в конфигурации: привычный номер может использовать другая программа.
| Порт | Служба | Транспорт и назначение |
|---|---|---|
| 20, 21 | FTP | TCP: 21 — управляющее соединение; 20 — исходный порт сервера для данных в классическом активном режиме |
| 22 | SSH, SFTP | TCP: удалённое управление и передача файлов через SSH |
| 25 | SMTP | TCP: прежде всего передача почты между почтовыми серверами |
| 53 | DNS | UDP и TCP: запросы, ответы и служебные операции DNS |
| 80 | HTTP | TCP: обычный HTTP, часто с перенаправлением на HTTPS |
| 110, 143 | POP3, IMAP | TCP: доступ к почте; шифрование зависит от режима и настроек |
| 443 | HTTPS | TCP для HTTP/1.1 и HTTP/2; UDP для HTTP/3 через QUIC |
| 3306 | MySQL | TCP: клиентские подключения к базе данных |
| 3389 | RDP | TCP и UDP: удалённый рабочий стол; использование UDP зависит от режима и условий подключения |
| 8080 | Альтернативный HTTP | TCP: приложения, прокси-серверы и тестовые веб-службы |
За что отвечает порт 443
443 — стандартный порт HTTPS. Браузер использует его для адресов с https://, если номер не указан явно. Транспорт зависит от версии HTTP.
Шифрование обеспечивает TLS, используемый соответствующим протоколом, а не число 443. Если просто перенести на этот номер незащищённую службу, защищённой она не станет. И наоборот: HTTPS может работать на другом порту при правильной настройке сервера и клиента.
Чем 8080 отличается от 80
80 — стандартный порт для адресов с http://. 8080 часто используют как альтернативу: например, когда основной веб-сервер уже занимает 80, а другое приложение должно принимать запросы отдельно.
В адресе http://192.0.2.10:8080 порт указан явно. Если его убрать, браузер обратится к 80, где может работать другой сайт или вообще ничего не слушать.
Приложение на 8080 можно оставить внутри сети, а внешние запросы принимать через HTTPS на 443 и передавать ему. Публиковать внутренний порт тогда не требуется.
Порты 21 и 22: FTP и SFTP
Серверные стойки в центре обработки данных.
Источник: Pexels
Порт 21/TCP относится к управляющему соединению FTP. Для данных протокол использует отдельное соединение: в активном режиме сервер традиционно отправляет их с порта 20 на согласованный порт клиента, а в пассивном клиент подключается к согласованному порту сервера. Поэтому разрешить только 21 иногда недостаточно, и для работы через NAT сервер (и клиент!) могут потребовать отдельной настройки.
22/TCP обычно принимает SSH. Через него работает SFTP — протокол передачи файлов в подсистеме SSH. Это не «FTP на другом порту»: устройство обмена и защита у них различаются.
Обычный FTP не шифрует пароли и файлы; для защиты выбирают SFTP либо FTP с TLS — FTPS.
Для чего нужны порты 25 и 53
25/TCP служит для обмена почтой между серверами. Пользовательские программы часто отправляют почту через 587 или 465. Одного порта 25 для всего почтового сервиса недостаточно.
53 — стандартный порт обычного DNS. Сервер имён должен быть доступен по предусмотренным для его роли транспортам. Если разрешить только 53/UDP, часть небольших запросов будет работать, а операции, требующие TCP, могут завершаться ошибками. Получится неприятная ситуация: «DNS вроде работает», но отдельные обращения не проходят.
Открытые порты: как проверить и закрыть лишние
«Порт открыт» может означать две разные вещи: программа принимает обращения на самом сервере или к ней действительно можно подключиться из нужной сети. Эти условия связаны, но не равны.
Например, служба слушает 443, но межсетевой экран отбрасывает пакеты. Или разрешение настроено, а программа остановлена — трафик некому принять.
Открытый, закрытый и фильтруемый порт
При сетевой проверке обычно различают такие состояния:
- Открытый: служба принимает TCP-соединения или UDP-датаграммы, а проверка получила подтверждающий это ответ.
- Закрытый: устройство доступно, но на выбранной точке нет принимающей службы. Для TCP обычно приходит сброс соединения, для UDP возможен ответ ICMP о недоступном порте.
- Фильтруемый: проверка не может достоверно определить открытость из-за фильтрации. Пакеты могут отбрасываться молча либо возвращать сообщение о запрете.
Само по себе молчание не доказывает, что виноват межсетевой экран: возможны потери, недоступность узла или отсутствие ответа приложения на незнакомый запрос. Особенно это заметно с UDP. Поэтому сканер иногда показывает open|filtered — открытый или фильтруемый, без возможности выбрать один вариант.
Результат зависит и от места проверки. Порт может быть доступен из служебной сети и недоступен из интернета — для административного интерфейса это нормальная, часто желательная схема.
53/TCP и 53/UDP — разные точки приёма. Один номер может одновременно использоваться обоими транспортами. Ошибка «открыли TCP, а программа принимает UDP» не исправляется перезапуском сервера: нужно согласовать протокол в службе и сетевых правилах.
Как посмотреть порты в Linux
Для локального списка удобно использовать ss:
sudo ss -lntup
Команда показывает принимающие TCP- и UDP-сокеты, числовые адреса и порты, а также связанные процессы. Права администратора нужны, чтобы увидеть сведения о процессах других пользователей. В старых системах встречается netstat, но для новой диагностики обычно удобнее ss.
У TCP ожидайте состояние LISTEN. У UDP часто будет UNCONN: отсутствие соединения для него нормально и не означает, что служба выключена.
Смотрите не только на номер, но и на локальный адрес:
127.0.0.1:8080— приём только через локальный интерфейс IPv4;0.0.0.0:8080— привязка ко всем локальным адресам IPv4;[::]:8080— привязка к неопределённому адресу IPv6; приём IPv4 дополнительно зависит от настроек сокета и системы.
Даже привязка ко всем адресам не отменяет сетевую фильтрацию. Для контейнера или виртуальной машины также учитывают сеть окружения и публикацию порта.
Как проверить порт в Windows
Локальные соединения и принимающие точки показывает команда:
netstat -ano
Ключ -a включает прослушиваемые порты, -n оставляет адреса и номера в числовом виде, -o добавляет идентификатор процесса — PID. По нему можно найти программу в диспетчере задач или консоли. У TCP-порта, ожидающего подключения, будет состояние LISTENING; UDP выводится без такого состояния.
Чтобы проверить доступ к конкретному TCP-порту с другого компьютера, в PowerShell используют:
Test-NetConnection -ComputerName 192.0.2.10 -Port 443
Вместо демонстрационного адреса нужно подставить адрес своего сервера. Поле TcpTestSucceeded показывает, удалось ли установить TCP-соединение. Эта команда не проверяет UDP, сертификат HTTPS и работоспособность самого сайта: успешное подключение означает только доступность TCP-точки.
Как проверить доступ снаружи через Nmap
Для выборочной проверки TCP-портов с отдельной машины подходит:
nmap -sT -Pn -p 22,80,443,8080 192.0.2.10
Ключ -sT проверяет TCP-соединение, -Pn пропускает предварительное обнаружение узла, -p задаёт порты. Подставьте адрес своего сервера; чужие системы проверяют с разрешения владельца.
Запуск с компьютера в той же локальной сети не покажет, как сервер виден из интернета. Для проверки публикации нужна машина за пределами проверяемой сети. UDP требует отдельного режима -sU; приведённая TCP-команда о нём ничего не сообщает.
Название службы у сканера может быть взято из справочника по номеру. Оно не доказывает, что на порту работает именно эта программа.
Для разбора самих пакетов используют tcpdump и Wireshark: с ними можно увидеть, уходит ли запрос, приходит ли ответ и на каком этапе прекращается обмен.
Как закрыть ненужный доступ
Способ зависит от того, нужна ли программа вообще. Неиспользуемую службу останавливают и отключают её автоматический запуск. Нужную только самому серверу привязывают к локальному адресу. Для внутренних приложений ограничивают доступ нужными сетями или адресами.
Запрет в межсетевом экране ограничивает обращения, но не останавливает программу. И наоборот: остановка службы не удаляет старое разрешающее правило. После изменений полезно повторить проверку с той стороны сети, для которой менялся доступ.
Если ограничиваете порт удалённого управления, сначала обеспечьте другой рабочий способ подключения. Иначе можно закрыть доступ самому себе и продолжать настройку уже через консоль управления сервером.
Порты и безопасность сервера
Сам номер порта не является уязвимостью. Риск создают доступная служба, её настройки, ошибки в программном обеспечении и слишком широкие права доступа. Поэтому задача администратора — оставить доступными только нужные приложения и только нужным пользователям.
Для публичного сайта обычно требуется внешний доступ к веб-службе. Базу данных, панель управления и удалённый рабочий стол без необходимости наружу не публикуют. К RDP и служебным портам баз данных безопаснее организовать доступ через VPN с проверкой пользователей и ограничениями по роли.
Межсетевой экран и ограничения доступа
Межсетевой экран нужен и на самом сервере, и на границе сети. Правила определяют, кому, куда и по какому протоколу разрешено обращаться. Средства защиты могут дополнительно анализировать приложения и события; соответствующее ПО для информационной безопасности представлено в Сервер Молл.
Для сетевых служб распространены внешние сканирования и подбор паролей. Снижают риск взлома такие вещи, как обновления, ключи или многофакторная проверка там, где они поддерживаются, ограничение источников и попыток входа (fail2ban). Перенос SSH с 22 на высокий порт уменьшает часть автоматического шума от ботов в логах, но не заменяет эти меры.
У UDP есть ещё один характерный риск: открытые службы с большими ответами могут участвовать в отражённых DDoS-атаках. Злоумышленник подставляет адрес жертвы, а сервер отправляет ответы ей. Если ответ существенно больше запроса, возникает усиление. Поэтому, например, рекурсивный DNS ограничивают доверенными клиентами, а частоту запросов и ответов контролируют.
NAT и проброс портов
NAT преобразует сетевые адреса, а в распространённой схеме с совместным использованием публичного IPv4-адреса — ещё и номера портов. Для входящего доступа на маршрутизаторе настраивают проброс: например, обращения к внешнему 443/TCP направляют на 192.168.1.10:443 внутри сети. Сам проброс не запускает службу и не защищает её; отдельно должны выполняться правила фильтрации. При NAT у провайдера одного правила на своём устройстве может быть недостаточно. Подробнее эти задачи разобраны в статье «Что такое маршрутизатор».
Не стоит считать отсутствие проброса универсальной защитой: у сервера может быть другой путь доступа, например публичный IPv6-адрес. Для IPv6 правила межсетевого экрана проверяют отдельно, даже если привычная IPv4-схема работает через NAT.
Частые вопросы
TCP или UDP — что выбрать для своего сервиса?
TCP подходит для упорядоченного потока без пропусков. UDP — для отдельных сообщений, если приложение обрабатывает потери, перестановку и перегрузку или они не являются критичными. В готовой программе используют предусмотренный разработчиком транспорт.
Может ли одна программа слушать несколько портов?
Да. Например, веб-сервер принимает HTTP на 80 и HTTPS на 443. Программа может создавать несколько сокетов для разных адресов, портов и протоколов. Обратная ситуация тоже возможна: один порт обслуживает несколько сайтов через общий веб-сервер, который различает запросы по имени сайта.
Можно ли запустить веб-сервер не на 80-м порту?
Да, например на 8080. Номер указывают в адресе явно либо используют сервер-посредник на стандартном порту. Настройки приложения и сетевые правила должны совпадать. Смена номера не включает шифрование.
Почему порт может быть занят?
Обычно другой процесс уже привязан к тому же адресу, порту и протоколу. Найдите его через ss или netstat и решите, какая служба должна принимать обращения. Одинаковый номер у TCP и UDP сам по себе конфликтом не является.
