Марафон для двух протоколов

"В гонке участвуют два протокола для последовательных линий. Колокол!.. Гонка началась. Вы хотите получать самые свежие новости о ходе состязания? Вы первыми узнаете лидера! Оставайтесь с нами!"

Итак, если миру действительно суждено стать одной большой деревней под названием Internet, то на каком языке мы, его обитатели, будем разговаривать друг с другом?

Если говорить только о протоколах для последовательных линий, то есть лишь два варианта: PPP или SLIP. Оба входят в стандарт TCP/IP, признанный коммуникационный протокол в Internet. По существу, коммуникационный протокол - это не что иное, как набор сложных процедур, при помощи которых узлы коммуникационной сети связываются и взаимодействуют друг с другом. TCP/IP предлагает для компьютеров в сети Internet единый язык и стандартные форматы представления информации, благодаря которым они могут общаться. Без единого языка протоколов подобное общение невозможно.

Фактически TCP/IP - это не один протокол, а набор, состоящий из нескольких, связанных между собой протоколов. В комплект входят четыре типа протоколов.

• Протоколы уровня звена данных, обеспечивающие связь компьютеров с сетью (такие как PPP и SLIP).
• Протоколы сетевого уровня, благодаря которым объединенные в сеть компьютеры могут общаться друг с другом.
• Протоколы транспортного уровня, обеспечивающие надежную связь между компьютерами.
• Специальные протоколы прикладного уровня для поддержки функций, которые пользователи хотели бы выполнять с компьютера через Internet. В их числе просмотр Web, передача файлов и электронная почта. Эти протоколы включают в себя HTTP для просмотра Web, ftp для копирования файлов с удаленных компьютеров (и, наоборот, на удаленные компьютеры) через Internet, Simple Mail Transfer Protocol для передачи сообщений электронной почты и, наконец, telnet для эмуляции терминала.

Хотя PPP и SLIP в данной классификации и отнесены к уровню звена данных, они отличаются от типичных протоколов этого уровня в локальных сетях. Разница в том, что PPP и SLIP - это специальные протоколы для передачи пакетов TCP/IP в Internet через телефонные линии. Также они обеспечивают инкапсуляцию на низшем уровне, чему в локальных сетях соответствуют, как правило, пакеты Ethernet, Token Ring или FDDI. (Место PPP и SLIP в архитектуре TCP/IP, а также формат пакетов PPP и SLIP см. на Рисунке 1.)

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

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

В КОЛЬЦЕ

SLIP был предложен в 1984 году в качестве протокола для связи с сетью TCP/IP по коммутируемым телефонным линиям. Он предполагает более примитивную, по сравнению с PPP, инкапсуляцию. В начале и в конце кадра SLIP помещается специальный символ (END), по которому отслеживается сохранение или нарушение целостности кадра вследствие шумов на линии (см. Рисунок 1).

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

Рамки TCP/IP, ограничивающие SLIP, не позволяют ему поддерживать одновременно и другие протоколы. Кроме того, SLIP не предусматривает проверку на наличие ошибок по контрольной сумме. Скорее, протоколы более высоких уровней должны проверять пришедшую из зашумленных телефонных линий информацию и инициировать ее восстановление. Мало того, первоначальные спецификации SLIP запрещали сжатие информации из заголовков пакетов. Поскольку SLIP никогда не был официальным стандартом, он так же многовариантен, как и Unix. Несмотря на все недостатки, он до сих пор продолжает широко использоваться.

К ДЕЛУ!

РРР был официально опубликован в 1993 году и стал стандартом для связи по последовательным каналам, например таким, которые применяются для обмена информацией между домашними компьютерами и Internet по коммутируемым телефонным линиям. РРР работает как с асинхронными, так и синхронными соединениями; он включает протокол управления каналом для переговоров о параметрах соединения между двумя конечными станциями. Протоколы управления сетью РРР помимо IP поддерживают протоколы сетевого уровня типа OSI, DECnet и AppleTalk. Пакеты РРР имеют тот же вид, что и формат ISO High-level Data-link Control (HDLC).

В отличие от пакетов SLIP, у которых очень простая структура, РРР имеют и другие поля, кроме ограничителей начала и конца. Каждый кадр начинается и заканчивается байт-переключателем, флажком. За первым флажком следует байт адреса (АДДР), байт управления (CNTL), поле протокола и собственно информационная часть пакета, т.е. дейтограмма IP (в случае TCP/IP). За этим полем следует поле контроля ошибок на основе циклического избыточного кода, или, иначе говоря, поле контрольной последовательности кадра (см. Рисунок 1).

РРР имеет значительные преимущества перед SLIP. Так, например, компьютеры на противоположных концах соединения могут договариваться о параметрах сеанса связи и сообщать друг другу свои IP-адреса. Последние, в отличие от SLIP, могут назначаться динамически. Иными словами, владельцы сетей связи, типа America Online или CompuServe, могут выделять пользователям адреса из пула IP-адресов. Адреса, таким образом, предоставляются лишь тем, кто реально работает в данный момент с сетью. При этом не требуется закрепления конкретного адреса за конкретным пользователем постоянно. РРР располагает средствами автоматического входа и благодаря полю протоколов поддерживает помимо TCP/IP и другие протоколы.

Еще одной чертой РРР является контроль и восстановление ошибок. Для повышения эффективности работы по медленным линиям протокол управления каналом допускает удаление постоянного флажка и полей адреса, а также сокращение поля протокола с двух байт до одного. Таким образом, РРР-пакеты по крайней мере на три байта длиннее, чем SLIP-пакет. Сжатие заголовка РРР-пакета позволяет повышать скорость связи и хотя бы частично компенсировать больший размер пакета. Какие данные сжимаются и сжимаются ли вообще, определяется специальными правилами.

КОЛОКОЛ!

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

Реализовать PPP сложнее, чем SLIP, поэтому логично предположить, что более сложные алгоритмы подчас действительно снижают быстродействие, зато дают выигрыш в дополнительном контроле, целостности данных или наличии других возможностей.

Сами пользователи Internet часто высказывают диаметрально противоположные мнения о PPP и SLIP. К тому же из-за сложности и динамичности сетей оценка реальной производительности становится крайне затруднительной, поскольку на практике невозможно заставить PPP и SLIP работать бок о бок одновременно и в одном и том же внешнем окружении.

ТЕСТОВАЯ СРЕДА

В качестве испытательного полигона для организации "забега" двух протоколов мы выбрали домашнюю вычислительную систему в лице Apple Macintosh Performa 5215CD PowerPC со встроенным модемом на 14,4 Кбит/с.

В качестве программного обеспечения для организации связи мы остановились на TCP/Connect II 2.3 компании InterCon Systems. Выбор был обусловлен следующими соображениями: во-первых, продукт хорошо себя зарекомендовал, а во-вторых, InterCon является ведущим производителем средств TCP/IP для Mac. (Продукт работает также на платформе Intel под Windows.)

Программное обеспечение, реализующее стандарты PPP и SLIP, должно было доказать свою эффективность при сравнительном тестировании производительности двух протоколов. Мы скопировали программы с ftp-сервера компании InterCon: ftp.intercon.com. Сотрудники отдела маркетинга компании предоставили нам ключ доступа для запуска ПО из скопированных файлов.

Для тестирования PPP и SLIP необходимо было найти оператора Internet, который бы предоставил нам бюджет для обоих протоколов. Как ни странно, эта задача оказалась непростой. Большинство крупных операторов общенационального масштаба и небольшие местные фирмы работали только по стандарту PPP. Но, поскольку Connecticut Internet Exchange была готова и даже стремилась предоставить доступ по двум протоколам, а, еще, и техническую поддержку, мы остановили свой выбор на этой компании.

TCP/Connect II поддерживает две сетевые конфигурации - одну для доступа по PPP, другую - для SLIP. В обеих конфигурациях способ выхода в Internet один и тот же: домашний компьютер набирает номер для выхода в модемный пул Connix на сервере доступа Internet. Трафик PPP и SLIP передается только по участку от конечной станции до сервера доступа в Internet компании Connix. Последний подключен к сети Ethernet, локальной по отношению к серверу доступа. Это означает, что дейтаграммы IP из пакетов PPP и SLIP размещаются в пакетах Ethernet на дальней стороне сервера доступа Internet. На Рисунке 2 мы приводим схему тестовой среды и схему перемещения пакетов между домашним компьютером и Connix Ethernet или, в общем случае, глобальной сетью Internet.

Домашний компьютер становится частью глобальной сети Internet через телефонную систему в момент установления соединения с Connix или другим оператором Internet. IP инкапсулируется в пакеты PPP или SLIP исключительно для того, чтобы они могли достигнуть сервер доступа Internet, на котором дейтаграммы IP извлекаются из пакетов и размещаются в пакетах Ethernet для передачи по той части сети, которая находится в ведении Connix Internet. Низкоуровневая инкапсуляция всегда соответствует физической реализации той сети (или сетей), где пакет будет передаваться между исходным и конечным пунктами.

В условиях эксперимента трафик пакетов между домашним компьютером и узлами Connix в сети Connix Ethernet, такими как www.connix.com и ftp.connix.com, не проходил по всей сложной структуре сетей Internet. Это позволило упростить условия эксперимента и изолировать воздействие PPP и SLIP, а также исключить влияние непредсказуемых факторов, которые невозможно было бы учесть при передаче пакетов по глобальной сети Internet. Однако несколько тестов необходимо было выполнить и для Internet в целом, дабы убедиться, что каждый из протоколов способен работать при условиях, характерных для больших сетей, которые в корне отличаются от условий в сетях, связывающих только домашний компьютер и сетевую среду Connix.

НАСТРОЙКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Мы сконфигурировали ПО TCP/Connect II таким образом, чтобы можно было использовать "родные" драйверы и тем самым добиться максимально возможной производительности. В TCP/Connect II опции SLIP и PPP настраиваются в разделе Configure ниспадающего меню Edit.

Конфигурация SLIP предельно проста. Пользователь должен указать IP-адрес домашнего компьютера. Кроме того, необходимо ввести имя хост-машины для домашнего компьютера, имя домена по умолчанию, а также имя сервера наименования доменов. Окно Active Network Configuration в TCP/Connect II помечается Х. Это означает, что используется данная конфигурация. Только одна сетевая конфигурация может быть активна.

Ввод имени хоста IP, активной конфигурации сети, типа интерфейса, имени домена по умолчанию, а также имен серверов наименования доменов в PPP происходит так же, как в SLIP. В то же время ввод IP-адреса в PPP осуществить сложнее, так как этот протокол допускает динамическое или статическое назначение адресов IP, а также ввод имени пользователя и пароля. Если выбран статический адрес IP, то пользователь должен указать его. В случае динамического назначения IP-адрес присваивается сервером Reverse Address Resolution Protocol, который назначает адреса автоматически.

ГОЛОВОЛОМКА

Для оценки производительности мы выбрали пять заданий для выполнения на скорость.

• Копирование файла небольшого размера/обновление удаленного каталога.
• Загрузка файла среднего размера.
• Копирование файла большого размера/обновление удаленного каталога.
• Загрузка домашней страницы Web.
• Удаление (стирание) файла/обновление каталога.

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

В первом тесте файл объемом 2380 байт копировался с домашнего компьютера на ftp-сервер (ftp.connix.com). Мы измеряли время исполнения от момента начала копирования до появления образа скопированного файла в удаленном каталоге.

Цель этого испытания - получить как можно больше выборок по производительности для разного времени суток. Выполнением таких заданий легко управлять, это позволяет набрать много статистики и гарантировать надежную работу до того, как приступить к более сложным тестам. Копируя ftp.connix.com в сеть Connix Ethernet, мы исключили всевозможные нестабильности, которые могли возникнуть при пересечении информации сети Internet за пределами Connix.

Во втором тесте для определения производительности при работе через Internet за пределами Connix, мы копировали программный файл объемом 25728 байт с узла gopher.novell.com через Connix на домашний компьютер. Время выполнения замерялось от запуска процесса до завершения копирования. Очевидно, влияние нестабильности большой сети на тестируемые протоколы оказалось значительнее, чем в предыдущем случае.

Во время третьего испытания крупный программный файл объемом 285568 байт копировался с домашнего компьютера на ftp-сервер (ftp.connix.com). Время измерялось от начала копирования до момента появления образа скопированного файла в удаленном каталоге. Тест должен был стать своего рода испытанием в экстремальных условиях, а также показать степень соответствия результатов при копировании больших файлов результатам для файлов небольшого объема. На время его выполнения обоими протоколами должны были повлиять различия в процедурах восстановления данных в каждом из них.

Тест на загрузку страницы Web был проведен на домашней странице www.connix.com, время отмерялось от фактического начала загрузки до появления на дисплее сообщения TCP/Connect II "Image complete". Каждый тест отражал продолжительность первой загрузки в каждом сеансе. Целью этого теста было установить производительность при просмотре Web. При загрузке домашней страницы, байты, ее образующие, пересылаются на домашний компьютер с сервера Web.

В последнем тесте мы удаляли файлы, участвовавшие в первом испытании, из удаленного каталога на ftp.connix.com, замеряя время от начала удаления до исчезновения образа файла из удаленного каталога. Этот тест был довольно простым, так как он предполагал пересылку только небольшого количества байт. При его проведении, в частности, выяснялось, какой протокол работает лучше при пересылке по сети файлов минимального объема.

ИТАК, ПЕРВЫМ К ФИНИШУ ПРИШЕЛ...

Испытания показали, что во всех случаях (за исключением одного) PPP быстрее, чем SLIP (см. Рисунок 3). В первом испытании PPP всегда показывал лучшие результаты, в среднем они были выше на 20%. Этот же протокол был в среднем на 16% быстрее во втором испытании. В нескольких случаях было очевидно, что SLIP работал медленнее из-за условий в сети за пределами Connix. Эти же самые условия не оказывали серьезного воздейстия на PPP, что показало проведение подряд двух аналогичных испытаний на каждом из протоколов. Точно так же средний результат PPP в третьей серии испытаний оказался на 5% лучше.

При загрузке домашней страницы Web PPP был на 38% быстрее SLIP. Если результаты первого были практически идентичны, то показатели SLIP сильно отличались друг от друга. В итоге средняя продолжительность оказалась больше. Подобный разброс можно объяснить тем, что SLIP, в отличие от PPP, не способен преодолеть ситуации загруженности сети.

Но при этом SLIP всегда работал быстрее при удалении файла. Это очень простая операция, поэтому неудивительно, что "прямолинейный" SLIP оказался быстрее. Более сложный характер PPP не позволяет повысить производительность в этом случае. Все результаты тестирования сведены в Таблицу 1.

ТАБЛИЦА 1. ПОДРОБНЫЕ РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ PPP/SLIP

В большинстве случаев PPP работает быстрее SLIP, однако существуют обстоятельства, при которых последний оказывается эффективнее. Ценность PPP - в его устойчивости и гибкости при работе в большой динамичной сети.

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