Сетевые сервисы

Взаимодействие компьютеров между собой, а также с другим активным сетевым оборудованием, в TCP/IP-сетях организовано на основе использования сетевых служб, которые обеспечиваются специальными процессами сетевой операционной системы (ОС) — демонами в UNIX-подобных ОС, службами в ОС семейства Windows и т. п. Примерами сетевых сервисов являются веб-серверы (в т.ч. сайты всемирной паутины), электронная почта, FTP-серверы для обмена файлами, приложения IP-телефонии и многое другое.

Сокеты, соединения

Специальные процессы операционной системы (демоны, службы) создают «слушающий» сокет и «привязывают» его к определённому порту (пассивное открытие соединения), обеспечивая тем самым возможность другим компьютерам обратиться к данной службе. Клиентская программа или процесс создаёт запрос на открытие сокета с указанием IP-адреса и порта сервера, в результате чего устанавливается соединение, позволяющее взаимодействовать двум компьютерам с использованием соответствующего сетевого протокола прикладного уровня.

Номера портов

Номер порта для «привязки» службы выбирается в зависимости от его функционального назначения. За присвоение номеров портов определённым сетевым службам отвечает IANA. Номера портов находятся в диапазоне 0—65535 и разделены на 3 категории:

История регулирования соответствия

Вопросы унификации соответствия сетевых служб номерам сокетов (портов) поднимались в RFC 322 и RFC 349, первые попытки регулирования были предприняты Джоном Постелом в RFC 433 и RFC 503.

В марте 1990 года (см. RFC 1060) функция регулирования соответствия сетевых служб номерам портов была передана специальной организации — IANA, которая актуализировала список соответствия выпуском документов RFC «Assigned Numbers» (под номерами 739, 750, 755, 758, 762, 770, 776, 790, 820, 870, 900, 923, 943, 960, 990, 1010, 1060, 1340, 1700). Значительную часть этих документов готовил Джон Постел.

С января 2002 года (см. RFC 3232) IANA публикует актуальный список соответствия на своём сайте (без закрепления в RFC): http://www.iana.org/assignments/port-numbers.

Локальная копия списка

Локальная копия списка входит в установочный пакет сетевых операционных систем. Файл локальной копии списка обычно называется services и в различных операционных системах «лежит» в разных местах:

Windows 98/ME C:Windowsservices Windows NT/XP C:Windowssystem32driversetcservices UNIX-подобные ОС /etc/services

Состояние сетевых служб операционной системы

В большинстве операционных систем можно посмотреть состояние сетевых служб при помощи команды (утилиты)

netstat -an

В ОС семейства Windows результат работы этой команды выглядит примерно так:

Активные подключения Имя Локальный адрес Внешний адрес Состояние TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 127.0.0.1:1026 0.0.0.0:0 LISTENING TCP 127.0.0.1:12025 0.0.0.0:0 LISTENING TCP 127.0.0.1:12080 0.0.0.0:0 LISTENING TCP 127.0.0.1:12110 0.0.0.0:0 LISTENING TCP 127.0.0.1:12119 0.0.0.0:0 LISTENING TCP 127.0.0.1:12143 0.0.0.0:0 LISTENING TCP 192.168.0.16:139 0.0.0.0:0 LISTENING TCP 192.168.0.16:1572 213.180.204.20:80 CLOSE_WAIT TCP 192.168.0.16:1573 213.180.204.35:80 ESTABLISHED UDP 0.0.0.0:445 *:* UDP 0.0.0.0:500 *:* UDP 0.0.0.0:1025 *:* UDP 0.0.0.0:1056 *:* UDP 0.0.0.0:1057 *:* UDP 0.0.0.0:1066 *:* UDP 0.0.0.0:4500 *:* UDP 127.0.0.1:123 *:* UDP 127.0.0.1:1900 *:* UDP 192.168.0.16:123 *:* UDP 192.168.0.16:137 *:* UDP 192.168.0.16:138 *:* UDP 192.168.0.16:1900 *:*

В UNIX-подобных ОС результат работы команды netstat -an имеет примерно такой вид:

Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:199 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:2601 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:2604 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:2605 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:13 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:179 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN tcp 0 0 10.0.0.254:1723 10.0.0.243:2441 ESTABLISHED tcp 0 0 192.168.19.34:179 192.168.19.33:33793 ESTABLISHED tcp 1 0 192.168.18.250:37 192.168.18.243:3723 CLOSE_WAIT tcp 0 0 10.0.0.254:1723 10.0.0.218:1066 ESTABLISHED tcp 1 0 192.168.18.250:37 192.168.18.243:2371 CLOSE_WAIT tcp 0 0 10.0.0.254:1723 10.0.0.201:4346 ESTABLISHED tcp 0 0 10.0.0.254:1723 10.0.0.30:2965 ESTABLISHED tcp 0 48 192.168.19.34:22 192.168.18.18:43645 ESTABLISHED tcp 0 0 10.0.0.254:38562 10.0.0.243:22 ESTABLISHED tcp 0 0 10.50.1.254:1723 10.50.1.2:57355 ESTABLISHED tcp 0 0 10.50.0.254:1723 10.50.0.174:1090 ESTABLISHED tcp 0 0 192.168.10.254:1723 192.168.13.104:65535 ESTABLISHED tcp 0 0 10.0.0.254:1723 10.0.0.144:65535 ESTABLISHED tcp 0 0 10.0.0.254:1723 10.0.0.169:2607 ESTABLISHED tcp 0 0 10.0.0.254:1723 10.0.0.205:1034 ESTABLISHED udp 0 0 0.0.0.0:1812 0.0.0.0:* udp 0 0 0.0.0.0:1813 0.0.0.0:* udp 0 0 0.0.0.0:161 0.0.0.0:* udp 0 0 0.0.0.0:323 0.0.0.0:* udp 0 0 0.0.0.0:123 0.0.0.0:* raw 0 0 192.168.10.254:47 192.168.13.104:* 1 raw 0 0 10.0.0.254:47 10.0.0.120:* 1 raw 0 0 10.10.204.20:47 10.10.16.110:* 1 raw 0 0 192.168.10.254:47 192.168.11.72:* 1 raw 0 0 10.0.0.254:47 10.0.0.144:* 1 raw 0 0 10.0.0.254:47 10.0.0.205:* 1 raw 0 0 10.50.0.254:47 10.50.0.174:* 1 raw 0 0 10.0.0.254:47 10.0.0.170:* 1 raw 0 0 10.0.0.254:47 10.0.0.179:* 1

Состояние (State) LISTEN (LISTENING) показывает пассивно открытые соединения («слушающие» сокеты). Именно они и предоставляют сетевые службы. ESTABLISHED — это установленные соединения, то есть сетевые службы в процессе их использования.

Проверка доступности сетевых служб

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

Одно из самых удобных средств — команда (утилита) tcptraceroute (разновидность traceroute), которая использует TCP-пакеты открытия соединения (SYN|ACK) с указанным сервисом (по умолчанию — web-сервер, порт 80) интересующего хоста и показывает информацию о времени прохождения данного вида TCP-пакетов через маршрутизаторы, а также информацию о доступности службы на интересующем хосте, либо, в случае проблем с доставкой пакетов — в каком месте пути они возникли.

В качестве альтернативы можно использовать отдельно

traceroute для диагностики маршрута доставки пакетов (недостаток — использование UDP-пакетов для диагностики) и
telnet или netcat на порт проблемной службы для проверки её отклика.