Компьютерные сети. 6-е изд.

5.1. Вопросы разработки сетевого уровня

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

5.1.1. Метод коммутации пакетов с ожиданием

Прежде чем начать подробное рассмотрение сетевого уровня, имеет смысл вспомнить окружение, в котором он функционирует (илл. 5.1). Основными компонентами сети являются устройства интернет-провайдера (ISP) — маршрутизаторы, коммутаторы и промежуточные узлы, соединенные линиями связи (они показаны на рисунке в сером овале), а также устройства пользователя (находятся вне овала). Хост H1 напрямую соединен с одним из маршрутизаторов провайдера А (это может быть домашний компьютер, подключенный к DSL-модему). Хост H2, напротив, входит в LAN (например, в офисную сеть Ethernet) с маршрутизатором F, принадлежащим клиенту, который с ним работает. Этот маршрутизатор связывается с провайдером по выделенной линии. Мы показали F вне овала, потому что он не принадлежит ISP. Однако в контексте данной главы мы будем считать маршрутизаторы клиента частью сети ISP, поскольку в них применяются те же самые алгоритмы, что и в маршрутизаторах интернет-провайдеров (именно алгоритмы будут основным предметом рассмотрения).

Илл. 5.1. Окружение, в котором функционируют протоколы сетевого уровня

Система работает следующим образом. Хост, у которого есть пакет для передачи, отправляет его на ближайший маршрутизатор — либо в своей LAN, либо провайдеру по двухточечному соединению (например, по каналу ADSL или по линии кабельного телевидения). Там пакет хранится до тех пор, пока не будет принят целиком и не пройдет полную обработку, включая верификацию контрольной суммы. Затем он передается по цепочке маршрутизаторов, которая в итоге приводит к пункту назначения. Такой механизм называется коммутацией пакетов с промежуточным хранением (store-and-forward), и мы уже рассматривали его в предыдущих главах.

5.1.2. Службы, предоставляемые транспортному уровню

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

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

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

3. Сетевые адреса, доступные транспортному уровню, должны использовать единую систему нумерации, даже между LAN и WAN.

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

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

Из этого следует, что сетевой службе не нужно требовать установления соединения, она должна в основном состоять из примитивов SEND PACKET (отправить пакет) и RECEIVE PACKET (получить пакет). В частности, сюда нельзя включать упорядочивание пакетов и контроль потока — все равно эти действия выполнит хост. Нет смысла выполнять одну и ту же работу дважды. Такое рассуждение — пример применения сквозного принципа (end-to-end argument), оказавшего значительное влияние на формирование интернета (Зальцер и др.; Saltzer et al., 1984). Кроме того, каждый пакет должен содержать полный адрес получателя, так как передача производится независимо от предшествующих пакетов.

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

Этот спор актуален даже спустя несколько десятилетий. Когда-то самые по­пулярные сети передачи данных (например, X.25 в 1970-х годах и Frame Relay в 1980-х) представляли собой системы, ориентированные на установление соединения. Но с появлением ARPANET и на ранних этапах развития интернета сетевые уровни без установления соединения получили широкое распространение. Сегодня неизменным символом успеха является протокол IP. На его популярность не повлияло даже появление требующей соединения технологии ATM, созданной в 1980-х годах с целью заменить IP; в настоящее время ATM применяется только в отдельных случаях, тогда как IP охватывает все телефонные сети. Однако требования QoS растут, и для интернета разрабатываются инструменты, предполагающие установление соединения. Примеры таких технологий — мультипротокольная коммутация по меткам (мы рассмотрим ее в этой главе) и VLAN (см. главу 4). Обе эти технологии сейчас широко используются.

5.1.3. Реализация службы без установления соединения

Мы рассмотрели два класса служб, которые сетевой уровень может предоставлять своим пользователям. Теперь перейдем к обсуждению его устройства. Возможны два варианта в зависимости от типа службы. Если предоставляется служба без установления соединения, пакеты по отдельности передаются в сеть и их маршруты рассчитываются независимо. При этом никакой предварительной настройки не требуется. В этом случае пакеты часто называют дейтаграммами (datagrams), по аналогии с телеграммами, а сети — дейтаграммными (datagram network). При использовании службы, ориентированной на установление соединения, весь путь от маршрутизатора-отправителя до маршрутизатора-получателя должен быть определен до начала передачи. Такое соединение называется виртуальным каналом (VC, Virtual Circuit), по аналогии с физическими каналами, устанавливаемыми в традиционных телефонных сетях. Сама система называется сетью виртуального канала (virtual-circuit network). В этом разделе мы обсудим дейтаграммные сети; в следующем — сети виртуального канала.

Рассмотрим принцип работы дейтаграммных сетей. Пусть у процесса P1 (илл. 5.2) есть длинное сообщение для Р2. Он передает свое послание транспортному уровню и информирует его о том, что данные необходимо доставить процессу Р2 на хосте Н2. Код транспортного уровня выполняется на хосте Н1; более того, обычно он является частью операционной системы. Заголовок транспортного уровня вставляется в начало сообщения, и в таком виде оно передается на сетевой уровень. Как правило, это просто еще одна процедура операционной системы.

Предположим, что в нашем примере сообщение в четыре раза длиннее максимального размера пакета. Поэтому сетевой уровень должен разбить его на четыре части (1, 2, 3 и 4) и отправить их все поочередно на маршрутизатор А с использованием какого-нибудь протокола двухточечного соединения, например PPP. Здесь в игру вступает провайдер. Каждый маршрутизатор имеет свою внутреннюю таблицу, по которой он определяет дальнейший путь пакета до любого возможного пункта назначения. Каждая запись таблицы состоит из двух полей: адресат и ведущая к нему исходящая линия. Во втором поле могут использоваться только линии, непосредственно соединенные с данным маршрутизатором. Так, например, на илл. 5.2 у маршрутизатора А имеются только две исходящие линии: к В и к С. Поэтому все входящие пакеты передаются в какую-то из этих двух точек, даже если они не являются адресатами. Изначальная таблица маршрутизации А показана на илл. 5.2 с пометкой «в начале».

В маршрутизаторе A пакеты 1, 2 и 3, поступившие на вход, кратковременно сохраняются для верификации контрольной суммы. Затем в соответствии с таблицей А каждый пакет отправляется в новом фрейме по исходящему соединению на маршрутизатор С. Далее пакет 1 уходит на Е, затем — на F. После этого он передается внутри фрейма по LAN на хост Н2. Пакеты 2 и 3 следуют по тому же маршруту.

Илл. 5.2. Маршрутизация внутри дейтаграммной сети

Однако с пакетом 4 происходит нечто другое. После прибытия на А он пересылается на маршрутизатор В, несмотря на то что его адресат — F, как и у первых трех пакетов. По какой-то причине А решил отправить пакет 4 по новому пути. Может быть, в результате отправки трех пакетов на линии ACE возник затор и маршрутизатор решил обновить свою таблицу (она показана на илл. 5.2 с пометкой «в конце»). Алгоритмы, управляющие таблицами и принимающие решения о выборе маршрута, называются алгоритмами маршрутизации (routing algorithms). Им будет уделено основное внимание в этой главе. Как мы увидим, существует несколько типов таких алгоритмов.

Протокол IP, составляющий основу всего интернета, является наиболее ярким примером сетевой службы без установления соединения. Каждый пакет содержит IP-адрес назначения, по которому маршрутизатор осуществляет индивидуальную отправку пакета. В пакетах IPv4 используются адреса длиной 32 бита, а в IPv6 — 128 бит. Далее мы подробно обсудим IP и его версии.

5.1.4. Реализация службы с установлением соединения

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

В качестве примера рассмотрим ситуацию, изображенную на илл. 5.3. Хост Н1 установил соединение с хостом Н2. Это соединение запоминается и становится первой записью во всех таблицах маршрутизации. Так, первая строчка таблицы маршрутизатора А говорит о том, что если пакет с идентификатором соединения 1 пришел с хоста Н1, то его нужно направить на С с идентификатором соединения 1. Точно так же первая запись С направляет пакет на Е все с тем же идентификатором соединения 1.

Илл. 5.3. Маршрутизация в сети виртуального канала

Теперь выясним, что произойдет, если хост Н3 захочет установить соединение с Н2. Он выбирает идентификатор соединения 1 (на данный момент это первое и единственное соединение) и просит сеть установить виртуальный канал. Таким образом, в таблице появляется вторая запись. Обратите внимание, что здесь возникает конфликт: А может отличить пакеты соединения 1, пришедшие с Н1, от пакетов соединения 1, пришедших с Н3, но С такой возможности не имеет. Поэтому А присваивает новый идентификатор соединения исходящему трафику и тем самым создает второе соединение. Для предотвращения таких конфликтов маршрутизаторы получили возможность менять идентификаторы соединения в исходящих пакетах.

Одним из примеров сетевой службы, ориентированной на соединение, является мультипротокольная коммутация по меткам (MultiProtocol Label Switching, MPLS). Она используется в сетях интернет-провайдеров; при этом IP-пакеты получают MPLS-заголовок, содержащий 20-битный идентификатор соединения или метку. Если провайдер устанавливает длительное соединение для передачи крупных объемов данных, MPLS часто остается невидимым для клиентов. Однако в последнее время эта служба применяется все чаще для обеспечения необходимого уровня QoS и решения других задач, связанных с управлением трафиком на уровне провайдера. К обсуждению MPLS мы еще вернемся далее в этой главе.

5.1.5. Сравнение сетей виртуальных каналов и дейтаграммных сетей

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

Проблема

Дейтаграммы

Виртуальные каналы

Установка канала

Не требуется

Требуется

Адресация

Каждый пакет содержит полный адрес отправителя и получателя

Каждый пакет содержит короткий номер виртуального канала

Информация о состоянии

Маршрутизаторы не содержат информации о состоянии

Каждый виртуальный канал требует места в таблице маршрутизатора

Маршрутизация

Маршрут каждого пакета выбирается независимо

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

Эффект от выхода маршрутизатора из строя

Никакого, кроме потерянных пакетов

Все виртуальные каналы, проходившие через отказавший маршрутизатор, прекращают существование

QoS

Трудно реализовать

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

Борьба с перегрузкой

Трудно реализовать

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

Илл. 5.4. Сравнение виртуальных каналов и дейтаграмм

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

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

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

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

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

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