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

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

Сокеты, соединенияПравить

Имеется викиучебник по теме «TCP/IP»

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

Номера портовПравить

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

Номера портов	Категория	Описание
0—1023	Общеизвестные порты	Номера портов назначены IANA и на большинстве систем могут быть использованы исключительно процессами системы (или пользователя root) или прикладными программами, запущенными привилегированными пользователями. Не должны использоваться^[1] без регистрации IANA. Процедура регистрации определена в разделе 19.9 RFC 4340 (англ.).
1024—49151	Зарегистрированные порты	Номера портов включены в каталог IANA и на большинстве систем могут быть использованы процессами обычных пользователей или программами, запущенными обычными пользователями. Не должны использоваться^[1] без регистрации IANA. Процедура регистрации определена в разделе 19.9 RFC 4340.
49152—65535	Динамические порты	Предназначены для временного использования (например, для тестирования приложений до регистрации IANA), а также в качестве клиентских (используемых для частных служб внутри закрытых сетей). Эти порты не могут быть зарегистрированы^[2].

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

Вопросы унификации соответствия сетевых служб номерам сокетов (портов) поднимались в 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:\Windows\services
Windows NT/XP: C:\Windows\system32\drivers\etc\services
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 на порт проблемной службы для проверки её отклика.

См. такжеПравить

ПримечанияПравить

↑ ¹ ² Термин не должны в данном контексте используется в значении определения SHOULD NOT, данного в RFC 2119 (англ.):

«НЕ ДОЛЖЕН» или «НЕ РЕКОМЕНДУЕТСЯ» означает, что при определённых обстоятельствах возможны отдельные случаи, обусловленные вескими причинами, когда нарушение указанных рекомендаций приемлемо или даже предпочтительно, но такие причины и обстоятельства должны быть понятны и тщательно взвешены, прежде чем нарушить рекомендации, помеченные данной фразой.

Оригинальный текст (англ.)[показатьскрыть]

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
↑ Термин не могут в данном контексте используется в значении определения MUST NOT, данного в RFC 2119 (англ.):

«НЕ МОЖЕТ» обозначает, что установлен абсолютный запрет.

Оригинальный текст (англ.)[показатьскрыть]

MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

СсылкиПравить

Актуальный список номеров портов // IANA (англ.)
RFC 322 (англ.) Well Known Socket Numbers
RFC 349 (англ.) Proposed Standard Socket Numbers (отменён RFC 433)
RFC 433 (англ.) Socket Number List (отменён RFC 503)
RFC 503 (англ.) Socket Number List (отменён RFC 739)
RFC 739 (англ.) ASSIGNED NUMBERS (первый список присвоенных номеров, был заменён рядом RFCs, последний из которых RFC 1700)
RFC 768 (англ.) User Datagram Protocol
RFC 793 (англ.) TRANSMISSION CONTROL PROTOCOL
RFC 1700 (англ.) ASSIGNED NUMBERS (последний список присвоенных номеров, отменён RFC 3232)
RFC 3232 (англ.) Assigned Numbers: RFC 1700 is Replaced by an On-line Database
RFC 4340 (англ.) Datagram Congestion Control Protocol (DCCP) — PROPOSED STANDARD

[SHOULD_NOT-1] ¹ ² Термин не должны в данном контексте используется в значении определения SHOULD NOT, данного в RFC 2119 (англ.):

«НЕ ДОЛЖЕН» или «НЕ РЕКОМЕНДУЕТСЯ» означает, что при определённых обстоятельствах возможны отдельные случаи, обусловленные вескими причинами, когда нарушение указанных рекомендаций приемлемо или даже предпочтительно, но такие причины и обстоятельства должны быть понятны и тщательно взвешены, прежде чем нарушить рекомендации, помеченные данной фразой.

Оригинальный текст (англ.)[показатьскрыть]

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

[2] Термин не могут в данном контексте используется в значении определения MUST NOT, данного в RFC 2119 (англ.):

«НЕ МОЖЕТ» обозначает, что установлен абсолютный запрет.

Оригинальный текст (англ.)[показатьскрыть]

MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

[1]

[2]