Linux API. Исчерпывающее руководство

Часть общеизвестных номеров портов строго привязаны к определенным приложениям (также известным как сервисы). Например, демон ssh (защищенная командная оболочка) использует общеизвестный порт 22, а протоколу HTTP, через который взаимодействуют веб-серверы и браузеры, назначен номер 80. Распределением портов в диапазоне от 0 до 1023 занимается Администрация адресного пространства Интернет (англ. Internet Assigned Numbers Authority, IANA, http://www.iana.org/). Назначение такого номера основывается на одобренной сетевой спецификации (обычно в виде документа RFC).

IANA также ведет учет зарегистрированных портов, выделяемых разработчикам приложений с соблюдением менее строгих правил (это значит, что программа не должна гарантировать доступность указанных портов для выполнения заявленных задач). Диапазон зарегистрированных портов, которыми заведует IANA, представлен номерами с 1024 по 41 951 (не все номера в данном диапазоне зарегистрированы).

Актуальный список общеизвестных и зарегистрированных номеров портов находится на https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.

В большинстве реализаций TCP/IP (в том числе и в Linux) номера портов в диапазоне от 0 до 1023 являются привилегированными — то есть только привилегированные процессы (CAP_NET_BIND_SERVICE) могут подключаться к этим портам. Данное обстоятельство не дает обычному пользователю написать программу, которая, например, подменяет демон ssh, чтобы перехватить пароли (иногда привилегированные порты называют зарезервированными).

Один и тот же порт можно использовать отдельно в TCP и UDP, однако на практике общеизвестные номера портов обычно назначают сразу обоим протоколам, даже если сервис работает только по одному из них (часто так и происходит). Это позволяет избежать путаницы с назначением портов в разных протоколах.

Динамические порты

Если приложение само не выберет определенный номер порта (то есть когда сокет не привязывается к конкретному порту с помощью bind()), то протоколы TCP и UDP назначат ему временный динамический порт. В данном случае приложение (обычно клиент) не заботит номер порта, который оно использует, однако порт все же должен быть назначен: таким образом транспортные протоколы смогут идентифицировать конечные точки взаимодействия. Это требуется и для того, чтобы удаленная программа на другом конце канала знала, как именно ей взаимодействовать с приложением. Протоколы TCP и UDP также назначают динамический порт при попытке привязать сокет к порту с номером 0.

С точки зрения организации IANA номера в диапазоне с 49 152 по 65 535 являются динамическими или приватными; они могут применяться локальными приложениями и назначаться в качестве динамических портов. Однако в некоторых системах для таких портов выделены другие диапазоны. В Linux этот диапазон определяется двумя номерами, содержащимися в файле /proc/sys/net/ipv4/ip_local_port_range (при желании их можно поменять).

54.6.2. Протокол пользовательских датаграмм (UDP)

UDP привносит в протокол IP ровно две возможности: номера портов и контрольные суммы для данных, которые позволяют обнаруживать ошибки в переданной информации.

Как и IP, протокол UDP не поддерживает соединения и является в такой же степени ненадежным. Если приложению, работающему поверх UDP, требуется некая надежность, то оно должно реализовать ее самостоятельно. Но, несмотря на это, протокол UDP иногда оказывается более предпочтительным по сравнению с TCP; подробную информацию по теме см. в разделе 57.12.

Контрольные суммы, применяемые в UDP и TCP, имеют длину всего 16 бит и являются дополнительным средством, которое может не обнаружить ошибки определенного типа. Следовательно, они не обеспечивают абсолютно надежного обнаружения ошибок. Нагруженные интернет-серверы сталкиваются с одной необнаруженной ошибкой передачи данных в среднем раз в несколько дней ([Stone & Partridge, 2000]). Приложения, нуждающиеся в более жестком контроле целостности данных, могут использовать протокол уровня защищенных сокетов (англ. Secure Sockets Layer, SSL), обеспечивающий не только защищенное взаимодействие, но и более тщательную проверку на ошибки. Одним из вариантов также является реализация собственного механизма мониторинга ошибок.

Выбор размера UDP-датаграмм, позволяющего избежать фрагментации на уровне IP

В разделе 54.4 мы описали механизм фрагментации в протоколе IP и отметили, что обычно его лучше избегать. Протокол TCP делает это автоматически, тогда как в UDP для фрагментации достаточно передать датаграмму, чей размер превышает значение MTU на локальном канальном уровне.