Выбрать главу

Диаграмма состояний SCRIPT

Порядок работы SCRIPT при установлении и завершении ассоциаций может быть проиллюстрирован диаграммой состояний (рис. 2.8).

Рис. 2.8. Диаграмма состояний SCRIPT

Как и на рис. 2.4, переходы из одного состояния в другое регулируются правилами SCRIPT и определяются текущим состоянием и порцией данных, полученной в этом состоянии. Например, если приложение выполняет активное открытие в состоянии CLOSED (Закрыто), SCRIPT отправляет пакет INIT и переходит в состояние COOKIE-WAIT (Ожидание cookie). Если затем SCRIPT получает пакет INIT-ACK, он отправляет пакет COOKIE-ECHO и новым состоянием становится COOKIE-ECHOED (Cookie отправлен обратно). Если после этого SCRIPT принимает COOKIE ACK, он переходит в состояние ESTABLISHED (Соединение установлено). В этом состоянии осуществляется передача основного объема данных. Порции данных могут передаваться совместно с пакетами COOKIE ECHO и COOKIE ACK.

Две стрелки из состояния ESTABLISHED на рис. 2.8 соответствуют двум сценариям завершения ассоциации. Если приложение вызывает функцию close до получения пакета SHUTDOWN (активное закрытие), переход осуществляется в состояние SHUTDOWN-PENDING (Ожидание завершения). Если же приложение получает пакет SHUTDOWN, находясь в состоянии ESTABLISHED (пассивное закрытие), переход осуществляется в состояние SHUTDOWN-RECEIVED (Получен сигнал о завершении).

Обмен пакетами

На рис. 2.9 показан реальный обмен пакетами для ассоциации SCRIPT. Рисунок включает установление ассоциации, передачу данных и завершение ассоциации. Мы также показываем состояния SCRIPT, через которые проходит каждый из узлов.

Рис. 2.9. Обмен пакетами для ассоциации SCRIPT

В этом примере первая порция данных включается клиентом в COOKIE ECHO, а сервер включает данные в порцию COOKIE ACK. В общем случае в пакет COOKIE ECHO может включаться и несколько порций данных, если приложение использует интерфейс типа «один-ко-многим» (о разных типах интерфейсов речь пойдет в разделе 9.2).

Блок информации, передаваемый в пакете SCRIPT, называется порцией (chunk). Порция информации самодостаточна, она включает сведения о типе данных, флаги и поле длины. Этот подход облегчает упаковку нескольких порций в один исходящий пакет (подробнее об упаковке порций и нормальном режиме передачи данных рассказывается в главе 5 [117]).

Параметры SCRIPT

SCTP использует параметры для облегчения использования дополнительных возможностей. Функции SCRIPT могут расширяться добавлением новых типов порций или новых параметров. При этом стандартные реализации SCRIPT имеют возможность сообщать о неизвестных параметрах и порциях данных. Старшие два бита пространства параметров и пространства порций определяют, что именно должен сделать получатель SCRIPT с неизвестным параметром или порцией (подробнее см. в разделе 3.1 [117]).

В настоящий момент разрабатываются два расширения SCRIPT:

1. Динамическое расширение адресов, позволяющее взаимодействующим узлам добавлять и удалять IP-адреса из существующей ассоциации.

2. Поддержка частичной надежности, позволяющая взаимодействующим узлам по указанию от приложения ограничивать повторную передачу данных. Если сообщение становится слишком старым (это решает приложение), оно пропускается, и никаких попыток отправить его еще раз не делается. Это означает, что доставка всех данных адресату уже не гарантируется.

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

В любой момент времени каждый транспортный протокол (UDP, TCP, SCRIPT) может использоваться несколькими процессами. Все три протокола различают эти процессы при помощи 16-разрядных целых чисел — номеров портов (port numbers).

Когда клиент хочет соединиться с сервером, клиент должен идентифицировать этот сервер. Для TCP, UDP и SCRIPT определена группа заранее известных портов (well-known ports) для идентификации известных служб. Например, каждая реализация TCP/IP, поддерживающая FTP, присваивает заранее известный порт 21 (десятичный) серверу FTP. Серверам TFTP (Trivial File Transfer Protocol — упрощенный протокол передачи файлов) присваивается порт UDP 69.

С другой стороны, клиенты используют динамически назначаемые, или эфемерные (ephemeral) порты, то есть порты с непродолжительным временем жизни. Эти номера портов обычно присваиваются клиенту автоматически протоколами UDP или TCP. Клиенту обычно не важно фактическое значение динамически назначаемого порта; клиент лишь должен быть уверен, что динамически назначаемый порт является уникальным на клиентском узле. Реализации транспортного уровня гарантируют такую уникальность.

IANA (Internet Assigned Numbers Authority — агентство по выделению имен и уникальных параметров протоколов Интернета) ведет список назначенных номеров портов. Раньше они публиковались в документах RFC; последним в этой серии был RFC 1700 [103]. В документе RFC 3232 [102] указан адрес базы данных, заменившей RFC 1700: http://www.iana.org/. Номера портов делятся на три диапазона.

1. Заранее известные порты: от 0 до 1023. Эти номера портов управляются и присваиваются агентством IANA. Когда это возможно, один и тот же номер порта присваивается данному сервису и для TCP, и для UDP. Например, порт 80 присваивается веб-серверу для обоих протоколов, хотя в настоящее время все реализации используют только TCP.

ПРИМЕЧАНИЕ

Когда веб-серверу был назначен порт 80, протокол SCRIPT еще не существовал. Новые порты назначаются всем трем протоколам, и в RFC 2960 отмечено, что все существующие номера портов TCP могут использоваться теми же службами, работающими по протоколу SCRIPT.

2. Зарегистрированные порты: от 1024 до 49 151. Они не управляются IANA, но IANA регистрирует и составляет списки использования этих портов для удобства потребителей. Когда это возможно, один и тот же порт выделяется одной и той же службе и для TCP, и для UDP. Например, порты с номерами от 6000 до 6063 присвоены серверу X Window для обоих протоколов, хотя в настоящее время все реализации используют только TCP. Верхний предел 49 151 для этих портов был установлен для того, чтобы оставить часть диапазона адресов для динамических портов. В документе RFC 1700 [103] верхний предел был 65 535.

3. Динамические, или частные порты: от 49 152 до 65 535. IANA ничего не говорит об этих портах. Эти порты мы иногда называем эфемерными. (Магическое число 49 152 составляет три четверти от 65 536.)

Разделение портов на диапазоны и общее распределение номеров портов показано на рис. 2.10.

Рис. 2.10. Распределение номеров портов

На этом рисунке мы отмечаем следующие моменты:

■ В системах Unix имеется понятие зарезервированного порта (reserved port), и это порт с номером меньше 1024. Эти порты может присвоить сокету только процесс, обладающий соответствующими привилегиями. Все заранее известные порты IANA являются зарезервированными портами; следовательно, сервер, желающий использовать этот порт (такой, как сервер FTP), должен обладать правами привилегированного пользователя.

■ Исторически сложилось так, что Беркли-реализации (начиная с 4.3BSD) позволяют динамически выделять порты в диапазоне от 1024 до 5000. Это было хорошо в начале 80-х, когда серверы не могли обрабатывать много клиентов одновременно, но сегодня можно легко найти сервер, поддерживающий более 3977 клиентов в любой момент времени. Поэтому некоторые системы выделяют динамически назначаемые порты по-другому, либо из диапазона, определенного IANA, либо из еще более широкого диапазона (например, Solaris, как показано на рис. 2.6), чтобы предоставить больше динамически назначаемых портов.