Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Мир TCP/IP. Internet Protocol

С.Д. Рябко

Непреходящие ценности

Сейчас, вероятно, еще рано говорить о становлении сетевых технологий как о явлении историческом, и поэтому нет уверенности в том, что то или иное суждение сохранит свою истинность на достаточно продолжительный срок. Тем не менее мне кажется, что историк, который лет через пятьдесят-сто попытается разобраться в эволюциях и революциях коммуникационных технологий последних 30 лет ХХ века, обязательно красным карандашом обведет три слова: "Cu", "UNIX", "TCP/IP". Это вызвано будет тем, что на фоне десятков технологических коллизий, например дискуссий об использовании мэйнфреймов и распределенных систем, на фоне триумфов и провалов таких китов коммуникационной и компьютерной индустрии, как IBM или Microsoft, три названных продукта выделяются почти мистическим идеологическим потенциалом, заложенным в них. Так, тот же Си (я не отделяю его от последующей трансформации в Си++), написанный, как злословили на его счет, "людьми с отвертками в руках", в конечном итоге стал единственным де-факто стандартным в мировом масштабе инструментальным средством, без труда победив, например, семейство красивых, строгих и функциональных языков программирования Н.Вирта. То же самое происходит и с операционными системами: Microsoft, породившая массу программных продуктов (но не породившая, правда, и малой части лежащих в их основе технических идей), и Novell, создавшая лучшую из ориентированных на файловый сервис сетевых операционных систем, отошли от идеологии отстаивания своих внутренних решений и начали миграцию в сторону UNIX (продукты Windows NT и UnixWare, соответственно). Хотя казалось, эти-то компании запросто могли бы принимать и отстаивать в мировом масштабе собственные решения.

Так в чем же секрет успеха этих, кстати, тесно исторически связанных, продуктов - Cи, UNIX и TCP/IP? Мне кажется, в первую очередь, в том, что при их создании исповедовалась универсальность принимаемых технологических решений, открытость к наращиванию функциональных возможностей. Например, даже несмотря на то, что заявленная с момента появления языка программирования Си переносимость (платформонезависимость) долгое время оставалась декларативной, да и сейчас обеспечение переноса Си-приложения с платформы на платформу происходит не всегда автоматически, именно изначальная установка на платформонезависимость предрешила прогресс в этом направлении. Или, скажем, принцип открытости архитектуры к наращиваемости функциональных возможностей привел к тому, что на некотором этапе развития в UNIX была реализована процедура удаленного доступа (remote login), открывшая качественно новые возможности в распределенных системах.

Тесная связь между собой Cu, UNIX и TCP/IP порождает их взаимодополняемость и взамоподдержку: написанная на Сu, операционная система UNIX относительно легко переносится с платформы на платформу; принцип платформонезависимости, использованный в Сu, находит свое логическое отражение в аппаратной (канальной) независимости протокола IP; возможности удаленного доступа UNIX используются в ответственных за сетевое управление протоколах семейства TCP/IP.

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

TCP/IP и Internet: немного истории

Интересно, что открытые спецификации TCP/IP ведут начало от проекта, инициированного закрытым ведомством - Министерством обороны США. Вызывает удивление и восхищение техническая дальновидность этой инициативы: сверхзадача, поставленная перед разработчиками проекта формулировалась не как создание частного сетевого решения, а как обеспечение среды для объединения разнородных локальных сетей и коммуникационных систем. Этот проект был начат в середине 70-х годов и возглавлялся агентством DARPA (Defense Advansed Research Projects Agency) Министерства обороны США. Современный вид базовые протоколы TCP/IP приобрели в 1977-1979 гг.

Для разработки проекта были привлечены широчайшие технологические ресурсы университетских, промышленных и правительственных лабораторий США. Соразработчиками и узлами создаваемой коммуникационной инфраструктуры стали Национальный научный фонд (NSF, National Science Foundation), Министерство энергетики (DOE, Department of Energy), Министерство обороны (DOD, Department of Defense), Агентство здравоохранения и гуманитарных услуг (HHS, Health and Human Services Agency) и Национальное аэрокосмическое агентство (NASA, National Aeronautics and Space Agency). Получившуюся в результате интерсеть называют connected Internet, DARPA/NSF Internet, или TCP/IP Internet, либо просто (для краткости) Internet 1.

Важнейшим шагом в развитии протоколов TCP/IP явилась их интеграция с операционной системой BSD UNIX (версия Berkley Software Distribution), созданной в Калифорнийском университете (University of California). Работы, выполненные в этом университете, положили начало и первым прикладным протоколам семейства TCP/IP. Так, прообразом современного протокола дистанционного файлового доступа FTP (File Traqnsfer Protocol) была берклиевская утилита для удаленного копирования (remote copy utility) файлов RCP.

Организационные структуры Internet

Реализация сетевого проекта требовала принятия организационных мер, координирующих усилия разработчиков. В связи с этим создавались и реорганизовывались технические комитеты, которые в 1989 г. приобрели современную структуру в виде центрального органа IAB (Internet Activities Board), включающего два подкомитета: исследовательский - IRTF (Internet Research Task Force) и "законодательный" - IETF (Internet Engineering Task Force). Последний выполняет весьма важную функцию анализа, разработки и принятия своеобразных стандартов сети Internet, получивших название RFC (Request For Comments).

Кроме того, в Internet существует орган, ответственный за распространение технической информации, работу по регистрации и подключению пользователей к Internet и за решение ряда административных задач, таких как распределение адресов в этой глобальной сети. Этот орган называется Network Information Center (NIC).

TCP/IP и OSI/ISO

Примерно к концу 80-х - началу 90-х годов относится всплеск энтузиазма вокруг коммуникационных протоколов, разработанных (или стандартизованных) Международной организацией по стандартизации (МОС, или ISO - International Standard Organization). Ею была разработана спецификация, названная моделью Взаимодействия открытых систем (ВОС, или OSI - Open Systems Interconnection). Одно время казалось, что создание такой весьма компетентной организацией ряда спецификаций коммуникационных стандартов, зачастую идеологически более общих и предусматривающих большую, нежели в их TCP/IP-прототипах, функциональность, ставит TCP/IP "вне закона" и постепенно приведет к его вытеснению OSI-продуктами. Однако TCP/IP выстояли. Причин тому несколько, и главная из них заключается в том, что TCP/IP сумели набрать предусмотренную в OSI-продуктах функциональность еще до того, как последние появились и апробировались на рынке. Весьма характерно эту ситуацию описал Алан Рейнхольд (Alan Reinhold), управляющий разработкой коммуникационных продуктов в филиале IBM в Реэйлейхе (шт. Северная Каролина): "В 1988 г. мы считали, что TCP/IP должены увядать по мере того, как рынок пользователей будет мигрировать в направлении OSI-продуктов. Мы ошибались." В настоящее время нет смысла говорить о борьбе на истребление между этими направлениями в развитии открытых систем. Наиболее точно их отношения характеризует бытующее в коммуникационных кругах словечко coopetition (образованно от двух основ: cooperation - сотрудничество и competition - конкуренция).

Семейство протоколов TCP/IP

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

Протокол IP осуществляет передачу информации от узла к узлу сети в виде дискретных блоков - пакетов. При этом IP не несет ответственности за надежность доставки информации, целостность или сохранение порядка потока пакетов и, таким образом, не решает с необходимым для приложений качеством задачу передачи информации. Эту задачу решают два других протокола - TCP (Transfer Control Protocol, протокол управления передачей данных) и UDP (User Datagram Protocol, дейтаграммный протокол передачи данных) - которые, как говорят, "лежат" над IP (т. е. используют процедуры протокола IP для передачи информации, добавляя к ним свою дополнительную функциональность)..

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

Выше, над транспортными протоколами TCP или UDP, лежат протоколы, реализующие те или иные прикладные службы, такие как обмен файлами (File Transfer Protocol, FTP) и сообщениями электронной почты (Simple Mail Transfer Protocol, SMTP), терминальный доступ к удаленным серверам (Telnet).

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

Уровень hardware (оборудование) описывает ту или иную среду передачи данных.

На уровне network interface (сетевой интерфейс) лежит аппаратно-зависимое программное обеспечение, реализующее распространение информации на том или ином отрезке среды передачи данных. Отметим, что TCP/IP, изначально ориентированный на независимость от среды передачи, никаких ограничений "от себя" на программное обеспечение этих двух уровней не накладывает. Понятия "среда передачи данных" и "программное обеспечение сетевого интерфейса" могут на практике иметь различные по сложности и функциональности наполнения - это можут быть и простое модемное двухточечное звено, и представляющая сложную многоузловую коммуникационную структуру сеть X.25 или Frame Relay.

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

При этом, напомним, протокол IP не обеспечивает транспортную службу, в том смысле, что не гарантирует доставку пакетов, сохранение порядка и целостности потока пакетов и не различает логические объекты (процессы), порождающие поток информации. Это задачи других протоколов - TCP и UDP, относящихся к следующему, транспортному (transport) уровню.

Выше - на уровне application (прикладном) - лежат прикладные задачи, запрашивающие сервис у транспортного уровня.

Следует также обратить внимание на терминологию, традиционно используемую в литературе по TCP/IP для обозначения информационных объектов, распространяющихся между различными уровнями. Приложение передает транспортному уровню сообщение (message), имеющее сообразные данному приложению размер и семантику. Транспортный уровень "разрезает" это сообщение (если оно достаточно велико) на пакеты (packet), которые передаются межсетевому уровню (т. е. протоколу IP). Последний формирует свои IP-пакеты (их еще называют IP-дейтаграммами) и затем упаковывает их в формат, приемлемый для данной физической среды передачи информации. Эти, уже аппаратно-зависимые, пакеты в литературе именуют кадрами (frame).

Internet Рrotocol: основа мироздания TCP/IP

Архитектурная концепция интерсети

Декомпозиционная концепция протокола IP подкупающе проста и поучительна. Мир в ней представляется как множество значимых для нас компьютеров (обычно их называют хостами, host), подключенных к некоторой единой интерсети, внутренняя структура которой для нас как пользователей неважна, что и подчеркивается изображением этой интерсети в виде некоего расплывчатого облачка (рис. 2,а). Если же мы будем любознательны и заглянем внутрь этого облачка (рис. 2,б), то увидим, что оно состоит из маленьких облачков, называемых физическими сетями (physical networks), и соединяющих их маршрутизаторов (router). Физические сети не являются, строго говоря, носителями протокола IP. Это могут быть локальные сети, работающие под управлением некоторых аппаратно-зависимых протоколов (Ethernet, Token Ring), или коммуникационные системы произвольной физической природы (модемные коммутируемые или выделенные линии, сети X.25, Frame Relay, FDDI, PPP, ATM и практически все прочее, что только придет вам на ум). Все функции протокола IP исполняют хосты и маршрутизаторы.

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

Философия IP: негарантированная, дейтаграммная, максимально обеспеченная доставка информации

О протоколе IP говорят, что он обеспечивает негарантированную (unreliable) доставку информации в том смысле, что IP не обеспечивает 100%-ную вероятность доставки пакета. Последний может быть утерян, дуплицирован, задержан, доставлен с нарушением порядка, и при этом IP не только никого не уведомляет об этих явлениях, но и не имеет инструментов для их детектирования.

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

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

Адреса IP

Физические объекты (хосты, роутеры, подсети) в IP-сети идентифицируются при помощи имен, называемых IP-адресами. Следует впрочем, уточнить что объект, наделяемый IP-адресом, есть, скорее, сетевое соединение, нежели некоторое физическое устройство. Например, хост, соединенный с двумя сетями , имеет два IP-адреса, относящихся к каждой из сетей: сеть Net1 идентифицирует его по адресу a1, а сеть Net2 - по адресу a2.

IP-адреса представляют собой 32-битовые идентификаторы, структура которых оптимизирована для решения основной задачи протокола IP - маршрутизации. Обычно для удобства представления IP-адресов используется так называемое "цифровое написание" IP-адресов (dotted decimal notation), когда адрес записывается как десятичное представление 4 байт, разделенных точками, например 192.171.153.60.

Три главных класса IP-адресов

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

Все IP-адреса разделены на 5 классов, но практическое применение находят в основном три первых.

Класс A определен для сетей с огромным (от 65535 до 16 777 215) числом хостов. В адресе этого класса 7 бит отведены под поле идентификатора сети (NetID), а 24 бит - под поле идентификатора хоста (HostID). Адреса класса B используются для среднемасштабных сетей, в которых содержится от 256 до 65536 хостов; под поля NetID и HostID отводится 14 и 16 бит соответственно. И, наконец, в адресах класса C, предназначенных для сетей с числом хостов менее 256, под HostID отведено 8 бит и под NetID - 21 бит. Заметьте, что IP-адрес построен таким образом, чтобы поля NetID и HostID можно было бы выделить быстро. Эффективность маршрутизации, осуществляемой маршрутизаторами и основанной только на полях NetID, зависит от эффективности выделения этого поля.

Описанная семантика адресов поясняет, в частности, что IP-адрес идентифицирует сетевое соединение, а не хост: адрес а1 на рис. 3 будет содержать идентификатор сети Net1, а адрес a2 - идентификатор сети Net2.

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

IP-адресация поддерживает адреса, обращенные к множеству хостов и/или сетей. Среди таких адресов различают два класса: широковещательные (broadcast), обращенные "ко всем", и групповые (multicast), обращенные к заданному множеству объектов. Остроумная адресная нотация при этом основывается на заполнении адресных полей нулями (обращение к данному объекту, this) или единицами (обращение ко всем объектам, all).

Специальные IP-адреса, формируемые по этим правилам, показаны на рис. 5.

Адрес 1 является своего рода "пустышкой". Он может использоваться в инициализационной процедуре, когда рабочая станция не знает (или хочет согласовать) своего IP-адреса, и только как адрес отправителя, но никогда как адрес получателя пакета.

Адрес 2, в котором идентификатор сети (NetID) заполнен нулями, а идентификатор хоста (HostID) имеет некоторое осмысленное значение, есть адрес конкретного хоста в сети, из которой он получил пакет. Применение такого адреса наиболее уместно в том случае, когда хост-отправитель не знает идентификатора сети, в которой работает. (Такая ситуация возможна, например, при инициализации бездисковой рабочей станции, которая при включении в сеть вообще "ничего не знает" ни о сети, ни о себе.) Этот адрес используется только как адрес получателя и никогда как адрес отправителя.

Адрес 3, в котором поле NetID имеет некоторое значение, а поле HostID заполнено нулями, трактуется протоколом IP, как адрес некоторой сети (но ни одного из хостов данной сети, поскольку состоящий из нулей HostID запрещен).

Адрес 5, в котором идентификатор сети имеет осмысленное значение, а поле идентификатора хоста заполнено единицами называется прямым широковещательным адресом (direct broadcast address), обращенным ко всем хостам в данной подсети. Наряду с ним в качестве широковещательного применяется также локальный, или ограниченный адрес (limited, или local broadcast address), целиком заполненный единицами (адрес 4), полезный предположительно, когда идентификатор сети по каким-либо причинам неизвестен. Использование этого адреса не рекомендуется.

Наконец, адрес 6 - тестовый адрес (loopback address), в котором первый байт имеет значение 127, а прочее поле не специфицировано (обычно заполняется единицами). Он используется для задач отладки и тестирования, не является адресом никакой сети и маршрутизаторы никогда не обрабатывают его.

Групповые адреса

Групповой адрес (multicast address), в отличие от широковещательного, применяется при обращении к выделенной группе хостов (но не ко всем хостам) некоторой физической сети или группы сетей. В этом случае используются адреса класса D . Групповая адресация в TCP/IP регламентируется входящим составной частью в IP протоколом Internet Group Management Protocol (IGMP). Обсуждение логики этого протокола выходит далеко за пределы круга проблем, рассматриваемых в этой статье, поэтому мы ограничимся рассмотрением ряда внешних, в своем роде замечательных, черт групповой адресации в TCP/IP.

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

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

Групповые адреса назначаются NIC и разделяются на два класса: постоянные - для непрерывно существующих групп (так называемые well-known adresses, всем известные адреса) и временные - для организуемых на некоторый срок групп, которые существуют до тех пор, пока в группе сохраняется хотя бы один член (так называемые transient multicast groups, временные адресные группы).

Распространение групповых сообщений по интерсети ограничивается временем жизни (time-to-live) IP-пакета, о котором мы поговорим несколько позже.

Адресная администрация Internet

Как правило, NIC распределяет только адреса физических сетей (NetID), оставляя администрирование адресов хостов за системной администрацией ведомств, которым данные сети принадлежат. Речь в данном случае идет, конечно, о сетях, подключенных к Internet. Автономные корпоративные IP-сети могут самостоятельно решать задачи адресной администрации.

Проблема отражения IP-адресов на физические адреса устройств в физических сетях

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

Задача эта нетривиальна в силу существенных архитектурных различий между разными аппаратными реализациями. Например, IP-адрес должен однозначно определять сетевое соединение и в сетях X.25 или Token Ring, где используются конфигурируемые и достаточно короткие адресные поля, и в сетях Ethernet, где каждый сетевой адаптер имеет "вшитый" длинный 48-битовый серийный номер, который устанавливают производители оборудования под управлением IEEE (Institute for Electric and Electronic Engineers).

В общем виде задача определения физического адреса хоста А (Ра) по его IP-адресу (Ia) выглядит как вычисление некоторой функции Pa=f(Ia). Эту задачу решают два входящих в IP в виде составных частей протокола: ARP (Adress Resolution Protocol) и RARP (Reverse Adress Resolution Protocol).

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

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

Три источника, три составные части...

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

Пакет IP

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

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

Поле "длина заголовка" (HLEN, H[eader] LEN[gth]) дает значение длины заголовка пакета, измеренное в 32-битовых словах. Это поле предусматривает изменение длины заголовка и интерпретацию его расширения в соответствии с полями IP OPTIONS и PADDING.

Поле "тип сервиса" (SERVICE TYPE) структурировано (рис. 6,в).

Субполе "приоритет" (PRECEDENCE) поля SERVICE TYPE принимает восемь значений: от 0 (нормальный приоритет) до 7 (сетевое управление). Биты D,T,R этого поля ответственны за тип транспортировки, который "запрашивает" пакет. Установка этих битов в состояние "1" требует соответственно низкой задержки при передаче пакета (от Delay - задержка), высокой пропускной способности (Throughput) и высокой надежности (Reliability). Последние два бита поля SERVICE TYPE не используются. Нужно отметить, что это поле не всегда используется применяемыми маршрутизаторами, хотя представляет собой достаточно интересный механизм для оптимизации транспортной службы.

Поле "полная длина" (TOTAL LENGTH) заголовка пакета задает полную (включая заголовок и данные) длину пакета, измеренную в октетах (байтах). Как видно из рис. 6,б, полная длина пакета IP принципиально может достигать длины 65535 байт.

Протоколу IP, предназначенному, как это уже неоднократно отмечалось, для межсетевого взаимодействия, приходится ориентироваться на различия в реализациях физических сетей, одним из которых является ограничение на максимальную длину кадра, разрешенную в той или иной физической сети (maximum transfer unit, MTU). Поэтому протокол IP вынужден решать задачу, более свойственную транспортному протоколу, - разбивку больших пакетов на малые (и, наоборот, их сборку). Это требуется делать в тех случаях, когда на вход некоторой физической сети поступает пакет, превосходящий по длине MTU для данной сети. Такая операция в IP называется фрагментированием (fragmentation).

Фрагментирование осуществляется следующим образом. Блок данных исходного (большого) пакета разделяется таким образом, чтобы размер полученных фрагментов в сумме с длиной заголовка не превышал MTU для физической сети, в которую направляются фрагменты. При этом фрагменты упаковываются в пакеты, заголовок которых очень похож на заголовок исходного пакета. Чтобы понять, что данные пакеты содержат фрагменты одного большого пакета, и обеспечить его последующую сборку, производится установка специальных признаков в поле FLAGS, смещения, по которым разрезался исходный блок данных, помещаются в поле FRAGMENT OFFSET, а в поле IDENTIFICATION записывается один общий для всех фрагментов идентификатор, указывающий на принадлежность фрагментов к одному большому блоку данных.

Поле "время жизни" заголовка пакета (TIME TO LIVE) указывает время, в течении которого пакет должен существовать в сети. Хосты и маршрутизаторы, обрабатывающие данный пакет, производят декрементацию этого поля в период обработки и хранения этого пакета. Когда время жизни истекает, пакет уничтожается. При этом источник сообщения уведомляется о потере пакета. Наличие конечного времени жизни пакета обеспечивает, в частности, защиту от таких нежелательных событий, как передача пакета по циклическому маршруту, перегрузка сетей.

Назначение оставшихся полей следующее:

PROTOCOL (8 бит) - указывает протокол вышележащего уровня (скажем, TCP или UDP), которому предназначена информация, содержащаяся в поле данных пакета IP;

HEADER CHECKSUM (16 бит) - используется для контроля целостности заголовка пакета IP;

SOURCE ADDRESS (32 бита) - IP-адрес отправителя пакета;

DESTNATION ADDRESS (32 бита) - IP- адрес получателя пакета;

OPTIONS (изменяемая длина) - применяется для указания необязательных параметров IP, связанных, скажем с режимами безопасности или маршрутизации;

PADDING (изменяемая длина) - дополняет заголовок пакета таким образом, чтобы он составлял целое число 32-битовых слов.

Обработка конфликтных ситуаций: протокол ICMP

Если происходит "нештатное" событие, например потеря пакета, то для его обработки инициализируется специальный протокол, называемый Internet Control Message Protocol (ICMP). Он призван выяснить природу ошибки, сформировать сообщение о ней и передать его приложению, сформировавшему пакет. Протокол выполняет следующие основные функции:

* обмен тестовыми сообщениями для выяснения наличия и активности узлов сети;

* анализ достижимости узла-получателя, сброс пакетов, направляемых к недостижимым узлам;

* изменение маршрутов (redirect);

* уничтожение пакетов с истекшим временем жизни;

* синхронизация времени в узлах сети;

* управление потоком (путем регулирования частоты посылки пакетов узлами-источниками).

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

Протоколы маршрутизации в IP-сетях

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

Блок-схема протокольной машины, реализующей маршрутизацию, показана на рис. 7. Центральным элементом этой схемы является маршрутный вычислитель. Ему на вход поступают пакеты: от вышележащих протоколов (TCP, UDP), от протокола ICMP (например, контрольное сообщение о потере пакета), из входящей очереди IP, лежащей непосредственно "над" сетевым интерфейсом.

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

Различают статическую и динамическую маршрутизации. Статическая, основывающаяся на жестко заданных маршрутных таблицах, наиболее приемлема для хостов, работающих в небольших сетях, поскольку хост не должен тратить много "сил" на задачи маршрутизации. Часто маршрутную таблицу на нем конфигурируют как небольшой список, состоящий из хостов-соседей и маршрутизатора по умолчанию (default gateway), которому хост и отдает все пакеты, маршрутизация которых у него вызывает какие-либо затруднения. Эта же логика работает и на уровне маршрутизаторов: маршрутизатор, обслуживающий, например, локальную сеть, обязан знать все о своей локальной сети, однако информацией о внешних сетях он может и не владеть, обращаясь при необходимости к владеющим этой информацией внешним маршрутизаторам. Поэтому об этой интересной особенности сетей TCP/IP говорят, что в них осуществляется маршрутизация на основе неполной информации.

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

Прежде чем решать задачу маршрутизации как поиска оптимального пути доставки информации, следует установить, с кем можно связаться вообще. Эта задача становится весьма нетривиальной в силу разделения маршрутизаторов на базовые (core gateways), подключаемые непосредственно к магистральным каналам, и прочие, обслуживающие произвольным образом соединенные подсети, называемые в мире IP автономными системами (autonomous systems). Она не всегда решается просто, поскольку маршрутизация в сетях IP осуществляется на основе неполной информации и достижимость (reachability) некоторого узла не очевидна. Задачи распространения информации по достижимости узлов сети решают два протокола: Exterior Gateway Protocol (EPG) и пришедший ему на смену Border Gateway Protocol (BGP).

Для обеспечения маршрутизации мало знать, что данный узел достижим. Необходимо найти и по мере возможности оптимизировать путь к нему. Эту задачу в сетях TCP/IP решает ряд протоколов динамической маршрутизации, которые по внутренней логике можно разделить на два основных класса: основанные на подсчете промежуточных ретрансляций (hop count) и основанные на знании полной топологии сети (так называемые SPF-протоколы, от Shortest Path First).

Протоколы на основе подсчета промежуточных ретрансляций производят вычисление наиболее коротких путей распространения, определяя число промежуточных маршрутизаторов на пути распространения пакета от данного маршрутизатора до получателя. Это решение традиционно было первым, но его нельзя считать оптимальным: в его рамках не учитывается реальная пропускная способность линий связи, поэтому "быстрый" путь, например через три сегмента локальной сети Ethernet, будет считаться более длинным, чем "медленный" однопролетный путь через, скажем, последовательную линию. На основе подсчета ретрансляций работают такие распространенные протоколы динамической маршрутизации, как Gateway-to-Gateway Protocol (GGP), обеспечивающий обмен информацией между мощными базовыми маршрутизаторами (core, или exterior gateways), подключаемыми непосредственно к магистральным каналам сетей (backbones) или Routing Information Protocol (RIP), решающий ту же задачу для менее значимых маршрутизаторов (interior gateways).

К протоколам второго типа следует отнести протокол HELLO, вычисляющий оптимальный путь на основе измерения задержки распространения пакетов, и развитой протокол OSPF (Open SPF), который содержит ряд дополнительных возможностей, включая

* вычисление оптимальных маршрутов для различных типов сервиса;

* аутентификацию узлов на основе простой парольной системы;

* выравнивание нагрузки сети (load balancing);

* маршрутизацию в подсетях;

* минимизацию широковещательных вызовов для поиска информации;

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

***

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


распечатать статью




  
1 '1996
СОДЕРЖАНИЕ

колонка редактора

• Говорит и показывает Интервидение

открытые системы

• Мир TCP/IP. Internet Protocol

• Пятая волна компьютеризации: открытые сети общего пользования

• DCE. Скорее жива, чем мертва?

• Ява - остров восходящего солнца

• Проблемы маршрутизации трафика в Internet

• Удаленный доступ по PPP

• Будущее мультимедиа в Internet

• Интеграция Unix и Windows NT средствами NFS

• Internet: каково же будущее?

корпоративные сети

• Переход к коммутируемым сетям

• Загадка маршрутизатора

• Мост над бурным потоком

• Технология управления распределенными сетями

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

• Дисковые массивы RAID типа SCSI-to-SCSI

• Ленточные системы с автоматической сменой кассет

• Сетевые адаптеры Ethernet для шины PCI

услуги сетей связи

• Системы низкоорбитальных спутников

• Кодирование речи в цифровой телефонии

• Архитектура и функциональные модули сетей SDH

приложения клиент-сервер

• Однопользовательские СУРБД

• SQL Server 6.0: взаимодействие клиента с сервером

• Комплексная автоматизация производства на основе систем SCADA

защита данных

• А в вашей сети живут драконы?

• Испытание антивирусных программ для NetWare

новые продукты

• RAID без компромиссов, Эмулятор SunPC для DOS и Windows, Коммутатор LinkSwitch 1000 фирмы 3Com, Маршрутизаторы 7500 фирмы Cisco, MultiNet for Windows фирмы TGV



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх