Применяемое оборудование

Маршрутизаторы

Маршрутизатор (router) можно упрощенно рассматривать как некое устройство, обеспечивающее:

· физическое подключение к себе каналов определенного типа;

· передачу данных по этим каналам;

· выбор маршрута, по которому надо передавать данные.

При этом не имеет значения, как именно устроен маршрутизатор. Главное - чтобы он справлялся с поставленными задачами. Часто возникает путаница в терминологии из-за того, что маршрутизатор можно сделать из обычного PC-совместимого компьютера путем установки в него необходимых плат (например, синхронных портов) и соответствующей настройки программного обеспечения. Естественно, помимо того, что функционально такой компьютер будет работать маршрутизатором, он способен выполнять и другие задачи. В то же время существуют специализированные устройства, называемые маршрутизаторами, которые предназначены только для выполнения упомянутого выше набора функций. Во многих случаях их применение является более целесообразным. Например, при необходимости обслуживания большого числа каналов, при сложных алгоритмах маршрутизации, при необходимости преобразования протоколов и т.д. Применение недорогих моделей маршрутизаторов конечными пользователями с несложной структурой собственной сети также является оправданным решением, так как, в этом случае уменьшаются затраты на поддержку работоспособности маршрутизатора и увеличивается надежность. Для подключения клиентов, построения сети и обслуживания внешних каналов мы используем маршрутизаторы фирмы Cisco System, Inc, являющейся лидером в области производства маршрутизаторов.

Использование PC в качестве маршрутизатора

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

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

Модемы

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

Если линия аналоговая, то с обеих сторон необходимо устанавливать модемы. Модем для аналоговой линии выбирается исходя из характеристик линии и желаемой скорости передачи данных. Учтите, что модель модема должна соответствовать количеству проводов в линии (два или четыре). В частности, далеко не все модемы могут работать по четырехпроводной линии. Для передачи данных по аналоговым линиям со скоростями до 33.6 Кбит/с используются модемы того же типа, что и применяемые для обычных коммутируемых телефонных каналов. Разница состоит в том, что помимо скоростных характеристик и прочих возможностей, необходимо обратить особое внимание на такие характеристики, как стабильность и отказоустойчивость в режиме длительной непрерывной эксплуатации. Не стоит пытаться сэкономить деньги, покупая дешевый модем для использования его на выделенной линии.

Для передачи данных по аналоговым линиям длиной 5-7 км со скоростями 64 Кбит/с и выше используются специальные модемы для коротких линий (Short Range Modems). Как правило, они имеют синхронный интерфейс. Очень широко используются модемы (и другое оборудование) фирмы RAD.

Компьютеры и операционные системы

Для полноценной работы в сети Вам понадобится компьютер для выполнения различных прикладных задач, связанных с работой Вашей организации в Internet. В число этих задач, в частности, входят:

· сервер DNS для Ваших доменов;

· передача, получение, перераспределение электронной почты;

· работа с системой телеконференций USENET;

· создание WWW и FTP серверов.

В качестве операционной системы для такого компьютера мы настоятельно рекомендуем использовать Unix. Мы не утверждаем, что это невозможно сделать, используя другие операционные системы. Возможно, что это так, но решения на базе Unix являются, как правило, надежными и проверенными. И это понятно, учитывая, что операционная система Unix очень давно органически связана с Internet и TCP/IP. Почти все сервис-провайдеры Internet используют именно Unix. Можно привести следующие ее преимущества:

· лучшая устойчивость;

· скромные по сравнению с многими операционными системами требования к ресурсам;

· наличие нескольких свободно распространяемых (бесплатных) версий для PC-совместимых компьютеров;

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

· возможность получить консультацию у провайдера.

Пожалуй, единственным недостатком этой системы является кажущаяся сложность ее администрирования и работы в ней. Этот недостаток, пожалуй, спорный и является следствием того, что многие уже давно привыкли работать с "менюшечно-окошечным" интерфейсом и администрировать систему движениями мыши. Если последнее является решающим фактором, то о Unix можно забыть, хотя и это там присутствует в определенной мере. Но тому, кто умеет работать в DOS'е без Norton Commander'а и, вместо передвижения по многочисленным меню, иногда отредактировать конфигурационный файл текстовым редактором, можно порекомендовать выбрать Unix.

В качестве компьютера для выполнения связанных с Internet прикладных задач можно использовать обычный PC-совместимый или т.н. рабочую станцию. PC-совместимого компьютера с достаточным количеством оперативной памяти и дискового пространства зачастую вполне хватает. При выборе версии Unix'а для такого компьютера, обязательно обратите внимание на спецификацию, которой он соответствует. Хорошим решением будет использование системы LINUX.

8.8 Последовательность действий по подключению
Исследование возможности и предварительное согласование
параметров подключения

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

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

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

Заключение договора на обслуживание

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

Получение канала

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

Подбор оборудования

Учтите, что зачастую сроки поставки необходимого оборудования могут составлять несколько недель, поэтому, позаботьтесь об этом заранее.

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

Физическое подключение канала

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

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

Начальное тестирование

Перед тем, как будет выполняться подключение, не забудьте произвести все авансовые платежи. Учтите, что сразу после того, как Ваш канал заработает, Ваш баланс в расчетной системе уменьшится на сумму, равную оплате за подключение и первый месяц работы. Если после этого Ваш баланс будет отрицательным, Вас отключат.

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

8.9 Архитектура протоколов

Общая их классификация имеет следующий вид:

1. RFC Index (перечень RFC – Request for Comments) – список всех изданных RFC в порядке возрастания номеров, дополняемый по мере их появления.

2. Internet official protocol standards (официальный перечень стандартов по протоколам Internet) – периодически обновляемый документ, где излагается общая характеристика процесса стандартизации в Internet, перечни вновь изданных RFC и обобщающие перечни протоколов, группируемые по стадиям стандартизации и иным признакам. Последняя версия этого документа изложена в RFC 2400.

3. RFC Summary Numbers (сводный перечень номеров RFC) переиздается, начиная с номера 699, через каждые 100 номеров и содержит перечни с краткими аннотациями каждых 100 предыдущих номеров RFC.

4. Assigned Numbers (присвоенные номера) – перечисляются присвоенные значения параметров, используемых в различных протоколах (например, адреса Internet, имена регионов, протокольные коды IP, номера портов TCP, коды опций Telnet, наименования типов терминалов).

К концу сентября прошлого года IAB выпустил 2331 документ RFC (последний изданный в сентябре RFC имеет номер 2428, но в первой тысяче осталось 77 «пустых» или пропущенных номеров, под которыми никогда ничего не издавалось). Динамика количественного выпуска документов RFC по годам (дифференциальная кривая) и с нарастающим итогом (интегральная кривая), начиная с 1969 года, которая в какой-то мере отражает динамику развития самой сети Internet.

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

Кроме того, RFC никогда не переиздаются и не пересматриваются с тем же номером. Пересмотренный протокол издается под другим номером, а прежние сохраняются в каталогах под прежними номерами.

Согласно RFC 2400 в Internet приняты две независимые системы классификации протоколов. Первая подразделяет протоколы по уровню зрелости или стадиям стандартизации на:

· информационные (informational);

· экспериментальные (experimental);

· предложения по стандартам (proposed standards);

· проекты стандартов (draft standards);

· стандарты (standards);

· исторические (historic).

Вторая делит протоколы по уровню требований или статусу на:

· обязательные (required);

· рекомендуемые (recommended);

· избирательного применения (elective);

· ограниченного применения (limited use);

· не рекомендуемые (not recommended).

Протоколы проходят три стадии созревания: предложение по стандарту, проект и стандарт, подвергаясь на каждой стадии тщательному анализу и тестированию. Предложение по стандарту может стать проектом только при наличии минимум двух независимых реализаций и рекомендации Инженерной группы управления Internet (IESG – Internet Engineering Steering Group). Продвижение от проекта к стандарту требует обычно эксплуатационной проверки и демонстрации взаимодействия с двумя или более реализациями и также рекомендации IESG.

От предложения до проекта стандарта минимальная задержка составляет 6 месяцев, от проекта до стандарта – 4 месяца. Фактические же задержки могут достигать нескольких лет.

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

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

Вышедшие из употребления протоколы сохраняются в перечнях RFC с пометкой «исторические». Все такие протоколы должны иметь статус «не рекомендуемые». Протоколы, замененные новыми, получают название «устарелые» (obsolete).

Если протокол находится в одной из стадий «предложение по стандарту», «проект стандарта» или «стандарт», считается, что он находится в «треке стандартов» (standards track). Протоколам в стадии «стандарт» присваиваются номера STD. При этом в отличие от нумерации документов RFC номер стандарта STD при его пересмотре не изменяется (хотя пересмотренный документ будет иметь новый номер RFC). Иначе говоря, стандарт по конкретному протоколу всегда будет иметь один и тот же номер STD.

Другая особенность нумерации STD состоит в том, что если спецификация стандарта охватывает несколько документов RFC, они будут иметь один и тот же номер STD. Например, спецификация Domain Name System определяется комбинацией двух RFC – 1034 и 1035, которые охватываются одним номером STD 13. Шесть RFC по протоколам сетевого уровня (протокол IP, его расширения и протоколы ICMP, IGMP) охватываются одним STD 5. Для большей ясности один из нескольких RFC, охватываемых одним STD, можно указывать двойным номером, например, «STD 13/RFC 1034».

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

Согласно RFC 2400 при вхождении в трек стандартов (на стадии предложения по стандарту) протокол должен получить один из трех статусов, который, однако, может быть пересмотрен в любой момент времени:

1. Обязательный – система должна реализовать этот протокол.

2. Рекомендуемый – желательно (по соображениям экономичности, технической эффективности или лучшей совместимости), чтобы система реализовала данный протокол.

3. Избирательного применения – система может реализовать один из нескольких протоколов аналогичного назначения по усмотрению разработчика. К таким протоколам должны относиться, например, протоколы электронной почты или протоколы маршрутизации. Фактически же, для всех протоколов в стадии «предложение по стандарту» независимо от наличия альтернатив и возможностей выбора в документе RFC 2400 указан статус «избирательного применения», что несколько противоречит определению этого статуса.

Помимо этого протоколы (в основном экспериментальные и исторические) могут получить один из следующих статусов:

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

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

С 1995 году IAB ввоцедуре принятия предложений по стандартам. Статус этих документов определен в RFC 1818, а документы BCP имеют свою независимую нумерацию. К сегодняшнему дню разработано 25 RFC в статусе BCP, однако при формальном группировании RFC по RFC 2400 документы BCP в отдельный класс не выделяются.

К сожалению, фактическая классификация конкретных документов и протоколов Internet как в самом RFC 2400, так и в других перечисленных регламентирующих и обобщающих документах IAB не обладает четкостью этого рисунка и страдает иногда нелогичностью и противоречивостью.

Прежде всего, в последнем обновленном RFC 2400, который перевел 20 ранее выпущенных версий этого документа в категорию исторических и одновременно устарелых, фактически упоминается лишь около 30% всех изданных RFC (758 документов). Сведения о стадии разработки и статусе остальных 70% RFC приходится разыскивать в 20 устарелых «исторических» RFC.

Уже отсюда видно, что понятию «устарелый» в классификации протоколов Internet придается смысл, несколько отличный от общепринятого. Это подтверждается еще и тем фактом, что после появления по какому-либо протоколу нового «предложения по стандарту» прежний продолжающий действовать стандарт по этому протоколу объявляется устарелым, хотя очевидно, что новое предложение по стандарту не может заменить действующий стандарт. Фактически, что признается и в самом RFC 2400, все устарелые протоколы делятся на две категории – те, которые не имеет смысла упоминать в официальном перечне протоколов, и те, которые заслуживают того, чтобы на какое-то время сохранить их в перечне, поскольку в данном случае «устарелый стандарт находится в процессе замены». Типичным (но не единственным) примером подобного подхода является стандарт STD 12 по протоколу NTP (Network Time Protocol), версия 2 (RFC 1119), который согласно RFC 2400 переведен в разряд устарелых стандартом избирательного статуса по протоколу NTP, версия 3 (RFC 1305) и в то же время оставлен в перечне действующих стандартов со статусом «рекомендуемый», а новому стандарту (по RFC 1305) номер STD 12 не передан.

Таблица 8.1.

Количественное распределение протоколов
Internet по стадиям разработки

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

Официально считается, что стадии стандартизации являются долгосрочными, остальные же, особенно те, которые отражают процесс обновления стандартов, должны длиться один-два года. Фактически же эти «краткосрочные» стадии растягиваются иногда на десятилетия. Например, некоторые предложения по стандартам Telnet (RFC 652 – 658) сохранялись на этой стадии в течение 24 лет (с 1974 по 1998 год), после чего были переведены в категорию исторических, а многие проекты стандартов сохраняют свой статус с 1990 года (RFC 951, 954, 1191 и др.) по сегодняшний день.

Анализ перечисленных документов IAB позволил выявить следующую статистику количественного распределения документов RFC и протоколов Internet по стадиям разработки.

К документам с неизвестной стадией разработки относятся 908 начальных документов Internet, изданных до 1990 года, которые, судя по RFC 2400, не входят в трек стандартов и не относятся к экспериментальным (их можно отнести либо к информационным, либо к историческим). «Исторический» и одновременно «устарелый» документ должен означать, что он заменен новым документом, просто «исторический» должен означать, что он морально устарел и не имеет замены. Все документы RFC подразделяются на две группы: технические спецификации (TS – Technical Specifications) и положения о применимости (AS – Applicability Statements). Пока издано только 8 спецификаций AS, находящихся в различных стадиях разработки.

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

Таблица 8.2.

Эта статистика не показывает, однако, динамики взаимоотношений. Так, если взаимосвязь Internet с устарелыми (ARPANET) или достаточно зрелыми, но в чем-то устаревающими системами (IPX Novell, AppleTalk), постепенно вытесняемыми самой Internet, стабилизировалась (судя по отсутствию новых RFC) в начале 80-х, то с конца 80-х началась проработка взаимосвязей с развивающимися новыми архитектурами Frame Relay, ATM, а также привлечение и освоение ресурсов, наработанных в ISO, ITU-T, что и отразилось в появлении соответствующих RFC.

C 1990 года IAB ввел новую серию документов под названием FYI (For Your Information), которые носят информационный характер и должны обеспечить пользователей Internet централизованным справочником по наиболее важным темам и обобщающим вопросам (терминология, ответы на часто задаваемые вопросы относительно Internet и т.п.). Документы FYI имеют свою независимую нумерацию, и помещаются отдельным разделом в RFC Index, но не анализируются в RFC 2300. Издано 32 документа FYI, большинство из которых имеют своими дубликатами документы RFC.

Взаимосвязи между протоколами Internet

Уровневая архитектура протоколов Internet во многом соответствует концепции семиуровневой архитектуры протоколов эталонной модели OSI. Основное различие этих двух архитектур состоит в том, что протоколы трех верхних уровней эталонной модели OSI – прикладного, представления данных и сеансового в Internet, как правило, объединяются в один уровень – прикладной.

Основными изначальными прикладными службами Internet были и остаются службы передачи файлов, электронной почты и обмена новостями, виртуальных терминалов и справочная служба. В каждой из таких областей шло постоянное развитие исходных и создание новых более эффективных протоколов, основные из которых, используемые сегодня перечислены на рисунке. Кроме того изначально применялись протоколы, выполняющие ряд вспомогательных, но повышающих эффективность работы функций – протоколы информирования о времени (TIME, NTP), получения собственных идентификаторов (BOOTP), получения информации об окружающей системе (Finger), диагностические протоколы (Echo) и др.

С середины 90-х в Internet начала активно развиваться и внедряться технология World Wide Web, обеспечивающая гипертекстовые ссылки и связки различных видов информации. В эти годы были созданы язык HTML и протокол HTTP, претерпевшие к настоящему времени несколько модификаций, а также необходимые форматы адресных ссылок URL и URN.

На прикладном уровне Internet используются также разработанные в рамках архитектуры OSI прикладные протоколы электронной почты Х.400 и справочной службы Х.500.

Для управления Сетью, эксплуатации и технического обслуживания различного сетевого оборудования разработан стандарт (STD 15/RFC 1157, статус «рекомендуемый») по протоколу SNMP. Кроме того, имеется несколько десятков документов различной стадии разработки, расширяющих функции SNMP на работу с самым разнообразным сетевым оборудованием и на взаимодействие с другими сетями в целом.

Функции уровня представления данных по эталонной модели OSI в Internet выполняет стандарт по протоколу и языку представления данных XDR, во мноIP. Вспомогательный протокол ICMP, предназначенный для передачи сообщений об ошибках в передаваемых пакетах IP, расположен над IP, но по своим функциям он все же больше тяготеет к сетевому уровню, чем к транспортному.

На уровне звена данных (канальном уровне) изначально использовался протокол SLIP, который сегодня фактически вытеснен протоколом двухпунктовых соединений PPP, поддерживающим как асинхронные (байт-ориентированные стартстопные), так и синхронные (бит-ориентированные) двунаправленные кабельные или модемные соединения. В последнее время дополнительно разработаны и успешно используются специальные стандарты для передачи IP-трафика по сетям различных архитектур, которые более полно учитывают особенности этих сетей. Кроме того на этом уровне часто используются (с применением инкапсуляции) протоколы других архитектур (Frame Relay, HDLC (в подсетях X.25), SDLC (в подсетях SNA), DDCMP (в подсетях DECNet), протоколы LAN и др.

На физическом уровне в сети Internet могут быть использованы практически все широко известные протоколы и интерфейсы физического уровня, стандартизованные ITU-T (CCITT), EIA, ISO, Frame Relay Forum, ATM Forum, протоколы и интерфейсы LAN, SDH (SONET) и др. Единственным ограничением, налагаемым протоколом РРР на физический уровень, является наличие дуплексного канала, выделенного или коммутируемого, работающего в асинхронном или синхронном последовательном режиме, прозрачном для пакетов уровня PPP. На скорости передачи данных и тип интерфейса никаких ограничений не налагается.

Протоколы прикладного уровня взаимодействуют с протоколами транспортного и сетевого уровней с использованием инкапсуляции. Так, в частности, протоколы HTTP, Telnet, FTP, SMTP, POP3, IMAP используют протокол TCP, протокол TFTP использует протокол UDP, а службы NetBIOS, TIME и протоколы OSI могут использовать оба транспортных протокола.

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

Взаимосвязь с другими сетями и архитектурами

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

Как уже отмечалось, вопросам взаимодействия Internet с другими сетями посвящено 290 документов RFC, отражающих используемые на практике конфигурации взаимодействия. Основные из таких конфигураций отражены на рис. 4, где указаны также соответствующие документы RFC, определяющие взаимодействие протоколов Internet с другими протоколами.

Можно выделить два основных подхода к взаимодействию Internet с другими сетевыми архитектурами и сетевыми технологиями.

1. Использование на нижних уровнях Internet современных высокоскоростных протоколов типа типа FDDI, Fast Ethernet, Frame Relay, ATM и др., повышающее эффективность работы прикладных протоколов Internet.

2. Использование более эффективных прикладных программ других сетевых архитектур (типа OSI, SNA) для работы по практически апробированным, достаточно зрелым и широко распространенным коммуникационным протоколам Internet.

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

1. разбиение длинного сообщения пользователя или единицы информации вышерасположенного уровня (пакета, кадра) на несколько более коротких фрагментов или сегментов. Этот процесс получил в литературе двоякое название: «фрагментация» (fragmentation) или «сегментирование» (segmenting);

2. образование из полученных фрагментов единиц информации (кадров, ячеек), воспринимаемых используемой сетевой технологией и упаковка полученных единиц информации в кадры или ячейки данной сетевой технологии. Этот процесс получил название «инкапсуляция» (encapsulation);

3. восстановление на принимающей стороне исходного сообщения, пакета или кадра. Этот процесс, в зависимости от конкретных используемых сетевых технологий, называется «сборка» (reassembling) (например, в X.25, ISDN) или «декапсуляция» (decapsulation) в большинстве других технологий.

Метод инкапсуляции протоколов определен в рекомендациях ITU-T I.363, I.365, Q.2119, стандартах ANSI T1.617a, Frame Relay Forum FRF.3.1 и в RFC 1490. На рис. 4 взаимодействие различных протоколов методом инкапсуляции изображено стрелками.

Метод преобразования услуг использован в показанном на рис. 4 взаимодействии протоколов Internet с прикладными протоколами OSI. В RFC 1006 (стандарт STD 35) определен механизм, позволяющий протоколу транспортного уровня ТР 0 (простой класс) по ISO/IEC 8073 (и, следовательно, любым прикладным программам OSI, работающим по ТР 0) функционировать над протоколом TCP Internet при использовании услуг протокола IP. В результате логические объекты всех верхних уровней OSI (прикладного, представления данных и сеансового) могут функционировать нормально, не ощущая того, что все они работают по TCP/IP.

В RFC 2126 (предложение по стандарту) дополнительно к протоколу ТР 0 предусмотрено также функционирование протокола ТР 2 (класс с мультиплексированием сетевых соединений) ISO/IEC 8073 над протоколом TCP и, кроме того, уточняются механизмы преобразования услуг TCP в услуги сетевого уровня OSI, используемые TP 0 и TP 2. Аналогичный стандарт «Использование прикладных протоколов OSI над протоколом TCP Internet» разработан в ISO.

Протокол по RFC 1006/2126 и ISO/IEC 14766 преобразует услуги протокола TCP Internet в стандартные по ISO/IEC 8348 услуги сетевого уровня OSI в режиме с установлением соединения (CONS), которые затем используются протоколом TP 0 или TP 2 по ISO/IEC 8073. Кроме того указанный протокол инкапсулирует протокольные блоки ISO/IEC 8073 в пакеты протокола ТСР. При этом все основные аспекты услуг транспортного уровня по ISO/IEC 8072 сохраняются, за исключением параметра качества услуг.

Наряду с широко известными сетевыми архитектурами и сетевыми технологиями OSI, X.25, ISDN, Frame Relay, ATM, SDH/SONET, а также стандартными технологиями локальных сетей семейства IEEE 802 (Ethernet, Token Ring, FDDI).

Технология SMDS, получившая название «коммутируемая многомегабитовая служба передачи данных», разработана компанией Bellcore. По ее определению, SMDS – это «высокоскоростная служба коммутации пакетов общего пользования, работающая в режиме без установления соединения и предназначенная для расширения локальных сетей за пределы оборудования пользователя через глобальные или региональные вычислительные сети». Эта служба может использоваться для многих применений, включая взаимосвязи локальных сетей, высокоскоростной доступ к удаленным базам данных, пакетная передача аудио- и видеоинформации, распределение ресурсов, передача изображений или телерадиология. При этом SMDS может обеспечивать взаимодействия с другими широкополосными технологиями, такими как Frame Relay и ATM. SMDS обеспечивает скорости передачи данных 56/64 Кбит/с (DS0), 1544 Мбит/с (DS1) и 44736 Мбит/с (DS3).

Спецификация NetBIOS, опубликованная в 1984 году корпорацией IBM под названием «IBM PC Network Technical Reference Manual», определила интерфейс и услуги сети IBM PC и совместимых систем, коллективно использующих общую широкополосную физическую среду. Предусмотрены два режима работы – сются динамически.

Поскольку служба NetBIOS сконструирована на основе различных протоколов и различного оборудования, то для обеспечения взаимодействия NetBIOS в Internet RFC 1001 и 1002 определили стандартный протокол для функционирования прикладных программ NetBIOS над протоколами TCP и UDP. Кроме того, поскольку для выполнения некоторых приложений NetBIOS типа серверов файлов ПК не подходят, то RFC 1001 и 1002 определили возможность построения реализаций на системах любого типа, где имеется комплект протоколов TCP/IP.

С другой стороны, RFC 1088 определил стандартный метод инкапсуляции датаграмм протокола IP в датаграммы NetBIOS с тем, чтобы обеспечить возможность работы в компьютерах сети NetBIOS прикладных программ Internet, работающих над IP. Кроме того определено преобразование 4-байтовых адресов IP в 16-байтовые имена NetBIOS. Использование маршрутизаторов, способных инкапсулировать пакеты IP в обычные протоколы уровня звена данных (типа протоколов локальных сетей), а также в датаграммы NetBIOS, позволяют компьютерам NetBIOS взаимодействовать со всей Internet.

Протокол PPP обеспечивает стандартный метод транспортирования многопротокольных датаграмм по двухпунктовым каналам. PPP определяет расширяемый Link Control Protocol и поддерживает семейство различных протоколов сетевого уровня NCP (Network Control Protocols). RFC 2097 определил один из протоколов NCP, поддерживаемых PPP, для функционирования протокола сетевого уровня NBFCP сети NetBIOS над PPP.

Высокопроизводительный параллельный интерфейс HIPPI, разработанный в конце 80-х – начале 90-х рабочей группой ANSI X3T9.3 HIPPI, представляет собой простой канал данных. Пара таких каналов обеспечивает одновременный прием и передачу данных на скорости 800 Мбит/с и факультативно 1600 Мбит/с.

Структура связей протокольных модулей

Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети internet, изображена на рис.1. Прямоугольники обозначают обработку данных, а линии, соединяющие прямоугольники, - пути передачи данных. Горизонтальная линия внизу рисунка обозначает кабель сети Ethernet, которая используется в качестве примера физической среды; "o" - это трансивер. Знак "*" - обозначает

Рисунок 8.2. Структура протокольных модулей в узле сети TCP/IP

IP-адрес, а "@" - адрес узла в сети Ethernet (Ethernet-адрес). Понимание этой логической структуры является основой для понимания всей технологии internet. В дальнейшем мы будем часто ссылаться на эту схему.

8.10 Потоки данных

Рассмотрим потоки данных, проходящие через стек протоколов. В случае использования протокола TCP (Transmission Control Protocol - протокол управления передачей), данные передаются между прикладным процессом и модулем TCP. Типичным прикладным процессом, использующим протокол TCP, является модуль FTP (File Transfer Protocol протокол передачи файлов). Стек протоколов в этом случае будет FTP/TCP/IP/ENET. При использовании протокола UDP (User Datagram Protocol - протокол пользовательских датаграмм), данные передаются между прикладным процессом и модулем UDP. Например, SNMP (Simple Network Management Protocol - простой протокол управления сетью) пользуется транспортными услугами UDP. Его стек протоколов выглядит так: SNMP/UDP/IP/ENET.

Модули TCP, UDP и драйвер Ethernet являются мультиплексорами n x 1. Действуя как мультиплексоры, они переключают несколько входов на один выход. Они также являются демультиплексорами 1 x n. Как демультиплексоры, они переключают один вход на один из многих выходов в соответствии с полем типа в заголовке протокольного блока данных.

Когда Ethernet-кадр попадает в драйвер сетевого интерфейса Ethernet, он может быть направлен либо в модуль ARP (Address Resolution Protocol адресный протокол), либо в модуль IP (Internet Protocol - межсетевой протокол). На то, куда должен быть направлен Ethernet-кадр, указывает значение поля типа в заголовке кадра.

Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть переданы либо модулю TCP, либо UDP, что определяется полем "протокол" в заголовке IP-пакета.

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

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

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

Хотя технология internet поддерживает много различных сред передачи данных, здесь мы будем предполагать использование Ethernet, так как именно эта среда чаще всего служит физической основой для IP-сети. Машина имеет одну точку соединения с Ethernet. Шестибайтный Ethernet-адрес является уникальным для каждого сетевого адаптера и распознается драйвером.

Машина имеет также четырехбайтный IP-адрес. Этот адрес обозначает точку доступа к сети на интерфейсе модуля IP с драйвером. IP-адрес должен быть уникальным в пределах всей сети Internet.

Работающая машина всегда знает свой IP-адрес и Ethernet-адрес.

Вопросы для самоконтроля:

1. Какие три метода коммутации используются в сетях для соединения абонентов?

2. Опишите, каким образом происходит коммутация сообщений?

3. В чем особенность коммутации пакетов в виртуальных каналах?

4. Опишите структуру связей протокольных модулей.

5. Как устанавливается физическое соединение между вызывающим и вызываемым абонентом?

6. Как передается сообщение при использовании коммутации сообщений?

7. Назовите функции протокола на сетевом уровне.

8. Являются ли диаграммные средства ориентированными на подключение?

9. Как называют сложную сеть с коммутацией пакетов?

10. Что такое скорость подключения?

11. Что такое цифровые каналы и аналоговые каналы, наиболее распространенные их примеры.

12. Расскажите что такое маршрутизатор. модели.

13. Должна ли модель модема соответствовать количеству проводов в линии.

14. Почему все провайдеры Internet используют линию Unix, ее преимущества.

15. Архитектура протоколов, общая их классификация.