Протоколы

9.1. Cетевая модель TCP/IP

Каждый из протокольных блоков (PDU) трафика мультисервисных сетей выполняет одну или несколько функций, предусмотренных семиуровневой моделью ЭМВОС (OSI).

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

Обширная коллекция сетевых протоколов и служб, называемая TCP/IP, включает намного больше, чем просто сочетание двух основных протоколов, давших ей имя. Тем не менее, эти протоколы заслуживают первоначального представления: протокол управления передачей (Transmission Control Protocol, TCP) обеспечивает надежную доставку сообщений произвольного размера и определяет сложный механизм доставки для всех видов данных в сети; протокол Internet (Internet Protocol, IP) организует маршрутизацию сетевых передач от отправителя к получателю, отвечает за сетевые и компьютерные адреса и выполняет множество других функций. Вместе взятые, эти протоколы передают значительную часть данных, циркулирующих в мультисервисных сетях, хотя представляют собой лишь крошечную долю от всей совокупности протоколов TCP/IP.

Так как архитектура TCP/IP была разработана за долго до становления в 1980 – х годах эталонной модели взаимодействия открытых систем (OSI), неудивительно, что конструктивная модель TCP/IP несколько отличается от эталонной модели OSI. В таблице 10.1. изброжены уровни двух моделей OSI и более простой TCP/IP; так же устанавливается их соответствие уровням. Эти комплекты уровней похожи, но не идентичны. Причиной этого является то, что некоторые функции, связываемые с Сеансовым и Уровнем представления эталонной модели взаимодействия открытых систем, заключены в Прикладном уровне TCP/IP; с другой стороны, некоторые аспекты Сеансового уровня первой модели присутствуют в Транспортном уровне второй.

Таблица 7.

Уровни согласно модели OSI	Уровни стека TCP/IP
	приклад ной	HTTP	FTP	Telnet	SMTP	SNMP	DNS	TFTP	прикладной
	представительный
	сеансовый
	транспортный	TCP	UDP	транспортный
	сетевой	IP(ICMP, ARP, RARP, RIP, OSPF)	межсетевой
	канальный	Ethernet, Token Ring, FDDI, ATM, MPLS, RPR, SONET/SDH, PPP…	Сетевого доступа интерфейса
	физический

9.2. Уровень доступа к сети

Уровень доступа к сети модели TCP/IP иногда называют сетевым интерфейсом. На этом уровне задействованы технологии локальных сетей (LAN), в частности, Ethernet, технология АТМ, Х.25, беспроводные среды и устройства.

На уровне доступа к сети применяются сетевые стандарты Института инженеров по электротехнике и электронике (Institute of Electrical and Electronics, Engineers, IEEE). В их числе – семейство стандартов IEEE 802, включающее, помимо прочих, следующие заслуживающие внимания компоненты:

• 802.1 по межсетевому обмену – общее описание функционирование межсетевого обмена (т.е. обмена данными между различными физическими сетями) для всего семейства стандартов 802;

• 802.2 по управлению логическим соединением LLC (Logical Link Control) – общее описание установки и поддержки логического соединения между двумя устройствами в пределах одной физической сети;

• 802.2 по управлению доступом к среде MAC (Media Access Control) – общее описание идентификации и получения доступа к интерфейсам сред передачи; включает схему создания уникальных адресов уровней управления доступом к среде (МАС) для всех интерфейсов сред;

• 802.3 по множественному доступу с контролем несущей и обнаружением конфликтов CSMA/CD (Carrier Sense Multiple Access with Collision Detection). CSMA/CD – это обозначение функционирования и поведения сетевой технологии, более известной как Ethernet. Это семейство также включает Gigabit Ethernet (802.3 z) вместе с двумя разновидностями по скорости – 10 и 100 Мбит/с, хотя стандарт 802.12 называется «Высокоскоростная работа в сети».

Согласно модели IEEE уровень звена данных делится на два подуровня: управление логическим каналом и управлением доступом к среде (УДС).

Верхний подуровень LLC (Logical Link Control) осуществляет управление процессом передачи информации на логическом уровне.

Нижний подуровень MAC (Medium Access Control) алгоритмы доступа к среде и адресацию станций. На этот подуровень возлагается функция совместного использования среды, определяющая особенности доступа к среде.

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

9.2.1. Управление логическим каналом

на подуровне LLC (УЛК)

В специфику протоколов на подуровне LLC следующие особенности:

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

2. функция обеспечения достоверности передаваемой информации снята с подуровняLLC и передана подуровню МАС.

3. в отличие от HDLC глобальных сетей в ЛВС используются двух адресные протоколы (отправителя и получателя).

4. в LLC передача данных на уровень МАС еще не означает его реальную отправку на другую станцию ЛВС, так как протокольный блок данных (ПДФ) буферизируется перед получением доступа к физической среде.

Формат протокольного блока (кадра) на уровне УЛК (LLC) представлен на рис. 9.1.

Рис. 9.1 формат кадра на уровне УЛК.

Каждый протокольный блок данных (ПБД) содержит два адреса к ТДУ: адрес получателя (ТДУП) и адрес отправителя (ТДУО) (обычно это объекты внутри станции). Адреса этих станций распознаются в подуровне УДС (МАС) (рис. 9.2).

Рис. 9.2

Рис. 9.2 форматы полей ТДУП и ТДУО.

Здесь: И/Г – бит «индивидуальный/групповой адрес»,

К/О – бит, означающий, что кадр является командой или ответом.

Поля адресов в ТДУП и ТДУО имеют по 8 бит. Индивидуальному адресу получателя соответствует И/Г=0; групповому - И/Г=1.

Код адреса ТДУП – 11111111 – означает адресацию всем ТДУ станции. Адрес ТДУО всегда индивидуален. Разряд К/О служит для распознания команд (К/О=0) и ответов (К/О=1).

Все кадры по характеру передаваемых данных и своему назначению подразделяются на:

- ПБДИ – информационные;

- ПБДУ – управляющие;

- ПБДН – ненумерованные.

Форматы полей управления кадров подуровня УЛК представлены на рис. 9.3.

Рис. 9.3 Форматы полей управления кадров УЛК.

ПБДИ обязательно содержит поле информации. Формат поля управления обязательно имеет первый разряд – 0 и содержит два адреса N(s) и N(r).

ПБДУ и ПБДН содержат первый разряд, равный 1. второй разряд для ПБДУ – 0; для ПБДН – 1.

Y – разряды, модифицирующие ПБДУ;

00 – готов к приему - RR;

01 – неприем – RRJ;

10 – не готов к приему – NR;

Х – резервные (всегда равны нулю).

Значения N(s) и N(r) устанавливаются по модулю 128 (от 0 до 127).

N(r) – подтверждает получение всех кадров с номерами N(r) – 1 и всех предшествующих этому номеру. Число N(r) показывает, что получатель ожидает кадр с номером N(r).

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

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

Бит З/П (запрос передачи/последний кадр) в ПБД, содержащих команды (К/О=0), трактируется как «Запрос передачи», а в ПБД содержащих ответы (К/О=1), трактируется как последний кадр в цепочке ответов.

Биты М в ПБДН модифицируют ПБДН (различные команды и ответы).

9.2.2. Управление на подуровне доступа к среде УДС (МАС)

Формат кадра подуровня УДС предусматривает 8 полей, показанных на рис. 9.4.

Рис. 9.4 Поля кадра подуровня УДС

ПМБ – преамбула

НО – начальный ограничитель

АП, АО – адрес получателя и отправителя

ДК – указатель длины кадра данных (УЛК)

ЗАП – заполнитель

КПК – контрольная последовательность кадра

• поле преамбулы имеет вид 10101010

• поле НО имеет вид 10101011 и означает начало кадра

• адрес получателя:

- 1-й бит=0 – индивидуальный

- 1-й бит=1 – групповой (группа станций, все станции, ни одной станции)

- 2-й бит=0 – локальный адрес (2 байт)

- 2-й бит=1 – глобальный адрес (6 байт)

При широковещательной адресации – все биты устанавливаются в единицу.

• Адрес отправителя всегда индивидуален, поэтому первый бит всегда =0

Поле ДК указывает число октет, содержащихся в поле УЛК.

Поле ЗАП – дополняет поле УЛК до минимального значения.

Поле КПК – дает циклическую проверку всех полей посредством полинома 9.1:

(9.1)

Непосредственная связь подуровня УДС с физическим уровнем доступа осуществляется кадрами, передаваемыми через интерфейс ИМС, показанными на рис. 9.5.

Рис. 9.5 Кадры на уровне интерфейса ИНС.

МОЛЧ – молчание

ПМБ – преамбула

НО – начальный ограничитель

КО – конечный ограничитель

ПМБ – 101010…10 – не менее 56 битовых интервалов

НО – 10101011

КО – передаются сигналом «пусто»

Наличие несущей обнаруживается по переходам сигнала. Если переходы не обнаруживаются в течение 0.75 …. 1.25 битовых интервала, отсчитываемого от центра последнего интервала, то несущая считается отсутствующей.

В последнее время получают распространение стандарты, предусматривающие передачу со скоростями, превышающими 10 Гбит/с.

Наиболее важные протоколы Уровня доступа к сети модели TCP/IP – протоколы SLIP и PPP. SLIP – это более старый протокол, не содержащий встроенных возможностей по безопасности.

PPP- это более современный протокол для последовательного канала, широко применяемый для соединений в сети Internet и в частных сетях TCP/IP. Он нейтрален по отношению к другим протоколам и может задействовать протоколы несколько типов одновременно в течении одного соединения по последовательному каналу. Реализация протокола PPP в системах Windows обеспечивает в пределах одного соединения поддержку всех основных Windows – протоколов.

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

Особое место в мультисервисных сетях принадлежит трафику, относящемуся к технологиям АТМ и MPLS. обе технологии используют принцип коммутации по меткам. Технология АТМ предусматривает дробление пакетов любого вида на небольшие ячейки, размером 53 байта с последующей коммутацией ячеек, в соответствии с имеющимися в их заголовках метками. В последние годы особое развитие получила технология MPLS. В основе технологии лежит возможность создания виртуальных маршрутов (тоннелей) к пунктам следования информационных потоков. Тоннели создаются программным путем и применяются для переноса агрегированного трафика, имеющего общий пункт назначения. Одной из характеристик, которая в лучшею сторону отличает MPLS от подобных ей технологий коммутации меток, в частности, от АТМ, является возможность MPLS передавать вместе с пакетом не одну метку, а целый стек меток. Это позволяет создать иерархию потоков в сети MPLS и организовать тоннельные передачи. Причем в сети MPLS можно создать тоннели и осуществлять управление трафиком в каком-то сегменте сети, а не от точек входа в сеть и выхода из нее, как того требуют традиционные средства образования тоннелей. Важной областью применения MPLS является строительство виртуальных сетей. Узлы, не имеющие прямых связей, в виртуальной сети могут рассматриваться как связанные тоннелями с заданными скоростями передачи. Если необходимо провести разделение потоков в соответствии с уровнем обслуживания, то можно построить соответствующее число параллельных виртуальных сетей.

9.3. Протоколы межсетевого уровня

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

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

• Адресация (Addressing).Здесь определяется механизм, посредством которого все сетевые интерфейсы в сети TCP/IP должны быть поставлены в соответствие с конкретными уникальными битовыми комбинациями, идентифицирующими каждый интерфейс в отдельности, а также сети (или даже культурные и языковые окружения сетей),к которым эти интерфейсы принадлежат.

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

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

Среди важнейших протоколов, функционирующих на Межсетевом уровне модели TCP/IP, есть следующие:

• IP (Internet Protocol, протокол Internet) направляет пакеты от отправителя к получателю;

• ICMP (Internet Control, Message Protocol, протокол контроля сообщений в сети Internet) контролирует маршрутизацию на основе протокола IP и поведение сети;

• PING (Packet Internetwork Grouper, отправитель пакетов Internet) проверяет доступность и период кругового обращения между IP-адресами отправители и получателя;

• ARP(Address Resolution Protocol,протокол разрешения адресов) осуществляется преобразование IP-адресов в MAC – адреса (Media Access Control Address, адреса управления доступном к среде) в определённом сегменте кабеля (всегда применяемого для осуществления финального этапа доставки пакета);

• RARP(Reverse Address Resolution Protocol, протокол определения адреса по местоположению) преобразует MAC-адреса в числовые IP-адреса;

• BOOTP(Bootstrap Protocol, протокол загрузки) –это предшественник

• DHCP (Dynamic Host Configuration Protocol, протокола динамической конфигурации хоста), управляющего сетевым размещением IP-адресов и другими данными, связанными с IP-конфигурацией. Протокол BOOTP позволяет сетевым устройствам получать загрузочные и конфигурационные данные по сети, а не с локального дисковода;

• RIP(Routing Information Protocol, протокол маршрутной информации) – это оригинальный базовый протокол маршрутизации для областей маршрутизации локальных или внутренних областей объединенных сетей;

• OSPF(Open Shortest Path First, первоочередное открытие кратчайших маршрутов) –это широко распространенный протокол маршрутизации состояния канала для локальных или внутренних областей маршрутизации локальных объединенных сетей;

• BGP (Border Gateway Protocol, пограничный межсетевой протокол) – это широко распространенный протокол маршрутизации, осуществляющий соединение с обычными магистралями сети Internet или с другими маршрутными доменами в этой сети, где многочисленные стороны совместно несут ответственность за формирование трафика.

9.3.1. Протокол IP

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

- определение пакта, который является базовым понятием и единицей передачи данных в сети Internet;

- определение адресной схемы, которая используется в сети Internet;

- передача данных между канальным уровнем (уровнем доступа к сети) и транспортным уровнем (другими словами мультиплексирование транспортных дейтаграмм во фреймы канального уровня)

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

- «нарезка» и сборка из фрагментов пакетов транспортного уровня.

Главными особенностями протокола IP является отсутствие ориентации на физическое или виртуальное соединение. Это значит, что прежде чем послать пакет в сеть, модуль операционной системы, реализующий IP, не проверяет возможность установки соединения, т.е. никакой управляющей информации кроме той, что содержится в самом IP – пакете, по сети не передается. Кроме этого, IP не заботится о проверке целостности информации в поле данных пакета, что заставляет отнести его к протоколам ненадежной доставки. Целостность данных проверяется протоколами транспортного уровня (TCP) или протоколами приложений.

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

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

Структура IP-заголовка версии IPv4 и его поля представлены на рисунке 9.6.

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

Поле «длина заголовка» (HL – Internet Header Length,4 бита) содержит длину заголовка IP-пакета в 32-разрядных словах. Значение этого поля не может быть меньше 5.

Рис. 9.6 Заголовок IP версии IPv4

В поле «тип обслуживания» (TOS – Type of Service, 8 битов) указывается требуемое качество обслуживания данных. В других протоколах аналогичное поле часто называют полем QoS (качество обслуживания). Поле содержит четыре параметра, несущих информацию о приоритете дейтаграммы, о возможности поступления последовательности таких дейтаграмм с регулярными интервалами, о допустимости ошибок, о важности скорости доставки дейтаграммы и, наконец, об относительной важности скорости по сравнению с надёжностью на случай конфликта между двумя этими партнёрами. Введены следующие обозначения: PPP – приоритет, D – атрибуты задержки, T – атрибуты пропускной способности, R – атрибуты надёжности. Трехбитовый код PPP указывает уровень приоритета блока данных, применяемый для управления при перегрузке (блоки данных с меньшим приоритетом могут быть отброшены, а обработка блока данных с более высоким приоритетом разрешается) и для управления потоком. Поле задержки D указывает, какова допустимая задержка при передаче пакета. Оно может принимать два значения – нормальная задержка и малая задержка. Значение 1 соответствует малой задержке. Поле пропускной способности Т указывает, какова должна быть пропускная способность средств доставки блока данных. Например, если блок данных генерируется приложением реального времени (таким как интерактивная игра), это приложение может запросить ускоренную доставку блока, что требует более высокой пропускной способности средств доставки. Допустимые значения – нормальная или высокая пропускная способность. Поле надежности R используется аналогичным образом, указывая, требует ли этот блок данных высокой или обычной надежности обслуживания.

Поле «общая длина» (Total Length, 16 битов), аналогичное полю длины TCP – заголовка, содержит измеряемую в битах суммарную длину дейтаграммы, включая длину IP - заголовка и данных. Этот параметрам позволяет узлам определить длину поля данных путем вычитания из его значения длины заголовка. Максимальная допустимая длина всей дейтаграммы целиком, считая буквы, входящие в заголовок дейтаграммы и данные, составляет 65535 байтов, т.е. длина дейтограммы может достигать байтов. Однако длинные дейтограммы при работе IP – протокола не используются. Все хосты и шлюзы сети, как правило, работают с длинами до 576 байтов. Число 576 выбрано из тех соображений, что этой длины пакета вполне достаточно для того, чтобы передать заголовок (64 байта) и блока данных (длиной до 512 байтов).

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

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

Поле «время жизни» (TTL – Time to live) содержит сведения о том, в течении какого времени дейтаграмме разрешено находится в сети, фактически представляя собой счетчик транзитов. Указанное время измеряется в секундах и уменьшается на 1 на каждом этапе обработки дейтаграммы в процессе ее следования по сети, а при достижении нуля дейтаграмма уничтожается в целях экономии ресурсов сети, когда группа маршрутизаторов может «гонять» блок данных по кругу из-за какой–то неисправности в сети. Когда маршрутизатор обнаруживает, что значения параметра «время жизни» достигло нуля, он немедленно удаляет блок данных и передает отправителю сообщение об ошибке с помощью рассмотренного выше протокола ICMP.

Поле «протокол» (protocol, 8 битов) содержит указание, какой протокол следует за IP. Каждый протокол, относящийся к TCP/IP, идентифицируется фиксированным номером.

Поле контрольной суммы (Header checksum, 16 битов) служит для проверки правильности информации заголовка дейтаграммы. Контрольная сумма обеспечивает проверку только данных заголовка, которые включают в себя IP – адреса источника и пункта назначения. При проверке заголовка IP, контрольная сумма анализирует правильность номера версии IP и подтверждает отличие от нуля поля «время жизни». Она позволяет также поверить отсутствие искажения заголовка IP и допустимость длины сообщения.

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

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

В начале 1995 года IETE, после 3-х лет консультаций и дискуссий, выпустило предложения по новому стандарту протокола IP-IPv6, который еще называют IPing.

Протокол IPv6 решает проблему нехватки IP – адресов за счет использования 128 – разрядных адресов вместо 32 – разрядных адресов IPv4, благодаря чему адресное пространство расширяется в 296 раз.

Новый заголовок IP – пакета показан на рисунке 9.7.

Рис. 9.7 Заголовок IPv6

Однако, не только адресная проблема определила появление нового протокола.

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

В этом заголовке поле «версия» - номер версии IP, равное 6. Поле «приоритет» может принимать значение от 0 до 15. Первые 8 значений закреплены за пакетами, требующими контроля переполнения, например, 0 – несимвольная информация; 1 – информация заполнения (news); 2 – не критичная ко времени передача данных (e-mail); 4 – передача данных режима on-line (FTP, HTTP, NFS, и т.п.); 6 – интерактивный обмен данными (telnet,X); 7 – системные данные или данные управления сетью (SNMP, RIP и т.п.). Поле «метка потока» предлагается использовать для оптимизации маршрутизации пакетов. В Ipv6 вводится понятие потока, который состоит из пакетов. Пакеты потока имеют одинаковый адрес отправителя и одинаковый адрес получателя и ряд ряд других одинаковых опций. Подразумевается, что маршрутизаторы будут способны обрабатывать это поле и оптимизировать процедуру пересылки пакетов, принадлежащих одному потоку. В настоящее время алгоритмы и способы использования поля «метка потока» находятся на стадии обсуждения. Поле длины пакета определяет длину следующей за заголовком части пакета в байтах. Поле «следующий заголовок» определяет тип следующего за заголовком IP – заголовка. Заголовок Ipv6 имеет меньшее количество полей, чем заголовок Ipv4. Многие необязательные поля могут быть указаны в дополнительных заголовках, если это необходимо. Поле «ограничение переходов» определяет число промежуточных шлюзов, которые ретранслируют пакет в сети. При прохождении шлюза это число уменьшается на единицу. При достижении значения «0» пакет уничтожается. После первых 8 байтов в заголовке указываются адрес отправителя пакета и адрес получателя пакета. Каждый из этих адресов имеет длину 16 байт. Таким образом, длина заголовка Ipv6 составляет 48 байтов.

После 4 байтов IP – адреса стандарта Ipv4, 16 байт IP – адреса для Ipv6 выглядят достаточными для удовлетворения любых потребностей Internet. Не все 2128 адресов можно использовать в качестве адреса сетевого интерфейса в сети. Предлагается выделение отдельных групп адресов, согласно специальным префиксам внутри IP – адреса, подобно тому как это делалось при определении типов сетей Ipv4. Так, двоичный префикс «0000010» предлагается закрепить за отображением IPX – адресов в IP – адреса. В новом стандарте выделяют несколько типов адресов: unicast addresses – адреса сетевых интерфейсов, anycast addresses – адреса не связанные с конкретным сетевым интерфейсом, но и не связанные с группой интерфейсов и multicast addresses – групповые адреса. Разница между последними двумя группами адресов в том, что anycast addresses это адрес конкретного получателя, но определяет адрес сетевого интерфейса только в локальной сети, где этот интерфейс подключен, а multicast – сообщение предназначено группе интерфейсов, которые имеют один multicast – адрес.

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

Коммутация по меткам протоколов IP широко используется в мультисервисных сетях, работающих по технологии MPLS.

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

9.4. Протоколы транспортного уровня модели TCP/IP

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

На Транспортном уровне модели TCP/IP присутствуют два протокола: TCP (протокол управления передачей) и UDP (протокол передачи дейтаграмм пользователя). Эти транспортные протоколы существуют в двух вариантах: на основе соединений (connection-oriented) (TCP) и без установления соединения (connectionless) (UDP). Различие выражается в действиях протокола TCP по организации и поддержке соединения между отправителем и получателем перед отсылкой данных, получению положительного подтверждения об успешной их передаче или запроса на повторную пересылку отсутствующих или ошибочных данных. В то же время протокол UDP просто пересылает данные «оптимальными усилиями» и не выполняет последующей проверки после их получения.

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

9.4.1. Протокол UDP

Протокол UDP (User Datagram Protocol – протокол пользовательских дейтаграмм, RFC 768) является одним из двух основных протоколов транспортного уровня. Протокол UDP предоставляет протоколам прикладного уровня услуги негарантированной доставки пакетов, что немногим отличается от услуги протокола IP. Поскольку для приложений, использующих протокол UDP важна в первую очередь скорость доставки данных, протокол UDP имеет очень короткий заголовок. Заголовок UDP содержит только три поля «Port» (Порт), «Checksum» (Контрольная сумма) и «Length» (Длина дейтограммы), первое предназначено для мультиплексирования дейтаграмм по различным приложениям, второе – обеспечивает целостность каждой конкретной переданной дейтаграммы.

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

Формат UDP дейтограммы показан на рис. 9.8.

Рис. 9.8 формат UDP- дейтограммы.

9.4.2. Поля UDP дейтограммы

Поле Source port (Порт отправителя) указывает порт приложения, отправившего дейтограмму. Это поле необязательное, если оно используется, то содержит нуль.

Поле Destination port (Порт получателя) указывает порт приложении, которое должно обрабатывать эту дейтограмму у получателя;

Поле Length (Длина) определяет число октетов (байт) в UDP дейтограмме, включая заголовок;

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

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

Рис. 9.9 формат псевдо заголовка UDP

Сам по себе псевдо заголовок не передается, поэтому размер UDP дейтограммы не увеличивается. Для проверки дейтограммы на приемной стороне, псевдо заголовок генерируется протоколом UDP из соответствующих полей IP пакета. Идентичность контрольных сумм гарантирует доставку пакета по правильному (указанному в поле «Destination address») адресу и по указанному порту. В поле псевдо заголовка «Protocol» указывается код протокола UDP равный 17.

9.4.3. Инкапсуляция UDP

Инкапсуляция – это вложение протокола более высокого уровня в ноле данных протокола более низкого уровня.

Протокол UDP, согласно стеку протоколов TCP/IP, должен взаимодействовать с протоколами прикладного уровня и протоколами межсетевого уровня. Протоколы прикладного уровня передают битовый (байтовый) поток протоколу UDP. Этот поток протокол UDP фрагментирует и вставляет в область данных своих дейтаграмм. Далее протокол UDP вычисляет контрольную сумму, добавляет свой заголовок и передает свои дейтаграммы нижележащему протоколу межсетевого уровня – протоколу IP. Протокол IP вставляет в область своих данных UDP дейтограмму целиком, не изменяя, и добавляет свой IP заголовок, таким образом, получая целостный IP пакет. После чего, IP пакет передается протоколу нижележащего уровня сетевого интерфейса. В случае, использования на этом уровне протокола Ethernet, IP пакет вставляет в область данных Ethernet кадра, после чего протокол Ethernet вычисляет свой заголовок и окончание и дописывает их к области данных. В результате получается полный Ethernet кадр с вложенными IP пакетом и UDP дейтограммой, содержащий битовый поток от конкретного приложения. Процесс вложения называется инкапсуляцией пользовательских данных и показан на рис. 9.10.

Рис. 9.10 инкапсуляция UDP-дейтограмм

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

Зона ответственности протокола Ethernet – локальная сеть. Если узел находится за пределами локальной сети, кадр должен быть декапсулирован до IP пакета, чтобы осуществить доставку по IP адресу, указанному в IP заголовке. Двух заголовках Ethernet и IP хватит, чтобы доставить UDP пакет до узла назначения, но не хватит, чтобы передать конкретному приложению переданный битовый поток. Поэтому необходимо на узле получателя декапсулировать пакет, сначала до UDP дейтограммы, заголовок которой может мультиплексировать битовый поток между приложениями, и затем отбросить и UDP заголовок, передав данные в чистом виде приложению.

9.4.4. Протокол TCP

Основная задача протокола TCP (Transmission Control Protocol – протокол управления передачей, RFC 793) обеспечить сквозную гарантированную доставку данных между прикладными процессами. Другими словами, если приложение на одном узле хочет передать данные без каких – либо изменений такому же приложению на другом узле, то задачу эту выполнить приложение доверяет протоколу TCP.

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

Рис. 9.11 Формат заголовка TCP-сегмента.

Заголовок TCP сегмента состоит из 32 – разрядных слов (32 бита) и имеет переменную длину, зависящую от размера поля «Options» и «Padding», но всегда кратную 32 битам. Формат заголовка TCP сегмента представлен на рисунке 9.11.

Поле «Source Port» и поле «Destination Port» (порт отправителя и получателя) указывает номер портов источника и получателя соответственно.

Поле «Sequence Number» (номер последовательности) определяет порядковый номер первого байта в поле данных сегмента среди всех октетов потока данных для текущего логического соединения (TCP сессия). Если в TCP сегменте передаются октеты с 5–го по 87–ой, то SN=5. В случае начальной установки соединения (TCP сегмент с флагом «SYN») в поле SN записывается случайный номер ISN (Initial Sequence Number = начальный номер последовательности), первом TCP сегменте без флага «SYN» поле SN=ISN+1.

Поле «Acknowledgment Number» (номер подтверждения) указывает (в совокупности с флагом «АСК»)порядковый номер октета, который отправитель данного сегмента желает получить подразумевая тем самым, что все предыдущие байты (с номерами от ISN+1 до АСК-1) были успешно получены.

Поле «Data Offset» (смещение данных, 4 бита) указывает смещение начала данных TCP в сегменте относительно начала сегмента. Поле указывает длину TCP заголовка. Минимальная длина заголовка без параметров может быть равна 5–ти 32–х битным словам или 160 байтам. Максимальная длина заголовка – 480 байт.

Поле «Reserved» (зарезервировано, 6 бит) зарезервировано для дальнейшего использования, заполняется нулями.

Поле «Flags» (флаги, 6 бит) содержит управляющие биты, для контроля над соединением.

• Флаг URG (urgent – срочно) указывает срочность доставки сегмента;

• Флаг ACK (Acknowledgment – подтверждение) подтверждает, что поле «Acknowledgment Number» указывает следующий октет, который предлагает принять получатель;

• Флаг PSH (Push – протолкнуть) указывает на незамедлительность отправки данных из TCP сегмента процессу прикладного уровня, даже, если приемный TCP буфер не заполнен. Используется при передаче данных интерактивных приложений;

• Флаг «RST» (Reset – перезагрузка) указывает на необходимость перезагрузки текущего TCP соединения;

• Флаг «SYN» (Synchronization – синхронизация) указывает на то, что данный TCP сегмент является запросом на установление соединения;

• Флаг «FIN» (Finish –конец) указывает на закрытие TCP соединения;

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

Поле «Checksum» (контрольная сумма) содержит контрольную сумму всего TCP сегмента. Обеспечивает поразрядную проверку целостности.

Поле «Urgent Pointer» (указатель срочности) используется для указания длины срочных данных, которые размещаются в начале поля данных сегмента. Число в этом поле указывает смещение октета срочных данных относительно первого октета данных в сегменте. Например, если в TCP сегменте передаются окном с 5 – го по 87 – ой и первые 15 из них срочные, то поле «Urgent Pointer»=15. Протокол TCP не регламентирует, как должны обрабатываться срочные данные, определено только, что они должны быть максимально быстро отправлены прикладному процессу. Поле «Urgent Pointer» действует в совокупности aлагом «URG».

Поле «Options» (опции, поле переменной длины) поле указывает на реализацию работы дополнительных услуг (опций) протокола TCP. Поле конкретной опции в поле «Options» состоит из октета «Option Kind» (тип опции), октета «Option Length» (длина опции) и октетов «Option Octets» (октетов с данными опции). Стандарт протокола TCP определяет три опции:

«End of Option List» (конец списка опций) имеет тип опции, равный «0», и длина в один октет. Определяет конец списка опций. Не используется, если набор опций TCP выходит за 32 – битную границу.

«No Operation» (бездействие) имеет тип опции, равный «1», и длину в один октет. Используется между TCP опциями для 32 – битного выравнивания.

«Maximum Segment Size» имеет тип опции равный «2», и длину в четыре октета. Описывает максимальный размер сегмента, который может быть передан по TCP соединению. Вычисляется на основании MТU (Maximum Transfer Unit – максимальный блок передачи), который может быть передан по соединению за вычетом IP и TCP заголовков. Данная опция включается только на стадии установки соединения, вместе с флагом «SYN».

Поле «Padding» (заполнение) заполняется нулями до выравнивания по 32 – битной границе в случае, если поле «Options» не укладывается в 32 – битное слово.

9.5. Протоколы прикладного уровня

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

9.5.1. HTTP – протокол передачи гипертекстов

Hyper Text Transfer Protocol (HTTP) – это протокол высокого уровня (а именно, уровня приложений), обеспечивающий необходимую скорость передачи данных, требующуюся для распределенных информационных систем гипермедиа. HTTP используется проектом World Wide Web с 1990 года.

Практические информационные системы требуют большего, чем примитивный поиск, модификация и аннотация данных. HTTP/1.0 открытое множество методов, которые могут быть использованы для указания целей запроса. Они построены на дисциплине ссылок, где для указания ресурса, к которому должен быть применен данный метод, используется Универсальный Идентификатор Ресурсов (Universal Resource Identifier – URI), в виде местонахождения (URL) или имени (URN). Формат сообщений сходен с форматом Internet Mail или Multipurpose Internet Mail Extensions (MIME – Многоцелевое Расширение почты Internet).

HTTP/1.0 используется также для коммуникаций между различными пользовательскими просмотрщиками и шлюзами, дающими гипермедиа доступ к существующим Internet протоколам, такие как SMTP, NNTP, FTP, Gopher и WAIS. HTTP/1.0 разработан, чтобы позволять таким шлюзам через proxy серверы, без какой – либо потери передавать данные с помощью упомянутых протоколов более ранних версий.

HTTP основывается на парадигме запросов/ответов. Запрашивающая программа (обычно она называется клиент) устанавливает связь с обслуживающей программой – получателем (обычно называется сервер) и посылает запрос серверу в следующей форме:

• Метод запроса,

• URI,

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

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

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

9.5.2. FTP–протокол

FTP (File Transfer Protocol, или «протокол передачи данных») – один из старейших протоколов в Internet и входит в его стандарты. Первые спецификации FTP относятся к 1971 году. С тех пор FTP претерпел множество модификаций и значительно расширил свои возможности. FTP использоваться как в программах пользователей, так и в виде специальной утилиты операционной системы.

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

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

Алгоритм работы протокола FTP состоит в следующем:

1. сервер FTP используется в качестве управляющего соединения на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны пользователя FTP.

2. после того как устанавливается управляющее соединение модуля «Интерпретатор протокола пользователя» с модулем сервера – «Интерпретатор протокола сервера», пользователь (клиент) может отправлять на сервер команды. FTP – команды определяют параметры соединения передачи данных: роль участников соединения (активный или пассивный), порт соединения (как для модуля «Программа передачи данных пользователя», так и для модуля «Программа передачи данных сервера»), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить (например, сохранить, считать, добавить или удалить данные или файл и другие).

3. после того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, «Программа передачи данных пользователя»), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль(например, «Программа передачи данных сервера» и«Программа передачи данных пользователя» закрывается, но управляющее соединение «Интерпретатора протокола сервера» и «Интерпретатора протокола пользователя» остается открытым. Пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных.

9.5.3. SMTP-протокол

Основная задача протокола SMTP (Simple Mail Transfer Protocol) заключается в том, чтобы обеспечивать передачу электронных сообщений (почту). Для работы через протокол SMTP клиент создает TCP соединение с сервером через порт 25. Затем клиент и SMTP сервер обмениваются информацией, пока соединение не будет закрыто или передано. Основной процедурой в SMTP является передача почты (Mail Procedure). Далее идут процедуры форвардинга почты (Mail Forwarding), проверка имен почтового ящика и вывод списка почтовых групп. Самой первой процедурой является открытие канала передачи, а последней – его закрытие.

Простой протокол передачи почты обеспечивает двухсторонний обмен сообщениями между локальным клиентом и удаленным сервером МТА. МТА – клиент шлет команды МТА – серверу, а он, в свою очередь, отвечает клиенту. Другими словами, протокол SMTP требует получать ответы (они описаны в этой главе) от приемника команд SMTP. Обмен командами и ответами на них называется почтовой транзакцией (mail transaction). Данные, как мы уже говорили, передаются в формате NVT ASCII. Кроме того, команды тоже передаются в формате NVT ASCII. Команды передаются в формате ключевых слов, а не специальных символов, и указывают на необходимость совершить ту или иную операцию. В таблице 9.2 приведен список ключевых слов (команд), определенный в спецификации SMTP – RFC 82.

Таблица 8 (начало).

Команды простого протокола передачи почты (SMTP)

Команды	Обязательства	Описание
HELO	да	Идентифицирует модуль – передатчик для модуля – приемника (hello).
MAIL	да	Начинает почтовую транзакцию, которая завершается передачей данных в один или несколько почтовых ящиков (mail).
RCPT	да	Идентифицирует получателя почтового сообщения (recipient).
DATA	нет	Строки, следующие за этой командой, рассматриваются получателем как данные почтового сообщения. В случае SMTP, почтовое сообщение заканчивается комбинацией символов: CRLF – точка – CRLF.
RSET	нет	Прерывает текущую почтовую транзакцию (reset).

Таблица 8 (продолжение).

NOOP	нет	Требует от получателя не предпринимать никаких действий, а только выдавать ответ OK. Используется главным образом для тестирования. (No operation).
QUIT	нет	Требует выдать ответ OK и закрыть текущее соединение.
VRFY	нет	Требует от приемника подтвердить, что ее аргумент является действительным именем пользователя.
SEND	нет	Начинает почтовую транзакцию, доставляющую данные на один или несколько терминалов (а не в почтовый ящик).
SOML	нет	Начинает транзакцию MAIL или SEND, доставляющую данные на один или несколько терминалов или почтовые ящики.
EXPN	нет	Команда SMTP – приемнику подтвердить, действительно ли аргумент является адресом почтовой рассылки и если да, вернуть адрес получателя сообщения (expand).
HELP	нет	Команда SMTP – приемнику вернуть сообщение – справку о его командах.
TURN	нет	Команда SMTP – приемнику либо сказать OK и поменяться ролями, то есть стать SMTP – передатчиком, либо послать сообщение – отказ и остаться в роли SMTP – приемника.

Дата добавления: 2015-08-05