Название книги в оригинале: Фейт Сидни М. TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

A- A A+ Белый фон Книжный фон Черный фон

На главную » Фейт Сидни М » TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security).





section section title { page-break-before: auto } image + p { page-break-before: avoid; margin-bottom: 1em; } cite + emphasis { text-decoration: underline }

Читать онлайн TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security). Фейт Сидни М.

TCP/IP

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

 Сделать закладку на этом месте книги

Посвящается моему мужу и другу Вальтеру.


Предисловие

 Сделать закладку на этом месте книги

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

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

В книге описана терминология, концепции и механизмы TCP/IP. Рассматриваются стандарты, определяющие работу этих протоколов, а также методы работы с приложениями TCP/IP: каким образом выполняются фоновые процессы и как диагностировать состояние сетевых ресурсов. Для тех, кому это необходимо, приведено детальное (на уровне бит и байт) описание структур сетевых сообщений и информационных потоков при обмене этими сообщениями. Обсуждается работа программного интерфейса socket и приводятся примеры клиентских и серверных программ.

В данном издании существенно расширен объем материала. Целая глава посвящена наиболее распространенным коммуникационным протоколам. Отдельные главы описывают систему именования доменов, Word Wide Web, сетевые новости и приложения Gopher. Приведены сведения о следующем поколении протокола IP (версия 6). Средства безопасности рассматриваются на протяжении всей книги, но есть и отдельная глава по этой теме.

Сидни М. Фейт (Sidnie M. Feit)

Благодарности

 Сделать закладку на этом месте книги

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

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

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

Компания Netmanage, Inc. предоставила последнюю версию Chameleon NFS (включающую Personal Web Server ) и программное обеспечение сетевого мониторинга NewtWatch. Сценарии сетевого управления выполнялись с помощью HP Open View for Windows Workgroup Node Manager . Компания Network General предоставила монитор Sniffer , подробную документацию, советы и много мегабайт отчетов отслеживания работы протоколов. Компания Ashmount Research Ltd. предоставила программу для Windows под названием NSLookup .

Многие другие производители предложили свои продукты и техническую информацию. Компания FTP Software, Inc. поделилась своими программными продуктами для Windows и технической документацией к ним. Производители, и среди прочих Cisco Systems и Bay Systems, тщательно и подробно отвечали на все возникшие при работе над книгой вопросы о производимых ими продуктах.

Предисловие к русскому изданию

 Сделать закладку на этом месте книги

По тематике протоколов TCP/IP существует достаточно обширная литература, в том числе на русском языке (например, издательство "Лори" выпустило книгу Тодда Леммла, Моники Леммл и Джеймса Челлиса "TCP/IP. Учебное руководство для специалистов MCSE"). Однако эти книги в основном имеют инженерную направленность. Две-три первые главы в них посвящены теоретическим вопросам TCP/IP, а далее идет описание конкретных реализаций на уровне устройств и программных продуктов. Прогресс в области компьютерной техники ведет к тому, что приводимые в этих изданиях сведения быстро устаревают.

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

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

Хотя читателю более известны понятия из теории операционных систем, связанные с MS DOS или Windows, в данной книге в основном рассматриваются примеры из Unix. Мы не стали комментировать специфику стандартных средств этой операционной системы. Заметим только, что системные команды часто именуются программами, поскольку каждая из них реализуется отдельной программой. За более подробными сведениями можно обратиться к различным книгам издательства "Лори" по тематике Unix, в частности к прекрасной книге Кеннета Розена, Ричарда Розински, Джеймса Фарбра и Дугласа Хорста "Unix System V Release 4".

М. Кузьмин Издательство "Лори" Москва

Введение

 Сделать закладку на этом месте книги

I.1 Основы

 Сделать закладку на этом месте книги

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

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

■ Программные средства были лицензионными (мы будем использовать для proprietary перевод "лицензионные", в смысле коммерческие и не доступные для бесплатного использования. — Прим. пер .) и работали только с оборудованием того же производителя.

■ Поддерживался только ограниченный набор локальных и региональных сетей.

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

■ Отсутствие гибкости не позволяло объединить уже существующие сети недорогими и простыми в работе средствами.

Эта ситуация изменилась с появлением протокола управления передачей/протокола Интернета (Transmission Control Protocol/Internet Protocol — TCP/IP) и порождаемыми им технологиями маршрутизации.

Сегодня компьютерные сети организаций стали взаимосвязанными системами. В организациях локальными сетями (Local Area Network — LAN) объединяются настольные рабочие станции (workstation), серверы (server) и хосты (host). Локальные сети (ЛС) соединяются с другими ЛС и региональными сетями (Wide Area Network — WAN).

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

I.2 Приложения TCP/IP

 Сделать закладку на этом месте книги

С самого начала в TCP/IP было заложено несколько важных свойств для служб работы с приложениями:

■ Терминальный доступ к любому хосту

■ Возможность копирования файлов с одного хоста на другой

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

С течением времени в наборе протоколов TCP/IP появились и другие возможности, очень важные для приложений:

■ Печать на удаленном принтере (Remote Printing)

■ Работа с сетевой файловой системой (Network File System — NFS)

■ Сетевые новости (Network News)

■ Gopher

■ Word Wide Web (WWW — Иногда эту службу Интернета в русскоязычной литературе называют "Всемирной паутиной", однако мы будем придерживаться более распространенного среди специалистов названия WWW. — Прим. пер .)

Кроме того, расширился набор утилит администрирования и обслуживания сети. Среди новых средств можно назвать:

■ Службу каталогов для отображения содержательных сетевых имен хостов на их физические сетевые адреса

■ Протокол динамического конфигурирования хоста (Dynamic Host Configuration Protocol — DHCP)

■ Сетевое управление хостами, маршрутизаторами (router) и другими сетевыми устройствами

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

Приложения для WWW привели к революционным переменам в вычислениях клиент/сервер и полностью преобразили методы выполнения прикладных расчетов.

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

I.3 Терминология

 Сделать закладку на этом месте книги

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

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

I.3.1 Протоколы, элементы, стеки и наборы

 Сделать закладку на этом месте книги

Протоколом  (protocol) называется набор правил для одной из коммуникационных функций. Например, протокол IP представляет собой набор правил для маршрутизации данных, a TCP определяет правила для надежной и последовательной доставки данных.

Элемент данных протокола  (protocol data unit — PDU), или пакет  (packet) — это форматированный элемент данных, который передается по сети. Пересылаемая в таком пакете информация часто называется полезной нагрузкой (payload).

Стек протоколов  (protocol stack) представляет собой набор организованных по уровням протоколов, которые, работая совместно, позволяют приложениям обмениваться данными. Например, стеком является набор протоколов TCP, IP и Ethernet.

Набор протоколов  (protocol suite) — это семейство протоколов, работающих совместно и связанных между собой. Набор протоколов TCP/IP обеспечивает множество различных возможностей, начиная от динамического определения адреса сетевого адаптера и заканчивая службой каталогов, определяющей способ доставки сообщения электронной почты.

I.3.2 Хосты

 Сделать закладку на этом месте книги

Хостом  называется компьютер, который выполняет приложения и имеет одного или нескольких пользователей. Поддерживающий TCP/IP хост работает как конечная точка сетевой коммуникации. Отметим, что персональные компьютеры (ПК), рабочие станции, мини-компьютеры или большие ЭВМ подпадают под определения хоста и каждый из этих компьютеров может реализовать стек TCP/IP.

В книге будут также использоваться термины: "станция"  (station), "компьютер"  (computer) и "компьютерная система"  (computer system) как синонимы термина "хост" .

I.3.3. Маршрутизаторы

 Сделать закладку на этом месте книги

Маршрутизатор  (router) управляет пересылкой данных по сети. Первоначально в стандартах TCP/IP использовался термин шлюз  (gateway), однако в области производства большее распространение получил термин "маршрутизатор". В области коммуникаций термин "шлюз"  определяет систему, выполняющую некоторое преобразование протокола.

В книге будет применяться термин "маршрутизатор",  однако при обращении к документации по стандартам TCP/IP нужно помнить, что в них используется термин "шлюз" .

I.3.4 Интернет

 Сделать закладку на этом месте книги

Термин "интернет"  (со строчной буквы) обозначает сетевую среду (локальную или региональную), объединенную с помощью маршрутизаторов. Интернет  (с прописной буквы) определяет сообщество из сетей интернета, объединяющее тысячи компьютеров.

I.3.5 Сетевой узел, система и элемент сети

 Сделать закладку на этом месте книги

Термины "сетевой узел " (network node), "система"  (system) и "элемент сети"  (network element) служат для обозначения такого коммуникационного объекта сети, для которого не указаны специализированные свойства (т.е. не задано, что это хост, маршрутизатор или иное устройство, например мост). Пример: "Целью обслуживания сети является управление и мониторинг всех ее узлов" .

I.3.6 ЛС, региональные сети и связи

 Сделать закладку на этом месте книги

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

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

I.3.7 Люди

 Сделать закладку на этом месте книги

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

I.3.8 Байты и октеты

 Сделать закладку на этом месте книги

Наиболее часто под байтом  (byte) понимается группа из восьми бит. Однако слово "байт" означает и наименьшую адресуемую часть памяти компьютера. Время от времени некоторые производители компьютеров создают машины с иным размером байтов информации.

Общепринятым для технической документации является термин октет  (octet), который всегда определяет ровно 8 бит данных. В книге мы будем использовать слова "байт" и "октет" как синонимы, а для обозначения байтов, не равных 8 бит, применять термин "логический байт"  (logical byte).

I.3.9 Стиль "тупоконечников" и "остроконечников"

 Сделать закладку на этом месте книги

Некоторые компьютеры хранят данные начиная от наиболее значимого бита. Такой стиль называется стилем "тупоконечников"  (Big Endian). Однако другие компьютеры первым размещают менее значимый бит — стиль "остроконечников"  (Little Endian; — Оба выражения заимствованы из романа Дж. Свифта "Путешествие Гулливера". — Прим. пер .)

Аналогичные названия имеют и стили для стандартов коммуникационного обмена данными, которые зависят от очередности передачи битов.

Стандарты для протоколов Интернета предполагают стиль "тупоконечников". Однако некоторые организации, например Институт инженеров по электротехнике и электронике (IEEE), предлагают при передаче начинать пересылку с битов или байтов наименьшей значимости (для обычных арабских чисел наименьшую значимость имеет крайняя правая цифра, а наибольшую — крайняя левая. — Прим. пер .).

I.4 Реализации с использованием оборудования различных производителей

 Сделать закладку на этом месте книги

В отличие от использовавшихся ранее лицензионных сетевых протоколов TCP/IP реализованы на компьютерах различных производителей и могут использовать программное обеспечение независимых компаний.

Реализация базировалась на принятых стандартах и бесплатном программном обеспечении, разработанном добровольцами. Строгие ограничения содержатся в дополнительных документах Host Requirements  (требования к хостам) и Router Requirements  (требования к маршрутизаторам).

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

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

Следовательно, любой из описанных в этой книге механизмов необязательно будет реально реализован в любом из программных продуктов. При покупке программного обеспечения TCP/IP для хоста нужно всегда проверять его на соответствие документу Host Requirements . Разработчик должен ответить на все вопросы о реализации в своем продукте любой из определенных в этом документе возможностей (эти возможности определяются как "должен и обязан" — must and should).

Разработчикам программного обеспечения можно рекомендовать внимательно изучить по этой книге все, что  должны поддерживать протоколы, равно как и то, каким образом  это должно быть реализовано. Однако одной этой книги будет недостаточно. Дело в том, что стандарты TCP бесплатно доступны в интерактивном виде (см. приложение В). Эти документы постоянно находятся в состоянии доработки — в них включаются новые возможности и более совершенные механизмы реализации и исключаются устаревшие разделы.

I.5 Диалоги

 Сделать закладку на этом месте книги

В книге приведено много примеров интерактивных диалогов (листингов работы пользователя). Текстовые диалоги были получены на компьютерах компании Sun Microsystems. Во многих примерах работа проводилась с хостом tigger.jvnc.net,  который находится в Принстоне (Нью-Джерси). Это большой сервер , обслуживаемый провайдером Global Enterprise Systems  (GES), который ранее назывался JVNC  (именно поэтому имя сервера заканчивается на jvnc.net ). Статистические данные о работе этого сервера  заслуживают внимания, поскольку он взаимодействует через Интернет со многими хостами  по всему миру. Несколько примеров были получены на компьютерах Йельского университета.

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

Несколько примеров представляют работу с графическим пользовательским интерфейсом (Graphical User Interface — GUI) для приложений TCP/IP, выполняющихся на компьютерах Windows и Macintosh. Некоторые из этих примеров показывают работу приложения Chameleon  компании Netmanage и браузера Netscape Navigator  компании Netscape, Inc. Отдельные экраны получены в HP Open View for Windows Workgroup Node Manager  компании Hewlett-Packard и NSLookup for Windows  компании Ashmount Research Ltd. Работа электронной почты демонстрируется на примере Eudora  компании Qualicomm для компьютеров Macintosh.

I.6 Дополнительная литература

 Сделать закладку на этом месте книги

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

В приложении В приведен список документов, которые определяют TCP/IP и связанные с этими протоколами возможности. Приложение С посвящено службам сетевых информационных центров (Network Information Center — NIC). Там же рассмотрены способы обращения в эти центры. Приложение D содержит примеры более эффективного использования IP-адресов (маски подсети переменной длины).

Глава 1

TCP/IP: что это такое и откуда взялось

 Сделать закладку на этом месте книги

1.1 Введение

 Сделать закладку на этом месте книги

В конце 60-х гг. Агентство перспективных исследовательских проектов (Advanced Research Project Agency — ARPA) Министерства обороны США (позднее переименованное в DARPA) начало сотрудничать с университетами и другими исследовательскими организациями в области новых технологий обмена данными.

Все эти организации совместно разработали Сеть агентства перспективных исследовательских проектов (Advanced Research Project Agency Network — ARPANET), первую сеть с коммутацией пакетов. Экспериментальный вариант этой сети из четырех узлов был запущен в эксплуатацию в 1969 г. Реализация прошла успешно, а ее возможности были протестированы на сети, протянувшейся через всю территорию США. В 1975 г. Агентство оборонных коммуникаций взяло на себя ответственность за эксплуатацию созданной сети, которая все еще рассматривалась как экспериментальный вариант.

1.1.1 Зарождение TCP/IP

 Сделать закладку на этом месте книги

Первые протоколы ARPANET работали медленно и часто приводили к краху сетевых коммуникаций. В статье Винтона Г. Серфа и Роберта Е. Кана A Protocol for Packet Network Interconnections (журнал IEEE Transactions of Communications , май 1974 г.) был предложен новый набор основных протоколов. В этой работе были заложены основы для последующей разработки протокола Интернета  (IP) и протокола управления передачей  (TCP). Начиная с 1980 г., потребовалось около трех лет для преобразования хостов ARPANET на новые протоколы (число хостов к тому времени приближалось к 100).

Возможности новых протоколов были продемонстрированы в 1978 г., когда терминал, расположенный на движущемся по Калифорнии автофургоне, переслал данные, сформированные в пакеты, на узел SRI International через всю территорию США и далее по спутниковой связи на хост в Лондоне (см. рис. 1.1).



Рис. 1.1. Демонстрация роботы TCP/IP с использованием нескольких различных сетевых технологий

В начале 80-х гг. ARPANET была полностью переделана на новые протоколы. К 1983 г. эта сеть содержала уже более 300 узлов и предоставляла своим пользователям обширные ресурсы. В 1984 г. исходная сеть ARPANET была разделена на две отдельные сети: первая, сохранившая исходное название, предназначалась для исследований и новых разработок, вторая — названная MILNET — стала неклассифицированной сетью для военных целей.

В начале 80-х гг. ARPANET была полностью переделана на новые протоколы. К 1983 г. эта сеть содержала уже более 300 узлов и предоставляла своим пользователям обширные ресурсы. В 1984 г. исходная сеть ARPANET была разделена на две отдельные


убрать рекламу







сети: первая, сохранившая исходное название, предназначалась для исследований и новых разработок, вторая — названная MILNET — стала неклассифицированной сетью для военных целей.

1.2 Принятие новых протоколов

 Сделать закладку на этом месте книги

В 1982 г. Министерство обороны США (Department of Defence — DOD) заимствовало набор коммуникационных протоколов ARPANET в качестве источника для формирования собственных распределенных вычислительных сетей.

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

1.3 Характеристики TCP/IP

 Сделать закладку на этом месте книги

TCP/IP обладает уникальными характеристиками, которые обеспечивают долговечность этих протоколов. Архитектура TCP/IP позволяет объединять сетевые кластеры, формируя то, что называется "интернетом" . Для пользователя интернет выглядит как одна большая сеть, сформированная из всех хостов, подключенных к отдельным сетевым кластерам.

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

1.3.1 Доступность TCP/IP

 Сделать закладку на этом месте книги

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



Рис. 1.2. TCP/IP — окружение для оборудования от различных производителей и различных сетей

Министерство обороны США обеспечило доступность TCP/IP, реализовав эти протоколы в Unix (по именам разработчиков — BBN — Bolt, Beranek, Newman). Далее Калифорнийский университет в Беркли использовал код BBN в операционной системе Berkeley Software Distribution (BSD) версии 4.2 (одна из разновидностей UNIX). Эта операционная система и ее более поздние версии были реализованы на многих аппаратных базах. Позднее TCP/IP был добавлен и в System V Unix компании AT&T.

В 90-х гг. TCP/IP начали использоваться в коммерческих программных продуктах и стали наиболее универсальными протоколами из доступных на рынке. Процесс интеграции протоколов TCP/IP в серверы и настольные системы был поистине стремительным.

Кроме того, поддержка TCP/IP реализована практически во всех сетевых технологиях (см. главу 4).

1.4 Интернет

 Сделать закладку на этом месте книги

Кроме простоты при объединении нескольких сетей, протоколы TCP/IP открыли дорогу для объединения с ARPANET сетей университетов и исследовательских организаций, что в конечном итоге привело к созданию суперсети Интернет . На протяжении 80-х годов магистральные соединения Интернета обеспечивались средствами ARPANET.

Характеристики протоколов TCP/IP обеспечили стабильное и единообразное расширение сети Интернет, которая стала самой большой всемирной сетью, объединяющей правительственные и военные сети, а также сети университетов и коммерческих организаций (каждая из которых может сама состоять из сотен подсетей). В 1985 г. была организована новая магистральная сеть National Science Foundation Net (NSFNET), которая обеспечила скоростные соединения для исследовательских центров и суперкомпьютеров.

Благодаря правительственной поддержке была сформирована инфраструктура региональных служб провайдеров  (regional Service Provider), охватившая всю территорию США. Университеты и исследовательские лаборатории подключались к ближайшему региональному провайдеру, который обеспечивал магистральные соединения внутри общей сети.

Стремительное расширение Интернета привело к формированию провайдеров в десятках стран по всему миру.

В 1994 г. в Интернете уже были объединены миллионы компьютеров, и эта область стала реальным сектором рынка компьютерных технологий. Поддержка сети осуществлялась National Science Foundation (NSF), а соединенные между собой провайдеры США образовали огромный коммутирующий центр, распределенный по всей территории страны.

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

1.5 INTERNIC

 Сделать закладку на этом месте книги

Многие годы координирующую роль в Интернете осуществляло Министерство обороны США. Принадлежащий ему комитет (DDN Network Information Center — DDN NIC) обслуживал пользователей, системных администраторов, координаторов сайтов и администраторов сетей.

Весной 1993 г. обслуживание гражданских пользователей Интернета было передано в National Science Foundation, которая в настоящее время состоит из двух агентств:

■ InterNIC Registration Services  (служба регистрации InterNIC), принадлежащая Network Solutions, Inc. (Герндон, Вирджиния)

■ InterNIC Directory and Database Services  (служба каталогов и баз данных InterNIC), принадлежащая AT&T

Дополнительные регистрационные центры были созданы и в других странах мира. Такие центры координируют именование и адресацию компьютеров в Интернете.

InterNIC Directory and Database Services служит депозитарием стандартов Интернета и других информационных документов. Все документы доступны бесплатно.

В приложении С приведены дополнительные сведения об InterNIC и других информационных центрах Интернета.

1.6 IAB, IETF и IESG

 Сделать закладку на этом месте книги

Разработка новых протоколов TCP/IP и обслуживание старых координируется Советом по архитектуре Интернета (Internet Architecture Board — IAB, который ранее назывался Internet Activities Board). IAB идентифицировал техническую специализацию новых средств. Например, в прошлом IAB направлял исследовательские работы по созданию новых протоколов сетевого управления, более функциональных протоколов маршрутизации и следующих версий IP.

В 1992 г. была сформирована Ассоциация Интернета  (Internet Society), в которую и вошла IAB. Целью Internet Society является помощь в расширении и обеспечении успешной работы Интернета.

IAB контролировала несколько важных групп: рабочую группу технологии Интернета  (Internet Engineering Task Force — IETF), которая разрабатывает и реализует новые протоколы, управляющую группу технологии Интернета  (Internet Engineering Steering Group — IESG), которая осуществляет руководство и контроль за деятельностью IETF.

1.6.1 Рабочие группы и разработка протоколов

 Сделать закладку на этом месте книги

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

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

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

1.6.2 Другие источники протоколов Интернета

 Сделать закладку на этом месте книги

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

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

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

1.7 Requests For Comments

 Сделать закладку на этом месте книги

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

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

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

InterNIC обслуживает индексы для RFC, а для устаревших документов предоставляется номер заменяющего RFC. Например, индекс для RFC 1098 (стандарт SNMP) содержит ссылки на устаревший документ RFC (1067) и пополняющий RFC 1098 документ с номером 1157:

1098 Case, J.D.; Fedor, М.; Schoffstall, M.L.; Davin, С.

Simple Network Management Protocol (SNMP). 1989 April; 34p.

(Format: TXT=71563 bytes) (Obsoletes RFC 1067; Updated by RFC 1157)

He все RFC описывают протоколы. Некоторые из них служат для систематизации и описания сведений, используемых в Интернете. Существует RFC с рекомендациями по выбору имен для компьютеров. Другой RFC содержит руководство по администрированию сетей TCP/IP и реализации в них средств безопасности. Имеются RFC, описывающие стратегии повышения производительности, экспериментальные алгоритмы или обсуждающие этические вопросы Интернета. После пересмотра некоторые RFC получают статус документов Best Current Practices  — BCP (описание лучшего текущего способа применения).

1.7.1 Состояние и статус стандартов

 Сделать закладку на этом месте книги

IAB периодически публикует информацию о работе над протоколами. Стадии разработки определяют текущее состояние  протокола:

■ Experimental (экспериментальный)

■ Proposed (предлагаемый)

■ Draft (черновик)

■ Standard (стандарт)

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

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

■ Required (требуется использовать)

■ Recommended (рекомендован к применению)

■ Elective (необязателен)

■ Limited Use (ограниченное использование)

■ Not recommended (не рекомендован к применению)

Текущий статус и состояние протоколов Интернета описываются в RFC, называемом IAB Official Protocol Standards  (официальные стандарты протоколов IAB). Этот документ периодически изменяется, отражая изменение номеров RFC.

1.7.2 Присвоенные номера

 Сделать закладку на этом месте книги

Сетевые параметры, специальные сетевые адреса, имена служб и стандартные идентификаторы терминалов либо компьютерных систем перечислены в RFC с именем Assigned Numbers  (присвоенные номера).

Присвоенные номера Интернета администрируются организацией авторизации присвоенных номеров  (Internet Assigned Numbers Authority — IANA), расположенной в настоящее время в Институте информационных служб университета Южной Калифорнии.

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

1.7.3 RFC и стимулирование сетевого взаимодействия продуктов различных производителей

 Сделать закладку на этом месте книги

То, что пользователи не должны придерживаться только одной компьютерной архитектуры, стало главной причиной одобрения TCP/IP в качестве коммуникационных стандартов правительственными учреждениями США. Эти организации желали покупать оборудование на рынке с реальной конкуренцией, когда предъявляемым требованиям удовлетворяет продукция различных разработчиков. Принятие и обслуживание стандартов должно было привести к снижению цен и лучшему качеству услуг.

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

■ Стандарты часто содержат необязательные возможности. При реализации различными производителями это может усложнить взаимодействие.

■ Разработчики иногда не до конца понимают требования стандартов, вследствие чего их продукты работают не вполне корректно.

■ Возможны ошибки в спецификациях стандартов.

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

■ Отдельная система с неудовлетворительными характеристиками пересылки или приема/передачи данных (за счет использования неэффективных алгоритмов) может снизить производительность всех систем сети.

Два документа RFC (октябрь 1989 г.) были посвящены как указанным проблемам, так и коррекции ошибок, разъяснению определений, спецификации необязательных возможностей, перечислению конфигурационных параметров и идентификации наиболее производительных алгоритмов. Наиболее важно то, что в этих документах специфицируются единые требования к реализации хостов. В прошлом сказывалось отсутствие этих документов. Корректность операций, взаимодействие и производительность существенно улучшились при строгом соблюдении требований следующих RFC:

RFC 1122, Requirements for Internet Hosts — Communication Layers  (Требования к хостам Интернета — уровни взаимодействия). В этом документе описывается уровень связи данных, IP и TCP.

RFC 1123, Requirements for Internet Hosts — Application and Support  (Требования к хостам Интернета — приложения и их поддержка). Этот документ определяет удаленную регистрацию, пересылку файлов, электронную почту и различные прикладные службы.

В 1995 г. был опубликован документ, относящийся к операциям маршрутизаторов:

RFC 1812 Requirements for IP Version 4 Routers  (Требования к маршрутизаторам для протокола IP версии 4).

1.7.4 Связанные документы

 Сделать закладку на этом месте книги

Серия RFC не содержит спецификаций протоколов и была опубликована как отдельный набор документов For Your Information  (FYI — К вашему сведению). Например: RFC 1325 Answers to commonly asked "new Internet user" questions  (Ответы на наиболее распространенные вопросы новых пользователей Интернета).

Еще одна серия, Internet Engineering Notes  (IEN — Заметки по технологии Интернета), содержит набор дискуссионных материалов, написанных еще в первые годы разработки протоколов Интернета.

1.8 Другие информационные ресурсы

 Сделать закладку на этом месте книги

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

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

1.9 Open System Interconnection

 Сделать закладку на этом месте книги

Взаимодействие открытых систем  (Open System Interconnection — OSI) стало результатом международных усилий по созданию компьютерных коммуникационных стандартов и базовых прикладных служб. Формально OSI разработана в рамках Международной организации по стандартизации  (International Organization for Standardization — ISO), созданной для поддержки обмена и кооперации в сфере научных исследований и технологий. Стандарты ISO публикуются как документы этой организации.

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

Протоколы OSI используются только на небольшом числе европейских сайтов, но IETF опубликовала несколько RFC, относящихся к взаимодействию окружений TCP/IP и OSI.

Глава 2

Обзор служб набора протоколов TCP/IP

 Сделать закладку на этом месте книги

2.1 Введение

 Сделать закладку на этом месте книги

Почему семейство протоколов TCP/IP получило столь широкое распространение? Прежде всего, благодаря способности к взаимному объединению гетерогенных локальных и глобальных сетей. Не менее важной является способность создавать основы для коммуникаций "равный с равным" (peer-to-peer), а также базовых служб поверх такого взаимодействия. Кроме того, с самого начала протоколы TCP/IP ориентировались на поддержку взаимодействия типа клиент/сервер.

2.2 Коммуникации между приложениями

 Сделать закладку на этом месте книги

Существует два основных типа взаимодействия между приложениями. Первый тип — связи, ориентированные на создание соединения  (connection-oriented), — применяется при работе приложения с потоком данных. Второй вариант — связи без создания соединения  (connectionless) — предполагает обмен независимыми сообщениями и подходит для случайных взаимодействий между приложениями при небольшом объеме пересылаемых данных.

2.2.1 Коммуникации с созданием соединений (TCP)

 Сделать закладку на этом месте книги

Протокол TCP  (Transmission Control Protocol) отвечает в TCP/IP за надежные коммуникации с созданием соединения по принципу "равный с равным". Сеанс регистрации с терминала и пересылка файлов выполняются с помощью TCP.

2.2.2 Коммуникации без создания соединений (UDP)

 Сделать закладку на этом месте книги

Некоторые операции обмена данными не требуют постоянного взаимодействия систем. Например, база данных на сетевом сервере может содержать таблицы имен сотрудников компании и их телефонные номера. Узнать номер телефона конкретного сотрудника можно при передаче на сервер запроса с указанием имени этого сотрудника. Сервер должен будет ответить сообщением, содержащим соответствующий телефонный номер. Такой тип взаимодействия поддерживается протоколом пользовательских датаграмм  (User Datagram Protocol — UDP).

2.2.3 Интерфейс программирования socket

 Сделать закладку на этом месте книги

Реализации TCP/IP обычно предоставляют для разработчиков коммуникационный программный интерфейс. Многие из таких интерфейсов основаны на программном интерфейсе socket  (дословно — "штепсельная розетка", "гнездо"), который первоначально был разработан для операционной системы Unix университета Беркли.

К программному интерфейсу socket относятся:

■ Простые подпрограммы для создания, пересылки и приема независимых сообщений, используемых при коммуникациях без создания соединения по протоколу UDP

■ Программы для создания соединения TCP, передачи и приема данных, а также для закрытия созданного соединения

2.2.4 Программный интерфейс RPC

 Сделать закладку на этом месте книги

Хотя и не так широко распространенный, как socket, программный интерфейс вызова удаленных процедур  (Remote Procedure Call — RPC) для соединений типа клиент/сервер достаточно часто используется в различных системах. Первоначально он был реализован в компьютерах компании Sun Microsystems, а затем перемещен на многие другие платформы.

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

Например, описанное в п. 2.2.2 приложение для просмотра телефонных номеров может быть реализовано через программы RPC.

2.3 Основные службы

 Сделать закладку на этом месте книги

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

2.3.1 Пересылка файлов

 Сделать закладку на этом месте книги

Пересылка файлов (file transfer) является старейшей службой TCP/IP. Протокол пересылки файлов (File Transfer Protocol — FTP) разрешает пользователю пофайловое копирование с одной системы на другую. FTP имеет дело с простыми типами файлов, такими как текстовые файлы в коде для обмена информацией Американского национального института стандартов (American National Standard Code for Information Interchange — ASCII) или неструктурированные двоичные файлы. FTP обеспечивает пользователю доступ к удаленной файловой системе для выполнения служебных операций: переименования и удаления файлов либо создания новых каталогов.

2.3.2 Доступ с терминала

 Сделать закладку на этом месте книги

В начале 70-х гг. многие производители компьютеров создавали модели терминалов, которые были совместимы только с их собственными компьютерными системами. Министерство обороны США закупало оборудование у различных производителей и, естественно, настаивало на обеспечении для каждого терминала единообразного доступа к любому компьютеру сети. Протокол терминального доступа telnet  сделал возможными такие операции для любого типа терминала. С течением времени telnet  расширил свои возможности по работе с самыми разнообразными моделями терминалов и операционными системами.

2.3.3 Электронная почта

 Сделать закладку на этом месте книги

Электронная почта (далее будем называть ее просто почтой, а когда речь пойдет об обычной почтовой службе, это будет оговорено дополнительно.— Прим. пер.)  привела к распространению TCP/IP среди многих конечных пользователей. Стандартизованы два аспекта п


убрать рекламу







очтовой службы:

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

■ Механизмы для направления и пересылки методом сохранить-переслать дальше при обмене почтовыми сообщениями между хостами. С первых дней Интернета для этого применяется простой протокол пересылки почты  (Simple Mail Transfer Protocol — SMTP). Более поздние расширения добавили этой службе новые функции.

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

На рис. 2.1 показано взаимодействие между хостами сети. Отметим, что TCP/IP полностью соответствует сетевой архитектуре "равный с равным" и любой из хостов может выступать как клиент или сервер, а также одновременно как клиент и сервер.



Рис. 2.1. Прикладные службы сети TCP/IP

2.3.4 Служба WWW

 Сделать закладку на этом месте книги

Word Wide Web (WWW) — наиболее привлекательная система из всех прикладных служб клиент/сервер, реализованных в TCP/IP. Пользователь может получить доступ к прекрасно оформленным документам, содержащим графические изображения и звуковые файлы, легко перемещаться между сайтами сети одним щелчком мыши и проводить поиск в огромных информационных архивах.

2.4 Дополнительные службы

 Сделать закладку на этом месте книги

К набору протоколов TCP/IP были добавлены и другие службы. Ниже рассмотрены наиболее популярные и широко распространенные.

2.4.1 Доступ к файлам

 Сделать закладку на этом месте книги

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

Многие продукты TCP/IP включают сетевую файловую систему (Network File System — NFS). Такие продукты поддерживают одну или обе роли NFS:

Доступ клиента к файлам.  Позволяет компьютеру получить доступ к удаленным файлам как к локальным. Конечный пользователь и локальные программы могут не учитывать реальное размещение файла в сети.

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

2.4.2 Новости

 Сделать закладку на этом месте книги

Приложения для работы с электронными новостями появились для обслуживания локальных электронных досок объявлений (bulletin board) и распространения находящихся на них данных на другие сайты сети.

Многие организации используют бесплатное программное обеспечение для публикации внешней информации электронным способом. Другие организуют доступ к группам новостей Интернета, на которых обсуждаются самые разнообразные темы, начиная от спорта и кончая физикой плазмы. Такое программное обеспечение применяется и для доступа к коммерческим информационным службам новостей, например к Рейтер, АР или UPI.

2.4.3 Служба имен DMS

 Сделать закладку на этом месте книги

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

Для создания соединения с хостом имя хоста должно быть преобразовано в его цифровой адрес. Первоначально каждый хост TCP/IP хранил полный список всех имен и адресов для хостов сети. Однако при стремительном расширении Интернета это стало невозможным, поскольку число хостов стало измеряться тысячами и миллионами.

Система именования доменов  (Domain Name System — DNS) предназначена для решения этой проблемы. DNS представляет собой базу данных для имен и адресов хостов, которая распределена по тысячам отдельных серверов. Протокол DNS разрешает пользователю послать запрос к базе данных локального сервера и получить ответ, который, возможно, придет от удаленного сервера.

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

2.4.4 Коммерческое программное обеспечение

 Сделать закладку на этом месте книги

Многие сторонние разработчики создают приложения, работающие поверх TCP/IP. Например, производители баз данных соединяют настольные компьютеры-клиенты с серверами средствами TCP/IP.

2.4.5 Управление сетью

 Сделать закладку на этом месте книги

По прошествии некоторого времени многие инструменты сетевого управления стали создаваться на основе набора протоколов TCP/IP. Например, существуют команды, позволяющие определить, находится ли конкретная система сети в рабочем состоянии, просмотреть ее текущую загрузку или получить список доступных в сети служб.

Такие команды очень полезны, но для централизации сетевого управления требуется единый и полный набор команд. В Интернете для этого был разработан простой протокол сетевого управления  (Simple Network Management Protocol — SNMP), позволяющий обслуживать любой сетевой узел, начиная от простейшего устройства и заканчивая операционной системой хоста или прикладным программным обеспечением.

2.4.6 Диалоги

 Сделать закладку на этом месте книги

Лучшим способом понять работу служб TCP/IP является их применение на практике. Эта глава завершается несколькими краткими примерами интерактивных диалогов, иллюстрирующими работу служб сети. Во всех диалогах вводимые пользователем команды напечатаны полужирным шрифтом. Это соглашение будет применяться по всей книге. Основы работы со службами достаточно просты.

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

2.4.7 Диалог доступа с терминала

 Сделать закладку на этом месте книги

Доступ с терминала является примером работы с простейшей службой. В приведенном ниже примере запрашивается соединение по telnet  с хостом bulldog.cs.yale.edu . После установки соединения telnet  информирует, что комбинация клавиш  CONTROL-] служит для возврата к сеансу с локальной системой. Затем удаленный хост выводит приглашение регистрации login :, и с этого момента начинается обычная работа с удаленным хостом, как если бы это был локальный компьютер.

> telnet bulldog.cs.yale.edu

Trying 128.36.0.3 ...

Connected to bulldog.cs.yale.edu

Escape character is '^]' .


login:

Хотя это очень простой диалог с пользователем, за кулисами происходит достаточно большая работа. Telnet  просматривает базу данных DNS и определяет, что адресом требуемой системы является 128.36.0.3. Именно этот адрес и будет использован telnet  для соединения с удаленным хостом.

Схемы именования и нумерации TCP/IP будут рассмотрены в главе 5. Однако уже сейчас можно понять, что имя состоит из нескольких разделенных точками слов, а адрес — из четырех цифр, также разделенных точками.

2.4.8 Просмотр имен в базе данных DNS

 Сделать закладку на этом месте книги

Как и многие системы TCP/IP, используемый нами локальный хост имеет клиентское приложение nslookup  (от network server lookup — просмотр сетевого сервера), которое разрешает пользователю интерактивно запросить базу данных DNS.

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

> nslookup

Default Server: DEPT-GW.CS.YALE.EDU

Address: 128.36.0.36


> bulldog.c8.yale.edu

Server: DEPT-GW.CS.YALE.EDU

Address: 128.36.0.36


Name: bulldog.cs.yale.edu

Address: 128.36.0.3

2.4.9 Диалог при пересылке файла

 Сделать закладку на этом месте книги

Далее можно использовать FTP для копирования файла chapter1  из каталога book  хоста plum.yale.edu  на локальный хост. Начинающиеся цифрами строки — это сообщения от сервера пересылки файлов. Команда cd  (change directory — изменить текущий каталог) служит для перехода к каталогу book  на удаленном хосте. Команда get  (получить) используется для копирования файла.

> ftp plum.yale.edu

Connected to plum.yale.edu

220 plum FTP server (SunOS 4.1) ready.


Name : icarus

331: Password required for icarus


Password :

230 User icarus logged in.


ftp> cd book

250 CWD command successful.


ftp> get chapter1

200 PORT command successful.

150 ASCII data connection for chapter1 (130.132.23.16,3330) (32303 bytes).

226 ASCII Transfer compete.

32303 bytes received in 0.95 seconds (33 Kbytes/s)


ftp> quit

221 Goodbye.

Пересылка файла упрощается в приложении для настольного компьютера с графическим пользовательским интерфейсом (Graphical User Interface — GUI). На рис. 2.2 показано копирование файла на персональный компьютер в приложении Chameleon  компании Netmanage. Перечисленные справа файлы находятся на сервере Unix. Один из них (с именем Index-byname) выбран для копирования. После копирования ему будет присвоено имя index.txt, которое указано в левом окне. Операция копирования запускается щелчком мыши на командной кнопке со стрелкой или при перетаскивании значка файла.



Рис. 2.2. Пересылка файла через приложение для настольного компьютера

2.4.10 WWW

 Сделать закладку на этом месте книги

Можно копировать файлы и с серверов WWW, не задумываясь об их реальном размещении. На рис. 2.3 показан экран браузера Netscape Navigator . Новые документы извлекаются щелчком мыши на одной из выделенных фраз. Далее их можно сохранить на локальном диске через меню File/Save.



Рис. 2.3. Использование браузера Netscape 

2.4.11 Новости

 Сделать закладку на этом месте книги

На рис. 2.4 представлен экран Chameleon  для работы с новостями. На нем перечислены группы новостей по темам научных исследований.



Рис. 2.4. Группы новостей по научной тематике

2.4.12 Диалог для доступа к файлу

 Сделать закладку на этом месте книги

Рассмотрим последний диалог с пользователем. В этом примере используется компьютер с дисковой операционной системой (Disk Operating System — DOS), подключенный к сети TCP/IP. Мы переключимся на устройство d:  локального хоста и просмотрим содержимое корневого каталога:

d:

d:\> dir

 Volume in drive D is SERVER

 Directory of D:\


.       <DIR>      10-25-95  8:03a

..      <DIR>      10-25-95  8:03a

ALTBWPM        711  2-18-95 12:53p

EGA512  FRS   3584  9-16-94  3:57p

WPRINT1     344392 11-05-95 13:28p

README  WPD   5492  9-16-95  3:57p

SPELL   EXE  40448  9-16-95  3:55p

WP      EXE 252416 11-15-95  4:51p

...

К этому примеру даже не требуется особых пояснений: файлы, которые отмечены как находящиеся на локальном диске d :, реально читаются с удаленного сервера NFS.

Глава 3

Архитектура TCP/IP

 Сделать закладку на этом месте книги

3.1 Введение

 Сделать закладку на этом месте книги

Протоколы TCP/IP разработаны для сетевого окружения, которое было мало распространено в 70-х гг., но сегодня стало нормой. Эти протоколы позволяют соединять оборудование различных производителей и способны работать через различные типы носителей или сред и связи данных. Они позволили объединить сети в единую сеть интернет , все пользователи которой имеют доступ к набору базовых служб.

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

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

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

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

3.2 Деление на уровни

 Сделать закладку на этом месте книги

Для достижения надежности обмена данными между компьютерами необходимо обеспечить выполнение нескольких операций:

■ Пакетирование данных

■ Определение путей (маршрутов) пересылки данных

■ Пересылку данных по физическому носителю

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

■ Сборку полученных данных, чтобы в формируемой последовательности не было потерянных частей

■ Проверку поступающих данных на наличие дублированных фрагментов

■ Информирование отправителя о том, сколько данных было передано успешно

■ Пересылку данных в нужное приложение

■ Обработку ошибок и непредвиденных событий

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

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

Коммуникационная модель обмена данными OSI строго соответствует структуре TCP/IP. Уровни и терминология модели OSI стали стандартной частью коммуникационной структуры обмена данными.

На рис. 3.1 показаны уровни OSI и TCP/IP. Начнем их анализ с самого нижнего уровня (в TCP/IP формально не определены уровни сеанса и представления).



Рис. 3.1. Уровни TCP/IP и OSI

3.2.1 Физический уровень

 Сделать закладку на этом месте книги

Физический уровень (physical layer) имеет дело с физическими носителями, разъемами и сигналами для представления логических нулей и единиц. Например, адаптеры сетевого интерфейса Ethernet и Token-Ring и соединяющие их кабели реализуют функции физического уровня.

3.2.2 Уровень связи данных

 Сделать закладку на этом месте книги

Уровень связи данных (data link layer) организует данные в кадры  (frame). Иногда его называют канальным уровнем. Как показано на рис. 3.2, каждый кадр имеет заголовок (header), содержащий адрес и управляющую информацию, а завершающая секция кадра (trailer) используется для исправления ошибок (иногда ее называют хвостом кадра. — Прим. пер .).

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

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



Рис. 3.2. Формат кадра

3.2.3 Сетевой уровень

 Сделать закладку на этом месте книги

Функции сетевого уровня (network layer) выполняет протокол IP, который осуществляет, маршрутизацию данных между системами. Данные могут следовать по одному пути или использовать несколько различных путей при перемещении в интернете. Данные пересылаются в элементах, называемых датаграммами  (datagram).

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



Рис. 3.3. Датаграмма IP

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

3.2.4 Транспортный уровень (TCP)

 Сделать закладку на этом месте книги

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

Приложения, например пересылки файлов, передают данные в TCP, который добавляет к ним заголовок и формирует элемент, называемый сегментом  (segment).

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

3.2.5 Транспортный уровень (UDP)

 Сделать закладку на этом месте книги

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

UDP передает исходящие сообщения в IP и предполагает на другой стороне получение входящих сообщений от IP. Далее UDP определяет приложение, которому направлены данные.

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

3.2.6 Службы для приложений

 Сделать закладку на этом месте книги

Как уже отмечалось в главе 2, набор протоколов TCP/IP включает стандартные службы для приложений, такие как доступ с терминала, пересылка файлов, обращение к файловым серверам NFS, электронная почта, сетевые новости, WWW и просмотр адресов в DNS.

3.2.7 Пакетирование данных

 Сделать закладку на этом месте книги

На рис. 3.4 показано, как пакетируются прикладные данные перед пересылкой по сети. Основным термином для объединения информации с заголовком соответствующего сетевого уровня является элемент данных протокола  (Protocol Data Unit — PDU). Например, сегмент TCP является PDU транспортного уровня, а датаграмма IP — PDU сетевого уровня.



Рис. 3.4. Пакетирование данных перед пересылкой по сети

3.3 Обзор протоколов

 Сделать закладку на этом месте книги

На рис. 3.5 представлено соотношение между отдельными компонентами набора протоколов TCP/IP.



Рис. 3.5. Соотношение между компонентами набора протоколов TCP/IP

Хотя текстовые пользовательские интерфейсы для пересылки файлов, доступа с терминала, работы с новостями или запросами к DNS для определения адреса по имени формально не стандартизованы, многие разработчики копируют интерфейс конечного пользователя из BSD Unix. Работающие в режиме текстовых команд пользователи находят, что пользовательский интерфейс не слишком отличается в разных системах.

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

Клиенты WWW, сетевых новостей, пересылки файлов (FTP), почты (SMTP) и терминального доступа (telnet ) могут взаимодействовать со своими серверами через соединения TCP. Большинство клиентов NFS обмениваются со своими серверами сообщениями UDP, хотя некоторые реализации NFS предполагают использование как UDP, так и TCP.

Просмотр каталогов DNS основан на сообщениях UDP. Станции управления SNMP извлекают сведения из сетевых устройств с помощью сообщений UDP.

3.4 Маршрутизаторы и топология сети

 Сделать закладку на этом месте книги

Набор протоколов TCP/IP может использоваться как в независимых локальных или региональных сетях, так и для их объединения в общие сети интернета. Любой хост с TCP/IP может взаимодействовать с другим хостом через локальную сеть, соединение "точка-точка" или через региональную сеть с пакетированием информации (см. рис. 3.6).



Рис. 3.6. Независимые друг от друга сети

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



Рис. 3.7. Объединение независимых сетей маршрутизаторами

Современные маршрутизаторы обеспечивают работу нескольких аппаратных интерфейсов, которые можно комбинировать для применения с конкретной сетевой топологией: Ethernet, Token-Ring, FDDI, синхронные соединения "точка-точка", Frame Relay и т.д.

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

Обширный и основанный на конкуренции рыно


убрать рекламу







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

3.5 Маршрутизация в IP

 Сделать закладку на этом месте книги

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

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

3.5.1 Протоколы маршрутизации

 Сделать закладку на этом месте книги

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

■ Добавление к интернету новой сети

■ Разрушение пути к пункту назначения или невозможность его достижения за заданное время

■ Добавление в интернет нового маршрутизатора, который может обеспечить более короткий путь к месту назначения

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

Сетевая возможность по управлению организацией сети соответствует понятию "автономной системы"  (Autonomous System — AS). Организация может выбрать любой из протоколов обмена информацией о маршрутизации, который связан с ее собственной автономной системой. Протоколы обмена информацией о маршрутизации применяются внутри автономных систем в виде протокола внутреннего шлюза  (Interior Gateway Protocol — IGP).

Протокол информации о маршрутизации  (Routing Information Protocol — RIP) стал одним из популярных стандартов IGP. Широкое распространение этого протокола связано с его простотой, однако новый протокол "Сначала открывать самый короткий путь"  (Open Shortest Path First — OSPF) имеет еще более обширный набор полезных возможностей.

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

3.6 Архитектура TCP

 Сделать закладку на этом месте книги

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

■ Точность

■ Сохранение последовательности

■ Полноту

■ Исключение дублирования

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

■ Нумерует каждый сегмент

■ Устанавливает таймер

■ Пересылает сегмент

Принимающая система TCP сообщает своему партнеру, сколько данных было передано правильно, посредством выдачи подтверждения (acknowledgment — ACK). Если подтверждение пересылки сегмента не будет получено за заданный интервал времени, TCP производит повторную пересылку этого сегмента. Такая стратегия называется повторной трансляцией с положительным подтверждением  (retransmission with positive acknowledgment). Иногда повторная пересылка приводит к дублированию доставленных на принимающую систему сегментов.

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

Поскольку одна сторона отправляет данные, а другая их принимает, TCP можно назвать полнодуплексным  (full-duplex) протоколом: обе стороны соединения могут одновременно посылать и принимать данные (т.е. присутствуют два потока данных). TCP одновременно выполняет роли передатчика и приемника.

3.7 Архитектура UDP

 Сделать закладку на этом месте книги

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

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

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

3.8 Концепция безопасности

 Сделать закладку на этом месте книги

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

Базовые концепции безопасности в сетевом окружении подобны аналогичным концепциям для центрального хоста:

■ Аутентификация пользователей

■ Целостность (гарантия отсутствия изменения данных)

■ Конфиденциальность (защита от нежелательного раскрытия информации)

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

 Сделать закладку на этом месте книги

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

Если речь идет о пересылке серьезных транзакций в сетях TCP/IP, то требуется способ для надежной идентификации отправителя. Процесс проверки на авторство называется аутентификацией  (authentication, дословно: проверка подлинности. — Прим. пер .).

3.8.2 Технология формирования резюме сообщения

 Сделать закладку на этом месте книги

Простой, но эффективный способ технологии аутентификации основан на резюме сообщения  (message digest). Как показано на рис. 3.8, такое резюме вычисляется по содержимому сообщения с помощью секретного ключа. В настоящее время наиболее распространен алгоритм Message Digest 5 (MD5), который был разработан Рональдом Ривестом (см. RFC 1321).



Рис. 3.8. Использование резюме сообщения.

Взаимное исследование  (challenge handshake) иллюстрирует один из способов применения резюме сообщения. Как и при обычной аутентификации, пользователю присваивается пароль, регистрируемый на хосте. Однако этот пароль уже не пересылается по сети. Вместо этого настольная система выполняет вычисление по алгоритму MD5, используя пароль и секретный ключ (ключ шифрования. — Прим. пер .). Как показано на рис. 3.9:

1. Пользователь посылает на хост свой идентификатор.

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

3. Хост и настольная система пользователя выполняют вычисления по алгоритму MD5 для сообщения от хоста и секретного пароля пользователя.

4. Система пользователя отсылает ответ хосту.

5. Хост сравнивает ответ. Если ответ верен, пользователь аутентифицируется.



Рис. 3.9. Использование MD5 при взаимном исследовании

3.8.3 Целостность сообщения

 Сделать закладку на этом месте книги

MD5 и совместно используемые секретные ключи можно применять для определения изменений в данных при их пересылке по сети. Рассмотрим рис. 3.10:

1. Вычисление MD5 выполняется над данными с помощью секретного ключа.

2. Данные и полученное сообщение посылаются партнеру.

3. Партнер выполняет вычисление MD5 над полученными данными и известным секретным ключом.

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

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



Рис. 3.10. Защита пересылаемых данных с помощью резюме сообщения, вычисленного по MD5

3.8.4 Конфиденциальность с помощью симметричного шифрования

 Сделать закладку на этом месте книги

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



Рис. 3.11. Симметричное шифрование

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

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

■ Изменение ключа связано с большими трудностями.

3.8.5 Асимметричный общедоступный ключ шифрования

 Сделать закладку на этом месте книги

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

Рассмотрим шкатулку с двумя различными ключами (А и Б), как показано на рис. 3.12:

■ Если шкатулка закрывается ключом А, то открывается ключом Б.

■ Если шкатулка закрывается ключом Б, то открывается ключом А.



Рис. 3.12. Использование различных ключей для открытия и закрытия

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

■ Все партнеры могут применять общедоступный ключ для шифрования пересылаемых данных.

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

Схема шифрования по общедоступным/личным ключам основана на том, что очень трудно подобрать два числа с большими значениями (количество проверок при этом выражается степенной функцией), чтобы получить значение ключей шифрования. Лучшим специалистам потребуется несколько месяцев, чтобы расшифровать данные с 129-разрядным ключом. Однако скорость работы компьютеров постоянно увеличивается, и вряд ли можно ожидать, что 1024-разрядные ключи останутся секретными по истечении еще нескольких лет.

Обслуживание общедоступных/личных ключей гораздо проще, чем симметричных. Однако нужна уверенность, что опубликованный общедоступный ключ "Jane Jone's Public Key" реально принадлежит нужной Джейн Джон, а не другому человеку с тем же именем.

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

3.8.6 Комбинированное шифрование

 Сделать закладку на этом месте книги

Комбинированное шифрование реализуется следующим образом:

■ Выбирается случайный симметричный ключ.

■ По этому ключу шифруются данные.

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

■ Получатель расшифровывает временный случайный ключ и далее использует его для расшифровки данных.

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



Рис. 3.13. Вложенный в зашифрованное сообщение ключ

В следующих главах мы рассмотрим реализацию этих методов в приложениях и коммуникациях TCP/IP. Наиболее впечатляющий результат рассмотрен в главе 24, где описываются аутентификация и шифрование на уровне IP как для классической версии 4 протокола IP, так и для новой версии 6 — IP Next Generation (следующее поколение IP).

Глава 4

Технологии физического уровня и уровня связи данных

 Сделать закладку на этом месте книги

4.1 Введение

 Сделать закладку на этом месте книги

За последние несколько лет было предложено беспрецедентное количество новых технологий для локальных и региональных сетей, быстро утвердившихся на компьютерном рынке. Произошел огромный скачок от технологий носителей на витых парах и волоконной оптики — скачок, который никто не мог предвидеть. Сети ISDN, Frame Relay, T1, Fractional T1, T3, волоконно-оптические линии SONET, SMDS, новые кабельные соединители и технология ATM обеспечивают связь с обширными территориями, которая становится все быстрее и дешевле.

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

Работа IETF видна по большой серии RFC, в том числе:

The Point-to-Point Protocol (РРР) for the Transmission of Multiprotocol Datagrams over Point-to-Point Links  (Протокол РРР для пересылки многопротокольных датаграмм по соединениям "точка-точка")

Standard for the transmission of IP datagrams over IEEE 802 networks  (Стандарт для пересылки датаграмм IP по сетям IEEE 802)

Transmission of IP and ARP over FDDI Networks  (Пересылка IP и ARP по сетям FDDI)

Classical IP and ARP over ATM  (Классические пересылки IP и ARP по сетям ATM)

4.2 Функции физического уровня, управление доступом к физическому носителю и уровень связи данных

 Сделать закладку на этом месте книги

В этой главе мы рассмотрим работу IP поверх различных технологий нижнего уровня. Однако сначала обратимся к происходящим на этих уровнях событиям (см. рис. 4.1).



Рис. 4.1. Функции нижних уровней

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

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

Описание формата кадра принадлежит уровню связи данных. Формат кадра различается в разных технологиях нижнего уровня, используемых для создания связи (например, линии Т1, цепи Frame Relay или локальные сети Ethernet). Каждый кадр имеет заголовок, содержащий сведения, необходимые для его доставки по связи. Формат заголовка зависит от применяемой технологии.

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 используется между двумя маршрутизаторами. Иногда со временем ухудшается качество соединения. Было бы неплохо заранее определять опасное состояние связи, для чего предусматривается автоматическое выполнение некоторых операций. Например, маршрутизатор может завершить коммутируемое соединение и провести повторный набор телефонного номера для воссоздания этого соединения. Если аналогичная проблема возникает в выделенной линии, то, возможно, придется временно переключить трафик на резервный канал связи.

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

Такие сведения позволяют провести анализ произошедших в связи событий. Например, если за определенный интервал времени было послано 100 000 октетов, а партнер успешно получил только 50 000, то ясно, что со связью не все в порядке.

4.9 Протокол SLIP

 Сделать закладку на этом месте книги

Протокол интерфейса последовательной линии связи (Serial Line Interface Protocol — SLIP), созданный до PPP, обеспечивает уже устаревшие методы пересылки датаграмм IP по последовательной линии связи.

SLIP — наиболее примитивный из всех разработанных протоколов. Датаграмма IP просто пересылается по последовательной линии, байт за байтом. SLIP маркирует конец датаграммы специальным разделительным байтом: 11000000 (X'C0). Что же произойдет, когда такой байт появится в самой датаграмме? Передающая часть SLIP использует Esc-последовательность, которую принимающая часть SLIP преобразует обратно в реальные данные:

С0 в данных → DB DC

DB в данных → DB DD

Обычно SLIP используется для соединения компьютеров PC, Macintosh и Unix с сетями IP по коммутируемым соединениям. Отметим, что SLIP не обеспечивает проверки FCS, передавая выявление ошибок на более высокие уровни. SLIP не обеспечивает пересылки никаких протоколов, кроме IP.

Протокол SLIP со сжатием (Compressed SLIP — CSLIP) является улучшенной версией протокола SLIP, производящей сжатие заголовков TCP/IP методом Вана Джекобсона и обеспечивающей лучшую производительность, чем SLIP.

SLIP можно использовать между хостами, хостом и маршрутизатором или между маршрутизаторами. На рис. 4.11 показан коммуникационный сервер, поддерживающий работу неинтеллектуальных терминалов ASCII и коммутируемые соединения с терминалами по SLIP. Для трафика SLIP данное устройство работает как маршрутизатор IP.



Рис. 4.11. Подключение терминала ASCII и соединения SLIP

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

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

 Сделать закладку на этом месте книги

Рассмотрим, как IP и другие протоколы пакетируют кадры для пересылки по локальным сетям. Классическая локальная сеть предполагает следующие свойства:

■ Станции совместно используют физический носитель.

■ Существуют правила управления доступом к носителю  (Media Access Control — MAC), определяющие моменты времени, когда станция может пересылать данные.

■ Данные передаются в кадрах.

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

4.11 DIX Ethernet

 Сделать закладку на этом месте книги

Локальные сети Ethernet первыми смогли передавать датаграммы IP. Компании Digital Equipment Corporation (DEC), Intel Corporation и Xerox Corporation совместно определили исходную спецификацию DIX  Ethernet в 1980 г. Пересмотренная версия 2 этой спецификации появилась в 1982 г.

4.11.1 Носители для DIX Ethernet

 Сделать закладку на этом месте книги

Традиционным магистральным носителем для данной технологии является узкополосный коаксиальный кабель. Первоначально применялся жесткий полудюймовый кабель с сопротивлением 50 Ом. Позднее стал использоваться тонкий и более гибкий коаксиальный кабель в 1/4 дюйма, названый thinnet (тонкий сетевой) или cheapernet  (дешевый сетевой), а еще позднее многие сети перешли на применение витых пар. Скорость передачи сигналов в 10 Мбит/с превалировала достаточно долгое время, однако сейчас доступна скорость пересылки в 100 Мбит/с. Сегодня DIX Ethernet может работать на широкополосных коаксиальных или волоконно-оптических кабелях.

Различия между вариантами Ethernet отражаются в следующей нотации:

[Скорость пересылки данных в Мбит/с][тип носителя][максимальная длина кабельного сегмента в сотнях метров]

Таким образом, 10BASE5 означает узкополосный (baseband) коаксиальный кабель со скоростью передачи данных в 10 Мбит/с и максимальной длиной сегмента в 500 м. Спецификация для тонкого кабеля 10BASE2 означает узкополосный коаксиальный кабель со скоростью передачи данных в 10 Мбит/с и максимальной длиной сегмента в 200 м.

10BROAD36 должна означать широкополосный коаксиальный кабель со скоростью обмена в 10 Мбит/с и максимальной длиной сегмента в 3600 м. Обозначениями для витых пар и волоконной оптики являются 10BASET и 10BASEF соответственно, хотя это и не вполне согласуется с правилами нотации.

4.11.2 Протокол MAC для DIX Ethernet

 Сделать закладку на этом месте книги

DIX Ethernet использует простую процедуру MAC с очень длинным названием: множественный доступ с контролем несущей и обнаружением конфликтов  (Carrier Sense Multiple Access with Collision Detection — CSMA/CD).

Интерфейс для работы с данными пакетирует информацию в кадры и прослушивает состояние носителя. Когда носитель свободен, интерфейс начинает пересылку данных (см. рис. 4.12).



Рис. 4.12. Управление доступом к носителю в Ethernet

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

4.11.3 MAC-кадры DIX Ethernet

 Сделать закладку на этом месте книги

Формат кадров DIX Ethernet с датаграммами IP показан на рис. 4.13.

Адреса источника и назначения имеют длину по 6 октетов (сами адреса администрируются IEEE). Значение типа  в X'08-00 означает пересылку датаграмм IP.



Рис. 4.13. Кадр DIX Ethernet с датаграммой IP

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

Для правильной работы протокола CSMA/CD требуются кадры длиной не менее 64 октетов. Следовательно, для очень коротких датаграмм нужно будет добавить незначащий заполнитель.

4.12 Сети по спецификации 802

 Сделать закладку на этом месте книги

После того как DIX Ethernet и другие технологии локальных сетей доказали на компьютерном рынке свою полезность, IEEE организовала комитет 802  по разработке и публикации стандартов для технологий локальных сетей.

Стандарты из серии 802, объединяющие разработки разных производителей, были признаны ISO и повторно опубликованы как документы этой организации.

Стандарты 802 касаются физических носителей, управления доступа к носителю и форматов кадров для различных типов локальных сетей. Например:

■ 802.3 описывает несколько измененную версию Ethernet.

■ 802.4 специфицирует широковещательную локальную сеть с пересылкой маркера, разработанную для производственных помещений.

■ 802.5 описывает технологию Token-Ring.

■ 802.6 определяет подсети на основе двойной шины для распределенных очередей (Distributed Queue Dual Bus), использующихся в городских сетях (Metropolitan Area Network — MAN).

4.13 Заголовок LLC для 802.2

 Сделать закладку на этом месте книги

Отдельный стандарт 802.2 определяет заголовок управления логической связью  (Logical Link Control — LLC), используемый во всех технологиях локальных сетей по спецификациям 802. Заголовок LLC выполняет две задачи:

■ Для кадров OSI идентифицирует протоколы источника и назначения

■ Содержит поля управления

Описание IEEE предполагает множество формальных правил, однако каждый из элементов достаточно прост.

Элементы для назначения и источника протоколов ISO каждого кадра описываются кодами точки доступа к службе назначения  (Destination Service Access Point — DSAP) и кодами точки доступа к службе источника  (Source Service Access Point — SSAP).

Значения DSAP/SSAP присваиваются протоколам ISO, но не протоколу IP или множеству других протоколов, используемых на практике. Для IP и других распространенных протоколов DSAP и SSAP устанавливаются в значение X'AA, что означает наличие следующего далее другого заголовка, который и будет определять тип протокола для размещенных в кадре данных. Дополнительный заголовок называется подзаголовком протокола доступа в подсети  (Subnetwork Access Protocol — SNAP ).

Подзаголовок SNAP содержит вводную часть (introducer) со следующим далее старым знакомым — кодом типа Ethernet. Вводная часть имеет прекрасное название — уникальный организационный идентификатор  (Organizationally Unique Identifier — OUI). Он определяет, кто несет ответственность за присвоение номеров протоколов.

Вводная часть (OUI) для кодов типа Ethernet (см. рис. 4.14) имеет значение X'00-00-00. Отдельный OUI со значением X'00-80-C2 служит для введения номеров различных протоколов мостов.



Рис. 4.14. Кадр 802.3 с заголовком LLC 802.2 и подзаголовком SNAP

4.13.1 Спецификации 802.3 и 802.2

 Сделать закладку на этом месте книги

Стандарт 802.3 содержит описание носителя Ethernet, протокола доступа к носителю CSMA/CD и формата MAC-кадров. В соответствии со стандартами комитета 802 заголовок 802.2 должен включаться в МАС-кадр 802.3.

На рис. 4.14 показан результат размещения датаграммы IP в кадре 802.3/802.2.

■ Отметим, что в отличие от DIX Ethernet третье поле заголовка кадра 802.3 содержит сведения о длине  информации, которая следует далее (за исключением заполнителя) вместо кода типа Ethernet. Длина определяется в 8 октетов полей LLC и SNAP. Далее мы увидим, что в заголовке IP размещается поле длины датаграммы, хотя для IP это значение является избыточным.

■ DSAP и SSAP имеют значения X'AA, указывая на следующий далее подзаголовок SNAP.

■ Поле управления содержит X'03, что означает нечисловую информацию — так же, как и в HDLC.

■ Вводная часть поля SNAP содержит X'00-00-00, указывая на следующий далее тип Ethernet (который имеет значение X'08-00).

Другие протоколы (например, IPX или DECnet) имеют похожие кадры — нужно только подставить правильные значения для типов Ethernet.

Отметим, что 8 дополнительных октетов добавлены без каких-либо изменений в функциях IP. Именно поэтому многие реализации продолжают использовать старую спецификацию формата DIX Ethernet. Сетевые адаптеры Ethernet Network Interface Card (интерфейсные карты сети Ethernet) и их программные драйверы обычно поддерживают оба стандарта, а при конфигурировании пользователь может выбрать нужный вариант.

Часто термин Ethernet  применяют как для старой DIX, так и для реализации IEEE 802.3/802.2. Иногда очень важно разделять эти понятия, поскольку системы, сконфигурированные для работы с DIX, не могут взаимодействовать с системами, сконфигурированными для 802.3/802.2.

4.14 Уровни в сетях 802

 Сделать закладку на этом месте книги

Ознакомимся со взглядом IEEE на сетевой мир. С появлением локальных сетей 802 IEEE разделил сетевой уровень 2 (уровень связи данных) на два подуровня (см. рис. 4.15).



Рис. 4.15. Уровни для локальных сетей 802

Подуровень MAC обеспечивает правила доступа к носителю — слушать и пересылать для 802.3 или ждать маркера для 802.5. Этот же уровень определяет первую часть заголовка кадра, которая содержит физические адреса источника и назначения.

Подуровень Logical Link Control описывает формат заголовка LLC. Он же определяет достаточно сложные правила для коммуникаций в те моменты, когда производится нумерация, подтверждение пересылки, управление потоком и повторная пересылка кадров с использованием уровня связи данных. Связи, обеспечивающие такие возможности, называются связями типа 2  (Type 2). Существует несколько протоколов, включая SDLC, LAPB или LAPD, которые выполняют коммуникации в локальных сетях с помощью связей типа 2.

Разумеется, датаграммы IP требуют только указания на подуровне Logical Link Control сведений о включении в кадр датаграммы IP. Обычно IP работает поверх протокола связи типа 1 .

4.15 Другие технологии локальных сетей

 Сделать закладку на этом месте книги

По требованию IEEE локальные сети Token-Ring, token bus и FDDI должны  включать заголовок LLC 802.2 и подзаголовок SNAP для пересылки протокола IP или иных протоколов с кодом типа Ethernet. Для них не существует укороченного формата.

Те же самые поля LLC и SNAP определяют вложенный протокол, как показано на рис. 4.14, а именно:

X'AA-AA-03-00-00-00 (тип Ethernet )

4.15.1 Конфигурация и носители для Token-Ring

 Сделать закладку на этом месте книги

Локальные сети Token-Ring были представлены компанией IBM, а позднее IEEE стандартизировал их как протокол 802.5. Станции в сети Token-Ring образуют физическое кольцо.

4.15.2 MAC для 802.5

 Сделать закладку на этом месте книги

Идея управления доступом к носителю (MAC) на основе маркера, или жетона, достаточно проста. Специальный кадр, называемый маркером  (token), передается по кольцу от станции к станции. Когда станция получает такой маркер, она должна отправить данные дальше в течение ограниченного интервала времени. По завершении этого интервала удерживающая маркер станция обязана переслать его следующей станции.

Хотя основная идея не требует пояснений, для протокола пересылки маркера по кольцу нужны более сложные механизмы, чем для сети Ethernet. В частности, протокол для уровня MAC спецификации 802.5 включает процедуры связывания и разъединения кольца Token-Ring, идентификации ближайших соседей, выявления неисправной станции или потерянного маркера, предотвращения циклической пересылки данных и решения проблем с сигналами. Для различных функций 802.5 определяются разные заголовки MAC-уровня. Тип пересылающего данные протокола указывается через заголовки LLC и SNAP, размещенные за информационным полем маршрутизации (Routing Information Field) кадра Token-Ring.

4.15.3 802.4 Token Bus

 Сделать закладку на этом месте книги

Стандарт 802.4 описывает широкополосную шину локальной сети на основе коаксиального кабеля, в которой используется маркер для управления доступом к носителю. 802.4 является частью набора протоколов автоматизации производства  (Manufacturing Automation Protocol), предлагаемых для использования в промышленных условиях. Сигналы в широкополосном коаксиальном кабеле не подвержены влиянию электромагнитных помех, связанных с промышленным производством. Использование протокола с пересылкой маркера позволяет достичь предсказуемого расписания доступа к локальной сети. Однако 802.4 никогда не имел широкого распространения.

4.15.4 FDDI

 Сделать закладку на этом месте книги

Волоконно-оптический интерфейс для распределенных данных (Fiber Distributed Data Interface — FDDI) со скоростью пересылки в 100 Мбит/с часто используется в локальных сетях для создания магистральных соединений, объединяющих низкоскоростные сегменты локальных сетей.

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

■ Как показано на рис. 4.16, основу FDDI составляет одиночное (или двойное) кольцо, называемое транком  (trunk). Станции могут соединяться непосредственно с транком или подключаться к нему через концентраторы. Допустимо подключение к транку древовидной структуры из концентраторов и станций.

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



Рис. 4.16. Топология сетей FDDI

Доступ к носителю в FDDI производится на основе пересылки маркера. Реально модель MAC-протокола очень похожа на 802.5 Token-Ring.

Кадр FDDI имеет MAC-заголовок и завершающую секцию, а когда кадр служит для пересылки IP, то используются уже знакомые нам заголовки 802.2 LLC и SNAP, отражающие перенос в кадре


убрать рекламу







датаграммы IP.

4.16 Использование концентраторов

 Сделать закладку на этом месте книги

Локальные сети Ethernet, Token-Ring и FDDI вначале существенно различались по топологии кабельных сетей, однако со временем большинство организаций перешло на подключение систем через концентраторы (hub). Эти устройства упрощают администрирование локальных сетей и позволяют перейти на единую физическую топологию — звезду или цепочку звезд.

4.17 Коммутация

 Сделать закладку на этом месте книги

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

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

4.18 Широковещательные и многоадресные рассылки

 Сделать закладку на этом месте книги

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

XFF-FF-FF-FF-FF-FF

Сетевой интерфейс можно настроить и на прием кадров, посланных при одной или нескольких многоадресных рассылках  (multicast). Многоадресность позволяет кадру попасть на указанный набор сетевых систем. Многоадресная рассылка всегда имеет единицу в младшем бите первого байта адреса:

X'01-00-00-00-00-00

Значения остальных бит устанавливаются в соответствии с конкретной службой многоадресной рассылки.

IANA зарезервировала список физических адресов многоадресных рассылок для нескольких служб. Например, многоадресная рассылка может применяться для передачи сообщения всем мостам сети. Отображение многоадресной рассылки уровня 3 в сетях IP в многоадресную рассылку уровня 2 будет рассмотрено в главе 5.

Термин "одноадресная рассылка"  (unicast) применяется для указания уникального физического адреса, присвоенного одному из интерфейсов при выполнении широковещательной или многоадресной рассылки. Если заголовок кадра содержит сведения об одноадресной рассылке, то предполагается доставка такого кадра только одному, указанному сетевому интерфейсу.

Теперь рассмотрим технологии для региональных сетей.

4.19 Сети с коммутацией пакетов

 Сделать закладку на этом месте книги

Технология коммутации пакетов была введена в экспериментальном порядке еще в ARPANET. Затем она была улучшена и расширена многими дополнительными возможностями коммуникации данных. Сети с пакетами X.25 получили широкое распространение еще с 80-х годов. Однако большинство пользователей предпочли новую технологию коммутации пакетов Frame Relay, обеспечивающую широкий спектр разнообразных возможностей.

4.20 Сети X.25

 Сделать закладку на этом месте книги

Обычная телефонная сеть позволяет соединиться с любым другим абонентом в любой точке планеты. Существует специальная международная организация по стандартам, ответственная за правила объединения национальных телефонных сетей в общемировую систему. Долгое время эта организация называлась Международным консультативным комитетом по телефонной и телеграфной связи  (International Telegraph and Telephone Consultative Committee — CCITT ). Позднее она была переименована в Сектор стандартизации в телекоммуникациях Международного телекоммуникационного союза  (Telecommunication Standardization Sector of the International Telecommunications Unit — ITU-T ).

В течение 70-х гг. CCITT начал работу над рекомендациями для создания глобальной цифровой  сети. Работа была завершена в 1980 г. Наиболее важной является рекомендация Х.25, определяющая правила для подключения компьютеров к цифровой сети. Точнее, X.25 описывает интерфейс между компьютером, именуемым оборудованием цифрового терминала  (data terminal equipment — DTE ), и сетевым коммуникационным элементом — оборудованием для терминирования цифровых цепей  (data circuit-terminating equipment — DTE ) как части сети для личного и общедоступного использования, в последнем случае — для провайдера сетевых услуг.

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

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

Цифровые сети X.25 предоставляют цепи двух типов. Коммутируемые виртуальные цепи  (switched virtual circuit) производят вызов данных так, как это делается в обычных телефонных сетях (в рекомендации X.121 от CCITT определен 14-значный номер для запросов X.25). Вызывающий абонент набирает 14-значный номер нужного ему компьютера, по которому производится вызов. В другом случае пользователь может применить постоянную виртуальную цепь  (permanent virtual circuit), которая работает подобно выделенной телефонной линии.

Рекомендации CCITT не ограничивают внутренней  структуры региональных цифровых сетей X.25, однако многие из них используют технологию внутренней коммутации пакетов.

4.20.1 Уровни в X.25

 Сделать закладку на этом месте книги

Протокол X.25 имеет три уровня. Уровень связи данных называется балансированным протоколом доступа к связи  (Link Access Protocol Balanced — LAPB), а сетевой уровень — уровнем пакетов X.25  (X.25 Packet Level). Владеющий оборудованием DTE пользователь устанавливает связь по X.25 с оборудованием DCE провайдера. Эта связь используется для пересылки данных нескольких  виртуальных цепей уровня 3. Коммутируемая виртуальная цепь инициализируется посылкой пакета Call Request  (запрос на вызов).

4.20.2 Х.25 и IP

 Сделать закладку на этом месте книги

X.25 — одна из многих технологий региональных сетей, способных пересылать датаграммы IP. IP использует виртуальные цепи X.25 таким же способом, как телефонные линии, — "точка-точка", т.е. трафик IP передается между хостами и маршрутизаторами через виртуальные цепи X.25.

Протоколы для связи X.25 (уровня 2) и пакетов X.25 (уровня 3) снимают проблемы правильного порядка передачи данных и коррекции ошибок. Цепи X.25 специально предназначены для создания надежного соединения между конечными точками связи.

Может показаться странным, что ненадежные службы IP работают поверх надежных протоколов X.25. И еще более странным, что, как в X.25, так и в IP реализованы протоколы уровня 3. Однако, учитывая стоимость и общепринятые требования, можно не обращать внимания на нечеткость деления на уровни. Элементы протоколов уровня 3 для сетей VINES, DECnet и SNA могут передаваться по цепям X.25 не менее успешно. Кроме того, данные для работы мостов по уровню 2 также иногда передаются по цепям X.25.

На рис. 4.17 показан трафик IP от нескольких источников, который маршрутизируется по одной виртуальной цепи X.25 и пересылается в несколько различных точек назначения.



Рис. 4.17. Использование сети X.25 для маршрутизации датаграмм IP

4.20.3 Многопротокольный режим поверх X.25

 Сделать закладку на этом месте книги

Существуют два метода для пересылки многопротокольного трафика по сети X.25 (аналогичные методы и форматы применяются для пакетного режима ISDN):

1. Для каждого протокола устанавливается отдельная  виртуальная цепь. Во время вызова партнеру указывается на пересылаемый протокол.

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

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

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

4.20.4 IP в отдельной виртуальной цепи X.25

 Сделать закладку на этом месте книги

Если трафик IP пересылается по отдельной коммутируемой виртуальной цепи, то это отражается в пакете Call Request  протокола X.25, который инициализирует цепь. В этом пакете имеется необязательное поле Call User Data  (вызываемые пользователем данные), которое для указания на трафик IP должно содержать значение X'CC.

Значение X'CC является идентификатором протокола сетевого уровня  (Network Layer Protocol ID — NLPID), как это установлено для трафика IP организацией ISO.

4.20.5 Другие протоколы в отдельной виртуальной цепи X.25

 Сделать закладку на этом месте книги

Несколько других протоколов также имеют коды ISO для NLPID, но коммерческим лицензионным протоколам такие коды не присвоены. Однако, как можно предположить, многие коммерческие протоколы производят присваивание двухбайтового кода типа для общепринятого многопротокольного окружения — Ethernet. Например, трафик AppleTalk имеет код типа Ethernet со значением X'80-9B.

Для запуска в виртуальной цепи одного протокола с присвоением кода типа Ethernet код NLPID должен иметь значение X'80 со следующим далее подзаголовком SNAP, что указывается в поле Call User Data пакета Call Request протокола X.25. Например, для установки виртуальной цепи на работу с трафиком AppleTalk следует послать:

X'80-00-00-00-80-9B

4.20.6 Многопротокольный режим в виртуальной цепи

 Сделать закладку на этом месте книги

Если в виртуальной цепи организуется многопротокольный режим, поле Call User Data устанавливается в X'00 и в каждый  кадр добавляется дополнительный заголовок, позволяющий идентифицировать тип протокола. Идентификация датаграммы IP очень эффективно выполняется посредством значения IP NLPID, равного X'CC,— это и будет дополнительным заголовком.

Для протоколов, идентификация которых выполняется кодом типа Ethernet, заголовок сообщения начинается NLPID со значением X'80, что указывает на следующий далее подзаголовок SNAP. Например, для цепи с многопротокольным режимом каждому  PDU протокола AppleTalk будет предшествовать заголовок:

X'80-00-00-00-80-9B

4.20.7 Пакеты или PDU?

 Сделать закладку на этом месте книги

Существует незначительная сложность в способе пересылки информации по Х.25. Некоторые сети X.25 передают пакеты очень маленького размера. Однако передать весь высокоуровневый PDU (например, датаграмму IP) можно через непрерывную последовательность пакетов  (packet sequence) с объединением данных в единый PDU на другой стороне цепи (для этого служит флажок "more/nomore" — еще/больше нет). В этом случае идентификатор протокола требуется только в заголовке первого пакета X.25 из пересылаемой последовательности.

4.21 Frame Relay

 Сделать закладку на этом месте книги

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

Технология Frame Relay (это протокол уровня 2) более подходит для набора протоколов TCP/IP. В этом случае к датаграмме IP добавляются только заголовок уровня связи данных и завершающая часть для проверки ошибок.

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

Начальный кадр Frame Relay стандартным способом определяет только  службу одной  виртуальной цепи. Пользователь должен связаться со службой провайдера и согласовать с ним требуемую скорость передачи при доступе к заданному сайту. Многие провайдеры обеспечивают скорости обмена вплоть до максимальной для линии Т1 скорости в 1.544 Мбит/с. Вне территорий США и Японии доступны линии E1 со скоростью 2.048 Мбит/с. (T1 и E1 отличаются только организациями, принявшими данные стандарты — американским и европейским комитетами соответственно. С технической точки зрения данные стандарты, включая доступные скорости обмена, подобны, хотя и не совместимы полностью между собой. — Прим. пер .) Обычно клиент платит фиксированную месячную арендную плату, величина которой зависит от согласованной скорости обмена.

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

Frame Relay обеспечивает лучшую производительность по сравнению с X.25 и поэтому чаще применяется на практике. На основе оборудования Frame Relay некоторые организации создают собственные лицензионные системы для внутренних сетей.

Как и для рассмотренных ранее протоколов, комитет IETF специфицировал формат для многопротокольной маршрутизации и перехода трафика через сетевые мосты для совместного использования цепей Frame Relay. Инкапсуляция датаграмм IP представлена на рис. 4.18.



Рис. 4.18. Инкапсуляция датаграммы IP в Frame Relay

Адресное поле Frame Relay обычно имеет длину в 2 октета и содержит 10-битовое поле идентификатора соединения по связи данных  (Data Link Connection Identifier — DLCI), определяющее отдельную цепь. Несколько бит в адресном поле используется для наполнения сигналов значениями, когда нужно указать, что кадр должен обрабатываться определенным образом, например для указания отмены кадра во время перегрузки. Если провайдер использует более длинные адреса, можно расширить адресное поле до 3 или 4 октетов.

Поле управления (CTL) имеет значение X'03 (т.е. нечисловая информация). Идентификатор протокола X'CC указывает, что кадр содержит датаграмму IP.

Кадры пересылаются по сети провайдера. Отбрасываются все кадры, проверочная последовательность (FCS) которых указывает на ошибку в них.

Для протоколов, которые должны описываться кодом типа Ethernet (например, AppleTalk), заголовок сообщения имеет формат, показанный на рис. 4.19. Для улучшения выравнивания сообщения после поля управления вставлен добавочный октет-заполнитель X'00. Значение X'80 для NLPID говорит о следующем далее подзаголовке SNAP. В нашем примере он содержит код типа Ethernet для протокола AppleTalk.



Рис. 4.19. Заголовок кадра Frame Relay с кодом типа Ethernet

За исключением байта-заполнителя (pad), данный заголовок идентичен заголовку для цепи X.25 в многопротокольном режиме.

4.22 SMDS

 Сделать закладку на этом месте книги

Служба коммутируемых многомегабитных данных  (Switched Multimegabit Data Service — SMDS) является еще одной общедоступной службой с коммутацией пакетов. Она была разработана для региональных компаний Bell (в свое время корпорация Bell была разделена правительством США на несколько региональных компаний. — Прим. пер .). Данная служба предназначена для предоставления широкого спектра вариантов производительности, включая высокоскоростные соединения, например 155 Мбит/с.

Интересным свойством SMDS является то, что данные могут быть посланы без открытия виртуальной цепи — без создания соединения  (connectionless). На практике логическая подсеть IP может быть сформирована с возможностями региональных сетей, и (см. рис. 4.20) этот логический сегмент региональной сети будет наследовать многие возможности высокоскоростных локальных сетей. Такие свойства делают SMDS привлекательной для создания магистральной структуры региональных сетей.



Рис. 4.20. Магистральная региональная сеть SMDS

Протокол интерфейса SMDS  (SMDS Interface Protocol — SIP) основан на стандарте IEEE с номером 802.6.

4.22.1 IP поверх SMDS

 Сделать закладку на этом месте книги

Ha рис. 4.21 показан формат заголовка после вставки заголовка SIP SMDS, что отражает факт присутствия датаграммы IP.



Рис. 4.21. Для идентификации IP в SMDS используются LLC и SNAP.

Этот формат подобен используемому в локальных сетях IEEE 802. Первые три октета создают заголовок LLC IEEE 802.2, а содержащий значение X'08-00 подзаголовок SNAP определяет для IP код типа Ethernet.

4.23 ATM

 Сделать закладку на этом месте книги

Режим асинхронной пересылки (Asynchronous Transfer Mode — ATM) представляет собой технологию с коммутацией ячеек, подходящую как для локальных, так и для региональных сетей. ATM объединяет преимущества безопасности при коммутируемом доступе с высокой производительностью и гибкостью. Эту технологию можно характеризовать следующим образом:

■ Данные коммутируются в 53-октетных ячейках.

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

■ Кадры разбиваются на ячейки в источнике и вновь объединяются в кадры в точке назначения с помощью уровней адаптации ATM  (ATM Adaptation Layer — AAL).

■ Существует несколько AAL, однако к пересылке датаграмм IP имеет отношение только AAL5.

■ Работу по сегментации и последующей сборке кадров при пересылке по региональной сети выполняет интерфейс обмена данными (Data Exchange Interface — DXI) — часть оборудования, соответствующая цифровому интерфейсу обычной телефонной линии.

Как в X.25 или Frame Relay, коммуникации ATM формируются путем создания виртуальной цепи и пересылки кадров по этой цепи.

В сетях ATM существуют два метода обслуживания многопротокольного трафика:

■ Создание отдельной виртуальной цепи для каждого протокола

■ Совместное использование одной виртуальной цепи всеми протоколами

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

Если для каждого протокола используется отдельная виртуальная цепь (как в X.25), то тип протокола для коммутируемой цепи можно анонсировать только один раз — в сообщении запроса на вызов.

Когда несколько маршрутизируемых протоколов совместно используют одну виртуальную цепь (см. рис. 4.22), кадр AAL5 начинается с уже известных нам заголовков LLC и SNAP. Тип IP Ethernet заключается в подзаголовке SNAP (см. рис. 4.22).



Рис. 4.22. Для идентификации IP в  ATM AAL используются LLC и SNAP.

Отметим, что кадр AAL5 не имеет в заголовке полей с адресами источника и назначения. Дело в том, что после вызова устанавливается виртуальная цепь от источника до точки назначения, а необходимая для коммутации в точке назначения информация находится в 5-октетном заголовке ячейки.

Заключительная часть AAL5 содержит байты-заполнители (для выравнивания), поле данных пользователя, поле payload length  (длина полезной нагрузки) и проверочную последовательность кадра (FCS). Полезная нагрузка учитывает размеры заголовков LLC и SNAP и самой датаграммы.

4.24 Максимальное число пересылаемых элементов

 Сделать закладку на этом месте книги

Каждая из рассмотренных нами технологий имеет различные максимальные размеры для своих кадров. После исключения заголовка кадра, заключительной части, а также заголовков LLC и SNAP (если они присутствуют), полученный результат будет определять максимально возможный размер датаграммы, которую можно переслать по носителю. Эта величина называется максимальным пересылаемым элементом  (Maximum Transmission Unit — MTU ).

Например, максимальный размер кадра для сети 802.3 10BASE5 равен 1518 октетам. Вычитая длину MAC-заголовка и завершающей части (18 октетов), поле управления связи Type 1 и заголовок SNAP (8 октетов), мы получим MTU, равный 1492 октетам.

В таблице 4.1 приведены MTU для различных технологий.


Таблица 4.1 Максимальный пересылаемый элемент

Протокол Максимальное количество октетов в датаграмме (MTU)
По умолчанию для PPP 1500
PPP (с небольшой задержкой) 296
SLIP 1006 (исходное ограничение)
X.25 1600 (отличается для некоторых сетей)
Frame Relay Обычно не менее 1600
SMDS 9235
Ethernet версии 2 1500
IEEE 802.3/802.2 1492
IEEE 802.4/802.2 8166
16 Mb IBM Token-Ring Максимально 17914
IEEE 802.5/802.2 4-Mb Token-Ring Максимально 4464
FDDI 4352
Hyperchannel 65535
ATM По умолчанию 9180 Максимально возможно 16K-1

Специальным случаем является линия "точка-точка". Она реально не наследует ограничений на размер датаграммы. Оптимальный размер зависит от уровня ошибок в данной линии связи. Если он высок, то лучшая производительность достигается при более коротких элементах данных. Максимальное значение по умолчанию в 1500 байт используется наиболее часто.

Первоначально протокол SLIP был специфицирован с максимальной длиной датаграммы в 1006 байт. Некоторые реализации могут поддерживать до 1500 байт, преобразуя SLIP в другие форматы пересылки данных по последовательной линии "точка-точка".

Для Token-Ring показано предельное значение MTU. Реально MTU для Token-Ring зависит от множества факторов, включая время удержания маркера в кольце.

4.25 Создание туннелей

 Сделать закладку на этом месте книги

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

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

Мы уже рассматривали применение туннеля. Когда датаграмма IP перемещается по сети X.25, она обрамляется заголовком сетевого уровня X.25. В этом случае трафик IP пересылается через туннель в среде X.25.

На практике применяется множество других вариантов использования туннелей. Иногда трафик IPX операционной системы Novell NetWare пересылается по туннелю в сети IP. Сообщения из NetWare обрамляются заголовками IP или UDP, маршрутизация производится в сети IP, а доставка выполняется на удаленный сервер NetWare. Многие разработчики предлагают продукты для пересылки по туннелю трафика SNA в сети IP.

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


убрать рекламу







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

4.26 Совместное использование сетевого интерфейса

 Сделать закладку на этом месте книги

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

Чтобы понять, как это происходит, рассмотрим конкретный интерфейс — локальную сеть Ethernet. Если персональный компьютер или сервер станут использовать интерфейс Ethernet для TCP/IP, IPX или DECnet, то как будут сосуществовать эти протоколы?

Мы уже знаем ответ на этот вопрос. Заголовок уровня связи данных содержит поле, идентифицирующее протокол сетевого уровня для конкретного сообщения.

На рис. 4.23 показан интерфейс Ethernet, совместно используемый стеками протоколов TCP/IP, IPX и DECnet. Посредничающий при выполнении операций программный уровень драйверов устройств  скрывает действия по вводу/выводу от стеков протоколов более высокого уровня.



Рис. 4.23. Протоколы совместно используют сетевой интерфейс.

4.27 Замечания об уровне связи данных

 Сделать закладку на этом месте книги

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

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

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

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

4.28 Завершающая часть кадра

 Сделать закладку на этом месте книги

Некоторые проблемы возникают при использовании нестандартных форматов протоколов из устаревших версий TCP/IP. Реализация BSD 4.2 предоставляет нестандартный формат для MAC-кадров Ethernet, в котором исключено поле типа кадра, а информация заголовков уровней 3 и 4 перемещена в завершающую часть кадра  (trailer). Цель этой перестановки — ускорение обработки поступающих кадров за счет снижения количества копирования данных. Такая возможность реализуется в некоторых коммерческих продуктах.

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

4.29 Рекомендуемая литература

 Сделать закладку на этом месте книги

RFC 1661 описывает протокол PPP. Аутентификация в PPP рассматривается в RFC 1334, а автоматический мониторинг качества линии — в RFC 1333.

Существует несколько RFC, обсуждающих пересылку датаграмм IP поверх средств более низкого уровня: RFC 1356 для X.25, RFC 1490 для Frame Relay, RFC 1209 для SMDS, RFC 1390 для FDDI, RFC 1577, 1932, 1626 и 1755 для ATM, RFC 1088 для NetBIOS, RFC 1055 для SLIP, RFC 1042 для сетей IEEE 802, RFC 894 для Ethernet и RFC 1201 для ARCNET.

Сведения о HDLC можно найти в ISO 3309, 4335 и 7809. Серия IEEE 802 и ISO 8802 описывает физические носители, доступ к носителю, а также протоколы логических связей для локальных и городских сетей.

Рекомендации CCITT по X.25 можно обнаружить в "Красной книге" CCITT 1984 г. Существует несколько документов по стандартам для Frame Relay. Лучше всего начать с ANSI T1.606 и рекомендации CCITT 1.122.

RFC 893 обсуждает инкапсуляцию в завершающей части кадра.

Глава 5

Именование и адресация

 Сделать закладку на этом месте книги

5.1 Введение

 Сделать закладку на этом месте книги

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

Администраторы Интернета сталкиваются с обслуживанием имен и адресов в огромной сети, размер которой ежегодно удваивается. Однако в Интернете выбрана удачная стратегия — делегирование полномочий.

Схема имен и адресов Интернета TCP/IP позволяет:

■ Делегировать присваивание имен и адресов тем, кто несет ответственность за работу всей или части отдельной сети

■ Позволить именам отражать логическую структуру организации

■ Присваивать адреса, отражающие топологию физической сети в организации

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

5.2 Примеры имен Интернета

 Сделать закладку на этом месте книги

Некоторые имена Интернета достаточно эксцентричны. Например, группа хостов Медицинской школы Йельского университета имеет следующие названия:

blintz.med.yale.edu 

couscous.med.yale.edu 

gazpacho.med.yale.edu 

lazagne.med.yale.edu 

paella.med.yale.edu 

sukiyaki.med.yale.edu 

strudel.med.yale.edu 

Серверам часто дают такие имена, чтобы пользователи могли легко их найти. Например:

www.whitehouse.gov  (Белый дом — резиденция президента США. — Прим. пер .)

ftp.microsoft.com  (ftp-сайт компании Microsoft. — Прим. пер .)

gopher.jvnc.net  (служба Gopher. — Прим. пер .)

Имена сайтов (узлов) Интернета не зависят от регистра символов. Например, www.whitehouse.gov  можно записать как WWW.WHITEHOUSE.GOV  или WWW.Whitehouse.Gov.  В книге мы будем использовать имена из строчных, прописных или из комбинации строчных и прописных символов.

5.3 Иерархическая структура имен

 Сделать закладку на этом месте книги

Иерархическая структура имен достаточно проста. Каждая организация имеет содержательное имя верхнего уровня, подобное yale.edu, whitehouse.gov  или microsoft.com . Схему именования внутри этих имен организация выбирает самостоятельно. Например, в Йельском и во многих других университетах именование делегировано факультетам и подразделениям. Следовательно, появляются имена, заканчивающиеся на:

cs.yale.edu 

math.yale.edu 

geology.yale.edu 

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

lion.zoo.cs.yale.edu 

leopard.zoo.cs.yale.edu 

tiger.zoo.cs.yale.edu 

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

hickory.theory.cs.yale.edu 

pecan.theory.cs.yale.edu 

olive.theory.cs.yale.edu 

walnut.theory.cs.yale.edu 

5.4 Администрирование имен

 Сделать закладку на этом месте книги

Использование иерархической структуры имен упрощает проверку уникальности имени компьютера, поскольку она возлагается на соответствующий персонал. Отметим следующее:

lion  Администрируется в пределах вычислительного центра зоопарка,  что позволяет иметь для каждого компьютера уникальное имя (lion, tiger  и т.д.).
lion.zoo  Администрируется в пределах всего вычислительного центра. Для каждой подгруппы используется уникальное имя (zoo, theory  и т.д.).
lion.zoo.cs  Администратор всей компьютерной сети Йельского университета присваивает каждому факультету и подразделению уникальное имя (cs, math, geology ), что обеспечивает уникальность имен компьютеров во всем университете.
lion.zoo.cs.yale.edu  Обслуживается официальным комитетом по регистрации, что обеспечивает уникальность имен для всех организаций (yale.edu, microsoft.com ). Следовательно, компьютеры во всем мире могут иметь уникальные имена.

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

Первоначально сеть Интернет спонсировалась Министерством обороны США, создавшим собственный информационный центр сетей  (Department of Defence Network Information Center — DDN NIC), который и занимался администрированием и регистрацией всех имен и адресов.

В 1993 г. ответственность за гражданские имена и адреса принял на себя Национальной научный фонд (National Science Foundation — NFS), а обслуживанием военных систем продолжал заниматься DDN NIC.NFS организовал службу регистрации InterNIC  Registration Service (InterNIC) — главную организацию по именованию и адресации во всемирном масштабе. Однако такая централизация привела к ненужным задержкам в работе этой службы. Поэтому InterNIC делегировала авторизацию имен в два главных центра региональной регистрации:

■ Азиатско-Тихоокеанский сетевой информационный центр (The Asia Pacific Network Information Center)

■ Европейский координационный сетевой центр RIPE (The RIPE Network Coordination Center). RIPE означает Европейский исследовательский центр по IP — Reseaux IP Européens.

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

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

5.5 Формальная структура имен

 Сделать закладку на этом месте книги

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

bellcore.com 

www.apple.com 

ftp.ncsa.uiuc.edu 

lion.zoo.cs.yale.edu 

Более длинные имена сложны для запоминания и ввода пользователями. Однако стандарт Интернета допускает для каждого маркера длину до 63 символов, а общую длину всего имени — до 255 символов.

5.6 Всемирное дерево имен

 Сделать закладку на этом месте книги

Имена Интернета структурированы как дерево (см. рис. 5.1). Каждому узлу дерева присвоена метка. Каждый узел дерева имеет имя, называемое именем домена  (domain name). Имя домена для узла создается из меток, проходимых по пути от  этого узла до  вершины дерева. Имена доменов узлов записываются как последовательность меток, разделенных точками.



Рис. 5.1. Всемирное дерево имен

Кроме того, доменом  называется часть дерева имен, содержащая один из узлов и все нижестоящие узлы. Другими словами, домен создается из всех имен с одинаковыми окончаниями. Примеры доменов:

edu  и все имена ниже этого узла (заканчиваются на edu )

yale.edu  и все имена ниже этого узла (заканчиваются на yale.edu )

cs.yale.edu  и все имена ниже этого узла (заканчиваются на cs.yale.edu )

Доменами верхнего уровня  (top-level domain) являются (см. рис. 5.1):

■ edu —  учебные заведения с четырехгодичным обучением

■ gov  — учреждения федерального правительства США

■ com  — коммерческие организации

■ net  — организации сетевых служб Интернета

■ org  — некоммерческие организации (96olympics.org, npr.org )

■ int  — международные организации (gopher.nato.int ). Редко используются и не видны в сети.

■ mil  — военные организации (army.mil, navy.mil )

■ us  — организации штатов США и региональных правительств, школы, двухгодичные колледжи, библиотеки и музеи

■ Countries  — двухсимвольный код ISO, идентифицирующий десятки других доменов высокого уровня: fr  — Франция, uk —  Великобритания, de —  Германия и т.д. (Для России: su —  старый код и ru  — новый. — Прим. пер .) Структура дерева внутри кода страны администрируется в пределах данной страны.

Домены yale.edu, whitehouse.gov  и ibm.com  называются доменами второго уровня  (second-level domain) — (см. рис. 5.2).



Рис. 5.2. Домены второго уровня

Есть еще одно ограничение. Меткой для корня  (root) дерева имен служит символ точки. Именно поэтому именем системы lion  вычислительного центра Йельского университета реально является:

lion.zoo.cs.yale.edu. 

Однако большинство пользователей (в том числе и автор этой книги) опускают последнюю точку при вводе имен.

5.7 Конфигурирование имен систем

 Сделать закладку на этом месте книги

Конфигурирование имени системы различается для разных систем. Наиболее часто администратор вводит это имя в меню или указывает при выполнении команды.

Для имени tiger  в системе Unix от SunOS  команда hostname  позволяет указать или просмотреть имя хоста:

> hostname

tiger.jvnc.net

Некоторые системы разделяют имя на две части — начальную метку и остаток от имени домена. Это делается с целью применения автоматического использования коротких имен для систем одного узла домена. Например, если пользователь работает на компьютере домена pnc.net  и вводит mickey , то автоматически будет использовано имя mickey.jvnc.net .

Пользователи программного продукта Chameleon  для Windows вводят имя своего компьютера в двух раскрывающихся меню (см. рис. 5.3).



Рис. 5.3. Конфигурирование имени системы

5.8 Адреса

 Сделать закладку на этом месте книги

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

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

Был выбран резонный для того времени метод. В соответствии с 32-разрядным регистром компьютера IP-адрес имеет длину в 32 бита (4 октета): результирующее адресное пространство  (address space) — множество всех возможных адресов — составляет 2³², т.е. 4 294 967 269 номеров.

Нотация с символом точки  упрощает чтение и запись IP-адресов. Каждый октет (8 бит) адреса преобразуется в десятичное число и точкой отделяется от других. Например, адрес для blitz.med.yale.edu  имеет в двоичной записи и нотации с точками следующие значения:

10000010 10000100 00010011 00011111

130 . 132 . 19 . 31

Отметим, что наибольшим числом в записи с точками может быть 255, что соответствует 11111111.

5.9 Форматы адресов

 Сделать закладку на этом месте книги

Как показано на рис. 5.4, IP-адрес состоит из двух частей: адреса сети  (network address) и локального адреса  (local address). Адрес сети идентифицирует сеть, к которой подключен узел, а локальный адрес определяет отдельный узел внутри сети организации.



Рис. 5.4. Формат IP-адреса

Каждый компьютер должен иметь IP-адрес, уникальный среди всех систем, с которыми он будет взаимодействовать.

5.10 Классы адресов

 Сделать закладку на этом месте книги

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

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

Многие годы существовало только три размера блоков адресов — большой, средний и малый. Соответственно, было три различных формата сетевого адреса:

■ Класса А для очень больших сетей

■ Класса В для средних сетей

■ Класса С для небольших сетей

Форматы для классов А, В и С показаны на рис. 5.5. Характеристики для адресов каждого класса представлены в таблице 5.1.



Рис. 5.5. Традиционные классы адресов

В первые дни существования Интернета все адреса класса А получили организации с очень большими сетями, например Военно-морской флот США или корпорация DEC. Сетевая часть таких адресов имеет длину в 1 октет, а оставшиеся 3 октета могут использоваться как локальная часть адреса и присваиваться как номера для узлов сетей.

Существует очень мало адресов класса А, и даже большим организациям часто вполне достаточно адресов класса B. Сетевая часть адреса класса В имеет длину в 2 октета, а 2 оставшихся октета служат для нумерации узлов.

Небольшим организациям присваиваются один или несколько адресов класса С. Сетевая часть в таком адресе имеет длину в 3 октета, а оставшийся октет используется как локальная часть и служит для нумерации узлов.

Это простейший способ распределения IP-адресов. Нужно просто проанализировать первое число в нотации с точками. Диапазоны чисел для каждого класса показаны в таблице 5.1 и на рис. 5.5.


Таблица 5.1 Характеристики классов адресов

Класс Длина сетевого адреса (в октетах) Первое число Количество локальных адресов
A 1 0-127 16777216
В 2 128-191 65536
С 3 192-223 256

Кроме классов А, В и С, существуют специальные адресные форматы: классы E и D. Адреса класса D применяются для многоадресных  рассылок в IP, когда одно сообщение распространяется среди группы разбросанных по сети компьютеров. Многоадресная рассылка необходима для приложений проведения конференций, которые мы рассмотрим ниже.

Адреса класса E используются в экспериментальных целях.

■ Адреса класса D начинаются с номеров между 224 и 239.

■ Адреса класса E начинаются с номеров между 240 и 255.

5.11 Адреса не подключенных к Интернету систем

 Сделать закладку на этом месте книги

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

10.0.0.0–10.255.255.255

172.16.0.0–172.31.255.255

192.168.0.0–192.168.255.255

Многие  организации используют эти адреса. Но если такая компания впоследствии сольется с другой компанией или решит организовать соединения со своими клиентами или поставщиками через TCP/IP, произойдет конфликт адресов. Однако можно зарегистрировать адреса класса С и использовать их для внешних коммуникаций. Можно купить программное обеспечение агентов-прокси (proxy) для преобразования информации между внутренними адресами компьютеров и внешним миром через зарегистрированные адреса класса С. (Локальные сети, которые никогда не предполагается соединять с Интернетом, могут иметь произвольные IP-адреса. — Прим. пер .)

Все "за" и "против" использования зарезервированных адресов можно узнать из RFC 1918 Address Allocation for Private Internet  (Присваивание адресов в частных сетях Интернета),

5.12 Примеры адресации

 Сделать закладку на этом месте книги

В этом разделе мы познакомимся с несколькими примерами глобально уникальных адресов классов А, В и С. Позднее мы рассмотрим новый бесклассовый  (classless) метод присваивания сетевых адресов.

5.12.1 Присваивание сети адресов класса A

 Сделать закладку на этом месте книги

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

15.255.152.2 relay.hp.com 

15.254.48.2 hpfcla.fc.hp.com 

Компания Hewlett-Packard владеет номерами от 15.0.0.0 до 15.255.255.255. Эти номера создают адресное пространство  данной организации.

5.12.2 Присваивание сети адресов класса В

 Сделать закладку на этом месте книги

Зарегистрированное авторство на адреса позволяет присвоить фиксированное значение первым двум октетам в адресе класса B. Последние два октета администрируются в пределах самой организации. Например, следующие адреса и имена хостов предназначены для провайдера Global Enterprise Systems Service Provider, которому был присвоен адрес класса В со значением 128.121.

128.121.50.145 tigger.jvnc.net 

128.121.50.143 mickey.jvnc.net 

128.121.51.51 camel-gateway.jvnc.net 

Системы Global Enterprise владеют адресами от 128.121.0.0 до 128.121.255.255.

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

5.12.3 Присваивание сетям адресов класса С

 Сделать закладку на этом месте книги

Организациям с небольшими сетями, которым требуются глобально уникальные адреса, предоставляются адреса класса С. Это означает, что регистрационное авторство присваивается на три первых октета полного адреса организации. Сама организация управляет только последним октетом. Например, компании WAIS, Inc. был присвоен адрес класса С 192.216.46. Некоторыми из ее адресов и имен хостов могут быть:

192.216.46.4 ns.wais.com 

192.216.46.5 webworld.wais.com 

192.216.46.98 wais.wais.com 

WAIS, Inc. владеет номерами от 192.216.46.0 до 192.216.46


убрать рекламу







.255.

5.13 Трансляция имен в адреса

 Сделать закладку на этом месте книги

Конечному пользователю проще вводить легко запоминаемые имена, когда требуется указать IP-адрес для системы назначения. Многие компьютеры сконфигурированы с созданием небольшого файла hosts , в котором перечислены имена и адреса всех локальных систем. Часть такого файла, хранимого на хосте компании Global Enterprise Systems с именем tigger.jvnc.ne t,  может выглядеть как:

128.121.50.2   r2d2.jvnc.net   r2d2

128.121.50.7   nisc.jvnc.net   nisc

128.121.50.141 minnie.jvnc.net minnie

128.141.50.141 mickey.jvnc.net mickey

128.141.50.143 donald.jvnc.net donald

128.141.50.145 tigger.jvnc.net tigger

128.141.50.148 chip.jvnc.net   chip

128.141.50.149 bambi.jvnc.net  bambi

128.121.50.152 sleepy.jvnc.net sleepy

Все остальные примеры этой главы получены на tigger.jvnc.net .

Запрос к распределенной базе данных системы именования доменов (Domain Name System — DNS) применяется при глобальном преобразовании имен в адреса. Предположим, приложение nslookup  посылает запрос на трансляцию имени в Domain Name Server, называемую r2d2.jvnc.net.  Мы решили выяснить адрес WWW сервера Белого дома (White House) и сервера пересылки файлов компании Novell, Inc.:

> nslookup

Default Server: r2d2.jvnc.net

Address: 128.121.50.2


> www.whitehouse.gov.

Server: r2d2.jvnc.net

Address: 128.121.50.2


Name: www.whitehouse.gov.

Address: 128.102.252.1


> ftp.novell.com.

Server: r2d2.jvnc.net

Address: 128.121.50.2


Name: bantu.Provo.Novell.COM

Address: 137.65.1.3

Aliases: ftp.novell.com

Ответ на второй запрос показывает, что имя ftp.novell.com  в действительности является псевдонимом  (alias) для компьютера bantu.Provo.Novell.COM .

5.14 Псевдонимы имен

 Сделать закладку на этом месте книги

Часто по соглашению можно присвоить компьютеру дополнительно к его реальному имени некоторый псевдоним (или краткое имя — nickname). Например, хост nicol.jvnc.net  обеспечивает пересылку файлов, службу gopher и службу World Wide Web (WWW). По соглашению, ему дополнительно присвоены следующие краткие имена:

ftp.jvnc.net 

gopher.jvnc.net 

www.jvnc.net 


> ftp.jvnc.net.

Server: r2d2.jvnc.net

Address: 128.121.50.2


Name: nicol.jvnc.net

Address: 128.121.50.10

Aliases: ftp.jvnc.net


gopher.jvnc.net.

Server: r2d2.jvnc.net

Address: 128.121.50.2


Name: nicol.jvnc.net

Address: 128.121.50.10

Aliases: gopher.jvnc.net


> www.jvnc.net.

Server: r2d2.jvnc.net Address: 128.121.50.2


Name: nicol.jvnc.net

Address: 128.121.50.10

Aliases: www.jvnc.net

>

Когда нагрузка на nicol  становится слишком большой, одну из его служб (и краткое имя этой службы) можно перенаправить на другой хост. Такой способ дает пользователю возможность достичь службы по неизменному имени, даже если ее домашний сайт будет изменен. Реальное имя хоста называется каноническим именем  (canonical name).

5.15 Неэффективность классов адресов

 Сделать закладку на этом месте книги

Сеть класса А охватывает 16 777 216 адресов, класса В — 65 536, а сеть класса С содержит только 256 номеров. Огромная разница между этими значениями делает неэффективным выделение адресных блоков и приводит к истощению адресного пространства IP.

Более эффективный бесклассовый  метод выделения адресов для организации рассмотрен в разд. 5.19.

5.16 Сети и подсети TCP/IP

 Сделать закладку на этом месте книги

Организации с адресами сетей класса А или В, как правило, имеют очень большие сети, состоящие из множества локальных и нескольких региональных сетей. В этом случае имеет смысл разделить адресное пространство так, чтобы оно отражало структуру сети в виде нескольких подсетей. Для этого локальная часть адреса разделяется на часть для подсети  (subnet part) и системную часть  (system part) любым выбранным организацией способом (см. рис. 5.6).



Рис. 5.6. Деление локального адреса на подсеть и системную часть

Определение размера части адреса для подсети и присваивание номеров подсетям производится организацией, владеющей данной частью адресного пространства.

Адреса подсети часто создаются в соответствии с байтовой границей. Организация с адресом класса В, например 128.21, может использовать для идентификации подсети третий байт:

128.121.1

128.121.2

128.121.3

Четвертый байт будет использоваться для идентификации отдельных хостов в подсети.

Организация с адресом класса С имеет только однобайтовое адресное пространство. Она может вообще не проводить деления на подсети или использовать первые 4 бита для адреса подсети и 4 бита для адресов хостов (см. рис. 5.7). На рисунке видно, что локальный адрес (61) имеет двоичное представление 0011 1101. Первые 4 бита идентифицируют подсеть, а последние 4 бита определяют системы.



Рис. 5.7. Четырехбитовая часть для подсети в адресе класса С

5.17 Маска подсети

 Сделать закладку на этом месте книги

Маршрутизация трафика на хост выполняется посредством анализа сетевой части и части для подсети IP-адреса. Сетевые части адресов классов А, В и С имеют фиксированный размер. Однако организация может указать собственный размер для поля подсети, и тут возникает вопрос о распознавании этой части в хостах и маршрутизаторах. На рис. 5.8 показано меню программы Chameleon  для ввода размера поля подсети.



Рис. 5.8. Конфигурирование маски подсети

Размер поля подсети реально хранится в конфигурационном параметре, называемом маской подсети  (subnet mask). Маска подсети имеет длину в 32 бита. Эти биты отражают для заданной сети длину поля подсети в адресе: для поля подсети в маске располагаются единицы, а для системного поля — нули.

Например, если для идентификации подсети используется третий байт, а сеть имеет адрес 128.121, то маска подсети будет:

11111111 11111111 11111111 00000000

Часто маска подсети записывается десятичной нотацией с точками: 255.255.255.0

Иногда применяется шестнадцатеричный формат:

X'FF-FF-FF-00

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

Например, если сеть содержит большое количество линий "точка-точка", то номера подсети будут использованы очень неэкономно, поскольку в коммуникации участвуют только две системы в каждой из подсетей "точка-точка". Организация может решить использовать 14-битовую маску (255.255.255.252) для соединений "точка-точка".


Таблица 5.2 Подсети в сети класса В

Биты подсети Количество подсетей Биты для хостов Количество хостов Маска подсети
0 0 16 65534 255.255.0.0
1 - 15 - Недопустимая комбинация
2 2 14 16382 255.255.192.0
3 6 13 8190 255.255.224.0
4 14 12 4094 255.255.240.0
5 30 11 2046 255.255.248.0
6 62 10 1022 255.255.252.0
7 126 9 510 255.255.254.0
8 254 8 254 255.255.255.0
9 510 7 126 255.255.255.128
10 1022 6 62 255.255.255.192
11 2046 5 30 255.255.255.224
12 4096 4 14 255.255.255.240
13 8190 3 6 255.255.255.248
14 16382 2 2 255.255.255.252
15 - 1 - Недопустимая комбинация

В таблице 5.2 показаны способы разделения локального адреса для сети класса B. В ней также приведено количество подсетей и хостов в разделах. Это количество на 2 меньше, чем можно было предположить, поскольку существуют некоторые ограничения, которые будут рассмотрены ниже. Например, если подсеть использует 6 бит, шаблон маски подсети будет:

11111111 11111111 11111100 00000000,

что можно записать как 255.255.252.0. Далее мы рассмотрим, почему нельзя использовать комбинации 1/15 (1 бит для подсети и 15 бит для адресов хостов) и 15/1.

В приложении D представлены примеры использования в одной сети нескольких различных масок подсетей, что позволяет эффективно присваивать адреса.

5.18 Специальные зарезервированные адреса

 Сделать закладку на этом месте книги

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

5.18.1 Идентификация сети и подсети

 Сделать закладку на этом месте книги

Для указания сети удобно использовать формат адреса с точками. По соглашению, это делается при заполнении локальной части адреса нулями. Например, 5.0.0.0 указывает на сеть класса А, 131.18.0.0 — на сеть класса В, а 201.49.16.0 — на сеть класса С.

Аналогичным образом указываются подсети. Например, если сеть 131.18.0.0 использует 8-битовую маску подсети, то 131.18.5.0 и 131.18.6.0 будут определять подсети. Эта же нотация применяется для записи сети или подсети назначения в таблице маршрутизации IP. Данное соглашение приводит к тому, что такие адреса нельзя присваивать хостам и маршрутизаторам. Кроме того, использование нуля как номера подсети делает некоторые адреса неоднозначными, например 130.15.0.0. По этой причине применение нулей в поле подсети запрещено в стандарте (см. RFC 1122). Сайты, использующие ноль как маску подсети, тем самым нарушают соглашение.

5.18.2 Широковещательная рассылка в локальной подсети

 Сделать закладку на этом месте книги

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

IP-адрес 255.255.255.255 (т.е. адрес, содержащий 32 единицы) рассылает датаграмму всем системам локальной связи. (Некоторые продукты, и в частности BSD 2.4 TCP/IP, используют для широковещательных рассылок нули вместо единиц. Это нестандартизованный способ, и с течением времени такие операционные системы должны быть заменены на правильные.) Такие широковещательные рассылки применяются, например, в протоколах BOOTP  и DHCP , когда при загрузке система запрашивает для себя IP-адрес и инициализационные данные у загрузочного сервера. Клиент посылает boot-запрос по адресу 255.255.255.255 и использует зарезервированный адрес 0.0.0.0 как IP-адрес источника.

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

5.18.3 Широковещательные рассылки к подсети

 Сделать закладку на этом месте книги

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

Если подсеть назначения является удаленной, то в результате отправки датаграммы IP по широковещательному адресу одна ее копия будет предназначена маршрутизатору, подключенному к сети 131.18.7.0. Предполагая, что подсеть является локальной, маршрутизатор применит адрес физической широковещательной рассылки в поле назначения кадра MAC для пересылки сообщения всем хостам подсети.

Отметим, что при этом подразумевается отсутствие у систем зарезервированного IP-адреса 130.18.7.255.

5.18.4 Широковещательные рассылки в сети

 Сделать закладку на этом месте книги

Допустимо посылать датаграмму IP на каждый хост заданной удаленной сети. Это выполняется при установке всей локальной части адреса в единицы. Например, если администратору нужно послать объявление на все узлы сети 201.49.16.0 класса С с топологией Ethernet, то для такой широковещательной рассылки подойдет IP-адрес:

201.49.16.255

Однако этот адрес не должен быть присвоен ни одному из хостов.

Адрес 131.18.255.255 должен применяться для отправки сообщения на все узлы сети класса С. Отметим, что, хотя и допустимо присваивать номер 255 одной из подсетей, это приведет к проблемам: неясно, предназначена ли широковещательная рассылка 130.15.255.255 для подсети или для всей сети. Чтобы исключить такие ситуации, никогда не следует присваивать номера из всех единиц (например, 255) для подсетей.

5.18.5 Ограничения на IP-адрес

 Сделать закладку на этом месте книги

Набор доступных IP-адресов существенно сокращается из-за применения специальных форматов для широковещательных рассылок и таблиц маршрутизации. Стандарт RFC 1122 Requirements for Internet Hosts — Communication Layers  (Требования к хостам Интернета — уровни взаимодействия) гласит:

■ Поля сети, подсети или хоста не должны содержать одни нули.

■ Поля сети, подсети или хоста не должны содержать одни единицы. Следовательно, на практике поле должно быть длиной не менее 2 бит.

5.18.6 Кольцевой адрес

 Сделать закладку на этом месте книги

Полной противоположностью широковещательной рассылке является метод, когда сообщение вообще не покидает хоста. Существует множество хостов, совмещающих функции клиента и сервера. Локальные сервер и хост взаимодействуют друг с другом через IP внутри данного компьютера. Для этого служит специальный адрес, называемый кольцевым  (loopback). По соглашению, для этого используется любой адрес, начинающийся на 127. На практике обычно применяют только адрес 127.0.0.1. Отметим, что для такого адреса резервируется адресное пространство целой сети класса С.

Работу кольцевого адреса легко увидеть. Например, клиент и сервер FTP программы Chameleon  могут одновременно соединяться в среде Microsoft Windows . После запуска сервера выводится экран, показанный на рис. 5.9.



Рис. 5.9. Сервер FTP в среде Windows

Клиент соединяется с сервером посредством кольцевого адреса 127.0.0.1 (см. рис. 5.10). Любые выполняемые клиентом пересылки файлов просто копируют файлы из одного каталога персонального компьютера в другой каталог того же компьютера. Журнал регистрации сервера позволяет записать выполняемые при этом операции с адресом 127.0.0.1 (см. рис. 5.11).



Рис. 5.10. Клиент FTP соединяется с локальным сервером



Рис. 5.11. Операции клиента с сервером FTP

5.18.7 Заключение о зарезервированных специальных адресах

 Сделать закладку на этом месте книги

Различные типы специальных адресов представлены в таблице 5.3.


Таблица 5.3 Специальные адреса

Адреса Описание
0.0.0.0 Используется как адрес источника в конфигурационном запросе при загрузке. Также отмечает маршрутизатор по умолчанию в таблице маршрутизации.
127.0.0.0 Зарезервирован
127.0.0.1 Кольцевой адрес. Клиентом и сервером является один и тот же хост.
127.0.0.2-127.255.255.255 Зарезервированы
128.0.0.0 Зарезервирован
191.255.0.0 Зарезервирован
192.0.0.0 Зарезервирован
255.255.255.0 Зарезервирован
240.0.0.0-255.255.255.254 Зарезервированы
255.255.255.255 Широковещательная рассылка на локально подключенные локальные сети.

5.19 Суперсети и CIDR

 Сделать закладку на этом месте книги

Методы присваивания адресов с использованием классов А, В и С крайне неэффективны. Адрес класса С предоставляет не более 254 доступных вариантов (0 и 255 нельзя использовать как адреса узлов). С другой стороны, если организации требуется несколько сотен или тысяч адресов, то ей нужно присвоить адрес класса В, и многие адреса такого пространства не будут задействованы.

Больший смысл имеет побитовое выделение адресного пространства в соответствии с реальными потребностями организации. Это сделать очень просто. Например, если организации нужно 4000 адресов, то ей предоставляется 12 бит для применения в локальной части ее адресного пространства. Оставшиеся 20 бит образуют фиксированный префикс, используемый как адрес новой суперсети  или префиксной  части адреса. Общепринятым способом указания размера такой бесклассовой части адреса является /20 .

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


Таблица 5.4 Блоки CIDR из адресного пространства класса С

Размер сетевой части Количество бит в локальной части Эквивалентное число сетей класса С Количество адресов для организации
/24 8 1 256
/23 9 2 512
/22 10 4 1 024
/21 11 8 2 048
/20 12 16 4 096
/19 13 32 8 192
/18 14 64 16 384
/17 15 128 32 768

В таблице 5.4 показаны различные адресные блоки, которые могут присваиваться из адресного пространства класса С. Для направления информации в организацию с такими адресами маршрутизатор Интернета должен знать:

■ Количество бит в сетевом префиксе

■ Реальный битовый шаблон, присвоенный как сетевой префикс для организации

После этого маршрутизатор может направлять трафик в организацию, используя единственную строку из своей таблицы маршрутизации. Такой механизм называется маршрутизацией бесклассовых доменов Интернета  (Classless Internet-Domain Routing — CIDR).

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

Маршрутизация Интернета является более эффективной благодаря делегированию больших адресных блоков провайдерам. Далее провайдер присваивает подблоки адресов своим клиентам. Трафик маршрутизируется к провайдеру с помощью выделенного тому префикса блока. Затем провайдер использует более длинный префикс для маршрутизации трафика к своим клиентам.

Например, провайдеру может быть выделен блок, начинающийся с 10-битового префикса 11000001 11, а одному из клиентов можно присвоить блок, начинающийся с 16-битового префикса 11000001 11011111.

5.20 Необходимость следующего поколения протокола IP

 Сделать закладку на этом месте книги

Внедрение бесклассовых адресов суперсетей и бесклассовой маршрутизации стало последней точкой в совершенствовании и использовании текущей схемы адресации протокола IP.

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

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


убрать рекламу







ятках тысяч отдельных сетей.

Для решения данных проблем был разработан протокол IP версии 6 (Next Generation ), обеспечивающий новые пути в использовании компьютеров и сетей (эта версия рассматривается в главах 22 и 23).

5.21 IP-адреса, интерфейсы и множественное пребывание

 Сделать закладку на этом месте книги

Идентификация сетей и подсетей в IP-адресе имеет много достоинств:

■ Упрощается работа по присваиванию адресов. Блок адресов можно делегировать для администрирования в отдельной сети или подсети.

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

■ Упрощается маршрутизация. Просмотр номеров сетей и подсетей выполняется быстрее и эффективнее.

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



Рис. 5.12. Присвоение IP-адресов интерфейсом

Маршрутизатор соединен с внутренними сетями 128.36.2 и 128.36.18, а также с внешней сетью 193.92.45. Так каков же будет IP-адрес этого маршрутизатора?

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

Хост также может подключаться более чем к одной сети или подсети. На рис. 5.12 хост имеет интерфейсы для двух сетей Ethernet и два IP-адреса: 128.36.2.51 и 128.36.5.17.

Системы, подключенные более чем к одной подсети, называются многоадресными  (multihomed). (Отметим, что в WWW этот же термин означает размещение на одном сервере нескольких сайтов и обычно переводится как "множественное присутствие". — Прим. пер .) Многоадресный хост вносит определенные сложности в маршрутизацию IP. Данные к такому хосту направляются по разным путям, в зависимости от выбранного для коммуникации IP-адреса. Было бы более приемлемо связать с таким хостом несколько имен, соответствующих различным интерфейсам. Например, пользователи локальной сети 128.36.2 могут взаимодействовать с иным именем хоста, чем пользователи локальной сети 128.36.5 (см. рис. 5.12).

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

5.22 Конфигурирование адресов и масок подсети

 Сделать закладку на этом месте книги

Как мы уже знаем, пользовательский интерфейс конфигурирования TCP/IP различается на разных хостах. В системе tigger  команда ifconfig  используется для установки или просмотра связанных с интерфейсом параметров. Ниже показаны параметры Ethernet интерфейса 0 (le0):

> ifconfig lе0

le0: flags = 63 <UP,BROADCAST,NOTRAILERS,RUNNING>

     inet 128.121.50.145 netmask ffffff00 broadcast 128.121.50.255

IP-адрес интерфейса — 128.121.50.145. Маска подсети выведена в шестнадцатеричном формате (ffffff00). Адресом широковещательной рассылки в этой подсети является 128.121.50.255.

Эта же сведения были введены через меню Chameleon . Например, раскрывающееся меню служит для конфигурирования IP-адреса (см. рис. 5.13).



Рис. 5.13. Конфигурирование IP-адреса через меню

5.23 Взаимосвязь имен и адресов

 Сделать закладку на этом месте книги

Посмотрев на имя системы (fermat.math.yale.edu ) и ее IP-адрес в нотации с точками (128.36.23.3), можно подумать, что части имени соответствуют номерам в нотации с точками. Однако на самом деле между ними нет никакой связи.

Действительно, иногда системам локальной сети присваивают имена, которые выглядят  как соответствующие иерархии адресов. Однако:

■ В той же локальной сети могут  находиться имена, полностью нарушающие это правило.

■ Хосты со сходной структурой имен могут  располагаться в различных локальных сетях или различных сетях других типов.

Для примера рассмотрим следующие имена и адреса:

macoun.cs.yale.edu  128.36.2.5

bulldog.cs.yale.edu  130.132.1.2

Адреса отражают сетевую точку подключения и ограничены в расположении, а имена систем, напротив, не зависят от физического подключения к сети. 

Организации могут расширять свои домены именами, подобными chicago.sales.abc.com  или newyork.sales.abc.com . Соответствующие компьютеры могут располагаться в указанных городах (Чикаго или Нью-Йорке).

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

5.24 Протокол ARP

 Сделать закладку на этом месте книги

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

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

Хорошо, что существует процедура автоматического определения физических адресов. Протокол разрешения адресов  (Address Resolution Protocol — ARP) обеспечивает метод динамической трансляции между IP-адресом и соответствующим физическим адресом на основе широковещательных рассылок.

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



Рис. 5.14. Поиск физического адреса системы

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

Когда система-источник получает такой ответ, она обновляет свою таблицу ARP и становится готовой к пересылке данных по локальной сети.

5.24.1 Содержимое сообщения ARP

 Сделать закладку на этом месте книги

Запросы ARP первоначально использовались в локальных сетях Ethernet, но структура таких запросов имеет более общую природу, поэтому их можно применять и в Token-Ring, локальных сетях Fiber Distributed Data Interface (FDDI) или в глобальных сетях Switched Multimegabit Data Service (SMDS). Один из вариантов ARP был разработан для региональных сетей с виртуальными цепями (подобных Frame Relay).

Сообщение ARP помещается в поле данных кадра вслед за заголовком (заголовками) нижних уровней. Например, для Ethernet с кадрами DIX сообщение ARP следует за MAC-заголовком, а для сетей типа 802.3 или 802.5 — за MAC-заголовком, заголовком Logic Link Control (LLC) и подзаголовком Sub-Network Access Protocol (SNAP). Тип протокола для таких кадров (ARP через Ethernet) определяется кодом X'0806. В таблице 5.5 показаны поля сообщения ARP.


Таблица 5.5 Формат сообщения ARP

Количество октетов Поле
2 Тип аппаратного адреса
2 Протокол адресации высокого уровня
1 Длина аппаратного адреса
1 Длина адреса высокого уровня
2 Тип сообщения: 00 01 = запрос, 00 02 = ответ
* Аппаратный адрес источника
* Адрес высокого уровня (IP) источника
* Аппаратный адрес приемника
* Адрес высокого уровня (IP) приемника

Длина последних четырех полей зависит от используемой технологии и применяемого протокола. Аппаратный адрес локальной сети 802.X содержит 6 октетов, а IP-адрес — 4 октета. В таблице 5.6 показаны примеры форматов сообщений, запрашивающих трансляцию IP-адресов в адреса Ethernet.


Таблица 5.6 Примеры сообщений для запросов ARP

Количество октетов Поле Описание
2 00 01 Ethernet
2 08 00 IP
1 06 Длина физического адреса в 6 октетов для Ethernet
1 04 Длина физического адреса IP
2 00 01 Запрос
6 02 07 01 00 53 23 Аппаратный адрес источника
4 80 24 04 12 Адрес высокого уровня источника
6 00 00 00 00 00 00 Аппаратный адрес назначения
4 80 24 04 0B Адрес высокого уровня назначения

При ответе меняются роли источника и приемника. Например, адресом высокого уровня источника  в ответе на запрос станет X'80-24-04-0B.

Применение ARP не ограничивается только TCP/IP: во втором поле также можно указать протокол, использующий ARP.

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

5.24.2 Таблица ARP

 Сделать закладку на этом месте книги

Большинство систем обеспечивает для администратора следующие команды:

■ Просмотр локальной таблицы ARP

■ Ручное удаление или добавление элементов таблицы

■ Загрузку в таблицу информации из конфигурационного файла

Диалог пользователя в процессе выполнения команды arp -a  показывает как изменяется содержимое таблицы ARP системы tigger  при соединении по telnet  с хостом mickey,  сведений о котором ранее не было в таблице. Отметим, что в выводе из команды указываются имена каждой системы, их IP-адреса и 6 октетов физического адреса (шестнадцатеричные числа, разделенные двоеточием).

> arp -a

nomad-eth0.jvnc.net (128.121.50.50) at 0:0:с:2:85:11

r2d2.jvnc.net (128.121.50.2) at 8:0:20:а:2с:3f

jim-mac.jvnc.net (128.121.50.162) at 8:0:7:6f:а6:65

tom-mac.jvnc.net (128.121.50.163) at 8:0:7:ff:96:9е

chip.jvnc.net (128.121.50.148) at 0:0:3b:86:6:4c

nisc.jvnc.net (128.121.50.7) at 8:0:20:11:d2:b7

nicol.jvnc.net (128.121.50.10) at 0:0:3b:30:32:34

minnie.jvnc.net (128.121.50.141) at 8:0:20:7:b5:da

>


> telnet mickey.3vnc.net

Trying 128.121.50.143 …

Connected to mickey.jvnc.net.

Escape character is '^]'

SunOS UNIX (mickey.jvnc.net)


login:

. . .

logout


> arp -a

nomad-eth0.jvnc.net (128.121.50.50) at 0:0:c:2:85:11

r2d2.jvnc.net (128.121.50.2) at 8:0:20:a:2c:3f

jim-mac.jvnc.net (128.121.50.162) at 8:0:7:6f:a6:65

tom-mac.jvnc.net (128.121.50.163) at 8:0:7:ff:96:9e

chip.jvnc.net (128.121.50.148). at 0:0:3b:86:6:4c

nisc.jvnc.net (128.121.50.7) at 8:0:20:11:d2:b7

nicol.jvnc.net (128.121.50.10) at 0:0:3b:80:32:34

minnie.jvnc.net (128.121.50.141) at 8:0:20:7:b5:da

mickey.jvnc.net (128.121.50.143) at 8:0:20:7:53:8f

>

5.24.3 Обратные запросы ARP

 Сделать закладку на этом месте книги

Один из вариантов ARP называется обратным запросом  (reverse ARP — RARP) и служит для определения узлом собственного  IP-адреса. Такие запросы предназначены для бездисковых рабочих станций и других устройств, которые получают конфигурационную информацию от сетевого сервера.

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

Обратные запросы ARP были вытеснены протоколом BOOTP и его улучшенной версией, названной протоколом динамического конфигурирования хоста  (Dynamic Host Configuration Protocol — DHCP). Этот протокол гораздо мощнее и предоставляет больший набор конфигурационных параметров для систем TCP/IP (BOOTP и DHCP будут рассмотрены в главе 11).

5.25 Множество адресов для одного интерфейса

 Сделать закладку на этом месте книги

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



Рис. 5.15. Интерфейс маршрутизатора с двумя IP-адресами

На рис. 5.15 показана локальная сеть с двумя логическими подсетями — 128.36.4.0 и 128.36.5.0. Интерфейсу локальной сети маршрутизатора присвоено два IP-адреса: 128.36.4.1 и 128.36.5.1. В такой сети трафик будет успешно маршрутизироваться, однако потребуется дополнительная работа по правильной маршрутизации датаграмм, направленных на хосты этой сети.

Предположим, что система А имеет 8-битовую маску подсети. Когда А захочет послать датаграмму в В, она пошлет ее маршрутизатору. Чтобы этого избежать, хост локальной сети нужно сконфигурировать с 7-битовой маской подсети, при этом 4 будет соответствовать 0000 0100, а 5 — 0000 0101.

5.26 Прокси ARP

 Сделать закладку на этом месте книги

Предположим, что в сети нельзя использовать смежные номера. Например, 128.36.4.0 и 128.36.20.0 совместно используют носитель. В этом случае хосты локальной сети можно конфигурировать с маской 255.255.0.0, т.е. без выделения подсетей. Затем хосты смогут использовать ARP для всех  точек назначения сети 128.36. Этот метод прекрасно подходит для сетей с совместным использованием носителя, но что делать с трафиком в подсеть сети 128.36, которая не принадлежит общей локальной сети?

Маршрутизатор локальной сети будет управлять внешним трафиком в том случае, если он поддерживает прокси  (прокси иногда называют посредником. — Прим. пер .) ARP  (Proxy ARP). При обнаружении запросов ARP, направляемых в точки назначения, которые являются для локальной сети внешними, маршрутизатор пошлет ответ ARP, содержащий физический адрес самого маршрутизатора . Если в локальной сети несколько маршрутизаторов, выбирается тот, у которого будет наилучший путь для ответа на запрос о точке назначения. Хосту потребуется заключить датаграмму в кадр и переслать ее маршрутизатору, который перешлет ее дальше.

5.27 Многоадресные рассылки

 Сделать закладку на этом месте книги

Широковещательные рассылки в IP позволяют доставить датаграмму на все системы сети или подсети. Вариант с большей избирательностью называется многоадресной  (multicasting) рассылкой. В этом случае датаграммы пересылаются группе систем (см. рис. 5.16).



Рис. 5.16. Распространение датаграммы в многоадресной рассылке

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

Для многоадресной рассылки используются IP-адреса класса D, формат которых представлен на рис. 5.17. Определен протокол для стандартной многоадресной рассылки, однако число поддерживающих этот протокол хостов и маршрутизаторов в настоящее время ограничено. Возможно, через несколько лет это положение изменится.



Рис 5.17. Адрес класса D для многоадресной рассылки в IP

5.27.1 Группы многоадресной рассылки

 Сделать закладку на этом месте книги

Группа многоадресной рассылки  (multicast group) — это набор систем, которым присвоен IP-адрес многоадресной рассылки. Члены группы продолжают использовать собственные IP-адреса, однако они имеют возможность принимать данные, посланные в многоадресной рассылке. Любая система может принадлежать нескольким группам многоадресной рассылки или ни одной из них.

Адреса класса D для многоадресных рассылок находятся в диапазоне номеров от 224 до 239. Некоторые IP-адреса многоадресных рассылок являются постоянными (они перечислены в RFC о присвоенных номерах  Интернета). К таким адресам относятся:

224.0.0.1 Все хосты локальной подсети

224.0.0.2 Все маршрутизаторы локальной подсети

224.0.0.5 Все маршрутизаторы, поддерживающие протокол Open Shortest Path First (OSPF)

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

Хост должен поддерживать несколько определенных функций, чтобы участвовать в одной или нескольких группах многоадресных рассылок:

■ Реализацию команды для объединения с многоадресной группой и идентификации интерфейса, который будет отслеживать соответствующие адреса

■ Распознавание на уровне IP многоадресной рассылки для входящих и исходящих датаграмм

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

Многоадресные рассылки не ограничиваются только локальными сетями. Маршрутизаторы с программным обеспечением для таких рассылок способны распространять датаграммы IP среди систем интернета.

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

Хосты используют протокол обслуживания групп Интернета  (Internet Group Management Protocol — IGMP) для отчета о своем членстве в группе перед ближайшим маршрутизатором, поддерживающим многоадресные рассылки. Такой отчет посылается по IP-адресу многоадресной рассылки, присвоенному данной группе. Маршрутизатор не транслирует такой отчет вне пределов локальной сети, поэтому он будет услышан только маршрутизаторами и другими членами локальной группы.

Так как протокол IGMP предполагает полноту информации о членстве в группе, то он разрешает маршрутизаторам периодически опрашивать хосты о членстве в различных текущих группах. Опрос проводится по IP-адресу многоадресной рассылки 224.0.0.1 на все хосты.

5.27.2 Трансляция многоадресных рассылок в адреса Ethernet и FDDI

 Сделать закладку на этом месте книги

Физическим интерфейсам локальных сетей Ethernet и FDDI могут присваиваться один или несколько адресов для многоадресных рассылок. Это логическое присваивание предполагает выбор из нескольких подходящих для этого значений, что существенно упрощает трансляцию IP-адресов многоадресных рассылок в физические адреса таких рассылок. Отметим, что для этого не нужен протокол ARP.

Для локальных сетей Ethernet и FDDI применяются следующие правила:

■ Первые 3 октета физического адреса для многоадресной рассылки имеют значение 01-00-5E.

■ Следующий далее бит должен быть установлен в 0, а последние 23 бита должны иметь значение младших 23-х битов IP-адреса многоадресной рассылки.

Такое отображение показано на рис. 5.18:

■ Последние 23 бита IP-адреса многоадресной рассылки отмечены как "х". Эти биты копируются в младшие биты физического адреса многоадресной рассылки.

■ Отмеченные символами "?" позиции IP-адреса многоадресной рассылки могут быть заполнены произвольными битами. Они не копируются в физический адрес многоадресной рассылки.



Рис. 5.18. Отображение части IP-адреса на физический адрес

Таким образом, три IP-адреса многоадресной рассылки

11100000 00010001 00010001 00010001

11100000 10010001 00010001 00010001

11100001 10010001 00010001 00010001

будут отображаться на один и тот же  физический адрес многоадресной рассылки:

00000001 00000000 01011110 00010001 00010001 00010001

Интерфейсы систем, принадлежащих одной из трех групп, будут реагировать на многоадресные рассылки в своих группах. Однако каждый из хостов на уровне IP будет отбрасывать (игнорировать) посторонние многоадресные рассылки.

Хорошим способом исключения дополнительной обработки является выбор адресов многоадресных рассылок, в которых в позициях "?" стоят нули. При этом все равно остается 2²³ (примерно 9 млн.) адресов для многоадресных рассылок.

5.27.3 Трансляция адресов многоадресных рассылок в адреса Token-Ring

 Сделать закладку на этом месте книги

К сожалению, рассмотренную выше схему для Ethernet и FDDI почти никогда нельзя применить в Token-Ring (по крайней мере, на момент написания этой книги), поскольку многие аппаратные интерфейсы Token-Ring не могут быть сконфигурированы на произвольные адреса многоадресных рассылок. Следовательно, остается применить один из трех методов трансляции (в зависимости от оборудования):

■ Вставить 23 бита IP-адреса многоадресных рассылок (этот метод рассмотрен выше)

■ Выбрать и использовать один из функциональных  (functional) адресов Token-Ring

■ Применить широковещательную рассылку по всему кольцу  Token-Ring

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

03-00-00-20-00-00

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

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

5.28 Дополнительная литература

 Сделать закладку на этом месте книги

Классы адресов определены в стандарте IP RFC 791. Выделение подсетей описывается в RFC 950, а формирование суперсетей — в RFC 1519. Широковещательные рассылки рассмотрены в RFC 919 и RFC 922.

Протокол Address Resolution Protocol специфицирован для Ethernet в RFC 826. Обратные ARP обсуждаются в RFC 903.

RFC 1112 посвящен многоадресным рассылкам в IP. RFC 1390 определяет трансляцию между IP-адресами многоадресных рассылок и адресами FDDI. RFC 1469 специфицирует трансляцию между IP-адресами многоадресных рассылок и адресами Token-Ring.

RFC 1178 содержит как серьезные, так и не совсем серьезные советы по выбору имени для компьютера. RFC 1034 и 1101 подробно обсуждают именование домен


убрать рекламу







ов. RFC 1035 описывает протоколы для создания Domain Name System и реализацию этой системы.

Стандарт Hosts Requirements (Требования к хостам), RFC 1122, предоставляет дополнительные сведения об именовании и адресации, равно как и корректирует неточности в некоторых стандартах.

Глава 6

Протокол интернета

 Сделать закладку на этом месте книги

6.1 Введение

 Сделать закладку на этом месте книги

Вспомним, что интернет — это набор сетей, соединенных маршрутизаторами (во многих ранних документах RFC использовался термин "шлюз" вместо "маршрутизатор"), a IP — это протокол сетевого уровня, обеспечивающий маршрутизацию данных в интернете. При создании IP исследователи и разработчики руководствовались следующими требованиями Министерства обороны США:

■ Приспособить к взаимодействию хосты и маршрутизаторы различных производителей

■ Объединить расширяющееся множество сетей различного типа

■ Обеспечить расширение сети без прерывания работы сетевых служб

■ Реализовать поддержку высокоуровневых сеансов и служб, ориентированных на сообщения

Всем этим требованиям удовлетворяет архитектура сетевого уровня IP.

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

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

6.2 Датаграммы IP

 Сделать закладку на этом месте книги

Протокол IP предоставляет механизм для пересылки по интернету элементов, называемых датаграммами IP  (IP datagram). Как показано на рис. 6.1, датаграмма IP формируется из заголовка IP и перемещаемой по сети порции данных.



Рис. 6.1. Формат датаграммы

Протокол IP можно назвать "протоколом наилучшей попытки". Это означает, что IP гарантирует не целостность доставки датаграммы в пункт назначения, а только наилучшую попытку выполнить доставку (см. рис. 6.2). Датаграмма может разрушиться по следующим причинам:

■ Ошибка в одном из битов во время пересылки в носителе.

■ Перегруженный маршрутизатор отбросил датаграмму, чтобы освободить свое буферное пространство.

■ Временно недоступен путь к точке назначения.



Рис. 6.2. Доставка в IP по принципу наилучшей попытки

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

6.3 Основные функции IP

 Сделать закладку на этом месте книги

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

■ маска подсети 

■ таблица маршрутизации  IP (таблица маршрутов)

6.4 Использование маски подсети

 Сделать закладку на этом месте книги

Предположим, что компьютер имеет IP-адрес 130.15.12.131 и подключен к локальной сети, а данные нужно послать:

Из: 130.15.12.131

В: 130.15.12.22

Можно предположить, что обе системы находятся в одной и той же подсети. Компьютер должен проверить, верно ли такое предположение. Проверка выполняется по маске подсети. Допустим, что хост имеет маску подсети:

255.255.255.0

т.е. есть маска состоит из 24 единиц и 8 нулей:

11111111111111111111111100000000

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

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

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



Рис. 6.3. Обрамление кадром и передача датаграммы

Адрес назначения, помещенный в заголовок кадра, должен быть физическим адресом системы назначения. Чтобы определить существование элемента для физического адреса 130.15.12.22, проверяется таблица протокола ARP. Если в таблице нет нужной записи, для ее формирования используется протокол ARP.

6.5 Хост в таблице маршрутизации IP

 Сделать закладку на этом месте книги

Предположим, что нужно переслать данные:

Из: 130.15.12.131

В: 192.45.89.5

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

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



Рис. 6.4. Перенаправление трафика через маршрутизатор по умолчанию

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

default 130.15.12.1

Другими словами, нужно направлять любые нелокальные датаграммы на маршрутизатор по умолчанию с IP-адресом 130.15.12.1  (отметим, что адрес назначения 0.0.0.0 используется в таблице маршрутизации для значения по умолчанию).

6.6 Маршрутизация по следующему попаданию

 Сделать закладку на этом месте книги

Для сохранения простоты таблицы маршрутизации хоста IP может не анализировать полный маршрут к точке назначения. Требуется только выяснить следующее попадание  (next hop иногда переводится как следующий участок. — Прим. пер .) и направить датаграмму туда .

Чтобы отправить датаграмму на интерфейс маршрутизатора 130.15.12.1, ее надо поместить в кадр, заголовок которого содержит физический адрес сетевого адаптера этого маршрутизатора.

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

6.7 Еще один пример таблицы маршрутизации хоста

 Сделать закладку на этом месте книги

Иногда таблицы маршрутизации хостов не столь просты. Рассмотрим, например, два маршрутизатора подсети 128.121.50.0 (см. рис. 6.5). Второй маршрутизатор управляет небольшой локальной сетью с несколькими рабочими станциями.



Рис. 6.5. Выбор маршрутизатора

Маршрутизатор tigger  управляет локальной сетью, и его таблицу маршрутизации можно вывести командой netstat -nr . В выводе используется термин шлюз — gateway , а не маршрутизатор — router . (Другие компьютеры могут выводить таблицу в несколько ином формате. Она будет содержать похожую, но не идентичную информацию. Например, некоторые системы могут выводить столбец со сведениями о расстоянии до следующей точки назначения.)

> netstat -nr

Routing tables

Destination  Gateway        Flags Refcnt     Use Interface

127.0.0.1    127.0.0.1      UH         6   62806 lo0

Default      128.121.50.50  UG        62 2999087 le0

128.121.54.0 128.121.50.2   UG         0       0 le0

128.121.50.0 128.121.50.145 U         33 1406799 le0

Командой netstat  выводятся сведения о том, где и как будет маршрутизироваться трафик tigger .

■ Первое место назначения в таблице — это кольцевой  адрес 127.0.0.1, который служит обозначением для трафика между клиентами и серверами в пределах системы tigger .

■ Запись default  используется для выполнения маршрутизации к любой точке назначения, которая не указана в таблице. Трафик должен быть направлен на интерфейс маршрутизатора по IP-адресу 128.121.50.50.

■ Датаграммы к любой системе подсети 128.121.54.0 должны быть направлены на интерфейс маршрутизатора по IP-адресу 128.121.50.2.

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

Команда netstat  выводит и другую интересную информацию:

■ Флаги  (Flags) сообщают, является ли маршрут пригодным для использования и будет ли следующее попадание хостом (H) или шлюзом (G).

■ REFcnt  отслеживает текущее количество активных применений маршрута.

■ Столбец Use  подсчитывает число датаграмм, которые были посланы по маршруту (после последней инициализации).

■ Интерфейс lo0  является логическим  интерфейсом для кольцевого трафика. Весь внешний трафик проходит через один интерфейс Ethernet — le0 .

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

6.8 Правило просмотра таблицы маршрутизации

 Сделать закладку на этом месте книги

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

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

■ Сначала в таблице ищется адрес, полностью совпадающий с IP-адресом назначения. Если он будет найден, эта запись используется для маршрутизации трафика.

■ Если такого адреса нет, в таблице ищется запись для подсети системы назначения.

■ Если нет и такого адреса, в таблице проводится поиск сети назначения.

■ Если отсутствует и этот адрес, в таблице проводится поиск элемента с соответствующим префиксом маршрутизации.

■ Если не будет найден и этот адрес, используется маршрутизатор по умолчанию.

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

6.9 Таблицы маршрутизатора

 Сделать закладку на этом месте книги

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



Рис. 6.6. Маршрутизация по многим направлениям

6.10 Таблица маршрутизации филиала компании

 Сделать закладку на этом месте книги

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



Рис. 6.7. Маршрутизация в филиале компании

Этот маршрутизатор имеет два интерфейса:

Интерфейс IP-адрес
1 130.15.40.1
2 130.15.201.2

Таблица маршрутизации будет содержать:

Назначение Интерфейс Следующее попадание Тип Протокол
130.15.40.0 1 130.15.40.1 Прямая Вручную
0.0.0.0 2 130.15.201.1 Косвенная Вручную

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

Вторая запись указывает маршрут по умолчанию к остальной части сети. Маршрутизатор для следующего попадания — 130.15.201.1 — доступен через интерфейс 2. Главный офис компании достигается косвенным  путем, через маршрутизатор следующего попадания. Оба маршрута были введены вручную.

6.11 Операции глобальной маршрутизации

 Сделать закладку на этом месте книги

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

■ IP хоста А исследует адрес назначения, чтобы проверить, не находится ли он в локальной подсети. Если нет, IP выполнит поиск в таблице маршрутизации.

■ Из таблицы видно, что следующим попаданием является маршрутизатор X. Датаграмма будет заключена в кадр, а в его заголовок будет помещен физический адрес локальной сети для маршрутизатора X.

■ Когда датаграмма прибудет на маршрутизатор X, удаляется ее обрамление кадром. IP маршрутизатора X сравнивает IP-адрес назначения со всеми своими адресами (по маске подсети) и проверяет, не находится ли точка назначения в локально подключенной подсети.



Рис. 6.8. Глобальная маршрутизация

■ Если нет, IP выполнит поиск в таблице маршрутизации. Следующим попаданием станет маршрутизатор Y, куда и будет направлена датаграмма после обрамления ее новым кадром.

■ Когда датаграмма поступит на маршрутизатор Y, будет удалено обрамление кадром. Протокол IP маршрутизатора Y сравнит IP-адрес назначения со всеми своими адресами (по маске подсети) и проверит, не находится ли точка назначения в локально подключенной подсети. Для нашего примера поиск будет успешным и датаграмма будет послана хосту B.

Маршрут от хоста А к хосту В содержал три попадания (участка): A-X, X-Y и Y-B.

6.12 Возможности IP

 Сделать закладку на этом месте книги

В IP существует несколько возможностей, обеспечивающих гибкость и пригодность этого протокола к различным окружениям. Среди прочих следует упомянуть адаптивную маршрутизацию  (adaptive routing), а также фрагментацию и сборку датаграммы  (datagram fragmentation and reassembly).

6.12.1 Адаптивная маршрутизация

 Сделать закладку на этом месте книги

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

Если одна из связей (см. рис. 6.9) будет разорвана, датаграмма может переключиться на другой маршрут (если он будет доступен).



Рис. 6.9. Адаптивная маршрутизация

Изменение в топологии сети приводит к автоматическому перенаправлению датаграммы по другому маршруту.  Адаптивная маршрутизация характеризуется гибкостью и надежностью.

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

6.12.2 MTU, фрагментация и сборка

 Сделать закладку на этом месте книги

Перед тем как датаграмма отправится по сети к участку следующего попадания, она инкапсулируется внутри заголовка (заголовков) второго уровня, требующегося для данной сетевой технологии (см. рис. 6.10). Например, для прохождения сети 802.3 или 802.5 добавляются: заголовок LLC, подзаголовок SNAP, MAC-заголовок и завершающая часть MAC.



Рис. 6.10. Формат пересылки кадра локальной сети

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

Максимальная длина датаграммы для конкретного носителя вычисляется как разность максимального размера кадра, длины заголовка кадра, длины завершающей части кадра и размера заголовка уровня связи данных:

Максимальный размер кадра – длина заголовка кадра – длина завершающей части кадра – размер заголовка уровня связи данных 

Максимально возможная длина датаграммы в заданном носителе называется максимальным элементом пересылки  (Maximum Transmission Unit — MTU). Например, для DIX Ethernet значение MTU равно 1500 октетам, для 802.3 — 1492 октетам, для FDDI — 4352, для SMDS — 9180 октетам.

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

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

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

6.13 Механизмы протокола IP

 Сделать закладку на этом месте книги

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

6.13.1 Заголовок датаграммы

 Сделать закладку на этом месте книги

Заголовок датаграммы организован как 5 или более 32-разрядных слов . Максимальная длина заголовка — 15 слов (т.е. 60 октетов), но на практике большинство заголовков датаграмм имеют минимально возможную длину в 5 слов (20 октетов).

Поля заголовка показаны на рис. 6.11. Они структурированы как последовательность слов. Отметим, что биты слов пронумерованы от 0 до 31.



Рис. 6.11. Формат датаграммы протокола IP

6.13.2 Поля назначения, поле источника и поле протокола

 Сделать закладку на этом месте книги

Наиболее важными полями заголовка являются: Destination IP Address  (IP-адрес назначения), Source IP Address  (IP-адрес источника) и Protocol  (протокол).

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

В таблице 6.1 показаны наиболее распространенные значения из поля протокола .


Таблица 6.1 Общепринятые номера из поля протокола заголовка IP

Номер Название Протокол Описание
1 ICMP Internet Control Message Protocol Переносит сообщения об ошибках и поддерживает отдельные сетевые утилиты
2 IGMP Internet Group Management Protocol Обеспечивает группы для многоадресных рассылок
6 TCP Transmission Control Protocol Обслуживает сеансы
8 EGP Exterior Gateway Protocol Устаревший протокол для маршрутизации во внешней сети
17 UDP User Datagram Protocol Обслуживает доставку независимых блоков данных
88 IGRP Interior Gateway Routing Protocol Обеспечивает взаимный обмен информацией о маршрутизации между маршрутизаторами компании Cisco

6.13.3 Версия, длина заголовка и длина датаграммы

 Сделать закладку на этом месте книги

В настоящее время используется четвертая версия IP (версия "Следующее поколение" имеет номер 6).

Длина заголовка измеряется в 32-разрядных словах. Если не нужны дополнительные варианты, можно ограничиться длиной заголовка в 5 слов (т.е. 20 октетов). Если задействованы один или больше дополнительных вариантов, может потребоваться заполнить конец заголовка незначащими нулями до границы 32-разрядного слова.

Поле длины датаграммы  определяет размер датаграммы в октетах. В это значение включается как заголовок, так и часть данных датаграммы. В таком 16-разрядном поле можно указывать значения до 216-1 октет = 65 535 октетов.

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

6.13.4 Приоритет и тип обслуживания

 Сделать закладку на этом месте книги

Первоначальным спонсором набора протоколов TCP/IP было Министерство обороны США, для которого было важно задание приоритетов датаграмм. Приоритеты мало используются вне военных и правительственных организаций. Для приоритета предназначены 3 бита, обеспечивающие 8 различных уровней.

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

Тип обслуживания  (Type of Service — TOS) содержит биты, определяющие качество обслуживания информации, которое может повлиять на обработку дата


убрать рекламу







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

Положение приоритета и типа обслуживания:

Биты Тип Описание
0-2 Приоритет Уровни 0-7
Уровень 0 — обычный приоритет
Уровень 7 — самый высокий приоритет
3-6 TOS Задержка, надежность, пропускная способность, стоимость или безопасность
7 Зарезервировано для будущего использования

Тип обслуживания определяет (как описано в текущем документе Assigned Numbers ) значения, приведенные в таблице 6.2. Это взаимоисключающие значения — для любой IP-датаграммы требуется только одно значение TOS. Стандарт Assigned Numbers  рекомендует использовать специальные значения для каждого из приложений. Например для telnet  — минимизировать задержку, для копирования файлов — максимизировать производительность и надежность при доставке управляющих сетевых сообщений.


Таблица 6.2 Значения поля типа обслуживания (TOS)

Значение TOS Описание
0000 По умолчанию
0001 Минимизировать денежную стоимость
0010 Максимизировать надежность
0100 Максимизировать производительность
1000 Минимизировать задержку
1111 Максимизировать безопасность

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


Таблица 6.3 Рекомендуемые значения поля типа обслуживания

Протокол Значение TOS Описание
Telnet и другие протоколы для регистрации 1000 Минимизировать задержку
Управляющий сеанс FTP 1000 Минимизировать задержку
Сеанс FTP по пересылке данных 0100 Максимизировать производительность
TFTP 1000 Минимизировать задержку
Фаза команд SMTP 1000 Минимизировать задержку
Фаза данных SMTP 0100 Максимизировать производительность
Запрос DNS к UDP 1000 Минимизировать задержку
Запрос DNS к TCP 0000 Без специального управления
Преобразование зон в DNS 0100 Максимизировать производительность
NNTP 0001 Минимизировать денежную стоимость
Ошибки ICMP 0000 Без специального управления
Запросы ICMP 0000 Обычно 0000, но иногда посылаются с другим значением
Ответы ICMP То же, что и у запроса, для которого формируется ответ
Любые IGP 0010 Максимизировать надежность
EGP 0000 Без специального управления
SNMP 0010 Максимизировать надежность
BOOTP 0000 Без специального управления

6.13.5 Поле времени жизни

 Сделать закладку на этом месте книги

Когда в интернет-системе IP происходит изменение топологии, например обрыв связи или инициализация нового маршрутизатора, некоторые датаграммы могут сбиться со своего маршрута за тот короткий период времени, пока не будет выбран новый маршрутизатор.

Более серьезные проблемы возникают из-за ошибок при ручном вводе информации о маршрутизации. Такие ошибки могут привести к потере датаграммы или зацикливанию ее по круговому маршруту на длительное время.

Поле времени жизни (Time-To-Live — TTL) ограничивает время присутствия датаграммы в интернете. TTL устанавливается хостом-отправителем и уменьшается каждым маршрутизатором, через который проходит датаграмма. Если датаграмма не достигает пункта назначения, а ее поле TTL становиться нулевым, она отбрасывается.

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

Рекомендуемое значение по умолчанию для TTL — примерно в 2 раза больше, чем максимально возможный путь в сети. Длина такого максимального пути часто называется диаметром  (diameter) интернета.

6.13.6 Заголовок контрольной суммы

 Сделать закладку на этом месте книги

Контрольная сумма (checksum) находится в 16-разрядном поле и вычисляется по значению остальных полей заголовка IP как сумма всех дополнений до единицы 16-разрядных слов заголовка. До вычисления поле контрольной суммы содержит 0. Контрольная сумма должна пересчитываться при перемещении датаграммы по сети, поскольку в датаграмме изменяется поле TTL. Могут изменяться и другие значения из заголовка вследствие фрагментации или записи информации в дополнительные поля.

6.14 Фрагментация

 Сделать закладку на этом месте книги

Поля идентификации  (Identification), флагов  (Flags) и смещения фрагмента  (Fragment Offset) позволяют фрагментировать и восстанавливать (собирать) датаграмму. Когда IP нужно переслать датаграмму большего размера, чем MTU следующего участка, то:

1. Сначала проверяется содержимое поля флагов.  Если значение "Не фрагментировать" установлено в 1, ничего делать не нужно — датаграмма отбрасывается и перестает существовать.

2. Если флаг "Не фрагментировать" установлен в 0, то поле данных разделяется на отдельные части в соответствии с MTU следующего участка. Полученные части выравниваются по 8-октетной границе.

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

 a. Длина датаграммы будет отражать текущую длину полученной датаграммы.

 b. Флаг More из поля флагов  устанавливается в 1 для всех частей, кроме последней.

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

 d. Для каждого фрагмента вычисляется собственная контрольная сумма.

Теперь настало время более подробно рассмотреть поля при фрагментации датаграммы.

6.14.1 Поле идентификации

 Сделать закладку на этом месте книги

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

6.14.2 Поле Флагов

 Сделать закладку на этом месте книги

Поле флагов  содержит три бита:

Бит 0 Бит 1 Бит 2
0=Зарезервировано 0=Можно фрагментировать 1=Нельзя фрагментировать 0=Последний фрагмент (Last) 1=Есть еще фрагменты (More)

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

Бит 2 устанавливается в 0 для последней или единственной части датаграммы. Бит 2, установленный в 1, указывает, что датаграмма фрагментирована и имеет следующие далее части.

6.14.3 Поле смещения фрагмента

 Сделать закладку на этом месте книги

Блок фрагментации  (fragment block) — это 8-октетная порция данных. Число в поле смещения фрагмента  (Fragment Offset) указывает величину смещения данного фрагмента (относительно начала датаграммы) в единицах блоков фрагментирования. Это поле имеет длину 13 бит (т.е. смещение может быть от 0 до 8192 блоков фрагментирования — или от 0 до 65 528 октетов). Предположим, что маршрутизатор разделил датаграмму (с идентификатором 348) из 3000 байт данных на три датаграммы по 1000 байт. Каждый фрагмент будет содержать собственный заголовок и 1000 байт данных (125 блоков фрагментирования). Содержимое полей идентификации, флагов  и смещений фрагментов  будет следующим:

Фрагмент Идентификатор Флаги Смещение фрагмента
1 348 Можно фрагментировать, More 0 блоков от начала
2 348 Можно фрагментировать, More 125 блоков (1000 октетов) от начала
3 348 Можно фрагментировать, Last 250 блоков (2000 октетов) от начала

Когда датаграмма доставляется без фрагментации, значения полей будут следующими:

Идентификатор Флаги Смещение фрагмента
348 Можно фрагментировать, Last 0 блоков от начала

Хост получателя, приняв датаграмму, помеченную как "Last" и имеющую смещение 0, знает, что она не фрагментирована.

6.14.4 Сборка фрагментированной датаграммы

 Сделать закладку на этом месте книги

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

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

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

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

6.14.5 Тайм-аут сборки датаграммы

 Сделать закладку на этом месте книги

Рассмотрим следующую последовательность событий:

■ Пересылается датаграмма.

■ Пославший ее процесс аварийно завершается.

■ Датаграмма фрагментируется при пересылке.

■ По пути следования теряется один из фрагментов.

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

6.14.6 Фрагментировать или не фрагментировать

 Сделать закладку на этом месте книги

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

В главе 7 мы познакомимся с протоколом исследования MTU, позволяющим исключить фрагментировать датаграмм и использовать наибольший размер MTU при пересылке информации.

6.15 Просмотр статистики IP

 Сделать закладку на этом месте книги

Узнать о том, как работает IP, можно по достаточно приблизительным статистическим отчетам. Команда netstat -s  выводит содержимое счетчиков для наиболее важных событий в IP. Нижеприведенный отчет получен на сервере tigger.jvnc.net,  который доступен хостам всей сети Интернет. Ответим, что в отчете вместо более точного термина "датаграмма"  используется термин "пакет"  (packet).

> netstat -s

ip:

13572051 total packets received

0 bad header checksums

0 with size smaller than minimum

8 with data size < data length

0 with header length < data size

0 with data length < header length

90 fragments received

0 fragments dropped (dup or out of space)

2 fragments dropped after timeout

0 packets forwarded

10 packets not forwardable

0 redirects sent 0

ip input queue drops

За отчетный период не было ни одной датаграммы с плохой контрольной суммой (checksums) и tigger  не отбросил ни одной датаграммы из-за недостатка памяти. Было принято 90 фрагментов, что составляет 0,00066% от общего объема информации. Два фрагмента отброшены по тайм-ауту, а 10 непересылаемых (nonforwardable) датаграмм, возможно, возникли при попытке маршрутизации от источника через tigger .

6.16 Варианты

 Сделать закладку на этом месте книги

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

■ Strict Source Route (Точный маршрут от источника)

■ Loose Source Route (Произвольный маршрут от источника)

■ Record Route (Запись маршрута)

■ Timestamp (Временная метка)

■ Department of Defense Basic Security (Базовая безопасность Министерства обороны)

■ Department of Defense Extended Security (Улучшенная безопасность Министерства обороны)

■ No Operation (Без операций)

■ End of Option List (Padding) — Конец списка вариантов (заполнитель)

Варианты безопасности используются Министерством обороны и некоторыми правительственными агентствами. Предложено также несколько других вариантов (полный список вариантов и их текущий статус можно найти в последних изданиях Assigned Number  и Internet Official Protocol Standard ).

6.16.1 Маршрутизация от источника

 Сделать закладку на этом месте книги

Существуют два источника: Strict Source Route,  определяющий полный путь к точке назначения, и Loose Source Route,  идентифицирующий контрольные точки по пути следования (milestones). Между контрольными точками можно использовать любые маршруты.

Strict Source Routes иногда применяется для повышения безопасности данных. Однако, как мы увидим далее, этот источник используется и хакерами при взломе систем компьютерной безопасности.

Иногда этот вариант используется при тестировании сетей. Loose Source Route предназначен для помощи при маршрутизации в удаленную точку.

Механизмы обоих вариантов похожи. Единственным отличием является то, что в Strict Source Route можно посещать только  системы из заранее заданного списка.

6.16.2 Обратный маршрут

 Сделать закладку на этом месте книги

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

При этом возникает одна сложность: с точки зрения источника и системы назначения адреса маршрутизаторов различны. На рис. 6.12 показан путь между двумя хостами. Маршрут от хоста А к хосту В предполагает прохождение через маршрутизаторы, адресами которых для хоста А являются 130.132.9.29 и 130.132.4.11. Путь от хоста В к хосту А проходит через маршрутизаторы с IP-адресами, известными хосту В как 128.36.5.2 и 130.132.4.16. Адреса интерфейсов маршрутизатора различны, поскольку они подключены к разным подсетям.



Рис. 6.12. Пути с точки зрения хостов А и В

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

6.16.3 Описание маршрута

 Сделать закладку на этом месте книги

Можно подумать, что для маршрутизации от источника достаточно создать список маршрутизаторов между  источником и точкой назначения. Однако это не так. В таблице 6.4 представлено содержимое полей IP-адреса источника  (Source IP Address), IP-адреса места назначения  (Destination IP Address) и поля маршрутизации от источника  (Source Route) на каждом шаге по пути перемещения:

■ На шаге 1 поле IP-адреса назначения  содержит адрес первого маршрутизатора. Указатель из поля Source Route  определяет следующее попадание (в таблице — полужирным шрифтом).

■ На шаге 2 поле IP-адреса назначения  содержит адрес второго маршрутизатора. Указатель из поля Source Route  определяет следующее попадание. В нашем примере — это реальная точка назначения датаграммы.

■ На шаге 3 датаграмма достигает назначения. Ее поля IP-адреса источника  и назначения  содержат правильные значения, а в Source Route  перечислены все пройденные маршрутизаторы.


Таблица 6.4 Маршрутизация от источника

Шаг IP-адрес источника IP-адрес назначения Поле Source Route
1 130.132.9.44 130.132.9.29 130.132.4.11 128.36.5.76
2 130.132.9.44 130.132.4.11 130.132.4.16 128.36.5.76
3 130.132.9.44 128.36.5.76 130.132.4.16 128.36.5.2

6.16.4 Маршрутизация от источника и безопасность

 Сделать закладку на этом месте книги

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

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

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

6.16.5 Запись пути

 Сделать закладку на этом месте книги

Поле записи пути  (Record Route) содержит список IP-адресов маршрутизаторов, пройденных датаграммой. Каждый встретившийся по пути следования маршрутизатор пытается добавить свой выходной адрес в такой список.

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

6.16.6 Временная метка

 Сделать закладку на этом месте книги

Существуют три формата для поля временной метки  (Timestamp), которое может содержать:

■ Список 32-разрядных временных меток

■ Список IP-адресов и соответствующих им пар временных меток.

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

В первом и втором случаях может не хватить места для записи. Тогда создается подполе переполнения (overflow) для подсчета узлов, которые не смогли записать свои временные метки.

6.16.7 Базовая и улучшенная безопасность для Министерства обороны

 Сделать закладку на этом месте книги

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

Параметр Basic Security  состоит из классификационных уровней, изменяющихся от Unclassified (не секретно) до Top Secret (совершенно секретно) и флагов идентификации авторства. Эти уровни определяют правила для датаграммы. Авторство присвоено нескольким организациям, например Агентству национальной безопасности США, ЦРУ и Министерству энергетики.

Датаграмма с Basic Security может содержать и поле Extended Security . Для этих полей существует несколько различных подформатов,


убрать рекламу







определяющих требования различных владельцев авторства.

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

6.16.8 Конец списка вариантов и отсутствие операций

 Сделать закладку на этом месте книги

Вариант "без операций"  (No Operation) применяется для заполнения промежутков между вариантами датаграмм. Например, он используется для выравнивания следующего варианта по 16- или 32-разрядной границе.

Конец списка вариантов  (End of Option List) служит для заполнения полей вариантов до 32-разрядной границы.

6.16.9 Кодирование вариантов

 Сделать закладку на этом месте книги

Существуют два однобайтовых варианта, кодируемых следующим образом:

No Operation 00000001

End of Option List 00000000

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

Для рассматриваемых вариантов возникает следующий вопрос: нужно ли их копировать в заголовки получаемых при фрагментации датаграмм? Копирование выполняется для Security, Strict Source Route  и Loose Source Route . Поля Record Route  и Timestamp  копируются только в первый фрагмент датаграммы.

Октет типа подразделяется на:

Биты Функция Описание
0 Флаг копирования Устанавливается в 1 для копирования при фрагментации
1-2 Класс варианта 0 — для датаграмм или сетевых управляющих сообщений, 2 — для отладки и измерений
3-7 Номер варианта Уникальное значение для каждого из вариантов

В таблице 6.5 показаны значения октета типа и его деление на поля Copy (копирование), Class (класс) и Option Number (номер варианта) для каждого стандартного варианта.


Таблица 6.5 Поля Copy, Class и Option Number

Значение Copy Class Number Имя
0 0 0 0 End of Options List
1 0 0 1 No Operation
137 1 0 9 Strict Source Route
131 1 0 3 Loose Source Route
7 0 0 7 Record Route
68 0 2 4 Timestamp
130 1 0 2 Security
133 1 0 5 Extended Security

Форматы наиболее общих полей вариантов представлены на рис. 6.13.



Рис. 6.13. Форматы полей вариантов

6.16.10 Кодирование Strict Source Route

 Сделать закладку на этом месте книги

Вариант Strict Source Route  (точный маршрут от источника) содержит указатели на список адресов. Указатель определяет позицию следующего обрабатываемого адреса. Первоначально указатель имеет значение 4, которое увеличивается на 4 при каждом попадании.

6.16.11 Кодирование Loose Source Route

 Сделать закладку на этом месте книги

Вариант Loose Source Route  (произвольный маршрут от источника) содержит указатели на список адресов. Исходное положение указателя, как в предыдущем случае, здесь 4 и увеличивается на 4 при достижении каждого из адресов списка.

6.16.12 Кодирование Record Route

 Сделать закладку на этом месте книги

Вариант Record Route  (запись маршрута) содержит указатели и место для записи адресов. Первоначально указатель имеет значение 4, а место, предназначенное для записи адреса, пусто.

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

6.16.13 Кодирование Timestamp

 Сделать закладку на этом месте книги

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

Если в подполе флага содержится 0, то при каждом попадании в выделенном месте записывается временная метка, а значение указателя увеличивается на 4. Когда будет заполнено все предварительно выделенное пространство, значение подполя переполнения увеличивается на единицу и все поступающие датаграммы отбрасываются.

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

6.16.14 Кодирование Basic и Extended Security Options

 Сделать закладку на этом месте книги

Значения этих полей устанавливаются военными и правительственными агентствами. Дополнительные сведения можно получить в RFC 1108.

6.17 Пример заголовка IP

 Сделать закладку на этом месте книги

На рис. 6.14 показан результат работы анализатора Sniffer  компании Network General для заголовка MAC-кадра сети DIX Ethernet и для заголовка IP.

DLC: - DLC Header -

DLC:

DLC: Frame 14 arrived at 10:26:10.5797; size is 61 bytes

DLC: Destination = Station Sun 076A03, Sun Atlantis

DLC: Source = Station Sun 07FD89, Sun Jupiter

DLC: Ethertype = 0800 (IP)

DLC:


IP: - IP Header -

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of Service = 00

IP:  000. .... = routine

IP:  ...0 .... = normal delay

IP:  .... 0... = normal throughput

IP:  .... .0.. = normal reliability

IP: Total length =47 bytes

IP: Identification = 4458

IP: Flags = 0X

IP: .0.. .... = may fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to Live = 30 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = 12F4 (correct)

IP: Source address = [192.42.252.1]

IP: Destination address = [192.42.252.20]

IP: No options

IP:


HEX


MAC Header

06 00 20 07 6A 03 (Destination physical address)

08 00 20 07 FD 89 (Source physical address)

08 00             (Protocol Type for IP)


IP Header

45 00 00 2F (Version, Hdr Length, Prec/TOS, Total Length)

11 6A 00 00 (Identification, Flags, Fragment Offset)

1E 06 12 F4 (Time to Live, Protocol, Header Checksum)

C0 2A FC 01 (Source IP Address)

C0 2A FC 14 (Destination IP Address)



Рис. 6.14. Интерпретация заголовков MAC и IP

Заголовок MAC начинается 6-байтовыми физическими адресами систем источника и назначения. Отметим, что анализатор Sniffer  заменяет первые 3 байта каждого физического адреса на соответствующее имя компании — производителя сетевого адаптера (в нашем случае это Sun ). Поле типа содержит код X'0800, что означает: "данную информацию доставлять в IP".

На рисунке датаграмма IP следует сразу за коротким MAC-заголовком сети DIX Ethernet. Это кадр стандарта 802.3, а за MAC-заголовком располагаются 8-байтовый заголовок LLC с подзаголовком SNAP.

Размер кадра — 61 байт. В эту величину включается 14-байтовый MAC-заголовок кадра, но не учитывается 4-байтовая завершающая часть MAC, поэтому полный кадр имеет длину 65 байт. Кадры Ethernet или 802.3 для носителя на коаксиальном кабеле должны иметь длину не менее 64 байт, следовательно, кадр едва не стал меньше допустимого минимального размера. Датаграмма кадра имеет общую длину только 47 байт.

Как и многие заголовки IP, рассматриваемый в примере заголовок не содержит вариантов и, следовательно, имеет длину 20 байт. На практике поле Type of Service  имеет, как правило, значение 0.

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

Датаграмма зафиксировала информацию о 30 попаданиях в поле TTL.  Поле Protocol  имеет значение 6, что указывает на доставку датаграммы TCP на хост назначения.

Анализатор Sniffer  транслировал IP-адреса источника и назначения в общепринятый формат с точками.

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

6.18 Сценарий обработки датаграммы

 Сделать закладку на этом месте книги

Для лучшего понимания работы IP рассмотрим операции по обработке датаграммы в маршрутизаторе и хосте назначения. Выполняемые при этом шаги показаны на рис. 6.15.



Рис. 6.15. Обработке датаграммы

Возникающие проблемы и ошибки приводят обычно к отбрасыванию датаграммы и посылке источнику сообщения об ошибке. Эти процессы будут рассмотрены в главе 7, посвященной протоколу Internet Control Message Protocol  (ICMP).

6.18.1 Обработка в маршрутизаторе

 Сделать закладку на этом месте книги

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

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

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

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

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

6.18.2 Обработка в хосте назначения

 Сделать закладку на этом месте книги

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

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

Целая датаграмма пересылается соответствующей службе высокого уровня, например TCP или UDP.

Хост не ожидает полного завершения сборки датаграммы из фрагментов. Когда поступает первый фрагмент, таймер устанавливается в локально конфигурируемое значение (обычно между 1 и 2 минутами). Фрагменты датаграммы, не собранные за это время, отбрасываются.

6.19 Средства защиты и безопасность

 Сделать закладку на этом месте книги

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

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

■ IP-адреса источника

■ IP-адреса назначения

■ Протокола

■ Приложения



Рис. 6.16. Маршрутизатор со средствами защиты

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

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

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

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



Рис. 6.17. Защита сайта с помощью демилитаризованной зоны

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

6.20 Замечания о производительности IP

 Сделать закладку на этом месте книги

Производительность интернета зависит от количества доступных ресурсов на хостах и маршрутизаторах и от эффективности их использования. К таким ресурсам относятся:

■ Полоса пропускания пересылки информации

■ Объем буферной памяти

■ Скорость работы центрального процессора (ЦП)

Совершенных механизмов работы протоколов не существует. Разработка протоколов требует компромисса между широтой возможностей и эффективностью.

6.20.1 Полоса пропускания

 Сделать закладку на этом месте книги

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

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

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

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

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

Эти алгоритмы оказывают существенное влияние на производительность сети и поэтому стали неотъемлемой частью стандарта TCP (см. главу 10).

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

6.20.2 Использование буфера

 Сделать закладку на этом месте книги

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

6.20.3 Ресурсы центрального процессора

 Сделать закладку на этом месте книги

Обработка датаграмм не приводит к большой загрузке центрального процессора (ЦП). Анализ заголовка достаточно прост. Не требуется сложного программного обеспечения для обслуживания тайм-аутов и повторной трансляции.

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

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

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

 Сделать закладку на этом месте книги

Существует класс IP-адресов, используемых в многоадресных  рассылках (см. главу 5), позволяющий маршрутизировать датаграмму от источника к группе систем, заданной одним из адресов класса D. Технологии и протоколы поддержки многоадресных рассылок в приложениях (например, в конференциях) существенно улучшились и расширили свои возможности за последние несколько лет.

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

■ Отправитель многоадресной рассылки может не являться членом группы этой рассылки.

■ Некоторые адреса для многоадресной рассылки стандартизированы и неизменны. Они зарегистрированы в IANA и опубликованы в RFC Assigned Numbers .

■ Временные адреса многоадресной рассылки выбираются некоторым текущим процессом администрирования — их уникальность не гарантируется.

■ Адрес многоадресной рассылки "все хосты"  — 224.0.0.1 — уникален. Датаграммы, посланные группе всех хостов, никогда не могут покинуть локальную подсеть.

■ Протокол IGMP  обеспечивает механизм для разрешения многоадресным маршрутизаторам определять принадлежность хостов к группе многоадресной рассылки. IGMP рассматривается как составная часть IP. Сообщения IGMP переносятся датаграммами IP со значением 2 в поле протокола.

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

Рассмотрим сценарий работы многоадресного хоста:

■ Хост, который хочет подключиться к  группе и получать многоадресные рассылки, начинает прослушивать адрес многоадресной рассылки для всех хостов (224.0.0.1).

■ Если хост хочет подключиться к конкретной группе, он должен сообщить об этом всем многоадресным маршрутизаторам по локальной связи. Для этого он отправляет сообщение-отчет  IGMP по адресу нужной группы многоадресной рассылки. Поле TTL такого сообщения установлено в 1, и сообщение не может покинуть локальную подсеть.

■ Затем хост начинает прослушивать датаграммы, посланные по адресу многоадресной рассылки.

■ Кроме того, хост реагирует на периодические запросы от локальных маршрутизаторов и отвечает соответствующим отчетом.

■ Для выхода из группы хост просто прекращает прослушивание на адрес этой группы и перестает направлять отчеты в группу.

Рассмотренные действия хоста слишком прямолинейны. Маршрутизация должна быть несколько сложнее и поэтому находится в стадии совершенствования. Рассмотрим действия в маршрутизаторе:

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

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

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

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


убрать рекламу







у другому многоадресному маршрутизатору.

IGMP-сообщение хоста имеет формат, показанный на рис. 6.18. Значение типа 1 определяет Host Membership Query (запрос о членстве хоста), а значение 2 — Host Membership Report (отчет о членстве хоста).



Рис. 6.18. Формат сообщения IGMP от хоста

6.22 Рекомендуемая литература

 Сделать закладку на этом месте книги

Протокол IP определен в RFC 791. Изменения, корректировки и требования совместимости специфицированы в RFC 1122. RFC 1812 подробно описывает требования IP версии 4 к маршрутизаторам и содержит подробные сведения об операциях таких маршрутизаторов.

Варианты безопасности Министерства обороны обсуждаются в RFC 1108. Вычислению контрольной суммы в Интернете посвящены RFC 1071, 1141 и 1624. RFC 815 представляет эффективные алгоритмы для сборки после фрагментации датаграммы в хосте получателя.

RFC 1112 специфицирует расширения хостов для многоадресных рассылок в IP.

Глава 7

Протокол ICMP

 Сделать закладку на этом месте книги

7.1 Введение

 Сделать закладку на этом месте книги

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

Средства для лечения таких неисправностей предоставляет протокол управляющих сообщений Интернета  (Internet Control Message Protocol — ICMP). Он выполняет роль сетевого помощника, способствуя маршрутизации в хостах и обеспечивая сетевого администратора средствами определения состояния сетевых узлов. Функции ICMP являются важной частью IP. Все хосты и маршрутизаторы должны быть способны генерировать и обрабатывать сообщения ICMP. При правильном использовании эти сообщения могут улучшить выполнение сетевых операций.

Сообщения ICMP пересылаются в датаграммах IP с обычным заголовком IP (см. рис. 7.1), имея в поле протокола  значение 1.



Рис. 7.1. Пакетирование сообщения ICMP

7.2 Сообщения об ошибках ICMP

 Сделать закладку на этом месте книги

Бывают ситуации, приводящие к отбрасыванию (удалению из сети) датаграммы IP. Например, точка назначения может стать недоступной из-за обрыва связи. Или может завершиться время жизни датаграммы. Маршрутизатор не сможет переслать длинную датаграмму при запрещении фрагментации.

При отбрасывании датаграммы по адресу ее источника направляется сообщение ICMP, указывающее на возникшую проблему. На рис. 7.2 показано сообщение ICMP, направленное к источнику датаграммы.



Рис. 7.2. Сообщение ICMP направляется по пути трафика.

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

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

Реально ICMP не имеет средств предоставить отчет об ошибках выделенному операционному центру. Для этого служит протокол SNMP (см. главу 20).

7.2.1 Типы сообщений об ошибках

 Сделать закладку на этом месте книги

На рис. 7.3 показаны обобщенные сообщения, формируемые маршрутизатором и хостом назначения для отчета о возникшей проблеме. В таблице 7.1 перечислены формальные имена сообщений об ошибках ICMP.



Рис. 7.3. Типы сообщений об ошибках ICMP


Таблица 7.1 Сообщения об ошибках ICMP

Сообщение Описание
Destination Unreachable  (недостижимая точка назначения) Датаграмма не может достичь хоста назначения, утилиты или приложения.
Time Exceeded  (время закончилось) Маршрутизатор определил завершение времени жизни, или закончилось время на сборку фрагментов в хосте назначения.
Parameter Problem  (проблема с параметром) В заголовке IP неверный параметр.
Source Quench  (подавление источника) Перегружен маршрутизатор или система назначения (системам рекомендуется не отправлять это сообщение).
Redirect  (перенаправление) Хост направил датаграмму на неверный локальный маршрутизатор.

7.2.2 Обязанность по отправке сообщения ICMP

 Сделать закладку на этом месте книги

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

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

7.2.3 Входящие сообщения ICMP

 Сделать закладку на этом месте книги

Что происходит при получении хостом сообщения ICMP? Рассмотрим пример, когда производится попытка обращения по зарезервированному (и, следовательно, недостижимому) адресу сети:

> telnet 10.1.1.1

Trying 10.1.1.1 ...

telnet: connect: Host is unreachable

Произошло то, что и должно было произойти,— в сообщении указано на недостижимость хоста (Host is unreachable).

Чтобы определить, какой  из маршрутизаторов послал сообщение ICMP, можно использовать команду traceroute :

> traceroute 10.1.1.1

traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets

> nomad-gateway (128.121.50.50) 2 ms 2 ms 2 ms

> liberty-gateway (130.94.40.250) 91 ms 11 ms 78 ms

> border2-hssi2-0.NewYork.mci.net (204.70.45.9) !H !H !H

Маршрутизатор New York послал сообщение Destination Unreachable , которое отображается на экране как !Н.

Функции traceroute  основаны на ICMP-сообщении Time Expired  и формируются следующим образом:

■ Создается короткое сообщение UDP, которое имеет заголовок IP с установленным в 1 полем TTL.

■ Трижды отправляется датаграмма.

■ Первый маршрутизатор (в примере — nomad-gateway ) устанавливает значение Time-to-Live (время жизни) в 0, отбрасывает датаграмму и отправляет источнику ICMP-сообщение Time Expired .

■ Функция traceroute  идентифицирует пославший сообщение маршрутизатор и трижды выводит само сообщение.

■ Значение Time-to-Live устанавливается в 2, и сообщение посылается дальше.

■ Процесс повторяется с увеличением Time-to-Live на каждом шаге.

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

7.3 Когда не нужно  посылать сообщение ICMP

 Сделать закладку на этом месте книги

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

■ Маршрутизации и доставке ICMP-сообщений messages

■ Широковещательных и многоадресных датаграммах

■ Фрагментах датаграмм, кроме первых

■ Сообщениях, чей адрес источника не идентифицирует уникальный хост (например, IP-адреса источников 127.0.0.1 или 0.0.0.0)

7.4 Формат сообщения ICMP

 Сделать закладку на этом месте книги

Сообщение ICMP переносится в части данных датаграммы IP. Каждое сообщение ICMP начинается тремя одинаковыми полями: полем типа  (Type), полем кода  (Code), обеспечивающим более подробное описание ошибки, и полем контрольной суммы  (Checksum). Формат оставшейся части сообщения определяется типом сообщения.

Сообщение об ошибке ICMP обрамляется заголовком IP. Добавляются первые 8 октетов датаграммы, которая привела к ошибке. Эти сведения позволяют проанализировать причину ошибки, поскольку содержат информацию о предполагаемом назначении датаграммы и целевом протоколе четвертого уровня. Дополнительные 8 байт позволяют определить коммуникационный элемент приложения (более подробно об этом см. в разделе о протоколах TCP и UDP).

В сообщение включается и контрольная сумма ICMP, начиная от поля Type .

7.4.1 Сообщение Destination Unreachable

 Сделать закладку на этом месте книги

Существует много причин прекращения доставки датаграммы. Разорванная связь физически не позволит маршрутизатору достичь подсети назначения или выполнить пересылку в точку следующего попадания. Хост назначения может стать недоступным при отключении его для проведения профилактики.

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



Рис. 7.4. Формат ICMP-сообщения Destination Unreachable

Формат сообщения Destination Unreachable  показан на рис. 7.4. Поле Type (в нашем случае 3) идентифицирует именно этот тип  сообщения. Поле Code  отражает причину отправки сообщения. Полный список кодов этого поля представлен в таблице 7.2.


Таблица 7.2 Коды ошибок сообщения Destination Unreachable

Код Смысл
0 Сеть недостижима.
1 Хост недостижим.
2 Запрашиваемый протокол не поддерживается в точке назначения.
3 Порт недостижим (недоступно удалённое приложение).
4 Необходима фрагментация, но установлен флаг "Не фрагментировать".
5 Неверен маршрут от источника.
6 Неизвестна сеть назначения.
7 Неизвестен хост назначения.
8 Хост источника изолирован.
9 Административно запрещены коммуникации с сетью назначения.
10 Административно запрещены коммуникации с хостом назначения.
11 Сеть недостижима для заданного типа обслуживания.
12 Хост недостижим для заданного типа обслуживания.

7.4.2 Сообщение Time Exceeded

 Сделать закладку на этом месте книги

Пересылаемая датаграмма может быть отброшена по тайм-ауту при уменьшении до нуля ее времени жизни (TTL). Еще один тайм-аут может возникнуть в хосте назначения, когда завершится время, выделенное на сборку, а прибыли еще не все фрагменты датаграммы. В обоих случаях формируется сообщение Time Exceeded  для источника датаграммы. Формат этого сообщения показан на рис. 7.5.



Рис. 7.5. Формат ICMP-сообщения Time Exceeded

Значения кодов (см. таблицу 7.3) отражают причину тайм-аута.


Таблица 7.3 Коды сообщения Time Exceeded

Код Смысл
0 Завершилось время жизни датаграммы.
1 Завершилось время на сборку фрагментов датаграммы.

7.4.3 Сообщение Parameter Problem

 Сделать закладку на этом месте книги

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



Рис. 7.6. Формат ICMP-сообщения Parameter Problem

Поле Pointer  (указатель) сообщения Parameter Problem  идентифицирует октет, в котором выявлена ошибка. На рис. 7.6 показан формат сообщения Parameter Problem , а в таблице 7.4 — значения кодов ошибок.


Таблица 7.4 Коды сообщения Parameter Problem

Код Смысл
0 Значение в поле указателя специфицирует ошибочный октет.
1 Отсутствует требуемый вариант (используется военными для указания на отсутствие параметров безопасности)
2 Неверная длина

7.4.4 Проблемы перегрузок

 Сделать закладку на этом месте книги

Протокол IP очень прост: хост или маршрутизатор обрабатывают датаграмму и посылают ее как можно быстрее. Однако доставка не всегда проходит гладко. Могут возникнуть различные проблемы.

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

Маршрутизатор может переполнить свои буферы и далее будет вынужден отбрасывать некоторые поступающие датаграммы. Медленное соединение через региональную сеть (например, на скорости 56 Кбит/с) между двумя скоростными локальными сетями (например, в 10 Мбит/с) может создать затор на пути следования датаграмм. Из-за этого в сети возникнут перегрузки, которые также приведут к отбрасыванию датаграммы и, следовательно, к созданию еще большего трафика.

7.4.5 Сообщение Source Quench

 Сделать закладку на этом месте книги

Сообщение Source Quench  (подавление источника) показано на рис. 7.7. Оно позволяет попытаться решить проблему перегрузок, хотя и не всегда успешно. Механизмы для подавления источника перегрузки сети должны создавать разработчики конкретных продуктов, но остается открытым конкретный вопрос:

Когда и кому маршрутизатор или хост должен отправлять сообщение Source Quench? Рис. 7.7. Формат ICMP-сообщения Source Quench



Обычно ICMP-сообщение указывает хосту источника на причину отбрасывания посланной им датаграммы. Однако при перегрузке такое сообщение может не дойти до этого хоста, генерирующего очень напряженный сетевой трафик. Кроме того, очень расплывчаты требования к обработке поступающих сообщений Source Quench .

Текущий документ по требованиям к хостам  (RFC 1812) оговаривает в качестве особого пункта, что сообщения Source Quench  вовсе не нужно  посылать. Работа должна выполняться более совершенным механизмом управления нагрузкой в сети.

7.4.6 Сообщения Redirect

 Сделать закладку на этом месте книги

К локальной сети может быть подключено более одного маршрутизатора. Когда локальный хост посылает датаграмму не на тот маршрутизатор, последний пересылает ее и отправляет хосту источника ICMP-сообщение Redirect  (перенаправление), как показано на рис. 7.8. Хост должен переключить последующий трафик на более короткий путь.



Рис. 7.8. Коррекция маршрутизации на хосте посредством сообщения Redirect

Сообщение Redirect  используется и для выключения маршрутизатора системным администратором. Хост может быть сконфигурирован с единственным маршрутизатором по умолчанию; при этом он будет динамически определять возможности пересылки через другие маршрутизаторы.



Рис. 7.9. Формат ICMP-сообщения Redirect

Формат сообщения о перенаправлении показан на рис. 7.9. Коды этого сообщения перечислены в таблице 7.5. Некоторые протоколы маршрутизации способны выбирать путь доставки на основе содержимого поля типа обслуживания  (TOS) датаграммы. Коды 2 и 3 предоставляют некоторые сведения да такого выбора.


Таблица 7.5 Коды перенаправления

Код Смысл
0 Перенаправление датаграммы в сеть
1 Перенаправление датаграммы в хост
2 Перенаправление датаграммы в сеть на основе значения из поля типа обслуживания
3 Перенаправление датаграммы в хост на основе значения из поля типа обслуживания

7.4.7 Управление поступающими сообщениями ICMP

 Сделать закладку на этом месте книги

Что должен делать хост, получивший сообщение ICMP? Реализации различных разработчиков по-разному отвечают на этот вопрос. В некоторых из них хосты игнорируют все или многие такие сообщения. Стандарты TCP/IP оставляют большую свободу выбора в решении этого вопроса. Для различных типов сообщений ICMP предлагаются следующие рекомендации:

Destination Unreachable  Доставить ICMP-сообщение на транспортный уровень. Выполняемые действия должны зависеть от того, является ли причина вывода сообщения временной или постоянной (например, административный запрет на пересылку).
Redirect  Хост обязан  обновить таблицу маршрутизации.
Source Quench  Доставить ICMP-сообщение на транспортный уровень или в модуль обработки ICMP.
Time Exceeded  Доставить на транспортный уровень.
Parameter Problem  Доставить ICMP-сообщение на транспортный уровень с необязательным уведомлением пользователя.

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

7.5 Исследование MTU по пути

 Сделать закладку на этом месте книги

При пересылке большого объема данных (например, при копировании файлов по сети) с одного хоста на другой размер датаграмм существенно влияет на производительность. Заголовки IP и TCP требуют не менее 40 дополнительных байт.

■ Если данные пересылаются в 80-байтовых датаграммах, дополнительная нагрузка составит 50%.

■ Если данные пересылаются в 400-байтовых датаграммах, дополнительная нагрузка составит 10%.

■ Если данные пересылаются в 4000-байтовых датаграммах, дополнительная нагрузка составит 1%.

Для минимизации дополнительной нагрузки лучше отсылать датаграммы наибольшего размера. Однако этот размер ограничивается значением максимального элемента пересылки (Maximum Transmission Unit — MTU) для каждого из носителей. Если датаграмма будет слишком большой, то она будет фрагментирована, а этот процесс снижает производительность. (С точки зрения пользователя, качество сети определяется двумя параметрами: интервалом пересылки (от начала пересылки до ее завершения) и временем ожидания (задержкой доступа к сети, занятой другими пользователями). Увеличение размера датаграммы приводит к снижению интервала пересылки, но увеличению ожидания для других пользователей. Грубо говоря, нагрузка на сеть будет выглядеть как пиковые импульсы с очень небольшой нагрузкой между ними, что считается самым неудачным вариантом загрузки сети. Гораздо лучше, когда сеть нагружается равномерно. — Прим. пер .)

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

Гораздо полезнее заранее знать наибольший допустимый размер датаграммы, которую можно переслать по заданному пути. Существует очень простой механизм исследования MTU по пути  (Path MTU discovery), позволяющий узнать это значение. Для такого исследования:

■ Флаг "Не фрагментировать"  заголовка IP устанавливают в 1.

■ Размер MTU по пути первоначально устанавливают в значение MTU для локального интерфейса.

■ Если датаграмма будет слишком велика для одного из маршрутизаторов, то он пошлет обратно ICMP-сообщение Destination Unreachable  с кодом 4.

■ Хост источника уменьшит размер датаграммы и повторит попытку.

Какое же значение нужно выбрать для следующей попытки? Спецификация IP предполагает сохранение значения MTU и его доступность для протоколов транспортного уровня. Если маршрутизатор имеет современное программное обеспечение, то он будет включать в пересылаемое дальше по сети сообщение Destination Unreachable  размер MTU (см. рис. 7.10). Иногда средства защиты конфигурируются на полное исключение всех  входящих сообщений ICMP, что не позволяет использовать механизм определения MTU по пути следования датаграммы.



Рис. 7.10. Сообщение Destination Unreachable приносит результат исследования размера

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

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

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

7.6 Сообщения запросов ICMP

 Сделать закладку на этом месте книги

Не все сообщения ICMP сигнализируют об ошибках. Некоторые из них извлекают из сети полезные сведения. Работает ли хост X? Не выключен ли хост Y? Как долго движется датаграмма до хоста Z и обратно? Какова маска подсети хоста источника?

Ответы на эти вопросы дают следующие сообщения ICMP:

■ Эхо-запросы  и эхо-ответы  обеспечивают обмен информацией между хостами и маршрутизаторами.

■ Запросы и


убрать рекламу







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

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

На рис. 7.11 представлено обслуживание запросов ICMP. Программа Ping  посылает эхо-сообщение "Вы в рабочем состоянии?", которое используется в ежедневной работе сетевого администратора. Запросы о маске адреса  применяются от случая к случаю, а запросы о временной метке  вообще редко.



Рис. 7.11. Сообщение запроса ICMP

7.6.1 Эхо-запросы и эхо-ответы

 Сделать закладку на этом месте книги

Эхо-запросы  (Echo Request) и эхо-ответы  (Echo Reply) применяются для проверки активности системы. Код типа 8 применяется в запросах, а код 0 — в ответах. Количество октетов в поле данных переменно и может выбираться отправителем.

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



Рис. 7.12. Формат ICMP-сообщений Echo Request и Echo Reply

Широко известная команда ping  доступна почти во всех системах TCP/IP, а ее работа основана на ICMP-сообщениях для эхо-запросов и эхо-ответов. В приведенном ниже диалоге сначала тестируется хост ring.bell.com . Затем отсылается последовательность из 14 сообщений, содержащих по 64 октета каждое. Отметим, что сообщения 0, 1 и 2 были потеряны. Справа приводятся сведения о пути туда и обратно.

> ping ring.bell.com

ring.bell.com is alive

> ping -s ring.bell.com 64 14

64 bytes from ring.bell.com: icmp_seq=3. time = 21. ms

64 bytes from ring.bell.com: icmp_seq=4. time = 18. ms

64 bytes from ring.bell.com: icmp_seq=5. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=6. time = 19. ms

64 bytes from ring.bell.com: icmp_seq=7. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=8. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=9. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=10. time = 18. ms

64 bytes from ring.bell.com: icmp_seq=11. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=12. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=13. time = 17. ms


-ring.bell.com PING Statistics-

14 packets transmitted, 11 packets received, 21% packet loss

round-trip (ms) min/avg/max = 17/17/21

7.6.2 Маска адреса

 Сделать закладку на этом месте книги

Напомним, что организация может разделить поле своего локального адреса на часть подсети и часть хоста. Когда включается система, она может быть сконфигурирована так, что не будет заранее знать, сколько бит было присвоено полю адреса подсети. Чтобы выяснить этот вопрос, система посылает широковещательный запрос на определение маски адреса  (Address Mask Request).

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

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

На рис. 7.13 показан формат запроса маски адреса  и ответа  на него. Тип 17 применяется для запроса, а тип 18 — для ответа. В общем случае можно игнорировать идентификатор и последовательный номер.



Рис. 7.13. Формат ICMP-сообщений Address Mask

На практике более предпочтительный метод определения маски адреса предоставляют протоколы загрузки, например Dynamic Host Configuration Protocol  или BOOTP . Эти протоколы более эффективны, поскольку обеспечивают полный набор конфигурационных параметров. Кроме того, операции выполняются более точно, в том числе и некорректные.

7.6.3 Временная метка и ответ на Timestamp

 Сделать закладку на этом месте книги

Сообщение с ответом на Timestamp  предоставляет сведения о времени в системе. Оно предназначено для оценки буферизации и обработки датаграммы на удаленной системе. Отметим следующие поля:

Originate timestamp  (исходная временная метка) Время последнего обращения к сообщению в системе-отправителе
Receive timestamp  (временная метка получения) Время первого обращения к сообщению отвечающей системы
Transmit timestamp  (временная метка пересылки) Время последнего обращения к сообщению отвечающей системы

По возможности, возвращаемое время должно измеряться в миллисекундах относительно полуночи по универсальному времени (Universal Time), которое ранее называлось временем по Гринвичу (Greenwich Mean Time). Большинство реализаций реально возвращает одно и то же время в полях Receive timestamp  и Transmit timestamp .

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

Тип 13 используется для запросов,  а 14 — для ответов.  Формат сообщения представлен на рис. 7.14.



Рис. 7.14. Формат сообщений запросов и ответов о временной метке

7.7 Просмотр действий в ICMP

 Сделать закладку на этом месте книги

Ниже показана часть отчета о статистике протоколов команды netstat. Приведенный фрагмент посвящен протоколу ICMP. В отчете отражены операции ICMP, выполненные после последней инициализации.

> netstat -s


icmp:

 1075 calls to icmp_error


 Output histogram:

  echo reply: 231

  destination unreachable: 1075


 2 messages with bad code fields

 0 messages < minimum length

 21 bad checksums

 0 messages with bad length


 Input histogram:

  echo reply: 26

  destination unreachable: 1269

  source quench: 2

  echo: 231

 231 message responses generated

Система отправила 1075 сообщений Destination Unreachable . Был получен 231 запрос Echo Requests , на каждый из которых был отправлен ответ. Было получено 26 ответов Echo Replies .

Локальная система зафиксировала 21 сообщение ICMP, полученное с неверной контрольной суммой ICMP.

Системой было получено 1269 сообщений Destination Unreachable  и 2 сообщения Source Quenches .

Следующий далее отчет команды netstat  содержит сведения о маршрутизации. Видно, что через сообщения Redirect  были динамически обнаружены новые маршрутизаторы. Было 12 отчетов о недостижимости точки назначения  (Destination Unreachable). Для выбора маршрута по умолчанию было использовано около 349 подстановочных символов  (wildcard).

> netstat -rs

routing:

 0 bad routing redirects

 0 dynamically created routes

 2 new routers due to redirects

 2 destinations found unreachable

 349 uses of a wildcard route

7.8 Обнаружение маршрутов

 Сделать закладку на этом месте книги

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

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

Протокол исследования маршрутов  (Router Discovery) предоставляет надежный метод, основанный на сообщениях ICMP, для отслеживания маршрутизаторов локальной сети. Основная идея состоит в периодическом объявлении маршрутизаторами о своем присутствии. Хостам нужно прослушивать такие сообщения.

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

Подключающийся к сети хост может быть не способен к ожиданию при поиске маршрутизаторов локальной сети. Такой хост самостоятельно запрашивает маршрутизаторы об отправке их объявлений о присутствии на собственный адрес. Для этого лучше всего использовать сообщение Router Solicitation  (настоятельная просьба к маршрутизаторам) в многоадресной рассылке по адресу "все маршрутизаторы"  (224.0.0.2). Поскольку не все системы поддерживают многоадресные рассылки, иногда применяется широковещательная рассылка (255.255.255.255).

Типичный сценарий для маршрутизатора:

■ Каждый интерфейс маршрутизатора конфигурируется с адресом объявления  (advertisement address) — 224.0.0.1 или 255.255.255.255 — для локальной сети, подключенной к данному интерфейсу.

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

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

■ Маршрутизатор напоминает о себе различными периодическими сообщениями Router Advertisement (рекомендуемый период 7–10 мин.).

■ Маршрутизатор посылает объявление  о присутствии при запросе об этом от хоста.

Для хоста сценарий выглядит так:

■ Каждый интерфейс хоста конфигурируется с Solicitation Address —  224.0.0.2 или 255.255.255.255.

■ При инициализации хоста начинается прослушивание Router Advertisement .

■ При запуске хост может послать необязательное сообщение Router Solicitation  по адресу настоятельных просьб (solicitation address). Маршрутизаторы ответят как по IP-адресу хоста, так и по адресу объявления.

■ Когда хост услышит о новом маршрутизаторе, он добавит маршрут по умолчанию  в свою таблицу маршрутизации. Этому элементу таблицы присваивается значение тайм-аута на время жизни (обычно 30 мин), которое указано в Router Advertisement .

■ Тайм-аут на время жизни сбрасывается при получении нового объявления от маршрутизатора. Если время жизни завершается по тайм-ауту, элемент для маршрутизатора удаляется из таблицы маршрутизации хоста.

■ Для объявления всем о корректном отключении от сети маршрутизатор может послать объявления с нулевым значением для времени жизни.

Если имеется более одного маршрутизатора, то как хост определяет тот, которому следует направить данную датаграмму? Каждое объявление маршрутизатора содержит номер предпочтительного уровня  (preference level). Если таблица маршрутизации не содержит специальных указаний, выбирается маршрутизатор с наибольшим  предпочтительным уровнем. Если он не сможет обеспечить наилучший маршрут, то ответит хосту ICMP-сообщением о перенаправлении.

В ICMP-сообщении Router Advertisement  имеет значение типа 9, a Router Solicitation  — 10.

7.8.1 Неисправные маршрутизаторы

 Сделать закладку на этом месте книги

Исследование маршрутов (маршрутизаторов) помогает хостам определить крах локального маршрутизатора, однако после достаточно длительного периода времени — возможно, через 30 мин. Реализация TCP/IP для хостов предполагает использование встроенного алгоритма для определения неисправности маршрутизатора. Его достоинства очевидны, например:

■ Существование активного сеанса TCP/IP через маршрутизатор

■ Фиксирование получения от маршрутизатора ICMP-сообщений о перенаправлении.

К числу недостатков можно отнести:

■ Невозможность ответа на запросы ARP

■ Множество последовательных тайм-аутов при повторной пересылке в TCP

Если есть причины считать маршрутизатор неисправным, окончательная проверка выполняется по запросу ping .

IP версии 6 обеспечивает наилучший способ исследования причин приостановки работы локальных хостов или маршрутизаторов.

7.9 Дополнительная литература

 Сделать закладку на этом месте книги

ICMP определен в RFC 792. RFC 1122 (требования к хостам) и RFC 1812 (требования к маршрутизаторам) содержат несколько очень полезных разъяснений. Исследованию маршрутов посвящен RFC 1256.

Исследование MTU по пути рассмотрено в RFC 1191, а дополнительные рекомендации представлены в RFC 1435.

Глава 8

Маршрутизация в IP

 Сделать закладку на этом месте книги

8.1 Введение

 Сделать закладку на этом месте книги

Маршрутизация — наиболее важная функция протокола IP. В больших сетях маршрутизаторы IP обмениваются информацией для сохранения корректного состояния своих таблиц маршрутизации. Каким образом это выполняется?

Единого протокола для изменения информации в таблицах маршрутизации IP не существует. 

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

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

На сегодняшний день широко используется несколько протоколов IGP. Остается очень популярным протокол информации о маршрутизации  (Routing Information Protocol — RIP), выбирающий маршрут на основе оценки простого счетчика попаданий.

Сайты с маршрутизаторами компании Cisco часто выбирают лицензированные протоколы этой компании — протокол маршрутизации шлюзов Интернета  (Internet Gateway Routing Protocol — IGRP) или улучшенный протокол IGRP  (Enhanced IGRP — EIGRP), в которых применяется весьма сложный способ измерения стоимости, учитывающий множество факторов, включая нагрузку и надежность.

Более сложный протокол, предлагающий первым открывать кратчайший путь  (Open Shortest Path First — OSPF), применяется в больших сетях. Некоторые организации используют протокол от одной промежуточной системы к другой  (Intermediate System to Intermediate System — IS-IS), который может маршрутизировать как трафик IP, так и OSI. Протоколы OSPF и IS-IS формируют подробные карты для сетей и генерируют пути перед выбором маршрута.

Предоставление свободы выбора протокола для организации конечного пользователя реализуется прекрасно. Однако необходим стандарт для маршрутизации в сети провайдера при соединении между собой сетей конечных пользователей. Хотя еще применяют устаревший протокол внешнего шлюза  (Exterior Gateway Protocol — EGP), большинство провайдеров перешло на протокол граничного шлюза  (Border Gateway Protocol — BGP).

В этой главе мы познакомимся с каждым из упомянутых выше протоколов и рассмотрим различия в предоставляемых ими возможностях.

8.2 Автономные системы

 Сделать закладку на этом месте книги

Как можно предоставить столько различных возможностей при выборе протокола маршрутизации? Модель Интернета разделяет весь мир (как всегда, имеется в виду сетевой мир. — Прим. пер .) на элементы, именуемые автономными системами  (Autonomous System — AS). Грубо говоря, автономной системой является чья-то сеть. Более формальное определение:

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

(RFC 1812, Требования к IP версии 4).

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

Типичной автономной системой является сеть компании или провайдера. Реально никому нет дела до автономной системы, пока не возникает потребность во взаимодействии с ней. В этом случае нужно зарегистрироваться в InterNIC и получить собственный номер автономной системы  (Autonomous System Number). На рис. 8.1 показаны компании, провайдеры, автономные системы и использование ими протоколов IGP и BGP. Часто нет нужды в обмене информацией о маршрутизации между компанией и провайдером, а необходимые для этого сведения можно ввести вручную.



Рис. 8.1. Автономные системы и протоколы маршрутизации

Администратор сети организации самостоятельно выбирает типы маршрутизаторов для внутреннего использования, как и протокол (протоколы) маршрутизации.

Как же объединяются автономные системы? Способ для этого найден в Интернете уже много лет назад. Как можно догадаться, уникальный номер автономной системы играет в этом основную роль. Протокол внешнего шлюза  (External Gateway Protocol — EGP) использует такие номера и выполняет всю необходимую работу.

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

Для маршрутизации номер автономной системы идентифицирует весь кластер сети, состоящий из сети провайдера и всех сетей его клиентов. Как отмечено в RFC 1930, новое определение для автономной системы такое:

Автономной системой является соединенная вместе группа из одного или нескольких префиксов IP для одной или нескольких сетей, имеющих единую  и строго определенную  политику маршрутизации.

Многие подключенные к Интернету сети имеют очень простую политику маршрутизации, т.е. один провайдер обеспечивает обмен данными с другими сетями Интернета. Такие сети не имеют отдельного номера автономной системы.

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

IANA определила один из блоков IP-адресов для личного (не общедоступного) использования. Для получения личного номера автономной системы можно воспользоваться зарезервированным IANA диапазоном от 64 512 до 65 535.

8.3 Маршрутизация в IP

 Сделать закладку на этом месте книги

Датаграмма IP следует по пути, состоящему из участков попаданий, первый из которых формируется при выходе из узла в смежную с ним локальную или региональную сеть. Маршрутизаторы, отстоящие друг от друга на одно попадание, называются соседями  (neighbor).

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

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

8.4 Метрики маршрутизации

 Сделать закладку на этом месте книги

Для сравнения и выбора лучшего из двух маршрутизаторов используется определенный тип метрик  (удаленных изменений).

8.4.1 Протоколы вектора расстояния

 Сделать закладку на этом месте книги

Самый простой протокол для сравнения маршрутизаторов использует счет попаданий между конечными точками пути. Некоторые улучшенные варианты оценивают стоимость  или вес  каждого из участков по пути следования. Например, участок попадания через высокоскоростную локальную сеть имеет вес, равный 1, а участок через низкоскоростной носитель (линия "точка-точка" на 19,2 Кбайт/с) имеет вес 10. Таким образом, путь по скоростному участку предпочтительнее пересылки по низкоскоростной связи. Протокол RIP  оценивает маршрут по счетчику попаданий.

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

Алгоритмы для принятия решения при маршрутизации, основанные на значениях метрик, называются векторами расстояния  (distance vector).

8.4.2 Протоколы по состоянию связи

 Сделать закладку на этом месте книги

Ранее большое внимание уделялось алгоритмам маршрутизации по состоянию связи  (link state). Работающие по этому принципу маршрутизаторы создают карту сети и исследуют пути от себя до каждой из точек сети.

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

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

Алгоритмы вычисления состояния связи часто первым  именуют кратчайший  путь (Shortest Path First — SPF). Это же название дается компьютерному алгоритму, вычисляющему наиболее короткие пути от одного узла до всех остальных узлов сети.

8.5 Таблицы маршрутизации

 Сделать закладку на этом месте книги

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

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

Точка назначения по умолчанию представляется как 0.0.0.0.

Не существует стандартов на формат таблиц маршрутизации, однако наиболее простая из них должна содержать следующие элементы:

■ Адрес сети, подсети или системы назначения

■ IP-адрес используемого маршрутизатора следующего попадания

■ Сетевой интерфейс для доступа к маршрутизатору следующего попадания

■ Маску для точки назначения

■ Расстояние до точки назначения (количество попаданий)

■ Время в секундах от последнего изменения маршрута

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

8.6 Таблица маршрутизации по протоколу RIP

 Сделать закладку на этом месте книги

Элементы маршрутизации таблицы 8.1 получены из университетског


убрать рекламу







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


Таблица 8.1 Таблица маршрутизации RIP-маршрутизатора

IP-маршрут назначения Маска IP-маршрута IP-маршрут следующего попадания Тип IP-маршрута Протокол IP-маршрута Метрика IP-маршрута 1 Метрики IP-маршрутов: 2, 3, 4, 5 (совпадают) Индекс ЕСЛИ IP-маршрута Возраст IP-маршрута (секунды)
0.0.0.0 0.0.0.0 128.36.0.2 * rip 2 -1 1 153,84
128.36.0.0 255.255.255.0 128.36.0.62 ** *** 0 -1 1 0
128.36.2.0 255.255.255.0 128.36.0.7 * rip 1 -1 1 30
128.36.11.0 255.255.255.0 128.36.0.12 * rip 1 -1 1 13
128.36.12.0 255.255.255.0 128.36.0.21 * rip 1 -1 1 15
128.36.13.0 255.255.255.0 128.36.0.12 * rip 1 -1 1 14
128.36.14.0 255.255.255.0 128.36.0.21 * rip 1 -1 1 16
128.36.15.0 255.255.255.0 128.36.0.21 * rip 1 -1 1 17
128.36.16.0 255.255.255.0 128.36.0.36 * rip 12 -1 1 24
128.36.17.0 255.255.255.0 128.36.0.12 * rip 1 -1 1 16
128.36.19.0 255.255.255.0 128.36.0.10 * rip 14 -1 1 27
128.36.20.0 255.255.255.0 128.36.0.10 * rip 1 -1 1 28
128.36.21.0 255.255.255.0 128.36.0.5 * rip 1 -1 1 5
128.36.22.0 255.255.255.0 128.36.0.5 * rip 1 -1 1 5
128.36.126.0 255.255.255.0 128.36.0.41 * rip 1 -1 1 23
130.132.0.0 255.255.0.0 128.36.0.2 * rip 2 -1 1 25
192.31.2.0 255.255.255.0 128.36.0.1 * rip 3 -1 1 10
192.31.235.0 255.255.255.0 128.36.0.41 * rip 1 -1 1 25

* — косвенный

** — прямой

*** — локальный

Таблица маршрутизации содержит элементы для многих различных подсетей сети 128.36.0.0, а также маршруты к сетям 130.132.0.0, 192.31.2.0 и 192.31.235.0 (эти значения извлечены из маршрутизатора приложением HP Open View for Windows Workgroup Node Manager ). Четыре столбца правой части таблицы не используются в RIP).

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

 Сделать закладку на этом месте книги

Для поиска совпадения с адресом назначения (например, 128.36.2.25) нужно сравнить 128.36.2.25 с каждым элементом маршрута назначения  (Route Destination). Элементы маски маршрута  (Route Mask) указывают, сколько бит из 128.36.2.25 должны совпадать с битами маршрута назначения. Допустим, третья строка таблицы 8.1 имеет маску маршрута 255.255.255.0, означающую, что должны совпадать первые три байта, 128.36.2 (именно так и будет). Более формально можно сказать, что нужно сравнивать маршрут назначения с результатом операции логического умножения адреса назначения и маски маршрута.

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

8.6.2 Маршрут по умолчанию

 Сделать закладку на этом месте книги

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

8.6.3 Использование подсети 0

 Сделать закладку на этом месте книги

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

8.6.4 Прямые и косвенные назначения

 Сделать закладку на этом месте книги

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

Оставшиеся элементы перечисляют удаленные подсети и сети, которые достигаются косвенно  (indirect) при направлении трафика на другие маршрутизаторы. Такие маршруты изучаются средствами протокола RIP.

8.6.5 Метрики маршрутизации

 Сделать закладку на этом месте книги

В таблице предусмотрено место для нескольких метрик. RIP использует только одну из них — простой счетчик количества попаданий по пути к точке назначения. Неиспользуемые значения установлены в -1. Отметим, что метрика 0 присвоена подсети 128.36.0, которая подключена непосредственно к маршрутизатору. Многие другие точки назначения доступны за одно попадание. Однако подсеть 128.36.19.0 отстоит от маршрутизатора на 14 попаданий.

Мы рассматривали маршрутизатор модели Shiva Lanrover , имеющий множество телефонных номеров для подключения линий к интерфейсу 1.

8.6.6 Возраст маршрута

 Сделать закладку на этом месте книги

Столбец возраста маршрута  (Route Age) отслеживает количество секунд от последнего изменения или проверки каждого из маршрутов. Элементы таблицы, созданные через RIP, будут считаться недействительными по тайм-ауту возраста, если их невозможно реконфигурировать в течение трех минут.

8.7 Таблица маршрутизации IGRP/BGP

 Сделать закладку на этом месте книги

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


Таблица 8.2 Элементы таблицы маршрутизации IGRP и BGP

IP-маршрут назначения Маска IP-маршрута IP-маршрут следующего попадания Тип IP-маршрута Протокол IP-маршрута Метрика IP-маршрута Индекс ЕСЛИ IP-маршрута Возраст IP-маршрута (секунды)
1 2 3 4 5
0.0.0.0 0.0.0.0 130.94.40.250 косвенный ciscolgrp 10647 1170 21000 0 255 6 12
128.121.50.0 255.255.255.0 128.121.50.50 прямой локальный 0 -1 -1 -1 -1 1 0
128.121.52.0 255.255.255.0 128.121.50.55 прямой локальный 0 -1 -1 -1 -1 1 35
128.121.54.0 255.255.255.0 128.121.50.50 прямой локальный 0 -1 -1 -1 -1 1 0
128.6.0.0 255.255.0.0 130.94.0.49 косвенный ciscolgrp 12610 1536 61000 2 255 3 11
128.96.0.0 255.255.0.0 130.94.40.250 косвенный ciscolgrp 14647 1170 61000 2 255 6 16
130.33.0.0 255.255.0.0 130.94.16.2 косвенный ciscolgrp 8710 1536 22000 1 255 2 18
130.44.0.0 255.255.0.0 130.94.0.49 косвенный ciscolgrp 16610 1536 101000 4 255 3 37
130.68.0.0 255.255.0.0 130.94.0.49 косвенный ciscolgrp 12710 1536 62000 3 255 3 39
130.94.1.24 255.255.255.248 130.94.0.49 косвенный ciscolgrp 82125 128 40000 0 255 3 41
130.94.1.32 255.255.255.248 130.94.0.49 косвенный ciscolgrp 182571 56 40000 0 255 3 42
130.94.2.8 255.255.255.248 130.94.0.49 косвенный ciscolgrp 10510 1536 40000 0 255 3 42
130.94.2.16 255.255.255.248 130.94.0.49 косвенный ciscolgrp 10510 1536 40000 0 255 3 43
130.94.7.0 255.255.255.248 130.94.0.49 косвенный ciscolgrp 10610 1536 41000 1 255 3 2
130.94.7.8 255.255.255.248 130.94.0.49 косвенный ciscolgrp 12510 1536 60000 1 255 3 3
44.0.0.0 255.0.0.0 130.94.15.201 косвенный bgp 0 -1 -1 -1 -1 6 51766
128.3.0.0 255.255.0.0 130.94.40.201 косвенный bgp 0 -1 -1 -1 -1 6 42049
129.210.0.0 255.255.0.0 130.94.15.201 косвенный bgp 0 -1 -1 -1 -1 6 586765
13.0.0.0 255.0.0.0 130.94.15.201 косвенный bgp 0 -1 -1 -1 -1 6 224463

Таблица маршрутизации содержит строки для различных сетей и подсетей (информация из маршрутизатора извлечена через систему управления HP Open View ).

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

 Сделать закладку на этом месте книги

Для поиска совпадения с назначением 128.121.54.101 нужно применить маску маршрута  для каждого элемента и сравнить результат с назначением маршрута  (Route Destination). Применение маски 255.255.255.0 к четвертой строке даст 128.121.54.0, что совпадает с элементом назначения.

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

8.7.2 Маршрут по умолчанию

 Сделать закладку на этом месте книги

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

8.7.3 Прямые и косвенные точки назначения

 Сделать закладку на этом месте книги

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

Далее идет несколько строк для удаленных (косвенных) точек назначения, положение которых было определено маршрутизатором посредством лицензированного протокола IGRP компании Cisco.

8.7.4 Малые подсети

 Сделать закладку на этом месте книги

Набор точек назначения начинается со строки таблицы, содержащей 130.94.1.24, которая выглядит как адрес хоста. Однако маска маршрута указывает, что все эти элементы являются небольшими подсетями. Они имеют часть адреса для хостов, состоящую только из трех последних бит. Например, двоичное представление 24 — 00011000, и все биты для представления этого числа реально принадлежат части адреса для подсети. Хосты такой подсети будут располагаться в диапазоне адресов от 130.94.1.25 до 130.94.1.30.

8.7.5 Строки для протокола Border Gateway Protocol

 Сделать закладку на этом месте книги

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

8.7.6 Метрики маршрутизации

 Сделать закладку на этом месте книги

Во второй части таблицы 8.2 видно, что метрика 0 присвоена тем точкам назначения, доступ к которым можно получить в трех непосредственно связанных с маршрутизатором сетях. Как и раньше, значения неиспользуемых метрик равны -1.

Всем пяти метрикам значения присвоены при помощи протокола IGRP компании Cisco. Однако не было попыток обеспечить осмысленные значения для метрик точек назначения Интернета в удаленных автономных системах, которые исследовались через протокол BGP.

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

8.7.7 Возраст маршрута

 Сделать закладку на этом месте книги

Для протокола IGRP столбец возраста маршрута  (Route Age) означает количество секунд, прошедших со времени последнего изменения или проверки маршрута. Строки таблицы маршрутизации, получаемые через этот протокол, должны время от времени реконфигурироваться. Для протокола BGP возраст маршрута отражает стабильность маршрутов в удаленные точки сети.

8.8 Протоколы обслуживания таблиц маршрутизации

 Сделать закладку на этом месте книги

Каким образом маршрутизаторы получают информацию для строк своих таблиц? Как поддерживать коррект


убрать рекламу







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

■ Анализировать сетевые датаграммы для определения наилучшего пути. Выбирать следующее попадание для каждого из маршрутов.

■ Обеспечивать ручной ввод данных в таблицу маршрутизации.

■ Обеспечивать ручное изменение строк таблицы маршрутизации.

Именно такие операции и выполняет простой маршрутизатор для подразделения компании (см. рис. 8.2). Он может иметь в таблице только две строки — для локальной сети 192.101.64.0 и маршрут по умолчанию для облака (облаками на рисунках принято обозначать сетевые связи через несколько маршрутизаторов. — Прим. пер .).



Рис. 8.2. Маршрутизация в подразделении компании

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

На некотором уровне сложности человек не сможет проанализировать и описать все сетевые условия. Поэтому протокол маршрутизации должен автоматизировать:

■ Обмен информацией между маршрутизаторами о текущем состоянии сети

■ Повторное вычисление для выбора наилучшего маршрута при каждом изменении в сети

Долгие годы проводились серьезные исследования протоколов маршрутизации. Многие из них были реализованы, а используемые в них метрики породили жаркие дебаты. Приведем характеристики наилучшего протокола:

■ Быстрая реакция на изменение в сети

■ Вычисление наилучшего маршрута

■ Хорошая масштабируемость при расширении сети

■ Бережное использование компьютерных ресурсов

■ Бережное использование сетевых ресурсов

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

Изучение протоколов маршрутизации начинается с наиболее простого из них — RIP.

8.9 Протокол RIP

 Сделать закладку на этом месте книги

Наиболее широко используемым протоколом IGP является RIP, заимствованный из протокола маршрутизации сетевой системы компании Xerox (Xerox Network System — XNS). Популярность RIP основана на его простоте и доступности.

RIP был первоначально реализован в TCP/IP операционной системы BSD и продолжает распространяться в операционных системах Unix как программа routed. 

Программа routed  стала стандартной частью многих хостов различных разработчиков и пакетов маршрутизации TCP/IP. RIP включен и в бесплатное программное обеспечение Корнельского университета, названное gated.  RIP получил широкое распространение еще за несколько лет до его стандартизации в документе RFC 1058. Вторая версия протокола была предложена в 1993 г. и улучшена в 1994 г. (после этого исходная версия получила маркировку "историческая", т.е. устаревшая).

RIP анализирует маршрут на основе простого вектора расстояния . Каждому попаданию присваивается вес (обычно 1). Общая метрика пути получается как сумма весов всех участков попадания. Выбор лучшего пути для следующего попадания производится по наименьшему значению метрики.

На рис. 8.3 показано распространение в сети процедуры оценки по вектору расстояния. Маршрутизатор из верхнего левого угла рисунка может определить, что датаграмма, направляемая через маршрутизатор А в сеть N, имеет меньше попаданий, чем направляемая в эту сеть через маршрутизатор B.



Рис. 8.3. Исследование количества попаданий до точки назначения

Для RIP наиболее важны простота и доступность. Часто нет особых причин использовать более совершенные (и более сложные) методы маршрутизации для малых сетей или сетей с простой топологией. Однако при применении в больших и сложных сетях у RIP проявляются серьезные недостатки. Например:

■ Максимальное значение метрики для любого пути равно 15. Шестнадцать означает "Точки назначения достичь нельзя!".  Поскольку в больших сетях можно быстро получить переполнение счетчика попаданий, обычно RIP конфигурируется со значением веса 1 для каждого из участков попадания независимо от того, является этот участок низкоскоростной коммутируемой линией или высокоскоростной волоконно-оптической связью. (Ограничение счетчика позволяет исключить зацикливание датаграмм по круговому маршруту. Другого метода для этого в RIP не существует. — Прим. пер .)

■ После нарушений в работе сети RIP очень медленно восстанавливает оптимальные маршруты. Реально после нарушения в сети трафик может даже зациклиться по круговому маршруту.

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

8.9.1 Инициализация RIP

 Сделать закладку на этом месте книги

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

Как показано на рис. 8.4, новости распространяются как сплетни — каждый маршрутизатор пересылает их своему ближайшему соседу. Например, маршрутизатор С очень быстро узнает, что он на расстоянии в два попадания от подсети 130.34.2.0.



Рис. 8.4. Распространение информации о маршрутизации

Как и все автоматизированные протоколы маршрутизации, RIP посылает информацию об изменениях маршрутов, получает такие сведения от других и пересчитывает пути. Маршрутизатор RIP отсылает информацию своим соседям-маршрутизаторам каждые 30 с. Отправка этих данных называется объявлением о маршруте (advertising route).

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

8.9.2 Обновление таблиц RIP

 Сделать закладку на этом месте книги

Как видно на рис. 8.5, маршрутизатор А пересылает трафик в сеть 136.10.0.0 через маршрутизатор B. А получил изменения от своего соседа D, который объявил о более коротком маршруте, и А изменил свою таблицу маршрутизации. Отметим, что количество попаданий от А до В добавляется к метрике от D для вычисления расстояния (2) от А до 136.10.0.0.



Рис. 8.5. Обновление таблиц маршрутизации в RIP

8.9.3 Механизм RIP версии 1

 Сделать закладку на этом месте книги

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

1. Присваивается вес для каждой подключенной и пересекаемой при пересылке датаграмм подсети (обычно 1).

2. Маршрутизатор посылает свою таблицу соседям каждые 30 с.

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

4. К локальной таблице маршрутизации добавляются новые точки назначения.

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

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

1. Маршрутизатор А пересылал трафик в точку назначения через маршрутизатор X, а X прислал изменения, указывающие на увеличение количества попаданий до точки назначения (или на невозможность достижения точки назначения по данному пути). Маршрутизатор А соответствующим образом изменит строку своей таблицы.

2. Маршрутизатор А пересылал трафик в точку назначения через маршрутизатор X, но не получил изменений от X в течение трех минут. А предполагает неисправность X и маркирует все пути через X как недостижимые (указав для метрики значение 16). Если за 2 мин для таких точек назначения не будет обнаружен новый маршрут, соответствующие строки удаляются (такой процесс образно называют "сборкой мусора" —  garbage collection). В то же время маршрутизатор А указывает своим соседям через посылаемые изменения, что маршрутизатор X не может обеспечить путь к точкам назначения.

8.9.4 Сообщения об изменениях в RIP версии 1

 Сделать закладку на этом месте книги

Как было сказано выше, между маршрутизаторами RIP периодически формируются сообщения об изменениях. Дополнительно можно послать к соседям сообщения с запросами информации о маршрутизации:

■ Во время инициализации

■ При выполнении операций сетевого мониторинга

Формат сообщений RIP версии 1 для запросов или ответов/изменений показан на рис. 8.6. Поле команд со значением 1 указывает на запрос, а идентификатор 2 определяет ответ или самопроизвольное сообщение об изменениях.



Рис. 8.6. Формат сообщений в RIP версии 1

8.9.5 Поля сообщения об изменениях в RIP версии 1

 Сделать закладку на этом месте книги

Когда создавалась исходная спецификация RFC для RIP, предполагалось, что сообщения о маршрутизации будут использоваться и другими протоколами, а не только IP. Поэтому в сообщении появилось поле идентификатора семейства адресов  (address family identifier) и место для адреса в 14 октетов.

Семейство адресов, IP-адрес и поле метрики могут повторяться, поэтому сообщение может содержать до 25 адресных элементов. Максимальная длина сообщения составляет 512 октетов. Если нужно переслать сведения о более чем 25 элементах, используется несколько сообщений.

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

Регулярные изменения RIP пересылаются через протокол UDP из порта источника 520 в порт 520 маршрутизатора назначения. Однако запросы могут посылаться из любого порта, на который и придет ответ на запрос.

8.9.6 Настройка RIP

 Сделать закладку на этом месте книги

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

■ При интервале между изменениями, равном 30 с, требуется много времени на распространение изменений по большой сети

■ После изменения, особенно при потере соединения, имеется тенденция к зацикливанию трафика по кольцу

Далее рассматриваются пути решения этих проблем.

8.9.7 Триггерные изменения и хранение

 Сделать закладку на этом месте книги

Триггерные изменения  (triggered updates) ускоряют процесс исследования изменений. Маршрутизатор, изменив метрику пути, посылает объявление о таком изменении.

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

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

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

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

8.9.8 Деление горизонта и опасный реверс

 Сделать закладку на этом месте книги

Почему иногда происходит зацикливание трафика в RIP? Причина в том, что после изменения проходит некоторое время, пока все маршрутизаторы не обновят информацию. На рис. 8.7 показан простой пример (он взят из RFC 1058). Маршрутизатор D имеет два пути к сети N . Один из них короткий (в одно попадание), а другой — длинный (в 10 попаданий). Если оборвется связь по короткому пути, маршрутизатор D заменит его на альтернативный (длинный) путь с метрикой 10.



Рис. 8.7. Маршрутизация после неисправности в сети

Однако в сообщениях RIP об изменении; посланных маршрутизаторам А, В и С, будут только следующие сведения:

Сеть N   Метрика = 2

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

■ D изменит строку своей таблицы на:

Назначение Следующее попадание Метрика
Сеть N А 3

■ D попытается переслать трафик к сети N  через А (последний отправит трафик обратно).

■ D отправит объявления об изменении своей таблицы на А, В и С (что он может достичь сети N  за три попадания).

■ Маршрутизаторы ответят, что они теперь смогут попасть в сеть N  за четыре попадания. Маршрутизаторы В и С столкнутся с неоднозначностью и, в зависимости от времени поступления изменений, могут пытаться отправлять свои трафики к сети N  друг через друга, через А или D.

■ Изменения RIP будут распространяться дальше и глубже.

Хорошо то, что метрики для сети N в А, В и С будут постоянно увеличиваться с приходом каждого нового изменения, пока не достигнут значения 11 и не будет определен правильный маршрут. Два простых механизма позволяют избежать путаницы в сети, которая может возникнуть во время устранения неисправности.

Деление горизонта  (split horizon) требует, чтобы маршрутизаторы не посылали своих объявлений о пути к системам со следующим попаданием по этому пути. В примере на рис. 8.7 маршрутизаторы А, В и С не будут указывать D, что могут достичь сети N,  поскольку путь к N проходит через сам маршрутизатор D.

Опасный реверс  (poisoned reverse) идет еще дальше. По этому алгоритму маршрутизаторы А, В и С (см. рис. 8.7) предотвращают распространение неверных сведений с помощью специального сообщения, означающего "Не пытайтесь передавать через меня!". Более точно — изменения будут включать элемент:

Сеть N   Метрика = 16

Это исключает проблемы в небольших сетях, но для сетей с большим диаметром колец зацикливания они остаются, даже когда реально нельзя достичь точки назначения. Метрики все равно когда-нибудь увеличатся до 16, и будет восстановлен правильный маршрут. Этот процесс называется подсчетом до бесконечности  (counting to infinity).

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

Несколько очевидных недостатков сообщений протокола RIP версии 1 мы рассмотрим в следующих разделах.

8.9.9 Нет маски подсети

 Сделать закладку на этом месте книги

В сообщения прокола RIP версии 1 не включаются маски (см. рис. 8.6), следовательно, нельзя определить, что представляет собой адрес: подсеть или хост.

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

Маршрутизаторы, не подключенные непосредственно к сети, не имели возможности определить маску подсети. Сведения о подсети удаленной сети были для них бесполезны. По этой причине маршрутизаторы RIP версии 1 не посылали сведений о подсетях и хостах на маршрутизаторы, которые не были подключены непосредственно к сети, содержащей эти подсети и хосты. Внешний маршрутизатор посылал единственный элемент для всей сети (например, 145.102.0.0).

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

8.9.10 Широковещательные рассылки в локальной сети

 Сделать закладку на этом месте книги

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

8.9.11 Отсутствие аутентификации

 Сделать закладку на этом месте книги

Еще одним неприятным свойством версии 1 является отсутствие аутентификации для сообщений RIP. Если некто получил доступ к сети и сформировал сообщение с заведомо ложной информацией (фальсифицировав адрес источника), то это может сделать недоступным большинство точек назначения и привести к серьезному нарушению работы сети.

8.9.12 Отсутствие распознавания медленных и быстрых связей

 Сделать закладку на этом месте книги

Сетевой администратор может вручную присвоить для связи значение счетчика попаданий. Следовательно, для связи "точка-точка" со скоростью 9,6 Кбайт/с можно установить значение счетчика 5, что укажет на ее меньшие возможности по сравнению со связью 10 Мбайт/с.

К сожалению, когда счетчик достигнет значения 15, точка назначения станет недоступной, а значит, администратору лучше использовать для всех связей одно и то же значение веса, равное 1.

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

8.9.13 Избыточный трафик

 Сделать закладку на этом месте книги

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

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

Новые протоколы маршрутизации решают такие проблемы с помощью посылки изменений только после их внесения и включают в сообщение только сведения о реально измененных путях. Периодически маршрутизаторы обмениваются сообщениями Hello! (Привет!), позволяющими выяснить работоспособность друг друга, за исключением коммутируемых связей, для которых всегда предполагается нормальное состояние у соседа, пока попытка реальной пересылки данных не завершится неудачей.

8.10 Протокол RIP версии 2

 Сделать закладку на этом месте книги

Хотя стандарт RFC 1058, в котором была определена версия 1, был опубликован еще в 1983 г., версия 2 протокола RIP появилась только в 1993 г. К этому времени была проведена большая работа по созданию более сложного протокола, способного решить проблемы старой версии. Однако многим организациям нравится простота в инсталляции и использовании RIP старой версии.

Версия 1 была декларирована "исторической", и пользователям нужно было перейти на версию 2. RIP версии 2 предлагает простые решения большинства проблем первой версии. Однако для совместимости с версией 1 изменения были ограничены. Максимальное значение счетчика попаданий осталось равным 15, а все содержимое таблицы маршрутизации по-прежнему обновляется каждые 30 с. Но для передачи изменений стали использоваться многоадресные , а не широковещательные рассылки.

Большинство доработок в версии 2 связано с размещением дополнительной информации в сообщении об изменениях. Формат сообщения версии 2 показан на рис. 8.8.



Рис. 8.8. Формат сообщения RIP версии 2

Маска подсети  (subnet mask) Помещена в сообщение
Следующее попадание  (next hop) Используется для отчета маршрутизатора через другие  маршрутизаторы. Например, "нужно идти к сети N  через маршрутизатор В". На рис. 8.9 показано, как один многопротокольный маршрутизатор проводит трансляцию между протоколами RIP и IGRP, а также пересылку информации о следующем попадании между двумя наборами маршрутизаторов.
Тег маршрута  (route tag) Это поле содержит информацию для внешнего протокола (например, для BGP). Наиболее популярно использование этого тега для указания номера автономной системы во внешней сети.


Рис. 8.9. Использование поля "Следующее попадание" в  отчете маршрутизатора

8.10.1 Аутентификация в RIP версии 2

 Сделать закладку на этом месте книги

Как один из вариантов, место для первого изменения может быть использовано для аутентификации. Оно указывается как поле аутентификации при значении X'FFFF в поле идентификатора семейства адресов. Используемый тип аутентификации описывается в следующем поле.

Оставшиеся 16 бит содержат саму информацию об аутентификации. Хотя для версии 2 определен только один тип аутентификации (с идентификатором 2), использующий простой пароль, разработчики маршрутизаторов понемногу переходят на аутентификацию MD5. На рис. 8.10 показан формат сообщения с аутентификационной информацией.



Рис. 8.10. Сообщение версии 2 RIP, начинающееся с аутентификации

8.11 Переход на более интеллектуальные протоколы

 Сделать закладку на этом месте книги

Для перехода на более интеллектуальные протоколы были сделаны два улучшения. Как и RIP, лицензированный протокол IGRP компании Cisco использует вектор расстояния, однако в нем устранены недостатки RIP. OSPF и IS-IS являются протоколами по состоянию связи. В них создаются карты сети и исследуются все маршруты к точке назначения, а затем полученные метрики путей сравниваются друг с другом.

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

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

8.12 Протоколы IGRP и EIGRP

 Сделать закладку на этом месте книги

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

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

Граничный маршрутизатор провайдера, использующий протоко


убрать рекламу







л IGRP, может собирать сведения от нескольких внешних автономных систем. Следовательно, в этом протоколе поддерживается маршрутизация между различными автономными системами.

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

В следующих разделах мы рассмотрим возможности IGRP и улучшения, вносимые EIGRP.

8.12.1 Маршрутизация в IGRP

 Сделать закладку на этом месте книги

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

Delay  Задержка Описывает (в десятках мкс) время на достижение точки назначения при отсутствии нагрузки в сети.
Bandwidth  Полоса пропускания Равна 10 000 000, деленным на наименьшую полосу пропускания по заданному маршруту (измеряется в Кбит/с). Например, наименьшая полоса пропускания в 10 Кбит/с соответствует метрике в 1 000 000 Кбит/с.
Load  Нагрузка Измеряется как доля полосы пропускания по заданному маршруту, используемая в текущий момент времени. Кодируется числами от 0 до 255 (255 соответствует нагрузке в 100%).
Reliability  Надежность Часть датаграмм, пришедшая без повреждения. Кодируется числами от 0 до 255 (255 соответствует 100-процентному отсутствию повреждений в датаграммах).
Hop count  Счетчик попаданий Определяет число попаданий до точек назначения.
Path MTU  MTU пути Наибольшее значение Maximum Transmission Unit (MTU) для датаграмм, которые можно переслать по любой связи общего пути.

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

В таблице 8.2 приведены метрики, возвращаемые протоколом Simple Network Management Protocol  (SNMP) из пула маршрутизаторов Cisco. Например:

IP-маршрут назначения Метрика IP-маршрута 1 Метрика IP-маршрута 2 Метрика IP-маршрута 3 Метрика IP-маршрута 4 Метрика IP-маршрута 5 Индекс ЕСЛИ IP-маршрута Возраст IP-маршрута (с)
128.6.0.0 12610 1536 61000 2 255 3 11
128.96.0.0 14647 1170 61000 2 255 6 16
128.112.0.0 10667 1170 21200 1 255 6 23

Для IGRP/EIGRP значения метрик имеют следующий смысл:

Метрика 1  Обобщенная метрика маршрута

Метрика 2  Метрика полосы пропускания

Метрика 3  Сумма задержек интерфейса

Метрика 4  Счетчик попаданий маршрута

Метрика 5  Надежность интерфейса (255 означает 100%)

Таблица 8.3 Измерение задержки и полосы пропускания в IGRP

Носитель Значение задержки по умолчанию (в десятках мкс) Метрика полосы пропускания (10 000 000 разделить на полосу пропускания в Кбит/с)
Спутниковая связь (500 Мбит) 200 000 (2 с) 20
Ethernet (10 Мбит) 100 (1 мс) 1 000
1.544 Мбит 2 000 (20 мс) 6 480
64 Кбит 2 000 156 250
56 Кбит 2 000 178 570
10 Кбит 2 000 1 000 000
1 Кбит 2 000 10 000 000

8.12.2 Другие конфигурируемые значения IGRP

 Сделать закладку на этом месте книги

Конфигурировать маршрутизаторы IGRP несложно. Кроме IP-адреса, маски подсети, MTU, полосы пропускания и задержки связи, можно специфицировать:

■ Фактор изменения (variance factor) V. Если M является наименьшей метрикой пути, используется путь с метрикой М×V.

■ Разрешить или запретить хранение (hold down).

■ Можно конфигурировать и таймеры, хотя чаще используют следующие значения по умолчанию:

■ Широковещательная рассылка изменений каждые 90 с.

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

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

■ Если в течение 540 с (время существования потока обновления — flush time), не приходит сведений об изменениях точки назначения, то удаляется соответствующая строка.

8.12.3 Механизм протокола IGRP

 Сделать закладку на этом месте книги

Как и в RIP, маршрутизатор IGRP периодически посылает своим соседям сведения об изменениях. К ним относится полное содержимое текущей таблицы маршрутизации со всеми метриками.

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

Метод расширения горизонтов служит для предотвращения объявления о пути тем маршрутизатором, который расположен ниже по цепочке следования на таком маршруте. Кроме того, IGRP предоставляет собственную версию метода опасного реверса. Если метрика маршрута увеличивается более чем в 1,1 раза, вероятно, будет сформировано зацикливание, и такой маршрут игнорируется.

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

■ По тайм-ауту коммуникации с ближайшим соседом — удаляется маршрут к этому соседу

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

■ Метрика увеличивается настолько существенно, что возможно возникновение опасного реверса

8.12.4 Внешняя маршрутизация

 Сделать закладку на этом месте книги

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

8.12.5 Возможности EIGRP

 Сделать закладку на этом месте книги

Улучшения в EIGRP основаны на тех же метриках и вычислении расстояния, что и обычные свойства этого протокола. Однако расширение свойств существенно улучшает возможности EIGRP за счет поддержки маски подсети и исключения периодических изменений. Пересылаются только реальные изменения, a EIGRP обеспечивает проверку их получения путем анализа обратного сообщения о подтверждении приема. Простые периодические сообщения Hello!  (Привет!) позволяют узнать об активности своих ближайших соседей. Еще одним важным усовершенствованием стало применение диффузионного алгоритма для изменений  (Diffusing Update Algorithm — DUAL), гарантирующего маршрутизацию без зацикливания.

8.12.6 DUAL в EIGRP

 Сделать закладку на этом месте книги

Основная идея DUAL проста и основана на следующем наблюдении:

Если путь постоянно приближает к точке назначения, то он не может сформировать зацикливание. 

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



Рис. 8.11. Маршрут с формированием зацикливания

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

8.12.7 Таблицы топологии в DUAL

 Сделать закладку на этом месте книги

Для реализации DUAL протокол EIGRP сохраняет информацию, которой не пользуется IGRP. EIGRP хранит информацию о маршрутах для каждого соседнего маршрутизатора, извлекая ее из сообщений об изменениях от этих маршрутизаторов (IGRP игнорирует любую информацию о неоптимальных маршрутах). Эта информация хранится в дополнительной таблице топологии  (topology table), содержащей следующие сведения:

Точка назначения Ближайший сосед Метрика ближайшего соседа Собственная текущая метрика

8.12.8 Пригодный преемник в DUAL

 Сделать закладку на этом месте книги

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

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

Рассмотрим этот процесс с более формальной точки зрения:

1. Предположим, что я могу достичь точки, где будет только один пригодный преемник на пути к точке назначения, через маршрутизатор Z.

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

3. Я перехожу в активное  (active) состояние и начинаю процесс пересчета маршрута  (route recomputation).

4. Во время пересчета я продолжаю маршрутизировать данные через Z.

5. Я посылаю сообщение об изменениях (называемое query — запрос) всем ближайшим соседям, за исключением Z. В сообщении объявляется о моей новой, большей метрике расстояния до точки назначения.

6. Если сосед имеет один или более пригодных маршрутов, он посылает ответ и объявляет собственный верный путь к точке назначения.

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

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

9. Когда маршрутизатор определяет для себя пригодный путь или недоступность точки назначения, он отсылает обратно ответ на полученный им запрос.

10. Когда придут ответы на все собственные запросы (не вторичные от других маршрутизаторов. — Прим. пер. ), маршрутизатор переходит в пассивное состояние.

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

8.13 Протокол OSPF

 Сделать закладку на этом месте книги

В 1988 г. комитет IETF начал работу над стандартом нового протокола для замены RIP. В результате была создана спецификация одного из протоколов IGP, призванная сначала открывать самый короткий путь  (Open Shortest Path First — OSPF). OSPF был разработан как протокол маршрутизации для использования внутри всех автономных систем любых сайтов. В 1990 г. OSPF был рекомендован в качестве стандарта. Это нелицензированный протокол для общедоступного использования.

Вспомним, что протоколы по состоянию связи исследуют пути посредством построения карты сети для формирования дерева пути, корнем которого является маршрутизатор. Метрики вычисляются для каждого пути, а затем оптимальный путь (пути) определяется для каждого типа обслуживания IP (Type Of Service — TOS).

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

■ Быстрое определение изменений в топологии и очень эффективное восстановление маршрутов без зацикливания

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

■ Разделение трафика между несколькими эквивалентными путями

■ Маршрутизация на основе типа обслуживания

■ Использование в локальных сетях многоадресных рассылок

■ Маски для подсетей и суперсетей

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

В апреле 1990 г., когда очень большая сеть NASA Science (Космического агентства США — Прим. пер .) была переведена на протокол OSPF, обнаружилось существенное снижение трафика в этой сети. После изменения или нарушения в работе сети глобальная корректировка информации о маршрутизации стала выполняться необычайно быстро — в пределах нескольких секунд (по сравнению с минутами для некоторых старых протоколов).

В середине 1991 г. была опубликована вторая версия OSPF, а в марте 1994 г. появилась доработанная вторая версия. Последний вариант описывается в 216-страничном документе, поэтому приведенные ниже сведения можно рассматривать только как общее описание этого протокола.

8.13.1 Автономные системы, области и сети

 Сделать закладку на этом месте книги

В стандарте OSPF термин "сеть"  (network) означает сеть IP, подсеть или суперсеть CIDR. Точно так же маска сети  (network mask) определяет сеть, подсеть или суперсеть CIDR. Область  (area) рассматривается как набор непрерывных сетей или хостов вместе со всеми маршрутизаторами, имеющими интерфейсы в этих сетях.

Автономная система, использующая OSPF, создается из одной или нескольких областей. Каждой области присвоен номер. Область 0 представляет собой магистраль  (backbone), которая соединяет все другие области и объединяет вместе автономные системы. Рассматриваемую топологию иллюстрирует рис. 8.12.



Рис. 8.12. Области и магистрали OSPF

8.13.2 Маршрутизация в области OSPF

 Сделать закладку на этом месте книги

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

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

Как только происходит изменение (например, обрыв связи), информация об этом распространяется по всей сети. Именно этим обеспечивается точность маршрутизации и быстрая реакция на неисправность. Например, если для показанной на рис. 8.13 структуры используется OSPF, то маршрутизатор A будет быстро информирован об обрыве связи с маршрутизатором В и узнает о невозможности доступа к сети N .



Рис. 8.13. Использование полной информации о маршрутизации

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

8.13.3 Кратчайшие пути для области OSPF

 Сделать закладку на этом месте книги

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

8.13.4 Магистрали, грани и границы OSPF

 Сделать закладку на этом месте книги

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

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

На рис. 8.14 магистраль (область 0) включает маршрутизаторы А, В, С, F и G. К области 1 относятся маршрутизаторы В и D. Область 2 содержит маршрутизаторы С, E и F. Маршрутизаторы В, С и F являются маршрутизаторами грани, a G — маршрутизатором границы. Маршрутизатор В знает все о топологии области 1 и магистрали. Аналогично маршрутизаторы С и F имеют сведения об области 2 и магистрали.



Рис. 8.14. Маршрутизаторы и области в автономных системах

Магистраль должна быть непрерывной. Что произойдет при разрыве магистрали из-за расформирования сети или неисправности оборудования? Иногда для объединения отдельных элементов в магистраль используют виртуальные связи .

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

Как показано на рис. 8.15, когда потеряна связь между А и F, маршрутизатор F не будет более соединен с другим маршрутизатором посредством магистральной связи. Для восстановления целостности магистрали придется воспользоваться виртуальной связью F-E-C.



Рис. 8.15. Определение виртуальной связи

8.13.5 Маршрутизация через грань области OSPF

 Сделать закладку на этом месте книги

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

8.13.6 Использование итоговой информации внутри области OSPF

 Сделать закладку на этом месте книги

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

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

Например, на рис. 8.16 маршрутизатору E нужно выбрать путь к сети M . Маршрутизатор E использует базу данных своей области для поиска расстояния dc и df до маршрутизаторов граней С и F. Каждый из них сообщает сведения о своем расстоянии mc и mf до сети M . Маршрутизатор E может сравнить dc+ mc и df+mf и выбрать кратчайший маршрут.



Рис 8.16. Маршрутизация между областями

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

8.13.7 Точка назначения вне автономной области OSPF

 Сделать закладку на этом месте книги

Многие автономные системы соединены с Интернетом или другими автономными системами. Маршрутизаторы границ (boundary, не путать с гранями. — Прим. пер .) предоставляют информацию о расстоянии до сети, расположенной вне автономной системы.

В OSPF существует два типа метрик для внешнего расстояния. Тип 1 эквивалентен метрике состояния локальной связи. Метрика типа 2 служит для длинных расстояний — она измеряет величины в большом диапазоне. Используя аналогию, можно уподобить метрику типа 2 километражу по общенациональной карте автодорог, на которой расстояния измеряются в сотнях км, а метрику типа 1 — километражу по карте отдельной области, где расстояния измеряются в км.

На рис. 8.17 показаны два маршрута к внешней сети N.  На таком расстоянии игнорируется метрика типа 1, а вычисления производятся по метрике типа 2 (будет выбран маршрут со значением этой метрики, равным 2).



Рис. 8.17. Выбор маршрута по метрике типа 2

Еще одной возможностью OSPF (специально предназначенной для провайдеров) является возможность маршрутизатора границы автономной системы работать в качестве сервера маршрутизации  (route server) и предоставлять сведения, идентифицирующие другие маршрутизаторы границ. Такие сведения должны включать:

Точку назначения, Метрику, Используемый маршрутизатор границы 

8.13.8 Протокол OSPF

 Сделать закладку на этом месте книги

Теперь мы готовы описать некоторые внутренние свойства протокола OSPF. Каждый маршрутизатор OSPF обслуживает подробную базу данных с информацией для создания дерева маршрутизации области. Например, в базе данных отражены:

■ Каждый интерфейс маршрутизатора, соединения и связанные с ними метрики

■ Каждая сеть с множественным доступом и список всех маршрутизаторов такой сети

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

8.13.9 Сообщения Hello

 
убрать рекламу







'1211988644'); return false;>Сделать закладку на этом месте книги

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

Маршрутизатор периодически отправляет в многоадресной рассылке сообщение Hello! (Привет!) в сети с множественным доступом (например, локальные сети Ethernet, Token-Ring или FDDI), чтобы другие маршрутизаторы смогли узнать о его активности. Это же сообщение посылается на другие концы подключенных линий "точка-точка" или виртуальных цепей, чтобы партнеры по этим связям смогли узнать о рабочем состоянии маршрутизатора.

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

8.13.10 Назначенный маршрутизатор

 Сделать закладку на этом месте книги

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

■ Несет ответственность за надежность изменений в базах данных своих смежных соседей в соответствии с последними изменениями в топологии

■ Служит источником объявления о сетевых связях  (network link advertisement), в которых перечисляются все маршрутизаторы, подключенные к сети с множественным доступом

На рис. 8.18 назначенный маршрутизатор А обменивается сведениями с маршрутизаторами В, С и D своей сети, а также с маршрутизатором E, подключенным по связи "точка-точка".



Рис. 8.18. Назначенный маршрутизатор обновляет сведения о сети у своих соседей

8.13.11 Смежность маршрутизаторов

 Сделать закладку на этом месте книги

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

Маршрутизаторы В, С и D синхронизируют содержимое своих баз данных с маршрутизатором А. Они не обмениваются этими сведениями друг с другом. Два маршрутизатора, которые синхронизируют свои базы данных, называются смежными  (adjacent). Маршрутизаторы В и С являются соседями,  но не являются смежными.

Ясно, что назначенный маршрутизатор обеспечивает эффективный метод согласования содержимого баз данных маршрутизаторов локальной сети. Этот же способ применяется в сетях Frame Relay и X.25. Маршрутизаторы могут обмениваться сообщениями Hello по виртуальным цепям, выбирать назначенный маршрутизатор и синхронизовать с ним свои базы данных. Все это позволяет ускорить процесс синхронизации сведений о сети и снизить сетевой трафик.

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

8.13.12 Инициализация базы данных маршрутизации

 Сделать закладку на этом месте книги

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

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

После завершения обмена каждый маршрутизатор будет знать:

■ Какой элемент еще не находится в локальной базе данных

■ Какой элемент имеется, но не содержит информации

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

8.13.13 Типы сообщений в OSPF

 Сделать закладку на этом месте книги

Протокол OSPF использует сообщения пяти типов:

Hello  "Привет!" Используется для идентификации соседей, выбора и поиска в сети назначенного маршрутизатора, а также в качестве сигнала "Я присутствую в сети!".
Database Description  Описание базы данных Используется во время инициализации для обмена информацией, чтобы маршрутизатор мог найти сведения, отсутствующие в его базе данных.
Link State Request  Запрос состояния связи Служит для запроса данных, которых маршрутизатор не обнаружил в своей базе данных, либо когда его данные уже устарели.
Link State Update  Изменение состояния связи Применяется в ответ на Link State Request и для динамического обмена сведениями о сетевой топологии.
Link State ACK  Подтверждение состояния связи Используется для подтверждения приема Link State Update. Отправитель повторно отсылает данные, пока не получит это сообщение.

8.13.14 Сообщения OSPF

 Сделать закладку на этом месте книги

Сообщения OSPF пересылаются непосредственно в датаграммах IP с типом протокола, равным 89.

Все сообщения OSPF начинаются 24-октетным заголовком (см. рис. 8.19). Номер текущей версии равен 2. Поле типа  содержит номер соответствующего типа сообщения. Длина определяет общую длину сообщения, включая заголовок.



Рис. 8.19. Стандартный 24-октетный заголовок сообщения OSPF

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

8.13.15 Содержание сообщения Link State Update протокола OSPF

 Сделать закладку на этом месте книги

В сообщениях Link State Update пересылается критическая для протокола OSPF информация. Изменения передаются между смежными маршрутизаторами. Назначенный маршрутизатор, получая сообщение об изменениях в сети с широковещательными рассылками, передает их в многоадресных рассылках другим маршрутизаторам этой сети. Изменения распространяются по области необычайно быстро. Прием каждого объявления о новом состоянии связи должен быть подтвержден.

Сообщения Link State Update содержат элементы, называемые объявлениями  (advertisement). Каждое сообщение может включать следующие типы объявлений:

Router Links  Связи маршрутизатора Состояние каждого из интерфейсов маршрутизатора.
Network Links  Сетевые связи Список маршрутизаторов, подключенных к сети с множественным доступом. Предоставляется назначенным маршрутизатором этой сети.
Summary Link to a Network  Список связей с сетью Маршруты к сети вне локальной области, но внутри автономной системы. Предоставляются маршрутизатором грани.
Summary Link to a Boundary Router  Список связей с маршрутизатором границы Маршруты через автономную систему к ее границе. Предоставляются маршрутизатором грани.
AS External Link  Внешние связи автономной системы Маршруты к точкам назначения в других автономных системах. Предоставляются маршрутизатором границы.

Сообщение Link State Update начинается стандартным 24-октетным заголовком. Оставшаяся часть сообщения содержит объявления о различных типах связей (перечислены выше).

8.13.16 Улучшения в OSPF

 Сделать закладку на этом месте книги

Протокол OSPF был значительно улучшен. Например, для снижения стоимости выгодно отключать коммутируемые линии и виртуальные цепи, когда по ним не пересылается трафик. Теперь в протоколе для таких линий формируются периодические сообщения Hello, что позволяет отключать линии, не участвующие в работе. Кроме того, OSPF доработан для поддержки многоадресных рассылок IP. В настоящее время OSPF активно используется, и можно ожидать дальнейших улучшений и пересмотров требований.

8.14 Маршрутизация в OSI

 Сделать закладку на этом месте книги

В OSI вместо маршрутизаторов или шлюзов используются промежуточные системы  (intermediate system). Протокол маршрутизации OSI (IS-IS) был первоначально разработан для OSI, но позднее расширен на IP.

Как и OSPF, IS-IS является протоколом по состоянию связи и поддерживает иерархическую маршрутизацию, типы обслуживания (TOS), разделение трафика по нескольким путям и аутентификацию.

В IS-IS определены маршрутизаторы двух типов: уровня 1 для маршрутизации внутри области и уровня 2 для точек назначения вне области (последние можно рассматривать как аналоги магистральных маршрутизаторов OSPF). Маршрутизатор уровня 1 для промежуточных систем пересылает трафик, направленный вне границ области, на ближайший маршрутизатор уровня 2. Трафик маршрутизируется далее на маршрутизатор уровня 2 области назначения.

Многие механизмы OSPF основаны на подобных (но не идентичных) механизмах IS-IS, например объявления о состоянии связи, поток сообщений и последовательные номера.

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

8.15 Протоколы EGP

 Сделать закладку на этом месте книги

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

8.16 EGP

 Сделать закладку на этом месте книги

Многие годы в Интернете широко использовался простой протокол внешнего шлюза (Exterior Gateway Protocol — EGP) для обеспечения автономных систем маршрутизацией информации во внешнюю сеть. Он характеризуется очень простой структурой. Маршрутизаторы EGP соседних автономных систем обмениваются сведениями о достижимых через них сетях.

EGP был разработан еще в начале 80-х годов, когда Интернет имел очень простую топологию, состоящую из магистрали и набора сетей, непосредственно подключенных к этой магистрали. Когда Интернет достиг современного размера и стал представлять собой топологию в виде сети сетей, EGP используется для пересылки сведений о доступе через цепочки автономных систем (см. рис. 8.20).



Рис. 8.20. Простое сообщение EGP в сложной сети

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

8.16.1 Модель EGP

 Сделать закладку на этом месте книги

Маршрутизатор EGP конфигурируется с адресом IP для одного или нескольких внешних соседних маршрутизаторов. Обычно внешние соседи соединены с общей сетью с множественным доступом или объединены одной линией "точка-точка".

EGP позволяет маршрутизатору определить, какие из сетей доступны через его внешнего соседа. В EGP используются следующие понятия:

Neighbor Acquisition  Обнаружение ближайшего соседа Маршрутизатор посылает запрос Neighbor Acquisition Request. Получатель запроса возвращает ответ Neighbor Acquisition Response и собственное сообщение Neighbor Acquisition Request.
Neighbor Release  Освобождение соседа Для прекращения связи с соседом маршрутизатор посылает сообщение Neighbor Cease (прекратить связь с соседом), на что получатель отвечает собственным сообщением Neighbor Cease.
Neighbor Reachability  Достижимость соседа Отношения между обнаруженными соседями поддерживаются за счет периодического обмена сообщениями Hello (Привет!) и I Heard You (Я получил ваше сообщение).
Network Reachability  Достижимость сети Маршрутизатор посылает блок своих запросов внешнему соседу, запрашивая информацию о достижимости сетей. Сосед отвечает сообщениями Network Reachability.

Содержание сообщений Network Reachability требует несколько большего обсуждения. Если внешний сосед соединен с линией "точка-точка", то сообщение должно идентифицировать сети, которых можно достичь через отправителя сообщения. Обеспечиваются сведения о счетчике попаданий для каждой точки назначения. На рис. 8.21 показана такая конфигурация — маршрутизатор А отчитывается о достижимости сетей перед маршрутизатором X.



Рис. 8.21. Сообщения Network Reachability

Как показано на рис. 8.22, иногда несколько маршрутизаторов различных автономных систем совместно используют сеть с множественным доступом. В этом случае маршрутизатор А по протоколу EGP будет информировать маршрутизатор X о достижимых через А, В и С сетях, предоставляя для каждой из них значения счетчика попаданий. Точно так же EGP-маршрутизатор X будет информировать маршрутизатор А о сетях, достижимых через X, Y и Z.



Рис. 8.22. Эффективный обмен информацией EGP

Маршрутизаторы А и X являются прямыми  соседями (direct neighbor), а В и С — косвенными  (indirect) для маршрутизатора X.

Если откажет маршрутизатор А, то X должен попытаться использовать одного из своих косвенных соседей (В или С) как прямого соседа для протокола EGP.

Сообщения EGP пересылаются непосредственно в датаграммах IP, имеющих в поле протокола значение 8.

8.17 Протокол BGP

 Сделать закладку на этом месте книги

В Интернете широко используется протокол граничного шлюза (Border Gateway Protocol — BGP). Текущей версией протокола является BGP-4.

В современном Интернете существует множество провайдеров, объединенных между собой на манер сети межсоединений. При движении к точке своего назначения трафик часто пересекает сети различных провайдеров. Например, показанный ниже путь начинается в JVNC, пересекает MCI, SPRINT и маршрутизатор NYSERNET, а затем достигает точки своего назначения.

> traceroute nyu.edu

traceroute to CMCL2.NYU.EDU       (123.122.128.2), 30 hops max, 40 byte packets

1 nomad-gateway.jvnc.net          (128.121.50.5C)   3 ms  3 ms  2 ms

2 liberty-gateway.jvnc.net        (130.94.40.250)  49 ms 10 ms 21 ms

3 border2-hssi2-0.NewYork.mci.net (204.70.45.9)    13 ms 12 ms 19 ms

4 sprint-nap.NewYork.mci.net      (204.70.45.6)    33 ms 25 ms 19 ms

5 sl-pen-2-F4/0.sprintlink.net    (192.157.69.9)   24 ms 21 ms 21 ms

6 ny-nyc-2-H1/0-T3.nysernet.net   (144.228.62.6)   31 ms 29 ms 24 ms

7 ny-nyc-3-F0/p.nysernet.net      (169.130.10.3)   31 ms 23 ms 20 ms

8 ny-nyu-1-h1/0-T3.nysernet.net   (169.130.13.18)  21 ms 34 ms 19 ms

9 NYU.EDU                         (128.122.128.2)  19 ms 22 ms 21 ms

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

Например (см. рис. 8.23), система BGP в автономной системе 34 сообщает автономной системе (АС) 205, что сети M к N  находятся в этой АС. АС 205 отчитывается о пути к M и N  через себя и  через АС 34. Затем АС 654 указывает на путь к M к N  через себя и  АС 205 и  34. В этом процессе происходит увеличение длины маршрута, но для каждой следующей системы в отчете приводится описание полного пути. Таким образом, информация о доступности в BGP включает полную цепочку автономных систему которые пересекаются по пути следования к точке назначения.



Рис. 8.23. Цепочка BGP из автономных систем

Путь приводится в том порядке, в котором будут пересекаться автономные системы по пути следования к точке назначения:

654, 205, 34 

Когда эти сведения будет передавать АС 117, она добавит себя в начало:

117, 654, 205, 34 

Отметим, насколько просто выявляются и устраняются кольца зацикливания. Когда АС получает объявление, в котором видит собственный идентификатор, она просто игнорирует такое объявление.

Кроме отчета о маршруте к отдельной сети, BGP способен распознать объединенный набор сетей, используя для этого префикс CIDR.

8.17.1 Объединение маршрутов в BGP

 Сделать закладку на этом месте книги

Маршрут  в Интернете состоит из сети назначения и инструкций по ее достижению. Наблюдается огромное увеличение числа маршрутов вследствие увеличения числа сетей.

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

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

Это несложно сделать для входящего трафика, но приходится выполнять обратные действия, когда провайдеру требуется обрабатывать выходящий трафик на основе внешних объявлений. Клиентская автономная система будет информировать провайдера о маршруте к своей внутренней сети. Далее провайдер объединит  (aggregate) маршруты с общим префиксом в единый элемент описания маршрута, перед тем как об этом маршруте будет объявлено во внешнем мире.

8.17.2 Механизмы BGP

 Сделать закладку на этом месте книги

Системы BGP открывают соединение TCP с общеизвестным (well-known) портом 179 соседа по BGP. Каждое сообщение об открытии определяет автономную систему отправителя и имеет идентификатор BGP, а также может содержать дополнительные сведения.

После открытия соединения равные между собой соседи обмениваются информацией о маршрутах. Соединение остается открытым и используется при необходимости для пересылки сведений об изменениях. Для проверки продолжения контакта системы периодически (обычно каждые 30 с) обмениваются сообщениями Keep-alive (продолжаю работать).

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

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

8.17.3 Содержание сообщения об изменениях в BGP

 Сделать закладку на этом месте книги

Сообщение об изменениях в BGP может содержать сведения только об одном пригодном маршруте. Однако в нем может присутствовать список из одного или нескольких изолированных  (withdrawn) маршрутов, которые не следует более использовать.

Описание маршрута состоит из нескольких атрибутов маршрута,  которые включают:

Origin of Path Information  Источник информации о пути: IGP исходной автономной системы, EGP или иной источник сведений.
AS Path  Путь к автономной системе Маршрут, по которому поступило сообщение об изменениях.
Next Hop  Следующее попадание IP-адрес граничного маршрутизатора, который нужно применять для следующего попадания на пути к точке назначения. Это может быть локальный маршрутизатор автономной системы или внешний маршрутизатор, который напрямую подключен к отправителю и получателю сообщения об изменениях.
Multi-exit Discriminator  Многовыходной дискриминатор Если существует несколько точек выхода для соединения с соседней автономной системой, сосед может присвоить им номера, чтобы указать, какой выход будет лучшим. Меньший  номер определяет лучший маршрут.
Local Preference  Локальное предпочтение Чистая внешняя информация используется для пересылки изменений BGP элементам локальной автономной системы. Когда есть несколько BGP-маршрутизаторов на пути к точке назначения, более предпочтительный из них имеет больший  номер.
Atomic Aggregate  Атомарное объединение Указывает, что автономная система объединила несколько точек назначения в единый маршрут.
Aggregator  Объединитель IP-адрес и номер автономной системы для последней из систем, которые объединяли несколько маршрутов в один.
Reachable Nets  Достижимые сети Список префиксов сетей, которых можно достичь через данный маршрутизатор.

8.17.4 Проблема выбора варианта

 Сделать закладку на этом месте книги

Рис. 8.24 показывает различия между Multi-exit Discriminator и Local Preference. Системы в АС 117 хотят достичь сети N  автономной системы (АС) 433. АС 654 имеет два маршрута к точке назначения, и она объявила, что лучший из них — через маршрутизатор E. Однако АС 117 имеет внутренне назначенное локальное предпочтение для доступа к сети N  через АС 119.



Рис. 8.24. Предпочтительные маршруты

8.17.5 Применение объединения маршрутов

 Сделать закладку на этом месте книги

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

Как показано на рис. 8.25, маршрутизаторы BGP в автономных системах 650, 651 и 652 могут отчитаться о своих маршрутах, однако провайдер автономной системы 117 объединил их в один маршрут (элемент таблицы маршрутизации). Этот факт отражается атрибутом Atomic Aggregate .



Рис. 8.25. Объеди


убрать рекламу







нение маршрутов

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

8.17.6 Изолированные маршруты BGP

 Сделать закладку на этом месте книги

Маршрут исключается, если:

■ Он присутствует в списке изолированных маршрутов из сообщения об изменениях.

■ В изменениях приведен заменяющий маршрут.

■ Система BGP завершает такое соединение. Все маршруты через эту систему становятся недействительными.

8.18 Дополнительная литература

 Сделать закладку на этом месте книги

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

RIP:

RFC 1058 Routing Information Protocol  (протокол информации о маршрутизации)

RFC 1723 RIP Version 2 Carrying Additional Information  (RIP, версия 2: перенос дополнительной информации)

RFC 1582 Extensions to RIP to Support Demand Circuits  (расширение RIP для поддержки цепей по требованию)

OSPF:

RFC 1583 OSPF Version 2  (OSPF, версия 2)

RFC 1793 Extending OSPF to Support Demand Circuits  (расширение OSPF для поддержки цепей по требованию)

RFC 1586 Guidelines for Running OSPF Over Frame Relay Networks  (рекомендации по работе с OSPF через сети Frame Relay)

RFC 1584 Multicast Extensions to OSPF  (расширение OSPF для многоадресных рассылок)

RFC 1403 BGP OSPF Interaction  (взаимодействие BGP и OSPF)

BGP

(в будущем предполагается вытеснение BGP протоколом IDRP для OSI — Inter-Domain Routing Protocol, протокол междоменной маршрутизации):

RFC 1771 A Border Gateway Protocol 4 (BGP-4)  (протокол граничного шлюза, версия 4)

RFC 1773 Experience with the BGP-4 Protocol  (исследование протокола BGP-4)

RFC 1772 Application of the Border Gateway Protocol in the Internet (Приложения для BGP в Интернете)

Кроме того, можно обратиться к интерактивной документации компании Cisco по адресу www.cisco.com  для получения технических данных о протоколах IGRP и EIGRP.

Глава 9

Протокол UDP

 Сделать закладку на этом месте книги

9.1 Введение

 Сделать закладку на этом месте книги

После знакомства с физическим перемещением битов в носителе и маршрутизацией датаграмм в Интернете, настало время рассмотреть службы для приложений, связанные с пересылкой данных. Начнем с протокола пользовательских датаграмм  (User Datagram Protocol — UDP). Это достаточно простой протокол, позволяющий приложениям обмениваться отдельными сообщениями.

Для каких целей используются эти службы? Существует множество приложений, построенных совершенно естественным способом поверх UDP. Так можно, например, реализовать простую систему просмотра базы данных. Кроме того, мы уже упоминали о системе DNS , сформированной на основе UDP (см. рис. 9.1).



Рис. 9.1. Вопрос и ответ DNS

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

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

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

9.1.1 Широковещательные и многоадресные рассылки

 Сделать закладку на этом месте книги

Одним из преимуществ UDP является использование этого протокола для широковещательных и многоадресных рассылок из приложений. Например, широковещательная рассылка клиента BOOTP запрашивает инициализационные параметры.

9.2 Порты приложений

 Сделать закладку на этом месте книги

Что происходит после прибытия данных в хост назначения? Как выполняется их доставка в нужное приложение (процесс)?

На рис. 9.2 видно, что для каждого уровня существует идентификатор протокола, указывающий операции, выполняемые над данными. На втором уровне тип Ethernet X'08-00 в заголовке кадра показывает, что кадр нужно передать в IP. На третьем уровне поле протокола  в заголовке IP указывает протокол четвертого уровня, куда нужно переслать данные (например, 6 для TCP или 17 для UDP).



Рис. 9.2. Пересылка данных до уровня приложений

Хост может участвовать одновременно в нескольких коммуникациях. Так как же из общего потока выделяется датаграмма UDP и доставляется на нужный уровень приложения? Такой процесс пересылки данных в требуемый процесс часто называют демультиплексированием.  Ответ состоит в том, что каждой конечной коммуникационной точке UDP присвоен 16-разрядный идентификатор, называемый номером порта.  Термин "порт"  не очень удачен для данного идентификатора. Порт для клиентской и серверной частей приложения не имеет никакого отношения  к портам оборудования и физическому пути пересылки данных).

Порты с номерами от 0 до 1023 зарезервированы для стандартных служб. Такие порты называются общеизвестными  (well-known). Их использование позволяет клиенту идентифицировать службу, к которой он хочет получить доступ. Например, доступ к DNS (которая основана на UDP) производится через общеизвестный порт 53.

Кто назначает общеизвестные порты? Как не трудно догадаться, этим занимается IANA. Номера портов для определенных приложений регистрируются этой организацией и публикуются в документе RFC Assigned Numbers  (присвоенные номера). Сокращенный список портов UDP из текущего документа RFC Assigned Numbers  показан в таблице 9.1.


Таблица 9.1 Примеры общеизвестных портов UDP

Служба Порт/протокол Описание
Echo 7/udp Посылка отправителю эхо-ответа на пользовательскую датаграмму
Discard 9/udp Отмена пользовательской датаграммы
Daytime 13/udp Отчет о времени дня в понятном формате
Quote 17/udp Возврат сообщения quote of the day — цитата дня
Chargen 19/udp Генератор символов
Nameserver 53/udp Сервер имен доменов
Bootps 67/udp Порт сервера для загрузки конфигурационной информации
Bootpc 68/udp Порт клиента для получения конфигурационной информации
TFTP 69/udp Порт протокола Trivial File Transfer Protocol
SunRPC 111/udp Вызов удаленных процедур (Remote Procedure Call) компании Sun
NTP 123/udp Протокол Network Time Protocol
SNMP 161/udp Используется для получения сетевых запросов обслуживания
SNMP-trap 162/udp Служит для получения отчетов о проблемах в сети

Несколько общеизвестных служб обеспечивает модули для тестирования, отладки и измерений. Например, echo  (эхо) с портом 7, соответствуя своему имени, возвращает любую посланную на этот порт датаграмму. Служба Discard  (отмена) порта 9, наоборот, удаляет из сети любую посланную на этот порт датаграмму. Character generator  (генератор символов) отвечает на любое сообщение датаграммой, содержащей от 0 до 512 байт. Количество байт выбирается случайным образом.

Служба quote of the day  (цитата дня) отвечает на любую датаграмму определенным сообщением, например, в некоторых системах программа fortune  выводит при регистрации "мудрые" советы (в данном примере приведена фраза Уинстона Черчилля: "Человек может случайно споткнуться об истину, но в большинстве случаев не замечает ее и сосредоточенно продолжает дальнейший поиск".):

> fortune

Churchill's Commentary on Man:

 Man will occasionally stumble over the truth, but most of the

 time he will pick himself up and continue on.

Служба daytime  (время дня) отвечает на любые датаграммы сообщением, содержащим текущую дату и время в формате ASCII. Такой формат можно прочитать на экране без дополнительных преобразований. Иначе ведет себя служба Network Time Protocol  (NTP), обеспечивающая надежный метод синхронизации компьютеров сети.

Сервер BOOTP и клиент этой службы используются для неконфигурируемых устройств. Рабочая станция может получить для себя IP-адрес, свою маску адреса, узнать местоположение маршрутизатора по умолчанию, адреса наиболее важных серверов сети и, при необходимости, имя и местоположение на сервере boot загружаемого программного файла конфигурации. Программное обеспечение в рабочую станцию поступает через протокол Trivial File Transfer Protocol  (см. главу 14).

Мы уже знаем, что сервер имен  доступен через порт 53 и команду nslookup . Порты 161 и 162 используются протоколом Simple Network Management Protocol .

Кроме официально назначенных номеров, любая система с TCP/IP может резервировать диапазон номеров для важных сетевых служб и приложений.

Оставшиеся номера портов (выше 1023) предоставляются клиентам от программного обеспечения хоста по мере необходимости. Выделение предусматривает следующие шаги:

1. Пользователь запускает клиентскую программу (например, nslookup ).

2. Клиентский процесс исполняет системную подпрограмму, имеющую смысл: "Я хочу выполнить коммуникацию UDP. Предоставьте мне порт".

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

Можно видеть, что TCP также идентифицирует источник и назначение своим 16-разрядным идентификатором порта. Например, порт 21 применяется для доступа к службе пересылки файлов , а порт 23 — для службы регистрации telnet .

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

9.3 Адреса socket

 Сделать закладку на этом месте книги

Используемая для коммуникации комбинация IP-адреса и порта называется адресом socket  (дословно — гнездо, разъем). Отметим, что адрес socket обеспечивает для сервера или клиента всю информацию, необходимую для идентификации партнера по коммуникации.

Заголовок IP содержит IP-адреса источника и назначения. Заголовки UDP и TCP содержат номера портов источника и назначения. Следовательно, каждое сообщение UDP или TCP несет в себе адрес socket для источника и назначения.

Ниже приведен результат выполнения команды netstat -па , выводящей локальные и удаленные адреса socket для текущих активных коммуникаций с системой tigger . Адреса socket записаны в форме IP-адрес.номер_порта .

> netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q Local Address       Foreign Address     (state)

Tcp      0      0   127.0.0.1.1340      127.0.0.1.111       TIME_WAIT

Tcp      0      0   128.121.50.145.25   128.252.223.5.1526  SYN_RCVD

Tcp      0      0   128.121.50.145.25   148.7.9.160.65.3368 ESTABLISHED

Tcp      0    438   128.121.50.145.23   130.132.57.246.2219 ESTABLISHED

Tcp      0      0   128.121.50.145.25   192.5.5.1.4022      TIME_WAIT

Tcp      0      0   128.121.50.145.25   141.218.1.100.3968  TIME_WAIT

Tcp      0      0   128.121.50.145.25   35.8.2.2.3722       TIME_WAIT

Tcp      0      0   128.121.50.145.1338 165.247.48.4.25     ESTABLISHED

Tcp      0      0   128.121.50.145.25   128.173.4.8.3626    ESTABLISHED

Tcp      0      0   128.121.50.145.25   192.48.96.14.3270   ESTABLISHED

. . .

Udp      0      0   *.7                 *.*

Udp      0      0   *.9                 *.*

Udp      0      0   *.37                *.*

Udp      0      0   *.19                *.*

Udp      0      0   *.111               *.*

. . .

Например, выделенный рамкой элемент показывает сеанс регистрации TCP из порта клиента 2219 с IP-адресом 130.132.57.246 на стандартный порт telnet с  номером 23 и адресом 128.121.50.145. Строки, подобные *.7 и *.9, представляют службы UDP на tigger , ожидающие запросов от клиентов.

9.4 Механизмы протокола UDP

 Сделать закладку на этом месте книги

Какой механизм необходим для запуска протокола User Datagram Protocol? Прежде всего, UDP должен быть присвоен уникальный идентификатор протокола (17). Это значение будет помещаться в поле протокола  IP с названием Protocol во всех исходящих сообщениях UDP. Входящие сообщения со значением 17 в поле протокола  IP доставляются в UDP. Протокол UDP формирует сообщение, добавляя простой заголовок к данным от приложения. В этом заголовке указываются номера портов источника и назначения.

9.4.1 Заголовок UDP

 Сделать закладку на этом месте книги

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



Рис. 9.3. Заголовок UDP

9.4.2 Контрольная сумма

 Сделать закладку на этом месте книги

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

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

Формат псевдозаголовка и его участие в вычислении контрольной суммы показаны на рис. 9.4. Отметим, что адрес источника, адрес назначения и поле протокола заимствуются из заголовка IP.



Рис. 9.4. Поля псевдозаголовка для контрольной суммы UDP

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

9.4.3 Другие функции UDP

 Сделать закладку на этом месте книги

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

9.4.4 Пример сообщения UDP

 Сделать закладку на этом месте книги

Рис. 9.5 содержит совмещенный вывод IP и UDP частей запроса и соответствующих им ответов. Этот результат получен в мониторе локальной сети Sniffer  компании Network General. Запрос содержал требование вывода статуса информации и был послан хостом на сетевую станцию управления. Часть для данных в сообщениях запроса и ответа не приведена.



Рис. 9.5. Заголовки IP и UDP для запроса и ответа

Запрос был послан из IP-адреса 128.1.1.1 и порта UDP с номером 1227 на IP-адрес назначения 128.1.1.10 и 161-й порт UDP (запросы сетевого обслуживания всегда направляются на порт UDP с номером 161).

В обоих заголовках IP поле протокола  имеет значение 17, что указывает на использование протокола UDP. Контрольная сумма UDP не вычисляется для запроса, но присутствует в ответе.

Анализатор Sniffer  распознает, что порт 161 назначен для сетевого обслуживания.

9.5 Нагрузки в UDP

 Сделать закладку на этом месте книги

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

Если на службу приходит больше датаграмм, чем она может обработать, то дополнительные сообщения просто отбрасываются. Этот факт можно обнаружить с помощью секции UDP Socket Overflows (переполнение в socket протокола UDP) отчета сетевой статистики. Например, приведенный ниже отчет создан командой netstat :

> netstat -s

. . .

udp:

 0 incomplete headers

 0 bad data length fields

 0 bad checksums

 17 socket overflows

9.6 Дополнительная литература

 Сделать закладку на этом месте книги

Протокол User Datagram Protocol определен в RFC 768. RFC от 862 до 865 обсуждают UDP-службы, echo, discard, character generator  и quote of the day . RFC 867 описывает утилиту daytime , a RFC 1119 представляет вторую версию службы network time . Протокол BOOTP рассматривается в главе 11, а о дополнительных службах UDP будет упомянуто в следующих главах.

Глава 10

Протокол TCP

 Сделать закладку на этом месте книги

10.1 Введение

 Сделать закладку на этом месте книги

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

10.1.1 Основные службы TCP

 Сделать закладку на этом месте книги

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

IP пытается доставлять датаграммы, прилагая максимальные усилия, однако по пути следования данные могут разрушиться или прибыть в точку назначения в ином порядке, чем были отправлены. Датаграмма может путешествовать по сети достаточно долго и прибывать в произвольные моменты времени. Именно в TCP обеспечивается надежность, порядок следования и исключаются неисправности и ошибки .

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

10.1.2 TCP и модель клиент/сервер

 Сделать закладку на этом месте книги

TCP естественным образом интегрируется в окружение клиент/сервер (см. рис. 10.1). Серверное приложение прослушивает  (listen) поступающие запросы на соединение. Например, службы WWW, пересылки файлов или доступа с терминала прослушивают запросы, поступающие от клиентов. Коммуникации в TCP запускаются соответствующими подпрограммами, которые и инициализируют соединение с сервером (см. главу 21 о программном интерфейсе socket).



Рис. 10.1. Клиент вызывает сервер.

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

10.2 Концепции TCP

 Сделать закладку на этом месте книги

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

10.2.1 Входной и выходной потоки данных

 Сделать закладку на этом месте книги

Концептуальная  модель соединения предполагает пересылку приложением потока данных равному приложению. В то же время оно способно принимать поток данных от своего партнера по соединению. TCP предоставляет полнодуплексный  (full duplex) режим работы, при котором одновременно обслуживаются два потока  данных (см. рис. 10.2).



Рис. 10.2. Приложения обмениваются потоками данных.

10.2.2 Сегменты

 Сделать закладку на этом месте книги

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

Приложение передает данные в TCP, а этот протокол помещает их в выходной буфер  (send buffer). Далее TCP вырезает куски данных из буфера и отправляет их, добавляя заголовок (при этом формируются сегменты  — segment). На рис. 10.3 показано, как данные из выходного буфера  TCP пакетируются в сегменты. TCP передает сегмент в IP для доставки в виде отдельной датаграммы. Пакетирование данных в куски правильной длины обеспечивает эффективность их пересылки, поэтому до создания сегмента TCP будет ожидать, пока в выходном буфере не появится соответствующее количество данных.



Рис. 10.3 Создание сегмента TCP

10.2.3 Выталкивание

 Сделать закладку на этом месте книги

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

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

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

10.2.4 Срочные данные

 Сделать закладку на этом месте книги

Модель пересылки данных приложением предполагает применение упорядоченного потока байтов, следующего к точке назначения. Снова обратившись к примеру интерактивного сеанса, предположим, что пользователь нажал клавишу attention  (внимание) или break  (прерывание). Удаленное приложение должно быть способно пропустить мешающие байты и отреагировать на нажатие клавиши как можно скорее.

Механизм срочных данных  (urgent data) маркирует специальную информацию в сегменте как срочную.  Этим TCP сообщает своему партнеру, что сегмент содержит срочные данные, и может указать, где они находятся. Партнер должен переслать эту информацию в приложение назначения как можно скорее.

10.2.5 Порты приложения

 Сделать закладку на этом месте книги

Клиент должен идентифицировать службу, к которой он хочет получить доступ. Это выполняется через спецификацию IP-адреса службы хоста и его номера порта TCP. Как и для UDP, номера портов TCP находятся в диапазоне от 0 до 65 535. Порты в диапазоне от 0 до 1023 называются общеизвестными (well-known) и используются для доступа к стандартным службам.

Несколько примеров общеизвестных портов и соответствующих им приложений показано в таблице 10.1. Службы Discard  (порт 9) и chargen  (порт 19) являются TCP-версиями уже известных нам по UDP служб. Нужно помнить, что трафик на порт 9 протокола TCP полностью изолирован от трафика на порт 9 протокола UDP.


Таблица 10.1 Общеизвестные порты TCP и соответствующие им приложения

Порт Приложение Описание
9 Discard Отмена всех входящих данных
19 Chargen Генератор символов. Обмен потоком символов
20 FTP-Data Порт пересылки данных FTP
21 FTP Порт для диалога FTP
23 TELNET Порт для удаленной регистрации по Telnet
25 SMTP Порт протокола SMTP
110 POP3 Служба выборки почтовых сообщений для персональных компьютеров
119 NNTP Доступ к сетевым новостям

Что можно сказать о портах, используемых клиентами? В редких случаях клиент работает не через общеизвестный порт. Но в таких ситуациях, желая открыть соединение, он часто запрашивает у операционной системы присвоения ему неиспользуемого и незарезервированного порта. В конце соединения клиент обязан возвратить этот порт обратно, после чего порт может быть использован повторно другим клиентом. Поскольку в пуле нерезервированных номеров существует более 63 000 портов TCP, ограничения на порты для клиентов можно не учитывать.

10.2.6 Адреса socket

 Сделать закладку на этом месте книги

Как мы уже знаем, комбинация IP-адреса и порта для коммуникации называется адресом socket.  Соединение TCP полностью идентифицируется адресом socket на каждом конце данного соединения. На рис. 10.4 показано соединение между клиентом с адресом socket (128.36.1.24, порт = 3358) и сервером с адресом socket (130.42.88.22, порт = 21).



Рис. 10.4. Адреса socket

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

Обычно сервер способен одновременно управлять несколькими клиентами. Уникальные адреса socket сервера присваиваются одновременно всем его клиентам (см. рис. 10.5).



Рис. 10.5. Несколько клиентов соединены с адресами socket сервера

Поскольку датаграмма содержит сегмент соединения TCP, идентифицирующийся IP-адресами и портами, серверу очень просто отслеживать несколько соединений с клиентами.

10.3 Механизм обеспечения надежности TCP

 Сделать закладку на этом месте книги

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

10.3.1 Нумерация и подтверждение

 Сделать закладку на этом месте книги

Для обеспечения надежной пересылки данных в TCP используются нумерация (numbering) и подтверждение (acknowledgment — ACK). Схема нумерации TCP несколько необычна: каждый  пересылаемый по соединению октет  рассматривается как имеющий порядковый номер. Заголовок сегмента TCP содержит порядковый номер первого октета данных этого сегмента .

От приемника требуется подтверждение получения данных. Если ACK не приходит за интервал тайм-аута, данные передаются повторно. Этот способ называется позитивным подтверждением с ретрансляцией  (positive acknowledgment with retransmission).

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

На рис. 10.6 показан упрощенный взгляд на тайм-аут и повторную пересылку в TCP.



Рис. 10.6. Тайм-аут и повторная пересылка в TCP

10.3.2 Поля портов, последовательности и ACK в заголовке TCP

 Сделать закладку на этом месте книги

Как показано на рис. 10.7, первые несколько полей заголовка TCP предоставляют место для значений портов источника и назначения, порядкового номера первого байта вложенных данных и ACK, равного порядковому номеру следующего  байта, ожидаемого на другом конце. Другими словами, если TCP от своего партнера получит все байты до 30-го, в этом поле будет значение 31, указывающее сегмент, который следует переслать далее.



Рис. 10.7. Начальные значения в полях заголовка TCP

Нельзя не отметить одну маленькую деталь. Предположим, что TCP переслал байты от 1 до 50 и более уже нет данных для отправки. Если от партнера поступают данные, TCP обязан подтвердить их получение, для чего пошлет заголовок без подключенных к нему данных. Естественно, в этом заголовке присутствует значение ACK. В поле последовательности — значение 51, т.е. номер следующего байта, который намеревается  послать TCP. Когда TCP пошлёт следующие данные, новый заголовок TCP также будет иметь в поле последовательности значение 51.

10.4 Установка соединения

 Сделать закладку на этом месте книги

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

Серверное приложение ожидает появления клиента, который, желая получить доступ к серверу, выдает запрос на соединение  (connect), идентифицирующий IP-адрес и порт сервера.

Существует одна техническая особенность. Каждая сторона начинает нумерацию каждого байта не с единицы, а со случайного порядкового номера  (далее мы узнаем, для чего это делается). Исходная спецификация дает совет: начальный порядковый номер генерировать на основе 32-разрядного внешнего таймера, увеличивающего значения примерно каждые 4 мкс.

10.4.1 Сценарий соединения

 Сделать закладку на этом месте книги

Процедуру соединения часто называют тройным рукопожатием (three-way handshake), поскольку для установки соединения производится обмен тремя сообщениями — SYN, SYN и ACK.

Во время установки соединения партнеры обмениваются тремя важными порциями информации:

1. Объем буферного пространства для приема данных

2. Максимальное количество данных, переносимое во входящем сегменте

3. Начальный порядковый номер, используемый для исходящих данных

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

Способность управлять тем, как посылает данные другая сторона, является важным свойством, обеспечивающим масштабируемость TCP/IP. 

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



Рис. 10.8. Установление соединения

Выполняются следующие операции:

1. Сервер инициализируется и становится готовым к соединению с клиентами (это состояние называется пассивным открытием — passive open).

2. Клиент запрашивает у TCP открытие соединения с сервером по указанному IP-адресу и порту (это состояние называется активным открытием — active open).

3. Клиентская TCP получает начальный порядковый номер (в данном примере — 1000) и посылает сегмент синхронизации  (synchronize segment — SYN). В этом сегменте пересылается порядковый номер, размер приемного окна (4 К) и размер наибольшего сегмента, который может принять клиент (1460 байт).

4. Когда поступает SYN, серверная TCP получает свой  начальный порядковый номер (3000). Она посылает сегмент SYN, содержащий начальный порядковый номер (3000), ACK 1001 (что означает нумерацию первого посланного клиентом байта как 1001), размер приемного окна (4 К) и размер наибольшего сегмента, который сможет получить сервер (1024 байта).

5. Клиентская TCP, получив от сервера сообщение SYN/ACK, отсылает обратно ACK 3001 (первый байт посланных сервером данных должен нумероваться как 3001).

6. Клиентская TCP указывает своему приложению на открытие соединения.

7. Серверная TCP, получив от клиентской TCP сообщение ACK, информирует свое приложение об открытии соединения.

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

10.4.2 Установка значений параметров IP

 Сделать закладку на этом месте книги

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

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

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

10.5 Пересылка данных

 Сделать закладку на этом месте книги

Пересылка данных начинается после завершения трехшагового подтверждения создания соединения (см. рис. 10.9). Стандарт TCP позволяет включать в сегменты подтверждения обычные данные, но они не будут доставляться приложению, пока создание соединения не завершится. Для упрощения нумерации применяются 1000-байтные сообщения. Каждый сегмент заголовка TCP имеет поле ACK, идентифицирующее порядковый номер байта, который предполагается получить от партнера по соединению .



Рис. 10.9. Простой поток обмене данными и ACK

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

Сервер отвечает клиенту сегментом, содержащим 1000 байт данных (начинающихся с номера 3001). В его поле ACK заголовка TCP будет указано, что байты с 1001 по 2000 уже успешно получены, поэтому следующий ожидающийся от клиента порядковый номер сегмента должен быть 2001.

Далее клиент посылает сегменты, начинающиеся с байтов 2001, 3001 и 4001 в указанной последовательности. Отметим, что клиент не ожидает ACK после каждого из посланных сегментов. Данные пересылаются партнеру до заполнения его буферного пространства (ниже мы увидим, что получатель может очень точно указать объем пересылаемых ему данных).

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

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



Рис. 10.10. Потеря данных и повторная трансляция

10.6 Закрытие соединения

 Сделать закладку на этом месте книги

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

A: "Я закончил работу. Данных для пересылки больше нет".

B: "Хорошо".

В: "Я тоже завершил работу".

A: "Хорошо".

Допустим и такой сценарий (хотя он используется крайне редко):

A: "Я закончил работу. Данных для пересылки больше нет".

В: "Хорошо. Однако есть какие-то данные…"

В: "Я тоже завершил работу".

A: "Хорошо".

В рассмотренном ниже примере соединение закрывает сервер, как это часто происходит для связей клиент/сервер. В данном случае после ввода пользователем в сеансе telnet  команды logout (выйти из системы) сервер инициирует запрос на закрытие соединения. В ситуации, показанной на рис. 10.11, выполняются следующие действия:

1. Приложение на сервере указывает TCP на закрытие соединения.

2. TCP сервера посылает заключительный сегмент (Final Segment — FIN), информируя своего партнера о том, что данных для отправки больше нет.

3. TCP клиента посылает ACK в сегменте FIN.

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

5. Клиентское приложение сообщает своему TCP о закрытии соединения.

6. TCP клиента посылает сообщение FIN.

7. TCP сервера получает FIN от клиента и отвечает на него сообщением ACK.

8. TCP сервера указывает своему приложению на закрытие соединения.



Рис. 10.11. Закрытие соединения

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

10.6.1 Внезапное завершение

 Сделать закладку на этом месте книги

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

10.7 Управление потоком

 Сделать закладку на этом месте книги

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

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

Поток данных поступает во входной буфер и сохраняется в нем до пересылки в приложение (определяемое портом TCP). На рис. 10.12 показан входной буфер, способный принять 4 Кбайт.



Рис. 10.12. Приемное окно входного буфера

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

10.7.1 Приемное окно

 Сделать закладку на этом месте книги

Приемное окно  (receive window) — любое пространство во входном буфере, еще не занятое данными. Данные остаются во входном буфере, пока не будут задействованы целевым приложением. Почему приложение не забирает данные сразу?

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

Приемное окно расширяется от последнего подтвержденного байта до конца буфера. На рис. 10.12 сначала доступен весь буфер и, следовательно, доступно приемное окно в 4 Кбайт. Когда поступит первый Кбайт, приемное окно сократится до 3 Кбайт (для простоты мы будем считать, что каждый сегмент имеет размер в 1 Кбайт, хотя на практике это значение меняется в зависимости от потребностей приложения). Поступление следующих двух сегментов по 1 Кбайту приведет к сокращению приемного окна до 1 Кбайта.

Далее приложение примет 3 Кбайт данных из буфера, освобождая место для приема следующей информации. Мысленно это можно представить как сдвиг  окна влево. А в буфере доступными станут уже 4 Кбайт.

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

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

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

10.7.2 Окно отправки

 Сделать закладку на этом месте книги

Система, передающая данные, должна отслеживать две характеристики: сколько данных уже было отправлено и подтверждено, а также текущий размер приемного окна получателя. Активное пространство отправки  (send space) расширяется от первого неподтвержденного октета к левому краю текущего приемного окна. Часть окна , используемая для отправки , указывает, сколько еще дополнительных данных можно послать партнеру.

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

1. Отправитель начинает работу с окном отправки в 4 Кбайт.

2. Отправитель пересылает 1 Кбайт. Копия этих данных сохраняется до получения подтверждения (ACK), поскольку может потребоваться их повторная передача.

3. Прибывает сообщение ACK для первого Кбайта, и отправляются следующие 2 Кбайт данных. Результат показан в третьей сверху части рис. 10.13. Хранение 2 Кбайт продолжается.

4. Наконец поступает ACK для всех переданных данных (т.е. все они получены приемником). ACK восстанавливает размер окна отправки в 4 Кбайт.



Рис. 10.13. Окно отправки

Следует указать на несколько интересных особенностей:

■ Отправитель не дожидается ACK для каждого из посылаемых сегментов данных. Единственным ограничением на пересылку является размер приемного окна (например, отправитель должен пересылать только 4 К однобайтовых сегментов).

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

10.8 Заголовок TCP

 Сделать закладку на этом месте книги

На рис. 10.14 показан формат сегмента (заголовок TCP и данные). Заголовок начинается с идентификаторов портов источника и назначения. Следующее далее поле порядкового номера  (sequence number) указывает позицию в исходящем потоке данных, которую занимает данный сегмент. Поле ACK  (подтверждения) содержит сведения о предполагаемом следующем сегменте, который должен появиться во входном потоке данных.



Рис. 10.14. Сегмент TCP

Существуют шесть флагов:

URG  Равен 1 для срочных данных
ACK  Равен 1 для всех сегментов, кроме начального
PSH  Указывает на необходимость своевременной доставки данных
RST  Индикатор ошибки, используется и для завершения сеанса
SYN  Равен 1 во время установки соединения
FIN  Равен 1 при нормальном закрытии

Поле смещения данных  (Data Offset) содержит размер заголовка TCP в 32-разрядных словах. Заголовок TCP должен заканчиваться на 32-битной границе.

10.8.1 Вариант максимального размера сегмента

 Сделать закладку на этом месте книги

Параметр "максимальный размер сегмента"  (maximum segment size — MSS) применяется для объявления о наибольшем куске данных, который может быть принят и обработан системой. Однако название несколько неточно. Обычно в TCP сегмент  рассматривается как заголовок плюс данные. Однако максимальный размер сегмента  определяется как:

Размер наибольшей датаграммы, которую можно принять, – 40 

Други


убрать рекламу







ми словами, MSS отражает наибольшую полезную нагрузку  в приемнике при длине заголовков TCP и IP по 20 байт. Если имеются дополнительные параметры, их длину следует вычесть из общего размера. Следовательно, количество данных, которые можно переслать в сегменте, определяется как:

Заявленное значение MSS + 40 – (сумма длин заголовков TCP и IP) 

Обычно партнеры обмениваются значениями MSS в начальных сообщениях SYN при открытии соединения. Если система не анонсирует величину максимального размера сегмента, используется значение по умолчанию в 536 байт.

Размер максимального сегмента кодируется 2-байтовой вводной частью со следующим далее 2-байтовым значением, т.е. наибольшая величина будет составлять 216-1 (65 535 байт).

MSS накладывает жесткое ограничение на пересылаемые в TCP данные: приемник не сможет обработать большие значения. Однако отправитель использует сегменты меньшего размера,  поскольку для соединения определяется еще размер MTU по пути следования.

10.8.2 Использование полей заголовка в запросе на соединение

 Сделать закладку на этом месте книги

Первый сегмент, посылаемый для открытия соединения, имеет значение флага SYN, равное 1, и флага ACK — 0. Начальный SYN является единственным  сегментом, имеющим поле ACK со значением 0. Отметим, что средства защиты пользуются этим признаком для выявления входных запросов на сеанс TCP.

Поле порядкового номера  содержит начальный порядковый номер  (initial sequence number), поле окна —  начальный размер приемного окна.  Единственным определенным на сегодняшний момент параметром TCP является максимальный размер сегмента (когда он не указан, используется значение по умолчанию в 536 байт), который предполагает получать TCP. Это значение занимает 32 бита и обычно присутствует в запросе на соединение в поле вариантов  (Option). Длина заголовка TCP, содержащего значение MSS, составляет 24 байта.

10.8.3 Использование полей заголовка в ответе на запрос соединения

 Сделать закладку на этом месте книги

В разрешающем ответе на запрос соединения оба флага (SYN и ACK) равны 1. Отвечающая система указывает начальный порядковый номер в соответствующем поле, а размер приемного окна — в поле Window . Максимальный размер сегмента, который желает использовать получатель, обычно находится в ответе на запрос о соединении (в поле вариантов ). Это значение может отличаться от значения запрашивающей соединение стороны, т.е. могут применяться две разные величины.

Запрос на соединение может быть отклонен посредством указания в ответе флага сброса (RST) со значением 1.

10.8.4 Выбор начального порядкового номера

 Сделать закладку на этом месте книги

Спецификация TCP предполагает, что во время установки соединения каждая из сторон выбирает начальный порядковый номер  (по текущему значению 32-разрядного внутреннего таймера). Как это выполняется?

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

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

10.8.5 Общепринятое использование полей

 Сделать закладку на этом месте книги

При подготовке заголовка TCP к пересылке порядковый номер первого октета передаваемых данных указывается в поле последовательного номера  (Sequence Number).

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

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

Флаг URGENT (срочность) при значении 1 предполагает срочную пересылку данных, а соответствующий указатель должен ссылаться на последний октет срочных данных. Типичным использованием срочных данных является пересылка из терминала сигналов на отмену или прерывание.

Срочные данные часто называют информацией вне полосы пропускания  (out-of-band). Однако этот термин неточен. Срочные данные пересылаются в обычном потоке TCP, хотя отдельные реализации могут иметь специальные механизмы для указания приложению на поступление срочных данных, а приложение должно проверить содержимое срочных данных, прежде чем поступят все байты сообщения.

Флаг RESET (сброс) имеет значение 1, когда следует аварийно завершить соединение. Этот же флаг устанавливается в ответе при поступлении сегмента, не связанного ни с одним из текущих соединений TCP.

Флаг FIN устанавливается в 1 для сообщений о закрытии соединения.


10.8.6 Контрольная сумма

 Сделать закладку на этом месте книги

Контрольная сумма IP предназначена только для заголовка IP, а контрольная сумма TCP вычисляется для всего сегмента, а также для псевдозаголовка, созданного из заголовка IP. Во время вычисления контрольной суммы TCP соответствующее поле имеет значение 0. На рис. 10.15 показан псевдозаголовок, очень напоминающий тот, что используется в контрольной сумме UDP.



Рис. 10.15. Поле псевдозаголовка включается в контрольную сумму TCP

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

10.9 Пример сегмента TCP

 Сделать закладку на этом месте книги

Рис. 10.16, протокол работы анализатора Sniffer  компании Network General, представляет собой последовательность сегментов TCP. Первые три сегмента устанавливают соединение между клиентом и сервером Telnet . В последнем сегменте переносится 12 байт данных.



Рис. 10.16. Отображение заголовка TCP анализатором Sniffer

Анализатор Sniffer  транслирует большинство значений в десятичный вид. Однако значения флагов выводятся как шестнадцатеричные. Флаг со значением 12 представляет собой 010010. Контрольная сумма выводится тоже в шестнадцатеричном виде.

10.10 Поддержка работы сеанса

 Сделать закладку на этом месте книги

10.10.1 Зондирование окна

 Сделать закладку на этом месте книги

Скоростной отправитель и медленный получатель могут сформировать приемное окно размером в 0 байт. Этот результат называется закрытием окна  (close window). Когда появляется свободное место для обновления размера приемного окна, используется ACK. Однако, если такое сообщение будет потеряно, обе стороны должны будут ожидать до бесконечности.

Для избежания такой ситуации отправитель устанавливает сохраняемый таймер  (persist timer) при закрытии премного окна. Значением таймера берется тайм-аут повторной пересылки. По завершении работы таймера партнеру отсылается сегмент зондирования окна  (window probe; в некоторых реализациях в него включаются и данные). Зондирование заставляет партнера посылать назад ACK, который сообщает о текущем статусе окна.

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

10.11 Завершение сеанса

 Сделать закладку на этом месте книги

10.11.1 Тайм-аут

 Сделать закладку на этом месте книги

Работа партнера по соединению может завершиться крахом либо полностью прерваться вследствие неисправности шлюза или связи. Чтобы предотвратить повторную пересылку данных в TCP, существует несколько механизмов.

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

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

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

10.11.2 Поддержание соединения

 Сделать закладку на этом месте книги

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

Однако любое соединение — активное или неактивное — занимает много памяти компьютера. Некоторым администраторам нужно возвратить в системы неиспользованные ресурсы. Поэтому многие реализации TCP способны посылать сообщение о поддержании соединения  (keep-alive), тестирующее неактивные соединения. Такие сообщения периодически отправляются партнеру для проверки его существования в сети. В ответ должны поступать сообщения ACK. Использование сообщений о поддержании соединения не является обязательным. Если в системе имеется такая возможность, приложение может отменить ее собственными средствами. Предполагаемый период по умолчанию  для тайм-аута поддержания соединения составляет целых два часа!

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

10.12 Производительность

 Сделать закладку на этом месте книги

Насколько эффективна работа TCP? На производительность ресурсов влияют многие факторы, из которых основными являются память и полоса пропускания (см. рис. 10.17).



Рис. 10.17. Факторы производительности TCP

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

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

Например, если источник может отсылать данные со скоростью 10 000 байт/с, а на возврат ACK тратится 2 с, то на другой стороне нужно обеспечить приемное окно размером не менее 20 000 байт, иначе поток данных не будет непрерывным. Приемный буфер в 10 000 байт вполовину снизит пропускную способность.

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

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

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

Предположим, что сетевое окружение совершенно: имеются достаточные ресурсы и контекстное переключение выполняется быстрее, чем ковбои выхватывают свои револьверы. Будет ли получена прекрасная производительность?

Не всегда. Имеет значение и качество разработки программного обеспечения TCP. За долгие годы в различных реализациях TCP были диагностированы и решены многие проблемы производительности. Можно считать, что наилучшим будет программное обеспечение, соответствующее документу RFC 1122, в котором определены требования к коммуникационному уровню хостов Интернета.

Не менее важно исключение синдрома "бестолкового окна"  и применение алгоритмов Джекобсона, Керна и Партриджа (эти интересные алгоритмы будут рассмотрены ниже).

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

10.13 Алгоритмы повышения производительности

 Сделать закладку на этом месте книги

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

■ Медленный старт  (slow start) мешает использованию большой доли сетевого трафика для нового сеанса, что может привести к непроизводительным потерям.

■ Излечение от синдрома "бестолкового окна"  (silly window syndrome) предохраняет плохо разработанные приложения от перегрузки сети сообщениями.

■ Задержанный ACK  (delayed ACK) снижает перегрузку посредством сокращения количества независимых сообщений подтверждения пересылки данных.

■ Вычисляемый тайм-аут повторной пересылки  (computing retransmission timeout) основывается на согласовании реального времени сеанса, уменьшая объем ненужных повторных пересылок, но при этом не вызывает больших задержек для реально необходимых обменов данными.

■ Торможение пересылки TCP при перегрузках  в сети позволяет маршрутизаторам вернуться в исходный режим и совместно использовать сетевые ресурсы для всех сеансов.

■ Отправка дублированных ACK  (duplicate ACK) при получении сегмента вне последовательности отправки позволяет партнерам выполнить повторную пересылку до наступления тайм-аута.

10.13.1 Медленный старт

 Сделать закладку на этом месте книги

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

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

Нагрузочное окно  (congestion window) начинается с размера в 1 сегмент. Для каждого сегмента с успешно полученным ACK размер нагрузочного окна увеличивается на 1 сегмент, пока оно остается меньше, чем приемное окно. Если сеть не перегружена, нагрузочное окно постепенно достигнет размера приемного окна. При нормальном состоянии пересылки размеры этих окон будут совпадать.

Отметим, что медленный старт — не такой уж и медленный. После первого ACK размер нагрузочного окна равен 2-м сегментам, а после успешного получения ACK для двух сегментов размер может увеличиться до 8 сегментов. Другими словами, размер окна увеличивается экспоненциально.

Предположим, что вместо получения ACK возникла ситуация тайм-аута. Поведение нагрузочного окна в таком случае рассматривается ниже.

10.13.2 Синдром "бестолкового окна"

 Сделать закладку на этом месте книги

В первых реализациях TCP/IP разработчики столкнулись с феноменом синдрома "бестолкового окна"  (Silly Window Syndrome — SWS), который проявлялся достаточно часто. Для понимания происходящих событий рассмотрим следующий сценарий, приводящий к нежелательным последствиям, но вполне возможный:

1. Передающее приложение быстро отсылает данные.

2. Принимающее приложение читает из входного буфера по 1 байту данных (т.е. медленно).

3. Входной буфер после чтения быстро заполняется.

4. Принимающее приложение читает 1 байт, и TCP отправляет ACK, означающий "Я имею свободное место для 1 байта данных".

5. Передающее приложение отправляет по сети пакет TCP из 1 байта.

6. Принимающий TCP посылает ACK, означающий "Спасибо. Я получил пакет и не имею больше свободного места".

7. Принимающее приложение опять читает 1 байт и отправляет ACK, и весь процесс повторяется.

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

Реальные ситуации, конечно, не столь экстремальны. Быстрый отправитель и медленный получатель будут обмениваться небольшими (относительно максимального размера сегмента) кусками данных и переключаться по почти заполненному приемному окну. На рис. 10.18 показаны условия для появления синдрома "бестолкового окна".



Рис. 10.18. Буфер приемного окно с очень малым размером свободного пространства

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

minimum(1/2 входного буфера, Максимальный размер сегмента) 

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

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

10.13.3 Алгоритм Нейгла

 Сделать закладку на этом месте книги

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

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

10.13.4 Задержанный ACK

 Сделать закладку на этом месте книги

Еще одним механизмом повышения производительности является способ задержки ACK. Сокращение числа ACK снижает полосу пропускания, которую можно использовать для пересылки другого трафика. Если партнер по TCP чуть задержит отправку ACK, то:

■ Можно подтвердить прием нескольких сегментов одним ACK.

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

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

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

10.13.5 Тайм-аут повторной пересылки

 Сделать закладку на этом месте книги

После отправки сегмента TCP устанавливает таймер и отслеживает поступление ACK. Если ACK не получен в течение периода тайм-аута, TCP выполняет повторную пересылку сегмента (ретрансляцию). Однако каким должен быть период тайм-аута?

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

Как выбрать правильный промежуток для тайм-аута? Значение, пригодное для высокоскоростной локальной сети, не подойдет для удаленного соединения со множеством попаданий. Значит, принцип "одно значение для любых условий" явно непригоден. Более того, даже для существующего конкретного соединения могут измениться сетевые условия, а задержки — увеличиться или снизиться.

Алгоритмы Джекобсона, Керна и Партриджа (описанные в статьях Congestion Avoidance and Control , Van Jacobson, и Improving Round-Trip Time Estimates in Reliable Transport Protocols , Karn и Partridge) позволяют адаптировать TCP к изменению сетевых условий. Эти алгоритмы рекомендованы к использованию в новых реализациях. Мы кратко рассмотрим их ниже.

Здравый смысл подсказывает, что наилучшей основой оценки правильного времени тайм-аута для конкретного соединения может быть отслеживание времени цикла  (round-trip time) как промежутка между отправкой данных и получением подтверждения об их приеме.

Хорошие решения для следующих величин можно получить на основе элементарных статистических сведений (см. рис. 10.19), которые помогут вычислить время тайм-аута. Однако не нужно полагаться на усредненные величины, поскольку более половины оценок будет больше, чем среднестатистическая величина. Рассмотрев пару отклонений, можно получить более правильные оценки, учитывающие нормальное распределение и снижающие слишком долгое время ожидания повторной пересылки.








mg_141png.jpg">

Рис. 10.19. Распределение значений времени цикла

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

Последнее отклонение = | Последний цикл - Средняя величина |

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

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

Например, если 1000 значений дали среднестатистическую величину в 170 единиц, но далее были замерены 50 значений со средним в 282, то текущее среднее будет:

170×1000/1050 + 282×50/1050 = 175

Более резонной будет величина сглаженного времени цикла  (Smoothed Round-Trip Time — SRTT), которая учитывает приоритет более поздних значений:

Новое SRTT = (1 – α)×(старое SRTT) + α×Последнее значение цикла

Значение α находится между 0 и 1. Увеличение а  приводит к большему влиянию текущего времени цикла на сглаженное среднее значение. Поскольку компьютеры быстро могут выполнять деление на степени числа 2, сдвигая двоичные числа направо, для α всегда выбирается значение (1/2)n (обычно 1/8), поэтому:

Новое SRTT = 7/8×старое SRTT + 1/8×Последнее время цикла

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


Таблица 10.2 Вычисление сглаженного времени цикла

Старое SRTT Самое последнее RTT (7/8)×(старое SRTT) + (1/8)×(RTT)
230.00 294 238.00
238.00 264 241.25
241.25 340 253.59
253.59 246 252.64
252.64 201 246.19
246.19 340 257.92
257.92 272 259.68
259.68 311 266.10
266.10 282 268.09
268.09 246 265.33
265.33 304 270.16
270.16 308 274.89
274.89 230 269.28
269.28 328 276.62
276.62 266 275.29
275.29 257 273.00
273.00 305 277.00

Теперь возникает вопрос о выборе значения для тайм-аута повторной пересылки. Анализ величин времени цикла показывает существенное отклонение этих значений от текущей средней величины. Имеет смысл установить границу для величины отклонений (девиаций). Хорошие величины для тайм-аута повторной пересылки (в стандартах RFC эту величину именуют Retransmission TimeOut — RTO) дает следующая формула с ограничением сглаженного отклонения (SDEV):

Т = Тайм-аут повторной пересылки = SRTT + 2×SDEV

Именно эта формула рекомендована в RFC 1122. Однако некоторые реализации используют другую:

Т = SRTT + 4×SDEV

Для вычисления SDEV сначала определяют абсолютное значение текущего отклонения:

DEV = | Последнее время цикла – старое SRTT |

Затем используют формулу сглаживания, чтобы учесть последнее значение:

Новое SDEV = 3/4×старое SDEV + 1/4×DEV

Остается один вопрос — какие взять начальные значения? Рекомендуется:

Начальный тайм-аут = 3 с

Начальный SRTT = 0

Начальный SDEV = 1,5 с

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

10.13.6 Пример статистики

 Сделать закладку на этом месте книги

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

tcp:

1301644 packets sent

 879137 data packets (226966295 bytes)

 21815 data packets (8100927 bytes) retransmitted


2012869 packets received

 762469 acks (for 226904227 bytes)

 35803 duplicate acks

 0 acks for unsent data

 1510769 packets (314955304 bytes) received in-sequence

 9006 completely duplicate packets (867042 bytes)

 74 packets with some dup. data (12193 bytes duped)

 13452 out-of-order packets (2515087 bytes)

Системой tigger  были повторно переданы менее чем 2,5% сегментов данных TCP. Для полутора миллионов входящих сегментов данных (остальные являются чистыми сообщениями ACK) дублированы были только 0,6%. При этом следует учитывать, что уровень потерь во входных данных примерно соответствует уровню для выходных сегментов. Таким образом, бесполезный трафик повторной пересылки составляет около 0,6% от общего трафика.

10.13.7 Вычисления после повторной отправки

 Сделать закладку на этом месте книги

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

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

10.13.8 Действия после повторной пересылки

 Сделать закладку на этом месте книги

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

■ Снижение скорости повторной пересылки

■ Борьба с перегрузкой сети с помощью сокращения общего трафика

10.13.9 Экспоненциальное торможение

 Сделать закладку на этом месте книги

После повторной пересылки удваивается интервал тайм-аута. Однако что произойдет при повторном переполнении таймера? Данные будут оправлены еще раз, а период повторной пересылки снова удвоится. Этот процесс называется экспоненциальным торможением  (exponential backoff).

Если продолжает проявляться неисправность сети, период тайм-аута будет удваиваться до достижения предустановленного максимального значения (обычно — 1 мин). После тайм-аута может быть отправлен только один сегмент. Тайм-аут наступает и при превышении заранее установленного значения для количества пересылок данных без получения ACK.

10.13.10 Снижение перегрузок за счет уменьшения пересылаемых по сети данных

 Сделать закладку на этом месте книги

Сокращение объема пересылаемых данных несколько сложнее, чем рассмотренные выше механизмы. Оно начинает работать, как и уже упомянутый медленный старт. Но, поскольку устанавливается граница для уровня трафика, который может в начальный момент привести к проблемам, будет реально замедляться скорость обмена вследствие увеличения размера нагрузочного окна по одному сегменту. Нужно установить значения границы для реального сокращения скорости отправки. Сначала вычисляется граница опасности (danger threshold):

Граница – 1/2 minimum (текущее нагрузочное окно, приемное окно партнера) 

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

■ Установить размер нагрузочного окна в один сегмент.

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

■ После этого с каждым полученным ACK к нагрузочному окну добавлять меньшее значение, которое выбирается на основе скорости увеличения по одному сегменту для времени цикла (увеличение вычисляется как MSS/N, где N — размер нагрузочного окна в сегментах).

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

■ Отправляется 1 сегмент (нагрузочное окно = 1 сегмент).

■ Получен ACK — отправляется 2 сегмента.

■ Получен ACK для 2 сегментов — посылается 4 сегмента, (достигается граница).

■ Получен ACK для 4 сегментов. Посылается 5 сегментов.

■ Получен ACK для 5 сегментов. Посылается 6 сегментов.

■ Получен ACK для 6 сегментов. Посылается 7 сегментов.

■ Получен ACK для 7 сегментов. Посылается 8 сегментов (нагрузочное окно по размеру снова стало равно приемному окну).

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



Рис. 10.20. Ограничение скорости пересылки во время перегрузки

10.13.11 Дублированные ACK

 Сделать закладку на этом месте книги

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

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



Рис. 10.21. Дублированные ACK

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

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

10.13.12 Что делается после подавления источника?

 Сделать закладку на этом месте книги

В соответствии со стандартом Host Requirements  (требования к хостам) TCP должен выполнять тот же самый медленный старт, как это описано выше, при подавлении источника (source quench). Однако сообщение об этом не является целенаправленным или эффективным, поскольку получившее это сообщение соединение может и не создавать слишком большого трафика. Текущая спецификация Router Requirements  (требования к маршрутизаторам) указывает, что маршрутизаторы не должны  посылать сообщений о подавлении источника.

10.13.13 Статистика TCP

 Сделать закладку на этом месте книги

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

tcp:

1301644 packets sent                               Пакетами именуются сегменты.

879137 data packets (226966295 bytes)

21815 data packets (8100927 bytes) retransmitted   Повторная пересылка.

132957 ack-only packets (104216 delayed)           Отметим большое количество

 задержанных ACK.

4 URG only packets

1038 window probe packets                          Зондирование открытия окна

 нулевого размера.

248582 window update packets

22413 control packets                              Это сообщения SYN и FIN.

2012869 packets received

762469 acks (for 226904227 bytes)

35803 duplicate acks                               Сигнал о пакетах, прибывших

 вне последовательности.

0 acks for unsent data

1510769 packets (314955304 bytes)

  received in-sequence

9006 completely duplicate packets (867042 bytes)   Результат тайм-аута при реальной

 доставке данных.

74 packets with some dup. data (12193 bytes duped) С целью большей эффективности

 некоторые данные при повторной отправке были перепакетированы для включения дополнительных байт.

13452 out-of-order packets (2515087 bytes)

530 packets (8551 bytes) of data after window      Возможно, эти данные были

 включены в сообщения зондирования.

526 window probes

14158 window update packets

402 packets received after close                   Это последующие повторные

 отправки.

108 discarded for bad checksums                    Неверная контрольная сумма TCP.

0 discarded for bad header offset fields

7 discarded because packet too short

6378 connection requests

9539 connection accepts

14677 connections established (including accepts)

18929 connections closed (including 643 drops)

4100 embryonic connections dropped

572187 segments updated rtt (of 587397 attempts)   Неудачные попытки изменения

 времени цикла, поскольку ACK не успел прийти до завершения тайм-аута,

11014 retransmit timeouts

26 connections dropped by rexmit timeout           Последующие неудачные попытки

 повторной отправки, что указывает на потерянное соединение.

1048 persist timeouts                              Тайм-ауты по зондированию

 нулевого окна.

535 keepalive timeouts                             Тайм-ауты по проверке

 неработающего соединения.

472 connections dropped by keepalive

10.14 Соответствие требованиям разработчика

 Сделать закладку на этом месте книги

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

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

10.15 Барьеры для производительности

 Сделать закладку на этом месте книги

TCP доказал свою гибкость, работая в сетях со скоростью обмена в сотни или миллионы бит за секунду. Этот протокол позволил достичь хороших результатов в современных локальных сетях с топологиями Ethernet, Token-Ring и Fiber Distributed Data Interface (FDDI), а также для низкоскоростных линий связи или соединений на дальние расстояния (подобных спутниковым связям).

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

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

■ Максимальный размер сегмента приемника — 1 Кбайт.

■ Приемное окно — 4 Кбайт.

■ Полоса пропускания позволяет пересылать по два сегмента за 1 с. 

■ Принимающее приложение поглощает данные по мере их поступления.

■ Сообщения ACK прибывают через 2 с.

Отправитель способен посылать данные непрерывно. Ведь когда выделенный для окна объем будет заполнен, прибывает ACK, разрешающий отправку другого сегмента:

SEND SEGMENT 1.

SEND SEGMENT 2.

SEND SEGMENT 3.

SEND SEGMENT 4.

Через 2 с: 

RECEIVE ACK OF SEGMENT 1, CAN SEND SEGMENT 5.

RECEIVE ACK OF SEGMENT 2, CAN SEND SEGMENT 6.

RECEIVE ACK OF SEGMENT 3, CAN SEND SEGMENT 7.

RECEIVE ACK OF SEGMENT 4, CAN SEND SEGMENT 8.

Еще через 2 с: 

RECEIVE ACK OF SEGMENT 5, CAN SEND SEGMENT 9.

. . .

Если приемное окно было только в 2 Кбайт, отправитель будет вынужден ждать одну секунду из каждых двух перед отправкой следующих данных. Фактически, чтобы удержать непрерывный поток данных, приемное окно должно иметь размер не менее:

Окно = Полоса пропускания×Время цикла

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

Теперь рассмотрим, что происходит с высокоскоростными соединениями. Например, если полоса пропускания и скорость пересылки измеряются 10 млн. бит в секунду, но время цикла составляет 100 мс (1/10 секунды), то для непрерывного потока приемное окно должно хранить, по крайней мере, 1 000 000 бит, т.е. 125 000 байт. Но наибольшее число, которое можно записать в поле заголовка для приемного окна TCP, равно 65 536.

Другая проблема возникает при высоких скоростях обмена, поскольку порядковые номера очень быстро закончатся. Если по соединению можно будет пересылать данные со скоростью 4 Гбайт/с, то порядковые номера должны обновляться в течение каждой секунды. Не будет возможности различить старые дублирующие датаграммы, которые были отсрочены более чем на секунду при перемещении по Интернету, от свежих новых данных.

Сейчас активно проводятся новые исследования для улучшения TCP/IP и устранения упомянутых выше препятствий.

10.16 Функции TCP

 Сделать закладку на этом месте книги

Данная глава посвящена многочисленным функциям TCP. Ниже перечислены основные из них:

■ Связывание портов с соединениями

■ Инициализация соединений посредством трехшагового подтверждения

■ Выполнение медленного старта, исключающего перегрузку сети

■ Сегментация данных при пересылке

■ Нумерация данных

■ Обработка поступающих дублированных сегментов

■ Вычисление контрольных сумм

■ Регулирование потока данных через приемное окно и окно отправки

■ Завершение соединения установленным способом

■ Прерывание соединения

■ Пересылка срочных данных