Преобразование IPадресов в физические адреса оконечных устройств

Концепция сети INTERNET, объединяющей разнородные по типам аппаратно-программных средств и протоколам физические сети, требует установления жесткого соответствия IP-адресов физическим адресам оконечных устройств.

Задачу определения физического адреса ЭВМ по ее IP-адре-су решают два протокола: Address Resolution Protocol (ARP, RFC826) и Reverse Address Resolution Protocol (RARP, RFC903), входящие в IP в виде составных частей.

Сущность протокола ARP заключается в следующем. Если узел А должен связаться с узлом В и знает его IP-адрес, но не знает физического адреса, то он передает широковещательное сообщение, в котором запрашивает физический адрес узла В. Все узлы принимают это сообщение, однако лишь узел В отвечает на него, посылая в ответ свой физический адрес узлу А. Последний, получив физический адрес В, запоминает его, чтобы не запрашивать повторно при следующих обращениях к узлу В.

Этот алгоритм приемлем для случая, когда узел А «знает» свой IP-адрес. В противном случае, когда узел А является, например, бездисковой рабочей станцией, у которой только что включили питание и она ничего не знает ни о себе, ни об окружающих, и не может произвести дистанционную загрузку операционной системы, «спасает» протокол RARP. Узел А широковещательно вызывает обслуживающий его сервер, указывая в запросе свой физический адрес (при этом узел А может даже не знать адреса сервера). В сети всегда есть по меньшей мере один обслуживающий такие запросы сервер (RARPсервер), который распознает запрос от рабочей станции, выбирает из некоторого списка свободный IP-адрес и передает узлу А сообщение, включающее динамически выделенный узлу A IP-адрес и другую необходимую информацию. При таком алгоритме выход из строя единственного в сети RARP сервера очень «нежелателен», поэтому протокол RARP поддерживает несколько серверов в сети, «подстраховывая» себя.

Протоколы транспортного уровня TCP и UDP

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

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

Любое обращение к процессу в удаленной ЭВМ осуществляется при помощи адреса, состоящего из двух частей: IP адреса, идентифицирующего ЭВМ, и номера порта, идентифицирующего процесс.

Все задачи можно условно разделить на две большие группы: известные всем (wellknown) и прочие. К известным относятся задачи (или услуги), получившие повсеместное распространение. Для них существуют заранее определенные порты, закрепленные в стандартах INTERNET. Это так называемые хорошо известные номера (wellknown numbers). Выделением номеров заранее определенных портов занимается организация IANA (Internet Assigned Numbers Authority).

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

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

Определение получателя — одна из главных задач транспортных протоколов в INTERNET. В семействе TCP/IP таких протоколов два.

Протокол UDP

UDP (RFC768) является дейтаграммным протоколом, не гарантирующим доставку и не сохраняющим порядок поступления дейтаграмм.

Сообщение протокола UDP называют абонентской дейтаграммой (user datagram). Оно состоит из заголовка и блока данных. Заголовок пользовательской дейтаграммы состоит из четырех 16битовых полей (рис. 39).

Рис. 39 — Формат заголовка дейтаграммы протокола UDP

Поля «Адрес порта процесса отправителя» и «Адрес порта процесса получателя» определяют адреса портов процесса отпра-вителя и процесса получателя. Поле «Адрес порта процесса отправителя» имеет конкретное значение только в том случае, если процесс отправитель должен получить ответное сообщение, в противном случае оно заполняется нулями.

Поле «Полная длина дейтаграммы» указывает полную длину (в октетах) заголовка и блока данных пользовательской дейтаграммы.

Поле «Контрольная сумма» содержит контрольную сумму. При ее расчете учитываются также сетевые адреса. В целом расчет контрольной суммы производится следующим образом:

1. Блок данных сообщения дополняется нулями до целого числа 16 битовых слов.

2. Поле «Контрольная сумма» заполняется нулями.

3. Перед сообщением помещается псевдозаголовок, структура которого показана на рис. 40.

4. Расчет контрольной суммы производится по всей этой совокупности данных, после чего снимаются псевдозаголовок и дополнение нулями, значение контрольной суммы помещается в соответствующее поле заголовка, а дейтаграмма передается сетевому уровню (протокол IP).

Рис. 40 — Формат псевдозаголовка дейтаграммы протокола UDP

ЭВМ-получатель для проверки контрольной суммы дейтаграммы производит аналогичные операции.

Расчет контрольной суммы операция необязательная. В случае, если поле «Контрольная сумма» заполнено нулями, то оно воспринимается как отказ от расчета контрольной суммы. Для случая (редкого, но возможного), когда рассчитанная контрольная сумма равна нулю, все биты поля «Контрольная сумма» устанавливаются в состояние «1».

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

Протокол TCP

В отличие от UDP протокол TCP (RFC793 и RFC761) обеспечивает полноценную транспортную службу. Транспортная служба TCP:

· обеспечивает доставку данных (при этом процесс передает протоколу данные в виде целостного файла);

· обрабатывает данные (не накладывает никаких ограничений на структуру данных);

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

· обеспечивает срочную передачу данных (даже одного байта);

· организует дуплексные виртуальные соединения посредством предварительной операции установления соединения;

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