TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

4.3 Сетевые технологии

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

1. Связи "точка-точка" в региональных сетях

2. Локальные сети

3. Службы доставки пакетов региональных сетей

4. Службы коммутации ячеек

Для каждой технологии необходим механизм, который:

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

■ выявляет ошибки при пересылке данных

На сегодняшний день многопротокольным окружением стали как локальные, так и региональные сети. Как показано на рис. 4.2, связи часто совместно используются несколькими протоколами (например, TCP/IP, Novell IPX/SPX, DECnet или Vines); эти же связи применяются при перенаправлении трафика. Многопротокольные хосты и маршрутизаторы должны иметь возможность сортировки различных типов трафика и, следовательно, иметь механизмы для:

■ идентификации типа протокола для PDU, используемого в каждом кадре.

Рис. 4.2. Несколько протоколов совместно используют один носитель.

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

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

4.4. Извлечение данных из пакетов

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

Перед тем как датаграмма будет передана по сетевой связи, она заключается в соответствующий этой связи кадр. После получения кадра маршрутизатор (см. рис. 4.3):

■ удаляет обрамление кадра и извлекает датаграмму

■ анализирует IP-адрес назначения датаграммы и выбирает следующий носитель для дальнейшей пересылки

■ заключает датаграмму в новый кадр (пакетирует ее) и передает по следующей связи, направляя ее далее по маршруту

Рис. 4.3. Извлечение данных из пакета

Перейдем к более детальному описанию и обсудим способы пакетирования данных для различного типа сетевых технологий. Начнем со связей "точка-точка".

4.5 Протоколы связей "точка-точка"

Датаграммы IP могут передаваться по связям "точка-точка" между парой хостов, хостом и маршрутизатором или парой маршрутизаторов. Протокол IP передает датаграмму посредством множества различных взаимодействий TCP или UDP по одиночной связи "точка-точка".

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

Рис. 4.4. Множество клиентов и серверов совместно используют одну сетевую связь.

В настоящее время трафик IP, пересылаемый по связям "точка-точка", пакетируется несколькими различными способами:

■ с использованием общепринятой версии протокола "точка-точка" HDLC

■ через стандартный протокол Интернета РРР

■ с использованием протокола SLIP

Понемногу реализации перемещаются в сторону стандарта Интернета PPP, который имеет множество разнообразных возможностей.

4.6 HDLC

Протокол управления высокоуровневой связью данных (High-level Data Link Control — HDLC) является международным стандартом для связи "точка-точка" начиная с 60-х годов. HDLC пересылает серию данных как синхронизированный по времени поток бит, разделенный на кадры. Каждый кадр отделяется специальным шаблоном (флажком):

0 1 1 1 1 1 1 0

Для распознавания этого шаблона необходимо исключить его возникновение в пользовательских данных. Для этого после пересылки флажка открытия кадра передающая аппаратура вставляет нули после каждых пяти последовательных единиц в пользовательских данных. Такой способ называется вставкой нулевого бита (zero-bit insertion) или набивкой битов (bit-stuffing).

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

На рис. 4.5 показаны данные до и после вставки дополнительных битов.

Рис. 4.5. Вставка нулевого бита в HDLC

4.6.1 Формат кадра HDLC

Использование шаблона в протоколе HDLC влияет на всю структуру формата кадра. На рис. 4.6 показан информационный кадр HDLC, имеющий заголовок, данные и завершающую секцию, которая содержит контрольную последовательность кадра (Frame Check Sequence — FCS). Октет шаблона применяется как разделитель в начале и в конце кадра.

Рис. 4.6. Формат кадра HDLC с разделителями

FCS создается в результате математического вычисления на основе содержимого кадра. Полученный результат называется циклической избыточной суммой (Cyclic Redundancy Check — CRC), и некоторые авторы используют для именования завершающей секции кадра название CRC, а не FCS. Аналогичные вычисления выполняются в точке назначения связи. Если полученный при этом результат не будет равен значению поля FCS, значит, некоторые биты кадра изменились при пересылке и кадр должен игнорироваться как содержащий ошибку.

Использование контрольной последовательности кадра — это очень полезная идея. Поле FCS можно обнаружить практически во всех кадрах локальных и региональных сетей.

Заголовок кадра HDLC имеет поле адреса назначения (destination address). Такое поле необходимо для многоточечной (multipoint) версии протокола HDLC (например, в протоколе Synchronous Data Link Control (SDLC) компании IBM), которая позволяет нескольким системам совместно использовать одну линию. Каждой системе присваивается собственный адрес, а трафик этой системы перенаправляется в соответствии с адресом в заголовке кадра.

IP не использует технологию многоточечной линии связи, и передаваемые в кадрах HDLC датаграммы IP имеют своим адресом двоичное значение 11111111 (шестнадцатеричное X'FF), которое называется широковещательным адресом (broadcast), определяющим пересылку кадра на все станции сети. (Далее в книге для записи шестнадцатеричных чисел используется формат X'N, где X указывает на шестнадцатеричное число, N — представляет само число, а "'" — разделяет два поля такой записи.— Прим. пер.)

Заголовок кадра HDLC имеет поле управления (control). Некоторые протоколы связи помещают в это поле номера пересылаемых кадров или номера кадров для подтверждения их получения. Примерами могут служить протоколы SDLC и LAPB, использующие поле управления для нумерации, подтверждения приема и повторной трансляции кадров. Такие протоколы выполняют повторную пересылку тех кадров, для которых не получено подтверждение их получения приемником за заданный интервал времени.

Кадры, переносящие датаграммы IP, как и кадры для пересылки данных других протоколов, например IPX или DECnet, не требуют нумерации и подтверждения. Для IP и других похожих протоколов в управляющем поле записывается значение X'03, указывающее на нечисловой информационный кадр (Unnumbered Information frame) протокола HDLC.

Таким образом, датаграммы IP в кадрах HDLC имеют формат, представленный на рис. 4.7.

Рис. 4.7. Формат кадра HDLC, передающего датаграмму IP

Обобщив, можно отметить, что при пересылке датаграмм IP в кадрах HDLC:

■ Используется широковещательный адрес X'FF.

■ Управляющее поле имеет значение X'03 — нечисловой информационный кадр.

4.6.2 Недостатки HDLC

То, что HDLC является стандартом, еще не означает успешного взаимодействия друг с другом связей "точка-точка" между различными реализациями интерфейсов HDLC.

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

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

Разработка HDLC была выполнена до появления многопротокольных сетей. Однако сегодня многие линии "точка-точка" служат для пересылки трафика от различных протоколов, что приводит к дополнительным проблемам.

Решение этих вопросов поручено комитету IETF.

4.7 Протокол PPP

Рабочая группа IETF предложила решение на основе протокола "точка-точка" (Point-to-Point Protocol — PPP). PPP может использоваться в любой полнодуплексной цепи — синхронной с пересылкой битов или асинхронной (старт/стоп) с пересылкой байтов. Этот протокол пригоден для медленных последовательных линий связи, быстрых выделенных линий, ISDN или волоконно-оптических каналов SONET. PPP был разработан для пересылки PDU различных протоколов — IP, IPX, DECnet, ISO и т.д. Кроме того, PPP обеспечивает пересылку данных через сетевые мосты.

PPP содержит несколько подпротоколов. Например:

■ Протокол управления связью (Link Control Protocol) служит для установки, проверки, конфигурирования и закрытия сетевой связи.

■ Протокол управления сетью (Network Control Protocol) предназначен для инициализации, конфигурирования и завершения использования отдельного сетевого протокола. Индивидуальный протокол Network Control Protocol определен для IP, IPX, DECnet, ISO и т.д.

Типичный сценарий РРР выполняется следующим образом:

■ Начинающая соединение по PPP система посылает кадр Link Control. Ее партнер отвечает дополнительным кадром Link Control, устанавливая параметры связи.

■ Проводится обмен кадрами Network Control Protocol для выбора и конфигурирования используемых протоколов сетевого уровня.

■ Данные выбранного протокола пересылаются по связи в кадрах PPP. Каждый кадр имеет поле заголовка, идентифицирующее тип протокола для содержащихся в кадре данных.

■ Для завершения связи применяется обмен кадрами Link Control и Network Control.

Заголовок кадра PPP похож на заголовок HDLC, но содержит одно дополнительное поле для идентификации протокола следующего уровня. На рис. 4.8 показан формат кадра PPP с датаграммой IP. Адресное поле имеет значение X'FF (широковещательная рассылка), а управляющее поле — X'03 (нечисловая информация). Дополнительное поле протокола (protocol field) имеет значение X'00-21, что соответствует пересылке датаграмм IP. Номера для протоколов определены в документе RFC Assigned Numbers (присвоенные номера) от IANA.

Рис. 4.8. Формат кадра PPP, переносящего датаграмму IP

4.7.1 Сжатие в PPP

Может показаться не очень разумным включение одних и тех же октетов адреса и управления в каждый кадр. Партнеры на каждом конце связи PPP могут работать в режиме сжатия (compression) для исключения этих полей.

Значения в поле протокола указывают, является ли содержимое кадра сообщением Link Control или Network Control, либо полезной информацией (например, датаграммой IP). При установке связи по PPP поле протокола имеет длину 16 бит, но далее при пересылке полезной информации его длина может быть сокращена до 8 бит. Следовательно, датаграмма может быть пакетирована более эффективно (см. рис. 4.9).

Рис. 4.9. Кадр PPP в сжатом формате

Еще одной возможностью в PPP является сжатие методом Вана Джекобсона, позволяющее исключить лишние байты, пересылаемые в сеансе TCP. Заголовки IP и TCP вместе имеют длину от 40 байт и более. Сжатие методом Вана Джекобсона уменьшает типичную 40-байтовую комбинацию до 3, 4 или 5 байт. Для этого оба партнера должны сохранять первоначальные заголовки. При изменениях во время сеанса TCP будут пересылаться только измененные значения в заголовках. Поскольку большая часть используемой в заголовках информации имеет статическую природу, объем пересылаемых изменений будет незначителен.

4.8 Дополнительный возможности PPP

Рабочая группа по PPP решила и несколько дополнительных проблем, которые могут возникнуть при использовании связей "точка/точка".

4.8.1 Аутентификация

Протокол PPP часто используется для удаленных коммуникаций и связи мобильного пользователя по коммутируемым соединениям. Коммутируемые соединения (dialup connection) иногда применяются для связи локальных сетей подразделений компании с сетью главного офиса.

Перед тем как разрешить внешней системе соединиться с сетью по коммутируемому соединению, следует провести аутентификацию такой системы. В настоящее время PPP поддерживает два способа аутентификации:

■ Простой протокол аутентификации по паролю (Password Authentication Protocol — PAP). В этом случае используются идентификатор пользователя и его пароль, которые вкладываются в кадры, пересылаемые по связи в процессе ее создания.

■ Протокол аутентификации по взаимной проверке (Challenge Handshake Authentication Protocol — CHAP).

Метод взаимной проверки был рассмотрен в главе 3 и не представляет особых трудностей при изучении. Как показано на рис. 4.10:

1. По связи открытым текстом пересылается имя пользователя.

2. Удаленный партнер отвечает случайным проверочным сообщением.

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

4. Удаленный партнер на основе пароля выполняет те же самые вычисления и сравнивает полученные результаты.

Рис. 4.10. Взаимная проверка в PPP

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

4.8.2 Автоматическое отслеживание качества связи

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