ОСиС_2008

высокой скоростью, но без уверенности в том, что они действительно дойдут до принимающей части приложения, тем более в правильном порядке.

Выбор транспортного канала для разрабатываемого сетевого приложения зависит от типа этого приложения. Будем различать следующие типы таких приложений:

1) приложения с передачей файлов. В общем случае такое приложение обслуживает пользователя, находящегося возле клиентского хоста. При этом производится пересылка файлов от серверной части приложения к клиентской части и (или) наоборот. Если размер файла достаточно велик, то прежде чем передавать информацию по транспортному каналу, сервер (клиент) делит файл на части-сообщения. Окончательное использование принятой информации в принимающей части приложения производится только после получения всего файла;

2) потоковые приложения. Принципиальное отличие такого приложения от приложений с передачей файлов — в том, что информация, передаваемая от сервера к клиенту, используется последним по частям, по мере поступления, не дожидаясь завершения приема всей информации. Подобным свойством обладают мультимедийные приложения, выполняющие передачу аудио- и (или) видеоданных в реальном времени. Примером является Интернет-телефония — устная беседа двух пользователей сети Internet, разделенных, возможно, многими тысячами километров. При этом как только любой из пользователей произнесет несколько звуков, эти звуки в закодированном виде сразу же передаются по сети. Затем они достигают приемного хоста и декодируются в нем приложением, становясь доступными для удаленного слушателя;

3) управляющие приложения. Такое сетевое приложение предназначено для сбора информации об удаленном объекте и (или) для оказания воздействия на этот объект с целью изменения его поведения. В качестве такого объекта может выступать технологический процесс, соединенный с хостом, или даже сам хост. Примером такого приложения, выполняющего управление удаленным хостом, является программа rlogin.

Перечисленные группы приложений предъявляют разные требования к транспортным каналам. Приложение с передачей файлов, как правило, очень критично к достоверности передачи данных, но не критично к задержке и к скорости передачи информации в канал. Это обусловлено тем, что при передаче

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

Сдругой стороны, пользователи, обслуживаемые приложением с передачей файлов, вполне допускают некоторый рост задержки. Подобный рост, естественно, приводит к увеличению всего времени реакции приложения на команду пользователя. Поэтому хотя приложение и некритично к величине задержки, ее снижение весьма желательно. Что касается скорости передачи информации

вканал, то она влияет на пользователя приложения с передачей файлов лишь потому, что влияет на величину задержки.

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

Потоковые приложения, выполняющие передачу аудио- и видеоинформации в реальном времени, не критичны к потере некоторой части (до 10 %) своих сообщений. Подобные потери приводят лишь к допустимому ухудшению качества звука или к возникновению небольших искажений на экране. С другой стороны, потоковые приложения весьма критичны к величине задержки и к скорости передачи информации в транспортный канал. Это объясняется тем, что большая задержка в передаче некоторых сообщений приводит к тому, что эти сообщения становятся ненужными («хороша ложка к обеду»). Кроме того, недопустимо какое-либо «торможение» в приеме транспортным каналом сообщений, содержащих аудио- и (или) видеоинформацию реального времени. Подобное замедление передачи неизбежно приведет к существенным искажениям звука и (или) изображения

вприемном хосте.

Сучетом сказанного при разработке мультимедийных потоковых приложений в основном используют транспортные каналы на основе протокола UDP. Напомним, что это датаграммные каналы, не обеспечивающие ни надежную передачу сообщений, ни правильный порядок их приема. С другой стороны, эти каналы имеют сравнительно небольшую задержку при передаче сооб-

щений-датаграмм, а также позволяют приложению передавать информацию в транспортный канал с постоянной скоростью.

Что касается управляющих приложений, то все они требуют от транспортного канала высокой достоверности передачи данных. Требование к задержке зависит от типа приложения. Если такое приложение обслуживает человека-пользователя, то к величине задержки не предъявляются жесткие требования. Если же приложение выполняет управление технологическим процессом, то допустимая величина задержки определяется скоростью изменений, протекающих в управляемом процессе: чем выше скорость, тем допустимая величина задержки меньше.

Если управляющее приложение не предъявляет жестких требований к величине задержки, то в качестве транспортного канала можно использовать TCP-соединение, реализованное в любой сети передачи данных, в том числе и Internet. Если же приложение требует, чтобы величина задержки не превышала предельную заданную величину, то в качестве сети передачи данных приходится использовать высококачественную сеть передачи данных. Для наиболее ответственных управляющих приложений в качестве такой сети могут использоваться выделенные каналы связи.

8.3. Транспортные интерфейсы

8.3.1. Транспортные порты

Транспортный интерфейс образуют системные вызовы, пользуясь которыми серверная и клиентские части сетевого приложения используют транспортные каналы, реализующие транспортный протокол UDP или TCP. С учетом того что точное описание транспортного интерфейса в этих протоколах отсутствует, существует некоторая свобода выбора типа транспортного интерфейса. Прежде чем рассматривать конкретный тип транспортного интерфейса, рассмотрим понятие транспортного порта, существенное для любого транспортного интерфейса.

Транспортный порт — структуры данных, образующие оконечности транспортных каналов, принадлежащие одной части (клиентской или серверной) конкретного приложения. Часто слово «транспортный» опускают, говоря просто «порт». Но с учетом того что термин «порт» имеет и другие значения (вспомним, например, про порты ввода-вывода), такое сокращение следует использовать осторожно.

Подобно другим объектам, управляемым ОС, все транспортные порты, принадлежащие конкретному хосту, пронумерованы, причем раздельно для каждого типа портов (UDP и TCP). Номер порта (UDP или TCP) — 16-битовое число, принимающее значение от 0 до 65535. Первые номера портов от 0 до 1023 зарезервированы за портами серверов распространенных приложений, называемых

стандартными портами.

Некоторые из стандартных UDP-портов:

7 — «эхо» (сообщение, переданное клиентом серверу по сети, пересылается сервером обратно. Используется для анализа работы сети);

11 — список активных пользователей;

17 — цитата дня; 37 — текущее время (пересылается от сервера к клиенту в виде

32-битного числа, содержащего число секунд, прошедших с фиксированной секунды, — нулевая секунда 1 января 1990 года);

53 — сервер доменных имен (рассматривается в подразд. 8.4); 69 — сервер упрощенной передачи файлов TFTP. Некоторые из стандартных TCP-портов:

20— порт FTP-сервера для передачи данных;

21— порт FTP-сервера для передачи управляющей инфор-

мации;

53— сервер доменных имен.

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

Для того чтобы серверная (или клиентская) часть приложения могла получать через свой порт сообщения от удаленной клиентской (или серверной) части, этот порт должен иметь внешний адрес, включающий, кроме номера порта, сетевой адрес того хоста, на котором порт находится. Общепринято использовать в качестве сетевого адреса хоста IP-адрес (Internet Protocol — межсетевой протокол, протокол сети Internet). IP-адрес представляет собой 32-битное (4-байтовое) число, уникальное для каждого хоста сети. Данный адрес принято изображать в виде четырех десятичных чисел, разделенных точками и представляющих значения каждого из байтов, например: 195.120.16.7. Числа IP-адреса, рассматрива-

емые слева направо, последовательно уточняют расположение адресуемого хоста в сети Internet.

Из всех существующих реализаций транспортных интерфейсов наиболее распространены интерфейсы на основе сокетов. Ранее мы уже рассматривали применение сокетов для создания локальных информационных каналов, связывающих процессы, выполняющиеся на одной и той же ЭВМ. Сейчас расширим это представление для связи удаленных частей сетевых приложений.

8.3.2. Интерфейс сокетов UDP-канала

Напомним, что сокет представляет собой окончание информационного канала, состоящее из двух очередей. Сейчас в качестве такого канала мы рассматриваем транспортный UDP-канал. Этот канал состоит из двух удаленных UDP-портов, каждый из которых содержит всего один сокет.

Как и для локального канала, каждый сокет имеет локальное системное имя (номер сокета в хосте), а также может иметь два программных имени: 1) локальное имя сокета, используемое той частью сетевого приложения, которая является «владельцем» этого сокета; 2) внешнее имя сокета, используемое удаленными частями приложения. Напомним, что внешнее имя сокета обычно называют адресом сокета. Как и для локальных каналов, первое из этих имен представляет собой «номер открытого файла». Второе имя должно быть уникальным в пределах всей сети передачи данных. В качестве такого имени (адреса) используется внешнее (сетевое) имя того порта, которому принадлежит данный сокет. Напомним, что внешнее имя порта включает сетевой IP-адрес хоста, а также номер UDP-порта.

Все, что было сказано ранее о создании на основе сокетов локального датаграммного информационного канала, относится и к созданию UDP-канала. При этом следует учесть лишь небольшие изменения:

1)при создании своего сокета (с помощью системного вызова СОЗДАТЬ_СОКЕТ) в качестве коммуникационного домена (это множество имен, к которому принадлежит внешнее имя сокета) следует задать AF_INET — множество имен Internet;

2)в качестве адреса сокета в системных вызовах СВЯЗАТЬ_

СОКЕТ_АДРЕС, ПОСЛАТЬ_ДАТАГРАММУ, ПОЛУЧИТЬ_ДАТА-

ГРАММУ используется пара (IP-адрес хоста, номер порта). Причем

всистемном вызове СВЯЗАТЬ_СОКЕТ_АДРЕС номер порта задает-

ся явно в виде числа (для UDP-порта, принадлежащего серверной части приложения), или этот номер проставляется самой ОС при выполнении данного вызова (для клиентских частей приложения). Никакого отдельного системного вызова для определения номера порта нет. В вызове ПОСЛАТЬ_ДАТАГРАММУ номер порта всегда задается самим приложением. Это или номер стандартного UDP- порта, или номер порта был получен ранее (вместе с IP-адресом в результате приема датаграммы с помощью системного вызова

ПОЛУЧИТЬ_ДАТАГРАММУ).

8.3.3. Интерфейс сокетов TCP-канала

В отличие от UDP-порта, TCP-порт, принадлежащий серверной части приложения, содержит в общем случае не один, а несколько сокетов. Один из них является главным сокетом и используется для приема запросов на создание виртуальных соединений. Остальные сокеты являются окончаниями созданных виртуальных соединений и используются для приема-передачи данных по этим каналам. Таким образом, один и тот же TCP-порт сервера одновременно используется для создания виртуальных соединений и участвует в работе этих соединений. TCP-порт клиента включает всего один сокет, выполняющий роль окончания виртуального соединения.

Для создания главного сокета сервера и сокета клиента используются системные вызовы СОЗДАТЬ_СОКЕТ. Все остальные сокеты сервера создаются во время выполнений системного вызова ПОЛУЧИТЬ_ЗАПРОС. Все, что было сказано ранее о создании на основе сокетов локального виртуального соединения, относится и к созданию TCP-канала. При этом следует учесть лишь небольшие изменения:

1)при создании сокетов с помощью системного вызова СОЗДАТЬ_СОКЕТ в качестве коммуникационного домена следует задать AF_INET — множество имен Internet;

2)в качестве адреса сокета в системных вызовах СВЯЗАТЬ_

СОКЕТ_АДРЕС и СОЕДИНИТЬ_СОКЕТЫ используется пара

(IP-адрес хоста, номер порта). Причем в системном вызове СВЯЗАТЬ_СОКЕТ_АДРЕС номер порта задается явно в виде числа

(для стандартных TCP-портов), или этот номер проставляется самой ОС при выполнении данного вызова. В вызове СОЕДИНИТЬ_СОКЕТЫ номер порта всегда задается самим прило- жением-клиентом как номер стандартного TCP-порта сервера.

8.4. Трансляция имен хостов

Во многих приложениях первоисточником IP-адресов хостов, используемых в качестве обязательных частей адресов UDP- и TCP-портов, является пользователь клиентской части приложения. То есть прежде чем выдать в ОС системные вызовы по созданию и использованию транспортного канала, приложение получает от пользователя сетевое имя того хоста, на котором находится серверная часть приложения. Использование в качестве пользовательского сетевого имени IP-адреса (как и любого другого численного имени) очень неудобно для пользователя. Поэтому в качестве пользовательских сетевых имен хостов принято использовать символьные имена хостов, называемые доменными именами.

Доменное имя хоста — последовательность меток, разделенных точками, которая зарегистрирована в системе доменных имен

DNS (DNS — Domain Name System). Здесь метка — последова-

тельность латинских букв, цифр, других символов, за исключением точки. Например, один из хостов на кафедре КСУП (компьютерные системы в управлении и проектировании) в Томском государственном университете систем управления и радиоэлектроники (ТУСУРе) имеет доменное имя kcup.fet.tusur.ru. В состав этого имени входят метки kcup, fet, tusur, ru. Приведенное доменное имя хоста является «листом» в дереве имен Internet, содержащем доменные имена всех хостов, подключенных к сети Internet. Фрагмент этого дерева приведен на рис. 65.

Структура дерева имен Internet очень похожа на структуру файловой системы. Точно так же вверху дерева находится корень, который, правда, не имеет имени и поэтому в имени хоста отсутствует. На следующем уровне дерева находятся имена доменов верхнего (первого) уровня. Здесь домен — множество имен сети Internet. Перечислим некоторые имена доменов первого уровня:

com — коммерческие организации; edu — образовательные учреждения;

net — основные центры поддержки сети Internet; int — международные организации;

fr — организации, расположенные во Франции; ru — организации, расположенные в России.

Безымянный корень

fet

sapr kcup

Домен

Имя хоста

Рис. 65. Фрагмент дерева доменных имен Internet

Так как домен является множеством, то он может быть разбит на подмножества (поддомены). Например, одним из поддоменов домена ru является tusur.ru. Обратим внимание, что в отличие от имени-пути файла имя домена верхнего уровня (ru) записывается не в левой, а в правой части доменного имени. Аналогично одним из поддоменов tusur.ru является fet.tusur.ru (ФЭТ — один из корпусов ТУСУРа). Домен fet.tusur.ru может иметь свои поддомены, а также хосты, в том числе и kcup.fet.tusur.ru.

Рассмотрим кратко вопрос о том, кто занимается построением дерева имен Internet. Во-первых, данный процесс происходит не стихийно, а организованно. Во-вторых, в этом участвует не одна, а много организаций. Главная из этих организаций — ICANN

(Internet Corporation for Assigned Names and Numbers). Она назна-

чает имена доменов первого и второго уровней, а также утверждает организации, каждая из которых ответственна за свой домен второго уровня. Одной из таких организаций является ТУСУР. Он занимается декомпозицией (детализацией) домена tusur.ru, не отчитываясь за результаты перед вышестоящей организацией.

Имя любого домена, являющегося «потомком» домена tusur.ru, ТУСУР может передать другой организации, которая и будет теперь отвечать за декомпозицию этого домена. Например, имя kcup.fet.tusur.ru передано кафедре КСУП, которая вправе присвоить его одному из своих хостов или использовать его в качестве имени своего домена.

В отличие от IP-адреса хоста, отражающего фактическое подключение этого хоста к сети передачи данных, доменное имя хоста в общем случае таким свойством не обладает. Например, все хосты, имена которых принадлежат домену fet.tusur.ru, подключены или к сети корпуса ФЭТ, или к локальным сетям, являющимся подсетями указанной сети. С другой стороны, хосты, принадлежащие одному и тому же домену net, могут быть расположены в разных концах света.

Размер дерева доменных имен чрезвычайно велик и продолжает быстро увеличиваться. Вспомним, что гораздо меньшее по размеру дерево файловой структуры локальной UNIX-системы не хранится в одном месте этой системы как единое целое. Для системы доменных имен DNS, используемой в условиях сети, распределенный характер тем более важен. При этом распределение дерева имен производится не по устройствам, а по узлам сети.

Каждая программа, называемая сервером DNS, содержит фрагмент дерева доменных имен, представляющий собой верхнюю часть одного из его поддеревьев. При этом для каждого доменного имени сервер DNS содержит соответствующий IP-адрес. Кроме того, каждый сервер DNS содержит IP-адреса нескольких других DNS-серверов, к которым относятся: а) корневой сервер; б) вышестоящий («родительский») DNS-сервер, содержащий «родительский» домен для поддерева данного сервера; в) «дочерние» DNS- серверы, которые содержат декомпозицию нижестоящих доменов данного сервера. Таким образом, все DNS-серверы оказываются связанными в единое дерево, корнем которого является корневой сервер DNS. Листьями данного дерева являются локальные DNSсерверы. Каждый хост «знает» IP-адрес своего локального сервера, так как этот адрес прописывается вручную при настройке ОС. Обычно это самый близкий DNS-сервер, расположенный в той же локальной сети, что и хост.

Перейдем к рассмотрению обслуживания сетевых приложений со стороны DNS-серверов. Любое сетевое приложение (а точнее —

клиентская часть приложения) может стать DNS-клиентом, если включит в состав своей программы специально предназначенную для этого библиотечную функцию (процедуру). В UNIX-системе это функция gethostbyname, имеющая один параметр — указатель на символьную строку, содержащую исходное DNS-имя. Данная функция возвращает значение — указатель на структуру, содержащую список из IP-адресов, соответствующих заданному DNS- имени. Если ни один IP-адрес не найден, то возвращается указатель

NULL.

Программный код функции gethostbyname таков, что он содержит системные вызовы для создания UDP-канала между хостом и UDP-портом номер 53 своего локального сервера, а также для отправки по этому каналу датаграммы-запроса, содержащей исходное DNS-имя. Получив запрос от приложения, локальный сервер действует следующим образом: если полученное DNS-имя имеется в базе данных самого локального сервера, то приложению возвращается искомый IP-адрес. В противном случае локальный сервер проверяет, является ли поступившее от приложения DNS-имя «родственным» имени того домена, за который отвечает данный сервер. (У «родственных» имен совпадают правые части.) Если имена родственны, то поступившее DNS-имя направляется вышестоящему DNS-серверу. При этом локальный сервер выступает в роли клиента, а вышестоящий DNS-сервер — в роли сервера. Если локальный сервер выяснит, что DNS-имена «неродственны», то он передаст поступившее от приложения DNS-имя корневому серверу. Так как корневой сервер «знает» IP-адреса всех DNS-серверов, которые ответственны за декомпозицию доменов второго уровня, то он возвратит в локальный сервер IP-адрес искомого DNS- сервера. Пользуясь этим IP-адресом, локальный сервер вновь повторит свой запрос. Полученный в результате ответ он возвратит приложению. Перейдем к рассмотрению вопроса о том, как локальный и другие серверы выполняют поступающие к ним запросы.

Каждый запрос на обслуживание, поступающий в DNS-сервер от приложения или от другого сервера, содержит кроме DNS-имени тип записи, уточняющий то значение, которое сервер должен возвратить клиенту. Перечислим наиболее интересные типы записи:

– A (сокращение от address) — возвращаемое значение представляет собой IP-адрес, соответствующий заданному DNS-имени;