Обновлено: 14.05.2024

4.4.5 Протокол XTP

При передаче больших массивов информации последовательные пакеты нумеруются. В случае потери принимающая сторона посылает отправителю список не доставленных пакетов (TCP повторяет пересылку всех пакетов, начиная с потерянного). Именно алгоритм селективной ретрансмиссии и позволяет повысить эффективность использования канала. Длина пакетов XTP кратна 64 бит. Совокупность информации, описывающей состояние XTP, называется контекстом. Каждый контекст управляет как входящим, так и исходящим потоками данных. Два активных контекста и поток данных образуют ассоциацию. В исходном состоянии контекст оконечной системы пассивен и находится в состоянии ожидания. Первый передаваемый пакет содержит полную адресную информацию. После получения первого пакета контекст становится активным. С этого момента ассоциация сформирована и обмен может происходить в обоих направлениях. Каждый последующий пакет несет в себе ключевой код, определяющий его принадлежность к данному контексту. При завершении передачи устанавливаются соответствующие биты опций, связь разрывается, а контексты возвращаются в пассивное состояние. Все виды XTP-пакетов имеют один и тот же формат заголовков. Управление контекстом осуществляется с помощью флагов, содержащихся в заголовке. Всего предусмотрено 15 флагов.

На рис. 4.4.5.1 показана зависимость пропускной способности канала для сети ATM при использовании транспортных протоколов TCP и XTP, в обоих случая использовался в качестве базового протокол IP. Измерения производились для приложений типа FTP. Из рисунка видно, что даже 1% потерянных или поврежденных пакетов понижает пропускную способность на 30% при работе с протоколом TCP. XTP требует только три пакета, чтобы сформировать виртуальный канал, в то время как XTP требует для тех же целей семь пакетов. Благодаря своей простоте XTP может легко подменить любой транспортный протокол в любом существующем телекоммуникационном приложении. Протокол предоставляет некоторые услуги недоступные в других протоколах, что оказывается особенно привлекательным для приложений мультимедиа.

При 5% потерях пакетов XTP обеспечивает в 6 раз большую пропускную способность, чем TCP. В таблице 4.4.5.1 приведены сравнительные результаты измерения пропускной способности канала ATM (155 Мбит/с) при использовании протоколов TCP, UDP и XTP (использовались пакеты длиной 8190 байт).

Таблица 4.4.5.1. Сравнительные характеристики протоколов TCP, UDPи XTP

Название протокола	Пропускная способность в Мбит/с
TCP	89-93
UDP	93-94
XTP	112-115

Из таблицы видно, что в нормальных условиях протокол XTP гарантирует пропускную способность на 25% выше, чем TCP или UDP.

Все поля в XTP-пакетах передаются так, что наиболее значимый байт передается первым (порядок байт - "big-endian"). Формат заголовка XTP-пакета показан на рис. 4.4.5.2. Поле ключ определяет принадлежность пакета к тому или иному контексту, поле команда (CMD) задает процедуру обработки пакета. Поле длина (DLEN) определяет объем данных в пакете, а поле номер по порядку (SEQ) представляет собой порядковый номер пакета в последовательности. Поля контрольная сумма и синхронизация используются для проверки корректности доставки. Старший бит поля ключ (RTN - возврат, рис. 4.4.5.3) зарезервирован в качестве флага, указывающего на контекст передающей (=0) или принимающей стороны (принимающая сторона, посылая пакеты, ставит RTN=1). Код поля ключ должен быть уникальным. Для обеспечения этого остальная часть поля делится на два субполя: индекс и инстанция (распределение бит между ними зависит от реализации и реальных потребностей). Индекс служит для выбора контекста, а инстанция подтверждает корректность кода индекс. Так при получении пакета сначала по индексу определяется контекст, а затем производится сравнение кодов инстанции в пакете и в таблице контекстов.

Рис. 4.4.5.2 Формат кадра протокола XTP

Рис. 4.4.5.3 Структура поля ключ

32-разрядное поле команды содержит в себе субполе опции. Названия различных бит этого поля показаны на рис. 4.4.5.4.

Рис. 4.4.5.4. Формат поля команда

XTP-передатчик контролирует все биты поля опции для каждого пакета. Некоторые дополнительные данные о битах субполя опции можно найти в таблице 4.4.5.2.

Таблица 4.4.5.2. Значения битов субполя опции

"По-пакетно" означает, что бит может изменяться от пакета к пакету. "Раз на ассоциацию" означает, что все контексты ассоциации должны иметь этот бит идентичным. "Один раз" означает, что бит может быть установлен один раз за время жизни контекста

Таблица 4.4.5.3. Коды типов пакетов XTP (Pformat)

Формат пакета	Код типа	Описание
data	0	Информационный пакет пользователя
cntl	1	Пакет управления состоянием
first	2	Исходный пакет ассоциации (содержит адресный сегмент)
ecntl	3	Пакет управления (ошибка)
tcntl	5	Пакет управления трафиком
join	6	Мультикастинг-пакет включения в группу
diag	8	Диагностический пакет

Младший байт поля команда содержит субполе типа пакета (ptype). Биты 0-4 этого субполя содержат код формата пакета (Pformat, см. таблицу 4.4.5.3). Биты 5-7 определяют версию протокола (ver). Для XTP 4.0 код версии равен 001.

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

Поле Check содержит контрольную сумму. Если бит nochek=1, то в поле записана контрольная сумма только заголовка, в противном случае - всего пакета.

Поле приоритет (sort) предназначено для задания приоритета пересылаемой информации. Это поле интерпретируется лишь в случае, если бит sort=1. При sort=0 поле приоритет должно быть обнулено. Контексты с приоритетным трафиком посылают пакеты с sort=1 и с определенным кодом в поле приоритет. Бесприоритетные контексты шлют пакеты с sort=0 и нулевым полем приоритета. На приемной стороне информация доставляется в соответствии с кодом приоритета. Поле приоритет характеризуется беззнаковым 16-разрядным числом. Код приоритет, равный нулю, указывает на самый низкий приоритет, чем больше этот код, тем выше приоритет. XTP обслуживает активные контексты в соответствии с присвоенными им приоритетами. Высокоприоритетная информация посылается раньше низкоприоритетной. Аналогичный порядок обслуживания работает и на принимающей стороне.

32-битовое поле синхронизация (Sync) служит для синхронизации диалога. Каждый контекст хранит код последнего посланного значения Sync в переменной Saved_sync. Когда пакет послан с Sreq=1, значение переменной Saved_sync увеличивается на единицу и этот код заносится в поле Sync отправляемого пакета. Получатель запоминает последний полученный код Sync в контекстной переменной Rcvd_sync. Значение этой переменной записывается в поле эхо каждого посылаемого управляющего пакета. Когда управляющий пакет получен, код поля sync сравнивается со значением Rcvd_sync. Если sync і Rcvd_sync, то управляющий пакет обрабатывается нормально. В противном случае управляющий пакет содержит информацию, которая старее полученной с предыдущими пакетами, и обрабатываться не должен.

Поле номер по прядку (SEQ) характеризуется 64-разрядным числом без знака и представляет собой порядковый номер байта в передаваемом потоке. Для первого пакета (first) поле SEQ характеризует объем буферов для потока откликов, а для пакетов Join это поле содержит дентификатор получателя (ключ контекста). Join-пакет отклик на запрос содержит в поле SEQ порядковый номер байта для текущей ассоциации. Диапазон значений поля номер по порядку для информационных пакетов начинается с SEQ и простирается вплоть до SEQ+ DLEN - 1. Для DIAG пакетов поле SEQ содержит код SEQ входного пакета, который вызвал ошибку. Если посылка пакета DIAG вызвана не входным пакетом, код SEQ должен быть равен нулю.

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

Управляющие сегменты несут в себе информацию о состоянии контекста, его приславшего. XTP пакеты, содержащие управляющие сегменты называются контрольными пакетами. Управляющие сегменты содержат пакеты типа Cntl, Ecntl и Tcntl. Управляющий сегмент Cntl-пакета несет в себе информацию об управлении обменом. Ecntl-пакеты включают в себя сегменты управления ошибками, а Tcntl-пакеты - сегменты управления трафиком. Формат управляющего сегмента показан на рис. 4.4.5.5.

Рис. 4.4.5.5 Формат общего управляющего сегмента пакета XTP

Три поля общего управляющего сегмента представляют статусную информацию и содержатся во всех трех типах контрольных пакетов. Первые два поля RSEQ и alloc являются параметрами управления обменом. Поле Echo используется для идентификации контрольных пакетов, которые являются откликом на пакеты с битом SREQ=1. Поле RSEQ содержит в себе номер очередного байта, подлежащего пересылке, и определяет начало окна, управляющего обменом. Поле Alloc интерпретируется, когда разрешено управление обменом. Код поля Alloc определяет объем данных, который отправитель может послать (а получатель принять). Если бит RES=1, то поле Alloc задает размер буфера, зарезервированного для данной ассоциации. Поле Echo используется для установления соответствия между запросом статуса и контрольными пакетами. Код поля Echo равен наибольшему значению sync для полученных пакетов. Это значение хранится в контекстной переменной rcvd_sync. Когда формируется контрольный пакет, значение rcvd_sync заносится в поле Echo этого пакета.

Формат сегмента управления ошибками показан на рис. 4.4.5.6. Этот сегмент включает в себя все поля общего управляющего сегмента, дополнительно использовано только два поля Nspan и Spans, которые сообщают о том, какие пакеты потеряны.

Рис. 4.4.5.6 Формат сегмента управления ошибками

Сегмент управления ошибками используется в пакетах Ecntl. Поле Nspan определяет число Spans в Ecntl-пакете. Так как пакет Ecntl посылается только в случае потери информации, поле Nspan несет в себе код не меньше 1. Поле Spans содержит в себе Nspan пар чисел, которые характеризуют интервалы номеров байт, переданных корректно. Речь здесь идет о данных, имеющих номера больше того, который указан в поле RSEQ. На основании этих данных можно вычислить, какая именно информация потеряна.

Формат сегмента управления трафиком показан на рис. 4.4.5.7. Помимо полей общего управляющего сегмента здесь присутствуют поля RSVD и XKEY, а также спецификация трафика. Поле RSVD является резервным и должно содержать нуль. Поле XKEY является обязательной принадлежностью всех Tcntl-пакетов, величина этого поля должна равняться значению ключа для контекста, посылающего пакет (бит RTN=1). Спецификация трафика используется в пакетах типа first и Tcnnl. Пакет first предлагает параметры режима обмена, а Tcntl несет в себе отклик на это предложение.

Рис. 4.4.5.7 Формат сегмента управления трафиком

Поле tlen определяет длину спецификации трафика, включая 4-байтовый дескриптор (tlen і ). Поле service используется для задания типа транспортного сервиса на фазе установления режима обмена. Коды доступных видов сервиса представлены в таблице 4.4.5.4. Эта информация передается в пакете типа first.

Таблица 4.4.5.4. Коды поля тип сервиса (service)

Код типа сервиса	Описание
0x00	Не специфицировано
0x01	Традиционная передача дейтограмм без подтверждения
0x02	Передача дейтограмм с подтверждением
0x03	Реализация транзакций
0x04	Традиционная передача потока данных с гарантированной доставкой
0x05	Передача потока данных в мультикастинг-режиме без подтверждения
0x06	Мультикастинг режим передачи потока данных с гарантированной доставкой

Поле tformat определяет формат поля traffic. Код tformat=0 используется тогда, когда не нужно ни какой спецификации трафика, в 4-байтовое поле traffic в этом случае записываются нули. В противном случае используется код tformat=0x01. Формат поля traffic для этого арианта показан на рис. 4.4.5.8.

Рис. 4.4.5.8 Формат поля traffic

Поле maxdata несет в себе код максимального размера информационного сегмента, который отправитель может послать за время жизни ассоциации. Поля inrate и inburst представляют собой параметры, определяющие входной поток данных. Поля outrate и outburst являются параметрами, задающими выходной поток данных.

Информационный сегмент включает в себя пользовательскую и другую протокольную и диагностическую информацию. XTP-пакеты, содержащие информационный сегмент, называются информационными пакетами. К их числу относятся пакеты типа data, first, join и diag. Информационные пакеты могут включать в себя сегмент данных, адресный сегмент, спецификатор трафика и диагностический сегмент. Формат полей адресного сегмента показан на рис. 4.4.5.9.

Рис. 4.4.5.9 Формат полей адресного сегмента

Адресный сегмент используется в пакетах типа first и join. Протокол XTP использует параметрическую схему адресации, возможны несколько форматов адресов отправителя и места назначения. Поле Alen определяет полную длину адресного сегмента. Поле Adomain представляет собой адресный демультиплексор, допуская работу с несколькими адресными доменами. Поле Adomain используется в частности для того, чтобы обеспечить совместимость с протоколами UDP и TCP (для TCP Adomain=6, для UDP 17, а для XTP 36). Поле Aformat идентифицирует адресный синтаксис в соответствии с таблицей 4.4.5.5.

Таблица 4.4.5.5. Значения кодов поля Aformat

Код поля aformat	Синтаксис адреса
0x00	Нулевой адрес
0x01	ip-адрес
0x02	ISO адрес протокольного сетевого уровня для передачи без установления связи
0x03	Адрес сети Ксерокс
0x04	IPX-адрес
0x05	Локальный адрес
0x06	IP-адрес версии 6

Поле адрес несет в себе адреса отправителя и получателя пакетов, форматы которых заданы полем Aformat.

Формат полей сегмента данных показан на рис. 4.4.5.10. Эти сегменты предназначены для применения на прикладных пользовательских уровнях и программами поддержки протокола XTP не интерпретируются. Сегмент включается в пакеты типа first и data.

Рис. 4.4.5.10 Формат полей сегмента данных

Размер поля Data имеет произвольное значение, первые 8 байт (поле Btag) представляют собой специальную метку (если бит опций заголовка btag=1). При Btag=0 метка отсутствует. Интерпретация поля Btag осуществляется исключительно прикладной программой и для XTP его значение безразлично.

Формат полей диагностического сегмента показан на рис. 4.4.5.11. Этот сегмент используется пакетами типа DIAG для информирования протокольной или прикладной программы о случаях ошибок. Поле Code определяет тип и категорию ошибки, вызвавшей отправку пакета типа DIAG. Поле val позволяет уточнить причину ошибки. Поле message является опционным и может иметь произвольную длину. Обычно это поле содержит текстовую интерпретацию полей Code и VAL.

На этом уровне есть два протокола, протокол UDP, который уже рассматривали и протокол TCP, который является одним из основных протоколов стека TCP/IP и интернет.

p, blockquote 3,0,0,0,0 -->

p, blockquote 4,0,0,0,0 -->

p, blockquote 5,0,0,0,0 -->

Поток байт

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

p, blockquote 6,0,0,0,0 -->

p, blockquote 7,0,0,0,0 -->

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

p, blockquote 8,0,0,0,0 -->

Гарантия доставки: подтверждение получения

p, blockquote 9,0,0,0,0 -->

p, blockquote 10,0,0,0,0 -->

Гарантия доставки: повторная отправка

p, blockquote 11,0,0,0,0 -->

p, blockquote 12,0,0,0,0 -->

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

p, blockquote 13,0,0,0,0 -->

p, blockquote 14,0,1,0,0 -->

Протокол TCP: скользящее окно

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

p, blockquote 15,0,0,0,0 -->

• Остановка и ожидание (Wi-Fi, канальный уровень)
• Скользящее окно (TCP, транспортный уровень)

Варианты подтверждения доставки

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

p, blockquote 17,0,0,0,0 -->

p, blockquote 18,0,0,0,0 -->

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

p, blockquote 19,0,0,0,0 -->

p, blockquote 20,0,0,0,0 -->

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

p, blockquote 21,0,0,0,0 -->

Пример подтверждения доставки

Рассмотрим на примере работу сети.

Скользящее окно

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

p, blockquote 23,0,0,0,0 -->

p, blockquote 24,0,0,0,0 -->

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

p, blockquote 26,0,0,0,0 -->

p, blockquote 27,0,0,0,0 -->

Тип подтверждения

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

• Кумулятивное подтверждение, говорит о том что получен указанный байт данных и все предыдущие. Такой подход используется в TCP по умолчанию. Сейчас из-за того что распространились высокоскоростные каналы связи большой протяженности, размер окна в TCP может быть увеличен до 1 гигабайта. Представьте, что вы передали гигабайт данных и у вас потерялся всего лишь один сегмент, который находится в середине. С помощью кумулятивного подтверждения вы можете подтвердить получение только первых 500 мегабайт, получится что вам придётся повторно передавать 500 мегабайт данных, которые уже есть у получателя.

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

p, blockquote 29,0,0,0,0 -->

p, blockquote 30,0,0,0,0 -->

p, blockquote 31,0,0,0,0 -->

Дублирование сегментов

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

p, blockquote 32,0,0,0,0 -->

p, blockquote 33,0,0,0,0 -->

p, blockquote 34,0,0,0,0 -->

p, blockquote 35,0,0,0,0 -->

p, blockquote 36,0,0,0,0 -->

В нашем примере 4 сегмента первый сегмент содержит байты от 0 до 1023, второй от 1024 до 2047 и так далее.

p, blockquote 37,0,0,0,0 -->

Нумерация байтов

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

p, blockquote 38,0,0,0,0 -->

• Например сегмент данных, байт 0, он содержит байты с 0 до 1023.
• Получатель отправляет подтверждение и в подтверждение включает номер следующего байта, который ожидается байт 1024.
• Отправитель передает следующий сегмент, включая в него номер первого байта, сегмент данных, номер первого байта 1024 содержит данные до номера байта 2047.
• Получатель отправляет подтверждение, что он ждет байт с номером 2048, если сегменты придут в неправильном порядке, то получатель по номерам байтов всегда сможет выставить их в правильной последовательности.

Дублирование сегментов

Рассмотрим как решается ситуация с дублированием сегментов.

p, blockquote 40,0,0,0,0 -->

• Отправитель включает в сегмент номер первого передаваемого байта 1024.
• Получатель отправляет подтверждение, где говорит что ждет байт в 2048.
• Но так как подтверждение не дошло, то отправитель передает тот же самый сегмент 1024.
• Однако получатель видит, что этот сегмент у него уже есть поэтому он этот сегмент игнорирует и снова отправляет подтверждение, где говорит что он ожидает байт 2048.

Соединение TCP

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

p, blockquote 42,0,0,1,0 -->

Задачи соединения

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

Установка соединения в TCP

p, blockquote 43,0,0,0,0 -->

p, blockquote 44,0,0,0,0 -->

p, blockquote 45,0,0,0,0 -->

p, blockquote 46,0,0,0,0 -->

Разрыв соединения в TCP

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

p, blockquote 47,0,0,0,0 -->

p, blockquote 48,0,0,0,0 -->

p, blockquote 49,0,0,0,0 -->

p, blockquote 50,0,0,0,0 -->

p, blockquote 51,0,0,0,0 -->

Заключение

p, blockquote 52,0,0,0,0 -->

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

p, blockquote 53,0,0,0,0 -->

p, blockquote 54,0,0,0,0 -->

p, blockquote 55,0,0,0,0 --> p, blockquote 56,0,0,0,1 -->

1. Лекция - Введение. Адресация. Протоколы (IP, TCP, UDP). Порты.

Официальная документация по Internet

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

Адресация в сети Internet.

Типы адресов.

Физический (MAC-адрес)

Сетевой (IP-адрес)

Символьный (DNS-имя)

Компьютер в сети TCP/IP может иметь адреса трех уровней (но не менее двух):

Локальный адрес компьютера. Для узлов, входящих в локальные сети - это МАС-адрес сетевого адаптера. Эти адреса назначаются производителями оборудования и являются уникальными адресами.

IP-адрес, состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов.

IPv4 - адрес является уникальным 32-битным идентификатором IP-интерфейса в Интернет.

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

10100000010100010000010110000011
записывается как

Перевод адреса из двоичной системы в десятичную

IP-адрес хоста состоит из номера IP-сети, который занимает старшую область адреса, и номера хоста в этой сети, который занимает младшую часть.

160.81.5. - номер сети

131 - номер хоста

Базовые протоколы (IP, TCP, UDP)

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

TCP/IP - собирательное название для набора (стека) сетевых протоколов разных уровней, используемых в Интернет. Особенности TCP/IP:

Открытые стандарты протоколов, разрабатываемые независимо от программного и аппаратного обеспечения;

Независимость от физической среды передачи;

Система уникальной адресации;

Стандартизованные протоколы высокого уровня для распространенных пользовательских сервисов.

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

Стек протоколов TCP/IP делится на 4 уровня:

Физический и канальный.

Позже была принята 7-ми уровневая модель ISO.

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

Пример инкапсуляции пакетов в стеке TCP/IP

Физический и канальный уровень.

Стек TCP/IP не подразумевает использования каких-либо определенных протоколов уровня доступа к среде передачи и физических сред передачи данных. От уровня доступа к среде передачи требуется наличие интерфейса с модулем IP, обеспечивающего передачу IP-пакетов. Также требуется обеспечить преобразование IP-адреса узла сети, на который передается IP-пакет, в MAC-адрес. Часто в качестве уровня доступа к среде передачи могут выступать целые протокольные стеки, тогда говорят об IP поверх ATM, IP поверх IPX, IP поверх X.25 и т.п.

Межсетевой уровень и протокол IP.

Основу этого уровня составляет IP-протокол.

IP (Internet Protocol) – интернет протокол.

Первый стандарт IPv4 определен в RFC-760 (DoD standard Internet Protocol J. Postel Jan-01-1980)

Последняя версия IPv4 - RFC-791 (Internet Protocol J. Postel Sep-01-1981).

Первый стандарт IPv6 определен в RFC-1883 (Internet Protocol, Version 6 (IPv6) Specification S. Deering, R. Hinden December 1995)

Последняя версия IPv6 - RFC-2460 (Internet Protocol, Version 6 (IPv6) Specification S. Deering, R. Hinden December 1998).

Протокол IP доставляет блоки данных от одного IP-адреса к другому.

Программа, реализующая функции того или иного протокола, часто называется модулем, например, “IP-модуль”, “модуль TCP”.

Когда модуль IP получает IP-пакет с нижнего уровня, он проверяет IP-адрес назначения.

Если IP-пакет адресован данному компьютеру, то данные из него передаются на обработку модулю вышестоящего уровня (какому конкретно - указано в заголовке IP-пакета).

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

Структура дейтограммы IP. Слова по 32 бита.

Версия - версия протокола IP (например, 4 или 6)

Длина заг. - длина заголовка IP-пакета.

Тип сервиса (TOS - type of service) - Тип сервиса (подробнее рассмотрен в лекции 8).

TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует запрашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP).

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

Время жизни (TTL - time to live) - каждый маршрутизатор уменьшает его на 1, что бы пакеты не блуждали вечно.

Протокол - Идентификатор протокола верхнего уровня указывает, какому протоколу верхнего уровня принадлежит пакет (например: TCP, UDP).

Коды некоторые протоколов RFC-1700 (1994)

Протокол IP является маршрутизируемый, для его маршрутизации нужна маршрутная информация.

Маршрутная информация, может быть:

Статической (маршрутные таблицы прописываются вручную)

Динамической (маршрутную информацию распространяют специальные протоколы)

Протоколы динамической маршрутизации:

RIP (Routing Information Protocol) - протокол передачи маршрутной информации, маршрутизаторы динамически создают маршрутные таблицы.

OSPF (Open Shortest Path First) - протокол "Открой кротчайший путь первым", является внутренним протоколом маршрутизации.

IGP (Interior Gateway Protocols) - внутренние протоколы маршрутизации, распространяет маршрутную информацию внутри одной автономной системе.

EGP (Exterior Gateway Protocols) - внешние протоколы маршрутизации, распространяет маршрутную информацию между автономными системами.

BGP (Border Gateway Protocol) - протокол граничных маршрутизаторов.

Другие служебные IP-протоколы

IGMP (Internet Group Management Protocol) - позволяет организовать многоадресную рассылку средствами IP.

RSVP (Resource Reservation Protocol) - протокол резервирования ресурсов.

ARP (Address Resolution Protocol) - протокол преобразования IP-адреса и адреса канального уровня.

Транспортный уровень

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

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

На транспортном уровне работают два основных протокола: UDP и TCP.

Первая и последняя версия TCP - RFC-793 (Transmission Control Protocol J. Postel Sep-01-1981).

Посылает запрос на следующий пакет, указывая его номер в поле "Номер подтверждения" (AS). Тем самым, подтверждая получение предыдущего пакета.

Делает проверку целостности данных, если пакет битый посылает повторный запрос.

Структура дейтограммы TCP. Слова по 32 бита.

Длина заголовка - задается словами по 32бита.

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

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

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

URG - флаг срочности, включает поле "Указатель срочности", если =0 то поле игнорируется.

ACK - флаг подтверждение, включает поле "Номер подтверждения, если =0 то поле игнорируется.

PSH - флаг требует выполнения операции push, модуль TCP должен срочно передать пакет программе.

RST - флаг прерывания соединения, используется для отказа в соединении

SYN - флаг синхронизация порядковых номеров, используется при установлении соединения.

FIN - флаг окончание передачи со стороны отправителя

UDP (Universal Datagram Protocol) - универсальный протокол передачи данных, более облегченный транспортный протокол, чем TCP.

Основные отличия от TCP:

Отсутствует соединение между модулями UDP.

При потере пакета запрос для повторной передачи не посылается

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

Структура дейтограммы UDP. Слова по 32 бита.

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

Протокол реального времени RTP

RTP (Real Time Protocol) - транспортный протокол для приложений реального времени.

RTCP (Real Time Control Protocol) - транспортный протокол обратной связи для приложения RTP..

Назначение портов

По номеру порта транспортные протоколы определяют, какому приложению передать содержимое пакетов.

Порты могут принимать значение от 0-65535 (два байта 2^16).

Некоторые заданные порты RFC-1700 (1994)

Программа Ping

Программа для проверки соединения и работы с удаленным хостом.

Программа TraceRoute - позволяет проверить маршрут до удаленного хоста.

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

Разберем, что такое сетевой протокол OSPF для чайников.

Принцип работы OSPF

Работа протокола OSPF строится по следующему алгоритму:

1. Маршрутизаторы производят обмен малыми пакетами HELLO.
2. После выполнения обмена между ними устанавливаются соседства. Каждый из маршрутизаторов добавляет в специальную локальную таблицу соседей.
3. Маршрутизаторы выполняют сбор состояний своих связей с соседями (линков). Линки включают id самого маршрутизатора и соседа, сеть и префикс, тип сети и метрику (стоимость линка). После сбора состояний маршрутизатор формирует пакет LSA (Link State Advertisement).
4. LSA рассылается каждому соседу, который передает пакет дальше по сети.
5. После получения пакета LSA каждый маршрутизатор добавляет содержащуюся в нем информацию в локальную таблицу LSDB (Link State Database).
6. В таблице LSDB накапливаются данные обо всех парах маршрутизаторов в пределах сети.
7. На основании накопленных данных выстраивается полная карта сети, которая включает все действующие маршрутизаторы и образованные между ними связи.
8. Используя карту, каждый маршрутизатор выполняет поиск самых коротких маршрутов во все сети и формирует из них таблицу маршрутизации.

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

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

Пакет OSPF помещается в пакет IP с мультикастовым адресом получателя. Отправителю же в нем соответствует адрес маршрутизатора. Пакет помещается в мультикастовый фрейм, например, в Ethernet. При формировании списков контроля доступа нужно учитывать, что OSPF инкапсулируется непосредственно в IP, а не в UDP или TCP.

Hello пакеты отправляются с установленной периодичностью. По умолчанию она составляет 1 раз в 10 секунд для сетей BMA и point-to-point и 1 раз в 40 секунд для сетей NBMA. Также существует понятие Dead-интервала, который по умолчанию равняется 4 Hello-интервалам. Если в течение этого периода маршрутизатор не получает ни одного пакета, то он считает, что сосед отключился. За этим следует пересчет и обновление таблицы маршрутизаторы.

ID маршрутизатора в OSPF

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

Идентификатор записывается в виде IP-адреса IPv4. Неважно, какое он примет значение, главное, чтобы он был уникальным в пределах этой сети. ID маршрутизатора в OSPF можно задать вручную. Если он не задан, то будет присвоен автоматически.

Принцип работы протокола OSPF предусматривает следующий алгоритм назначения ID маршрутизатора:

1. В случае явного задания идентификатора командой router-id, используется назначенный вручную ID.
2. В случае если не было ввода router-id, присваивается больший адрес из настроенных на маршрутизаторе loopback интерфейсов.
3. При отсутствии loopback интерфейсов принимается больший адрес из всех включенных на маршрутизаторе интерфейсов.

Для определения большего адреса используется прямое сравнение по октетам слева направо.

Работа OSPF в сетях с множественным доступом

Решение этой проблемы достигается посредством механизма выбора Designated Router (DR) и Backup Designated Router (BDR), которые представляют собой роли маршрутизаторов. В сети с множественным доступом, к которой подключены более 2 маршрутизаторов, один из них назначается на роль DR, а второй — на роль BDR. При отправке любым маршрутизатором какого-либо пакета, он поступает не всем устройства в сети, а подается на отдельный мультикастовый адрес, доступный только DR и BDR. В свою очередь, DR рассылает пакет всем маршрутизаторам в сети. Такое посредничество значительно снижает нагрузку. BDR выполняет резервную функцию и моментально принимает роль DR при его отключении. После этого среди остальных маршрутизаторов сразу выбирается новый BDR.

Метрика в OSPF

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

Например, Cisco применяет два варианта расчета стоимости.

В первом случае стоимость линка рассчитывается как обратная величина от его скорости (1000 — для 1 Мбит, 100 — для 10 Мбит, 10 — для 100 Мбит, 1 — для 1 Гбита и т. д.). Этот вариант подойдет при условии, что все маршрутизаторы будут считать стоимость по данному алгоритму, аэто требует использование только устройств Cisco.

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

Типы маршрутизаторов OSPF

Принцип действия протокола OSPF предусматривает использование следующих типов маршрутизаторов:

• IR (Internal Router) — это внутренний маршрутизатор, у которого все интерфейсы ассоциированы только с одной определенной областью.
• ABR (Area Border Router) — устанавливается в нулевой зоне для обеспечения связи с другими зонами.
• ASBR (Autonomous System Boundary Router) — обеспечивает объединение автономных систем для обмена маршрутами.

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

Читайте также:

  
• Примут ли исковое заявление без оплаты госпошлины
  
• Как заключить договор с программистом
  
• Справка млс что это
  
• Как оформить представление по акту проверки
  
• Если не заключен договор на вывоз мусора а заставляют платить с частного дома что делать