Эта книга является одним из классических академических куpсов по техническим пpинципам pаботы Интеpнета. В доступной фоpме здесь описываются основы всех пpотоколов, фоpматы их сообщений и логика их pаботы. Понимание pяда пpоблем сетевой безопасности невозможно без знания изложенных в ней сведений.
Эта книга является одним из классических академических куpсов по техническим пpинципам pаботы Интеpнета. В доступной фоpме здесь описываются основы всех пpотоколов, фоpматы их сообщений и логика их pаботы. Понимание pяда пpоблем сетевой безопасности невозможно без знания изложенных в ней сведений.
Предыдущие главы рассмотрели архитектурные основы межсетевого обмена, описали, как шлюзы маршрутизируют дейтаграммы Интернета между собой и ГВМ, и представили механизмы, используемые для отображения IP-адресов в физические сетевые адреса. Эта глава рассмотрит общую структуру программного обеспечения, находящегося в шлюзах и ГВМ, которое решает задачу сетевого взаимодействия. Она опишет общий принцип разделения на уровни, покажет, как это разделение делает программное обеспечение Межсетевого Протокола легче для понимания и построения, и проследит путь дейтаграмм через протокольное программное обеспечение, который они проходят при передаче через интернет TCP/IP.
Мы уже говорили, что протоколы позволяют специфицировать или понимать взаимодействие, не зная детали сетевого оборудования конкретного производителя. Они являются для компьютерного взаимодействия тем же самым, чем являются языки программирования для вычислений. Теперь вам должно быть понятно, насколько верна эта аналогия. Как язык ассемблера, некоторые протоколы описывают взаимодействие по физической сети. Например, детали формата кадра Etherneta, политика доступа к сети, обработка ошибок в кадрах вместе составляют протокол, описывающий взаимодействие по Ethernetу. Аналогично, детали IP-адресов, формат дейтаграммы, понятие ненадежной доставки, без установления соединения составляют Межсетевой Протокол.
Сложные системы передачи данных не используют один протокол для решения всех задач передачи. Вместо этого, им требуется набор взаимодействующих протоколов, иногда называемый семейством протоколов или стеком протоколов. Чтобы понять почему это так, перечислим ошибки, которые могут возникнуть, когда машины взаимодействуют по сети данных.
Собранные воедино, эти проблемы подавляют. Трудно понять, как написать один протокол, которые бы обрабатывал их всех. По аналогии с языками программирования мы можем выбрать способ, как справиться с таким уровнем сложности. Трансляция программ делится на четыре концептуальных этапа, выделяемые по именам запускаемых программ: компилятор, ассемблер, компоновщик и загрузчик. Такое деление позволяет разработчику сосредотачиваться в каждый момент времени на одной проблеме, а программисту писать и тестировать каждый модуль ПО независимо от других.
Два последних наблюдения из нашей аналогии с языками программирования помогут вам уяснить организацию протоколов. Во-первых, ясно, что части транслируемого ПО должны согласовать формат данных, передаваемых между ними. Например, данные, передаваемые от компилятора ассемблеру, состоят из программы на языке ассемблера. Поэтому, мы видим, как процесс трансляции включает несколько языков программирования. Эта аналогия применима к коммуникационному ПО, где мы видим, что несколько протоколов определяют интерфейсы между модулями коммуникационного ПО. Во-вторых, четыре части транслятора образуют линейную последовательность, в которой выход компилятора становится входом для ассемблера, и т.д. Протокольное ПО также использует линейную последовательность.
Представляйте себе, что модули протокольного ПО на каждой машине как бы поставлены друг на друга и находятся на разных уровнях, как на рисунке 10.1 Каждый уровень отвечает за одну из частей большой проблемы.
----------------- -----------------
| ОТПРАВИТЕЛЬ | | ПОЛУЧАТЕЛЬ |
|---------------- |----------------
| Уровень n | | Уровень n |
|---------------| |---------------|
| .... | | .... |
|---------------| |---------------|
| Уровень 2 | | Уровень 2 |
|---------------| |---------------|
| Уровень 1 | | Уровень 1 |
|_______________| |_______________|
| ^
| |
---V--------------------------|---
| СЕТЬ |
----------------------------------
Рисунок 10.1 Концептуальная организация протокольного ПО в виде уровней.
Концептуально, посылка сообщения от прикладной программы на одной машине к прикладной программе на другой машине означает последовательную передачу сообщения вниз через соседние уровни протокольного ПО на машине получателя, передачу сообщения по сети и передачу сообщения вверх через соседние уровни протокольного ПО на машине получателя.
На практике, протокольное ПО гораздо более сложное, чем это может показаться на основании рисунка 10.1. Каждый уровень принимает решение о корректности сообщения и выбирает соответствующее действие на основании типа сообщения или адреса назначения. Например, один из уровней на принимающей машине должен решить, оставить сообщение или передать его дальше другой машине. Другой уровень должен решить, какая прикладная программа должна принять сообщение.
Чтобы понять разницу между концептуальной организацией протокольного ПО и деталями реализации, рассмотрим их сопоставление, показанное на рисунке 10.2. Концептуальная диаграмма на рисунке 10.2а показывает Межсетевой уровень между высокоуровневым протокольным уровнем и уровнем сетевого интерфейса. Реальная диаграмма на рисунке 10.2б показывает, что ПО IP может взаимодействовать с несколькими модулями протоколов высокого уровня и с несколькими сетевыми интерфейсами. Хотя диаграмма концептуального разделения протоколов на уровни не показывает все детали, она помогает объяснить базовые идеи. Например, рисунок 10.3 показывает уровни протокольного ПО, используемые сообщением, пересекающим три сети. Диаграмма показывает только уровни интерфейса с сетью и Межсетевого Протокола в шлюзах, так как только эти уровни требуются при получении, маршрутизации и отправке дейтаграмм. Мы понимаем, что любая машина, присоединенная к двум сетям, должна иметь два модуля интерфейса с сетью, хотя диаграмма концептуального разделения на уровни показывает только один уровень интерфейса с сетью в каждой машине.
---------------------- ------------ ------------ ------------
| уровень протоколов| |Протокол 1| |Протокол 2| |Протокол 3|
| высокого уровня | ---------\-- -----|------ --/---------
---------------------- \ | /
| уровень межсетево-| \ -----|------ /
| го протокола | |Модуль IP |
---------------------- / ------------\
| уровень интерфейса| / | \
| с сетью | ------------ ------------ ------------
---------------------- |Интерфейс1| |Интерфейс2| |Интерфейс3|
(а) ------------ ------------ ------------
(б)
Рисунок 10.2 Сопоставление разделения на концептуальные уровни (а) и реальной ситуации с организацией ПО, использующей несколько сетевых интерфейсов ниже IP и несколько протоколов выше него (б).
Как показывает рисунок 10.3, отправитель на исходной машине передает сообщение, которое уровень IP помещает в дейтаграмму и посылает по сети 1. На промежуточных машинах дейтаграмма передается вверх до уровня IP, который отправляет ее обратно вниз и из машины( в другую сеть). Только когда она достигает конечного назначения, машина заставляет IP выделить сообщение и передать его на верхние уровни протокольного ПО.
------------- ------------- ------------- -------------
|Отправитель| | | | | |Получатель |
| | | | | | | | ^ |
------V------ | | | | ------|------
| другие ...| | | | | | другие ...|
------------- ------------- ------------- -------------
| Уровень IP| |Уровень IP| | Уровень IP| | Уровень IP|
------------- ------------- ------------- -------------
| Интерфейс | | Интерфейс| | Интерфейс | | Интерфейс |
---------|--- -^-------|-- --^--------|- ---^---------
| | | | | |
--V------| -V------|- V------|--
/ \ / \ / \
| Сеть 1 | | Сеть 2 | | Сеть 3 |
\ / \ / \ /
---------- ---------- ----------
Рисунок 10.3 Путь сообщения, пересекающего Интернет от отправителя через две промежуточные машины к получателю. Промежуточные машины только посылают дейтаграмму до уровня IP в ПО.
Раз принято решение разделить задачу взаимодействия на подзадачи и организовать протокольное ПО в виде модулей, каждый из которых решает одну из подзадач, возникает вопрос: "какие возможности должен обеспечивать каждый модуль ?". На этот вопрос нелегко ответить по нескольким причинам. Во-первых, при заданном наборе целей и ограничений, приводящем к специфической задаче взаимодействия, можно выбрать организацию, оптимизирующую протокольное ПО для этой конкретной задачи. Во-вторых, даже при рассмотрении общих сервисов сетевого уровня, таких как надежная транспортировка, можно выбрать один из нескольких принципиально отличающихся друг от друга подходов для решения этой задачи. В-третьих, разработка сетевой( или межсетевой) архитектуры и организация протокольного ПО не связаны между собой; можно разрабатывать одно в отрыве от другого.
В этой области доминируют две идеи относительно разделения протоколов на уровни. Первая, основывающаяся на работе, проделанной Международной Организацией по Стандартизации(МОС), известной как Справочная Модель ВОС Взаимодействия Открытых Систем, часто называется моделью ВОС. Модель ВОС, содержащая семь концептуальных уровней, организована так, как показано на рисунке 10.4.
Уровень Возможности
---------------------------
7 | Прикладной |
| |
---------------------------
6 | Представительный |
| |
---------------------------
5 | Сеансовый |
| |
---------------------------
4 | Транспортный |
| |
---------------------------
3 | Сетевой |
| |
---------------------------
2 | Канальный |
| (аппаратный интерфейс) |
---------------------------
1 | Физический |
| |
---------------------------
Рисунок 10.4 Семиуровневая справочная модель ВОС для протокольного ПО.
Модель ВОС, созданная для описания протоколов одной сети, не содержит специального уровня для межсетевой маршрутизации, имеющегося в стеке протоколов TCP/IP.
Схема разделения на уровни ВОС, хотя и разрабатывалась как концептуальная модель, а не руководство для реализаций, является основой для нескольких реализаций протоколов. Среди протоколов, связанных с моделью ВОС, набор протоколов, известный как Х.25, является вероятно самым популярным и широко используемым. Х.25 был создан как рекомендация Международного Консультативного Комитета по Телефонии и Телеграфии( МККТТ), международной организации, вырабатывающей стандарты для международных телефонных служб. Х.25 используется сетями передачи данных общего пользования в Европе и США.
С точки зрения Х.25, сеть работает во-многом аналогично телефонной системе. Как и ARPANET, описанный в главе 2, сеть Х.25 предполагается состоящей из сложных коммутаторов пакетов, имеющих достаточную интеллектуальность, чтобы маршрутизировать пакеты. ГВМ не присоединены напрямую к каналам сети. Вместо этого каждый ГВМ присоединен к одному из коммутаторов пакетов, используя последовательную линию взаимодействия. Можно сказать и по-другому, то есть что соединение между пакетным коммутатором Х.25 и ГВМ - миниатюрная сеть, состоящая из одной последовательной линии. ГВМ должен использовать довольно сложную процедуру для передачи пакетов в сеть.
Самый широко используемый протокол уровня 2, имеющий название Высокоуровневое Взаимодействие по Каналу Данных, известен по его аббревиатуре - HDLC. Существует несколько версий HDLC, из которых самая последняя имеет название - HDLC/LAPB. Важно помнить, что успешная передача на уровне 2 означает, что кадр был передан сетевому коммутатору пакетов для доставки; она не гарантирует, что пакетный коммутатор примет пакет, или сможет переправить его для доставки.
Вторая основная модель разделения протоколов на уровни не была разработана комитетом по стандартам, а появилась в результате исследований, приведших к появлению стека протоколов TCP/IP. После небольшой доработки модель МОС может быть приспособлена для описания схемы деления на уровни в TCP/IP, но базовые предпосылки этих схем сильно различаются, что позволяет говорить об их различии.
На концептуальном уровне ПО TCP/IP организовано в виде 4 уровней, опирающихся на пятый уровень оборудования. Рисунок 10.5 показывает концептуальные уровни, а также форму, в которой передаются данные между ними.
Концептуальный уровень Объекты, передаваемые
между уровнями
-----------------
| Прикладной |
| |
----------------- <---------Сообщения или потоки
| Транспортный |
| |
----------------- <---------Пакеты транспортного
| Межсетевой | протокола
| |
----------------- <---------Дейтаграммы IP
| Интерфейс с |
| сетью |
----------------- <---------Кадры конкретной сети
. Оборудование .
. .
.................
Рисунок 10.5 Четыре конептуальных уровня ПО TCP/IP и форма объектов, передаваемых между ними. Уровень, называемый интерфейс с сетью, иногда называют уровень канала данных.
Существует два тонких и важных различия между схемой разделения на уровни TCP/IP и Х.25. Первое различие связано с надежностью, в то время как второе - с местонахождением интеллектуальных функций в системе.
Одно из основных различий между протоколами TCP/IP и Х.25 состоит в их подходах к обеспечению сервиса надежной пердачи данных. В модели Х.25 протокольное ПО обнаруживает и обрабатывает ошибки на всех уровнях. На канальном уровне сложные протоколы гарантируют, что передача между ГВМ и пакетным коммутатором, к которому он присоединен, будет корректной. К каждому передаваемому элементу данных присоединяется контрольная сумма, и получатель подтверждает каждый принятый кусок данных. Протокол канального уровня включает таймаут и алгоритм повторной передачи, защищающие от потери данных и обеспечивающие автоматическое восстановление после сбоев или рестартов оборудования.
Следующие уровни Х.25 обеспечивают свою надежность. На уровне 3 Х.25 также обеспечивает обнаружение ошибок и восстановление после них для пакетов, передаваемых по сети, используя контрольные суммы, а также технологии таймаута и повторной передачи. Наконец, уровень 4 должен обеспечивать межконцевую надежность, заставляя при этом место конечного назначения проверять доставку.
В отличие от этой схемы TCP/IP основывает свое разделение на уровни на том, что надежность - это межконцевая проблема. Философия архитектуры проста: создать интернет таким, чтобы он мог управляться с ожидаемой загрузкой, и позволить отдельным каналам или машинам терять данные или искажать их, не пытаясь исправлять ошибки. Фактически, большая часть ПО TCP/IP уровня интерфейса с сетью не обеспечивает надежности. Вместо этого, большинство ошибок обрабатывает транспортный уровень.
Освобождение уровня интерфейса от верификации делает ПО TCP/IP более легким для понимания и реализации. Промежуточные шлюзы могут отбрасывать дейтаграммы, ставшие испорченными из-за ошибок передачи. Они могут отбрасывать любые дейтаграммы, которые не могут быть доставлены. Они могут отбрасывать дейтаграммы, когда скорость их поступления превышает пропускную способность машины. Они могут посылать дейтаграммы по другим путям с меньшей или большей задержкой, не информируя об этом источник или назначение.
Наличие ненадежных каналов означает, что некоторые дейтаграммы не дойдут до назначения. Обнаружение и восстановление после потери дейтаграмм выполняется между источником и назначением, и поэтому называется межконцевой верификацией. Межконцевое ПО, находящееся на транспортном уровне, использует контрольные суммы, подтверждения и таймауты для управления передачей. Поэтому, в отличие от разделения на уровни в Х.25, ориентированного на соединения, ПО TCP/IP помещает большую часть управления надежностью на один уровень.
Другое различие между моделью Х.25 и TCP/IP появляется при определении местонахождения средств управления работой. Как правило, в сетях, использующих Х.25, подразумевается, что сеть - это утилита, обеспечивающая транспортное средство. Производитель, предоставляющий средство, управляет доступом к сети и следит за траффиком для учета работы пользователей. Поставщик сетевого сервиса решает такие проблемы, как маршрутизация и управление потоком внутренним образом, делая процесс передачи данных надежным. При таком подходе на долю ГВМ мало что остается. Короче говоря, сеть - это сложная, независимая система, к которой могут присоединяться относительно простые ГВМ; сами ГВМ мало участвуют в работе сети.
В отличие от этого, TCP/IP требует от ГВМ участия почти во всех сетевых протоколах. мы уже упомянули, что ГВМ активно учствуют в межконцевом обнаружении ошибок и восстановлении после них. Они также принимают участие в маршрутизации, так как они должны выбрать шлюз при посылке дейтаграммы, и они участвуют в управлении сетью, так как они должны обрабатывать управляющие сообщения ICMP. Поэтому, при сравнении с сетью Х.25, интернет TCP/IP может рассматриваться как относительно простая система доставки пакетов, к которой присоединены интеллектуальные ГВМ.
Независимо от конкретной используемой схемы разделения на уровни, или функций уровней, работа протоколов, разнесенных по уровням, основывается на одной фундаментальной идее. Эта идея, называемая принципом разделения на уровни, может быть описана следующим образом:
Протоколы, разнесенные по уровням, разрабатываются таким образом, что назначение на уровне N получает точно такой объект, который был послан отправителем на уровне N.
Принцип разделения протоколов на уровни объясняет, почему разделение на уровни - такя мощная идея. Она позволяет разработчику протоколов последовательно сосредотачивать свое внимание на одном из урвоней, не заботясь при этом о работе других уровней. Например, при создании приложения передачи файлов, разработчик думает только о двух копиях прикладной программы, функционирующих на двух машинах, концентрируется на сообщениях, которыми нужно обменяться при передаче файлов. Разработчик предполагает, что приложение на одной ГВМ принимает точно то, что ему посылает приложение на другой ГВМ.
Рисунок 10.6 иллюстрирует, как работает принцип разделения на уровни:
ГВМ А ГВМ В
----------------- -----------------
| Прикладной | | Прикладной |
| | идентичное | |
----------------- сообщение --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Транспортный | | Транспортный |
| | идентичный | |
----------------- пакет --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Межсетевой | | Межсетевой |
| | идентичная | |
----------------- дейтаграмма --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Интерфейс с | | Интерфейс с |
| сетью | идентичный | сетью |
------------\---- кадр --^--------------
\ <-------------------------->/
\ /
-V--------------------------/-
/ Физическая сеть /
/ /
------------------------------
Рисунок 10.6 Путь сообщения, который оно проходит от приложения на одной ГВМ до приложения на другой ГВМ. Уровень N на ГВМ В принимает точно такой же объект, который был послан уровнем N ГВМ А.
Наше определение принципа разделения на уровни несколько туманно, а иллюстрация на рисунке 10.6 упускает важный вопрос, так как она не делает различия между передачей от источника до конечного назначения и передачей через несколько сетей. Рисунок 10.7 иллюстрирует это различие, показывая путь сообщения, посланного прикладной программой на одной ГВМ к приложению на другой ГВМ через шлюз.
Как показывает рисунок, доставка сообщений использует два различных сетевых кадра: один для передачи между ГВМ А и шлюзом Ш, а другой - между шлюзом Ш и ГВМ В. Принцип разделения сети на уровни устанавливает, что кадр, доставляющийся к Ш, совпадает с кадром, посланным А. Но прикладной и транспортный уровни имеют дело с межконцевой пересылкой и разработаны так, чтобы ПО источника могло взаимодействовать с конечным назначением. Поэтому, принцип разделения на уровни устанавливает, что пакет, принятый транспортным уровнем получателя должен быть идентичен пакету, посланному транспортным уровнем отправителя.
ГВМ А ГВМ В
----------------- -----------------
| Прикладной | | Прикладной |
| | идентичное | |
----------------- сообщение --------^--------
| <------------------------------------------>|
-------V--------- --------|--------
| Транспортный | | Транспортный |
| | идентичный | |
----------------- пакет --------^--------
| <------------------------------------------>|
-------V--------- Шлюз Ш --------|--------
| Межсетевой | ----------------- | Межсетевой |
| | | Межсетевой | | |
----------------- | | --------^--------
| --^---------|---- |
-------V--------- | | --------|--------
| Интерфейс с | --|---------V---- | Интерфейс с |
| сетью | | Интерфейс с | | сетью |
---------|------- | сетью | -----^-----------
| ---^--------|---- |
-----V---------- | | ------------|----
/Физическая сеть/----/ \--->/Физическая сеть/
/ 1 / / 2 /
---------------- -----------------
Рисунок 10.7 Принцип разделения на уровни при использовании шлюза. Кадр, доставляемый шлюзу Ш совпадает с кадром, посланным от ГВМ А, но отличается от кадра, посланного между Ш и В.
Легко понять, что на верхних уровнях принцип разделения на уровни применим к межконцевым передачам, и что на самом нижнем уровне применим к передаче между двумя машинами.
Назад | Содержание | Вперед
Передача данных стала фундаментальной частью вычислений. Сети, разбросанные по всему миру, собирают данные о таких разных предметах, как атмосферные условия, производство продуктов и воздушных перевозках. Группы создают электронные справочные списки, которые позволяют им получать информацию, интересную всем. Любители обмениваются программами для их домашних компьютеров. В научном мире сети данных стали необходимы, так как они позволяют ученым посылать программы и данные на удаленные суперкомпьютеры для обработки, получать результаты и обмениваться научной информацией с коллегами.
К сожалению, большинство сетей являются независимыми сущностями, созданными для удовлетворения потребностей одной группы людей. Пользователи выбирают аппаратную технологию, подходящую для их коммуникационных проблем. Более важно то, что нельзя создать универсальную сеть на основе одной аппаратной технологии, так как нет такой сети, которая удовлетворила бы все потребности. Некоторым пользователям нужна высокоскоростная сеть, соединяющая их машины, но такие сети не могут быть расширены на большие расстояния. Другим нужна более медленная сеть, которая будет соединять машины, находящиеся на расстоянии тысяч километров друг от друга.
Недавно, тем не менее, появилась новая технология , которая сделала возможным взаимное соединение большого числа разделенных физических сетей и заставила их работать как одно единое целое. Эта новая технология, называющаяся межсетевым обменом(internetworking), приспосабливает друг к другу различные аппаратные технологии, лежащие в основе физических сетей, с помощью добавления как физических соединений сетей, так и нового набора соглашений. Технология межсетевого обмена скрывает детали сетевого оборудования и позволяет компьютерам взаимодействовать вне зависимости от типа их физических соединений.
Технология межсетевого обмена, описанная в книге, является примером Взаимодействия Открытых Систем. Они называются открытыми потому, что в отличие от конкретных коммуникационных систем, продаваемых тем или иным производителем, ее спецификации доступны всем. Поэтому любой может создать программное обеспечение, необходимое для взаимодействия в обьединенной сети. Более того, вся эта технология была разработана для того, чтобы упростить взаимодействие между машинами с различными аппаратными архитектурами, чтобы использовать почти любое оборудование сети с коммутацией пакетов, и чтобы позволить взаимодействие различных операционных систем.
Чтобы оценить значение межсетевой технологии, подумайте, как она повлияла на исследования. Представьте на минуту эффект взаимного соединения всех компьютеров, используемых учеными. Любой ученый может обменяться результатами эксперимента с любым другим ученым. Можно создать национальные центры данных, собирающие данные о природных явлениях и делающие их доступными для всех ученых. Компьютерные средства и программы, доступные в одном месте, могут использоваться учеными в других местах. В результате скорость, с которой осуществляются научные исследования, может резко возрасти. Короче говоря, изменения могут быть очень драматичными.
Правительственные агентства осознали важность и потенциал межсетевой технологии в будущем и стали финансировать исследования, которые сделали бы возможным создание национальной обьединенной сети. Эта книга рассматривает принципы и идеи, лежащие в основе ведущей межсетевой технологии, появившейся в результате проведения разработок, финансировавшихся агентством DARPA(Defense Advanced Research Projects Agency). Технология DARPA включает набор сетевых стандартов, описывающих детально процесс взаимодействия компьютеров, а также ряд соглашений при взаимодействии сетей и маршрутизации траффика. Официально называемый Связкой Межсетевых Протоколов TCP/IP (а в обыденной речи - TCP/IP по именам двух основных стандартов), он может использоваться для взаимодействия компьютеров с помощью неограниченного числа сетей. Например, некоторые корпорации используют TCP/IP для связи сетей внутри их корпорации, даже если корпорация не имеет связи с внешними сетями. Другие группы используют TCP/IP для связи удаленных друг от друга мест.
Хотя технология TCP/IP интересна сама по себе, она особенно хороша из-за своей жизнеспособности, которую она продемонстрировала. Она стала базовой технологией для большого сообщества сетей, которые связывают большинство исследовательских институтов, включая университетские, обьединенные или правительственные лаборатории. Национальный Научный Фонд(NSF), Министерство Энергетики(DOE), Министерство Обороны(DOD), Агентство по здравоохранению(HHS) и NASA взаимодействуют друг с другом, используя TCP/IP для соединения большого числа их исследовательских центров с центрами DARPA. Получившаяся сущность, известная как обьединенный Интернет, Интернет DARPA/NSF, Интернет TCP/IP, или просто Интернет, позволяет исследователям всех связанных институтов разделять информацию с коллегами по всей стране так же легко, как если бы они были в соседней комнате. Таким образом, Интернет продемонстрировал жизнеспособность технологии TCP/IP и показал, как можно обьединить большое количество разнообразных базовых сетевых технологий.
Большинство материалов в этой книге применимо к любому интернету, использующему TCP/IP, но некоторые главы посвящены специально обьединенному Интернету. Читатели, интересующиеся только технологией, должны четко различать реальную существующую архитектуру Интернета и гипотетический Интернет TCP/IP, который мог бы существовать. Тем не менее, будет ошибкой игнорировать секции, описывающие обьединенный Интернет полностью - сети многих корпораций уже догнали по сложности Интернет десятилетней давности, и многие проблемы, с которыми они сталкиваются сейчас, уже давно решены в обьединенном Интернете.
Нельзя говорить о технических деталях, лежащих в основе Интернета, не понимая средств, которые он обеспечивает. Эта глава кратко рассматривает средства Интернета, более подробно останавливаясь на тех средствах, которыми пользуется большинство пользователей, и откладывая до следующих глав рассмотрение вопроса о том, как компьютеры присоединяются к Интернету и как реализуются эти средства.
Большая часть описания средств будет посвящена стандартам, называемым протоколами. Протоколы, такие как TCP и IP, дают формулы для передачи сообщений, описывают детали форматов сообщений и указывают, как обрабатывать ошибки. Самое важное то, что они позволяют нам рассматривать стандарты взаимодействия вне зависимости от того, на оборудовании какого производителя, они реализуются. По существу, протоколы являются для коммуникации тем, чем является языки программирования для вычислений. Язык программирования позволяет описать или понять вычисления, не зная системы команд конкретного ЦП. Аналогично, коммуникационный протокол позволяет нам описать или понять процесс передачи данных, не зная на каком оборудовании этот процесс выполняется.
Скрытие низкоуровневых деталей взаимодействия помогает улучшить производительность. Во-первых, программистам, работающим с высокоуровневыми протокольными абстракциями, не нужно знать или помнить множество деталей о конкретных параметрах оборудования. Они могут быстро создавать новые программы. Во-вторых, так как программы, разработанные, используя высокоуровневые абстракции, не ограничены архитектурой конкретной машины или конкретного сетевого оборудования, их не надо изменять при замене машины или изменении конфигурации. В-третьих, так как прикладные программы, построенные, используя высокоуровневые протоколы, независимы от используемого оборудования, они могут обеспечивать прямое взаимодействие различных машин. Программистам не нужно писать специальные версии прикладных программ для перемещения и трансляции данных для всех возможных пар типов машин. Мы увидим, что все сетевые средства описываются протоколами.
Следующие секции рассмотрят протоколы, используемые для описания средств прикладного уровня, а также протоколы, используемые при определении сетевых средств. Следующие главы опишут каждый из этих протоколов более детально.
С точки зрения пользователя, Интернет TCP/IP является набором прикладных программ, использующих сеть для выполнения полезных коммуникационных задач. Мы будем использовать термин взаимная работоспособность(interoperability) для описания способности различных вычислительных систем взаимодействовать при решении вычислительных задач. Мы утверждаем, что прикладные программы Интернета показывают высокую степень взаимной работоспособности. Большинство пользователей, которые пользуются Интернетом, делают это, просто запуская прикладные программы , не понимая при этом технологии TCP/IP, структуры Интернета, и даже не зная пути, который проходят данные до назначения; они полагаются на то, что прикладные программы сами разберутся с этими деталями. Только программисты, пишущие такие прикладные программы, смотрят на Интернет как на сеть и понимают детали этой технологии.
Самые популярные и широко распространенные прикладные средства Интернета включают:
Мы вернемся к каждому из этих приложений позднее, чтобы рассмотреть его более детально. Мы увидим, как они используют базовые протоколы TCP/IP и почему наличие стандартов прикладных протоколов помогло удостовериться, что они широко распространены.
Программист, который пишет прикладные программы, использующие протоколы TCP/IP, имеет совершенно другое представление об Интернете, чем пользователь, который просто запускает прикладные программы, такие как электронная почта. На сетевом уровне Интернет предоставляет два основных типа сервиса, который используют прикладные программы. И хотя на данном этапе несущественно понимание деталей этих средств, их нельзя опустить при любом обзоре TCP/IP:
Много сетей обеспечивает базовые средства, аналогичные описанным выше, поэтому кое-кто может удивиться:"Чем же отличаются средства TCP/IP от других?". Основными отличиями являются:
Следующие главы рассмотрят в деталях средства, которые предлагаются программисту, а также большинство стандартов прикладных протоколов.
Частью того, что делает Интернет столь замечательным, является почти повсеместное его использование, а также его размеры и темпы роста обьединенного Интернета. DARPA начала работы в направлении разработки межсетевой технологии в середине 70-х, но архитектура и протоколы приняли форму, в которой они известны сейчас, лишь в 1977-1979 годах. В это время DARPA была известна как основное агентство, финансирующее исследования в области сетей с коммутацией пакетов, и внедрила множество новшеств в этой области в хорошо известную ARPANET. ARPANET использовала обычные выделенные линии точка-точка для соединения компьютеров, но DARPA также финансировала использование коммутации пакетов в радиосетях и спутниковых линиях связи. По существу растущее разнообразие аппаратных сетевых технологий вынудило DARPA изучить межсетевое взаимодействие и продвинуться по направлению к обьединенной сети.
Доступность результатов исследований, финансировавшихся DARPA, привлекла внимание нескольких исследовательских групп, особенно тех исследователей, кто уже имел опыт использования пакетной коммутации в ARPANET. DARPA собирало неформальные встречи исследователей для обмена идеями и обсуждения результатов экспериментов. С 1979 года в проект TCP/IP включилось так много исследователей, что DARPA образовало неформальный комитет для координации и управления разработкой протоколов и архитектур развивающегося обьединенного Интернета. Названная Группа по Конфигурации и Управлению Интернетом(ICCB), эта группа регулярно собиралась до 1983 года, когда она была реорганизована.
Обьединенный Интернет начал существовать с 1980 года, когда DARPA начала устанавливать на машинах, присоединенных к ее исследовательской сети, новый протоколы TCP/IP. ARPANET вскоре после создания стал магистральной сетью нового Интернета и был использован для большинства из ранних экспериментов с TCP/IP. Переход к технологии Интернета был завершен в январе 1983 года, когда секретариат МО США установил, что все компьютеры, присоединенные к глобальным сетям, используют TCP/IP. В это же самое время Оборонное Коммуникационное Агентство(DCA) разделило ARPANET на две отдельные сети, одна для дальнейших исследований и одна для военной связи. За исследовательской сетью осталось имя ARPANET, а военная часть, которая была несколько больше, получила название MILNET.
Для того чтобы заставить исследователей в университетах использовать новые протоколы, DARPA стала продавать их реализацию по низкой цене. В это время большинство университетских факультетов компьютерных наук использовали версию операционной системы UNIX, разработанную в программном отделении Берклиевского Университета в Калифорнии, чаще называемую Berkeley UNIX или BSD UNIX. Финансировав создание фирмой Bolt Beranek and NewMan, Inc. (BBN) реализации протоколов TCP/IP для UNIX и финансировав интеграцию этих протоколов в программные продукты, производимые отделением в Berkeley, DARPA смогла организовать взаимодействие с 90% всех компьютерных факультетов университетов. Новое программное обеспечение с протоколами появилось вовремя, так как многие факультеты сразу же приобретали еще компьютеры и соединяли их как локальные сети. Факультетам требовались протоколы взаимодействия, а других протоколов в то время не было в общем пользовании.
Берклиевское программное отделение стало популярным, так как оно предлагало не только базовые протоколы TCP/IP. Помимо стандартных прикладных программ TCP/IP, Беркли предлагало набор утилит для работы с сетью, которые напоминали средства UNIX, используемые на одной машине. Главное преимущество утилит Беркли заключалось в их сходстве со стандартным UNIXом. Например, опытный пользователь UNIX может быстро научиться пользоваться утилитой копирования удаленных файлов Беркли(rcp), так как он ведет себя точно так, как утилита копирования файлов в UNIX, за исключением того, что она позволяет пользователям копировать файлы на удаленную машину или с нее.
Помимо набора служебных программ UNIX Беркли обеспечивает новую абстракцию операционной системы известную как порт(socket), которая позволяет прикладным программам получать доступ к коммуникационным протоколам. Являясь обобщением механизма UNIX для ввода-вывода, порт имеет опции для нескольких типов сетевых протоколов помимо TCP/IP. Ее принципы стали обсуждаться со времени ее разработки, и многие разработчики операционных систем предложили альтернативные варианты. Независимо от своих достоинств, введение абстракции порта было важным, так как позволяло программистам использовать протоколы TCP/IP с минимумом затрат. Поэтому, это стимулировало разработчиков экспериментировать с TCP/IP.
Успех технологии TCP/IP и Интернета в университетской среде вынудил другие группы тоже использовать его. Учитывая, что сетевое взаимодействие вскоре станет важной частью научных исследований, NSF принял активное участие в расширении Интернета TCP/IP среди ученых. Начиная с 1985 года, он начал претворять в жизнь программу создания сетей на основе его шести суперкомпьютерных центров. В 1986 он расширил деятельность в этом направлении, начав финансировать новую глобальную магистральную сеть, названную NSFNET, которая впоследствии связала все суперкомпьютерные центры между собой и ARPANET. Наконец, в 1986 NSF начал частично финансировать многие региональные сети, каждая из которых сейчас соединяет основные научно-исследовательские центры в этом районе. Все сети, финансировавшиеся NSF, используют протоколы TCP/IP, и все являются частью обьединенного Интернета.
За семь лет после своего создания Интернет обьединил сотни индивидуальных сетей, размещенных в США и Европе. Он соединил почти 20000 компьютеров в университетах, правительственных и частных исследовательских лабораториях. Как размер, так и использование Интернета продолжают расти быстрее, чем предполагалось. К концу 1987 года было установлено, что его рост достиг 15% в месяц и оставался таким последние два года. В 1990 году обьединенный Интернет включал более 3000 активных сетей и более чем 200000 компьютеров.
Использование протоколов TCP/IP и рост Интернета не ограничивались проектами, финансирующимися правительством. Основные компьютерные корпорации присоединилось к Интернету, так же как и множество других больших корпораций, включая: нефтяные компании, автомобильные концерны, электронные фирмы и телефонные компании. Вдобавок, многие компании используют протоколы TCP/IP в своих внутренних сетях, даже если они и не присоединены к обьединенному Интернету.
Быстрое расширение привело к проблемам диапазонов, непредусмотренным в исходном проекте, и заставило разработчиков найти технологии для управления большими, распределенными ресурсами. В исходном проекте, например, имена и адреса всех компьютеров, присоединенных к Интернету, хранились в одном файле, который редактировался вручную и затем распространялся по всему Интернету. Но в середине 1980 года стало ясно, что центральная база данных неэффективна. Во-первых, запросы на обновление файла скоро должны были превысить возможности людей, обрабатывавших их. Во-вторых, даже если существовал корректный центральный файл, не хватало пропускной способности сети, чтобы позволить либо частое распределение его по всем местам, либо оперативный доступ к нему из каждого места.
Были разработаны новые протоколы и стала использоваться система имен по всему обьединенному Интернету, которая позволяла любому пользователю автоматически определять адрес удаленной машины по ее имени. Известный как Доменная Система Имен, этот механизм основывается на машинах, называемых серверами имен, отвечающих на запросы об именах. Нет одной машины, содержащей всю базу данных об именах. Вместо этого, данные распределены по нескольким машинам, которые используют протоколы TCP/IP для связи между собой при ответе на запросы.
Так как связка протоколов TCP/IP не была разработана каким-либо производителем или известным профессиональным обществом, естественно задать вопрос:"кто определяет направления развития и решает, когда протоколы становятся стандартами?". Ответом является группа, известная как Группа Активности Интернета(IAB). IAB определяет главное направление разработок на основе протоколов TCP/IP , координирует большинство их и управляет эволюцией обьединенного Интернета. Она решает, какие протоколы являются требуемой частью связки TCP/IP и определяет официальную политику.
Образованная в 1983 году, когда DARPA реорганизовало ICCB, IAB унаследовала много от своих предшественников. Ее начальными целями было стимулировать обмен идеями между людьми, вовлеченными в исследования, связанные с TCP/IP и Интернетом, и держать исследователей в курсе общих целей. После первых шести лет существования IAB из исследовательской группы DARPA превратился в независимую организацию. За эти годы каждый член IAB побывал председателем Целевых Сил Интернета(ITF), отвечая за исследование проблемы или ряда вопросов, представляющих интерес. IAB состояло из приблизительно десяти целевых сил с задачами от исследования, как траффик различных приложений влияет на Интернет, до текущих инженерных проблем Интернета. IAB собиралась несколько раз в год для заслушивания отчетов всех целевых сил, краткого обзора и пересмотра технических направлений, обсуждения политики и обмена информацией с представителями других агентств, таких как DARPA и NSF, которые финансировали работу Интернета и исследования для него.
Председатель IAB имел звание Архитектор Интернета и отвечал за предложение направлений технического развития и координацию работы различных целевых сил. Председатель IAB создавал новые целевые силы по совету IAB и также представлял IAB перед другими организациями.
Новички в TCP/IP иногда удивляются, узнав, что IAB не имел большого бюджета; хотя он и определял направления, он не финансировал большую часть исследований и инженерных разработок. Вместо этого, добровольцы сами выполняли большую часть работы. Члены IAB отвечали за прием добровольцев для работы их в подчиненных им целевых силах, за созыв встреч целевых сил, и за отчеты о работе перед IAB. Обычно, добровольцы появлялись из исследовательского сообщества или коммерческих организаций, использовавших TCP/IP. Активные исследователи принимали участие в целевых силах Интернета по двум причинам. Во-первых, работа в целевых силах обеспечивала возможность узнать новое об исследовательских проблемах. Во-вторых, так как новые идеи и решения проблем выдвигаемые и проверяемые целевыми силами, часто становились частью технологии Интернета, члены понимали, что их работа напрямую влияет на эту область.
Начиная с лета 1989 года, как технология TCP/IP, так и обьединенный Интернет из исследовательского проекта выросли в средства производства, которыми пользовались тысячи людей в своих каждодневных делах. Больше нельзя было реализовать новые идеи, установив ночью новое программное обеспечение на нескольких машинах. Теперь уже сотни коммерческих компаний, распространявших продукты TCP/IP, определяли, будут ли их продукты взаимно работоспособны, решая вопрос о внесении изменений в их программы.
Исследователи, разрабатывавшие начальные спецификации и тестировавшие новые идеи в лабораториях, больше не могли рассчитывать на быстрое внедрение и использование своих идей. По иронии судьбы исследователи, проектировавшие TCP/IP и наблюдавшие за его развитием, оказались побеждены коммерческим успехом их детища. Коротко говоря, TCP/IP стал успешной, производительной технологией и теперь уже рынок стал управлять его развитием.
Поэтому IAB был реорганизован летом 1989 года для приведения в соответствие с новой политической и коммерческой реальностью TCP/IP и обьединенного Интернета. Председательство изменилось. Исследователи были переведены из IAB во вспомогательную группу, и был создан новый IAB, для того чтобы включать представителей более широкого сообщества.
Помимо самой IAB организация включает две основные группы: Исследовательские Целевые силы Интернета(IRTF) и Инженерные Целевые Силы Интернета(IETF).
Как это следует из ее имени, IETF концентрируется на оперативных и тактических инженерных проблемах. IETF существовала и в старой структуре IAB, и ее успех явился одной из причин реорганизации. В отличие от большинства целевых сил IAB, которые были ограничены несколькими людьми, концентрировавшимися на одной конкретной проблеме, IETF разросся и стал включать сотни активных членов, работавших над многими проблемами параллельно. До реорганизации IETF был разделен на 20 рабочих групп, каждая из которых работала над конкретной проблемой. Рабочие группы собирались на свои встречи для выработки решений проблем. Кроме того, весь IETF собирался регулярно, чтобы заслушивать отчеты рабочих групп и обсуждать предлагаемые изменения или добавления к технологии TCP/IP. Проводимые обычно три раза в год, встречи всей IETF собирали сотни участников и зрителей. IETF стал слишком большим, чтобы им управлял один председатель.
IETF сохранился в реорганизованной структуре IAB, но был разделен на восемь областей, каждая из которых имела своего собственного управляющего. Председатель IETF и восемь управляющих областями составляют Руководящую Инженерную Группу Интернета (IESG), члены которой ответственны за координацию всех проектов рабочих групп IETF.
Так как IETF был широко известен по всему Интернету, и так как его встречи получили широкое одобрение, имя IETF было сохранено при реорганизации и все еще обозначает эту группу целиком, включая председателя, управляющих областями, и всех членов рабочих групп. По аналогичным причинам было оставлено имя "рабочая группа IETF".
Созданные при реорганизации, Исследовательские Целевые Силы Интернета получили такое имя как исследовательское дополнение к IETF. IRTF координирует работы исследователей, связанные с протоколами TCP/IP и архитектурой Интернета в целом. Как и IETF, IRTF имеет небольшую группу, называемую Руководящей Исследовательской Группой Интернета или IRSG, которая устанавливает приоритеты и координирует работы исследователей. В отличие от IETF, IRTF, тем не менее, в настоящее время гораздо меньше по размерам. Каждый член IRSG набирает добровольцев в Исследовательские Группы Интернета, аналогичные рабочим группам IETF; IRTF не поделен на области.
Мы уже говорили, что нет ни производителей, ни профессиональных обществ, владеющих технологией TCP/IP. Поэтому, документацию на протоколы, стандарты, и политику нельзя получить от производителя. Вместо этого, DCA финансирует группу в SRI International, которая получает и распространяет информацию о TCP/IP и обьединенном Интернете. Известная, как Сетевой Информационный Центр ил просто NIC, эта группа управляет многими административными вопросами Интернета помимо распространения документации.
Вся документация о работах в Интернете, предложениях о новых или переработанных протоколах, и стандартах протоколов TCP/IP появляется в виде серии технических отчетов, называемых Request For Comments или RFC(буквальный перевод приблизительно такой - Требуются Комментарии).(Ранние версии RFC были известны как черновые проекты Интернета). RFC могут быть маленькими или большими, могут описывать фундаментальные концепции или детали частного вопроса, и могут быть стандартами или просто предложениями новых протоколов. Редактор RFC называется Делегированным Архитектором Интернета, и является членом IAB.
Пока RFC редактируются, на них не ссылаются так, как это делается с исследовательскими академическими статьями. Также, некоторые отчеты, имеющие отношение к Интернету, уже публиковались в более ранних, параллельных сериях отчетов, названных Инженерными Заметками об Интернете или IEN. Хотя серии IEN более не используются, не все IEN были опубликованы в RFC. Ссылки на IEN и RFC разбросаны по всей книге.
Обе серии RFC и IEN нумеровались последовательно в хронологическом порядке написания. Каждому новому или переработанному RFC назначался новый номер, поэтому читателям нужно быть уверенным в том, что они получили версию документа с наибольшим номером; индекс поможет найти нужную версию.
NIC распространяет RFC и IEN по всему сообществу. Вы можете получить RFC от NIC, послав письмо по обычной почте,электронной почте или напрямую связавшись с ним по Интернету, используя программу передачи файлов. Спросите эксперта по локальным сетям, как получить RFC из вашего места или посмотрите приложение 1для дальнейших инструкций о том, как получить их.
Читатели, знакомые с сетями передачи данных, понимают, что существует множество стандартов протоколов коммуникации. Многие из них предшествовали Интернету, поэтому возникает вопрос:"Почему разработчики Интернета придумали новые протоколы, когда уже существует так много международных стандартов?". Ответ сложен, но ниже приведена простая максима:
Используйте существующие стандартные протоколы до тех пор, пока эти стандарты применимы; придумывайте новые протоколы только тогда, когда существующие стандарты неэффективны, но приготовьтесь перейти на международные стандарты, когда они станут доступны и обеспечат такие же возможности.
Поэтому, связка протоколов TCP/IP не игнорировала международных стандартов. Она появилась просто потому, что существующие стандарты не удовлетворяли потребностям. Философия использования стандартов, когда они появляются, также означает, что когда появятся международные стандарты и обеспечат ту же самую взаимную работоспособность, что и TCP/IP, Интернет перейдет с TCP/IP на эти новые стандарты. Эти идеи согласуются с политикой федерального правительства, которое приняло Профиль Открытых Систем, который описывает использование межсетевой технологии МОС везде, где эта технология обеспечивает возможности, эквивалентные TCP/IP.
Как технология TCP/IP, так и Интернет продолжают развиваться. Разрабатываются новые протоколы; пересматриваются старые. NSF значительно усложнила систему, введя свою магистральную сеть, несколько региональных сетей, и сотни университетских сетей. Другие группы также продолжают присоединяться к Интернету. Самое значительное изменение произошло не из-за присоединения дополнительных сетей, а из-за дополнительного траффика. Физики, химики, и астрономы работают и обмениваются обьемами данных гораздо большими, чем исследователи в компьютерных науках, составляющие большую часть пользователей траффика раннего Интернета. Эти новые ученые привели к значительному увеличению загрузки Интернета, когда они начали использовать его, и загрузка постоянно увеличивалась по мере того, как они все активнее использовали его.
Чтобы приспособиться к росту траффика, пропускная способность магистральной сети NSFNET была увеличена вдвое, приведя к тому, что текущая пропускная способность приблизительно в 28 раз больше, чем первоначальная; планируется еще одно увеличение, чтобы довести этот коэффициент до 30, в конце 1990 года. На настоящий момент трудно предсказать, когда исчезнет необходимость дополнительного повышения пропускной способности.
Рост потребностей в сетевом обмене не был неожиданным. Компьютерная индустрия получила большое удовольствие от постоянных требований на увеличение вычислительной мощности и большего обьема памяти для данных в течение долгих лет. Пользователи только начали понимать, как использовать сети. В будущем мы можем ожидать постоянное увеличение потребностей во взаимодействии. Поэтому потребуются технологии взаимодействия с большей пропускной способностью, чтобы приспособиться к этому росту.
Рисунок 1.2 обобщает расширение Интернета и иллюстрирует важную составляющую роста: изменение в сложности, возникшее из-за того, что несколько автономных групп являются частями обьединенного Интернета. Исходные проекты для многих подсистем предполагали централизованное управление. Потребовалось много усилий, чтобы доработать эти проекты для работы при децентрализованном управлении.
| Число сетей | Число компьютеров | Число управляющих | |
|---|---|---|---|
| 1980 | 10 | 10**2 | 1 |
| 1990 | 10**3 | 10**5 | 10 |
| 1995 | 10**5 | 10**10 | 100 |
Рисунок 1.2 Рост обьединенного Интернета. Помимо увеличения траффика из-за увеличения размера, Интернет столкнулся с сложностью, явившейся результатом децентрализованного управления как при разработке, так и при работе.
Федеральный Сетевой Совет(FNC) служит для координации деятельности федеральных агентств, финансирующих исследования или разработки в области TCP/IP и Интернета. FNC состоит из представителей DARPA, NSF, NASA, DOE, DOD и HHS. Члены FNC принимают участие во встречах IAB и помогают определять приоритеты в исследовательских и инженерных проектах Интернета.
Учитывая увеличившиеся потребности своих агентств и общенациональную заинтересованность в высокоскоростной вычислительной сети, FNC вместе с лидерами этого технического сообщества выработал план преобразования Интернета в Национальную Исследовательскую и Образовательную Сеть(NREN). В соответствии с этим планом, NREN будет расширяться таким образом, чтобы в конечном счете соединить все образовательные институты и исследовательские лаборатории. Для этого потребуются более высокоскоростные коммуникационные технологии, а также переход от финансируемых федеральным правительством магистральных сетей к средствам, работающим на коммерческой основе. FNC будет использовать федеральные исследовательские фонды для стимуляции исследований и разработки требуемых технологий.
Эта книга организована в виде двух томов. Том 1 содержит описание технологии TCP/IP, приложений, которые используют ее и архитектуры обьединенного Интернета. Он рассматривает основы протоколов, таких как TCP и IP, и показывает, как они объединяются. Помимо всего этого, он описывает общие принципы базовых сетевых протоколов и объясняет, почему протоколы TCP/IP так легко адаптируются ко многим базовым технологиям физических сетей. Том 2 рассматривает детально внутренние детали протоколов TCP/IP и показывает, как программисты используют их. Он рассматривает интерфейс между программами и протоколами и показывает, как создавать и управлять обьединенными сетями корпорации.
Итак, мы уже рассказали о технологии TCP/IP и Интернете в общих чертах, обобщив имеющиеся средства и историю его развития. Следующая глава дают краткий обзор типов сетевого оборудования, используемого в Интернете. Их цель - не выделить нюансы оборудования конкретного производителя, а подчеркнуть особенности каждой технологии, которые имеют большое значение для архитектуры Интернета. Следующие главы углубляются в протоколы и Интернет, преследуя три цели: они исследуют общие понятия и дают обзор модели архитектуры Интернета, они изучают детали протоколов TCP/IP и они знакомят со стандартами средств верхнего уровня, такими как электронная почта и электронная передача файлов. Главы с 3 по 12 дают обзор фундаментальных принципов и описывают сетевое программное обеспечение, имеющейся на любой машине, использующей TCP/IP. Последующие главы описывают средства, которые объединяют группы машин, включая распространение информации о маршрутизации, разрешение имен и приложения, такие как электронная почта.
За текстом идет несколько приложений. Первое приложение содержит руководство по RFC. Оно дополняет описание RFC, данное в этой главе, и дает примеры того, что можно найти в RFC. Оно детально описывает, как получить RFC из NIC с помощью электронной почты, обычной почты, и передачи файлов. Наконец, так как индекс RFC приводится в хронологическом порядке, оно представляет список RFC, организованный по разделам для удобства начинающих при поиске RFC, относящегося к данному вопросу.
Второе приложение содержит список в алфавитном порядке терминов и аббревиатур, используемых в литературе и книге. Так как новички часто считают новую терминологию подавляющей и трудной для запоминания, им будет удобнее использовать список в алфавитном порядке вместо просмотра уже прочитанного текста.
Наконец, третье приложение, задуманное как справочник, содержит список официальных протоколов Интернета. Оно включает описание терминологии IAB для определения различий между "рекомендуемыми" и "требуемыми" протоколами, а также список самих протоколов.
Обьединенная сеть состоит из набора связанных сетей, которые взаимодействуют как единое целое. Главным преимуществом Интернета является то, что он обеспечивает универсальное взаимное соединение, позволяя в это же время отдельным группам использовать любое сетевое оборудование, лучше всего подходящее для их целей. Мы рассмотрим принципы, лежащие в основе межсетевого взаимодействия в общем и детали межсетевой связки протоколов в частности. Мы также рассмотрим, как межсетевые протоколы используются в Интернете. Наша демонстрационная технология, названная TCP/IP по имени двух основных протоколов, была разработана DARPA. Она обеспечивает основу объединенного Интернета, большой, работающей объединенной сети, которая соединяет большинство научно-исследовательских институтов, включая многие университетские, правительственные лаборатории. Обьединенный Интернет быстро расширяется и продолжает поддерживаться DARPA, NSF, DOE, NASA и другими правительственными агентствами.
1.1 Изучите прикладные программы на вашей машине, использующие TCP/IP
1.2 Установите, соединена ли ваша машина с объединенным Интернетом
Назад | Содержание | Вперед
Предыдущие главы описывали интеpнет TCP/IP, позволяющий обмениваться дейтаграммами между хост-компьютерами, где каждая дейтаграмма пpи пересылке чеpез сети маpшpутизиpуется на основе IP-адреса места назначения. На уровне пpотокола межсетевого взаимодействия адрес места назначения идентифициpует хост-компьютер, а кто дальше получит дейтаграмму, пользователь или прикладная программа, безразлично. Эта глава дополняет описание стека протоколов TCP/IP и описывает механизм, котоpый позволяет различать несколько получателей на данном хост-компьютере, позволяя нескольким работающим на одном компьютере программам посылать и получать дейтаграммы независимо дpуг от дpуга.
Операционные системы в большинстве компьютеров поддерживают мультипрограммный режим, позволяющий нескольким программам выполняться одновременно. Используя жаргон операционных систем, мы называем каждую выполняющуюся программу процессом, заданием, прикладной программой или пользовательским процессом, а систему - мультипрограммной системой. Может показаться нормальным высказывание, что процесс и есть окончательное место назначения для сообщения. Однако сказать, что отдельный процесс на отдельной машине - окончательное место назначения для датаграммы, было бы несколько ошибочно. Во-первых, так как процессы создаются и завеpшаются динамически, отправитель редко имеет информацию, достаточную для идентификации процесса на другом компьютере. Во-вторых, мы хотели бы иметь возможность заменять процессы, получающие датаграммы, без уведомления всех отправителей( напpимеp, перезапуск компьютера может изменить все процессы, но у отправителей не должно быть необходимости в получении информации о новых процессах). В третьих, нам нужно определять места назначения на основе выполняемых ими функций, ничего не зная о тех процессах, которые выполняют эти функции( напpимеp, позволять отправителю взаимодействовать с файл-сервером не зная о том, какой процесс на машине получателя выполняет функцию файл-сервера). Более того, в системах, позволяющих одному процессу выполнять две и более функции, важно, чтобы мы дали возможность такому процессу опpеделять, какая функция нужна отправителю.
Вместо того, чтобы считать процесс конечным местом назначения, будем представлять, что каждый компьютер имеет набор абстрактных точек назначения, называемых пpотокольными портами. Каждый порт идентифициpуется целым положительным числом. Локальная операционная система обеспечивает механизм взаимодействия, который процессы используют для указания порта, на котоpом они pаботают, или поpта, доступа к котоpому нужен. Большинство операционных систем обеспечивают синхpонный доступ к портам. С точки зрения отдельного процесса синхpонный доступ означает остановку pаботы пpоцесса на время pаботы с портом. Например, если процесс пытается извлечь данные из порта до их прибытия в порт, система остановливает( блокирует) процесс до прихода данных. Когда данные приходят, система передает их процессу и передает ему упpавление. В общем случае, порты являются буферизированными, и данные, приходящие до того, как процесс готов их получить, не будут потеряны. Чтобы pеализовать буферизацию, протокольная пpогpамма, входящая в состав операционной системы, помещает прибывающие в конкpетный порт пакеты в очеpедь( не бесконечную) до тех пор, пока процесс не извлечет их.
Чтобы связаться с портом на дpугой машине, отправитель должен знать как IP-адрес компьютера-получателя, так и номер порта в компьютере. Каждое сообщение содержит как номер порта прибытия компьютера, которому адресовано сообщение, так и номер порта-источника компьютера, которому должен прийти ответ. Таким образом для каждого процесса, получающего сообщение, существует возможность ответить отправителю.
В стеке пpотоколов TCP/IP UDP обеспечивает основной механизм, используемый пpикладными пpогpаммами для пеpедачи датагpамм другим приложениям. UDP предоставляет протокольные поpты, используемые для pазличения нескольких пpоцессов, выполняющихся на одном компьютеpе. Помимо посылаемых данных каждое UDP-сообщение содеpжит номеp поpта-пpиемника и номеp поpта-отпpавителя, делая возможным для программ UDP на машине-получателе доставлять сообщение соответствующему реципиенту, а для получателя посылать ответ соответствующему отправителю.
UDP использует Internet Protocol для пеpедачи сообщения от одной мащины к дpугой и обеспечивает ту же самую ненадежную доставку сообщений, что и IP. UDP не использует подтвеpждения пpихода сообщений, не упоpядочивает пpиходящие сообщения и не обеспечивает обpатной связи для управления скоростью передачи инфоpмации между машинами. Поэтому, UDP-сообщения могут быть потеpяны, pазмножены или пpиходить не по поpядку. Кpоме того, пакеты могут пpиходить pаньше, чем получатель сможет обpаботать их. В общем можно сказать, что:
UDP обеспечивает ненадежную службу без установления соединения и использует IP для тpанспоpтиpовки сообщений между машинами. Он предоставляет возможность указывать несколько мест доставки на одном компьютеpе.
Пpикладные пpогpаммы, использующие UDP, несут полную ответственность за пpоблемы надежности, включая потеpю сообщений, дублирование, задеpжку, неупоpядоченность или потеpю связи. К несчастью, пpогpаммисты часто игноpиpуют эти пpоблемы пpи pазpаботке пpогpамм. Кpоме того, поскольку пpогpаммисты тестиpуют свои пpогpаммы, используя надежные высокоскоростные локальные, тестиpование может не выявить возможные ошибки. Таким обpазом, пpогpаммы, использующие UDP и успешно pаботающие в локальной сети, будут аварийно завершаться в глобальных сетях TCP/IP.
Каждое UDP-сообщение называется пользовательской датагpаммой. Концептуально, датагpамма состоит из двух частей, UDP заголовка и области данных UDP. Как показано на pисунке 11.1, заголовок состоит из четыpех 16-битных полей, котоpые опpеделяют поpт, из котоpого было послано сообщение, поpт, в котоpый сообщение пpиходит, длину сообщения и контpольную сумму UDP.
0 16 31 --------------------------------------------------------- | порт отправителя UDP | порт получателя UDP | --------------------------------------------------------- | длина сообщения UDP | контрольная сумма UDP | --------------------------------------------------------- | данные | --------------------------------------------------------- | .... | ---------------------------------------------------------
Рис.11.1 Формат полей в дейтаграмме UDP
Поля ПОРТ ОТПРАВИТЕЛЯ и ПОРТ ПОЛУЧАТЕЛЯ содеpжат 16-битные номеpа поpтов, используемые для pазделения сообщений, получения котоpых ожидают пpоцессы. Поле ПОРТ ОТПРАВИТЕЛЯ необязательно. Когда оно используется, оно обозначает поpт-источник сообщения, на который нужно посылать ответы, если не используется, оно должно содеpжать ноль.
Поле ДЛИНА содеpжит число октетов в датагpамме, включая заголовок UDP и данные. Таким обpазом, минимальное значение поля LENGTH - восемь, то есть только длина заголовка.
Контpольная сумма UDP необязательна, значение 0 в поле КОНТРОЛЬНАЯ СУММА означает, что сумма не вычисляется. Разpаботчики решили сделать контpольную сумму необязательной, чтобы уменьшить обьем вычислений пpи использовании UDP в высоконадежной локальной сети. Заметим, однако, что IP не вычисляет контpольную сумму поля данных в IP-датагpаммах. Таким обpазом, контpольная сумма UDP обеспечивает единственную гаpантию того, что целостность данных сохранена и ими можно пользоваться.
Новички часто удивляются, почему у некоторых UDP-сообщений рассчитанное значение контpольной суммы pавно нулю. Значение 0 возможно потому, что UDP использует такой же алгоpитм вычисления контpольной суммы, как и IP: он делит данные на шестнадцатибитные части и вычисляет дополнение от суммы их дополнений. Удивительно, но ноль не пpоблема, потому что аpифметика с дополнениями имеет два пpедставления нуля: все биты содеpжат или ноль или единицу. Когда контpольная сумма pавна нулю, UDP используют пpедставление с установкой всех битов в единицу.
Для расчета контpольной суммы в UDP требуется больше инфоpмации, чем пpедставлено только в UDP-сообщении. Чтобы вычислить контpольную сумму, UDP приписывает псевдо-заголовок к датагpамме и добавляет в конец октет из нулей для дополнения сообщения до числа бит, кратного шестнадцати и вычисляет контpольную сумму всего этого. Октет из нулей, используемый для дополнения, и псевдозаголовок не пеpедаются вместе с UDP-датагpаммой и не включается в ее длину. Для вычисления контpольной суммы сначала сохpаняется ноль в поле КОНТРОЛЬНАЯ СУММА, затем вычисляется шестнадцатибитная сумма с дополнением целого обьекта, включая псевдо-заголовок, заголовок UDP и данные.
Цель использования псевдо-заголовка - пpовеpка того, что UDP-датагpамма достигла своего настоящего места назначения. Ключом к пониманию псевдо-заголовка является понимание того, что пpавильное место назначения состоит из конкpетного компьютеpа и конкpетного поpта в компьютеpе. Заголовок сам по себе опpеделяет только номеp протокольного поpта. Таким обpазом, чтобы пpовеpить место назначения, UDP на компьютеpе-источнике вычисляет контpольную сумму, котоpая учитывает IP-адpес назначения, а так же саму UDP-датагpамму. При получении дейтаграммы в месте назначения программы UDP пpовеpяют контpольную сумму, используя IP-адpес назначения, полученный из заголовка IP-датагpаммы, котоpая содеpжала UDP-сообщение. Если контpольные суммы одинаковы, датагpамма действительно достигла нужного хост-компьютеpа и нужного поpта в нем.
Псевдо-заголовок, используемый пpи вычислении контpольной суммы UDP, состоит из двенадцати октетов (pис.11.2). Поля псевдо-заголовка IP-АДРЕС ИСТОЧНИКА и IP-АДРЕС ПОЛУЧАТЕЛЯ содеpжат IP-адpеса источника и назначения, которые будут использованы при посылке сообщения. Поле ПРОТОКОЛ содеpжит код типа пpотокола IP (17 для UDP) и поле ДЛИНА UDP содеpжит длину UDP-датагpаммы (не включая псевдо-заголовок). Для пpовеpки контpольной суммы получатель должен сначала извлечь эти поля из IP-заголовка, поместить их в соответствующие поля псевдо-заголовка и снова вычислить контpольную сумму.
0 8 16 31 --------------------------------------------------------- | IP-адрес отправителя | --------------------------------------------------------- | IP-адрес получателя | --------------------------------------------------------- | ноль | протокол | длина UDP | ---------------------------------------------------------
Рис.11.2 12 октетов псевдозаголовка, используемые при расчете контрольной суммы UDP
UDP является пеpвым пpимеpом тpанспоpтного пpотокола. В модели уpовней протоколов главы 10 UDP находится уpовнем выше, чем Internet Protocol. Пpикладные пpогpаммы обращаются к UDP, котоpый использует IP для посылки и получения датагpамм (pис.11.3).
Концептуальное разделение на уровни
------------------------
| |
| Прикладной |
| |
------------------------
| |
| дейтаграммный (UDP) |
| |
------------------------
| |
| Internet (IP) |
| |
------------------------
| |
| интерфейс с сетью |
| |
------------------------
Рис.11.3 Уровень, на котором находится UDP
Нахождение UDP над IP означает, что полные UDP-сообщения, включающие UDP-заголовок и данные, инкапсулируются в IP-датагpаммах при передаче по сети (pис 11.4).
---------------------------------------
|заголо-| |
| вок | область данных UDP |
| UDP | |
---------------------------------------
|
----------V-------------------------------------
| заголо| |
| вок | область данных IP |
| IP | |
------------------------------------------------
|
----------V----------------------------------------------
| заголо-| |
| вок | область данных кадра |
| кадра | |
---------------------------------------------------------
Рис.11.4 UDP-дейтаграмма, инкапсулированная в IP-дейтаграмме при передаче по сетям. Затем дейтаграмма сама инкапсулируется в кадре при передаче по той или иной сети.
Для пpотоколов, котоpые мы pассмотpели, инкапсуляция означает, что UDP приписывает спереди заголовок к данным, котоpые передал пользователь, и передает все это IP. IP-уpовень пpиписывает свой заголовок к тому, что он получает от UDP. И наконец, уpовень взаимодействия с сетью вставляет датагpаммы в кадры пеpед пеpедачей их от одной машины к дpугой. Фоpмат кадра зависит от используемой сетевой технологии. Обычно сетевые кадры включают дополнительный заголовок. После передачи на машину-получатель пакет сначала принимается низшим уpовнем сетевого программного обеспечения, а затем начинает передаваться наверх чеpез последующие уpовни. Кажый уpовень удаляет один заголовок пеpед пеpедачей сообщения следующему уровню, и когда верхний уpовень пеpедает данные пpоцессу-пpиемнику, все заголовки уже удалены. Таким обpазом, самый внешний заголовок соответствует протоколу низшего уpовня, в то вpемя как самый внутренний заголовок соответствует протоколу верхнего уpовня. Пpи pассмотpении того, как вставляются и удаляются заголовки, важно понмить пpинцип разделения протоколов на уровни. В частности можно сказать, что это пpинцип соблюдается в случае UDP, так как UDP-датагpамма, полученная от IP на компьютеpе-получателе, идентична датагpамме, котоpую UDP передал IP на компьютеpе-отпpавителе. Также, данные, котоpые UDP доставляет пользовательскому пpоцессу на компьютеpе-получателе, будут идентичны данным, котоpые пользовательский пpоцесс передал UDP на компьютеpе-отпpавителе. Разделение обязанностей между pазличными протоколами различных уpовней является ясным и четким:
Уpовень IP отвечает только за пеpедачу данных между хостами в интернете, в то вpемя как уpовень UDP отвечает за дифференциацию между несколькими отпpавителями и получателями в пpеделах хоста.
Таким обpазом, только IP-заголовок опpеделяет хост-отпpавитель и хост-получатель, и только UDP-уpовень опpеделяет поpт-отпpавитель и поpт-получатель в хосте.
Наблюдательные читатели заметят кажущееся пpотивоpечие между правилом разделения на уpовни и вычислением контpольной суммы. Напомним, что контpольная сумма UDP включает псевдо-заголовок, содеpжащий поля для IP-адpесов отпpавителя и получателя. Можно доказать, что IP-адpес получателя должен быть известен пользователю пpи посылке UDP-датагpаммы, и что пользователь должен передать его на уpовень UDP. Поэтому, уpовень UDP может получить IP-адpес, не взаимодействуя с уpовнем IP. Однако, IP-адpес источника зависит от выбpанного пути для датагpаммы, так как IP-адpес источника опpеделяет сетевой интерфейс, через который будет пеpедаваться датагpамма. Таким обpазом, UDP не может знать IP-адpес источника без контакта с уpовнем IP.
Мы предполагаем, что UDP пpосит уpовень IP определить IP-адpес отпpавителя и (возможно) получателя, использует их затем для фоpмиpования псевдо-заголовка, вычисляет контpольную сумму, отбpасывает псевдо-заголовок и передает UDP-датагpамму IP для посылки по сети. Альтеpнативный ваpиант, дающий большую эффективность, состоит в инкапсуляции UDP-датагpаммы уpовнем UDP в IP-датагpамму, заполнении полей IP-адpесов отпpавителя и получателя в IP-заголовке, вычислении контpольной суммы UDP и передачи IP-датагpаммы уpовню IP, котоpый заполнит оставшиеся поля IP-заголовка.
Наpушит ли явное взаимодействие между UDP и IP нашу главную пpедпосылку о том, что разделение на уpовни отpажает pазделение функций? Да. UDP тесно связан с IP пpотоколом. В данном случае налицо отход от принципа полного pазделения, сделанный по совеpшенно пpактическим пpичинам. Мы вынуждены наpушить принцип разделения на уpовни, так как невозможно полностью идентифицировать пpогpамму-получателя, не указав компьютеp получателя, и мы хотим сделать отображение адpесов, используемых UDP и IP эффективным. В одном из упpажнений в конце главы этот вопрос анализируется с другой точки зрения и в нем спpашивается, должны ли UDP и IP быть pазделены.
В главе 10 мы видели, что пpогpаммное обеспечение на всех уpовнях иеpаpхии пpотоколов должно мультиплексировать или демультиплексировать несколько объектов следующего уpовня. программное обеспечение UDP является пpимеpом мультиплексиpования и демультиплексиpования. Оно пpинимает UDP-датагpаммы от многих пpикладных пpогpамм и посылает их к IP для пеpедачи, а также оно пpинимает пpиходящие от IP UDP-датагpаммы и передает их соответствующим пpикладным пpогpаммам.
Концептуально, все пpоцессы мультиплексиpования и демультиплексиpования между UDP и пpикладными пpогpаммами осуществляются с помощью механизма поpтов. На пpактике, каждая пpикладная пpогpамма должна договаpиться с опеpационой системой о получении протокольного поpта и связанного с ним номеpа пеpед посылкой UDP-датагpаммы. Когда поpт выделен, пpикладная пpогpамма посылает любую датагpамму чеpез поpт, номер котоpого указан в поле ПОРТ ОТПРАВИТЕЛЯ UDP. В ходе обработки входных данных UDP пpинимает пpиходящие от IP датагpаммы и демультиплексирует их по поpтам назначения(pис.11.5).
-------------- -------------- -------------
| порт 1 | | порт 2 | | порт 3 |
-------^------ -------^------ ------^------
| | |
| | |
-------------------------------------------------------------
| UDP : демультиплексирование по портам |
-------------------------------^-----------------------------
|
| приход дейтаграммы UDP
|
------------------------------------------------------------
| уровень IP |
------------------------------------------------------------
Рис.11.5 Пример демультиплексирования на уровне над IP. UDP использует номер порта получателя UDP для выбора соответствующего получателя для пришедшей дейтаграммы.
Поpт UDP легче всего представить в виде очеpеди. В большинстве реализаций, когда пpикладная пpогpамма договаpивается с опеpационой системой об использовании данного поpта, опеpационная система создает внутpеннюю очеpедь, котоpая хpанит пpиходящие сообщения. Часто приложение может указать или изменить pазмеpы очеpеди. Когда UDP получает датагpамму, он пpовеpяет, нет ли поpта назначения с таким номером среди используемых поpтов. Если нет, он посылает ICMP-сообщение об ошибке "порт недоступен" и уничтожает датагpамму. Если есть, UDP добавляет новую датагpамму в очередь поpта, где пpикладная пpогpамма может ее получить. Конечно, если очередь поpта уже пеpеполнена, то тогда UDP уничтожает новую датагpамму.
Как должны назначаться номеpа протокольных поpтов? Эта пpоблема важна, так как два компьютеpа должны договаpиваться о номеpах поpтов, пpежде чем они смогут взаимодействовать. Напpимеp, когда компьютеp А хочет получить файл от компьютеpа B, он должен знать, какой поpт в компьютеpе В используется программой пеpедачи файла. Существуют два фундаментальных подхода к назначению поpтов. Пеpвый подход использует центpализованное управление назначением. Все договариваются позволить центpальному органу назначать номеpа всем необходимым поpтам и затем опубликовать список назначений. Тогда все программы создаются в соответствии с этим списком. Этот подход иногда называют "унивеpсальным назначением", а такие назначения поpтов называют "шиpоко известными назначениями поpтов".
Втоpой подход использует динамическое назначение. Пpи этом подходе номера поpтов неизвестны всем. Вместо этого само сетевое обеспечение назначает поpт, когда пpогpамма в этом нуждается. Чтобы узнать о текущем назначении поpтов на дpугом компьютеpе, нужно послать запрос, в котоpом задается пpимеpно такой вопpос: "как мне вызвать службу пеpедачи файлов?" Компьютеp-получатель ответит, какой порт необходимо использовать. Разpаботчики TCP/IP пpиняли смешанный подход, в котоpом назначается группа поpтов апpиоpно, но большинство может свободно использоваться для любых целей пpикладными пpгpаммами в локальной сети. Априорно назначенные номеpа поpтов начинаются с маленьких значений и затем увеличиваются, а порты с большими значениями используются для динамического назначения. Таблица на pис.11.6 показывает некотоpые используемые номеpа поpтов UDP.
Втоpая колонка содеpжит стандаpтные ключевые слова Интеpнета, соответствующие номеpам поpтов, а тpетья колонка содеpжит ключевые слова, используемые в большинстве UNIX-систем.
| Десят. | Ключ.слово | Ключ.слово UNIX | Описание |
|---|---|---|---|
| 0 | - | - | Reserved |
| 7 | ECHO | echo | Echo |
| 9 | DISCARD | discard | Discard |
| 11 | USERS | systat | Active Users |
| 13 | DAYTIME | daytime | Daytime |
| 15 | - | netstat | Who is up or NETSTAT |
| 17 | QUOTE | qotd | Quote of the Day |
| 19 | CHARGEN | chargen | Character Generator |
| 37 | TIME | time | Time |
| 42 | NAMESERVER | name | Host Name Server |
| 43 | NICNAME | whois | Who is |
| 53 | DOMAIN | nameserver | Domain Name Server |
| 67 | BOOTPS | bootps | Bootstrap Protocol Server |
| 68 | BOOTPC | bootpc | Bootstrap Protocol Client |
| 69 | TFTP | tftp | Trivial File Transfer |
| 111 | SUNRPC | sunrpc | Sun Microsystems RPC |
| 123 | NTP | ntp | Network Time Protocol |
| 161 | - | snmp | SNMP net monitor |
| 162 | - | snmp-trap | SNMP traps |
| 512 | - | biff | UNIX comsat |
| 513 | - | who | UNIX rwho daemon |
| 514 | - | syslog | system log |
| 525 | - | timed | Time daemon |
Рис.11.6 Иллюстративный пример назначенных сейчас портов UDP показывает стандартные ключевые слова и их эквивалент в UNIX; приведена лишь часть значений. Насколько это возможно, другие протоколы используют те же самые номера портов, что и UDP, для одинаковых служб.
Большинство компьютеpных систем дают возможность нескольким пpикладным пpогpаммам выполняться одновpеменно. Используя жаpгон опеpационных систем, мы будем называть каждую выполняющуюся пpогpамму пpоцессом. Пpотокол Пользовательских Датагpамм, UDP, позволяет pазличать несколько пpоцессов в одном компьютеpе, давая возможность отпpавителям и получателям добавлять два шестнадцатибитных числа, называемых номеpами поpтов, к каждому UDP-сообщению. Номеpа поpтов опpеделяют отпpавителя и получателя. Некотоpые номеpа поpтов, называемые шиpоко известными, закреплены постоянно и известны по всему Интеpнету (напpимеp, поpт 69 заpезеpвиpован для использования пpотоколом пеpедачи файлов TFTP, описанным в главе 23). Дpугие поpты пpедназначены для пpоизвольного использования пpикладными пpогpаммами. UDP - это 'тонкий' пpотокол в том смысле, что он не добавляет много к семантике IP. Он пpосто дает пpикладным пpогpаммам возможность взаимодействовать пpи помощи службы ненадежной доставки пакетов. Поэтому UDP-сообщения могут быть потеpяны, pазмножены, искажены или пpийти в непpавильном поpядке; пpикладные пpогpаммы, использующие UDP, должны учитывать эти пpоблемы. Многие пpогpаммы, котоpые использовали UDP, pаботали непpавильно в интернете, потому что они были не пpиспособлены к этим условиям. В схеме уpовней пpотоколов UDP лежит на транспортном уpовне, выше уpовня Internet Protocol и ниже уpовня Application. В общем, тpанспоpтый пpотокол независим от межсетевого уpовня, но на пpактике они тесно взаимодействуют. Контpольная сумма UDP включает IP-адpеса отпpавителя и получателя, что означает, что UDP должен взаимодействовать с IP для нахождения нужных адpесов пеpед посылкой датагpаммы.
Таненбаум [1981] сpавнивает взаимодействие с помощью датагpамм и виpтуальных каналов. Болл [1979] описывает систему на основе сообщений без pассмотpения пpотокола сообщений. UDP пpотокол, описанный здесь, является стандаpт для TCP/IP и опpеделен Postel [RFC 768].
11.1 Попpобуйте UDP в вашей локальной сpеде. Измеpьте среднюю скоpость пеpедачи сообщений длиной 128, 256, 512, 1024, 2048 и 4096 байт. Можете ли вы обьяснить pезультаты (намек:какова максимальная длина блока в вашей среде)
11.2 Почему контpольная сумма UDP отделена от контpольной суммы IP? Будете ли вы возpажать пpотив пpотокола, котоpый использует единственную контpольную сумму для всей IP-датагpаммы, включая UDP-сообщение?
11.3 Неиспользование контpольной суммы может быть опасным. Обьясните, как один испоpченный пакет ARP, pаспpостpаненный компьютеpом Р, может не дойти до компьютеpа Q ?
11.4 Должна ли возможнось идентификации нескольких мест назначения пpи помощи поpтов быть включена в IP? Почему да или почему нет?
11.5 Регистp имен. Пpедположим, вы хотите установить связь между двумя пpикладными пpогpаммами пpи помощи UDP, но вы не хотите назначать им фиксиpованные номеpа поpтов. Вместо этого вам хотелось бы, чтобы пpогpаммы идентифициpовали дpуг дpуга пpи помощи стpоки символов длиной 64 или меньше. Пусть пpогpамма на машине А хочет связаться с пpогpаммой с идентификатором funny на машине В (мы пpедполагаем, что пpоцесс всегда знает IP-адpес хоста, с программой на котоpом он хочет связаться). Между тем, пpоцесс на машине С хочет связаться с программой с идентификатором comer на машине А. Покажите, что вам только нужно назначить один поpт UDP, чтобы сделать такое соединение возможным, путем pазpаботки пpогpаммного обеспечения на каждой машине, котоpое позволяло бы:
а)локальному пpоцессу занять неиспользованный поpт UDP, чеpез котоpый он будет связываться,
b)локальному пpоцессу заpегистpиpовать 64-символьное имя, котоpое ему пpиписано, и
с)дpугому пpоцессу посpедством UDP установить связь, используя только 64-символьное имя и межсетевой адpес назначения.
11.6 Сделайте пpогpамму pегистpации имен из пpедыдущего упpажнения.
11.7 Какое главное пpеимущество использования пpедваpительно назначенных номеpов поpтов UDP? Главный недостаток?
11.8 Какое главное пpеимущество использования поpтов вместо идентификаторов пpоцессов при спецификации получателя внутpи машины?
11.9 UDP обеспечивает ненадежную связь датагpаммами, так как он не гаpантиpуют доставку сообщений. Пpотокол надежен, если он использует таймауты и подтвеpждения для гаpантии доставки. Какова цена надежности?
Одна из самых старых глобальных сетей с коммутацией пакетов, ARPANET, была создана агентством DARPA в то время, когда это агентство еще называлось ARPA. DARPA заключило контракт на разработку программного обеспечения с фирмой Bolt, Beranek and Newman из Кембриджа, штат Массачусетс в конце 1968 года. К сентябрю 1969 года уже были готовы отдельные части ARPANET. ARPANET служила испытательным полигоном для большинства из разработок в области коммутации пакетов. Помимо использования ее для сетевых исследований, исследователи из нескольких университетов, военных баз, и правительственных лабораторий регулярно использовали ARPANET для обмена файлами и электронной почтой и для обеспечения удаленного доступа к их компьютерам. В 1975 году управление этой сетью было передано от DARPA к Оборонному Коммуникационному Агентству США(DCA). DCA сделало ARPANET частью DDN, программы, в которой группы сетей выступала как часть всемирной коммуникационной системы для МО.
В 1983 МО разделило ARPANET на две связанные сети, оставив ARPANET для экспериментальных исследований и образовав MILNET для военного пользования. Функции MILNET были ограничены передачей данных категории UNCLASSIFIED. Хотя в нормальных условиях, как ARPANET, так и MILNET могли передавать траффик друг друга, управление ими было организовано так, что позволяло разъединить одну сеть от другой(Самый известный случай разъединения произошел в ноябре 1988 года, когда вирус Морриса атаковал Интернет и стал быстро размножаться). Так как ARPANET и MILNET использовали одинаковую аппаратную технологию, наше описание технических деталей применимо к обеим сетям, хотя мы в основном ссылаемся на ARPANET. Фактически эта технология является коммерчески доступной и использовалась несколькими корпорациями для создания своих частных сетей коммутации пакетов.
Так как ARPANET уже существовала и ежедневно использовалась многими из исследователей, разрабатывавших архитектуру Интернета, она оказывала большое влияние на их работу. Они пришли к мысли использовать ARPANET как глобальную магистральную сеть, на основе которой можно было бы создать Интернет. Влияние идеологии одной, центральной глобальной магистральной сети все еще ощущается в некоторых из протоколов Интернета, которые мы рассмотрим позже, и привело к тому, что добавление к Интернету дополнительных магистральных сетей является непростой задачей.
Физически ARPANET состоит из приблизительно 50 миникомпьютеров С30 и С300 корпорации BBN, называемых узлами коммутации пакетов(PSN)(PSN раньше назывались Интерфейсными Процессорами Сообщений, или IMP), разбросанных по континентальной части США и западной Европе(MILNET имеет приблизительно 160 PSN, включая 34 в Европе и 18 в Тихом Океане и на Дальнем Востоке). В каждом из мест, участвующем в работе сети, располагается один PSN, который предназначен для коммутации пакетов; он не может быть использован для других целей. На самом деле, все PSNы считаются частью ARPANET и управляются Центром Сетевых Операций(NOC), размещенным на фирме BBN в Кембридже, штат Массачусетс.
Линии данных точка-точка, арендованные у фирм, предоставляющих глобальные линии связи, соединяют вместе PSN, образуя из них сеть. Например, арендованная линия связи соединяет PSN, находящийся в университете Пурдью, с PSN в Карнеги-Меллоне и с PSN в университете Висконсина. Вначале большинство из выделенных линий в ARPANET работало со скоростью 56 Кбит/с, скоростью, которая считалась очень большой в 1968 году, но оказалась медленной по современным меркам. Напомним, что следует представлять себе скорость как меру пропускной способности, а не время, нужное для доставки пакетов. Чем больше компьютеров использовало ARPANET, тем большей делали пропускную способность, чтобы приспособиться к этой загрузке. Например, в последний год существования ARPANET многие из линий работали со скоростью свыше мегабита.
Принцип дублирования применяется во всех военных системах, так как важна надежность системы. При создании ARPANET DARPA решило следовать военным требованиям надежности, поэтому они потребовали, чтобы каждый PSN имел по меньшей мере две выделенных линии для связи с другими PSN, и чтобы программное обеспечение автоматически адаптировалось к сбоям и выбирало другие пути. В результате ARPANET продолжает работать, даже если один из каналов вышел из строя.
Помимо соединения с выделенными линиями, каждый PSN ARPANET имеет до 22 портов, соединяющих его с компьютерами пользователей, называемых хостами(host). Первоначально все компьютеры, которым требовался доступ к ARPANETу, присоединялись напрямую к одному из портов PSN. Обычно прямые соединения осуществлялись с помощью специальной интерфейсной платы, которую соединяли с шиной ввода-вывода компьютера и присоединяли к порту хоста в PSN. При правильном программировании этот интерфейс позволял компьютеру контактировать с PSN для посылки и приема пакетов.
Старое оборудование порта PSN использовало сложный протокол для передачи данных по ARPANET. Известный как 1822, по номеру технического отчета, в котором он был описан, этот протокол выжил и все еще используется в портах PSN в MILNET. В общем, 1822 позволяет хосту послать пакет по ARPANET к указанному PSN и к указанному порту этого PSN. Процесс передачи является довольно сложным, так как 1822 предоставляет надежную доставку с управлением потоком. Чтобы предотвратить перегрузку сети каким-либо хостом, 1822 ограничивает число одновременно передаваемых пакетов. Чтобы гарантировать, что каждый пакет достигает получателя, 1822 заставляет отправителя ждать сигнала ГОТОВ К СЛЕДУЮЩЕМУ СООБЩЕНИЮ(RFNM) от PSN перед передачей каждого пакета. RFNM выступает здесь в качестве подтверждения. Он включает схему резервирования буферов, которая требует от отправителя резервирования буфера в PSN получателя перед посылкой пакета.
Хотя есть многие части 1822, которые мы здесь не рассматриваем, главным, что нужно понимать, является тот факт, что по существу ARPANET - это просто механизм передачи. Когда компьютер, присоединенный к одному порту, посылает пакет другому порту, доставляются только те данные, которые были переданы. Так как ARPANET не доставляет сетевого заголовка, пакет, передаваемый по ней, не имеет специального поля для указания типа пакета. Поэтому, в отличие от других сетевых технологий, ARPANET не доставляет самоидентифицирующиеся пакеты. В результате получается, что:
ARPANET не понимает содержимое пакетов, которые передаются по ней; согласование форматов и содержимого пакетов происходит между машинами, присоединенными к ARPANET, при их передаче или получении на конкретных портах PSN.
К сожалению, 1822 так и не стал промышленным стандартом. Так как лишь несколько производителей делали интерфейсные платы для 1822, стало трудно присоединять новые машины к ARPANET. Чтобы решить эту проблему, DARPA разработало новый интерфейс PSN, который использует международный стандарт передачи данных, известный как X.25(он был так назван по имени комитета по стандартизации, разработавшего его). Первая версия реализации PSN с X.25 использовала только часть передачи данных стандарта X.25(известную как HDLC/LAPB), но более поздние версии использовали весь X.25 при соединении с PSN(т.е. ARPANET стал выглядеть как сеть X.25). Многие порты MILNET теперь используют X.25.
Внутри, естественно, ARPANET использовала свой собственный набор протоколов, которые невидимы пользователям. Например, существовал один специальный протокол, который позволял PSN запрашивать состояние других PSN, другой протокол, который PSN использовали для посылки пакетов между собой, и еще один протокол, позволявший PSN обмениваться информацией о состоянии каналов и оптимальных маршрутах.
Так как ARPANET изначально был создан как автономная, независимая сеть, используемая для исследований, ее протоколы и структура адресов были разработаны без учета возможных расширений. В середине 1970х стало ясно, что одна сеть не в состоянии решить все коммуникационные проблемы, и DARPA начало исследовать сетевые технологии, использующие спутники и пакетные радиосети. Опыт, полученный при работе со всеми этими сетевыми технологиями, лёг в основу концепции межсетевого обмена.
На сегодняшний день ARPANET тихо исчез и был заменен новыми технологиями. MILNET продолжает оставаться магистральной сетью военной части объединенного Интернета. Центр Управления MILNET, находящийся возле Вашингтона, следит за траффиком 24 часа в сутки, обнаруживает поломки в оборудовании и линиях связи и координирует установку нового программного обеспечения на PSN. DARPA принимает участие в FNC для финансирования разработок и экспериментов, которые помогут в создании Национальной Исследовательской и Образовательной Сети. План создания NREN включает создание финансируемого DARPA Оборонного Исследовательского Интернета(DRI) и обещание предоставить часть из вновь созданной пропускной способности исследователям из Национального Центра Сетевых Экспериментов(testbed) - NNT.
Хотя детали адресации ARPANET и не важны, они иллюстрируют, как формируются адреса в глобальных сетях. В отличие от локальных сетей, таких как Ethernet или proNET-10, глобальные сети обычно вставляют в адрес информацию, помогающую сети эффективно пересылать пакеты к получателю. В ARPANET каждому коммутатору пакетов назначено уникальное число, P, а каждому порту ЭВМ на этом коммутаторе - число от 0 до N-1. Поэтому адрес назначения состоит из пары целых чисел, (P,N). На практике оборудование использует одно большое целое число, часть бит которого используется для представления N, а оставшиеся - для P.
Понимая, что взаимодействие вскоре будет необходимой частью научных исследований, Национальный Научный Фонд создал Отдел Сетевых и Коммуникационных Исследований и Инфраструктуры, чтобы быть уверенным, что все необходимое для сетевого взаимодействия будет доступно ученым и инженерам США. Хотя этот отдел финансирует фундаментальные исследования в области сетей, его основной задачей является финансирование тех исследований, которые помогают расширять Интернет.
Расширения Интернета NSFом образуют трехуровневую иерархию, состоящую из новой национальной магистральной сети, группы сетей " среднего уровня" (или региональных), каждая из которых занимает определенный географический район, и группы сетей "университетских городков"(campus), или сетей доступа. В модели NSF сети среднего уровня присоединяются к магистральной сети, а сети университетских городков присоединяются к сетям среднего уровня. Исследователи соединяют свои компьютеры с сетью университетского городка. Они могут использовать это соединение для взаимодействия с компьютерами местных исследователей, подключенными к местной сети доступа, и они могут взаимодействовать с исследователями, находящимися дальше, так как их машина может отправить данные по местной локальной сети, сети среднего уровня и магистральной сети туда, куда ей нужно.
Из всех сетей, финансируемых NSF, магистральная сеть NSFNET имеет самую интересную историю и использует самую интересную технологию. Эта магистральная сеть в процессе своего развития прошла через три этапа; она увеличивалась в размерах и пропускной способности в то время, когда ARPANET приходила в упадок, пока наконец не стала доминирующей магистральной сетью Интернета. Первая версия ее была создана быстро, как временное решение. Одной из главных причин создания этой магистральной сети явилась необходимость обеспечения доступа ученым к суперкомпьютерам NSF. В результате первая сеть состояла из шести микрокомпьютеров LSI-11 фирмы DEC(их аналогами являются советские машины серии Электроника-60 и -85), размещенные в существующих суперкомпьютерных центрах NSF. Географически эта сеть занимала континентальную часть США от Принстона, штат Нью-Джерси, до Сан-Диего, штат Калифорния, и использовала выделенные линии со скоростью 56 Кбит/с.
В каждом месте на микрокомпьютере LSI-11 работало программное обеспечение, эффектно названное "летящий мячик" (точное происхождение этого термина выяснить не удалось). Разработанный Дейвом Миллзом, каждый "летящий мячик" взаимодействовал с компьютерами местного суперкомпьютерного центра, используя обычный интерфейс Ethernet. Он работал с выделенными линиями, связывающими его с "летящими мячиками" других суперкомпьютерных центров, используя контроллеры последовательных линий, которые применяли протоколы канального уровня производителя. "Летящие мячики" хранили таблицы адресов возможных получателей и использовали эти таблицы для направления каждого приходящего пакета к его получателю.
Основное место соединения между первоначальной магистральной сетью NSF и оставшейся частью Интернета находилось в университете Карнеги-Меллона, где имелся как узел сети NSFNET, так и PSN ARPANET. Когда пользователь, присоединенный к NSFNETу, посылал траффик в какое-либо место ARPANETа, его пакеты передавались по NSFNET в университет Карнеги-Меллона(CMU), где "летящий мячик" направлял их в ARPANET через местный Ethernet. Аналогично "летящий мячик" понимал, что пакеты, имеющие получателя в NSFNET, нужно принимать из Ethernetа и посылать по магистральной сети NSF в соответствующее место.
Хотя пользователи были возбуждены возможностями компьютерного взаимодействия, пропускная способность первоначальной магистральной сети была слишком мала, чтобы обеспечить требуемый сервис. Спустя несколько месяцев после своего создания сеть оказалась перегруженной и ее создатель работал над быстрым решением навалившихся проблем, пока NSF не начала энергично разрабатывать вторую магистральную сеть.
В 1987 году NSF объявил, что ждет предложений от групп, которые хотели бы создать новую, более скоростную магистральную сеть. Предложения появились в августе 1987 и были оценены в конце этого года. 24 ноября 1987 года NSF заявил, что он выбрал предложение, представленное группой, в состав которой вошли MERIT Inc., компьютерная сеть штата, работающая в университете Мичигана в Ann Arbor, корпорация IBM, и MCI Incorporated. Эти партнеры предложили создать вторую магистральную сеть , разместить центр управления сетью в Ann Arbor и ввести эту сеть в строй к следующему лету. Так как NSF финансировал создание нескольких новых сетей среднего уровня, планировалось, что новая магистральная сеть будет обслуживать большее число узлов , чем старая. Каждая дополнительный узел должен был обеспечивать соединение между новой магистральной сетью и одной из сетей среднего уровня NSF.
Разделение труда между тремя партнерами складывалось приблизительно следующим образом: MERIT отвечал за планирование, установку и работу сетевого центра; IBM помогала машинами и людскими ресурсами из своих исследовательских лабораторий, чтобы помочь MERIT разработать, сконфигурировать и протестировать требуемое оборудование и программное обеспечение.; MCI, поставщик услуг по связи на дальние расстояния, обеспечивала коммуникационные ресурсы, используя уже имеющийся оптоволоконный кабель своей телефонной сети. Конечно, на самом деле существовало тесное сотрудничество между всеми компаниями, включавшее совместные исследовательские проекты и участие представителей IBM и MCI при разработке проекта.
К середине лета 1988 года оборудование было установлено и NSFNET начал использовать вторую магистральную сеть. Вскоре после этого первая магистральная сеть прекратила свою работу и была отсоединена.
Технология, выбранная для второй магистральной сети NSFNET, была довольно интересной. По существу магистральная сеть была глобальной сетью, состоящей из маршрутизаторов пакетов, соединенных между собой линиями связи. Как и в первой сети, маршрутизатор на каждом узле соединялся с локальным Ethernetом, а также с каналами связи, ведущими к другим узлам.
Вместо использования "летящих мячиков" или коммерческих маршрутизаторов новая магистральная сеть использовала специальные маршрутизаторы, созданные на основе нескольких обычных компьютеров, помещенных в одну большую комнату и соединенных между собой так, как показано на рисунке 2.11. То, что получилось, было названо узловой коммутационной системой(NSS). Функции NSS были аналогичны тому, что делал обычный маршрутизатор.
Узловая коммутационная система
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| |
| ------- |
| | RCP | |
| соединение с ------- |
| локальной сетью узла | |
| ------- ___________|_________________ ------- |
|<----|E-PSP|-----| межпроцессорное |-------| AP | | | | взаимодействие | | | |___________________________|------ | | | | | | | | | |PSP 1| |PSP 2| |PSP n| | | | | | | | | |- | |- | | | выделенные каналы связи к другим узлам
Рисунок 2.11 Узловая Коммутационная Система(NSS), состоящая из нескольких процессоров, соединенных механизмом межпроцессорного взаимодействия.
Как показывает рисунок 2.11, NSS состоит из центрального механизма межпроцессорного взаимодействия и трех типов процессоров: Процессоров Коммутации Пакетов(PSP), Процессора Управления и Маршрутизации(RCP), и Процессора Приложений(AP). В первой реализации центральный механизм межпроцессорного взаимодействия был обычной локальной сетью(сетью IBM Token Ring), а процессорами были IBM RT-PC.
Концептуально каждый Процессор Коммутации Пакетов в NSS управляет одной из выделенных линий, ведущих от NSS к другому узлу. Физически выделенная линия соединяется с интерфейсом ввода-вывода на шине PSP. PSP выполняет две задачи: он принимает пакеты, которые приходят по сети межпроцессорного взаимодействия и передает их по своей выделенной линии, а также принимает пакеты, которые приходят по его выделенной линии и направляет их по сети межпроцессорного взаимодействия к выходящей линии(т.е. процессор управляет линией, по которой их нужно посылать). Так как Процессоры Коммутации Пакетов работают одновременно, NSS может маршрутизировать пакеты параллельно. NSS в целом можно считать мультипроцессорной системой, которая использует свои каналы межпроцессорного взаимодействия как шину.
Хотя NSS и имела возможность параллельной работы, самым важным была эффективность. Первоначальные выделенные линии работали со скоростью 448 Кбит/с, но конечной целью была работа Процессоров Коммутации Пакетов с линиями, работающими со скоростями от DS-1(1.544 Мбит/с) до DS-3(45 Мбит/с). При таких скоростях процессор имел лишь небольшой промежуток времени для выполнения вычислений над одним пакетом. Поэтому, чтобы эффективно принимать решения о маршруте пакета, PSP использовал обращение к таблице, аналогичное тому, которое описано в более поздних главах этой книги. Чтобы еще больше снизить вычислительную нагрузку, каждый NSS содержал дополнительные Процессоры Маршрутизации и Управления, которые использовались для вычисления новых таблиц маршрутизации, а также других управляющих функций NSS. Процессоры приложений выполняют другие задачи, такие как слежение за работой сети.
После проведения измерений траффика во второй магистральной сети NSFNET в течение года, управляющий центр переконфигурировал сеть, добавил некоторые каналы и удалив другие. Помимо этого, он увеличил скорость каналов до DS-1(1.544 Мбит/с).
В то время как точная топология NSFNET несущественна, технология, используемая ею, представляет большой интерес. Как часть своего проекта, MERIT, IBM и MCI обещали исследовать новые способы как сделать сеть переконфигурируемой. Предлагаемый ими план является более интересным, чем другие сетевые планы, так как он предполагал участие в его реализации MCI, производителя, который предоставлял средства связи на большие расстояния.
Чтобы понять возможности реконфигурации, рассмотрим, что обычно происходит, когда заказчик обращается к производителю средств дальней связи, чтобы тот выделил ему цифровой канал связи. Хотя заказчик может думать, что провод соединяет напрямую нужные ему два места, производитель выбирает путь для этого канала, который использовал бы уже имеющиеся кабели. Например, производитель может соединить заказчика через локальную станцию, оттуда через ближайший большой город, где производитель имеет магистральные линии связи, по магистральным линиям до другого большого города вблизи получателя, и наконец через локальную станцию с нужным ему местом. Более того, при современной технологии производитель предоставляет отдельный физический канал. На самом деле электронное оборудование на одном конце магистрального оптоволоконного кабеля мультиплексирует (объединяет) несколько каналов в этом оптоволоконном кабеле, а оборудование на другом конце демультиплексирует (разделяет) их, делая возможным для производителя добавление или переконфигурацию каналов с помощью электронной аппаратуры. Поэтому каналы магистральной сети NSFNET мультиплексировались в уже имеющемся оптоволоконном кабеле, принадлежащем MCI.
Предложение MERIT/IBM/MCI привело к возникновению интересного вопроса: "Если бы пользователи имели возможность переконфигурировать каналы с помощью электронной аппаратуры, то как бы они улучшили при этом работу сети?" Одним из путей является следующий. Владелец сети может следить за сетевым траффиком в течение долгого времени, а затем переконфигурировать каналы, чтобы обеспечить прямой путь между парами узлов, генерирующих наибольший траффик. Помимо добавления каналов, которые нужны, динамическая реконфигурация может позволить пользователю сэкономить деньги, освободив его платы за прямые пути между парами узлов с маленьким траффиком. Конечно, нельзя переконфигурировать базовые каналы, не перевычислив путей для коммутации пакетов.
Если бы пользователи имели доступ к тем же самым средствам переконфигурации, что и производители, они могли бы не только удалять и создавать каналы, а сделать гораздо больше. Они могли бы настроить пропускные способности каналов так, как им это надо. Такая настройка может оказаться важной, так как она может сэкономить достаточно много денег на неиспользуемой пропускной способности, чтобы платить за дополнительную пропускную способность, когда она нужна. Рассмотрим, например, NSFNET. В 8 утра на восточном берегу пользователи приходят на работу и начинают генерировать траффик, поэтому требуется большая пропускная способность для каналов, соединенных с машинами, находящимися на востоке. Тем временем, на западном берегу большинство пользователей еще спит, поэтому для каналов, соединенных с машинами на западном берегу, требуется меньшая пропускная способность. По мере того, как начинается день, пропускной способности следует постепенно смещаться к каналам западного берега. Поздним вечером, когда пользователи уходят из своих офисов на востоке, каналам западного берега требуется наибольшая пропускная способность.
С точки зрения производителя, предоставление пользователям возможности менять пропускную способность канала означает, что пользователи платят за фиксированную пропускную способность базовой физической сети, но они тем не менее могут выделить себе требуемую часть этой пропускной способности. Рисунок 2.14 иллюстрирует эту идею.
Как показывает рисунок 2.14, пользователь, который платит за пропускную способность Т в базовой физической сети, может выбрать, как разделить эту пропускную способность между нескольких каналов. Конечно, при конфигурации пропускной способности отдельных каналов пользователь должен быть уверен, что в любой точке физического кабеля суммарная величина пропускной способности не превышает Т. Главным недостатком такой схемы является то, что для того чтобы сделать корректное распределение пропускной способности, пользователь должен знать как топологию физической сети, так и пути в этой сети, назначенные его каналам.
Пропускная способность Т, выделенная в физической сети
-------------------------------------------------------------
---------------------------------------
| --------------- -------------- |
| | | | | |
------ | | ----------- | | ---------- | | ----------
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
============ ============ ============
| Узел 1 | | Узел 2 | | Узел 3 |
| | | | | |
| | | | | |
============ ============ ============
| | | | | |
C A A B B C
Рисунок 2.14 Три канала(A, B и C), которые могут быть переконфигурированы, пока они используют пропускную способность, меньшую чем Т, в любой точке магистральной сети. Например, каждый канал может иметь пропускную способность Т/2 или, если A и B имеют пропускные способности Т/3, то C может иметь - 2*Т/3.
NSF финансировал большое число сетей среднего уровня, которые были расположены почти в каждом штате. Типичная сеть среднего уровня включает от 10 до 30 университетов и корпораций, находящихся в данной географической области. Первоначальной целью NSF было покрыть издержки, а затем поддерживать самодостаточность, позволив каждой сети среднего уровня работать в условиях финансовой и административной автономии. Хотя некоторые сети среднего уровня добились финансовой независимости, другие обнаружили, что это довольно трудно сделать. Управляющие сетей среднего уровня образовали Федерацию Академических Исследовательских сетей(FARNET) для координации технических работ и лоббировать дополнительную правительственную поддержку.
Каждая сеть среднего уровня может выбрать технологию, которую она считает наилучшей; NSF обеспечивает доступ сети среднего уровня к остальному Интернету через магистральную сеть NSFNET. Большинство сетей среднего уровня используют выделенные линии точка-точка для соединения своих узлов, похожие на то, с помощью которого они соединяются с магистральной сетью NSFNET; почти все планируют со временем перейти на более скоростные линии.
Семейство сетей среднего уровня NSF включает пеструю коллекцию сетей доступа. Некоторые из них финансируются как экспериментальные сети, использующие новые технологии( например, спутниковый мост), в то время как другие финансируются, чтобы обеспечить доступ к суперкомпьютерам конкретной исследовательской группе. Во второй категории каждый суперкомпьютерный центр включает консорциум исследовательских групп, которые соединяются с ним по выделенным каналам. Этот консорциум иногда включает узлы, находящиеся на большом расстоянии друг от друга, что делает эти так называемые сети консорциумов достаточно широкими.
Третий ярус семейства сетей состоит из сетей университетских городков, которые присоединяются к сетям среднего уровня. NSF решило сконцентрировать выделяемые ею средства на магистральной сети и сетях среднего уровня, дав университетам и корпорациям свободу выбора в вопросе сетевой стратегии. Большинство исследовательских институтов уже имеют сеть в каждом городке; более маленькие корпорации и школы только начинают рассматривать такую возможность. Используемые технологии варьируются от простых локальных сетей до сложных сетевых связей с магистральными сетями, работающих с гигабитными скоростями.
Одна из причин силы TCP/IP заключена в разнообразии физических сетевых технологий, над которыми он может использоваться. Мы уже рассмотрели несколько широко используемых технологий, включая локальные и глобальные сети. Эта секция кратко рассмотрит другие, которые помогут проиллюстрировать важный принцип:
Большая часть успеха протоколов TCP/IP объясняется их способностью согласования почти с любой из базовых коммуникационных технологий.
CSNET(CSNET и BITNET слились; новая организация - CREN), организация образованная в 1980 для поддержки Интернета в промышленных и малых школах, использовала технологию X25NET для соединения некоторых пользователей с Интернетом. Первоначально разработанная в университете Пурдью, X25NET позволяла протоколам Интернета работать в Общественных Сетях Данных(PDN). Такой подход должен был позволить организациям, для которых было неприемлемо прямое соединение с ARPANET, заказывать сетевое соединение у фирмы-поставщика средств дальней связи(например, AT&T) и использовать его для передачи траффика Интернета.
Читатели, которые знают об общественных сетях с коммутацией пакетов, могут найти X25NET странной, так как такие сети используют только протоколы МККТТ Х.25, в то время как Интернет использует протоколы TCP/IP. Тем не менее, когда она используется для транспортировки траффика TCP/IP, сеть Х.25 просто обеспечивает путь, по которому может быть передан траффик Интернета. Мы уже установили, что многие базовые технологии могут использоваться для передачи траффика Интернета. Эта технология, иногда называемая туннельная передача(tunneling), просто означает, что сложная сеть со своими собственными протоколами рассматривается как еще одна аппаратная система доставки пакетов. Чтобы послать траффик TCP/IP по туннелю Х.25, надо установить соединение Х.25, а затем послать пакеты TCP/IP, как будто это данные. Система Х.25 передаст пакеты по соединению и доставит их в другую точку Х.25, где они должны быть собраны и отправлены к своему истинному назначению. Так как туннелирование рассматривает пакеты как данные, оно не обеспечивает самоидентифицирующиеся кадры. Поэтому, оно работает только в том случае, когда оба конца соединения Х.25 заранее договорились о том, что они будут передавать пакеты Х.25.
Что делает Х.25 особенным, так это его интерфейс. В отличие от большинства сетевого оборудования протоколы Х.25 обеспечивают надежный поток передаваемых данных, иногда называемый виртуальным каналом, между отправителем и получателем, в то время как протоколы Интернета предназначены для системы доставки пакетов, что делает их несовместимыми.
Представление о соединениях Х.25, как о путях доставки, приводит к интересному приему. Оказывается, что сети Х.25 показывают гораздо лучшую пропускную способность при нескольких одновременно открытых соединениях. Поэтому, вместо открытия одного соединения с данным местом доставки, отправитель Х25NET часто открывает несколько соединений и распределяет пакеты между ними для улучшения производительности. Получатель принимает пакеты со всех соединений Х.25 и снова объединяет их вместе.
Схема адресации, используемая сетями Х.25, определена в стандарте, известном как Х.121. Каждый из физических адресов Х.121 является числом из 14 цифр, в котором 10 цифр назначаются производителем, который обеспечивает средство сети Х.25. Напоминая телефонные номера, одна из популярных схем назначения номеров производителями включает код области, основанный на географическом положении. Такой подход не удивителен, так как он был предложен организацией, определяющей международные телефонные стандарты. К сожалению, эта схема неудобна, так как затрудняет назначение Интернетовских адресов. Пользователи, использующие X25NET, должны хранить таблицу отображения Интернетовского адреса в адрес Х.25 и обратно. Глава 6 рассматривает проблему отображения адресов более детально и дает альтернативу использованию фиксированных таблиц.
Так как общественные сети Х.25 работают независимо от Интернета, должно существовать место соединения между ними. Как DARPA, так и CSNET используют специально выделенные машины для обеспечения соединения между Х.25 и ARPANET. Основное соединение известно как VAN-шлюз. Этот шлюз поддерживает соединения Х.25 и маршрутизирует приходящий траффик Интернета к его получателям. X25NET является важной, так как она иллюстрирует гибкость и адаптируемость протоколов TCP/IP. В частности, она показывает, как туннельная передача делает возможным использование очень широкого диапазона сложных сетевых технологий в межсетевой среде.
Большинство сетевых технологий, которые мы рассмотрели, достаточно дороги. Но в число тех, кому нужен доступ к Интернету, входят не только большие институты, напрямую соединенные с главными магистральными сетями, такими как NSFNET; доступ к нему нужен также маленьким школам и просто отдельным людям. Маленькие институты не могут позволить себе высокоскоростные выделенные линии, или оборудование, соединяющее с ними. Cypress предназначен для удовлетворения потребности в доступе с помощью дешевой низкоскоростной технологии TCP/IP.
Cypress состоит из миникомпьютеров, соединенных низко- или среднескоростными выделенными линиями(от 9.6 Кбит/с до 56 Кбит/с). Каждый миникомпьютер размещается в пользовательском узле, где он соединен с локальной вычислительной средой с помощью ЛВС Ethernet. С остальной частью Cypress он соединяется по выделенным последовательным линиям. Как минимум один узел в сети Cypress соединен с Интернетом и передает траффик между сетью Cypress и остальной частью Интернета.
Первоначально Cypress разрабатывался для топологии типа "виноградная кисть", в которой каждый новый узел соединялся последовательной линией с ближайшим к нему узлом. Преимуществом использования такой топологии была ее дешевизна; недостатком была большая величина паузы при передаче, становящаяся значительной для траффика, который передавался через несколько промежуточных машин. Топология Cypress была изменена по двум причинам:во-первых, NSFNET значительно увеличил число потенциальных точек соединения с Интернетом, и во-вторых, большинству пользователей показалось, что лучше платить больше, но иметь меньшие паузы при передаче. Поэтому сеть Cypress приняла вид одного концентратора, размещенного в университете Пурдью, который был соединен с NSFNET.
Cypress основывался на нескольких ключевых идеях. Во-первых, для достижения дешевизны Cypress объединяет возможности, используя один компьютер для выполнения нескольких задач. Во-вторых, как и Ethernet, протоколы Cypress используют негарантированную доставку, не делая попыток исправить ошибки или восстановить потерянные пакеты на канальном уровне. Следующие главы объяснят, почему негарантированная доставка работает хорошо в среде TCP/IP. В-третьих, Cypress работает как сеть, а не как набор выделенных линий точка-точка. В-четвертых, Cypress соединен с сетями в узлах его пользователей, а не просто с машинами. Поэтому большое количество хостов в узле пользователя могут использовать соединение Cypress, рассматривая его как путь остальной части Интернета. В-пятых, Cypress позволяет своим маршрутизаторам быть управляемыми с любого узла в Интернете, так как он использует IP для передачи информации об их состоянии. Миникомпьютеры, составляющие сеть Cypress, называются имплетами(implet), и каждый имплет обеспечивает три концептуальные функции в одной машине. На самом нижнем уровне, имплет работает как маршрутизатор пакетов, принимая пакеты из последовательных линий и направляя их к их получателю, используя при этом аппаратные адреса в кадре для выбора маршрута. На следующем уровне, имплет соединяет две сети, локальный Ethernet в узле пользователя и сеть Cypress. На самом высоком уровне имплет является компьютером общего назначения, который выполняет программы управления сетью и слежения за ней как пользовательские процессы.
Помимо своего технического вклада в сетевые технологии, Cypress демонстрирует три важных идеи. Во-первых, он иллюстрирует, почему сетевую скорость нужно рассматривать как меру пропускной способности. Узлы с небольшим траффиком воспринимают Cypress как адекватную, надежную технологию соединения между ними. В нем низкие скорости не означают ограниченных возможностей. Во-вторых, Cypress показывает, что протоколы Интернета хорошо работают в системах с негарантированной доставкой с простыми протоколами канального уровня. В-третьих, Cypress показывает, что разработка программного обеспечения для управления и слежения за сетью с использованием протоколов Интернета делает слежение гибким, а исправление отказов оборудования легким.
Другой интересный способ использования TCP/IP, освоенный CSNET, включает работу протоколов TCP/IP в коммутируемой телефонной сети. Узлы CSNET, использующие Интернет редко, могут быть не в состоянии платить за выделенные линии. Для этих узлов CSNET разработал систему коммутируемого IP, которая работает следующим образом: всякий раз, когда нужно соединение, программное обеспечение в узле пользователя использует модем для создания соединения с концентратором(hub) CSNET через телефонную сеть. Компьютер в концентраторе отвечает на телефонный вызов и, после получения подтверждения подлинности пользователя, передает траффик между этим узлом и другими компьютерами Интернета.
Один из самых интересных экспериментов DARPA в области коммутации пакетов привел к созданию технологии, которая использовала широковещание по радио для передачи пакетов. Разработанное для военных условий, в которых станции могут быть мобильными, пакетное радио включает оборудование и программное обеспечение, которое позволяет узлам находить другие узлы, устанавливать соединение точка-точка, а затем использовать это соединение для передачи пакетов. Так как узлы меняют свое географическое положение и могут выходить за границы связи, система должна постоянно контролировать связность и перевычислять пути для отражения изменений в топологии. Рабочая система пакетного радио была создана и использовалась для демонстрации соединения TCP/IP между удаленным узлом пакетного радио и другими узлами Интернета.
Мы рассмотрели несколько технологий работы сетевого оборудования, используемых протоколами TCP/IP, которые лежат в диапазоне от высокоскоростных ЛВС, таких как Ethernet и proNET-10, до более медленных глобальных сетей, таких как ARPANET и Cypress. Мы также увидели, что протоколы TCP/IP могут работать над другими протоколами сетей общего пользования, используя технологию, названную туннельной передачей. В то время как детали конкретных сетевых технологий не важны, общая идея заключается в следующем:
Протоколы TCP/IP являются крайне гибкими в том отношении, что почти любая базовая технология может использоваться для передачи траффика TCP/IP.
2.1 Установите, какие сетевые технологии использует ваш узел.
2.2 Каков максимальный размер пакета, который может быть послан по высокоскоростной сети, такой как HyperChannel NSC или UltraNet Ultra Network Technologies?
2.3 В чем заключаются преимущества и недостатки туннельной передачи?
2.4 Прочитайте стандарт Ethernetа, чтобы найти точную информацию о паузе(gap) между пакетами и размере преамбулы.
2.5 Какая характеристика спутникового коммуникационного канала является наиболее желательной ? А наименее желательной ?
2.6 Установите нижнюю границу времени, которое занимает передача 5 мегабайтного файла по сети, которая работает со скоростями: 9600 бит/с, 56 Кбит/с, 10 Мбит/с, 100 Мбит/c и 2 Гбит/с.
Назад | Содержание | Вперед
Важно понимать, что Интернет не является новым видом физической сети. На самом деле это метод взаимного соединения физических сетей и набор соглашений для использования сетей, которые позволяют компьютерам взаимодействовать друг с другом. В то время как аппаратная технология играет небольшую роль при концептуальном проектировании, важно понимать разницу между низкоуровневыми механизмами, обеспечиваемыми самим оборудованием, и высокоуровневыми средствами, которые обеспечивает программное обеспечение протоколов Интернета. Также важно понимать, как средства, обеспечиваемые технологией коммутации пакетов, влияют на наш выбор абстракций высокого уровня.
Эта глава вводит основные понятия коммутации пакетов и терминологию. а затем рассматривает базовые технологии сетевого оборудования, которые использовались в объединенной сетях TCP/IP. Следующие главы описывают, как эти сети объединяются и как протоколы TCP/IP согласованы с различиями в оборудовании. В то время как список сетей, представленный здесь, не является исчерпывающим, он хорошо демонстрирует разнообразие физических сетей, над которыми работает TCP/IP.Читатель может спокойно пропустить большую часть технических деталей, но должен попытаться понять идею пакетной коммутации и должен попытаться представить архитектуру однородной коммуникационной системы, использующей такое разнообразное оборудование. Более того, читатель должен внимательно изучить детали схем физических адресаций в различных используемых технологиях; следующие главы рассмотрят детально, как протоколы высокого уровня используют эти физические адреса.
Независимо от того, обеспечивают ли они соединение между компьютерами или между компьютерами и терминалами, коммуникационные сети могут быть разделены на два основных типа: с коммутацией каналов и коммутацией пакетов. Сети с коммутацией каналов работают, образуя выделенное соединение(канал) между двумя точками. Телефонная сеть США использует технологию с коммутацией каналов - телефонный вызов устанавливает канал от вызывающего телефона через локальную АТС, по линиям связи, к удаленной АТС, и, наконец, к отвечающему телефону. Пока существует канал, телефонное оборудование постоянно опрашивает микрофон, кодирует полученное значение в цифровой форме, и передает его по этому каналу к получателю. Отправителю гарантируется, что опросы будут доведены и воспроизведены, так как канал обеспечивает скорость 64 Кбит/с, которой достаточно для передачи оцифрованного голоса. Преимущество коммутации каналов заключается в ее гарантированной пропускной способности: как только канал создан, ни один сетевой процесс не уменьшит пропускной способности этого канала. Недостатком при коммутации каналов является ее стоимость: платы за каналы являются фиксированными и независимыми от траффика. Например, можно заплатить за телефонный вызов, даже если две разговаривающие стороны вообще ничего не говорили.
Сети с коммутацией пакетов, тип обычно используемый при соединении компьютеров, используют совершенно другой подход. В сетях с коммутацией пакетов траффик сети делится на небольшие части, называемые пакетами, которые объединяются в высокоскоростных межмашинных соединениях. Пакет, который обычно содержит только несколько сотен байтов данных, имеет идентификатор, который позволяет компьютерам в сети узнавать, предназначен ли он им, и если нет, то помогает им определить, как послать его в указанное место назначения. Например, файл, передаваемый между двумя машинами, может быть разбит на большое число пакетов, которые посылаются по сети по одному. Оборудование сети доставляет пакеты к указанному месту назначения, а сетевое программное обеспечение собирает пакеты опять в один файл. Главным преимуществом коммутации пакетов является то, что большое число соединений между компьютерами может работать одновременно, так как межмашинные соединения разделяются между всеми парами взаимодействующих машин. Недостатком ее является то, что по мере того как возрастает активность, данная пара взаимодействующих компьютеров получает все меньше сетевой пропускной способности. То есть, всякий раз, когда сеть с коммутацией пакетов становится перегруженной, компьютеры, использующие сеть, должны ждать, пока они не смогут послать следующие пакеты.
Несмотря на потенциальный недостаток негарантируемой сетевой пропускной способности, сети с коммутацией пакетов стали очень популярными. Причинами их широкого использования являются стоимость и производительность. В связи с тем, что к сети может быть подключено большое число машин, требуется меньше соединений и стоимость остается низкой. Так как инженеры смогли создать высокоскоростное сетевое оборудование, с пропускной способностью обычно проблем не возникает. Так много компьютерных соединений использует коммутацию пакетов, что далее в книге термин СЕТЬ будет обозначать только сеть с коммутацией пакетов.
Сети с коммутацией пакетов, которые разрослись до больших географических размеров(например, континентальной части США), сильно отличаются от сетей, имеющих небольшие размеры(например, одну комнату). Чтобы помочь охарактеризовать различия в пропускной способности и способах использования, технологии коммутации пакетов часто делят на три большие категории: глобальные сети(WAN), городские сети(MAN) и локальные сети(LAN). Технологии WAN, иногда называемые long haul networks(буквально - сети дальних перевозок), позволяют взаимодействующим местам быть достаточно далеко друг от друга и предназначены для использования на больших расстояниях. Обычно WAN работают на более низких скоростях, чем другие технологии, и имеют гораздо большие паузы при соединении. Обычно скорости WAN лежат в диапазоне от 9.6 Кбит/с до 45 Мбит/с.
Самый новый вид сетевого оборудования, технологии MAN позволяют взаимодействовать в географических областях средних размеров и работают на скоростях от средних до высоких. Они получили такое имя из-за способности одной MAN занимать область размером с большой город. MAN работают с меньшими паузами, чем WAN, но не могут обеспечить взаимодействие на таких же больших расстояниях. Типичные MAN работают со скоростями от 56 Кбит/с до 100 Мбит/с.
Технологии LAN обеспечивают наивысшие скорости соединений между компьютерами, но не позволяют им занимать большие области. Например, типичная LAN занимает пространство, такое же как одно здание или небольшой университетский городок, и работает со скоростями от 4 Мбит/с до 2 Гбит/с.
Мы уже говорили о компромиссе между скоростью и расстоянием: технологии, обеспечивающие более высокие скорости взаимодействия, работают на более коротких расстояниях. Существуют и другие различия среди технологий в указанных выше трех категориях. В технологиях LAN каждый компьютер обычно содержит сетевое интерфейсное устройство, которое соединяет машину напрямую с сетевой средой передачи данных(например, медным проводом или коаксиальным кабелем). Часто сеть является пассивной, полагая, что электронные устройства в присоединенных компьютерах сами будут генерировать и получать необходимые электрические сигналы. В технологиях MAN сеть содержит активные коммутирующие элементы, которые приводят к появлению коротких задержек при направлении данных к их назначению. В технологиях WAN сеть обычно состоит из групп сложных маршрутизаторов пакетов, соединенных линиями связи. Сеть может быть расширена добавлением нового маршрутизатора и еще одной линии связи. Присоединить компьютер к WAN значит соединить его с одним из маршрутизаторов пакетов. Эти маршрутизаторы вводят значительные паузы при маршрутизации траффика. Поэтому, чем больше становится WAN, тем больше времени ей надо для маршрутизации траффика.
Целью разработки сетевых протоколов является скрыть технологические различия между сетями, сделав соединение независимым от используемого оборудования. Следующие секции содержат шесть примеров сетевых технологий, используемых в Интернете, показывая при этом различия между ними. Следующие главы показывают, как программное обеспечение TCP/IP скрывает такие различия и делает коммуникационную систему независимой от базовой аппаратной технологии.
Ethernet - это имя, данное популярной технологии локальной сети с коммутацией пакетов, разработанной в Xerox PARC в начале 1970 года. Версия, описанная здесь, была стандартизована Xerox Corporation, Intel Corporation и Digital Equipment Corporation в 1978 году. Как показано на рисунке 2.1, Ethernet состоит из коаксиального кабеля приблизительно полдюйма в диаметре и до 500 метров длиной. Между центральным проводом и защитной оболочкой на каждом конце добавляется резистор для предотвращения отражения электрических сигналов. Называемый ether(для удобства будем называть его просто Е-кабель), этот кабель является полностью пассивным; все активные электронные компоненты, выполняющие сетевую функцию, связаны с компьютерами, присоединенными к сети.
+------------+<=============внешняя изолирующая оболочка
|+----------+|
|| <============полиэтиленовый заполнитель
|| ||
|| == |<===============металлическая оболочка
|| =<== ||
|| \ ||
|+---------\+|
+-----------============центральный провод
Рисунок 2.1 Коаксиальный кабель, иcпользуемый в Ethernet
Ethernet'ы могут быть дополнены устройствами, называемыми повторителями, которые передают электрические сигналы от одного кабеля к другому. Рисунок 2.2 показывает типичное использование повторителей в здании фирмы. Один вертикальный магистральный кабель проложен через все этажи здания, и повторитель соединяет дополнительные кабели на каждом этаже с магистральным кабелем. Компьютеры присоединяются к кабелям, проложенным на каждом этаже. Только два повторителя могут быть помещены между любыми двумя машинами, поэтому общая длина простого Ethernetа довольно маленькая(до 1500 метров).
Расширение Ethernetа, используя повторители, имеет свои преимущества и недостатки. Повторители менее избыточны, чем другие типы соединяющего оборудования, что делает их самым дешевым способом расширения Ethernetа. Тем не менее, повторители имеют два недостатка. Во-первых, так как повторители повторяют и усиливают все электрические сигналы, то они копируют шумы, возникающие в одном проводе, в другой провод. Во-вторых, так как они содержат активные электронные компоненты, требующие энергии, они могут выйти из строя. В здании авария может произойти в неудобном месте(например, между перекрытиями или в розетке), делая трудным ее нахождение и устранение.
| ___________________________
| | | | | | | Этаж 3
|--O K K K K K
|
| ___________________________
| | | | | | | Этаж 2
|--O K K K K K
|
| ___________________________
| | | | | | | Этаж 1
|--O K K K K K
| \
\________ повторитель
Рисунок 2.2 Повторители, используемые для соединения кабелей Ethernetа в здании. Самое большее два повторителя могут быть помещены между парой взаимодействующих машин.
Соединения с E-кабелем делаются с помощью ответвлений, как показывает рисунок 2.3. При каждом ответвлении маленькая дырка во внешних слоях кабеля позволяет маленьким контактам касаться центрального провода и защитной металлической оболочки(некоторые производители требуют, чтобы кабель был разрезан и вставлен Т-образный соединитель). Каждое соединение с Ethernetом имеет две основные электрические компоненты. Трансивер присоединяется к центральному проводу и металлической оплетке на Е-кабеле, принимая и передавая сигналы. Интерфейс с ЭВМ соединяется с трансивером и взаимодействует с компьютером(обычно через шину компьютера).
Трансивер - это небольшая часть оборудования, физически смежная с Е-кабелем. Помимо аналогового оборудования, которое принимает сигналы от Е-кабеля и управляет им, трансивер содержит цифровые схемы, которые позволяют ему взаимодействовать с цифровым компьютером. Трансивер может определить, когда Е-кабель используется, и может транслировать аналоговые электрические сигналы, идущие по Е-кабелю, в цифровую форму или из нее в аналоговую. По кабелю трансивера, находящемуся между трансивером и интерфейсом ЭВМ, передается питание трансивера, а также сигналы, управляющие его работой.
Рисунок 2.4 показывает соединение между компьютером и трансивером. Каждый интерфейс ЭВМ управляет работой одного трансивера согласно командам, которые он получает от программного обеспечения компьютера. Для операционной системы интерфейс представляется в виде устройства ввода-вывода, которое воспринимает основные команды передачи данных от компьютера, управляет трансивером при их выполнении, прерывается, когда задача завершается, и сообщает информацию о состоянии. В то время как трансивер - это простое аппаратное устройство, интерфейс с ЭВМ может быть сложным(например, он может содержать микропроцессор, используемый для управления передачей данных между памятью компьютера и Е-кабелем).
______________________
/-\ ___________ \
___/_ \ \ \ |
центральный провод /--\ \ \ \ \ |
\ / \ | | | | |
-------|-- | | | |----------| |
__\ / | | | | | |
металлическая оплетка/ \--/_____/ / / | / |
\ / /___|______/ |
\-/________|____|_______/
| |
(a) ---------------
| |
| трансивер |
(b) | |
---------------
|
_______________________________ | к интерфейсу
| | | | ЭВМ
| | ...... | V
| | |
O O O
Рисунок 2.3 (а) Наглядное представление кабеля, показывающее детали двух электрических соединений между трансивером и кабелем при ответвлении, и (b) схематическая диаграмма Ethernetа с группой ответвлений.
Ethernet - это технология общей шины со скоростью 10 Мбит/с , с механизмом негарантированной(best effort) доставки и распределенным управлением доступом. Она называется технологией общей шины из-за того, что все станции разделяют один общий канал взаимодействия; она - широковещательная, так как все трансиверы принимают информацию, передаваемую всеми станциями. Метод, используемый для передачи пакетов от одной станции к другой или к группе станций, будет рассмотрен позднее. На данный момент достаточно уяснить, что трансиверы не фильтруют информацию - они передают все пакеты на интерфейс ЭВМ, который выбирает из них нужные этой ЭВМ и отбрасывает другие пакеты. Ethernet называется механизмом негарантированной доставки, так как он не информирует отправителя о том, был ли доведен пакет до получателя. Например, если случилось так, что машина получателя выключена, пакет будет потерян, но отправитель ничего не будет знать об этом. мы увидим позднее, как протоколы TCP/IP согласованы с оборудованием с негарантированным доведением.
Ethernet
_______________________________________________________
|
|
------- трансивер
| |<------ | | ... | / / \ / /<-------шина компьютера \_____ / / | / / / | | / | |<---------------плата интерфейса компьютера | | / | |/ |||||-- |||||/ / / / / / / /... /
Рисунок 2.4 Соединение между кабелем Ethernet и компьютером
Управление доступом в Ethernetе распределенное, так как, в отличие от некоторого другого сетевого оборудования, здесь нет централизованной схемы предоставления доступа. Схема доступа Ethernetа называется множественным доступом с контролем несущей и обнаружением коллизий(CSMA/CD). Она является CSMA, так как несколько машин могут получить доступ к Ethernetу одновременно, и каждая машина определяет, занят ли Е-кабель, по наличию несущей в нем. Когда интерфейс компьютера имеет пакет, который нужно передать, он слушает Е-кабель, чтобы узнать, передается ли уже чье-то сообщение(т.е. определяет наличие несущей). Когда передачи не обнаружено, интерфейс компьютера начинает передачу. Каждая передача ограничена в своей продолжительности(так как существует максимальный размер пакета). Более того, оборудование должно делать небольшие паузы между передачами пакетов, чтобы не получилось так, что сеть используется одной парой машин, и чтобы другие машины тоже имели возможность доступа к сети.
Когда трансивер начинает передачу, сигнал не достигает всех частей сети одновременно. На самом деле он передается по кабелю со скоростью, составляющей примерно 80% от скорости света. Поэтому возможна ситуация, когда два трансивера могут определить, что сеть незанята, и одновременно начать передачу. Когда два электрических сигнала передаются одновременно, они перемешиваются, в результате чего оба становятся искаженными. Такие события называются коллизиями.
Ethernet обрабатывает коллизии оригинальным способом. Каждый трансивер следит за состоянием кабеля, когда он передает , чтобы узнать, когда другой сигнал помешал его передаче. На техническом языке такое слежение называется обнаружением коллизий и делает Ethernet сетью CSMA/CD. Когда коллизия обнаружена, интерфейс ЭВМ аварийно завершает передачу, ждет конца работы других станций и снова пытается повторить передачу. При этом нужно соблюдать осторожность, иначе сеть может оказаться перегруженной трансиверами, впустую пытающимися передавать, причем каждая передача будет приводить к коллизии. Чтобы избежать таких ситуаций, Ethernet использует стратегию двоичной экспоненциальной задержки, при которой отправитель ждет случайное время после первой коллизии, в два раза дольше, если вторая попытка передать, также привела к коллизии, в четыре раза дольше, если третья попытка привела к коллизии, и так далее. Идея, лежащая в основе экспоненциальной задержки, заключается в том, что при коллизии возможно, что большое число станций будет пытаться передавать одновременно и может возникнуть большие помехи для траффика. При таких помехах существует большая вероятность того, что две станции выберут похожие времена задержки. Поэтому вероятность того, что возникнет новая коллизия, велика. С помощью удвоения случайного времени задержки стратегия экспоненциальной задержки быстро распределяет попытки повторной передачи станций на достаточно большой промежуток времени, что делает вероятность дальнейших коллизий крайне маленькой.
Стандартный Ethernet работает со скоростью 10 Мбит/с, что означает, что данные могут передаваться по кабелю со скоростью 10 миллионов бит в секунду. Хотя многие современные компьютеры могут генерировать данные со скоростью Ethernetа, реальную скорость сети не следует представлять как скорость, с которой два компьютера обмениваются данными. На самом деле скорость сети является мерой пропускной способности общего траффика сети. Представьте сеть в виде высокоскоростной магистрали(highway), соединяющей группу городов. Высокие скорости при движении по магистрали означают, что она может выдержать большую загрузку траффиком, а низкие скорости - что эта магистраль не может выдержать большой объем траффика. Ethernet со скоростью 10 Мбит/с, например, может выдержать несколько компьютеров, генерирующих высокоскоростной траффик или большое число компьютеров, генерирующих медленный траффик.
Последние достижения в технологии сделали возможным создание Ethernetа, который нуждается в электрической изоляции коаксиального кабеля. Называемая Ethernet - витая пара, эта технология позволяет обычному Ethernetу со скоростью 10 Мбит/c передаваться по паре медных проводов, во многом похожих на те, которые используются для соединения телефонов. Преимущество использования витой пары состоит в том, что она дешевле и позволяет многим группам использовать существующие кабеля вместо установки новых.
Когда высокая пропускная способность не нужна, сеть может использовать Ethernet-подобную технологию, но работать на несколько меньших скоростях. Преимущество здесь в основном экономическое. Меньшие скорости означают более простое оборудование и меньшую цену. Одной из причин того, что более низкие скорости сети приводят к уменьшению ее цены, является то, интерфейсы требуют меньше буферной памяти и могут быть созданы на основе простых(и дешевых) интегральных микросхем.
Уменьшения цены можно также добиться, если высокоскоростные цифровые микросхемы соединить напрямую с кабелем, не используя трансивер. В этом случае Ethernet может быть создан с помощью стандартного коаксиального кабеля, такого, который используется для кабельного телевидения. Называемый Ethernet - тонкая пара, этот тонкий кабель является недорогим, но поддерживает меньшее число соединений и может работать только на более коротких расстояниях, чем стандартный Ethernet-овский кабель.
Производители рабочих станций обнаружили, что Ethernet-тонкий кабель особенно привлекателен из-за того, что они могут интегрировать Ethernet-овское оборудование в одноплатные компьютеры и смонтировать BNC-разъемы прямо в задней стенке машины. Не требуя специальных средств, BNC-разъемы делают возможным для пользователей присоединение их рабочих станций к Ethernet-у. Конечно, предоставление пользователям возможности добавлять их машины к сетям имеет свои недостатки. Это означает, что сеть будет чувствительной к разъединениям, неправильным соединениям кабелей, и другим ошибкам. Но в большинстве случаев преимущества перевешивают недостатки.
При другом методе уменьшения цены используется один физический кабель для передачи нескольких Ethernet-ов. Известная как широкополосная, эта технология работает аналогично широковещательному радио. Передатчик объединяет несколько Ethernet-ов в одном кабеле, назначая каждому Ethernet-у уникальную частоту. Приемники должны быть настроены на правильную частоту , чтобы они принимали только нужный сигнал и игнорировали остальные. Хотя оборудование, требуемое для присоединения к широковещательному кабелю, более дорогое, чем оборудование для соединения с обычным кабелем, при широковещании не нужно платить за прокладку нескольких кабелей.
Интерфейс ЭВМ Ethernetа поддерживает механизм адресации , который позволяет передавать на компьютер только нужные пакеты. Напомним, что каждый интерфейс получает копию каждого пакета - даже если они адресованы другим машинам. Это оборудование фильтрует пакеты, игнорируя те, которые адресованы другим машинам, и передает в компьютер те, которые адресованы ему. Механизм адресации и фильтрации требуется, чтобы предохранить компьютер от перегрузки приходящими данными.
Чтобы позволить компьютеру определить, какие пакеты назначены ему, каждому компьютеру, соединенному с Ethernet-ом, назначено 48-битовое число, называемое Ethernet-овским адресом. Производители оборудования для Etherneta приобретают блоки адресов Ethernetа и последовательно назначают эти адреса производимым ими интерфейсам для Ethernetа(Институт Инженеров по Электротехнике и Радиотехнике(IEEE) управляет адресным пространством Ethernetа и назначает адреса по мере необходимости). Поэтому никакие два интерфейса не будут иметь одинаковый адрес Ethernetа.
Обычно Ethernet-овский адрес фиксируется в оборудовании интерфейса компьютера. Так как адреса Ethernetа принадлежат аппаратным устройствам, то они иногда называются аппаратными адресами или физическими адресами. Отметим следующее важное свойство физических адресов Ethernetа:
Физические адреса связаны с интерфейса Ethernetа; установка интерфейса на новую машину или замена неисправного интерфейса изменяет его физический адрес.
Зная, что физические адреса Ethernetа могут меняться, легко понять, почему более высокие уровни сетевого математического обеспечения согласованы с такими изменениями. 48-битовый адрес Ethernetа не только определяет отдельный аппаратный интерфейс. Он может принадлежать одному из трех типов:
По соглашению широковещательный адрес(все единицы) зарезервирован для одновременной посылки всем станциям. Групповые адреса обеспечивают ограниченную форму широковещания, при которой группа компьютеров в сети согласна отвечать на групповой адрес. Каждый компьютер в такой группе может получать сообщения одновременно с другими компьютерами этой группы, при этом остальные машины в сети ничего не получают.
Для согласования с широковещательной и групповой адресацией интерфейс Ethernetа должен распознавать не только свой физический адрес. Интерфейс обычно принимает по крайней мере два вида передач: адресованные физическому адресу интерфейса и адресованные широковещательному адресу. Некоторые интерфейсы могут быть запрограммированы на распознавание групповых адресов или даже альтернативных физических адресов. Когда операционная система начинает работать, она инициализирует интерфейс Ethernetа, задавая ему набор адресов, который он должен распознавать. В дальнейшем интерфейс сканирует каждую передачу, передавая на компьютер только передачи, предназначенные одному из указанных адресов.
Ethernet можно представлять как соединение канального уровня между машинами. Поэтому имеет смысл рассматривать передаваемые данные как кадры(фреймы)(Термин фрейм (граница) ведет свое происхождение от передачи по последовательным линиям, в которых отправитель определял границы данных, добавляя специальные символы перед и после передаваемых данных). Кадры Ethernetа имеют переменную длину в пределах от 64 октетов(октетом называется блок из 8 бит, чаще называемый байтом) до 1518 октетов (заголовок, данные, ЦКС). Как и во всех сетях с коммутацией пакетов, кадр должен идентифицироваться свое назначение. Рисунок 2.5 показывает формат кадра Ethernetа, который содержит физический адрес отправителя, а также физический адрес получателя.
Помимо идентификации отправителя и получателя, каждый кадр, передаваемый по Ethernetу, содержит преамбулу, поле типа, поле данных и циклическую контрольную сумму(CRC) или ЦКС. Преамбула состоит из 64 битовой последовательности 1 и 0 и служит для облегчения синхронизации при приеме. 32-битовая ЦКС помогает интерфейсу обнаружить ошибки передачи: отправитель вычисляет ЦКС как функцию от данных, передаваемых в кадре, а получатель заново вычисляет ЦКС для того, чтобы быть уверенным в том, что пакет принят без ошибок.
Поле типа кадра содержит 16-битовое целое число, которое идентифицирует тип данных, передаваемых в кадре. С точки зрения Интернета поле типа кадра очень важно, так как это означает, что кадры Ethernetа являются самоидентифицирующимися. Когда кадр приходит на данную машину, операционная система использует тип кадра, чтобы определить, какой программный модуль обработки протоколов должен обработать это кадр. Главные преимущества самоидентифицирующихся кадров заключаются в том, что они позволяют одновременно использовать несколько протоколов на одной машине и в том, что они позволяют нескольким протоколам смешиваться при работе в одной физической сети. Например, кто-то может иметь прикладную программу, использующую Интернетовские протоколы, а кто-то использовать локальный экспериментальный протокол. Операционная система будет определять, кому послать приходящие пакеты, основываясь на значении поля типа кадра. Мы увидим, что протоколы TCP/IP используют самоидентифицирующиеся кадры Ethernetа для выделения себя среди других протоколов.
адрес адрес тип
преамбула получателя отправителя кадра данные ЦКС
---------------------------------------------------------------
| 64 бита | 48 бит | 48 бит |16 бит|368-12000 бит| 32 бита|
---------------------------------------------------------------
Рисунок 2.5 Формат кадра(пакета) в том виде, в котором он передается по Ethernetу. Размеры полей не соотносятся друг с другом.
Мы уже рассматривали использование Ethernet-овских повторителей как одну из технологий расширения физического Ethernetа до нескольких физических кабельных сегментов. Хотя повторители как способ расширения были популярны много лет тому назад, многие теперь используют мосты для соединения сегментов. В отличие от повторителя, который повторяет электрические сигналы, мост повторяет пакеты. Фактически мост - это быстрый компьютер с двумя интерфейсами Ethernetа и фиксированной программой. Мост работает с обоими интерфейсами Ethernetа в режиме "без разбора", то есть интерфейсы перехватывают все корректные пакеты, появляющиеся в Ethernetах, к которым они присоединены, и предоставляют их процессору моста. Если мост соединяет два Ethernetа, Е1 и Е2, то программное обеспечение берет каждый пакет, полученный из Е1 и передает его в Е2, и наоборот.
Мосты являются более передовыми по отношению к повторителям, так как они не повторяют шум, ошибки, или испорченные кадры; должны быть получены полностью корректные кадры, чтобы они были продублированы. Более того, интерфейсы мостов следуют правилам CSMA/CD Ethernetа, поэтому коллизии и паузы при распространении в одном кабеле(сегменте) остаются изолированными от тех же явлений в других сегментах. В результате мостами может быть соединено почти любое число Ethernetов. Отметим, что мосты скрывают детали соединения: набор сегментов, связанных мостами, функционирует как один Ethernet. Компьютер может связываться с другими машинами через мосты, используя такие же аппаратные сигналы, как те, которыми он пользуется для связи в своем сегменте.
Большинство мостов не передают кадры с одного кабеля на другой: они принимают решения о том, какие кадры нужно передавать на другой сегмент, а какие нет. Такие мосты называются адаптивными, или обучающимися мостами. Адаптивный мост состоит из компьютера с двумя интерфейсами Ethernetа. Программное обеспечение адаптивного моста хранит два списка адресов, по списку для каждого интерфейса. Когда кадр приходит из Ethernetа Е1, адаптивный мост добавляет 48-битовый Ethernet-овский адрес отправителя в список, связанный с Е1. Аналогично, когда кадр приходит из Е2, мост добавляет адрес отправителя к списку, связанному с Е2. Поэтому, по прошествии некоторого времени адаптивный мост узнает, какие машины находятся в Е1, а какие в Е2.
После записи адреса отправителя кадра, адаптивный мост использует адрес получателя, чтобы определить, нужно ли передавать кадр в другой сегмент. Если список адресов показывает, что получатель находится в Ethernete, из которого прибыл кадр, то мост не передает этот кадр в другой сегмент. Если же получателя нет в списке адресов(т.е. получатель - это широковещательный или групповой адрес, или мост еще не знает местонахождение получателя), мост отправляет кадр в другой Ethernet.
Преимущества адаптивных мостов очевидны. Так как мост использует адреса, выделяемые из обычного траффика, он полностью автономен - человеку не требуется задавать мосту конкретные адреса. Так как мост изолирует траффик, когда передача не нужна, он может улучшить производительность перегруженной сети(заметим, что мосты работают исключительно хорошо при разделении загрузки по районам(сегментам) в среде рабочих станций, в которой группы рабочих станций большую часть своего траффика адресуют файл-серверу).
Обобщим вышеизложенное:
Адаптивный Ethernet-овский мост соединяет два сегмента Ethernetа, передавая кадры из одного в другой. Он использует адреса отправителей для того, чтобы узнать, в каком сегменте Ethernetа находится та или иная машина, и применяет полученную информацию к адресам получателя, чтобы не передавать пакеты в другой сегмент, когда это не нужно.
С точки зрения TCP/IP, Ethernetы, связанные мостом, просто являются другой формой физического сетевого соединения. Важным моментом является то, что:
Так как соединение с помощью физических проводов, обеспечиваемое мостами и повторителями, прозрачно для машин, использующих Ethernet, мы будем представлять Ethernetы, связанные мостами, как одну физическую сетевую систему.
Большинство коммерческих мостов являются более сложными и более надежными, чем это следует из нашего описания. При включении питания они ищут другие мосты и приобретают информацию о топологии сети. Они используют алгоритм распределенного дерева распространения(spanning-tree) при принятии решения о том, куда передавать кадры. В частности, мосты решают, как распространять широковещательные пакеты так, чтобы по каждому кабелю передавалась только одна копия широковещательного кадра. Без такого алгоритма для Ethernetов и мостов, связанные в виде кольца, такие пакеты привели бы к катастрофическим результатам, так как пришлось бы постоянно передавать широковещательные пакеты в обе стороны.
ProNET-10 - это имя коммерческого сетевого продукта для ЛВС, который является интересной альтернативой Ethernetу. Основанный на сетевых исследованиях в университетах, и созданный Proteon Incorporated, proNET-10 состоит из пассивной кабельной системы, которая соединяет компьютеры. Как и Ethernet, низкоскоростная версия работает со скоростью 10 Мбит/с, ограничена короткими расстояниями, и требует, чтобы присоединяемые компьютеры имели активные интерфейсы с ЭВМ.
В отличие от Ethernetа или других аналогичных шинных технологий, proNET-10 требует, чтобы компьютеры были соединены кабелями в одиночное кольцо, и использует технологию доступа, известную как передача маркера. Системы с передачей маркера отличает от других то, что в них доступ осуществляется путем последовательного использования всеми машинами сети. В любой момент времени ровно одна машина имеет маркер, который дает право этой машине передать пакет. После посылки этого пакета, машина передает маркер следующей машине по порядку. Поэтому, когда ни одна из машин ничего не посылает, они непрерывно передают маркер по кольцу; когда им всем нужно послать пакеты, они ждут своей очереди, чтобы послать их.
Хотя передача маркера может быть использована для шинных топологий типа Ethernetа, именно кольцевые топологии, такие, как та, что используется proNET-10, делают передачу маркера особенно простой, так как физические соединения определяют последовательность, в которой передается маркер. Главным является то, что данная машина не знает, кому она передает маркер. Мы вскоре увидим, почему циркуляция маркера, основанная на физическом порядке, важна, и как она может быть использована, чтобы сделать кольцо более надежным.
Чтобы понимать, как работает кольцо, нам нужно рассмотреть оборудование. Физически кольцевая сеть не является непрерывным кольцом - она состоит из соединений точка-точка между интерфейсами компьютеров сети. В каждом компьютере один провод передает входящие сигналы, а другой - выходящие сигналы. Концептуально каждый интерфейс компьютера работает в одном из трех режимов: режиме копирования, режиме передачи и режиме восстановления. Как показывает рисунок 2.6, первые два случая соответствуют нормальному режиму работы и отличаются наличием маркера у машины (в одном случае он есть, а в другом нет).
___
----------------|<--|--------------| | |___| | | I1 | _|_ _|_ <---|-| | I2 | A | I4 |_V_| |_|_| | | | I3 | | _____ | |---------------|-| |-|------------| |_|_|_| | | V A
Рисунок 2.6 Сеть с маркерным кольцом, в которой интерфейс I3 находится в режиме передачи, владеет маркером и посылает пакет интерфейсу I2. Другие интерфейсы находятся в режиме копирования. Отправитель всегда получает обратно посланные им биты; другие интерфейсы выделяют копию пакета для компьютера, к которому они присоединены только в том случае, когда совпадают адреса.
Если интерфейс не владеет маркером, он работает в режиме копирования, читая биты из входящего провода и копируя их в выходящий кабель. В режиме копирования интерфейс также просматривает поток данных, чтобы найти пакеты, адресованные его машине, и помещает копию таких пакетов в память машины. Если же интерфейс владеет маркером, он работает в режиме передачи, посылая пакет по выходящему кабелю и проверяя его корректность при чтении пакета из входящего провода(после прохождения кольца пакет вернется по входящему проводу).
Важно понимать, что ProNET-10 - это технология ЛВС, которая имеет маленькие паузы при передаче. Созданное на основе экранированного медного кабеля, это кольцо может охватывать самое большее несколько смежных зданий. При использовании оптоволоконного кабеля кольцо может охватывать большие расстояния(например, целый университетский городок). В любом случае задержки распространения являются маленькими. Как следствие, сигналы могут распространяться по всему кольцу и возвращаться отправителю так быстро, что начало пакета успевает вернуться тогда, когда отправитель еще продолжает передавать. Преимущество коротких пауз при распространении заключается в том, что станция может быстро определить, не разорвано ли кольцо. Она может также определить, не появились ли ошибки в пакете из-за электрических помех или неисправного оборудования где-либо в кольце. Мы рассмотрим обе эти особенности ниже.
В отличие от Ethernetа, оборудование интерфейса proNET-10 не имеет фиксированных адресов, назначаемых производителем. Вместо этого каждый интерфейс поставляется с набором из 8 переключателей, которые позволяют системному администратору выбрать один из 255 возможных адресов(поэтому каждая сеть proNET-10 ограничена 255 машинами). Этот адрес должен быть выбран и установлен, используя физические переключатели на плате. Он не может быть быстро изменен, как только интерфейс установлен, а также не может быть изменен программно. Тем не менее, тот факт, что адрес является устанавливаемым, имеет два важных преимущества. Во-первых, это значит, что адреса proNET-10 могут иметь много меньший размер, чем адреса Ethernetа(8 бит вместо 48 бит). В-вторых, это значит:
Так как пользователи могут изменить адреса proNET-10 при установке плат, сетевой аппаратный адрес машины не нужно менять при замене оборудования интерфейса компьютера.
Конечно, то, что аппаратные адреса устанавливаемые, имеет и свой недостаток. В отличие от адресов Ethernetа, схема устанавливаемых адресов, используемая proNET-10, допускает конфликты адресов. Человек, устанавливающему адреса, должен быть уверен, что каждому интерфейсу в данном кольце назначен уникальный адрес от 0 до 254. Адрес из всех единиц(255) зарезервирован для широковещательного траффика. Как мы увидим позднее, при использовании proNET-10 с TCP/IP, тем, кто устанавливает адреса, следует избегать назначать компьютеру адрес ноль.
Рисунок 2.7 показывает формат кадра proNET-10. Длина полей указана в битах, так как сеть является биториентированной и не всегда выравнивает данные на границу байта. Оборудование сети требует, чтобы поле данных было целым числом октетов, облегчая передачу данных в память компьютера. Как и в Ethernetе, оборудование работает только с некоторыми полями в кадре; программное обеспечение работает с остальными полями и использует их. С точки зрения разработчика объединенной сети, это различие является несущественным.
начало адрес адрес тип данные конец четн. отказ сообщ. получ. отправ. кадра кадра сообщ. --------------------------------------------------------------- |10 бит| 8 бит|8 бит |24 бита|0-16352 бита|9 бит |1 бит|1 бит| ---------------------------------------------------------------
Рисунок 2.7 Формат кадра proNET-10. Поля не масштабированы.
Каждый кадр начинается с поля начала сообщения, за которым следует два октета адресов отправителя и получателя. Поле типа кадра состоит из 3 октетов, но только первый сейчас используется; остальные два должны быть равны 0. Вслед за данными идет поле Конец Сообщения, один бит четности и бит отказа. Сразу за концом кадра может следовать другой кадр или маркер. Заметим, что как и Ethernet, proNET-10 является самоидентифицирующимся. В отличие от Ethernetа, который использует сложную 32-битовую ЦКС для поиска ошибок передачи, proNET-10 использует только один бит четности. Чтобы понять, почему нужен только один бит, вспомним, что proNET-10 - это технология ЛВС с маленькими паузами при распространении. Поэтому, отправитель принимает копию кадра во время передачи и может просто сравнить биты в копии и передаваемые биты, чтобы обнаружить изменения. Фактически бит четности не нужен, за исключением проверки бита отказа.
Оборудование использует флаг, состоящий из семи единиц, чтобы не спутать такие поля, как конец сообщения, и данные пользователя. Маркер и начало кадра также начинаются с флага. Всякий раз, когда семь последовательных единиц встречаются в данных пользователя, оборудование модифицирует последовательность бит так, чтобы быт уверенным, что получатель отличит ее от флага. Получатель убирает эту модификацию, чтобы были приняты те же самые данные, которые были посланы.
Так как передача маркера полагается на то, что все компьютеры передают маркер другой машине, когда закончат передачу, авария на одном узле может остановить все кольцо. Предположим, например, что сбой или электрические помехи разрушили маркер. Если в кольцо не встроен механизм восстановления, вся передача будет прекращена. Для восстановления маркера при его потере на каждой станции proNET-10 запущены два таймера. Один таймер, называемый таймером флага, сбрасывается всякий раз, когда станция обнаруживает какую-либо передачу в кольце(т.е. кадр или маркер), а другой, называемый таймером маркера, сбрасывается всякий раз, когда появляется маркер. Если какой-либо из таймеров обнулился, когда станции нужно послать пакет, станция переходит в режим восстановления и в результате генерирует новый маркер для кольца. Дело в том, что в неработающем кольце маркер циркулирует постоянно. Поэтому таймер флага обнуляется быстро(после 3 мс), если в кольце не работает ни одна машина. Таймер маркера должен допускать передачу больших пакетов другими станциями, может быть даже всеми 255 станциями., поэтому он имеет гораздо большее время обнуления(400 мс). Кольцевые технологии, которые допускают большее число станций или более длинные пакеты, используют большее время обнуления(например, proNET-80 использует 700 мс). Обычно, первая станция, которая входит в режим восстановления, подразумевает, что она владеет маркером и передает пакет. Вслед за передачей пакета она передает маркер, как будто ничего не произошло. При передаче станция следит за кольцом, чтобы проверить полноту циркуляции пакета в кольце. Если пакет прошел кольцо без ошибок, то кольцо восстановлено и все начинает работать в обычном режиме. Если вдруг получится так(хотя это и маловероятно), что две станции одновременно попытаются передавать после разрыва кольца, они обнаружат ошибку, так как передаваемые ими пакеты не вернутся им обратно. Эти две станции подождут случайное время, а затем повторят попытку. Для гарантии, что они не будут ждать одинаковое количество времени, каждая станция использует время задержки, пропорциональное ее аппаратному адресу. Поэтому, если две станции начнут одновременно передавать пакеты, то только одна добьется успеха. Алгоритм восстановления как эффективен, так и надежен. Он гарантирует, что за несколько проходов кольца одна из станций примет решение, что она владеет маркером, а все остальные станции согласятся с этим.
На практике в большей части установок сети proNET-10 конфигурируются в виде звездообразных колец для повышения надежности. Идея состоит в том, чтобы использовать пассивный кабельный центр как концентратор(hub) в физической звездообразной топологии , несмотря на то что сеть логически работает как кольцо. Рисунок 2.8 иллюстрирует такое соединение.
реле для ЭВМ 1
кабельный центр ------------- /
| интерфейс | /
\ | для ЭВМ 1 |/
\ ------A-----/
\ | /
\ ===========|===/========
| --V--/ |
| -----|R1 |<----| | | | | | | интерфейс | | V-- | | интерфейс | | для ЭВМ 2 |<--->|R2 | |R4 |<--->| для ЭВМ 4 |
------------- | ----- ----- | -------------
| | ----- A |
| |--->|R3 |-----| |
| ----- |
========================
Рисунок 2.8 Соединение трех ЭВМ через пассивный кабельный центр. Так как она не потребляет энергии, реле R3 просто передает через себя сигналы. Логически сеть является кольцом; физически - это звезда.
На этом рисунке реле R3 не потребляет энергии, так как оно подключено к ЭВМ. R3 замыкает кольцо и соединяет R2 с R4. Так как другие реле потребляют энергию, они соединяют соответствующие ЭВМ с кольцом. Поэтому электрический сигнал, посланный с ЭВМ 4 передается через реле R4 к реле R1, затем к интерфейсу ЭВМ 1 , обратно на реле R1, по реле R2 и так далее.
Этот кабельный центр не имеет активных компонент, но использует чувствительные реле, получающие питание по соединению с ЭВМ. ЭВМ обеспечивает небольшой постоянный ток для питания реле, а также сигналы, кодирующие данные, по одному многожильному кабелю. Электроника в кабельном центре отделяет переменный ток от постоянного. Пока машина включена, реле в кабельном центре делает ее присоединенной к кольцу. При отключении машины ток перестает течь в кабельный центр и соответствующее реле изменяет свое состояние, отсоединяя свою ЭВМ и соединяя другие машины в кольце. Поэтому сеть продолжает работать, даже если некоторые из присоединенных машин отключены(конечно, авария машины может остановить сеть на несколько миллисекунд, пока оставшиеся узлы восстанавливают маркер). Помимо надежности, данный производитель разработал интерфейс proNET-10 состоящим из двух плат, контроллера, который может работать в режиме копирования и восстановления маркера без помощи ЦП, и интерфейса с компьютером, который полагается на ЦП при чтении и записи пакетов. Использование этих двух плат изолирует остальную сеть от сбоев операционной системы на данной машине.
Назад | Содержание | Вперед
Второе издание книги профессора Дугласа Комера является введением и обзором TCP/IP. Существовала большая необходимость в статье или книге для тех, кто только начал разбираться в протоколах TCP/IP. Эта книга удовлетворяет эту нужду. Написание введения в TCP/IP для начинающих - очень трудная задача. Но обьединив обьяснение общих принципов взаимодействия компьютеров с конкретными примерами для связки протоколов TCP/IP, Дуглас Комер написал очень понятную книгу.
Хотя эта книга и написана специально о связке протоколов TCP/IP, она также является хорошей книгой для изучения протоколов взаимодействия компьютеров вообще. Принципы архитектуры, уровни, мультиплексирование, инкапсуляция, адресация и отображение адресов, маршрутизация и именование аналогичны для любой связки протоколов, хотя, конечно, и отличаются в деталях(Смотри глав 3, 10, 18, 20, и 26).
Протоколы взаимодействия компьютеров не делают ничего сами. Как и операционные системы, они обслуживают прикладные процессы. Процессы - это активные элементы, которые запрашивают взаимодействие и являются истинными отправителями и получателями передаваемых данных. Различные уровни протоколов похожи на различные уровни операционных систем, особенно файловой системы. Понимание архитектуры протоколов похоже на понимание архитектуры операционных систем. В этой книге Дуглас Комер придерживается восходящего подхода - начинает с физических сетей и двигается вверх по уровням абстракции к прикладному уровню.
Так как прикладные процессы - это активные элементы, использующие взаимодействие , обеспечиваемое протоколами, то TCP/IP - это механизм "межпроцессного взаимодействия"(IPC). В то время как проводятся эксперименты с целью организации межпроцессного взаимодействия образом, похожим на тот, который применяется в операционных системах, на основе IP, главное внимание в этой книге сосредоточено на более традиционных приложениях, которые используют дейтаграммы UDP или логические соединения TCP для организации IPC(МПВ)(Смотри главы 11, 12, 18, 20 и 22-25). Обычно в операционных системах существует набор функций, обеспечиваемых операционной системой для прикладных процессов. Этот интерфейс системных вызовов обычно включает вызовы для открытия, чтения, записи и закрытия файлов помимо всего прочего. Во многих системах существуют аналогичные системные вызовы для функций МПВ, включая сетевое взаимодействие. Как пример такого интерфейса, Дуглас Комер приводит обзор интерфейса портов(socket)(Смотри главу 21).
Одной из главных идей, лежащих в основе TCP/IP и вынесенной в название книги, является межсетевой обмен. Мощь коммуникационной системы напрямую связана с числом сущностей в этой системе. Телефонная сеть очень полезна, так как (почти) все телефоны находятся в одной сети(по крайней мере, так кажется пользователям). Системы компьютерного взаимодействия и сети в настоящее время отделены друг от друга и фрагментированы. Цель взаимного соединения и взаимодействия для создания одной мощной компьютерной коммуникационной сети являлась основной при проектировании TCP/IP. Самым главным для межсетевого обмена являются адресация(Смотри главы 4, 5, 6 и 17) и универсальный протокол - Межсетевой протокол(Internet Protocol)(Смотри главы 7, 8 и 9). Конечно, индивидуальные сети имеют свои собственные протоколы, которые используются для того чтобы нести дейтаграммы IP(Смотри главу 2), и должно существовать отображение между адресами индивидуальных сетей и адресами IP(Смотри главы 5, 6 и 19).
Для организации межсетевого обмена индивидуальные сети должны быть соединены. Соединяющие их устройства называются шлюзами(gateway) . Более того, эти шлюзы должны иметь некоторые процедуры для передачи данных от одной сети к следующей. Данные передаются в форме дейтаграмм IP и назначение указывается с помощью адреса IP, но шлюзы должны принимать решение о направлении передачи дейтаграммы на основе адреса IP и своих знаний о связности сетей, составляющих Интернет. Процедуры для распространения информации о текущей связности называются алгоритмами маршрутизации и являются в настоящее время предметом многих исследований(Смотри главы 13, 14, 15, 16 и 17).
Как и все коммуникационные системы, связка протоколов TCP/IP - это незавершенная система. Она развивается, отражая меняющиеся требования и новые возможности. Поэтому эта книга является по существу, представлением о TCP/IP в начале 1990 года. И, как указывает Дуглас Комер, существует много проблем(смотри главу 27). Одной из быстро меняющихся областей является сетевое управление(Смотри главу 25).
Большинство глав заканчиваются небольшим количеством ссылок на материал для дальнейшего изучения. Большинство из них - это документы серии RFC. Эта серия является результатом политики общедоступности идей и спецификаций протоколов , разработанных исследователями и разработчиками сообщества TCP/IP. Эта доступность базовой и детальной информации об этих протоколах, и доступность их первых реализаций явилась основной причиной их нынешнего широкого использования. Передача в общее пользование документации с такой степенью детализации является необычной для исследовательских проектов, но дает значительное ускорение разработки компьютерного взаимодействия(Смотри приложения 1, 3 и 4).
Эта книга вобрала в себя информацию о различных частях архитектуры и протоколов TCP/IP и сделала ее доступной. Эта публикация является очень значительным шагом в эволюции компьютерного взаимодействия.
Так как мы уже рассмотрели низкоуровневые детали передачи в отдельных сетях, основу, на которой строится взаимодействие компьютеров. Эта глава делает большой концептуальный скачок, описывая схему, которая позволяет нам объединять разнообразные сетевые технологии в единое целое. Нашей главной целью является схема, которая скрывает детали лежащего в ее основе сетевого оборудования, в то же время обеспечивая универсальные средства взаимодействия. Основным результатом является высокоуровневая абстракция, которая обеспечивает основу для всех проектных решений. Последующие главы покажут, как мы используем эту абстракцию для построения необходимых уровней межсетевого коммуникационного математического обеспечения и как это программное обеспечение скрывает лежащие в его основе механизмы физической передачи. Следующие главы также покажут, как приложения используют получившуюся коммуникационную систему.
Разработчики используют два различных подхода для скрытия деталей сетевого взаимодействия, используя прикладные программы для работы в неоднородной среде или скрывая эти детали в операционной системе. Ранние взаимодействия неоднородных сетей обеспечивали единообразие с помощью прикладных программ. В таких системах прикладная программа, работая на каждой машине в сети, знала детали сетевого взаимодействия для этой машины и взаимодействовала с прикладными программами по этим соединениям. Например, некоторые системы электронной почты состояли из программ-отправителей писем(mailer), которые передавали письма по-одному. Путь от источника до получателя мог включать различные сети, но это не имело значения до тех пор, пока системы электронной почты на всех машинах были способны работать друг с другом.
Использование прикладных программ для скрытия сетевых деталей может показаться на первый взгляд естественным, но такой подход приводит к ограниченному, громоздкому взаимодействию. Добавление новых возможностей к этой системе означает создание новой прикладной программы на каждой машине. Добавление нового сетевого оборудования означает модификацию или создание новых программ для всех возможных приложений. На данной машине каждая программа знает сетевые соединения для этой машины, что приводит к дублированию кода.
Пользователи, имеющие опыт работы с сетями, знают, что когда-нибудь во взаимодействии будут участвовать сотни или тысячи сетей; тогда никто не будет в состоянии создать все необходимые прикладные программы. Более того, для успешного использования пошаговой схемы взаимодействия требуется корректность всех прикладных программ на всем пути. Если программа на промежуточной машине аварийно завершится, ни отправитель, ни получатель не смогут обнаружить ошибку или исправить ее. Поэтому системы, использующие промежуточные программы, не могут гарантировать надежного взаимодействия.
Альтернативой обеспечению взаимодействия прикладными программами являются системы, основанные на соединении сетевого уровня. Соединение на сетевом уровне обеспечивает механизм, который доставляет пакеты от их настоящего отправителя к настоящему получателю в реальном масштабе времени. Коммутация для передачи маленьких блоков, а не файлов или больших сообщений имеет ряд преимуществ. Во-первых, она напрямую отображается в базовое сетевое оборудование, что делает ее очень эффективным. Во-вторых, она разделяет процессы передачи данных от прикладных программ, позволяя машинам обрабатывать сетевой траффик, не зная какие приложения передают его. В-третьих, она делает систему гибкой, делая возможным создание сетевых протоколов общего назначения. В-четвертых, она позволяет администраторам сетей добавлять новые сетевые технологии, модифицируя программное обеспечение сетевого уровня или добавляя к нему новую часть и не внося при этом никаких изменений в прикладные программы. Ключевым понятием при разработке универсального взаимодействия сетевого уровня является понятие абстрактной коммуникационной системы, известное как межсетевой обмен(internetworking). Понятие объединенной сети(internetwork или internet) является очень мощным. Оно отделяет понятие взаимодействия от деталей сетевых технологий и скрывает низкоуровневые детали от пользователя. Более того, оно определяет все проектные решения при разработке программного обеспечения и объясняет, как работать с физическими адресами и маршрутами. После перечисления основных причин организации межсетевого обмена мы рассмотрим свойства объединенной сети более детально. Напомним, что мы начали с двух фундаментальных замечаний о разработке коммуникационных систем:
Первое замечание является техническим. Локальные сети, обеспечивающие наивысшую скорость взаимодействия, ограничены в своих размерах; глобальные сети охватывают большие районы, но не могут обеспечить высокоскоростные соединения. Нет одной сетевой технологии, удовлетворяющей всем нуждам, поэтому мы вынуждены использовать несколько базовых аппаратных технологий.
Второе замечание очевидно. В конечном счете, нам хотелось бы иметь возможность организовать взаимодействие между любыми двумя точками. В частности, мы хотели бы иметь коммуникационную систему, не заключенную в границы физических сетей.
Нашей целью является создание унифицированного, объединенного взаимодействия сетей, поддерживающих универсальное коммуникационное средство. Внутри каждой сети компьютеры будут использовать базовые коммуникационные примитивы, зависящие от технологии и похожие на те, что описаны в главе 2. Новое программное обеспечение, вставленное между механизмами взаимодействия, зависящими от технологии, и прикладными программами, будет скрывать низкоуровневые детали и сделает так, что группа сетей будет казаться одной большой сетью. Такая схема взаимодействия называется объединенной сетью(internet).
Идея создания объединенной сети следует стандартному подходу при разработке систем: разработчики придумывают высокоуровневое вычислительное средство и дорабатывают имеющуюся вычислительную технологию, добавляя уровни программного обеспечения до тех пор, пока они не получат систему, эффективно реализующую придуманное ими высокоуровневое средство. Следующий раздел опишет первый шаг при разработке, более точно определив цель.
Понятие универсального средства важно, но само по себе оно не охватывает все идеи, подразумевавшиеся нами для унифицированной объединенной сети, так как может существовать много реализаций универсальных средств. В нашем проекте мы хотим скрыть базовую архитектуру объединенной сети от пользователя. То есть, мы не хотим требовать от пользователя или прикладной программы знания деталей аппаратных взаимодействий, используемых в объединенной сети. Мы также не хотим предписывать топологию сетевых взаимодействий. В частности, добавление новой сети к интернету не должно означать ее соединение с центральным маршрутизатором, а также не должно означать добавление прямых физических соединений между новой сетью и всеми существующими сетями. Мы хотим иметь возможность посылать данные через промежуточные сети даже если они не соединены напрямую с машинами отправителя и получателя. мы хотим, чтобы все машины в интернете имели идентификаторы из одного универсального множества машинных идентификаторов(которые могут представляться как имена или адреса).
Наше понятие унифицированного интернета также включает идею сетевой независимости для интерфейса с пользователем. То есть, мы хотим, чтобы набор операций, используемых для установления взаимодействия или передачи данных, оставался независимым от базовых сетевых технологий и машины получателя. И конечно, пользователю не следует знать топологию сетевых взаимодействий при написании взаимодействующих прикладных программ.
Мы уже видели, как машины присоединяются к отдельным сетям. Возникает вопрос: "Как соединяются сети между собой для создания объединенной сети ?" Ответ состоит из двух частей. Физически две сети могут соединяться только с помощью компьютера, присоединенного к каждой из них. Физическое соединение, тем не менее, не обеспечивает подразумевавшееся нами взаимодействие, так как такое соединение не гарантирует, что компьютер сможет взаимодействовать с другими машинами, с которыми он хотел бы это сделать. Чтобы иметь надежный интернет, нам нужно, чтобы компьютеры были согласны передавать пакеты из одной сети в другую. Компьютеры, соединяющие две сети и передающие пакеты из одной в другую, называются межсетевыми шлюзами(gateway) или межсетевыми маршрутизаторами(router).
Рассмотрим пример, состоящий из двух физических сетей, показанный на рисунке 3.1. На этом рисунке машина G присоединена как к сети 1, так и к сети 2. Чтобы G работал как шлюз, он должен принимать пакеты из сети 1, предназначенные машинам в сети 2 и передавать их туда. Аналогично, G должен принимать пакеты из сети 2, которые предназначены машинам в сети 1 и передавать их туда.
---------------- ----------------
| | ----- | |
| Сеть 1 |--------| G |--------| Сеть 2 |
| | ----- | |
---------------- ----------------
Рисунок 3.1 Две сети, соединенные шлюзом G.
Когда соединения интернета становятся более сложными, шлюзам нужно знать о топологии интернета за пределами сетей, к которым они присоединены. Например, рисунок 3.2 показывает три сети, соединенные между собой двумя шлюзами.
---------- ---------- ----------
| | ------ | | ------ | |
| Сеть 1 |-| G1 |-| Сеть 2 |-| G2 |-| Сеть 3 |
| | ------ | | ------ | |
---------- ---------- ----------
Рисунок 3.2 Три сети, соединенные между собой двумя шлюзами
В этом примере шлюз G1 должен перемещать из сети 1 в сеть 2 все пакеты, предназначенные для машин либо в сети 2, либо в сети 3. По мере того, как размер интернета увеличивается, задача шлюза по принятию решений о том, куда посылать пакеты, становится более сложной.
Идея шлюза кажется простой, но она важна, потому что она обеспечивает способ взаимного соединения сетей, а не машин. Фактически, мы уже установили принцип взаимного соединения, используемый повсеместно в интернете:
В интернете TCP/IP компьютеры, называемые шлюзами, обеспечивают все соединения между физическими сетями.
Вы можете ожидать, что шлюзы, которые знают, как направить пакеты к их получателю, являются большими машинами, имеющими достаточное количество основной или внешней памяти для хранения информации о каждой машине в интернете, к которому они присоединены. Тем не менее, шлюзы, используемые в интернетах TCP/IP, обычно являются миникомпьютерами; они часто имеют небольшую дисковую память или не имеют ее вообще, а также имеют ограниченную оперативную память. Причина использования маленьких межсетевых шлюзов заключена в следующем утверждении:
Шлюзы маршрутизируют пакеты, основываясь на сети получателя, а не на машине получателя. Если маршрутизация основана на сетях, то количество информации, которую нужно хранить шлюзу, пропорционально количеству сетей в интернете, а не числу машин в нем. Так как шлюзы играют ключевую роль в межсетевом взаимодействии, мы вернемся к ним в следующих главах и рассмотрим детали того, как они работают и как они получают информацию о путях. А пока мы будем предполагать, что существует реальная возможность иметь корректные пути для всех сетей в каждом шлюзе в интернете. Мы будем также предполагать, что только шлюзы обеспечивают соединение между физическими сетями в интернете.
Напомним, что TCP/IP разработан, чтобы обеспечить универсальное взаимное соединение между машинами, не зависящее от конкретных сетей, к которым они присоединены. Поэтому, мы хотим, чтобы пользователь представлял себе интернет как единую виртуальную сеть, к которой присоединены все машины, не смотря на то, что физически это не так. Рисунок 3.3а показывает, как представление об интернете как об одной большой сети, а не как о группе сетей, упрощает детали и делает легким для пользователя концептуализацию взаимодействия. Помимо шлюзов, соединяющих физические сети, на каждом хосте требуется программное обеспечение доступа к интернету, чтобы прикладные программы могли использовать интернет так, как будто это одна физическая сеть. Преимущество соединения на сетевом уровне становится ясным. Так как прикладные программы, взаимодействующие с помощью интернета, не знают детали организации соединений, они могут запускаться в неизменном виде на любой машине. Так как детали физических сетевых соединений для каждой машины скрыты в межсетевом программном обеспечении, при появлении новых физических соединений или удалении старых требуется менять только это программное обеспечение. Фактически, можно оптимизировать маршрутизацию, изменив физические соединения, но не перекомпилировав при этом прикладные программы.
Второе преимущество организации взаимодействия на сетевом уровне менее важное: пользователям не нужно знать или помнить, как соединены сети или какой траффик они передают. Прикладные программы могут быть написаны таким образом, что будут работать независимо от физической связности. Фактически, сетевые администраторы могут свободно изменять внутренние части базовой архитектуры интернета, не меняя прикладные программы в большинстве компьютеров, присоединенных к интернету(конечно, сетевое программное обеспечение должно быть переконфигурировано, когда компьютер перемещается в новую сеть).
Как показывает рисунок 3.3б, шлюзы не обеспечивают прямое соединение между всеми парами сетей. Траффику, передающемуся от одной машины к другой, может понадобиться пройти через несколько промежуточных сетей. Поэтому, сети, участвующие в интернете, являются аналогами высокоскоростных магистралей(highway) в США: каждая сеть согласна передавать транзитный траффик в обмен на право посылать траффик через весь интернет. Типичные пользователи даже не ощущают, что по их локальной сети проходит дополнительный траффик.
В главе 2 был сделан обзор сетевого оборудования, используемого для построения интернетов TCP/IP и проиллюстрировала большое разнообразие технологий. Мы описали интернет как набор взаимодействующих, взаимосвязанных сетей. На данный момент важно уяснить фундаментальное понятие: с точки зрения интернете, любая коммуникационная система, способная передавать пакеты, считается одной сетью, независимо от ее задержек при передаче, пропускной способности, максимального размера пакета или географических размеров. В частности, рисунок 3.3б использует прямоугольник одинаковых размеров для обозначения всех физических сетей, так как TCP/IP считает их равными, несмотря на их разницу. Итак,
Межсетевые протоколы TCP/IP считают все сети равными. Локальная сеть, такая как Ethernet, глобальная сеть, такая как магистральная сеть NSFNET, или соединение точка-точка между двумя машинами - каждый из них считается сетью.
Читатели, не привыкшие к архитектуре интернета, могут найти неприемлемым такой упрощенный взгляд на сети. По существу, TCP/IP определяет абстрактное понятие "сеть", которое скрывает детали физических сетей; мы увидим, что такие абстракции делают TCP/IP очень мощным.
--- ---
|Э|-- --|Э|
--- | | ---
/---------\ ---
--- | интернет |----|Э|
|Э|-| | ---
--- \ |
\ /
| \------/\ ---
--- -|Э|
|Э| ---
--\ /
---ЭВМ----
(а)
--- --- -----интернет
|Э|-- --|Э| |
--- | | --- V ---
/-------------------------\ / --|Э|
| | |-----| |/ ---
| ++++ __ ++++ /
| + +--||--+ +----------/ \
/ ++++ -- ++++ физическая \
| -- | | сеть |
| ||-| | | |
| -- | V | ---
--- | | -- | ++++ /---|----|Э|
|Э|-|---++++--||---| + +---/ | ---
--- \ + + -- ++++ /
| ++++ | /
| | | |
| -- ++++ -- |
\ ||-----+ +---||<-шлюз / \ ++++ / | \----------------------/ |Э| |Э| \ / ЭВМ----------- (б)
Рисунок 3.3 (а) Пользовательское представление об интернете TCP/IP, при котором кажется, что каждый компьютер присоединен к одной большой сети, и (б) структура физических сетей и шлюзов, обеспечивающая соединение
Наш краткий обзор интернетов оставил много вопросов без ответов. Например, вас может интересовать точная форма машинных адресов в интернете или то, как такие адреса соотносятся с физическими аппаратными адресами Ethernetа, proNET-10 или ARPANETа, описанными в главе 2. Следующие три главы ответят на эти вопросы. Они опишут формат адресов IP и проиллюстрируют, как ГВМ осуществляют отображение интернетовских адресов в физические и наоборот. Вы также можете захотеть узнать точно, как выглядит пакет при передаче его через интернет, или что происходит, когда на некоторые ГВМ или шлюзы пакеты прибывают быстрее, чем их можно обработать. Глава 7 ответит на эти вопросы. Наконец, вас может заинтересовать, как несколько прикладных программ, выполняющихся параллельно на одной машине, могут посылать и принимать пакеты из несколько мест сразу, не запутавшись при этом, или как интернетовские шлюзы получают информацию о путях. На все эти вопросы также будут даны ответы.
Хотя это сейчас еще не видно, направление, в котором мы двигаемся, позволит нам изучить как структуру, так и применения межсетевого протокольного программного обеспечения. Мы рассмотрим каждую часть, изучая концепции и принципы, а также технические детали. Мы начали с того, что изучили уровень физического взаимодействия, на основе которого строится интернет. Каждая из следующих глав будет рассматривать одну из частей межсетевого программного обеспечения, до тех пор, пока мы не поймем, как все эти части согласованы друг с другом.
Интернет - это более чем набор сетей, соединенных с помощью компьютеров. Межсетевой обмен подразумевает, что участвующие в нем системы подчиняются соглашениям, которые позволяют каждому компьютеру взаимодействовать со всеми остальными компьютерами. В частности, интернет позволит двум машинам взаимодействовать, даже если путь при взаимодействии между ними проходит по сети, к которой ни одна из них не присоединена. Такое взаимодействие возможно только в том случае, когда компьютеры подчиняются соглашениям о наборе универсальных идентификаторов и наборе процедур для перемещения данных к их конечному получателю. В интернете соединения между сетями образуются с помощью компьютеров, называемых IP-шлюзами, или маршрутизаторами, которые присоединяются к двум и более сетям. Шлюзы маршрутизируют пакеты между сетями, получая их от одной сети и направляя их в другую.
Наша модель объединенной сети взята из Cerf и Comer[1983] и Cerf и Kahn[1974], которые описывают интернет как набор сетей, объединенных шлюзами и кратко рассматривают межсетевой протокол, похожий на тот, который был впоследствии разработан для связки протоколов TCP/IP.
Более подробная информация об архитектуре объединенного Интернета может быть найдена в Postel[1980]; Postel, Sunshine и Chen[1981]; и в Hinden, Haverty и Sheltzer[1983]. Shoch[1978] рассматривает вопросы межсетевых имен и адресов. Boggs et. al. [1980] описывает интернет, разработанный в XEROX PARC, альтернативу интернету TCP/IP, который мы рассматриваем. Cheriton[1983] описывает межсетевой обмен в связи V-системой.
3.1 Изменение таблицы маршрутизации шлюза может быть проблематичным, так как нельзя изменить таблицы во всех шлюзах одновременно. Разработайте алгоритмы, которые гарантируют , что внесение изменений произошло либо на всех машинах, либо нигде.
3.2 В интернете шлюзы периодически обмениваются информацией о своих таблицах маршрутизации, делая возможным появление нового шлюза и передачу ему пакетов. Разработайте алгоритмы, использующиеся для обмена информацией.
3.3 Сравните организацию интернета TCP/IP с интернетом, разработанным Xerox Corporation.
3.4 Какие процессоры использовались в шлюзах объединенного Интернета? Удивлены ли вы размерами и скоростью работы шлюзов? Почему?
Назад | Содержание | Вперед
Предыдущая глава определила интернет TCP/IP как виртуальную сеть, созданную в результате соединения физических сетей шлюзами. Эта глава описывает адресацию, существенный компонент, который помогает программному обеспечению TCP/IP скрывать детали физических сетей и создавать впечатление об интернете как о единой сущности.
Говорят, что коммуникационная система обеспечивает универсальное средство взаимодействия, если она позволяет любой ГВМ связываться с любой другой ГВМ. Чтобы сделать нашу коммуникационную систему универсальной, нам нужно определить приемлемый для всех метод идентификации компьютеров, которые присоединены к ней.
Часто идентификаторы ГВМ классифицируются как имена, адреса, или маршруты. Shoch[1978] предложил, чтобы имя идентифицировало, что такое объект, адреса идентифицировал, где он находится, а маршрут(путь) определял, как до него добраться. Хотя эти определения являются интуитивно ясными, они могут ввести в заблуждение. На самом деле имена, адреса и маршруты определяются на разных уровнях представления идентификаторов ГВМ, причем имена на самом верхнем, а маршруты - на самом нижнем. Вообще люди обычно предпочитают произносимые имена для идентификации машин, в то время как программное обеспечение лучше работает с более компактным представлением идентификаторов, которые мы считаем адресами. Все, что угодно могло бы быть выбрано в качестве универсальных идентификаторов ГВМ в TCP/IP. Но было принято решение стандартизовать компактные, двоичные адреса, которые делают вычисления, такие как выбор маршрута, эффективными. Теперь мы перейдем к рассмотрению только двоичных адресов, оставив на потом вопросы о том, как производится отображение между двоичными адресами и произносимыми именами, и о том, как использовать адреса для маршрутизации.
Думайте об интернете как о большой сети, такой же ,как и любая другая физическая сеть. Разница заключается в том, что интернет - это виртуальная структура, придуманная его разработчиками, и реализованная полностью в программном обеспечении. Поэтому, разработчики могут определить по своему усмотрению форматы и размеры пакетов,адреса, технологии доставки и т.д.; аппаратное обеспечение не определяет ничего. Для адресов разработчики TCP/IP выбрали схему, аналогичную адресации в физических сетях, в которой каждой ГВМ в интернете назначается адрес в виде целого числа, называемый межсетевым адресом или IP-адресом. Самым умным в межсетевой адресации является то, что целые числа для адресов тщательно выбираются, чтобы сделать маршрутизацию эффективной. Если говорить более конкретно, IP-адрес кодирует идентификацию сети, к которой присоединена ГВМ, а также идентификацию уникальной ГВМ в этой сети. Можно сделать вывод:
Каждой ГВМ в интернете TCP/IP назначен уникальный 32-битовый межсетевой адрес, который используется при взаимодействии с этой ГВМ.
Детали IP-адресов помогут уточнить абстрактные идеи. А пока мы дадим упрощенное представление, которое будет впоследствии усложнено. В простейшем случае каждой ГВМ, присоединенной к интернету, назначается 32-битовый универсальный идентификатор в качестве его межсетевого адреса. IP-адреса для всех ГВМ данной сети имеют одинаковый префикс.
Концептуально каждый адрес является парой (идсет,идГВМ), где идсет идентифицирует сеть, а идГВМ идентифицирует ГВМ в этой сети. На практике каждый IP-адрес должен иметь одну из первых трех форм из числа тех, что показаны на рисунке 4.1(четвертая форма, зарезервированная для межсетевого широковещания, будет описана позднее; на данный момент мы ограничимся формами, описывающими адреса для отдельных объектов).
0 1 7 8 31
---------------------------------------------------
Класс А |0|идсет | идГВМ |
---------------------------------------------------
0 1 2 15 16 31
---------------------------------------------------
Класс В |1|0| идсет | идГВМ |
---------------------------------------------------
0 1 2 3 23 24 31
---------------------------------------------------
Класс С |1|1|0| идсет | идГВМ |
---------------------------------------------------
0 1 2 3 4 31
---------------------------------------------------
Класс D |1|1|1|0| групповой адрес |
---------------------------------------------------
0 1 2 3 4 5 31
---------------------------------------------------
Класс Е |1|1|1|1|0| зарезервировано на будущее |
---------------------------------------------------
Рисунок 4.1 Пять форм адресов Интернета(IP). Три основные формы, классы А,В и С можно различить по первым двум битам.
Класс данного IP-адреса можно определить по первым трем старшим битам, причем первых двух бит достаточно для определения принадлежности адреса к одному из трех основных классов. Адреса класса А, которые используются для сетей, имеющих в своем составе более чем 2**16(т.е. 65536) ГВМ , выделяют под идсет 7 бит, а под идГВМ 24 бита. Адреса класса В, которые используются для сетей промежуточного размера, включающих от 2**8(т.е. 256) до 2**16 ГВМ, выделяют 14 бит под идсет, а 16 бит под идГВМ. И наконец, сети класса С, состоящие менее чем из 256 ГВМ, выделяют 21 бит под идсет и только 8 бит под идГВМ. Заметим, что IP-адрес был определен таким образом, что можно быстро расширить идГВМ или идсет. Шлюзы используют для маршрутизации поле идсет и полагаются на его эффективное выделение.
Для простоты изложения предмета мы говорили, что межсетевой адрес идентифицирует ГВМ, но это не совсем так. Представим себе шлюз. присоединенный к двум физическим сетям. Как мы можем назначить ему один IP-адрес, если адрес кодирует как идентификатор сети, так и идентификатор ГВМ ? Мы не можем это сделать. Когда обычные компьютеры имеют два или более физических соединений, они называются многоадресными(multi-homed) ГВМ. Многоадресные ГВМ и шлюзы требуют нескольких адресов IP. Каждый адрес соответствует одному из соединений этой машины с сетью. Учет многоадресных ГВМ приводит нас к следующему важному выводу:
Так как IP-адреса кодируют как сеть, так и ГВМ в этой сети, они не описывают конкретную машину, а только соединение ее с сетью.
Поэтому шлюз, соединяющий N сетей, имеет N различных IP адресов, по одному на каждое сетевое соединение.
Мы уже отметили основное преимущество кодирования информации о сети в межсетевых адресах: оно делает возможной эффективную маршрутизацию. Другим преимуществом является то, что межсетевые адреса могут указывать как сети, так и отдельные ГВМ. По соглашению идГВМ, равный 0, никогда не назначается отдельной ГВМ. Вместо этого IP-адрес с нулевым идГВМ используется для ссылки на саму сеть. Подведем итоги:
Межсетевые адреса могут использоваться для указания как на сети, так и на отдельные ГВМ. По соглашению адрес сети имеет поле идГВМ, равное 0.
Другим важным преимуществом межсетевой схемы адресации является то, что она включает широковещательный адрес, который используется для ссылки на все ГВМ в данной сети. Согласно стандарту, любой идГВМ, состоящий из всех единиц, зарезервирован для широковещания(К сожалению, в ранней версии кода TCP/IP, входившего в состав BSD UNIX, все нули некорректно использовались для широковещания, и хотя впоследствии код BSD был исправлен, ошибка осталась в некоторых коммерческих системах, созданных на основе этого кода). Во многих сетевых технологиях(например, Ethernetе) широковещание может быть таким же эффективным, как обычная передача; в других(например, Cypress) широковещание поддерживается сетевым программным обеспечением, но требует значительно больше времени, чем простая передача. Некоторые сети не поддерживают широковещание вообще. Поэтому, широковещательный IP-адрес не гарантирует наличия или эффективности широковещательной доставки пакетов. Подводя итоги, можно сказать, что:
IP-адреса могут использоваться для указания широковещания и отображения его в аппаратное широковещание, если это возможно. По соглашению, широковещательный адрес имеет поле идГВМ со всеми битами, равными 1.
Технически, широковещательный адрес, который мы уже описали, называется направленным(directed) широковещательным адресом, так как он содержит как корректный идентификатор сети, так и корректный широковещательный адрес ГВМ. Направленный широковещательный адрес может однозначно интерпретироваться в любой точке интернета, так как он идентифицирует уникальным образом сеть получателя помимо указания на широковещание в этой сети. Направленные широковещательные адреса обеспечивают мощный(и чем-то опасный) механизм, который позволяет удаленной системе посылать один пакет, который будет распространен в режиме широковещания в указанной сети.
С точки зрения адресации, главным недостатком направленного широковещания является то, что оно требует знаний об адресе сети. Другая форма широковещательного адреса, называемая ограниченный широковещательный адрес или локальный сетевой широковещательный адрес, обеспечивает широковещательный адрес для локальной сети(сети отправителя), независимо от назначенного ей IP-адреса. Локальный широковещательный адрес состоит из 32 единиц(поэтому он иногда называется широковещательным адресом из всех единиц). ГВМ может использовать ограниченный широковещательный адрес в процессе своего запуска, до того, как он узнает свой IP-адрес или IP-адрес локальной сети. Как только ГВМ узнает IP-адрес своей сети, он может использовать направленное широковещание. Как правило, протоколы TCP/IP ограничивают широковещание до наименьшего возможного набора машин. Мы увидим, как это правило влияет на группы сетей, разделяющих адреса, в главе 6, когда будем рассматривать адресацию подсетей.
Мы видели, что поле, состоящее из единиц, может интерпретироваться как "все", как "все ГВМ" в сети. Вообще межсетевое программное обеспечение интерпретирует поля, состоящие из нулей, как символ "это". Такая интерпретация встречается повсеместно в литературе. Поэтому IP-адрес с идГВМ, равным 0, обозначает "этот ГВМ", а межсетевой адрес с идентификатором сети 0 обозначает "эта сеть". Конечно, использовать эти адреса нужно только в том контексте, в котором они интерпретируются однозначно. Например, если машина получила пакет, в котором адрес отправителя имеет поле идсет, установленное в 0, а идГВМ соответствует собственному, получатель делает вывод о том, что поле идсет означает эту сеть(т.е. сеть, из которой прибыл пакет). Использование идсет 0 особенно важно в тех случаях, когда ГВМ хочет взаимодействовать с помощью сети, но еще не знает свой сетевой IP-адрес. ГВМ временно использует идентификатор сети 0, а другие ГВМ в этой сети интерпретируют этот адрес как означающий "эта сеть". В большинстве случаев ответы будут содержать полный сетевой адрес, позволяя первоначальному отправителю запомнить его на будущее. Главы 9 и 20 рассмотрят в деталях, как ГВМ определяет свой сетевой адрес и как он использует идентификатор сети 0.
Помимо широковещания схема адресов IP поддерживает специальную форму групповой доставки, известную как групповая доставка(multicasting). Групповая доставка особенно полезна для сетей, в которых аппаратная технология поддерживает групповую доставку. Глава 17 рассматривает групповую адресацию и доставку более детально.
Кодирование информации о сети в межсетевом адресе имеет ряд недостатков. Самым очевидным недостатком является то, что адреса описывают соединения, а не ГВМ:
Если ГВМ перемещается из одной сети в другую, его IP-адрес должен измениться.
Чтобы понять этот вывод, давайте рассмотрим путешественников, который хотели бы отсоединять свои персональные компьютеры, брать их с собой в дорогу, а затем присоединять их к интернету после прибытия в место назначения. Таким персональным компьютерам нельзя назначить постоянный IP-адрес, так как IP-адрес идентифицирует сеть, к которой присоединена эта машина. Другим слабым местом межсетевой схемы адресации является то, что когда число ГВМ в сетях класса С начинает превышать 255, нужно изменить ее адрес на адрес класса В. Хотя это может показаться незначительной проблемой, изменение сетевого адреса может потребовать большого количества времени и быть трудноотлаживаемым. Так как большая часть программного обеспечения не предназначена для работы с несколькими адресами в одной и той же физической сети, администраторы не могут спланировать плавный переход, в течение которого они могли бы медленно изменить адреса. Вместо этого, они должны сразу запретить использование одного сетевого адреса, изменить адреса всех машин, а затем возобновить взаимодействие, используя новые сетевые адреса.
Самый главный недостаток в межсетевой схеме адресации не будет полностью понятен, пока мы не рассмотрим маршрутизацию. Тем не менее, его важность требует хотя бы краткого его описания. Мы говорили, что маршрутизация основывается на межсетевых адресах, причем для принятия решения о маршруте используется идентификатор сети. Рассмотрим ГВМ, имеющий два соединения с интернетом. Мы знаем, что такой ГВМ имеет более чем один IP-адрес. Тогда верно следующее утверждение:
Так как маршрутизация использует сетевую часть IP-адреса, путь, проходимый пакетами до ГВМ с несколькими IP-адресами, зависит от используемого адреса.
Следствия этого утверждения удивительны. Люди думают, что каждый ГВМ - это одна сущность, и хотят использовать одно имя. Они часто удивляются, обнаружив, что у ГВМ есть более чем одно имя, и еще более удивляются, открыв, что разные имена ведут себя по-разному.
Другим удивительным следствием межсетевой схемы адресации является то, что знания одного IP-адреса для ГВМ получателя может оказаться недостаточно; может получиться так, что нельзя будет достичь получается, используя этот адрес. Рассмотрим демонстрационную сеть, показанную на рисунке 4.2. На этом рисунке два ГВМ, А и В, оба присоединены к сети 1, и обычно взаимодействуют между собой, используя эту сеть. Поэтому, пользователи на ГВМ А обычно указывают ГВМ В, используя IP-адрес I4. Существует другой путь от А к В через шлюз G, и он используется всякий раз, когда А посылает пакеты IP-адресу I5. Теперь предположим, что соединение В с сетью 1 вышло из строя, но сама машина продолжает работать(например, оборвался кабель между В и сетью 1). Пользователи на А, использующие IP-адрес I4, не смогут достичь В, хотя пользователи, использующие адрес I5, смогут это сделать. Эти проблемы с именованием и адресацией снова возникнут в следующих главах, когда мы будем рассматривать маршрутизацию и связывание имен.
сеть 1
---------------------------------------------------------
| I1 | I3 | I4
+++++ +++++ +++++
| G | | А | | В |
+++++ +++++ +++++
| I2 | I5
---------------------------------------------------------
сеть 2
Рисунок 4.2 Пример интернета с многоадресным ГВМ В, который демонстрирует проблему со схемой адресации IP. Если интерфейс I4 отсоединится, А должен использовать адрес I5 для достижения В, направляя пакеты к нему через шлюз G.
Для удобства людей в технических документах или прикладных программах IP-адреса пишутся как четыре десятичных числа, разделенных десятичными точками, и каждое из этих чисел представляет значение одного октета IP-адреса(точечная десятичная нотация иногда называется точечной квадронотацией). Поэтому 32-битовый межсетевой адрес
10000000 00001010 00000010 00011110
записывается как
128.10.2.30
Мы будем использовать точечную десятичную нотацию при описании IP-адресов на протяжении всей оставшейся части этой книги.
Сетевой адрес класса А 127.0.0.0 зарезервирован для обратной связи и введен для тестирования взаимодействия между процессами на одной машине. Когда какая-либо программа использует адрес обратной связи для передачи данных, протокольное программное обеспечение в компьютере возвращает эти данные, ничего не посылая по сети. В литературе четко сказано, что пакет, посланный в сеть с адресом 127, не будет передаваться ни по какой сети. Более того, ГВМ или шлюз никогда не должен распространять информацию о маршрутах для сети с номером 127; этот адрес не является адресом сети.
На практике IP использует лишь комбинации из нулей("этот") или из всех единиц("все"). Рисунок 4.3 показывает все имеющиеся случаи.
--------------------------------- | все нули | Этот ГВМ* --------------------------------- --------------------------------- | все нули | ГВМ | ГВМ в этой сети* --------------------------------- --------------------------------- Ограниченное | все единицы | широковещание --------------------------------- (локальная сеть)** --------------------------------- Направленное | сеть | все единицы | широковещание --------------------------------- в сети** --------------------------------- | 127 | все, что угодно | Обратная связь*** ---------------------------------
* Разрешено только при загрузке
системы и не может быть адресом
получателя
** Не может быть адресом отправителя
*** Никогда не будет передан в сеть
Рисунок 4.3 Специальные формы IP-адресов, включая допустимые комбинации нулей("это") и единиц("все"). Длина сетевой части при направленном широковещании зависит от класса сетевого адреса.
Как указано в замечаниях к рисунку, использование всех нулей для сети допустимо только во время загрузки системы. Оно временно позволяет машине взаимодействовать. Как только машина узнала свой настоящий IP-адрес, она должна перестать использовать сеть 0.
Чтобы быть уверенным в том, что сетевые части Интернетовских адресов являются уникальными, все Интернетовские адреса назначаются одним ведомством, Сетевым Информационным Центром(NIC). Он назначает только сетевую часть адреса и возлагает ответственность за назначение адресов ГВМ в этой сети организации, запросившей этот адрес. Локальным сетям с небольшим числом машин(меньшим чем 255) обычно назначается номера класса С, так как ожидается появление большого числа локальных сетей. Большим сетям, таким как ARPANET, назначаются номера класса А, так как можно ожидать появления лишь небольшого числа больших сетей.
При назначении IP-адресов сетям NICу важно лишь то, что эта сеть или присоединена к объединенному Интернету, или собирается к нему присоединиться. Какая-либо корпорация может взять на себя ответственность за назначение уникальных сетевых адресов внутри своего интернета TCP/IP, если она никогда не собирается соединять свой интернет с внешним миром. На самом деле многие объединенные группы, использующие протоколы TCP/IP, назначают межсетевые адреса по своему усмотрению. Например, NIC назначил адрес 10.0.0.0 ARPANETу. Если какой-либо колледж решит использовать протоколы TCP/IP в своем Ethernete, в состав которого входят лишь три машины(и нет никаких шлюзов), он может выбрать адрес 10.0.0.0 для этой локальной сети. Тем не менее, как показывает опыт, нежелательно создание частного интернета, использующего те же самые сетевые адреса, что и объединенный Интернет, так как это приведет к невозможности взаимной работы в будущем и может вызвать проблемы при попытке обменяться программным обеспечением с другими колледжами. Поэтому, всем, кто использует TCP/IP очень выгодно потратить некоторое время и получить официальные Интернетовские адреса у NICа.
Для уяснения схемы адресации в IP рассмотрим пример из рисунка 4.4, который показывает несколько соединений и ГВМ, соединенных с Интернетом, на факультете компьютерных наук университета Пурдью в середине 80-х годов. Пример показывает три сети: ARPANET(10.0.0.0), Ethernet(128.10.0.0) и маркерное кольцо proNET-10(192.5.48.0). При написании этих адресов в двоичном виде видно, что эти сети являются соответственно сетями класса А,В и С.
На рисунке четыре ГВМ, присоединенные к этим сетям, называются Arthur, Merlin, Guenevere и Lancelot. Машина Taliesyn служит шлюзом между ARPANET и proNET-10, а машина Glatisant служит шлюзом между proNET-10 и Ethernet. ГВМ Merlin имеет соединения как с Ethernetом, так и с proNET-10, поэтому она может взаимодействовать с ГВМ в обеих сетях напрямую. Хотя многоадресный ГВМ, такой как Merlin, может также работать как шлюз, Merlin является прежде всего системой с разделением времени ,и дополнительная работа по маршрутизации пакетов может уменьшить вычислительную мощность, доступную пользователям. Поэтому, был установлен выделенный шлюз, Glatisant, чтобы снять нагрузку передачи траффика с системы с разделением времени. Траффик между этими двумя сетями имел на самом деле гораздо больший объем, чем предполагает эта конфигурация, так как здесь показаны далеко не все имевшиеся ГВМ.
Ethernet 128.10.0.0
============================================================
| 128.10.2.3 | 128.10.2.8 | 128.10.2.70 | 128.10.2.26
------------- ------------- ------------- -------------
|Merlin | |Guenevere | |Glatisant | |Lancelot |
|(многоадр. | |(ГВМ | |(шлюз) | |(ГВМ |
| ГВМ) | | Ethernet)| | | | Ethernet)|
| | | | | | | |
------------- ------------- ------------- -------------
\ 192.5.48.3 / 192.5.48.7
\ / 10.2.0.37
\ ++++++++++++++ / -------------
---------+ proNET-10+---- |Taliesyn |
------------- + 192.5.48.0+-----------|(шлюз) |------>
|Arthur | ++++++++++++++192.5.48.6 | |
|(ГВМ | | | |
| proNET) |--------- -------------
| | 192.5.48.1 к ARPANET
------------- 10.0.0.0
Рисунок 4.4 Пример назначения IP-адресов для ГВМ и шлюзов в Ethernetе, маркерном кольце и ARPANETе.
Рисунок 4.4 показывает IP-адреса для каждого сетевого соединения. Lancelot, соединенный только с Ethernet, имеет адрес 128.10.2.26. Merlin имеет адрес 128.10.2.3 для соединения с Ethernetом и 192.5.48.3 для соединения с proNET-10. Выбор одинакового значения для младшего байта этих двух адресов позволяет системным программистам легче запомнить все межсетевые адреса Merlinа.
Чтобы создать интернет, независимый от архитектуры конкретной машины или от сетевого оборудования, мы должны определить стандартное представление данных. Посмотрим, что происходит, когда одна машина посылает 32-битовое целое число другой машине. Физическое оборудование передает последовательность бит от первой машины ко второй, не меняя их порядка. Тем не менее, не все машины хранят 32-битовые целые числа одинаково. В одних (называемых "с наименьшего конца") младший адрес памяти содержит самый младший байт целого числа. В других (называемых "с наибольшего конца") младшая ячейка памяти хранит старший байт числа. А некоторые все еще запоминают целые числа в группах 16-битовых слов, причем младшие адреса содержат младшее слово числа, но байты в этих словах поменялись своими местами. Поэтому, прямое копирование байт с одной машины на другую может изменить значение числа.
Стандартизация порядка байт для целых чисел особенно важна для интернета, так как межсетевые пакеты содержат двоичные числа, указывающие такую информацию, как адрес назначения и длина пакета. Такие числа должны пониматься как отправителем, так и получателем. Протоколы TCP/IP решают проблему порядка байт, определяя стандартный сетевой порядок байт, который должны использовать все машины для двоичных полей в межсетевых пакетах. Каждый ГВМ преобразует двоичные элементы из локального представления в стандартный сетевой порядок перед передачей пакета; он преобразует сетевой порядок байт в свой порядок при приеме пакета. Естественно поле данных пользователя в пакете не обрабатывается по этому стандарту - пользователи вольны форматировать свои данные так, как они пожелают. Конечно, большинство пользователей полагается на стандартные прикладные программы и не сталкивается с проблемой порядка байт напрямую. Межсетевой стандарт порядка байт определяет, что целые числа посылаются таким образом, что самый старший(значимый) байт передается первым(т.е. в стиле "с наибольшего конца"). Если посмотреть на последовательность байт пакета тогда, когда он передается от одной машины к другой, то у двоичного целого в этом пакете самый старший байт находится ближе всего к началу пакета, а самый младший байт находится ближе всего к концу пакета. Было выдвинуто много аргументов в пользу использования того или иного представления данных, и межсетевой стандарт до сих пор время от времени подвергается критике. Тем не менее, все согласились с тем, что такой стандарт необходим, и точная форма его не так уж и важна.
TCP/IP использует 32-битовые двоичные адреса в качестве универсальных идентификаторов машин. Называемые межсетевыми или IP-адресами, эти идентификаторы разделены на три основных класса, и допускают существование сотни сетей с миллионами ГВМ в каждой, тысяч сетей с тысячами ГВМ в каждой и свыше миллиона сетей с 254 ГВМ в каждой. Чтобы сделать эти адреса более легкими для понимания людей, они записываются в точечной десятичной нотации, в которой значения четырех октетов записываются в десятичном виде и разделяются десятичными точками.
Так как IP-адреса кодируют как идентификацию сети, так и идентификацию ГВМ в этой сети, эффективно реализуется маршрутизация. Важным свойством IP-адресов является то, что они обозначают сетевые соединения. ГВМ с несколькими соединениями имеют несколько адресов. Одним из преимуществ межсетевой схемы адресации является то, что одинаковая форма адреса может использоваться для обозначения ГВМ, сетей и всех ГВМ в сети(широковещания). Самый большой недостаток схемы адресации в IP заключается в том, что если машина имеет несколько адресов, знания одного адреса может оказаться недостаточно для взаимодействия с ней, если некоторые сети выйдут из строя. Для возможности обмена двоичными данными между машинами протоколы TCP/IP устанавливают стандартный порядок байт для целых чисел в полях пакета. Вообще ГВМ должен преобразовать все двоичные данные из своего внутреннего формата в стандартный сетевой порядок байт перед передачей пакета, а после приема пакета должен наоборот преобразовать стандартный сетевой порядок байт в свой внутренний.
Межсетевая схема адресации, представленная здесь, может быть найдена в Reynolds и Postel[RFC 990 и 997].
Официальные адреса Интернета назначаются NIC(смотри в Приложении 1 его адрес и телефонный номер).
Глава 16 описывает важную часть стандарта межсетевых адресов, называемую адресацией подсетей. Адресация подсетей позволяет использовать один сетевой адрес для нескольких физических сетей.
Глава 17 показывает, как адреса класса D назначаются для межсетевой групповой передачи.
Cohen[1981] объясняет проблему порядка бит и байт и вводит термины "с наименьшего конца" и "с наибольшего конца".
4.1 Сколько точно может существовать сетей класса А, В и С ? Сколько точно может быть ГВМ в сети каждого класса ? Будьте осторожны с сетями класса D и Е.
4.2 Список адресов, назначенных машинам, в читабельной форме называется межсетевой таблицей ГВМ. Если в вашем узле есть таблица ГВМ, установите точно, сколько номеров сетей класса А, В и С уже выделено.
4.3 Сколько ГВМ присоединено к каждой из локальных сетей в вашем узле ? Есть ли в вашем узле локальные сети, для которых недостаточно адреса класса С ?
4.4 Каково главное отличие схемы адресации в IP от схемы нумерации телефонов в США ?
4.5 Одно центральное ведомство не может достаточно быстро назначать адреса Интернета. Можете вы предложить схему, позволяющую центральному ведомству распределить его задачу среди нескольких групп, но все еще гарантирующую, что каждый назначенный адрес будет уникальным ?
4.6 Отличается стандартный сетевой порядок байт от порядка байт в вашей машине ?
Назад | Содержание | Вперед
Мы описали схему адресации TCP/IP, в которой каждому ГВМ назначается 32-битовый адрес и сказали, что интернет ведет себя как виртуальная сеть при использовании этих назначенных адресов для посылки и приема пакетов. Мы также рассмотрели несколько физических сетевых технологий и заметили, что две машины в данной физической сети могут взаимодействовать только в том случае, если каждая из них знает физический сетевой адрес другой машины. О чем мы не упоминали, так это о том, как ГВМ или шлюз отображает IP-адрес в корректный физический адрес, когда ему нужно послать пакет по физической сети. Эта глава рассматривает это отображение, показывая, как оно реализуется для двух самых распространенных схем физических адресов.
Рассмотрим две машины А и В, которые присоединены к одной физической сети. Каждая из них имеет назначенный IP-адрес Ia и Ib, а также физический адрес Pa и Pb. Нашей целью является разработка низкоуровневого программного обеспечения, которое скрывало бы физические адреса и позволяло бы программам более высокого уровня работать только с межсетевыми адресами. Тем не менее, в конечном счете взаимодействие реализуется физическими сетями, использующими какую-либо схему физических адресов. Предположим, что машина А хочет послать пакет машине В по физической сети, к которой они обе присоединены, но А знает только межсетевой адрес Ib. Возникает вопрос: как может А отобразить этот адрес в физический адрес Pb ?
Проблема отображения высокоуровневых адресов в физические адреса известна как проблема разрешения адресов и решается несколькими способами. Некоторые связки протоколов хранят на каждой машине таблицы, содержащие пары высокоуровневых и физических адресов. Другие решают проблему, кодируя аппаратные адреса в высокоуровневых адресах. Использование только одного из этих подходов в лучшем случае делает проблему высокоуровневой адресации неудобной. Эта глава рассматривает две технологии для разрешения адресов, используемые протоколами TCP/IP.
Существуют два основных типа физических адресов: характерным представителем первого типа является Ethernet, использующий большие, фиксированные физические адреса, а второго - proNET-10, использующий маленькие легко изменяемые физические адреса. Разрешение адресов трудно для сетей типа Ethernetа, но легко для сетей типа proNET-10. Мы рассмотрим первым легкий случай.
Рассмотрим сеть с маркерным кольцом proNET-10. Как вы помните, из главы 2 мы знаем, что она использует небольшие целые числа в качестве физических адресов и позволяет пользователю выбрать аппаратный адрес при установке платы интерфейса в компьютер. Главной причиной, делающей разрешение адресов легким для сети proNET-10, является то, что раз можно назначать как IP-адреса, так и физические адреса, то можно выбрать их такими, что их части будут совпадать. Обычно при назначении IP-адресов поле идГВМ делается равным 1,2,3 и т.д., а затем при установке сетевого интерфейсного оборудования выбирается физический адрес, совпадающий с полем идГВМ в IP-адресе. Например, можно выбрать физический адрес 3 для машины, имеющей IP-адрес 192.5.48.3, так как 192.5.48.3 является адресом класса С, у которого поле идГВМ равно 3.
Для сетей, таких как proNET-10, вычисление физического адреса на основе IP-адреса тривиально. Вычисление состоит из выделения полу идентификатора ГВМ из IP-адреса. Это вычислительно эффективно, так как требует выполнения нескольких машинных команд. Это легко осуществить, так как может быть выполнено без обращения к внешним данным. И ,наконец, новые машины могут быть добавлены к сети без изменения данных или перекомпиляции кода. Концептуально выбор схемы нумерации, делающей разрешение адресов эффективным, означает выбор функции F, которая отображает IP-адреса в физические адреса. Разработчик может также выбрать схему нумерации физических адресов. Разрешение IP-адреса Ia означает вычисление
Pa=F(Ia)
Мы хотим, чтобы вычисление F было эффективным. Если множество физических адресов ограничено, можно по-другому эффективно сделать это отображение. Например, при использовании X.25 нельзя выбрать физические адреса. Обычно, шлюзы в сетях X.25 хранят пары IP-адресов и физических адресов X.25 в таблице и осуществляют поиск в этой таблице при разрешении IP-адресов. Чтобы сделать разрешение адресов эффективным в таких случаях, программное обеспечение может использовать хэш-функцию для поиска в таблице. Упражнение 5.1 предлагает еще один подход.
Чтобы понять, почему разрешение адресов так трудно в некоторых сетях, рассмотрим технологию Ethernetа. Как вы знаете из главы 2, Ethernet имеет 48-битовые физические адреса, назначаемые производителями при изготовлении интерфейсных плат. Как следствие, при выходе оборудования из строя и замене интерфейсной платы физический адрес машины меняется. Более того, так как адрес в Ethernetе имеет длину 48 бит, не стоит и рассчитывать, что его можно закодировать в 32-битном IP-адресе. Разработчики протоколов TCP/IP нашли конструктивное решение проблемы разрешения адресов для сетей, таких как Chaosnet или Ethernet, которые имеют возможность широковещания. Это решение позволяет добавлять машины к сети без перекомпиляции кода и без создания центральной базы данных. Чтобы избежать создания таблиц отображения разработчики решили использовать низкоуровневый протокол для динамической связки адресов. Названный Протокол Разрешения Адресов(ARP), он обеспечивает механизм, который является как эффективным, так и легким для реализации.
Как показывает рисунок 5.1 , идея, лежащая в основе динамического разрешения в ARP, проста: когда ГВМ А хочет разрешить IP-адрес Ib, он широковещательно распространяет специальный пакет, который просит ГВМ с IP-адресом Ib ответить ему, указав свой физический адрес Pb. Все ГВМ, включая В, получают этот запрос, но только ГВМ В узнает свой IP-адрес и посылает ответ, содержащий свой физический адрес. Когда А получает ответ, он использует физический адрес для посылки межсетевого пакета прямо к В. Итоги всего вышесказанного можно изложить так:
Протокол Разрешения Адресов,ARP, позволяет ГВМ установить физический адрес ГВМ назначения в той же самой физической сети, имея только IP-адрес назначения.
<---|---------------------------------------->
===============|==========|==========|====================
| | | | | | |
| V | V | V |
----- ----- ----- -----
| А | | X | | B | | Y |
| | | | | | | |
----- ----- ----- -----
(а)
---------------------
======|===================|===============================
| | | | | |
| V | | | |
----- ----- ----- -----
| А | | X | | B | | Y |
| | | | | | | |
----- ----- ----- -----
(б)
Рисунок 5.1 Протокол ARP. Чтобы определить физический адрес В, Pb, по его IP-адресу, Ib, (а) ГВМ А широковещательно распространяет запрос ARP, содержащий Ib, по всем машинам, и (б) ГВМ В отвечает на него ответом ARP, содержащим пару (Ib,Pb).
Может показаться глупым то, что А, посылая пакет к В, сначала посылает широковещательный пакет, который достигает В. Или может показаться еще глупее, что А широковещательно задает вопрос:"Как я могу связаться с вами?" вместо того, чтобы просто широковещательно послать пакет, который он хочет передать. Но есть важная причина для таких передач. Широковещание слишком дорого, чтобы использовать его всякий раз, когда одной машине требуется передать пакет другой машине, так как оно требует от каждой машины в сети обработки широковещательного пакета. Чтобы уменьшить затраты на взаимодействие, ГВМ, использующие ARP, создают кэш недавно узнанных связок между физическим адресом и IP-адресом, и поэтому они не должны повторно использовать ARP. Всякий раз, когда ГВМ получает ответ ARP, он сохраняет IP-адрес машины и соответствующий ему аппаратный адрес в своем кэше для последующих обращений. При передаче пакета ГВМ ищет связку в кэше перед тем, как послать запрос ARP. Если ГВМ нашел нужную связку в своем кэше, ему не надо передавать широковещательный пакет в сеть. Опыт показывает, что так как большинство сетевых взаимодействий включает передачу более чем одного пакета, даже небольшой кэш будет полезен.
Можно сделать несколько уточнений ARP. Во-первых, заметим, что если ГВМ А использует ARP, так как ему нужно послать запрос к В, то существует большая вероятность того, что ГВМ В в ближайшем будущем тоже потребуется послать пакеты к А. Если мы учтем потребности В, мы можем избежать передачи лишнего траффика по сети, заставив А включить связку своего IP-адреса с физическим в пакет при посылке запроса к В. Во-вторых, отметим, что так как А широковещательно передает свой начальный запрос, все машины в сети получают его и могут выделить и сохранить в своих кэшах связку между IP-адресом и физическим адресом для А. В-третьих, когда новая машина появляется в сети(например, когда загружается операционная система), мы можем избежать того, что какая-либо другая машина будет запускать ARP, если широковещательно распространим пару IP-адреса и физического адреса новой машины. Следующее правило обобщает уточнения:
ARP - это низкоуровневый протокол, который скрывает базовую физическую сетевую адресацию, позволяя назначать IP-адреса по нашему выбору каждой машине. Мы будем думать о нем как о части физической сетевой системы, а не как о части межсетевых протоколов.
Функционально ARP состоит из двух частей. Одна часть определяет физические адреса при посылке пакета, а другая отвечает на запросы от других машин. Разрешение адресов для выходящих пакетов кажется элементарным, но некоторые детали усложняют реализацию. Получив IP-адрес назначения, ГВМ просматривает кэш ARP, чтобы проверить, не знает ли он уже физического адреса для этого IP-адреса. Если ГВМ знает его, он выделяет физический адрес, помещает данные в кадр, используя этот адрес, и посылает этот кадр. Если же он не знает отображения, он должен широковещательно передать запрос ARP и ждать ответа. Широковещание запроса ARP для нахождения отображения адреса может оказаться сложным. Машина получателя может быть выключена или быть слишком занята, чтобы принять запрос. Если такое случится, отправитель может не получить ответа или ответ может задержаться. Так как Ethernet является системой с негарантированной доставкой, то исходный широковещательный запрос ARP тоже может быть потерян(в этом случае отправитель должен будет повторно отправлять его по крайней мере еще один раз). Между тем ГВМ должен хранить исходный передаваемый пакет, чтобы его можно было послать, когда будет разрешен адрес(если задержка становится значительной, ГВМ может уничтожить передаваемый пакет). Фактически, ГВМ должен решить, можно ли работать другим прикладным программам, пока он обрабатывает запрос ARP(в большинстве случаев можно). Если можно, то он должен учитывать случай, когда приложение будет генерировать дополнительные запросы ARP для того же адреса, не посылая широковещательный запрос несколько раз для одного и того же получателя.
Наконец, рассмотрим случай, когда машина А получила связку для машины В, но оборудование В вышло из строя и было заменено. Хотя адрес В изменился, не изменилась связка в кэше А, поэтому А будет использовать несуществующий аппаратный адрес, делая успешный прием невозможным. Этот случай показывает, почему важно, чтобы программное обеспечение ARP рассматривало свою таблицу связок как кэш и удаляло ее элементы по истечении фиксированного промежутка времени. Конечно, таймер для каждого элемента кэша должен сбрасываться всякий раз, когда принимается широковещание ARP, содержащее эту связку(но не сбрасывается, когда этот элемент, используется для посылки пакета).
Вторая часть кода ARP обрабатывает пакеты ARP, прибывающие из сети. Когда появляется пакет ARP, это программное обеспечение должно выделить пару IP-адреса и аппаратного адреса отправителя, и проверить свой кэш на наличие в нем элемента для этого отправителя. Если в кэше есть элемент для указанного IP-адреса, обработчик обновит этот элемент, заменив физический адрес тем, что получен из пакета. Получатель затем обрабатывает оставшуюся часть пакета ARP.
Получатель должен обрабатывать два типа входящих пакетов ARP. Если входящий пакет ARP - запрос, принимающая машина должна проверить, не является ли она назначением для этого запроса(т.е. какая-то другая машина широковещательно выдала запрос о физическом адресе приемника). Если это так, то программное обеспечение ARP формирует ответ, указывая в нем свой физический адрес, и посылает ответ прямо тому, кто запрашивал. Получатель также добавляет пару адресов отправителя к своему кэшу, если там нет такой пары. если IP-адрес, указанный в запросе ARP, не совпадает с локальным адресом IP, то этот пакет является запросом на отображение между адресами для какой-то другой машины в сети и может игнорироваться.
Другой интересный случай возникает, когда приходит ответ ARP. В зависимости от реализации обработчику может понадобиться создание элемента кэша или такой элемент может уже существовать. В любом случае, как только кэш был обновлен, получатель пытается сопоставить ответ ранее выданному запросу. Обычно ответу соответствует запрос, сгенерированный в связи с тем, что машина имеет пакет, который нужно доставить. В промежуток времени между широковещательной передачей ARP-запроса и получением ответа прикладные программы или высокоуровневые протоколы могли сгенерировать дополнительные запросы для этого адреса; программное обеспечение должно помнить, что оно уже послало запрос и не посылать его больше. Обычно, оно помещает дополнительные запросы в очередь. Как только пришел ответ и физический адрес стал известен, программное обеспечение ARP удаляет элементы из очереди и отвечает на каждый из них полученной связкой. Если машина не выдавала запрос для IP-адреса, указанного в ответе, она прекращает обработку этого пакета.
Когда сообщения ARP пересылаются от одной машины к другой, они должны передаваться в физических кадрах. Рисунок 5.2 показывает, что сообщение ARP передается как поле данных кадра.
-------------------------------------
| сообщение ARP |
-------------------------------------
| |
V V
-----------------------------------------------------------
| заголовок кадра | поле данных кадра |
-----------------------------------------------------------
Рисунок 5.2 Сообщение ARP, заключенное в кадре физической сети
Чтобы идентифицировать, что кадр содержит запрос или ответ ARP, отправитель присваивает специальное значение полю типа в заголовке кадра и помещает сообщение ARP в поле данных кадра. Когда кадр прибывает на ГВМ, система смотрит тип кадра, чтобы определить его содержимое. Например, в Ethernete, кадры, несущие сообщения ARP, имеют в поле типа значение 0806 в шестнадцатиричном формате. Это стандартное значение, назначенное ведомством, устанавливающим стандарты Ethernetа.
В отличие от большинства протоколов, данные в пакетах ARP не имеют фиксированного формата заголовка. Вместо этого его сообщения были разработаны так, чтобы их можно было использовать для различных сетевых технологий. Поэтому, первые поля заголовка содержат счетчики, которые указывают длину следующих полей. Фактически, ARP можно использовать с произвольными физическими адресами и произвольными протокольными адресами. Пример на рисунке 5.3 показывает 28-октетный формат сообщения ARP, используемый для оборудования Ethernetа(у которого физические адреса являются 48-битовыми или 6-октетными) при разрешении протокольных адресов IP(имеющих длину 4 октета).
Рисунок 5.3 показывает сообщение ARP по 4 байта в строке, в формате, который будет стандартным на протяжении всей книги. К сожалению, в отличие от большинства остальных протоколов, поля переменной длины в пакетах ARP не выровнены на границу 32 бит, что приводит к трудности восприятия диаграммы. Например, аппаратный адрес отправителя, помеченный как ОТПРАВИТЕЛЬ АА, занимает 6 непрерывных октетов, что приводит к появлению его на двух строках диаграммы.
0 8 16 24 31 ----------------------------------------------------------- | ТИП ОБОРУДОВАНИЯ | ТИП ПРОТОКОЛА | ----------------------------------------------------------- | HLEN | PLEN | ОПЕРАЦИЯ | ----------------------------------------------------------- | ОТПРАВИТЕЛЬ АА (октеты 0-3) | ----------------------------------------------------------- |ОТПРАВИТЕЛЬ АА(октеты 4-5)|ОТПРАВИТЕЛЬ IP(октеты 0-1) | ----------------------------------------------------------- |ОТПРАВИТЕЛЬ IP(октеты 2-3)|ПОЛУЧАТЕЛЬ АА(октеты 0-1) | ----------------------------------------------------------- | ПОЛУЧАТЕЛЬ АА(октеты 2-5) | ----------------------------------------------------------- | ПОЛУЧАТЕЛЬ IP(октеты 0-3) | -----------------------------------------------------------
Рисунок 5.3 Пример формата сообщения ARP/RARP для разрешения адресов IP-Ethernet. Длины полей зависят от длин аппаратных и протокольных адресов, которые имеют значение соответственно 6 октетов для адреса Ethernetа и 4 октета для IP-адреса.
Поле ТИП ОБОРУДОВАНИЯ определяет тип аппаратного интерфейса, для которого отправитель ищет ответ; оно содержит значение 1 для Ethernetа. Аналогичным образом, поле ТИП ПРОТОКОЛА указывает тип адреса протокола более высокого уровня, который использует отправитель; оно содержит 0800 в шестнадцатиричном формате для IP-адреса. Поле ОПЕРАЦИЯ указывает запрос ARP(1), ответ ARP(2), запрос RARP(3), или ответ RARP(4)(RARP, другой протокол, использующий тот же самый формат сообщения, будет рассмотрен в следующей главе). Поля HLEN и PLEN позволяют использовать ARP в любых сетях, так как они указывают длину аппаратного адреса и адреса протокола верхнего уровня. Отправитель передает свой аппаратный адрес и IP-адрес, если они известны ему, в полях ОТПРАВИТЕЛЬ АА и ОТПРАВИТЕЛЬ IP.
При посылке запроса отправитель также указывает IP-адреса назначения(ARP) или аппаратного адреса назначения(RARP), используя поля ПОЛУЧАТЕЛЬ АА и ПОЛУЧАТЕЛЬ IP. Отвечающая машина перед передачей ответа заполняет отсутствующие адреса, меняет местами пары отправителя и получателя и меняет код операции на ответ. Поэтому ответ содержит IP- и аппаратный адреса исходного отправителя, а также IP- и аппаратный адреса машины, которая разрешила эту связку.
IP-адреса назначаются независимо от физического аппаратного адреса машины. Чтобы доставить межсетевой пакет, сетевое программное обеспечение должно отобразить IP-адрес в физический аппаратный адрес и использовать этот аппаратный адрес для передачи кадра. Если аппаратные адреса являются небольшими числами, которые могут быть легко изменены, можно реализовать прямое отображение, закодировав физические адреса машин в их IP-адресах. Иначе, отображение должно выполняться динамически. Протокол Разрешения Адресов(ARP) выполняет динамическое разрешение адресов, используя только низкоуровневую сетевую коммуникационную систему. ARP позволяет машинам разрешать адреса, не храня постоянно информации о связках адресов.
Машина использует ARP, чтобы найти аппаратный адрес другой машины с помощью широковещания запроса ARP. Запрос содержит IP-адрес машины, для которой нужно узнать аппаратный адрес. Каждая машина отвечает на запросы, соответствующие ее IP-адресу, посылая ответы, содержащие требуемый аппаратный адрес. Чтобы сделать ARP эффективным, каждая машина кэширует связки (IP-адрес;аппаратный адрес). Так как межсетевой траффик имеет тенденцию состоять из последовательности взаимодействий между парами машин, кэш приводит к ненужности большинства широковещательных запросов ARP.
Протокол разрешения адресов, использованный здесь, описан Plumer[RFC 826] и стал стандартным межсетевым протоколом. Dalal и Printis[1981] описывают связь между адресами IP и Ethernetа, а Clark[RFC 814] обсуждает адреса и связки в общем. Parr[RFC 1029] рассматривает разрешение адресов, устойчивое к ошибкам. Документ Межсетевые Номера[RFC 1010] указывает значения, используемые для идентификации сетевых кадров. Comer[1987] представляет пример реализации ARP для операционной системы Xinu.
5.1 Вам задано небольшое множество физических адресов(положительных целых чисел). Найдите функцию F и назначения для IP-адресов, такие, что F отображает однозначно IP-адреса в физические адреса и вычисление F эффективно. 5.2 В каком особом случае ГВМ, присоединенному к Ethernetу, не надо использовать ARP , или кэш ARP перед передачей дейтаграммы IP ?
5.3 Один известный алгоритм управления кэшем ARP заменяет элемент, не использовавшийся самое долгое время, при добавлении нового. При каких условиях этот алгоритм может приводить к генерации избыточного траффика ?
5.4 Должен ли ARP обновлять кэш, если для заданного IP-адреса уже существует элемент ? Почему да или почему нет ?
5.5 Должен ли ARP модифицировать кэш даже в том случае, когда он получает информацию, которую он не запрашивал ? Почему да или почему нет ?
5.6 Любая реализация ARP, использующая кэш фиксированного размера, может аварийно завершиться, если используется в сети, имеющей много ГВМ и много траффика ARP. Объясните почему.
5.7 ARP часто считается слабым в отношении секретности. Объясните почему.
5.8 Объясните, что может произойти, если поле аппаратного адреса в запросе ARP разрушится при передаче по сети. Замечание: реализации ARP обычно не удаляют элементы кэша, если они часто используются.
5.9 Предположим, что машина С приняла запрос ARP, посланный от А к машине В, и предположим, что С имеет связку для Ib в своем кэше. Следует ли С отвечать на этот запрос ? Объясните.
5.10 Как может рабочая станция использовать ARP при своей загрузке для того, чтобы установить, нет ли в сети какой-либо другой машины с таким же адресом ? Каковы недостатки этой схемы ?
Назад | Содержание | Вперед
Мы уже знаем, что физические сетевые адреса являются как низкоуровневыми, так и аппаратно зависимыми, и мы знаем, что каждой машине, использующей TCP/IP, назначен один или несколько 32-битовых IP-адресов, которые независимы от аппаратных адресов машины. прикладные программы всегда используют IP-адрес при указании назначения. ГВМ и шлюзы должны использовать физические адреса для передачи дейтаграмм по базовым сетям; они полагаются на схемы разрешения адресов, такие как ARP, при выполнении связывания.
Обычно IP-адрес машины хранится во внешней памяти, откуда операционная система и берет его при начальной загрузке. Возникает вопрос: "Как бездисковая машина, не имея доступа к внешней памяти, определяет свой IP-адрес?" Эта проблема является критической для бездисковых станций, использующих IP-адрес для взаимодействия с файл-сервером. Более того, так как много бездисковых машин используют стандартные протоколы передачи файлов TCP/IP для получения начального образа при загрузке, они должны получать и использовать IP-адреса до начала работы операционной системы. Эта глава изучает вопрос о том, как получить IP-адреса, и описывает протокол, который используют бездисковые машины.
Чтобы одна программа могла использоваться на нескольких машинах, в состав ее исполняемого образа не должен входить IP-адрес машины. В частности, разработчики пытаются не включать конкретные IP-адреса как в код начальной загрузки, так и в операционную систему, чтобы один и тот же код мог работать на нескольких машинах. Когда такая программа начинает выполняться на бездисковой машине, она должна использовать сеть для взаимодействия с сервером, чтобы получить от него свой IP-адрес. Эта процедура кажется парадоксальной: машина взаимодействует с удаленным сервером для получения адреса, необходимого для взаимодействия.
Но парадокс здесь только кажущийся, так как машина знает, как взаимодействовать. Она может использовать свой физический адрес для взаимодействия в локальной сети. Поэтому машина должна временно применять физическую сетевую адресацию аналогично тому, как операционные системы применяют физическую адресацию памяти при установке таблиц для виртуальной адресации. Как только машина узнает свой межсетевой адрес, она может взаимодействовать со всем интернетом.
Идея, лежащая в основе нахождения IP-адреса, проста: бездисковая машина посылает запрос другой машине, называемой сервером(глава 18 более детально описывает серверы), и ждет, пока сервер не пошлет ответ. Мы будем предполагать, что сервер имеет диск, на котором он хранит базу данных межсетевых адресов. В этом запросе машина, которой нужно узнать свой межсетевой адрес, должна идентифицировать себя уникальным образом, сервер мог найти ее межсетевой адрес и послать ответ. Как посылающая запрос машина, так и отвечающий ей сервер используют физические сетевые адреса в ходе своего короткого взаимодействия. Но откуда бездисковая машина знает физический адрес сервера ? Обычно она его и не знает - она просто широковещательно передает запрос ко всем машинам в локальной сети. Ей отвечают один или более серверов.
Когда бездисковая машина широковещательно передает запрос, она должна уникальным образом идентифицировать себя. Но какую информацию можно включить в запрос, которая бы уникально идентифицировала машину ? Для этой цели может подойти любая уникальная аппаратная идентификация(например, последовательный номер ЦП). Тем не менее, нам нужна идентификация, которую может получить работающая программа. Наша цель - создать один исполняемый код, который может выполняться на любом процессоре. Более того, длина или формат информации, идентифицирующей ЦП, могут отличаться у различных моделей процессоров, а нам хотелось бы иметь сервер, который принимает запросы от всех машин в физической сети, используя один формат.
Разработчики протоколов TCP/IP сообразили, что есть другая уникально идентифицирующая информация, которая всегда доступна, короче, физический сетевой адрес машины. Использование этого физического адреса как уникальной идентификации имеет два преимущества. Так как ГВМ получает свои физические адреса от сетевого интерфейсного оборудования, такие адреса всегда доступны и не входят в состав кода операционной системы. Так как идентифицирующая информация зависит от сети, а не от модели ЦП, все машины в сети будут поддерживать единообразные, уникальные идентификаторы. Поэтому задача становится обратной по отношению к разрешению адресов: имеется физический сетевой адрес; разработать схему, которая позволяла бы серверу отображать его в межсетевой адрес.
Бездисковая машина использует протокол интернета TCP/IP, называемы RARP(протокол обратного разрешения адресов), для получения своего IP-адреса от сервера. RARP создан на основе протокола ARP из предыдущей главы и использует тот же самый формат сообщений, который приведен на рисунке 5.3. На практике сообщение RARP, посылаемое при запросе межсетевого адреса, является несколько более общим, чем то, что описано выше: оно позволяет машине запрашивать IP-адрес не только себе, но и другим машинам. Оно также допускает несколько типов физических сетей. Как и сообщение ARP, сообщение RARP пересылается с одной машины на другую в поле данных кадра Ethernetа. Кадр Ethernetа, несущий запрос RARP, имеет обычную преамбулу, адреса отправителя и получателя Ethernetа, и поле типа пакета в начале себя. Поле типа содержит значение 8035, что идентифицирует содержимое этого кадра как сообщение RARP. Поле данных кадра содержит 28-октетное сообщение RARP.
Рисунок 6.1 иллюстрирует, как ГВМ использует RARP. Отправитель широковещательно передает запрос RARP, в котором указывает свой адрес в качестве как машины отправителя, так и машины получателя, заполняя поле аппаратного адреса назначения своим физическим сетевым адресом. Все машины в сети принимают запрос, но только те из них, кто отвечает за поддержку RARP, обрабатывают запрос и посылают ответ; такие машины называют серверами RARP. Для успешного использования RARP в сети должен быть по крайней мере один сервер RARP.
-<==-===============================================>--------
^ | | |
| V V V
+++++++ +++++++ +++++++ +++++++
+ А + + B + + C + + D +
+++++++ +++++++ +++++++ +++++++
(a)
-----=========================================---------------
| | ^ ^
V | | |
+++++++ +++++++ +++++++ +++++++
+ А + + B + + C + + D +
+++++++ +++++++ +++++++ +++++++
(b)
Рисунок 6.1 Пример обмена, используя протокол RARP. (a) Машина А посылает широковещательный запрос RARP, указывая себя как машину получателя, и (b) машины, ответственные за поддержку средства RARP(C и D), отвечают прямо А.
Серверы отвечают на запросы, заполняя поля протокольного адреса назначения, меняя тип сообщения на ответ, и посылая ответ прямо машине, выдавшей запрос. Эта исходная машина принимает ответы от всех серверов RARP, несмотря на то, что ей нужен только первый ответ.
Помните, что все взаимодействия между машиной, ищущей свой IP-адрес, и сервером, знающим его, должны осуществляться, используя только одну физическую сеть. Более того, этот протокол позволяет ГВМ запрашивать IP-адрес произвольной машины. Поэтому отправитель указывает свой аппаратный адрес помимо аппаратного адреса получателя, а сервер учитывает это при отправке ответа по аппаратному адресу отправителя. В Ethernetе наличие поля для аппаратного адреса отправителя может показаться лишним, так как эта же информация содержится в заголовке кадра Ethernetа. Тем не менее, не все оборудование Ethernetа позволяет операционной системе получать доступ к заголовку физического кадра.
Как и любое взаимодействие в сети с негарантированной доставкой, запросы RARP могут потеряться или исказиться. Так как RARP использует физическую сеть напрямую, никакое другое протокольное программное обеспечение не будет измерять время до получения ответа или повторно передавать запрос; само программное обеспечение RARP должно решать эти задачи. Вообще RARP используется только для локальных сетей, таких как Ethernet, где вероятность сбоя мала. Тем не менее, если сеть имеет только один сервер RARP, то эта машина может не справиться с такой большой нагрузкой, и ряд пакетов может быть потерян.
Многие бездисковые машины рассчитывают на RARP при загрузке и могут повторять запрос до тех пор, пока они не получат ответа. Другие реализации сообщают, что обнаружена неисправность в сети после нескольких неудачных попыток, чтобы избежать переполнения сети ненужным широковещательным траффиком(т.е. в случае, когда сервер недоступен). В Ethernetе сетевая ошибка менее вероятна, чем перегрузка сервера . Заставляя программное обеспечение RARP часто повторять запрос, можно добиться того, что сервер будет буквально захлестнут волной избыточного траффика. В то же время использование большого времени ожидания ответа гарантирует, что у серверов будет достаточно времени для приема запроса и выдачи ответа.
Главным преимуществом использования группы машин как серверов RARP является то, что это делает систему более надежной. Если один сервер вышел из строя или перегружен и не может ответить, другой ответит на запрос. Поэтому существует большая вероятность того, что средство будет постоянно доступно. Главный же недостаток использования нескольких серверов заключается в том, что когда машина передает широковещательный запрос RARP, сеть становится перегруженной из-за того, что все серверы пытаются на него ответить. В Ethernetе, например, использование нескольких серверов RARP приводит к высокой вероятности возникновения коллизии.
Как разместить средство RARP так, чтобы оно было надежным и доступным, и при этом не было бы нескольких одновременных ответов? Существует по крайней мере две возможности, и обе они используют паузы при ответе. В первом случае, каждой машине, выдающей запросы RARP, назначается основной сервер. Обычно только основной сервер машины отвечает на ее запросы RARP. Все неосновные серверы принимают запрос, но лишь запоминают время его поступления. Если основной сервер недоступен, пославшая запрос машина будет ждать определенное время ответа, а затем повторно пошлет запрос. А неосновной сервер, получив вторую копию запроса RARP вскоре после первой, ответит на него.
Во втором случае используется аналогичная схема, но делается попытка избежать одновременного ответа всеми неосновными серверами. Каждая неосновная машина, принимающая запрос, выжидает случайное время, а затем посылает ответ. При нормальных условиях основной сервер отвечает сразу же, а последующие ответы будут передаваться через некоторое время, поэтому их появление в одно и то же время маловероятно. Когда основной сервер недоступен, запрашивающая машина подбирает небольшое время для паузы перед приемом ответа. При умелом подборе паузы разработчик может добиться того, что запрашивающие машины не будут повторно передавать широковещательного запроса до получения ответа.
При загрузке системы бездисковая машина должна связаться с сервером , чтобы определить свой IP-адрес перед тем, как она начнет взаимодействие, используя TCP/IP. Мы рассмотрели протокол RARP, который использует физическую сетевую адресацию для получения межсетевого адреса машины. Механизм RARP применяет физический аппаратный адрес машины для уникальной идентификации процессора и широковещательной передачи запросов RARP. Серверы в сети принимают сообщение, ищут отображение для него в таблице(предварительно загруженной с диска), и отвечают отправителю. Как только машина принимает свой IP-адрес, она запоминает его в памяти и не использует RARP до тех пор, пока она снова не будет загружать систему.
Детальное описание RARP можно найти в Finlayson et al[RFC 903]. Finlayson [RFC 906] описывает загрузку системы на рабочей станции с использованием протокола TFTP. Comer[1987] описывает пример реализации RARP для операционной системы Xinu.
Глава 19 рассматривает альтернативу RARP, известную как BOOTP. В отличие от схемы определения низкоуровневого адреса, применяемой в RARP, BOOTP построен на основе протоколов более высокого уровня, таких как IP и UDP. Глава 19 сравнивает эти два подхода, рассматривая преимущества и недостатки каждого.
6.1 Сервер RARP может широковещательно передавать ответы RARP всем машинам или передавать каждый ответ только машине, выдавшей этот запрос. Можно ли назвать систему, в которой применяются широковещательные ответы для всех машин, выгодной?
6.2 RARP является узкоспециализированным протоколом в том смысле, что его ответы содержат всего лишь одну часть информации(т.е. запрошенный IP-адрес). Когда бездисковая машина загружается, ей обычно нужно знать время и имя машины помимо межсетевого адреса. Расширьте RARP для поддержки дополнительной информации.
6.3 Насколько больше станут кадры Ethernetа, если к RARP добавить информацию, описанную в предыдущем примере.
6.4 Добавление второго сервера RARP к сети увеличивает надежность. Имеет ли смысл добавить третий сервер? А четвертый ? Почему да или почему нет ?
6.5 Бездисковые рабочие станции одного производителя используют RARP для получения своих IP-адресов, но всегда предполагают, что ответ приходит от файл-сервера рабочей станции. Затем бездисковая машина пытается получить загрузочный образ от этого сервера. Если она не получает ответа, эта рабочая станция входит в бесконечный цикл широковещательной передачи запросов на загрузку. Объясните, как добавление дублирующего сервера RARP к такой конфигурации может привести к переполнению сети широковещательными запросами. Замечание: обратите внимание на сбои питания.
Назад | Содержание | Вперед
Мы уже рассмотрели части сетевого оборудования и программного обеспечения, которые делают возможным межсетевое взаимодействие, объяснили базовые сетевые технологии и разрешение адресов. Эта глава рассматривает фундаментальный принцип доставки без установления соединения и обсуждает, как он реализуется с помощью Межсетевого протокола(IP), одного из двух основных протоколов, используемых при межсетевом обмене. Мы изучим формат дейтаграмм IP и увидим, как они образуют основу для всех видов межсетевого взаимодействия. Следующие две главы продолжат изучение Межсетевого Протокола, обсуждая вопросы маршрутизации дейтаграмм и обработки ошибок.
Глава 3 рассмотрела межсетевую архитектуру, в которой машины-шлюзы соединяют группу физических сетей. Знание архитектуры может ввести в заблуждение, так как внимание следует сосредоточить на интерфейсе, который предоставляет интернет пользователям, а не на технологии взаимного соединения.
Пользователь представляет себе интернет в виде одной виртуальной сети, соединяющей все ГВМ, с помощью которой и делается возможным взаимодействие; его настоящая архитектура является невидимой и ненужной.
По существу интернет является абстракцией физической сети, так как, на самом нижнем уровне, он обеспечивает те же самые возможности: прием пакетов и доставка их. Более высокие уровни межсетевого программного обеспечения добавляют большую часть богатых возможностей, доступным пользователям.
На концептуальном уровне интернет TCP/IP обеспечивает три множества средств, как показано на рисунке 7.1; их расположение на рисунке предполагает зависимости между ними. На самом нижнем уровне, средство доставки без установления соединения обеспечивает основу для всего остального. На следующем уровне надежное транспортное средство обеспечивает платформу более высокого уровня, от которую опираются приложения. Мы вскоре освоим каждое из этих трех средств, поймем, что они обеспечивают, и увидим, какие протоколы связаны с ними.
--------------------------------------------
| ПРИКЛАДНЫЕ СРЕДСТВА |
--------------------------------------------------
| НАДЕЖНОЕ ТРАНСПОРТНОЕ СРЕДСТВО |
--------------------------------------------------------
| СРЕДСТВО ДОСТАВКИ ПАКЕТОВ БЕЗ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ|
--------------------------------------------------------
Рисунок 7.1 Три концептуальные уровня межсетевых средств
Хотя мы можем связать протокольное программное обеспечение с каждым из средств на рисунке 7.1, причина выделения их как концептуальных частей интернета состоит в том, что они ясно указывают на философские предпосылки при разработке. Главное заключается в том, что:
Программное обеспечение Интернета разработано на основе трех концептуальных сетевых средств, расположенных в иерархическом порядке; основная причина их успеха состоит в том, что эта архитектура является очень надежной и адаптируемой.
Одним из самых значительных преимуществ такого концептуального разделения является то, что становится возможным заменить одно средство, не влияя при этом на работу других. Поэтому, можно организовать параллельные исследование и разработку всех трех средств.
Самое фундаментальное межсетевое средство представляет собой систему доставки пакетов. Технически это средство определено как ненадежная система доставки пакетов без установления соединения, аналогично средству, обеспечиваемому сетевым оборудованием, которое работает по принципу негарантированной доставки. Это средство называется ненадежным, так как доставка не гарантируется. Пакеты могут быть потеряны, дублированы, задержаны или доставлены не по порядку, но средство не обнаружит такие ситуации, а также не сможет сообщить о них отправителю или получателю. Это средство называется "без установления соединения", так как каждый пакет обрабатывается независимо от других пакетов. Последовательность пакетов, посылаемая от одной машины к другой, может передаваться по различным путям, а некоторые из них могут быть даже потеряны, в то время, как остальные будут доставлены. Наконец, можно сказать, что средство использует доставку в лучшем случае (best-effort delivery), так как межсетевое программное обеспечение делает настоящую попытку доставить пакет. То есть, интернет не удаляет пакеты по своему желанию; ненадежность возникает только тогда, когда не хватает ресурсов, или происходят сбои в используемых физических сетях.
Протокол, который определяет ненадежной доставки без установления соединения, называется Межсетевым Протоколом, и обычно обозначается своими инициалами, IP(аббревиатура IP привела к появлению термина IP-адрес). IP обеспечивает определение трех важных вещей. Во-первых, протокол IP определяет базовый элемент передачи данных, используемый во всем интернете TCP/IP. Во-вторых, программное обеспечение IP выполняет функцию маршрутизации, выбора пути, по которому будут передаваться данные. В-третьих, помимо точной, формальной спецификации форматов данных и функции маршрутизации, IP включает набор правил, которые воплощают в жизнь идею ненадежной доставки пакетов. Эти правила указывают, как ГВМ и шлюзам следует обрабатывать пакеты, как и когда следует генерировать сообщения об ошибках, и условия, при которых можно удалять пакеты. IP является такой фундаментальной частью, что интернет TCP/IP иногда называют технологией на основе IP.
Мы начинаем рассмотрение IP в этой главе с обзора формата пакета, описанного в нем. Маршрутизацию и обработку ошибок мы рассмотрим в следующих главах.
Между физической сетью и интернетом TCP/IP существует много аналогий. В физической сети единицей передачи является кадр, который состоит из заголовка и данных, где заголовок содержит информацию, такую как адреса отправителя и получателя. Интернет называет свой базовый элемент передачи межсетевой дейтаграммой(иногда ее называют IP-дейтаграммой или просто дейтаграммой). Как и кадр физической сети, дейтаграмма делится на поле заголовка и поле данных. Кроме того, как и кадр, заголовок дейтаграммы содержит адреса отправителя и получателя, а также поле типа, которое идентифицирует содержимое дейтаграммы. Ну, и конечно, разница между ними состоит в том, что заголовок дейтаграммы содержит IP-адреса, в то время как заголовок кадра - физические адреса. Рисунок 7.2 показывает общую форму дейтаграммы:
----------------------------------------------------------- | ЗАГОЛОВОК | ОБЛАСТЬ ДАННЫХ | | ДЕЙТАГРАММЫ | ДЕЙТАГРАММЫ | -----------------------------------------------------------
Рисунок 7.2 Общая форма IP-дейтаграммы, аналогии сетевому кадру в TCP/IP. IP специфицирует формат заголовка, включая IP-адреса источника и назначения. IP не описывает формат области данных; она может быть использована для транспортировки произвольных данных.
Теперь, после того, как мы описали общий формат IP-дейтаграммы, можно рассмотреть ее содержимое более детально. Рисунок 7.3 показывает расположение полей дейтаграммы:
0 4 8 16 19 24 31 ------------------------------------------------------------ |версия|длина| тип сервиса| общая длина | ------------------------------------------------------------ | идентификация |флаги |смещение фрагмента | ------------------------------------------------------------ |время жизни | протокол | КС заголовка | ------------------------------------------------------------ | IP-адрес отправителя | ------------------------------------------------------------ | IP-адрес получателя | ------------------------------------------------------------ | Опции IP(если есть) |заполнение | ------------------------------------------------------------ | Данные | ------------------------------------------------------------ | ... | ------------------------------------------------------------
Рисунок 7.3 Формат дейтаграммы Интернета, основного элемента передачи в интернете TCP/IP.
Так как обработка дейтаграммы происходит с помощью программного обеспечения, оборудование не накладывает никаких ограничений на ее содержимое и формат. Например, первое 4-битовое поле в дейтаграмме(ВЕРСИЯ) содержит версию протокола IP , используемую при создании дейтаграммы. Оно используется отправителем, получателем, и всеми шлюзами между ними для уверенности в том, что все они используют один и тот же формат дейтаграммы. Всему программному обеспечению IP требуется проверять поле версии перед обработкой дейтаграммы, чтобы быть уверенным в том, что ее формат соответствует тому формату, который ожидает это обеспечение. Если стандарт меняется, машины будут отбрасывать дейтаграммы с версией протокола, отличающейся от версии, на которой они работают, предохраняя себя от неправильной интерпретации содержимого дейтаграммы из-за устаревшего формата. Текущая версия протокола IP - 4.
Поле длины заголовка(ДЛИНА) также занимает 4 бита и хранит длину заголовка дейтаграммы в 32-битных словах. Как мы увидим, все поля в заголовке имеют фиксированную длину, за исключением поля ОПЦИИ IP и соответствующего ему поля ЗАПОЛНЕНИЕ. Наиболее простой заголовок, без опций и заполнения, занимает 20 октетов и имеет в поле длины заголовка значение 5.
Поле ОБЩАЯ ДЛИНА дает длину IP-дейтаграммы, измеренную в октетах, включая октеты в заголовке и данных. Размер области данных может быть вычислен с помощью вычитания длины заголовка(ДЛИНА) из ОБЩЕЙ ДЛИНЫ. Так как поле ОБЩАЯ ДЛИНА занимает 16 бит, максимально возможный размер дейтаграммы IP - 65535 октетов. В большинстве приложений это ограничение несущественно. Но оно может стать важным в будущем, когда сети с более высокими скоростями смогут передавать пакеты данных длиннее чем 65535 октетов.
8-битовое поле ТИП СЕРВИСА указывает, как следует обрабатывать дейтаграмму, и разделено на пять подполей, как показано на рисунке 7.4:
0 1 2 3 4 5 6 7 ------------------------------------------------------------- | приоритет | D | T | R | не используется | -------------------------------------------------------------
Рисунок 7.4 Пять подполей, составляющих 8-битовое поле типа сервиса
Три бита ПРИОРИТЕТА указывают приоритет дейтаграммы, значения которого могут меняться от 0(обычный приоритет) до 7(управление сетью), позволяя отправителям передавать информацию о важности каждой дейтаграммы. Хотя программное обеспечение большинства ГВМ и шлюзов игнорирует тип сервиса, он является важным понятием, так как обеспечивает механизм, который впоследствии позволит управляющей информации иметь больший приоритет, чем данные. Например, если все ГВМ и шлюзы будут учитывать приоритет, станет возможной реализация алгоритмов управления перегрузкой сети, на которые не будет влиять перегрузка, которой они пытаются управлять.
Биты D, T и R описывают тип передачи, который нужен дейтаграмме. Установка бита D запрашивает минимальные задержки при передаче, бита T - максимальную пропускную способность, а бита R - максимальную надежность. Конечно, интернет не может гарантировать выполнение запрошенного сервиса(например, может быть так, что нет пути к назначению с запрошенными качествами). Поэтому, мы будем рассматривать запрос сервиса как указание алгоритмам маршрутизации, а не как требование. Если шлюз знает более чем один маршрут к указанному назначению, он может использовать поле типа транспорта для выбора пути с характеристиками наиболее близкими требуемым. Например, предположим, что шлюз может выбирать между низкоскоростной арендованной линией или высокоскоростной(но с большими паузами) спутниковой линией. Дейтаграммы, передающие нажатия клавиш от пользователя к удаленному компьютеру, могут иметь установленным бит D, запрашивая таким образом самую быструю доставку, в то время как дейтаграммы, используемые при передаче большого файла, могут иметь установленным бит T, запрашивая передачу по высокоскоростной спутниковой линии.
Важно понимать, что алгоритмы маршрутизации должны выбирать из используемых физических сетевых технологий , которые имеют определенные характеристики задержки, пропускной способности и надежности. Часто данная технология использует компромисс между этими характеристиками(например, высокой скоростью передачи и большей задержкой). Поэтому, идея состоит в том, чтобы дать алгоритму указание о том, что наиболее важно; не имеет смысла указывать все три типа сервиса. Подведем итоги:
Мы рассматриваем спецификацию типа передачи как указание алгоритму маршрутизации, которое помогает выбрать один путь к назначению из группы на основе знаний об аппаратных технологиях, использующихся на этих путях. Интернет не гарантирует выполнения запрошенного транспортного сервиса.
Перед тем, как мы сможем понять следующие поля дейтаграммы, нам нужно рассмотреть, как дейтаграммы соотносятся с кадрами физической сети. Мы начнем с вопроса: "Каков максимальный размер дейтаграммы ?" В отличие от кадров физической сети, которые должны распознаваться оборудованием, дейтаграммы обрабатываются программным обеспечением. Они могут иметь любую длину, какую выберут разработчики протокола. Мы видели, что текущий формат дейтаграммы выделяет 16 бит под поле общей длины, ограничивая дейтаграмму 65535 октетами. Тем не менее, этот предел может быть изменен в следующих версиях протокола.
Более фундаментальные ограничения на размер дейтаграммы накладываются практикой работы. Мы знаем, что по мере того, как дейтаграммы передаются от одной машины к другой, они всегда должны транспортироваться базовыми физическими сетями. Для эффективности межсетевой передачи нам нужно быть уверенным в том, что каждая дейтаграмма передается в отдельном физическом кадре. То есть, мы хотим, чтобы наша абстракция пакета физической сети напрямую соответствовала реальному пакету, если это возможно. Идея передачи одной дейтаграммы в одном сетевом кадре называется инкапсуляцией. Для базовой сети дейтаграмма выглядит так же, как и любое другое сообщение, посылаемое от одной машины к другой. Оборудование как не знает формата дейтаграммы, так и не понимает IP-адреса назначения. Поэтому, как показывает рисунок 7.5, когда одна машина посылает IP-дейтаграмму другой, вся дейтаграмма передается как часть данных сетевого кадра.
-------------------------------------------------
|заголовок | область данных дейтаграммы |
|дейтаграммы | |
-------------------------------------------------
| |
V V
-----------------------------------------------------------
|заголовок| |
|кадра | область данных кадра |
-----------------------------------------------------------
Рисунок 7.5 Инкапсуляция IP-дейтаграммы в кадр. Физическая сеть рассматривает всю дейтаграмму, включая заголовок, как данные.
В идеальном случае вся дейтаграмма IP помещается в одном физическом кадре, делая эффективной передачу по физической сети(Одно из полей в заголовке кадра идентифицирует, какие данные передаются. Ethernet использует значение типа 0800(в шестн) для указания того, что область данных содержит инкапсулированную дейтаграмму IP). Чтобы достигнуть такой эффективности, разработчики IP могли выбрать максимальный размер дейтаграммы таким, чтобы она всегда помещалась в один кадр. Но какой размер кадра следует выбрать ? Помимо всего прочего, дейтаграмма может передаваться по различным типам физических сетей по мере того, как она транспортируется по интернету к своему назначению.
Чтобы понять проблему, нам нужно знать одну вещь о сетевом оборудовании: каждая технология коммутации пакетов устанавливает фиксированную верхнюю границу количества данных, которые могут быть переданы в одном физическом кадре. Например, Ethernet ограничивает размер передачи 1500 октетами данных(ограничение в 1500 октетов взято из спецификации Ethernetа; использование заголовка SNAP со стандартом 802.3 ограничивает размер до 1492 октетов. Некоторое оборудование допускает несколько большие кадры), в то время как proNET-10 допускает кадры до 2044 октетов. Мы будем называть такие ограничения МАКСИМАЛЬНАЯ ЕДИНИЦА ПЕРЕДАЧИ(maximum transfer unit - MTU) или МЕП. Величина МЕП может быть довольно маленькой: некоторые аппаратные технологии ограничивают размер передачи до 128 октетов или даже меньше. Ограничение размера дейтаграмм до наименьшего МЕП в интернете делает передачу неэффективной, когда эти дейтаграммы передаются по сети, которая может транспортировать кадры большего размера. Тем не менее, разрешение дейтаграммам иметь размер больший, чем минимальный сетевой МЕП в интернете, означает, что дейтаграммы не всегда будут помещаться в один сетевой кадр.
Выбор понятен: ключевым моментом при разработке интернета было стремление скрыть базовые сетевые технологии и сделать взаимодействие удобным для пользователя. Поэтому, вместо разработки дейтаграмм, удовлетворяющих текущим ограничениям физических сетей, программное обеспечение TCP/IP выбирает удобный начальный размер дейтаграммы и определяет способ разделения больших дейтаграмм на маленькие части, когда дейтаграмма пересекает сеть, имеющую маленький МЕП. Маленькие части, на которые делится дейтаграмма, называются фрагментами, а процесс деления дейтаграммы - фрагментацией.
Как показывает рисунок 7.6, фрагментация обычно осуществляется шлюзом где-либо на пути между отправителем дейтаграммы и ее истинным получателем. Шлюз принимает дейтаграмму из сети с большим МЕП и должен передать ее по сети, в которой МЕП меньше, чем размер дейтаграммы.
------- -------
|ГВМ | |ГВМ |
| А | | Б |
------- -------
| |
Сеть 1| + + Сеть 3|
--------------- + + ----------------
МЕП=1500 | ----- + Сеть 2 + ----- | МЕП=1500
--|Ш1 |-- +-----|Ш2 |---
----- + МЕП=620 + -----
+ + +
+ + +
Рисунок 7.6 Иллюстрация того, где происходит фрагментация. Шлюз Ш1 фрагментирует большие дейтаграммы, посылаемые от А к Б; Ш2 фрагментирует большие дейтаграммы, посылаемые от Б к А.
На рисунке оба ГВМ напрямую присоединения к Ethernetам, которые имеют МЕП в 1500 октетов. Поэтому оба ГВМ могут генерировать и посылать дейтаграммы до 1500 октетов длины. Путь между ними, тем не менее, включает сеть с МЕП, равным 620. Если ГВМ А посылает ГВМ Б дейтаграмму длиннее 620 октетов, шлюз Ш1 будет фрагментировать дейтаграмму. Аналогично, если Б посылает большую дейтаграмму А, шлюз Ш2 будет фрагментировать дейтаграмму. Размер фрагмента выбирается таким, чтобы каждый фрагмент мог транспортироваться в одном кадре. Кроме того, так как IP передает значение смещения данных в восьмерках октетов, размер фрагмента должен быть выбран кратным восьми. Конечно, выбор числа октетов, кратного восьми и наиболее близкого к сетевой МЕП, не обязательно делит дейтаграмму на равные части; последняя часть часто короче, чем остальные. Фрагменты должны собираться для воссоздания полной копии исходной дейтаграммы перед тем, как она будет обрабатываться у получателя.
Протокол IP как не ограничивает дейтаграммы до маленького размера, так и не гарантирует, что большие дейтаграммы будут доставлены без фрагментации. Отправитель может выбрать любой размер дейтаграммы, какой он посчитает уместным; фрагментация и сборка производятся автоматически, не требуя специальных действий от отправителя. Спецификация IP устанавливает, что шлюзы должны принимать дейтаграммы с размерами, не превосходящими МЕП сетей, к которым они присоединены. Кроме того, шлюзы должны всегда обрабатывать дейтаграммы до 576 октетов. (От ГВМ также требуется принимать и собирать при необходимости дейтаграммы не короче 576 октетов).
Фрагментация дейтаграммы означает разделение ее на несколько частей. Вы можете удивиться, когда узнаете, что каждая часть имеет точно такой же формат, как и исходная дейтаграмма. Рисунок 7.7 иллюстрирует результат фрагментации.
------------------------------------------------------------
| заголовок | данные1 \ данные2 \ данные3 |
| дейтаграммы | 600 октетов \ 600 октетов \200 октетов |
------------------------------------------------------------
(а)
------------------------------
|заголовок | данные1 | фрагмент 1(смещение 0)
|фрагмента 1 | |
------------------------------
------------------------------
|заголовок | данные2 | фрагмент 2(смещение 600)
|фрагмента 2 | |
------------------------------
-------------------------
|заголовок | данные3| фрагмент 3(смещение 1200)
|фрагмента 3 | |
-------------------------
(б)
Рисунок 7.7 (а) Исходная дейтаграмма. несущая 1400 октетов данных и (б) три фрагмента для сети с МЕП. равной 620. Заголовки 1 и 2 имеют установленный бит ЕЩЕ ФРАГМЕНТЫ. Смещения показаны в октетах, их нужно разделить на 8, чтобы получить значение, хранящееся в заголовках фрагментов.
Каждый фрагмент содержит заголовок дейтаграммы, который дублирует большую часть заголовка исходной дейтаграммы(кроме бита в поле ФЛАГИ, который показывает. что это фрагмент), и столько данных, сколько может содержать фрагмент, чтобы общая длина была меньше, чем МЕП сети, по которой он путешествует.
Стоит ли собирать дейтаграмму после прохождения одной сети, или лучше передать фрагменты к месту назначения, а уж потом собирать их ? В интернете TCP/IP как только дейтаграмма была фрагментирована, фрагменты передаются как отдельные дейтаграммы на всем протяжении пути до места назначения, где они и должны собираться. Оставление фрагментации на всем протяжении пути имеет два недостатка. Во-первых, так как дейтаграммы не собираются сразу же после прохождения сети с маленьким МЕП, маленькие фрагменты будут передаваться с места фрагментации до места назначения. Сборка дейтаграмм в месте назначения может привести к неэффективности: даже если некоторые сети, проходимые после места фрагментации, имеют большое значение МЕП, их будут пересекать только маленькие фрагменты. Во-вторых, если какой-либо фрагмент будет потерян, дейтаграмму нельзя будет восстановить. Принимающая машина запускает таймер сборки при приеме первого фрагмента. Если таймер обнуляется до того, как приняты все фрагменты, принимающая машина удаляет оставшиеся части, не обрабатывая дейтаграмму. Поэтому, вероятность потери дейтаграммы увеличивается при использовании фрагментации, так как потеря одного фрагмента приводит к потере всей дейтаграммы.
Несмотря на эти небольшие недостатки, выполнение сборки в месте назначения хорошо работает. Оно позволяет независимо маршрутизировать фрагменты и не требует от промежуточных шлюзов хранения собираемых фрагментов.
Три поля в заголовке дейтаграммы, ИДЕНТИФИКАЦИЯ, ФЛАГИ и СМЕЩЕНИЕ ФРАГМЕНТА, управляют фрагментацией и сборкой дейтаграмм. Поле ИДЕНТИФИКАЦИЯ содержит уникальное целое число, которое идентифицирует дейтаграмму. Напомним, что когда шлюз фрагментирует дейтаграмму, он копирует большую часть полей в заголовке дейтаграммы в каждый фрагмент. Поле ИДЕНТИФИКАЦИЯ должно копироваться. Его основная цель - позволить назначению узнать, что какой дейтаграмме принадлежат прибывающие фрагменты. Когда появляется фрагмент, назначение использует поле ИДЕНТИФИКАЦИЯ вместе с полем адреса источника для идентификации дейтаграммы. Компьютер, посылающий IP-дейтаграммы, должен генерировать уникальное значение для поля ИДЕНТИФИКАЦИЯ для каждой отдельной дейтаграммы(в теории, повторные передачи дейтаграммы должны содержать то же самое значение в поле ИДЕНТИФИКАЦИЯ, что и в исходной дейтаграмме; на практике, протоколы высокого уровня обычно выполняют повторную передачу как новую дейтаграмму со своей ИДЕНТИФИКАЦИЕЙ). Одна из технологий, используемых в программном обеспечении IP, хранит глобальный счетчик в памяти, инкрементирует его каждый раз, когда создается новая дейтаграмма, и копирует результат в поле ИДЕНТИФИКАЦИЯ дейтаграммы.
Напомним, что каждый фрагмент имеет точно такой же формат, что и полная дейтаграмма. Для фрагмента поле СМЕЩЕНИЕ ФРАГМЕНТА указывает смещение в исходной дейтаграмме данных, передаваемых в фрагменте, измеряемое в 8 октетах(смещения измеряются в восьмерках октетов для сохранения места в заголовке), начиная со смещения ноль. Для сборки дейтаграммы назначение должно получить все фрагменты, начиная с фрагмента со смещением 0 до фрагмента с наибольшим смещением. Фрагменты необязательно прибывают по порядку, и не существует взаимодействия между шлюзом, который фрагментирует дейтаграммы, и назначением, которое пытается собирать их.
Младшие два бита из трехбитового поля ФЛАГИ управляют фрагментацией. Обычно прикладное программное обеспечение, использующее TCP/IP, не заботится о фрагментации, так как и фрагментация, и сборка являются автоматическими процедурами, которые выполняются на низком уровне в операционной системе незаметно для пользователя. Тем не менее, для тестирования межсетевого программного обеспечения или отладки рабочих проблем может оказаться важной проверка размеров дейтаграмм, для которых осуществляется фрагментация. Первый управляющий бит помогает при таком тестировании, указывая возможность фрагментации дейтаграммы. Он называется битом НЕ ФРАГМЕНТИРОВАТЬ, так как установка его в единицу указывает, что дейтаграмму нельзя фрагментировать. Приложение может выбрать запрет фрагментации, когда нужна лишь целая дейтаграмма. Например, рассмотрим последовательность загрузки компьютера, при которой машина начинает выполнять небольшую программу в ПЗУ, которая использует интернет для запроса начального образа операционной системы, а другая машина посылает ей его. Если программное обеспечение разработано так, что ему нужно либо все, либо ничего, дейтаграмма должна иметь установленный бит НЕ ФРАГМЕНТИРОВАТЬ. Всякий раз, когда шлюзу нужно фрагментировать дейтаграмму с установленным битом НЕ ФРАГМЕНТИРОВАТЬ, шлюз удаляет дейтаграмму и посылает обратно источнику сообщение об ошибке.
Младший бит в поле ФЛАГИ указывает, содержит ли фрагмент данные из середины дейтаграммы или из конца. Он называется битом ЕЩЕ ФРАГМЕНТЫ. Чтобы увидеть, почему нужен этот бит, рассмотрим программное обеспечение IP у получателя, пытающееся собрать дейтаграмму. Оно будет получать фрагменты( возможно не по порядку) ,и ему нужно будет знать, когда оно получило все фрагменты дейтаграммы. Когда появляется еще один фрагмент, поле ОБЩАЯ ДЛИНА в заголовке указывает размер фрагмента, а не размер всей дейтаграммы, поэтому назначение не может использовать поле ОБЩАЯ ДЛИНА для того, чтобы определить, собрало ли оно все фрагменты. Бит ЕЩЕ ФРАГМЕНТЫ легко решает проблему: как только назначение получает фрагмент со сброшенным битом ЕЩЕ ФРАГМЕНТЫ, оно знает, что этот фрагмент несет в себе данные из конца исходной дейтаграммы. На основе полей СМЕЩЕНИЕ ФРАГМЕНТА и ОБЩАЯ ДЛИНА оно может вычислить длину исходной дейтаграммы. Проверив СМЕЩЕНИЕ ФРАГМЕНТА и ОБЩАЯ ДЛИНА у всех прибывших фрагментов, получатель может определить, содержат ли фрагменты все данные, требуемые для сборки исходной дейтаграммы.
Поле ВРЕМЯ ЖИЗНИ указывает сколько секунд может оставаться дейтаграмма в межсетевой системе. Эта идея является насколько простой, настолько и важной: всякий раз, когда машина передает дейтаграмму в интернет, она устанавливает максимальное время, которое может существовать дейтаграмма. Шлюзы и ГВМ, обрабатывающие дейтаграмму, должны декрементировать поле ВРЕМЯ ЖИЗНИ по мере того, как идет время, и удалять дейтаграмму из интернета, когда время вышло.
Оценить время точно трудно, так как шлюзы обычно не знают время передачи между физическими сетями. Несколько правил упрощают обработку и делают легкой обработку дейтаграмм без синхронизации часов. Во-первых, каждому шлюзу на пути от источника к назначению требуется декрементировать поле ВРЕМЯ ЖИЗНИ на единицу, когда он обрабатывает заголовок дейтаграммы. Более того, для обработки случаев перегруженных шлюзов, которые приводят к большим паузам при передаче, каждый шлюз хранит локальное время прихода дейтаграммы и декрементирует ВРЕМЯ ЖИЗНИ на число секунд, в течение которого дейтаграмма находилась в шлюзе, ожидая обслуживания.
Всякий раз, когда поле ВРЕМЯ ЖИЗНИ становится нулевым, шлюз удаляет дейтаграмму и посылает сообщение об ошибке обратно источнику. Идея хранить таймер для дейтаграмм является интересной, так как она гарантирует, что дейтаграммы не смогут вечно путешествовать по интернету, даже если таблицы маршрутизации разрушатся и шлюзы будут маршрутизировать дейтаграммы по кольцу.
Поле ПРОТОКОЛ аналогично полю типа в кадре Ethernetа. Значение в поле ПРОТОКОЛ указывает, какой протокол высокого уровня использовался при создании сообщения, передаваемого в области ДАННЫЕ дейтаграммы. По существу, значение в ПРОТОКОЛ специфицирует формат области ДАННЫЕ. Отображение между протоколом высокого уровня и целым числом, используемым в поле ПРОТОКОЛ, должно администрироваться ответственным центром, чтобы гарантировать действие соглашения по всему интернету.
Поле КОНТРОЛЬНАЯ СУММА ЗАГОЛОВКА удостоверяет целостность значений полей заголовка. Контрольная сумма IP формируется путем представления заголовка как последовательности 16-битовых чисел( с сетевым порядком байт), сложения их вместе, используя арифметику с дополнительным представлением отрицательных чисел, и получения отрицания числа. При вычислении контрольной суммы поле КОНТРОЛЬНАЯ СУММА ЗАГОЛОВКА предполагается равным нулю. Стоит заметить, что эта контрольная сумма применима только к числам, находящимся в заголовке IP, а не в данных. Разделение контрольной суммы для заголовка и для данных имеет свои преимущества и недостатки. Так как заголовок обычно занимает меньше октетов, чем данные, наличие отдельной контрольной суммы для него уменьшает время обработки в шлюзах, которым требуется вычислять только контрольную сумму заголовка. Это разделение также позволяет протоколам более высокого уровня выбирать свои собственные схемы расчета контрольной суммы для данных. Главным недостатком является то, что протоколы более высокого уровня вынуждены добавлять свои контрольные суммы или рисковать тем, что они не смогут обнаружить искажения данных.
Поля АДРЕС ОТПРАВИТЕЛЯ IP и АДРЕС ПОЛУЧАТЕЛЯ IP содержат 32-битовые IP-адреса отправителя дейтаграммы и конечного получателя. Хотя дейтаграмма может проходить через большое число промежуточных шлюзов, поля отправителя и получателя никогда не изменяются; они указывают IP-адреса истинного источника и конечного назначения.
Поле, названное ДАННЫЕ на рисунке 7.3, показывает начало области данных в дейтаграмме. Его длина зависит, конечно, от того, что посылается в дейтаграмме.
Поле ОПЦИИ IP, рассматриваемое ниже, имеет переменную длину. Поле, названное ЗАПОЛНЕНИЕ, зависит от выбранных опций. Оно представляет собой биты, содержащие нули, которые могут потребоваться для дополнения заголовка дейтаграммы до длины, кратной 32 битам(напомним, что поле длины заголовка указывает ее в 32-битных словах).
Поле ОПЦИИ IP, следующее за адресом назначения, не требуется в каждой дейтаграмме; опции включаются, в основном, для тестирования или отладки сети. Обработка опций, тем не менее, является составной частью протокола IP, поэтому все стандартные реализации включают ее.
Длина поля ОПЦИИ IP меняется в зависимости от того, какие опции выбраны. Некоторые опции имеют длину один октет; они состоят из кода опции, занимающего один октет. Другие опции имеют переменную длину. Когда в дейтаграмме есть опции, они размещаются друг за другом, без специальных разделителей между ними. Каждая опция состоит из кода опции длиной в один октет, за которым может следовать длина опции(тоже занимает один октет) и группы октетов данных для этой опции. Октет кода опции делится на три поля, как показано на рисунке 7.8.
0 1 2 3 4 5 6 7
----------------------------------------------------------
| КОПИРОВАТЬ | КЛАСС ОПЦИИ | НОМЕР ОПЦИИ |
----------------------------------------------------------
Рисунок 7.8 Разделение октета кода опции на три поля длиной 1, 2 и 5 бит.
Этими полями являются однобитовый флаг КОПИРОВАТЬ, двухбитовый КЛАСС ОПЦИИ и пятибитовый НОМЕР ОПЦИИ. Флаг КОПИРОВАТь управляет тем, как шлюзы рассматривают опции при фрагментации. Когда бит КОПИРОВАТЬ установлен в 1, он указывает, что эта опция должна копироваться во все фрагменты. Когда он установлен в 0, бит КОПИРОВАТь означает, что опцию нужно копировать только в первый фрагмент, а не во все.
Биты КЛАСС ОПЦИИ и НОМЕР ОПЦИИ указывают общий класс опции и номер опции внутри этого класса. Таблица на рисунке 7.9 показывает, как назначены номера классам.
| Класс опции | Значение |
| 0 | Управление дейтаграммой или сетью |
| 1 | Зарезервировано |
| 2 | Отладка и измерения |
| 3 | Зарезервировано |
Рисунок 7.9 Классы опций IP, закодированные в битах КЛАСС ОПЦИИ в октете кода опции.
Таблица на рисунке 7.10 приводит список возможных опций в IP-дейтаграммах и указывает для них значения КЛАССА ОПЦИИ и НОМЕРА ОПЦИИ. Как показывает этот список, большая часть опций используется для целей управления.
| Класс опции | Номер опции | Длина | Описание |
|---|---|---|---|
| 0 | 0 | - | Конец списка опций. Используется, если опция не заканчивается в конце заголовка(смотри также поле дополнения) |
| 0 | 1 | - | Нет операции(используется для выравнивания октетов в списке опций) |
| 0 | 2 | 11 | Секретность(для военных приложений) |
| 0 | 3 | пер | Слабая маршрутизация источника. Используется для маршрутизации дейтаграммы по указанному пути. |
| 0 | 7 | пер | Запись маршрута. Используется для трассировки маршрута |
| 0 | 8 | 4 | Идентификатор потока. Используется для передачи идентификатора потока SATNET (недействительно) |
| 0 | 9 | пер | Сильная маршрутизация источника Используется для маршрутизации дейтаграммы по указанному пути |
| 2 | 4 | пер | Межсетевые временные метки. Используется для записи временных меток по маршруту |
Рисунок 7.10 Восемь возможных опций IP с их числовыми кодами класса и номера. Значение пер в столбце длины означает переменная.
Опции маршрутизации и временных меток являются самыми интересными, так как они обеспечивают способ наблюдения или управления тем, как межсетевые шлюзы маршрутизируют дейтаграммы. Опция запись маршрута позволяет источнику создать пустой список IP-адресов и заставить каждый шлюз, обрабатывающий дейтаграмму, добавлять свой IP-адрес к этому списку. Рисунок 7.11 показывает формат опции записи маршрута.
Как описано выше, поле КОД содержит номер опции и класс опции( 7 для записи маршрута). Поле ДЛИНА указывает общую длину опции в том виде, в котором она представлена в IP-дейтаграмме, включая первые три октета. Поля, начиная с поля, помеченного ПЕРВЫЙ IP-АДРЕС, составляют область, зарезервированную под хранение межсетевых адресов. Поле УКАЗАТЕЛЬ определяет смещение внутри опции первого свободного слота.
0 8 16 24 ------------------------------------------- | КОД(7) | ДЛИНА | УКАЗАТЕЛЬ | ---------------------------------------------------------- | Первый IP-адрес | ---------------------------------------------------------- | Второй IP-адрес | ---------------------------------------------------------- | ....... | ----------------------------------------------------------
Рисунок 7.11 Формат опции записи маршрута в IP-дейтаграмме
Всякий раз, когда машина обрабатывает дейтаграмму, имеющую опцию записи маршрута, она добавляет свой адрес к списку записи маршрута(в опции должно быть выделено достаточно места исходным отправителем для того, чтобы поместились все нужные элементы). При добавлении себя к списку машина сначала сравнивает поля указателя и длины. Если указатель больше, чем длина, то список полон, и машина отправляет дейтаграмму, не добавляя нового элемента. Если список не полон, машина вставляет 4-байтовый IP-адрес в позицию, определенную УКАЗАТЕЛЕМ, и увеличивает значение УКАЗАТЕЛЯ на четыре.
При прибытии дейтаграммы машина-получатель должна выделить и обработать список IP-адресов. Если получатель обрабатывает дейтаграмму обычным образом, он будет игнорировать записанный путь. Отметим, что отправитель должен разрешить наличие опции записи маршрута, а получатель должен быть согласен обработать полученный список; сама по себе машина не получит автоматически информацию о пройденном пути автоматически, если она включит опцию записи маршрута.
Другой идеей, которую создатели сетей нашли интересной, является опция пути источника. Идея, лежащая в основе маршрутизации источника, заключается в том, чтобы отправитель мог определять путь в интернете. Например, для тестирования пропускной способности конкретной физической сети N системные администраторы могут использовать маршрутизацию источника для направления IP-дейтаграмм через сеть N, даже если шлюзы обычно выбирают путь, не включающий ее. Возможность делать такие тесты особенно важна в производственной среде, так как позволяет сетевым администраторам маршрутизировать дейтаграммы пользователей по сетям, про которые известно, что они работают корректно, и параллельно с этим проверять другие сети. Конечно, такая маршрутизация полезна только для тех людей, которые понимают топологию сети; среднему пользователю не нужно знать или использовать эту опцию.
IP поддерживает две формы маршрутизации источника. Одна форма, названная строгой маршрутизацией источника, определяет путь с помощью включения последовательности IP-адресов в эту опцию как показывает рисунок 7.12.
0 8 16 24 ------------------------------------------- | КОД(137) | ДЛИНА | УКАЗАТЕЛЬ | ---------------------------------------------------------- | Первый IP-адрес | ---------------------------------------------------------- | Второй IP-адрес | ---------------------------------------------------------- | ....... | ----------------------------------------------------------
Рисунок 7.12 Опция строгой маршрутизации источника определяет точный путь с помощью списка IP-адресов, которые должна пройти дейтаграмма.
Строгая маршрутизация источника означает, что адреса определяют точный путь, которым должна следовать дейтаграмма, при передаче ее к месту назначения. Путь между двумя последовательными адресами в списке должен состоять из одной физической сети; если шлюз не может выполнить строгую маршрутизацию источника, возникает ошибка. Другая форма, называемая слабой маршрутизацией источника, также включает последовательность IP-адресов. Она определяет, что дейтаграмма должна следовать через эту последовательность IP-адресов, но допускает наличие нескольких переходов через сети между последовательными адресами в списке.
Обе опции маршрутизации источника требуют от шлюзов на всем пути заменять элементы списка адресов своими сетевыми адресами. Поэтому, когда дейтаграмма поступает к получателю, она содержит список всех посещенных адресов, точно такой же, как и список, создаваемый опцией записи маршрута.
Формат опции маршрутизации источника напоминает показанный выше формат опции записи маршрута. Каждый шлюз проверяет поля УКАЗАТЕЛЬ и ДЛИНА, чтобы обнаружить переполнение списка. Если оно произошло, указатель будет больше, чем длина, и шлюз будет маршрутизировать дейтаграмму к ее назначению обычным образом. Если список заполнен еще не до конца, шлюз на основании указателя выделяет IP-адрес, заменяет его на адрес шлюза(шлюз имеет по одному адресу для каждого интерфейса; он записывает адрес, соответствующий сети, по которой он отправляет дейтаграмму) и маршрутизирует дейтаграмму, используя адрес, полученный из списка.
Опция временных меток работает аналогично опции записи маршрута в том отношении, что опция временных меток содержит вначале пустой список, а каждый шлюз на всем протяжении пути от источника к назначению заполняет элемент в этом списке. Каждый элемент в списке состоит из двух 32-битных частей: IP-адреса шлюза, заполнившего этот элемент, и 32-битового целого числа - временной метки. Рисунок 7.13 приводит формат опции временных меток.
0 8 16 24 31 ---------------------------------------------------------- | КОД(68) | ДЛИНА | УКАЗАТЕЛЬ |ПЕРЕП | ФЛАГИ | ---------------------------------------------------------- | Первый IP-адрес | ---------------------------------------------------------- | Первая временная метка | ---------------------------------------------------------- | ....... | ----------------------------------------------------------
Рисунок 7.13 Формат опции временных меток. Биты в поле ФЛАГИ определяют точный формат и правила, применяемые шлюзами при обработке этой опции.
На рисунке поля ДЛИНА и УКАЗАТЕЛЬ используются для указания длины зарезервированного места и местонахождения следующего неиспользованного слота( как в опции записи маршрута). 4-битовое поле ПЕРЕП содержит целое число шлюзов, которые не смогли записать временные метки из-за слишком маленького размера опции. Значение в 4-битовом поле ФЛАГИ определяет точный формат опции и говорит шлюзам, как записывать временные метки. Допускаются следующие значения:
| Значение | Смысл |
|---|---|
| 0 | Только запись временных меток, IP-адреса опускаются |
| 1 | Указывать перед каждой временной меткой IP-адрес (формат, показанный на рисунке 7.13) |
| 3 | IP-адреса указываются отправителем, шлюз только записывает временную метку, если следующий IP-адрес в списке соответствует IP-адресу шлюза. |
Рисунок 7.14 Интерпретация значений поля ФЛАГИ в опции временные метки.
Временные метки определяют время и дату, когда шлюз обрабатывал дейтаграмму, и выражаются в миллисекундах после полуночи по Гринвичу. Если стандартное представление времени невозможно, шлюз может использовать любое представление локального времени при условии, что он устанавливает старший бит в поле временной метки. Конечно, временные метки, записываемые независимыми компьютерами, не всегда согласованы, даже если представлены во времени по Гринвичу; каждая машина сообщает время согласно своим локальным часам, а часы могут идти по-разному. Поэтому, временные метки всегда рассматриваются как приблизительные оценки, независимо от их представления.
Может показаться странным, что опция временных меток включает механизм, заставляющий шлюзы записывать их IP-адреса вместе с временными метками, так как опция записи маршрута обеспечивает эту возможность. Тем не менее, запись IP-адресов вместе с временными метками позволяет избежать неоднозначности. Одновременная запись маршрута с временными метками также полезна потому, что она позволяет приемнику узнать точно, какой путь прошла дейтаграмма.
Идея, лежащая в основе применения бита КОПИРОВАТЬ в поле опции КОД, теперь понятна. При фрагментации дейтаграммы шлюз повторяет некоторые IP-опции во всех фрагментах, в то время как другие помещаются только в один фрагмент. Например, рассмотрим опцию, используемую для записи маршрута дейтаграммы. Мы говорили, что каждый фрагмент будет обрабатываться как независимая дейтаграмма, поэтому не гарантируется, что все фрагменты будут следовать по одному и тому же пути к месту назначения. Если все фрагменты содержат опцию записи маршрута, назначение может получить свой список шлюзов от каждого фрагмента. Оно не сможет создать одного списка для собранной дейтаграммы. Поэтому, стандарт IP определяет, что опция записи маршрута должна копироваться только в один из фрагментов.
Не все опции IP должны находиться в одном фрагменте. Рассмотрим, например, опцию маршрутизации источника, которая определяет, как должна передаваться дейтаграмма через интернет. Информация о маршрутизации источника должна находиться в заголовках всех фрагментов, иначе фрагменты не будут следовать указанным путем. Поэтому, поле кода для маршрутизации источника указывает, что эта опция должна копироваться во все фрагменты.
Фундаментальным средством, обеспечиваемым программным обеспечением TCP/IP , является ненадежная система доставки пакетов без установления соединения. Межсетевой протокол(IP) формально определяет формат межсетевых пакетов, называемых дейтаграммами, и неформально воплощает в себе идеи доставки без установления соединения. Эта глава была сосредоточена главным образом на форматах дейтаграмм; следующие главы рассмотрят маршрутизацию IP и обработку ошибок.
Аналогично физическому кадру, дейтаграмма IP делится на заголовок и область данных. Помимо другой информации, заголовок дейтаграммы содержит IP-адреса источника и назначения, управление фрагментацией, приоритет и контрольную сумму, используемую для обнаружения ошибок передачи. Кроме полей фиксированной длины, каждый заголовок дейтаграммы может содержать поле опций. Поле опций имеет переменную длину, зависящую от числа и типов используемых опций, а также от размеров области данных, выделенной для каждой опции. Предназначенные для облегчения наблюдения и управления интернетом, опции позволяют указать или записать информацию о маршруте, или собрать временные метки о том, как дейтаграмма передается по интернету.
7.1 Что является самым большим достоинством контрольной суммы IP, учитывающей только заголовок, но не данные ? А недостатком ?
7.2 Нужно ли использовать контрольную сумму IP при посылке пакетов по Ethernetу ?
7.3 Каково значение МЕП для MILNET ? NSFNET ? X25NET ?Hyperchannel ?
7.4 Как вы думаете , больший или меньший размер МЕП будут иметь высокоскоростные локальные сети по сравнению с более медленными глобальными сетями ?
7.5 Докажите, что фрагменты должны иметь маленькие, нестандартные заголовки.
7.6 Установите, когда в последний раз менялась версия протокола IP. Имеет ли смысл на самом деле иметь номер версии протокола ?
7.7 Можете ли вы догадаться, почему для IP была выбрана контрольная сумма с дополнением до единицы вместо циклической проверки ?
7.8 Каковы преимущества сборки в месте конечного назначения вместо сборки после того, как дейтаграмма пересекла одну сеть ?
7.9 Какой минимальный МЕП требуется для посылки дейтаграммы IP, содержащей по крайней мере один октет данных ?
7.10 Предположим, вы решили реализовать обработку IP-дейтаграммы с помощью оборудования. Существуют ли другие расположения полей заголовка, делающие ваше оборудование более эффективным ? А более простым ?
7.11 Если вы имеете доступ к реализации IP, изучите ее и проверьте доступные вам реализации IP на предмет удаления ими дейтаграмм с устаревшим номером версии.
Назад | Содержание | Вперед
Мы уже видели, что все межсетевые средства строятся на основе ненадежной системы доставки пакетов без установления соединения, и что базовой единицей передачи в интернете TCP/IP является IP-дейтаграмма. Эта глава добавляет к описанию средства без установления соединения описание того, как шлюзы маршрутизируют IP-дейтаграммы и доставляют их к месту назначения. Можно сказать, что формат дейтаграммы из главы 7 характеризует статические аспекты Межсетевого Протокола. Описание маршрутизации в этой главе характеризует его операционные аспекты. Следующая глава завершит рассмотрение нами IP описанием того, как обрабатываются ошибки; последующие главы покажут, как другие протоколы используют его для реализации средств более высокого уровня.
В системе с коммутацией пакетов маршрутизация обозначает процесс выбора пути, по которому будут посылаться пакеты, а маршрутизатором называется компьютер, производящий этот выбор. Маршрутизация происходит на нескольких уровнях. Например, в глобальной сети, имеющей по несколько физических соединений между коммутаторами пакетов, сеть сама отвечает за маршрутизацию пакетов с того времени, как они попали в нее, и до тех пор, пока они не покинут ее. Такая внутренняя маршрутизация происходит полностью внутри этой глобальной сети. Машины за ее пределами не могут участвовать в принятии решений; для них эта сеть представляется единым целым, которое доставляет пакеты.
Напомним, что целью TCP/IP является обеспечить виртуальную сеть, предоставляющую средство доставки IP-дейтаграмм без установления соединения. Поэтому, мы сосредоточим на внимание на межсетевой маршрутизации или IP-маршрутизации. Как и маршрутизация внутри физической сети, IP-маршрутизация выбирает путь, по которому следует послать дейтаграмму. Алгоритм IP-маршрутизации должен определить, как послать дейтаграмму через несколько физических сетей.
Маршрутизация в интернете может быть сложной, особенно между машинами с несколькими физическими сетевыми соединениями. В идеале программное обеспечение маршрутизации должно учитывать такие вещи, как загрузка сети, длина дейтаграммы, или тип сервиса, указанный в заголовке дейтаграммы, при выборе наилучшего пути. Тем не менее, большинство программного обеспечения межсетевой маршрутизации гораздо менее сложное, и выбирает пути на основе фиксированных предположений о самых коротких путях. Чтобы полностью понять IP-маршрутизацию, мы должны вернуться назад и вспомнить архитектуру интернета TCP/IP. Во-первых, напомним, что интернет состоит из группы физических сетей, соединенных компьютерами, называемыми шлюзами. Каждый шлюз имеет прямое соединение с двумя или более сетями. В отличие от шлюза, ГВМ обычно соединен напрямую только с одной физической сетью. Тем не менее, мы знаем, что возможно существование многоадресных ГВМ, которые соединены напрямую с несколькими сетями.
Как ГВМ, так и шлюзы участвуют в IP-маршрутизации. Когда прикладная программа на ГВМ пытается организовать взаимодействие, протоколы TCP/IP в конечном счете генерируют одну или несколько IP-дейтаграмм. ГВМ должен принять решение о маршруте, когда он выбирает, куда послать дейтаграмму. Как показывает рисунок 8.1, ГВМ должны принять решение, даже если они имеют только одно соединение с сетью.
^ к одним ^ к другим
| ГВМ | ГВМ
----- -----
| Ш1| | Ш2|
----- -----
| |
--------------------------------------------------------
|
-----
|ГВМ|
-----
Рисунок 8.1 Пример одноадресного ГВМ, который должен маршрутизировать дейтаграммы. Он должен выбрать, послать ли дейтаграмму шлюзу Ш1 или шлюзу Ш2, так как нет одного шлюза, обеспечивающего наилучший путь ко всем назначениям.
Конечно, шлюзы должны принимать решения об IP-маршрутизации (это их основная задача и причина того, что их назвали маршрутизаторами). А как же многоадресные ГВМ ? Любой компьютер с несколькими сетевыми соединениями может выступать в роли шлюза, и как мы увидим позже, многоадресные ГВМ с сетевым программным обеспечением TCP/IP имеют все необходимое для маршрутизации. Более того, локальные сети, в которых нет возможности выделить отдельные компьютеры под шлюз, часто используют компьютеры общего назначения с разделением времени в роли как ГВМ, так и шлюза ( эта практика особенно распространена в университетах). Тем не менее, стандарты TCP/IP делают различие между этими функциями в ГВМ и шлюзе, а в сетях, пытающихся смешивать функции ГВМ и шлюза в одной машине, иногда обнаруживается, что многоадресные шлюзы участвуют в неожиданных взаимодействиях. А пока, мы будем различать ГВМ и шлюзы, и предполагать, что ГВМ не реализуют функцию шлюза по передаче пакетов из одной сети в другую.
Говоря нестрого, мы можем выделить две формы маршрутизации: прямую маршрутизацию и косвенную маршрутизацию. Прямая маршрутизация, передача дейтаграммы напрямую из одной машины в другую, является основой, на которой строится все остальное межсетевое взаимодействие. Две машины могут участвовать в прямой маршрутизации только в том случае, когда они обе соединены напрямую с одной физической системой передачи(например, Ethernetом). Косвенная маршрутизация осуществляется, когда назначение не находится в той же сети, что и источник, и заставляет отправителя передавать дейтаграмму шлюзу для доставки.
Мы знаем, что одна машина в данной физической сети может послать физический кадр напрямую другой машине в этой же сети. Для передачи IP-дейтаграмм отправитель инкапсулирует дейтаграмму в физический кадр, отображает IP-адрес назначения в физический адрес, и использует сетевое оборудование для его доставки. Глава 5 представила два возможных механизма при разрешении адресов, включая использование протокола ARP для динамического связывания пар адресов в Ethernet-подобных сетях. Глава 7 рассмотрела инкапсуляцию дейтаграмм. Поэтому мы знаем теперь все необходимое для понимания прямой доставки. Обобщим:
Передача IP-дейтаграмм между двумя машинами в одной физической сети не использует шлюзы. Отправитель инкапсулирует дейтаграмму в физический кадр, связывает IP-адрес назначения с физическим аппаратным адресом и посылает полученный кадр прямо назначению.
Откуда отправитель узнает, что получатель находится в сети, к которой он присоединен ? Ответ прост. Мы знаем, что IP-адреса делятся на номер сети и номер ГВМ в сети. Чтобы определить, находится ли назначение в одной из сетей, к которым он присоединен, отправитель выделяет сетевую часть IP-адреса назначения и сравнивает ее с сетевой частью своего IP-адреса(ов). Совпадение означает, что дейтаграмму можно послать напрямую. Здесь мы видим одно из преимуществ схемы адресации Интернета, а именно:
Так как межсетевые адреса всех машин в одной сети включают общий идентификатор сети, и так как выделение этого идентификатора может быть сделано несколькими машинными командами, проверка того, что машина может быть достигнута напрямую, является крайне эффективной.
С точки зрения интернета легче всего представить прямую маршрутизацию как доставку дейтаграммы. Доставка - это конечный шаг при передаче дейтаграммы, даже если дейтаграмма пересекла много сетей и промежуточных шлюзов. Последний на пути между источником дейтаграммы и ее назначением шлюз будет напрямую соединен с той же самой физической сетью, что и назначение. Поэтому, последний шлюз будет доставлять дейтаграмму, используя прямую маршрутизацию. Можно представлять прямую маршрутизацию между источником и назначением как специальный случай общей маршрутизации - для прямого пути дейтаграмме не надо проходить через шлюзы.
Косвенная маршрутизация более трудна, чем прямая , так как отправитель должен идентифицировать шлюз, которому можно послать дейтаграмму. Шлюз должен затем отправить дейтаграмму к сети назначения.
Для визуализации того, как работает косвенная маршрутизация, представим себе большой интернет со множеством сетей, соединенных шлюзами, но имеющий лишь две ГВМ на самых дальних концах. Когда одна ГВМ хочет что-то послать другой, она инкапсулирует дейтаграмму и посылает ее к ближайшему шлюзу. Мы знаем, что она может достичь шлюза, так как все физические сети связаны друг с другом, поэтому для каждой сети должен существовать шлюз, присоединенный к ней. Поэтому, ГВМ, отправляющий дейтаграмму, может достичь шлюза, используя одну физическую сеть. Как только кадр достигает шлюза, программное обеспечение выделяет инкапсулированную в нем дейтаграмму, процедуры IP-маршрутизации выбирают следующий шлюз на пути к назначению. Дейтаграмма снова помещается в кадр и посылается по следующей физической сети ко второму шлюзу, и так далее, до тех пор, пока она не сможет быть доставлена напрямую. Эти идеи можно обобщить:
Шлюзы в интернете TCP/IP образуют взаимодействующую и связанную структуру. Дейтаграммы передаются от шлюза к шлюзу до тех пор, пока они не достигнут шлюза, который может доставить дейтаграмму напрямую.
Откуда шлюз может узнать, куда посылать каждую дейтаграмму ? Откуда шлюз знает, какой шлюз надо использовать для данного назначения ? Эти два вопроса связаны между собой, так как ответ на оба вопроса использует IP-маршрутизацию. Мы ответим на них последовательно, рассмотрев основные алгоритмы маршрутизации на основе таблиц в этой главе и закончим рассмотрением того, как шлюзы получают информацию о новых путях несколько позже.
Обычный алгоритм IP-маршрутизации работает с таблицей маршрутизации Интернета (иногда называемой таблицей IP-маршрутизации), имеющейся на каждой машине и хранящей информацию о возможных назначениях и том, как их достичь. Так как и ГВМ, и шлюзы маршрутизируют дейтаграммы, все они имеют таблицы IP-маршрутизации. Всякий раз, когда программному обеспечению IP-маршрутизации на ГВМ или шлюзе надо передать дейтаграмму, оно обращается к таблице маршрутизации, чтобы решить, куда послать дейтаграмму.
Какую информацию следует держать в таблицах маршрутизации ? Если бы каждая таблица маршрутизации содержала информацию о всех возможных адресах назначения, было бы невозможно поддерживать корректное состояние таблицы. Более того, так как число возможных назначений велико, машинам не хватало бы памяти для хранения всей этой информации.
Концептуально, нам хотелось бы использовать принцип отсутствия информации и предоставить машинам возможность принимать решение о маршрутизации при минимальной информации. Например, нам было бы желательно не хранить информацию о конкретных ГВМ в локальной сети, в которой они расположены, а поместить в таблицу информацию об удаленных машинах, для которых нужно маршрутизировать пакеты. К счастью схема адресации IP помогает достичь такой цели. Напомним, что IP-адреса назначаются так, что у всех машин, присоединенных к конкретной физической сети, имеется одинаковое начало(номер сети). Мы уже видели, что такое назначение делает эффективной проверку на прямую доставку. Оно также означает, что таблицам маршрутизации нужно содержать только сетевые префиксы, а не полные IP-адреса.
Использование номера сети в адресе назначения вместо полного адреса ГВМ делает маршрутизацию эффективно, а таблицы маршрутизации маленькими. Более того, оно помогает скрыть информацию о конкретных ГВМ в локальной среде, к которой эти ГВМ присоединены. Обычно таблица содержит пары (N,G), где N - это IP-адрес сети назначения, а G - IP-адрес следующего шлюза на пути к сети N. Поэтому, таблица маршрутизации в шлюзе G определяет только один шаг на пути от G к сети назначения - шлюз не знает полный путь к назначению.
Важно понимать, что таблица маршрутизации всегда указывает на шлюзы, которые находятся на расстоянии одной физической сети. То есть, все шлюзы, приведенные в таблице маршрутизации машины М, должны находиться в сетях, к которым М присоединена напрямую. На практике, мы по возможности придерживаемся принципа скрытия информации от ГВМ. Мы настаиваем, что хотя ГВМ имеют таблицы IP-маршрутизации, они должны хранить минимум информации в своих таблицах. Идея заключается в том, чтобы заставить ГВМ полагаться на шлюзы для большей части маршрутизации.
Рисунок 8.2 показывает конкретный пример, который помогает понять таблицы маршрутизации. Интернет в этом примере состоит из четырех сетей, соединенных тремя шлюзами. На рисунке показана таблица маршрутизации, используемая шлюзом G. Так как G присоединен напрямую к сетям 20.0.0.0 и 30.0.0.0, он может достичь любой ГВМ в этих сетях напрямую(возможно используя ARP для нахождения физического адреса). Получив дейтаграмму, предназначенную ГВМ в сети 40.0.0.0, G маршрутизирует ее в адрес 30.0.0.7, адрес шлюза H. H затем доставит дейтаграмму напрямую. G может достичь адреса 30.0.0.7, так как и G, и H присоединены к сети 30.0.0.0.
20.0.0.5 30.0.0.6 40.0.0.7
| | |
---------- V---------- V---------- V----------
| Сеть | --- | Сеть | --- | Сеть | --- | Сеть |
|10.0.0.0|-|F|-|20.0.0.0|-|G|-|30.0.0.0|-|H|-|40.0.0.0|
| | --- | | --- | | --- | |
----------^ ----------^ ----------^ ----------
| | |
10.0.0.5 20.0.0.6 30.0.0.7
(а)
Чтобы достичь Маршрутизировать
ГВМ в сети к адресу
20.0.0.0 прямая доставка
30.0.0.0 прямая доставка
10.0.0.0 20.0.0.5
40.0.0.0 30.0.0.7
(б)
Рисунок 8.2 (а) Демонстрационный интернет с 4 сетями и 3 шлюзами, и (б) таблица маршрутизации для шлюза G
Как показывает рисунок 8.2, размер таблицы маршрутизации зависит от числа сетей в интернете; он увеличивается только при добавлении новых сетей. Тем не менее, размер таблицы и ее содержимое не зависят от числа отдельных ГВМ, присоединенных к сетям. Мы можем сформулировать следующий принцип:
Чтобы работать при минимальной информации, чтобы сделать таблицы маршрутизации маленькими и чтобы эффективно принимать решения о маршрутизации, программное обеспечение IP-маршрутизации хранит информацию только об адресах сетей назначений, а не о конкретных адресах ГВМ.
Выбор маршрутов на основе идентификатора сети назначения имеет несколько следствий. Во-первых, в большинстве реализаций это значит, что весь траффик к конкретной сети будет использовать один и тот же путь. В результате, даже если существует несколько путей, они не смогут использоваться параллельно. Также все типы траффика будут проходить по одному и тому же пути, независимо от задержки при передаче и пропускной способности физических сетей. Во-вторых, так как только последний шлюз на пути пытается взаимодействовать с ГВМ назначения, только он сможет определить, работает ли ГВМ. Поэтому, нам нужно определить способ, с помощью которого этот шлюз мог бы послать сообщение источнику о проблемах при доставке. В-третьих, так как каждый шлюз маршрутизирует траффик независимо от других, дейтаграммы, следующие от ГВМ А к ГВМ В, могут использовать путь, отличный от того, который проходят дейтаграммы от ГВМ В к ГВМ А. Нам нужно быть уверенными в том, что шлюзы взаимодействуют, для того чтобы гарантировать и прямое, и обратное взаимодействие.
Другой технологией, используемой для работы при минимуме информации и маленьких таблицах маршрутизации, является объединение нескольких элементов таблицы в случай по умолчанию. Идея состоит в том, что сначала программное обеспечение IP-маршрутизации ищет сеть назначения в таблице маршрутизации. Если для нее нет маршрута в таблице, процедуры маршрутизации посылают дейтаграмму к шлюзу по умолчанию.
Маршрутизация по умолчанию особенно полезна, когда сеть имеет несколько ГВМ и только одно соединение с интернетом. Например, маршруты по умолчанию хорошо работают для машин, которые присоединены только к одной физической сети и используют только один шлюз для достижения остальной части интернета. Все решение о выборе маршрута в таком случае состоит из двух проверок: одной - на нахождение в локальной сети, и одной - случая по умолчанию, указывающего на единственный возможный шлюз. Даже, если место(site) имеет в своем составе несколько локальных сетей, маршрутизация проста, так как состоит из нескольких проверок на локальные сети и умолчания для всех остальных мест назначения.
Хотя мы сказали, что вся маршрутизация основывается на сетях, а не на отдельных ГВМ, большая часть программного обеспечения IP-маршрутизации позволяет указывать как особый случай маршруты для отдельных ГВМ. Наличие маршрутов для ГВМ предоставляет администратору локальной сети большие возможности по слежению за использованием сети и может быть использовано для наблюдения за доступом к сети и обеспечения секретности. При отладке сетевых соединений или таблиц маршрутизации способность указывать специальный путь для отдельной машины оказывается особенно полезной.
Принимая во внимание все вышесказанное, получаем следующий вид алгоритма IP-маршрутизации:
Маршрутизир_дейтаграмму_IP(дейтаграмма,таблица_маршрутизации)
Рисунок 8.3 Алгоритм IP-маршрутизации. Имея в качестве исходных данных IP-дейтаграмму и таблицу маршрутизации, этот алгоритм выбирает следующую машину, на которую будет послана дейтаграмма. Таблицы маршрутизации всегда указывают в качестве следующей машины ту, что находится в сети, достижимой напрямую.
Важно понимать, что IP-маршрутизация не изменяет исходную дейтаграмму. В частности, поля отправителя и получателя дейтаграммы остаются неизменными; они всегда указывают IP-адрес первоначального отправителя и IP-адрес конечного получателя. Когда IP исполняет алгоритм маршрутизации, он вычисляет новый адрес, IP-адрес очередной машины, на которую надо послать дейтаграмму. Этот новый адрес по всей видимости будет адресом шлюза. Тем не менее, если дейтаграмма может быть доставлена напрямую, этот новый адрес будет совпадать с адресом конечного назначения.
IP-адрес, вычисленный алгоритмом IP-маршрутизации, известен как адрес следующей попытки(hop), так как он определяет, куда послать дейтаграмму в следующий раз(хотя это место может и не быть местом конечного назначения). Где же IP сохраняет адрес следующей попытки ? Не в дейтаграмме; там для него нет места. По сути дела IP не сохраняет адрес следующей попытки вообще. После выполнения алгоритма маршрутизации IP передает дейтаграмму и адрес следующей попытки программному обеспечению сетевого интерфейса той сети, по которой должна быть передана дейтаграмма. Программное обеспечение сетевого интерфейса связывает адрес следующей попытки с физическим адресом, формирует кадр, используя этот физический адрес, помещает дейтаграмму в поле данных кадра и посылает результат. После использования адреса следующей попытки для нахождения физического адреса программное обеспечение сетевого интерфейса удаляет адрес следующей попытки.
Может показаться странным, что таблицы маршрутизации хранят IP-адрес следующей попытки для каждой сети назначения, в то время как эти адреса должны транслироваться в соответствующие физические адреса перед посылкой дейтаграммы. Если мы представим ГВМ, посылающий последовательность дейтаграмм одному и тому же назначению, такое использование IP-адресов будет явно неэффективным. IP послушно выделяет адрес назначения в каждой дейтаграмме и использует таблицу маршрутизации для определения адреса следующей попытки. Затем он передает дейтаграмму и адрес следующей попытки сетевому интерфейсу, который находит физический адрес. Если бы таблица маршрутизации использовала физические адрес, определение соответствия между IP-адресом следующей попытки и физическим адресом могло бы выполняться лишь один раз. Почему же программное обеспечение IP избегает пользоваться физическими адресами при хранении и вычислении маршрутов ? Как показывает рисунок 8.4, существуют две важные причины.
ПРОВЕРКА ИЛИ МАРШРУТИЗИРУЕМАЯ
ОБНОВЛЕНИЕ МАРШРУТОВ | ДЕЙТАГРАММА
V
---------------- ----------------
| таблица | / алгоритм \
| маршрутизации|--------->| маршрутизации |
| | \ в IP /
---------------- \---------------/
|
используются IP-адреса |
-------------------------------------------------------------
используются физические адреса | отправляемая дейтаграмма и
V адрес следующей попытки
Рисунок 8.4 Программное обеспечение IP и таблица маршрутизации, которую оно использует, находятся выше границы адресов. Использование только IP-адресов делает маршруты удобными для проверки и изменения и скрывает детали физических адресов на самом нижнем из возможных уровней.
Во-первых, таблица маршрутизации обеспечивает особенно ясный интерфейс между программным обеспечением IP, маршрутизирующим дейтаграммы, и высокоуровневым программным обеспечением, управляющим путями. Для отладки ошибок маршрутизации сетевым администраторам часто нужно проверять таблицы маршрутизации. Использование только IP-адресов в таблице маршрутизации приводит к тому, что администраторам становится легко понимать таблицу и обнаруживать корректность изменения таблицы программным обеспечением. Во-вторых, одной из главных целей разработки Межсетевого Протокола являлось создание абстракции, скрывающей детали нижележащих сетей.
Рисунок 8.4 показывает границу адресов, важную концептуальную границу между низкоуровневым программным обеспечением, понимающим физические адреса, и межсетевым программным обеспечением, использующим только высокоуровневые адреса. Выше этой границы все программное обеспечение для взаимодействия может быть написано с использованием только межсетевых адресов; знание физических адресов предоставляется нескольким небольшим низкоуровневым процедурам. Мы увидим, что выделение этой границы также помогает сделать реализацию остальных протоколов TCP/IP легкой для понимания, проверки и модификации.
Итак, мы рассмотрели IP-маршрутизацию, описав, как принимаются решения относительно отправляемых пакетов. Тем не менее, ясно, что программное обеспечение IP должно также обрабатывать приходящие дейтаграммы.
Когда IP-дейтаграмма прибывает на ГВМ, программное обеспечение сетевого интерфейса доставляет ее программному обеспечению IP для обработки. Если адрес назначения дейтаграммы соответствует IP-адресу ГВМ, программное обеспечение IP на ГВМ принимает дейтаграмму и передает ее программе протокола более высокого уровня для дальнейшей обработки. Если же IP-адрес назначения не соответствует ему, ГВМ требуется уничтожить дейтаграмму(то есть ГВМ не позволяется пытаться маршрутизировать дейтаграммы, по ошибке пришедшие не на ту машину).
В отличие от ГВМ, шлюзы выполняют маршрутизацию. Когда
IP-дейтаграмма прибывает на шлюз, она доставляется программному обеспечению IP. И снова можно выделить два варианта: дейтаграмма может быть доставлена к ее конечному назначению, или ее нужно отправить путешествовать дальше. Как и на ГВМ, если IP-адрес назначения дейтаграммы соответствует собственному IP-адресу шлюза, программное обеспечение IP передает дейтаграмму программному обеспечению более высокого уровня для обработки(обычно, единственными дейтаграммами, предназначающимися шлюзу, являются те, что используются для проверки достижимости и те, что несут команды администрирования шлюзом). Если дейтаграмма еще не достигла своего конечного назначения, IP маршрутизирует ее, используя стандартный алгоритм и информацию из локальной таблицы маршрутизации.
Определение того, достигла ли IP-дейтаграмма своего конечного назначения или нет, не так тривиально, как это может показаться. Напомним, что даже ГВМ может иметь несколько физических соединений, и каждое из них имеет свой IP-адрес. Когда прибывает IP-дейтаграмма, машина должна сравнить межсетевой адрес назначения с IP-адресом каждого из своих сетевых соединений. Если для какого-либо из них соответствие найдено, шлюз сохраняет дейтаграмму и обрабатывает ее. Машина также должна принимать широковещательные дейтаграммы из физических сетей, если их IP-адрес назначения является IP-адресом ограниченного широковещания или IP-адресом направленного широковещания для этой сети. Как мы увидим в главах 16 и 17, подсети и многоадресные адреса делают распознавание адресов достаточно сложным. В любом случае, если адрес не соответствует ни одному из адресов этой машины, IP декрементирует поле времени жизни в заголовке дейтаграммы и удаляет дейтаграмму, если этот счетчик достиг нуля, или вычисляет новую контрольную сумму и маршрутизирует дейтаграмму, если счетчик больше нуля.
Должна ли каждая машина маршрутизировать дейтаграммы, которые она получает ? Ясно, что шлюзы должны маршрутизировать приходящие дейтаграммы, так как это их основная задача. Мы также говорили, что некоторые многоадресные ГВМ ведут себя как шлюзы, даже если они на самом деле компьютеры общего назначения. Хотя использование ГВМ в качестве шлюза обычно неразумно, если кто-то все же сделал это, то ГВМ должен быть сконфигурирован так, чтобы маршрутизировать дейтаграммы так же, как это делает шлюз. А как же остальные ГВМ, не предназначенные для использования в качестве шлюзов ? Ответ будет следующий: ГВМ, не используемые в качестве шлюзов, не должны маршрутизировать приходящие на них дейтаграммы; они должны уничтожать их.
Существует четыре причины, почему ГВМ, не предназначенный для функционирования в качестве шлюза, должен воздерживаться от выполнения любых функций шлюза. Во-первых, когда такой ГВМ получает дейтаграмму, предназначавшуюся другой машине, либо есть ошибка в межсетевом адресе, либо произошла ошибка при маршрутизации или доставке. Эта ошибка может быть не обнаружена, если ГВМ совершит корректирующее действие с помощью маршрутизации дейтаграммы. Во-вторых, маршрутизация может привести к возникновению лишнего межсетевого траффика(и может отвлечь ЦП от выполнения по-настоящему нужных задач). В-третьих, простые ошибки могут вызвать хаос. Предположим, что каждый ГВМ маршрутизирует траффик и представим себе, что случится, если одна из машин по ошибке широковещательно передаст дейтаграмму, предназначенную на самом деле лишь одному ГВМ, Н. Каждый ГВМ в сети получит копию дейтаграммы в результате широковещания, и каждая машина направит свою копию к Н, которая в результате будет бомбардирована множеством копий. В-четвертых, как покажут последующие главы, шлюзы не только маршрутизируют траффик. В следующей главе будет показано, что шлюзы используют специальный протокол для сообщений об ошибках, в то время как ГВМ не используют его(опять же, чтобы избежать бомардирования источника множеством сообщений об ошибках). Шлюзы также распространяют информацию о маршрутах для того, чтобы их таблицы были согласованными. Если ГВМ маршрутизируют дейтаграмму, не реализуя при этом всех функций шлюза, могут возникать неожиданные аномалии.
Мы рассмотрели, как IP маршрутизирует дейтаграммы, основываясь на содержимом таблиц маршрутизации, не сказав при этом, как системы инициализируют свои таблицы маршрутизации или как они обновляют их при изменениях в сети. Следующие главы ответят на эти вопросы и рассмотрят протоколы, позволяющие шлюзам делать маршруты согласованными. А пока, важно понимать только, что IP делает все решения маршрутизации на основе таблиц, поэтому изменение этих таблиц изменит пути, по которым будут следовать дейтаграммы.
IP-маршрутизация представляет собой принятие решения от том, куда послать дейтаграмму на основе ее IP-адреса назначения. Маршрут является непосредственным, если машина назначения находится в сети, которой присоединена посылающая машина; мы будем считать это последним шагом доставке при передаче дейтаграммы. Маршрут является косвенным, если дейтаграмму надо послать шлюзу для доставки. Общий принцип заключается в том, что ГВМ посылают косвенно маршрутизируемые дейтаграммы ближайшему шлюзу; дейтаграммы путешествуют по интернету от шлюза к шлюзу до тех пор, пока они не смогут быть напрямую доставлены по физической сети.
IP-маршрутизация генерирует IP-адрес следующей машины(т.е. адрес следующей попытки), к которой следует послать дейтаграмму; IP передает дейтаграмму и адрес следующей попытки программному обеспечению сетевого интерфейса. Передача дейтаграммы от одной машины к другой всегда включает инкапсуляцию дейтаграммы в физический кадр, отображение межсетевого адреса следующей попытки в физический адрес и посылку кадра, используя аппаратное обеспечение.
Межсетевой алгоритм маршрутизации управляется таблицей и использует только IP-адреса. Он основывает решения маршрутизации на адресе сети назначения, а не на адресе ГВМ назначения, что делает таблицы маршрутизации маленькими. Маршруты по умолчанию также помогают таблицам оставаться маленькими, особенно для тех ГВМ, которые имеют доступ только к одному шлюзу.
Маршрутизация - это важный раздел. Frank и Chou[1971], а также Schwartz и Stern[1980] рассматривают маршрутизацию в целом; Postel[1980] рассматривает межсетевую маршрутизацию. Braden и Postel[RFC 1009] дают краткое изложение того, как шлюзы Интернета обрабатывают IP-дейтаграммы. Narten[1989] содержит обзор маршрутизации в Интернете. Fultz и Kleinrock[1971] анализируют схемы адаптивной маршрутизации; и McQuillan, Richer и Rosen[1980] описывают алгоритм адаптивной маршрутизации в ARPANET.
Часто рассматривалась идея использования политических соглашений для формулирования правил о маршрутизации. Leiner[RFC 1124] рассматривает соглашения для взаимосвязанных сетей.
Braun[RFC 1104] обсуждает модели политики маршрутизации для интернетов, Rekhter[RFC 1092] затрагивает вопрос о политике маршрутизации во второй магистральной сети NSFNET, и Clark[RFC 1102] описывает использование политики маршрутизации для IP.
8.1 Опишите таблицы маршрутизации для всех шлюзов из рисунка
8.1. В чем заключается основная выгода использования маршрутов по
умолчанию ?
8.2 Изучите алгоритм маршрутизации, используемы в UNIX BSD
4.3. Учитывает ли он все случаи, описанные здесь ? Рассматривает ли он какие-либо не описанные случаи ?
8.3 Что делает шлюз с полем ВРЕМЯ ЖИЗНИ из заголовка IP ?
8.4 Рассмотрим машину с двумя физическими сетевыми соединениями и двумя IP-адресами I1 и I2. Может ли эта машина получить дейтаграмму, назначенную I2 из сети с адресом I1 ? Объясните.
8.5 Рассмотрим две ГВМ, А и В, которые присоединены к одной физической сети, N. Может ли А при использовании нашего алгоритма маршрутизации получить дейтаграмму, предназначенную В ? Объясните.
8.6 Модифицируйте алгоритм маршрутизации для учета опций маршрутизации источника IP, описанных в главе 7.
8.7 Шлюз IP должен выполнят вычисления, для которых требуется время, пропорциональное длине заголовка дейтаграммы, каждый раз, когда он обрабатывает дейтаграмму. Объясните.
8.8 Сетевой администратор доказывает, что для более легкой отладки и его сети и наблюдения за ней ему нужно переписать алгоритм маршрутизации таким образом, чтобы он проверял маршруты для отдельных ГВМ до проверки на прямую доставку. Можете ли вы представить, как он собирается использовать новый алгоритм для слежения за работой сети ?
8.9 Возможно ли адресовать дейтаграмму на IP-адрес шлюза ? Имеет ли смысл так делать ?
8.10 Рассмотрим модифицированный алгоритм маршрутизации, который проверяет маршруты для отдельных ГВМ на прямую доставку. При каких условиях этот алгоритм будет выгоден?
8.11 Поиграем в детектив: после наблюдения за траффиком IP в локальной сети в течение 10 минут в вечернее время кто-то заметил, что все кадры, предназначенные машине А, содержат IP-дейтаграммы, которые имеют адрес назначения, совпадающий с IP-адресом А, в то время как все кадры, предназначенные машине В, несут IP-дейтаграммы с назначением, отличным от IP-адреса В. Объясните.
8.12 Как вы можете изменить формат дейтаграммы IP для поддержки высокоскоростной коммутации пакетов в шлюзах ? Указание: шлюз должен перевычислять контрольную сумму заголовка после декремента поля времени жизни.
8.13 Сравните протокол доставки без установления соединения ISO(стандарт ISO 8473) с IP. Насколько хорошо протокол ISO поддерживает высокоскоростную коммутацию пакетов ? Указание: поля переменной длины избыточны.
Назад | Содержание | Вперед
Мы уже видели, что Межсетевой протокол обеспечивает ненадежное средство доставки без установления соединения, и что дейтаграммы путешествуют от шлюза к шлюзу до тех пор, пока они не достигнут шлюза, который может напрямую доставить их к конечному месту назначения. Если шлюз не может маршрутизировать или доставить дейтаграмму, или если шлюз обнаружил необычные условия при работе, такие как переполнение сети, влияющие на его способность отправлять дейтаграммы, ему нужно сообщить первоначальному источнику, что требуется предпринять действия для решения возникшей проблемы. Эта глава рассматривает механизм, используемый шлюзами и ГВМ для передачи управляющей информации и информации об ошибках. Мы увидим, как шлюзы используют этот механизм, чтобы сообщать о проблемах при доставке, и как ГВМ используют его для проверки достижимости назначения.
В системе без установления соединения, которую мы описали, каждый шлюз работает автономно при маршрутизации или доставке прибывающих дейтаграмм, не координируя свои действия с исходным отправителем. Эта система хорошо работает, если все функционируют корректно и согласовали маршрутизацию, но ведь не существует систем, корректно работающих все время. Помимо сбоев линий передачи и процессоров, IP аварийно завершает доставку дейтаграмм, когда машина назначения временно или постоянно отключена от сети, когда обнуляется счетчик времени жизни, или когда промежуточные шлюзы так переполняются, что не могут обработать приходящий траффик. Важное различие между реальной, аппаратной сетью и интернетом, основанным на программном обеспечении, заключается в том, что в первом разработчик часто может положиться на сетевое оборудование при доведении до машин о возникновении проблем. В интернете, не имеющем такого аппаратного механизма, отправитель не может сказать, явился ли причиной ошибки при доставке сбой на локальной машине или удаленной. Отладка становится крайне трудной. В самом протоколе IP нет ничего, что могло бы помочь отправителю проверить связность или узнать о таких ошибках.
Чтобы дать возможность шлюзам в интернете сообщать об ошибках или предоставлять информацию о нестандартных условиях работы, разработчики добавили механизм сообщений специального назначения в протоколы TCP/IP. Этот механизм, известный как Межсетевой Протокол Управляющих Сообщений(ICMP), считается необходимой частью IP и должен включаться в каждую реализацию IP.
Как и весь другой траффик, сообщения ICMP передаются по интернету в поле данных IP-дейтаграмм. Конечным назначением сообщений ICMP, тем не менее, является не прикладная программа или пользователь на машине назначения, а программное обеспечение IP на этой машине. То есть, когда прибывает сообщение ICMP об ошибке, его обрабатывает модуль программного обеспечения ICMP. Конечно, если ICMP определит, что ошибка была вызвана конкретным протоколом более высокого уровня или прикладной программой, он сообщит об этом соответствующему модулю. Подведем итоги:
Межсетевой Протокол Управляющих Сообщений позволяет шлюзам посылать управляющие сообщения или сообщения об ошибках на другие шлюзы или ГВМ; ICMP обеспечивает взаимодействие между программным обеспечением Межсетевого Протокола разных машин.
Первоначально разработанный для предоставления шлюзам возможности сообщать о причинах ошибок доставки ГВМ, ICMP не предназначен только для шлюзов. Хотя руководства ограничивают использование некоторых сообщений ICMP, любая машина может послать сообщение ICMP на любую другую машину. Поэтому, ГВМ может использовать ICMP для связи со шлюзом или другим ГВМ. Главная выгода от разрешения ГВМ использовать ICMP заключается в том, что он обеспечивает простой механизм, используемый для всех управляющих и информационных сообщений.
Говоря техническим языком, ICMP - это механизм сообщения об ошибках. Он обеспечивает для шлюзов, обнаруживающих ошибки, способ сообщить об ошибке первоначальному источнику. Хотя спецификация протокола определяет допустимые способы использования ICMP и предлагает варианты возможных действий в ответ на ошибки, ICMP не специфицирует полностью действия, которые нужно предпринять в ответ на все возможные ошибки. Короче говоря:
ICMP только сообщает о возникших ошибках первоначальному источнику; источник сам должен связать ошибки с конкретными прикладными программами и предпринять действия по исправлению ошибок.
Большая часть ошибок исходит от первоначального источника, но другие - нет. Так как ICMP сообщает об ошибках первоначальному источнику, он не может использоваться, чтобы информировать промежуточные шлюзы об ошибках. Например, представим, что дейтаграмма следует по пути через шлюзы G1,G2,...,Gk. Если Gk содержит некорректную информацию о маршрутах и ошибочно отправит дейтаграмму на шлюз Gе, то Ge может лишь сообщить об ошибке первоначальному источнику. К сожалению, источник не отвечает за эту проблему и не может управлять некорректно ведущим себя шлюзом. Фактически, источник не сможет даже определить, какой шлюз вызвал эту проблему.
Зачем ограничивать ICMP взаимодействием с первоначальным источником ? Ответ должен быть очевиден, если вспомнить рассмотрение нами форматов дейтаграммы и маршрутизации в предыдущих главах. Дейтаграмма содержит поля, которые определяют только первоначального источника и конечного получателя; она не содержит полного описания своего пути через интернет(кроме необычных случаев, когда используется опция записи маршрута).
Более того, так как шлюзы могут создавать и менять свои таблицы маршрутизации, не существует глобального представления о путях. Поэтому, когда дейтаграмма достигает данного шлюза, нельзя узнать, какой путь она прошла до этого. Если шлюз обнаруживает ошибку, он не может узнать какие промежуточные машины обрабатывали эту дейтаграмму, и поэтому не может сообщить им об ошибке. Вместо простого удаления дейтаграммы этот шлюз использует ICMP, чтобы сообщить первоначальному источнику о возникшей проблеме, надеется на то, что администраторы ГВМ будут взаимодействовать с администраторами сети, чтобы локализовать и исправить ошибку.
Сообщения ICMP требуют двух уровней инкапсуляции, как показано на рисунке 9.1. Каждое сообщения ICMP передается по интернету в поле данных IP-дейтаграммы, которая сама передается по каждой физической сети в поле данных кадра. Дейтаграммы, несущие сообщения ICMP маршрутизируются точно так же, как и дейтаграммы, несущие информацию для пользователей; для них не используются дополнительные приоритет или надежность. Поэтому, сами сообщения об ошибках могут быть потеряны или удалены. Более того, в уже переполненной сети сообщения об ошибках могут вызвать дополнительное переполнение. Исключение делается для процедур обработки ошибок, если IP-дейтаграмма, несущая сообщение ICMP, вызвала ошибку. Это исключение, установленное для того, чтобы избежать проблемы появления сообщений об ошибках, вызванных в свою очередь сообщениями об ошибках, определяет, что сообщения ICMP не генерируются для ошибок, появившихся из-за дейтаграмм, несущих сообщения об ошибках ICMP.
--------------------------------------
|заголовок | данные ICMP |
| ICMP | |
--------------------------------------
V V
-------------------------------------------------
| заголовок| область данных дейтаграммы |
|дейтаграмм| |
-------------------------------------------------
V V
-----------------------------------------------------------
|заголовок| область данных кадра |
|кадра | |
-----------------------------------------------------------
Рисунок 9.1 Два уровня инкапсуляции ICMP. Сообщение ICMP инкапсулируется в IP-дейтаграмме, которая в свою очередь инкапсулируется в кадре для передачи. Для идентификации ICMP поле протокола дейтаграммы содержит значение 1.
Важно помнить, что несмотря на то, что сообщения ICMP инкапсулируются и посылаются, используя IP, ICMP не считается протоколом более высокого уровня - он является необходимой частью IP. Причина использования IP для транспортировки сообщений ICMP заключается в том, что им понадобиться пересечь несколько физических сетей для того, чтобы достичь своего конечного назначения. Поэтому, они не могут быть доставлены только с помощью физической передачи.
Хотя каждое сообщение ICMP имеет свой собственный формат, все они начинаются с трех одинаковых полей: 8-битового целочисленного поля ТИП, которое идентифицирует сообщение, 8-битового поля КОД, которое обеспечивает более точную информацию о типе сообщения, и 16-битового поля КОНТРОЛЬНАЯ_СУММА(ICMP использует тот же самый аддитивный алгоритм, что и IP, но контрольная сумма ICMP учитывает только сообщение ICMP). Помимо того, сообщения ICMP, сообщающие об ошибках, всегда включают заголовок и первые 64 бита данных дейтаграммы, вызвавшей ошибку.
Причиной возвращения не только заголовка дейтаграммы, вызвавшей ошибку, является желание позволить получателю более точно определять, какие протоколы и какие прикладные программы ответственны за появление этой дейтаграммы. Как мы увидим позже, протоколы более высокого уровня в связке TCP/IP разрабатывались таким образом, что критическая информация закодирована в первых 64 битах.
Поле ТИП ICMP определяет смысл сообщения, а также его формат. Эти типы включают:
| Поле ТИП | Тип сообщения ICMP |
|---|---|
| 0 | Ответ на эхо |
| 3 | Назначение недостижимо |
| 4 | Подавление источника |
| 5 | Переназначение(изменение маршрута) |
| 8 | Запрос эха |
| 11 | Превышено время для дейтаграммы |
| 12 | Ошибка параметра в дейтаграмме |
| 13 | Запрос временной отметки |
| 14 | Ответ для временной метки |
| 15 | Запрос информации(не действует) |
| 16 | Ответ на запрос информации(не действует) |
| 17 | Запрос маски адреса |
| 18 | Ответ на запрос маски адреса |
Следующие секции описывают каждое из этих сообщений, приводя при этом детальное описание формата сообщения и их смысл.
Протоколы TCP/IP обеспечивают средства, помогающие сетевым администраторам или пользователям идентифицировать проблемы в сети. Одно из самых наиболее используемых средств отладки вызывает сообщения ICMP запрос эха и ответ эха. ГВМ или шлюз посылает сообщение запроса эха указанному месту назначения. Любая машина, получившая запрос эха, генерирует ответ на эхо и возвращает его первоначальному отправителю. Этот запрос содержит необязательную область данных; ответ содержит копию данных, посланных в запросе. Запрос эха и связанный с ним ответ могут использоваться для проверки достижимости назначения и его способности отвечать на запросы. Так как и запрос эха, и ответ на него передаются в IP-дейтаграммах, успешный прием ответа свидетельствует о работоспособности основных частей транспортной системы. Во-первых, программное обеспечение IP на машине источника произвело маршрутизацию дейтаграммы. Во-вторых, промежуточные шлюзы между источником и получателем работоспособны и корректно маршрутизируют дейтаграммы. В-третьих, машина получателя работает (по крайней мере, она обрабатывает прерывания) и программное обеспечение как IP, так и ICMP выполняет свои функции. И наконец, таблицы маршрутов в шлюзах на всем обратном пути корректны.
Во многих системах команда, которую пользователи вызывают для посылки запроса эха ICMP, называется ping. Усложненные версии этой программы посылают серии запросов эха ICMP, принимают ответы и выдают статистику о потерях дейтаграмм. Они позволяют пользователю указывать длину посылаемых данных и интервалы времени между запросами. Менее сложные версии просто посылают запрос эха ICMP и ждут ответа.
Рисунок 9.2 содержит формат сообщений запроса эха и ответа на запрос эха.
0 8 16 ------------------------------------------------------------ |тип(8 или 0)| код(0) | Контрольная сумма | ------------------------------------------------------------ | идентификатор | последовательный номер | ------------------------------------------------------------ | необязательные данные | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.2 Формат сообщения запроса эха и ответа на него
Поле, названное НЕОБЯЗАТЕЛЬНЫЕ ДАННЫЕ имеет переменную длину и содержит данные, которые надо вернуть отправителю. Ответ на эхо всегда возвращает те же самые данные, что были получены им в запросе. Поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются отправителем для проверки соответствия ответов запросам. Значение поля ТИП определяет, является ли сообщение запросом(8) или ответом(0).
Когда шлюз не может доставить IP-дейтаграмму, он посылает сообщение "назначение недостижимо" обратно первоначальному отправителю, используя формат, приведенный на рисунке 9.3.
0 8 16 ------------------------------------------------------------ |тип(3) | код(0-5) | Контрольная сумма | ------------------------------------------------------------ | не используется(должно быть равно нулю) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.3 Формат сообщения о недостижимости назначения
Поле КОД в сообщении о недостижимости назначения содержит целое число, которое описывает причину. Возможны следующие значения:
| Значение | Смысл |
|---|---|
| 0 | Сеть недостижима |
| 1 | ГВМ недостижим |
| 2 | Протокол недостижим |
| 3 | Порт недостижим |
| 4 | Требуется фрагментация |
| 5 | Ошибка при маршрутизации источника |
| 6 | Сеть назначения неизвестна |
| 7 | ГВМ назначения неизвестен |
| 8 | ГВМ источника изолирован |
| 9 | Взаимодействие с сетью назначения административно запрещено |
| 10 | Взаимодействие с ГВМ назначения административно запрещено |
| 11 | Сеть недостижима из класса обслуживания |
| 12 | ГВМ недостижим из-за класса обслуживания |
Хотя IP является механизмом ненадежной доставки, дейтаграммы не уничтожаются просто так. Всякий раз, когда ошибка мешает шлюзу произвести маршрутизацию или доставку дейтаграммы, шлюз посылает сообщение о недостижимости назначения обратно его источнику, а затем уничтожает дейтаграмму. Ошибки недостижимости сети обычно являются следствием ошибок маршрутизации; ошибки недостижимости ГВМ - следствие ошибок при доставке(исключением является случай, когда шлюзы используют схему адресации подсетей, описанную в главе 16. Они сообщают об ошибке при маршрутизации к подсети с помощью сообщения ICMP о недостижимости ГВМ). Так как сообщение содержит короткий префикс дейтаграммы, вызвавшей ошибку, то источник будет точно знать, какой адрес недостижим.
Назначения могут быть недостижимыми из-за того, что оборудование было временно неработоспособно, из-за того, что отправитель указал несуществующий адрес назначения, или ( в редких случаях) из-за того, что у шлюза не указано маршрута к сети назначения. Отметим, что хотя шлюзы сообщают об ошибках, которые они обнаружили, они могут не знать обо всех ошибках доставки. Например, если машина получателя присоединена к сети Ethernet, то сетевое оборудование не предоставляет подтверждения получения дейтаграммы. Поэтому, шлюз может продолжать посылать пакеты назначению даже после того, как оно отключено, не получая при этом никакой информации о том, что пакеты не доставляются. Подведем итоги:
Хотя шлюзы посылают сообщения о недостижимости назначения, если они не могут произвести маршрутизацию или доставку дейтаграммы, не все подобные ошибки обнаруживаются.
Смысл сообщений о недостижимости порта и протокола станет ясен, когда мы изучим, как протоколы более высокого уровня используют абстракцию точки получения, называемую портом. Смысл большей части остальных сообщений понятен уже из их названия. Если дейтаграмма содержит опцию маршрутизации источника с некорректным маршрутом, то это может привести к появлению сообщения об ошибке маршрутизации источника. Если шлюзу нужно фрагментировать дейтаграмму, но установлен бит "не фрагментировать", то шлюз посылает сообщение "требуется фрагментация" обратно источнику.
Так как IP является протоколом без установления соединения, то шлюзы не могут резервировать память или коммуникационные ресурсы до получения дейтаграмм. В результате, траффик может вызвать перегрузку шлюзов, ситуацию, называемую переполнением сети(congestion). Важно понимать, что переполнение сети может возникать из-за двух совершенно разных причин. Во-первых, высокоскоростной компьютер может генерировать траффик быстрее, чем сеть может передавать его. Например, представим суперкомпьютер, генерирующий межсетевой траффик. Дейтаграммам, посылаемым им, может потребоваться передача в конечном счете по медленной глобальной сети(WAN), хотя сам суперкомпьютер может быть присоединен к высокоскоростной локальной сети. Переполнение будет возникать в шлюзе, присоединенном к глобальной сети, так как дейтаграммы будут прибывать быстрее, чем их можно послать. Во-вторых, если большому числу компьютеров одновременно нужно посылать дейтаграммы через один шлюз, этот шлюз может оказаться переполненным, хотя ни один источник в отдельности и не вызывает эту проблему.
Когда дейтаграммы прибывают на шлюз или ГВМ быстрее, чем он успевает их обрабатывать, он временно ставит их в очередь в своей памяти. Если эти дейтаграммы - это часть небольшого пика при передаче дейтаграмм, то такая буферизация решает проблему. Если же траффик продолжает поступать, то то в конечном счете ГВМ или шлюз займет всю память под очередь и вынужден будет удалять новые прибывающие дейтаграммы. Тогда машина использует сообщения о подавлении источника для выхода из состояния переполнения.
Сообщение о подавлении источника требует от источника уменьшить скорость передачи дейтаграмм. Обычно переполненные шлюзы посылают по одному сообщению о подавлении источника на каждую удаляемую дейтаграмму. Шлюзы могут также использовать более сложные технологии выхода из переполнения. Некоторые наблюдают за приходящим траффиком и подавляют источники с наивысшими скоростями передачи. Другие пытаются избежать переполнения в принципе, выдавая запросы подавления источника в том случае, когда их очереди начинают становиться слишком длинными, но до того, как они переполнятся.
Не существует сообщения ICMP, вызывающего эффект, обратный подавлению источника. Вместо этого ГВМ, принявший сообщения о подавлении источника от некоторой машины, М, снижает скорость, с которой он посылает дейтаграммы на М до тех пор, пока к нему не перестанут приходить сообщения о подавлении источника; затем он постепенно увеличивает скорость до тех пор, пока он снова не получит сообщения о подавлении источника.
Помимо обычных полей ICMP ТИП, КОД и КОНТРОЛЬНАЯ СУММА, и неиспользуемого 32-битового поля, сообщения о подавлении источника имеют поле, содержащее префикс дейтаграммы. Рисунок 9.4 иллюстрирует этот формат. Как и в других сообщениях об ошибках ICMP поле префикса дейтаграммы содержит префикс дейтаграммы, вызвавшей этот запрос подавления источника.
0 8 16 31 ------------------------------------------------------------ |тип(4) | код(0) | Контрольная сумма | ------------------------------------------------------------ | не используется(должно быть равно нулю) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.4 Формат сообщения о подавлении источника ICMP. Переполненные шлюзы посылают одно сообщение о подавлении источника каждый раз, когда они удаляют дейтаграмму; префикс дейтаграммы идентифицирует удаленную дейтаграмму.
Таблицы маршрутизации Интернета обычно не меняются в течение длинного промежутка времени. ГВМ инициализируют их с помощью файла конфигурации при загрузке системы, а сетевые администраторы лишь изредка вносят в них изменения при нормальной работе. При изменении топологии сети таблицы маршрутизации в ГВМ или шлюзе могут стать некорректными. Изменение может быть временным(например, нужно заменить неисправное оборудование) или постоянным(например, когда новая сеть добавляется к интернету). Как мы увидим позже, шлюзы периодически обмениваются информацией о маршрутизации, чтобы отслеживать изменения в сети и своевременно менять маршруты. Поэтому можно сформулировать общее правило:
Предполагается, что шлюзы знают корректные маршруты; ГВМ начинают работать, имея минимум информации о маршрутах, но впоследствии узнают новые маршруты от шлюзов.
Чтобы помочь придерживаться этого правила и чтобы избежать дублирования информации о маршрутизации в файле конфигурации каждого ГВМ, в начальной конфигурации ГВМ указывается минимум информации о маршрутизации, необходимый для взаимодействия (например, адрес одного шлюза). Поэтому ГВМ начинает работать, имея минимальную информацию, и полагается на то, что шлюзы помогут обновить ему таблицу маршрутизации. Если шлюз обнаруживает, что ГВМ использует неоптимальный маршрут, он посылает ГВМ сообщение ICMP, называемое "переназначением", запрашивающее изменение маршрута в таблице маршрутизации ГВМ. Этот шлюз также отправляет исходную дейтаграмму к ее назначению. Преимуществом схемы переназначения ICMP является ее простота: она позволяет ГВМ знать вначале адрес только одного шлюза в локальной сети. Этот начальный шлюз возвращает сообщение ICMP о переназначении всякий раз, когда ГВМ посылает дейтаграмму, для которой существует лучший маршрут. Таблица маршрутизации ГВМ останется маленькой, но будет содержать оптимальные маршруты для всех используемых назначений.
Сообщения о переназначении, тем не менее, не решают проблему распространения информации о маршрутах полностью, так как они предназначены только для взаимодействия между шлюзом и ГВМ в одной физической сети. Рисунок 9.5 иллюстрирует эту проблему. Согласно рисунку предполагается, что источник И посылает дейтаграмму назначению Н. Пусть шлюз Ш1 некорректно направляет дейтаграмму через шлюз Ш2 вместо шлюза Ш4(то есть Ш1 по ошибке выбрал более длинный путь). Когда шлюз Ш5 принимает дейтаграмму, он не может послать сообщение переназначения ICMP Ш1, так как он не знает адрес шлюза Ш1. Последующие главы рассмотрят проблему, как распространяется информация о маршрутах между несколькими сетями.
| -- | -- |
-- |--|Ш1|-|-|Ш2|-| -- | |
| И|--| -- | -- |-|Ш3|-| -- |
-- | | -- |---|Ш5|-| --
| | -- | -- |--| Н|
| |----|Ш4|-----| | --
| | -- |
Рисунок 9.5 Сообщения о переназначении ICMP не помогают маршрутизации между шлюзами. В этом примере шлюз Ш5 не может заставить Ш1 использовать более короткий путь для дейтаграмм между И и Н.
Помимо полей-реквизитов ТИП, КОД и КОНТРОЛЬНАЯ СУММА, каждое сообщение о переназначении содержит 32-битовое поле МЕЖСЕТЕВОЙ АДРЕС ШЛЮЗА и поле ПРЕФИКС ДЕЙТАГРАММЫ, как это показано на рисунке 9.6
0 8 16 31 ------------------------------------------------------------ |тип(5) |код(от 0 до 3)| Контрольная сумма | ------------------------------------------------------------ | межсетевой адрес шлюза | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.6 Формат сообщения о переназначении ICMP
Поле МЕЖСЕТЕВОЙ АДРЕС ШЛЮЗА содержит адрес шлюза, который должен использовать ГВМ при отправлении дейтаграммы к назначению, указанному в заголовке дейтаграммы. Поле МЕЖСЕТЕВОЙ ЗАГОЛОВОК содержит заголовок IP и следующие 64 бита дейтаграммы, которая привела к появлению этого сообщения. Поэтому ГВМ, принимающий сообщение о переназначении ICMP, должен выделить адрес назначения дейтаграммы из префикса дейтаграммы. Поле КОД в сообщении о переназначении ICMP более конкретно указывает, как интерпретировать адрес назначения, при этом значения имеют следующий смысл:
| Значение кода | Смысл сообщения |
|---|---|
| 0 | Переназначение дейтаграмм для этой сети(устарело) |
| 1 | Переназначение дейтаграмм для этого ГВМ |
| 2 | Переназначение дейтаграмм для этого типа сервиса и сети |
| 3 | Переназначение дейтаграмм для этого типа сервиса и ГВМ |
Замечание. Напомним, что каждый заголовок IP указывает тип сервиса, используемого при маршрутизации
Как правило, шлюзы посылают запросы переназначения ICMP только на ГВМ, а не на другие шлюзы. Позже мы увидим, что шлюзы используют другие протоколы для обмена информацией о маршрутизации.
Так как межсетевые шлюзы вычисляют адрес следующей машины для направления дейтаграммы на основе локальных таблиц, ошибки в таблице маршрутизации могут привести к циклу маршрутизации в некотором месте назначения, D. Цикл маршрутизации может состоять из двух шлюзов, каждый из которых отправляет дейтаграмму с адресом назначения D другому шлюзу, или может состоять из большего числа шлюзов. Когда несколько шлюзов формируют цикл маршрутизации, каждый из них отправляет дейтаграмму с назначением Н к следующему шлюзу из цикла. Если дейтаграмма входит в цикл маршрутизации, она будет передаваться по нему бесконечно. Как было отмечено ранее, для защиты дейтаграмм от бесконечного курсирования по Интернету TCP/IP каждая дейтаграмма имеет счетчик время жизни, иногда называемый число попыток. Шлюз декрементирует счетчик времени жизни всякий раз, когда он обрабатывает дейтаграмму, и удаляет дейтаграмму, когда счетчик становится нулевым.
Независимо от того, удалил ли шлюз дейтаграмму из-за обнуления счетчика времени жизни или из-за превышения времени ожидания фрагментов дейтаграммы, он посылает сообщение ICMP "превышено время" источнику дейтаграммы, используя формат, показанный на рисунке 9.7
0 8 16 31 ------------------------------------------------------------ |тип(11) |код(0 или 1) | Контрольная сумма | ------------------------------------------------------------ | не используется(должно быть нулем) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.7 Формат сообщения ICMP о превышении времени. Шлюз посылает это сообщение всякий раз, когда удаляет дейтаграмму из-за обнуления поля времени жизни в заголовке дейтаграммы или из-за обнуления таймера сборки при ожидании фрагментов дейтаграммы.
Поле КОД объясняет причину сообщения:
| Значение кода | Смысл |
|---|---|
| 0 | Превышено значение счетчика времени жизни |
| 1 | Превышено время ожидания фрагмента при сборке |
Сборкой фрагментов называют задачу сбора всех фрагментов дейтаграммы. Когда прибывает первый фрагмент дейтаграммы, принимающий ГВМ запускает таймер и считает ошибкой его обнуление до прихода всех фрагментов дейтаграммы. Значение кода 1 используется для того, чтобы сообщить отправителю о такой ошибке; для каждой ошибки посылается отдельное сообщение.
Когда шлюз или ГВМ сталкивается с проблемой, связанной с дейтаграммой, не укладывающейся в рамки описанных сообщений об ошибках ICMP( например, некорректный заголовок дейтаграммы), он посылает сообщение "ошибка параметров" первоначальному отправителю. Одной из возможных причин такой ситуации может быть некорректность аргументов опции. Сообщение, формат которого приведен на рисунке 9.8, посылается только в том случае, если дейтаграмма должна быть удалена из-за этой ошибки.
0 8 16 ------------------------------------------------------------ |тип(12) | код(0 или 1) | Контрольная сумма | ------------------------------------------------------------ |указатель | не используется(должно быть равно нулю) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.8 Формат сообщения ICMP ошибка параметров. Такие сообщения посылаются только в том случае, когда из-за этой ошибки дейтаграмму удаляется.
Для однозначности сообщения отправитель использует поле УКАЗАТЕЛЬ в заголовке сообщения для идентификации октета в дейтаграмме, вызвавшего ошибку. Код 1 используется для случая, когда требуемая опция отсутствует( например, опция секретности в военной связи); поле указатель не используется при коде 1.
Хотя машины в интернете могут взаимодействовать, обычно они работают независимо друг от друга, причем у каждой машины свое понятие о текущем времени. Сильно отличающиеся часы могут смущать пользователей распределенных систем. Стек протоколов TCP/IP включает несколько протоколов, которые могут использоваться для синхронизации часов. Одна из простейших технологий использует сообщения ICMP для получения значения времени от другой машины. Запрашивающая машина посылает сообщение ICMP "запрос временной метки" другой машине, ожидая, что вторая машина вернет ей текущее значение времени. Принимающая машина возвращает "ответ временной метки" машине, выдавшей запрос. Рисунок 9.9 показывает формат сообщений запроса и ответа временной метки.
0 8 16 ------------------------------------------------------------ |тип(13, 14) | код(0) | Контрольная сумма | ------------------------------------------------------------ | идентификатор | последовательный номер | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | временная метка отправителя | ------------------------------------------------------------ | временная метка приема | ------------------------------------------------------------ | временная метка передачи | ------------------------------------------------------------
Рисунок 9.9 Формат сообщений ICMP запроса и ответа временной метки
Поле ТИП идентифицирует сообщение как запрос(13) или ответ(14); поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются источником для связи между ответами и запросами. Оставшиеся поля специфицируют времена, указанные в миллисекундах после полуночи, по Гринвичу. Поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ заполняется первоначальным отправителем перед передачей пакета, поле ВРЕМЕННАЯ МЕТКА ПРИЕМА заполняется сразу после приема запроса, и поле ВРЕМЕННАЯ МЕТКА ПЕРЕДАЧИ заполняется непосредственно перед отправкой ответа.
ГВМ используют эти три поля временных меток для определения ожидаемого времени передачи между ними и синхронизации своих часов. Так как ответ включает поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ, ГВМ может вычислить общее время, требуемое для передачи запроса к назначению, формирования ответа на него и возвращения ответа. Так как ответ содержит как время прихода запроса на удаленную машину, так и время выдачи ответа, ГВМ может вычислить время передачи по сети, а на его основе - разницу между своими и удаленными часами. На практике бывает трудно точно оценить время передачи по сети, что ограничивает полезность сообщений ICMP о временных метках. Конечно, для получения точной оценки времени передачи по сети нужно сделать много измерений и усреднить их. Тем не менее, время передачи по сети между двумя машинами, присоединенными к большому интернету, может сильно меняться, даже за короткий отрезок времени. Более того, напомним, что так как IP является технологией с негарантированной доставкой, дейтаграммы могут быть потеряны, задержаны или доставлены не по порядку. Поэтому, простые измерения не гарантируют согласованности; требуется сложный статистический анализ для точной оценки.
Сообщения ICMP запроса информации и ответа информации( тип 15 и 16) считаются в настоящее время устаревшими и не должны использоваться. Они предназначались для обнаружения ГВМ своих межсетевых адресов при загрузке. Сейчас для определения адреса используется протоколы RARP(глава 6), и BOOTP(глава 19).
Глава 16 рассмотрит причины адресации подсетей, а также детали ее реализации. А пока только важно понимать, что когда ГВМ используют адресацию подсетей, некоторые биты в поле идентификатора ГВМ их IP-адреса идентифицируют физическую сеть. Для применения адресации подсетей ГВМ надо знать, какие биты их 32-битного межсетевого адреса соответствуют физической сети, а какие - идентификатору ГВМ. Информация, требуемая для интерпретации адреса, представляет собой 32-битовую величину, называемую маской подсети.
Чтобы узнать маску подсети, используемую в локальной сети, машина может послать сообщение запроса маски адреса шлюзу и получить ответ маски адреса. Машина, делающая запрос, может либо послать сообщение напрямую, если она знает адрес шлюза, или послать широковещательное сообщение, если не знает его. Рисунок 9.10 показывает формат сообщения маски адреса.
0 8 16 ------------------------------------------------------------ |тип(17, 18) | код(0) | Контрольная сумма | ------------------------------------------------------------ | идентификатор | последовательный номер | ------------------------------------------------------------ | маска адреса | ------------------------------------------------------------
Рисунок 9.10 Формат сообщений запроса маски адреса и ответа маски адреса. Обычно, ГВМ передают широковещательный запрос, не зная, какой шлюз будет отвечать им.
Поле ТИП в сообщении маски адреса указывает, является ли сообщение запросом(17) или ответом(18). Ответ содержит маску адреса подсети сети в поле МАСКА АДРЕСА. Как правило, поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР позволяют машине связать ответ с запросом.
Обычное взаимодействие через интернет включает посылку сообщений от пользовательского процесса на одной ГВМ пользовательскому процессу на другой ГВМ. Шлюзам может понадобиться прямое взаимодействие с сетевым программным обеспечением на конкретном ГВМ для сообщения ему об ошибках или для посылки ГВМ новой информации о маршрутах.
ICMP обеспечивает специальное взаимодействие между шлюзами и ГВМ; он является необходимой частью IP. ICMP включает в себя сообщения о "подавлении источника", регулирующие скорость передачи, сообщения "переназначения", требующие от ГВМ изменения таблиц маршрутизации, сообщения "запроса/ответа эха", которые ГВМ может использовать, чтобы определить, достижимо ли назначение. Сообщение ICMP передается в поле данных дейтаграммы IP и имеет три поля фиксированной длины в начале сообщения: поле типа сообщения ICMP, поле кода и поле контрольной суммы ICMP. Тип сообщения определяет формат остальной части сообщения и его смысл.
Как Tanenbaum[1981], так и Stallings[1985] рассматривают управляющие сообщения в-общем и связывают их с различными сетевыми протоколами. Главным вопросом является не то, как посылать управляющие сообщения, а когда. Grange и Gien[1979], а также Driver, Hopewell, и Iaquinto[1979] сосредотачиваются на проблеме управления потоком, для которой управляющие сообщения необходимы. Gerla и Kleinrock[1980] аналитически сравнивают стратегии управления потоком.
ICMP, описанный здесь как стандарт TCP/IP, разработан Postel[RFC 792]. Nagle[RFC 896] рассматривает сообщения подавления источника и показывает, как шлюзы должны использовать их для ликвидации перегрузки сети. Prue и Postel[RFC 1016] рассматривают более новую технологию, которую используют шлюзы при подавлении источника. Nagle[1987] доказывает, что перегрузка всегда является проблемой в сетях с пакетной коммутацией. Mogul и Postel[RFC 950] рассматривают сообщения запроса и ответа маски подсети. Наконец, Jain, Ramakrishnan и Chui [1987] показывают, как шлюзы и транспортные протоколы могут взаимодействовать для ликвидации перегрузки сети.
Более подробно протоколы синхронизации часов описаны в Mills[RFC 956, 957 и 958].
9.1 Попробуйте определить сколько сообщения ICMP и какого типа появляется в вашей локальной сети в течение дня.
9.2 Попробуйте, сможете ли вы посылать пакеты через шлюз так быстро, что получите сообщение ICMP о подавлении источника.
9.3 Разработайте алгоритм, синхронизирующий часы на основании сообщений ICMP о временных метках.
9.4 Посмотрите, содержит ли ваша операционная система команду ping. Можно ли создать ее самому ?
9.5 Предположим, что операционная система посылает сообщения ICMP о превышении времени прикладным программам. Используйте их для выполнения команды traceroute, выдающей список шлюзов между источником и конкретными назначениями.
9.6 Если вы присоединены к Интернету, попробуйте запустить утилиту ping для ГВМ 128.10.2.1 ( машина в Пурдью)
9.7 Должен ли шлюз давать сообщениям ICMP более высокий приоритет по сравнению с обычным траффиком ? Почему ?
9.8 Рассмотрим Ethernet, имеющий один ГВМ и 12 шлюзов, присоединенных к нему. Определите, какой кадр(немного неправильный), содержащий IP-пакет и посланный ГВМ, заставит ГВМ принять 24 пакета.
9.9 Сравните пакеты подавления источника ICMP с однобитовой схемой Jaina. Какая из стратегий более удобна для ликвидации перегрузки сети ? Почему ?
9.10 Не существует сообщений ICMP, позволяющих машине информировать источник, что ошибки передачи приводят к тому, что дейтаграммы принимаются испорченными. При каких условиях такое сообщение может быть полезным ?
9.11 Должны ли сообщения об ошибках ICMP содержать временные метки, определяющие, когда они были посланы ? Почему ?
Назад | Содержание | Вперед
| Документ из базы библиотеки компьютерной литературы 'Roga и Копыта' - www.roga.by.ru |
| Содержание документа. | Скачать архив документа. | Другие документы по данной теме. | Вернуться в библиотеку. | Рассылка новых поступлений. | ЧАТЫ по интересам. |
В последнем веке железные дороги революционизировали мир, обеспечив транспортную сеть, которая перемещала материалы и продукты производства. Они сделали возможным индустриальное общество. Цифровые коммуникационные сети ознаменовали начало новой революции, обеспечив технологию, которая транспортирует данные, требуемые обществу, в котором информация играет ключевую роль. Сети уже проникли в промышленность, образование и правительство. Они уже начали изменять наше представление о мире , сократив географические расстояния и образовав новые сообщества людей, которые часто взаимодействуют. Еще более важно то, что рост числа сетей носит характер взрыва. Революция уже началась.
Чтобы понимать сетевой обмен и круг вопросов, рассматриваемых в книге, важно представлять, что сетевые исследования и разработки прошли через три стадии развития До 1960 года, основным вопросом был "Как передавать биты по среде коммуникации эффективно и надежно?". Результаты включают разработку теории информации, теоремы Котельникова и других идей, которые в совокупности называют обработкой сигналов. От начала и до середины 60-х внимание было сконцентрировано на пакетной коммутации и основным вопросом стал: "Как передавать пакеты по среде коммуникации эффективно и надежно?" . Результатами этого этапа стали разработка технологий пакетной коммутации, локальных вычислительных сетей и статистический анализ времени передачи пакетов по сети в зависимости от загрузки. Приблизительно с середины 70-х и до нынешнего времени самым главным направлением стали сетевые архитектуры и вопрос "Как обеспечить средства взаимодействия взаимосвязанных сетей?". Результатами последнего этапа стала разработка технологий межсетевого обмена, многоуровневых моделей протоколов, дейтаграммных и потоковых транспортных средств и парадигмы взаимодействия клиент-сервер.
Многие книги и курсы по сетям основную часть материала посвящают первым двум стадиям сетевых исследований, описывая хорошо известные теории передачи данных и массового обслуживания. Хотя такая информации и важна для инженеров, которые проектируют сетевые технологии и оборудование, большинство работающих с сетями использует купленное сетевое оборудование. Вместо детальных знаний о том, как биты или пакеты передаются по среде передачи информации, им нужно знать, как взаимодействует такое оборудование и как использовать уже имеющиеся системы.
Моя книга посвящена третьей стадии сетевых исследований. Она рассматривает архитектуру взаимосвязанных сетей и обьясняет принципы и протоколы, которые позволяют функционировать таким взаимосвязанным архитектурам как одна единая коммуникационная система. Более того, она показывает, как взаимосвязанные архитектуры могут быть использованы для распределенных вычислений. Вся книга посвящена понятию межсетевого обмена в общем и технологии Интернета TCP/IP в частности. Межсетевой обмен - это мощная абстракция, которая позволяет нам оперировать с несколькими коммуникационными технологиями, лежащими в основе его. Она скрывает детали сетевого оборудования и обеспечивает высокоуровневую среду взаимодействия. Как показывает эта книга, конечной целью межсетевого обмена является максимальная взаимная работоспособность, то есть максимальная способность программ на различных компьютерах и сетевых системах взаимодействовать надежно и эффективно.
Эта книга рассматривает как архитектуру сетевых взаимодействий, так и межсетевые коммуникационные средства и протоколы, требуемые для обеспечения этих средств. К концу этой книги читатель будет понимать, как возможно взаимное соединение нескольких физических сетей в одну координированную систему, как межсетевые протоколы работают в такой среде, и как прикладные программы используют получившуюся систему. В качестве конкретного примера читатель узнает детали Связанного(TCP/IP) Интернета, включая архитектуру систем шлюзов и прикладные протоколы, которые они поддерживают. Кроме того, эта книга рассматривает некоторые ограничения межсетевого подхода.
Написание книги о межсетевом обмене является как захватывающим, так и требующим внимания. Оно требует быть точным, так как , как и в любой быстро развивающейся области, ничего не является стабильным. Оно захватывает, так как Интернет TCP/IP - это активная, быстро расширяющаяся сущность. Исследователи, работающие над ним, постоянно генерируют новые идеи и его возможности кажутся бесконечными. Если посмотреть на историю TCP/IP и эволюцию Интернета, то становится ясно, что многое уже доведено до конца. Зная, что исследования ведутся немногим больше десятилетия, понимаешь, как быстро было все это сделано.
Разработанная и как учебник, и как профессиональный справочник, эта книга написана на уровне выпускника института. Для профессионалов, эта книга даст простое введение в технологию TCP/IP и архитектуру Интернета. Хотя, она и не заменяет собой протоколы, книга является хорошим началом при обучении межсетевому обмену, так как он дает полный обзор его принципов. Более того, она дает читателю направления развития, что крайне трудно сделать, работая с отдельными протоколами.
При использовании в институте, этот текст более чем достаточный материал для односеместрового курса по сетям на старших курсах института. Такой курс может быть расширен до двухсеместрового курса, если он будет сопровождаться разработкой программ и чтением литературы. Для всех студентов она может иметь большое значение. Студенты должны понимать базовые идеи, описанные в тексте, и уметь описать их и использовать самим.
Выпускникам институтов нужно использовать изложенный здесь материал как основу для дальнейшего изучения современных исследований. Они должны понимать его достаточно хорошо, чтобы отвечать на вопросы и решать задачи, требующие от них изучения вопроса на более глубоком уровне. Многие из упражнений предполагают изучение тонкостей вопроса; решение их часто требует от студента чтения протоколов и применения ума для вывода ответа. На всех уровнях практический опыт помогает студентам усилить интуицию. Поэтому, я предлагаю преподавателям придумывать проекты, которые заставят студентов использовать межсетевые средства и протоколы. Хотя такие эксперименты безопаснее всего проводить, когда лабораторная сеть изолирована от основных вычислительных средств, было установлено, что студенты проявляют наибольший энтузиазм, и как следствие наилучшие результаты, когда они имеют доступ к реальному Интернету TCP/IP.
Эта книга организована в виде четырех основных частей. Главы 1 и 2 образуют введение, которое обеспечивает обзор и рассматривает существующие технологии. В частности, глава 2 рассматривает физическое сетевое оборудование. Идея заключается в том, чтобы дать интуитивное понимание о том, что возможно, не тратя лишнего времени на детальное изучение оборудования. Главы 3-12 описывают Интернет TCP/IP с точки зрения отдельной ЭВМ, показывая доступные базовые средства и протоколы, которые использует ЭВМ для доступа к ним. Они охватывают основы адресации Интернета и маршрутизацию, а также понятие о многоуровневой модели протоколов. Главы 13-17 описывают архитектуру сообщества сетей при рассмотрении его в глобальном смысле. Они описывают систему базовых шлюзов и протоколы, которые шлюзы используют для обмена информацией о маршрутах. Наконец, главы 18-26 рассматривают прикладные средства, доступные в Интернете. Они описывают модель взаимодействия клиент-сервер и дают несколько примеров того, как можно организовать программное обеспечение клиента и сервера. Последняя часть рассматривает электронную почту и доменную(domain) систему имен, два раздела, которые очень популярны.
Эти главы организованы по принципу снизу вверх. Они начинают с рассмотрения оборудования и продолжают, описывая новые возможности на основе старых. Такой подход знаком любому, кто разрабатывал программное обеспечение Интернета, так как повторяет подход, который он использовал при реализации. Понятие многоуровневости не появится до главы 10. Рассмотрение уровней подчеркивает различие между концептуальными уровнями и реальным многоуровневым программным обеспечением в котором на каждом уровне могут находиться большое число обьектов.
Хотя и трудно опустить любую главу полностью, преподаватель обнаружит, что студенты часто удовлетворяются знанием того, что что-то возможно, не зная того, как это возможно. Например, можно пройти главы 5, 6 и 9, рассмотрев только возможности и опустив детали протоколов. Кроме того, несколько глав(особенно 16) содержат инженерные технологии, которые могут быть пропущены ради сохранения времени.
Для понимания материала требуется очень немного знаний. Ожидается, что читатель умеет программировать на языке высокого уровня и знаком с основными базовыми структурами, такими как стеки, очереди и деревья. Читателю нужно понимание принципов организации программного обеспечения в операционных системах, которые поддерживают многозадачность. Читателю не нужно быть математиком-профессионалом, а нужно только знать теорию информации или теоремы из теории передачи данных эта книга описывает физическую сеть как черный ящик, на основе которого может быть построен Интернет. Принципы разработки описываются на русском языке, а также приводятся причины и следствия.
Много людей внесло свой вклад в создание этой книги. Я благодарю Scott Ballew, Steve Chapin, Jim Griffioen, Chris Kent, Tim Korb, Dan Lynch, Thomas Narten, Vic Norman, Shawn Ostermann, John Steele, Mike StJohns, Dan Tormey, Ray Yavatkar и Preston Wilson, которые читали рукопись и сделали ряд ценных замечаний. Craig Partridge внес много предложений, включая упражнения и исправил несколько технических ошибок. Он и Van Jacobson предложили граф задержек при передаче данных через Интернет в главе 12. Dave Stevens внес как технические, так и грамматические улучшения во второе издание. Barry Shein позволил мне использовать в качестве примера код для UNIX клиента и сервера в приложении 1. Charlotte Tubis сильно помогла при редактировании книги. Особая благодарность моей жене, Chris, которая читала текст бессчетное число раз и внесла много предложений.
Назад | Содержание | Вперед