Понятие протокола, и связанные с ним понятия

Вид материала

Документы

Содержание Уровень сетевых интерфейсов TCP/IP. Структура стека протоколов TCP/IP Спецификации передачи трафика IP в локальных сетях (LAN). ARP. Протокол ARP Формат ARP пакета для локальной сети Спецификации передачи трафика IP в глобальных сетях (WAN). Call request Call request Передача IP трафика через произвольные цифровые каналы. Протоколы SLIP и PPP. Факультативный материал – сжатие заголовков TCP/IP на примере сжатия Ван Джакобсона.

Подобный материал:

• Программа курса лекций, 33.31kb.
• А, а также связанные с этим сервисы, частично или полностью через пакетные сети, 211.32kb.
• Тема Основные понятия о правовых явлениях, 165.32kb.
• Контрольная работа по предмету «Логика», 57.32kb.
• Понятия налоги и налогообложение. Налоговая система понятие налога и сбора. Принципы, 2182.16kb.
• Задачи: Продолжить формирование понятия о внутренней среде и ее компонентах. Раскрыть, 161.91kb.
• Естественные науки 14 апреля с 10. 00 до 17., 82.95kb.
• Словари профессий, 47.56kb.
• Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 114.5kb.
• Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 107.69kb.

Уровень сетевых интерфейсов TCP/IP.

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

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

Как видно, структура стека протоколов TCP/IP не вполне соответствует 7-уровневой модели ISO-OSI, что неудивительно, если учесть, что он создавался значительно раньше.

Стек протоколов TCP/IP специально создавался для объединения разнородных сетей в единую интерсеть, поэтому там, где должны были бы, согласно модели OSI, находится канальный и физический уровни, находится уровень сетевых интерфейсов, который дополняется новой спецификацией RFC всякий раз, когда появляется новая сетевая технология.

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

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

В идеологии стека TCP/IP уровень сетевых интерфейсов включает любые технологии, на основе которых функционируют отдельные сети, объединяемые в интерсеть.

Это могут быть и в самом деле простейшие технологии, подобные Ethernet, или весьма сложные, как ATM, могут быть даже альтернативные TCP/IP стеки протоколов, например, IPX/SPX.

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

Это в равной мере может быть как LAN, так и WAN технология.

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

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

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

1. Инкапсуляцию IP-пакетов в кадры/пакеты данной сетевой технологии для передачи их по сети, с корректной последующей передачей их IP-протоколу.
   
2. Установление соответствия IP-адресов адресам, используемым данной сетевой технологией (ARP/RARP). В IP-протоколе принята своя система адресования узлов сети, не связанная прямо с какой-либо системой адресации локальных сетей. Этим протокол IP отличается, например, от протокола IPX, где в качестве адреса узла в сети используется его аппаратный MAC-адрес. В этом и сила, и слабость IP. Он может быть совмещен с любой технологией, использующей любые форматы локальных адресов, но нуждается при этом в дополнительном протоколе, устанавливающем соответствие между IP-адресами узлов сети и их адресами в рамках локальной технологии. IPX не нуждается в протоколах типа ARP в локальных сетях, но в случае перехода к глобальным сетям, использующим другие по составу и структуре адреса, он потребовал бы таких протоколов. Следующая версия протокола IP – IP V6, тоже не нуждается в протоколе ARP, но платит за это длиной адреса – 128 бит (16 байт).
   
3. Широковещательную и/или мультивещательную рассылку пакетов в сетях, не поддерживающих такие режимы.
   

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

Спецификации передачи трафика IP в локальных сетях (LAN).

Для локальных сетей (LAN) инкапсуляция IP-пакетов осуществляется в ненумерованные информационные кадры LLC-SNAP (RFC-1042). Исключение составляет Ethernet, для которого наряду с LLC-SNAP поддерживается, и даже рекомендуется формат кадра Ethernet II (Ethernet DIX)( RFC-894). Протоколу IP соответствует код протокола 0x800H. Требования к узлам в этом случае требуют, чтобы узел мог принимать и передавать оба типа инкапсуляции (как RFC-1042, так и RFC-894), и умел различать их во входном потоке. На передачу по умолчанию используется инкапсуляция RFC-894, но этот параметр является настраиваемым.

Прямое отображение Padr=F(IP-adr) (в частности, использование локального адреса в качестве адреса узла) возможно для некоторых технологий локальных сетей, например, ArcNet, proNET-10, использующих короткие, однобайтовые адреса (к сожалению, эти технологии сейчас уже не используются). С некоторыми оговорками, для адресов класса не ниже B, оно еще возможно при использовании двухбайтовых (16 битных) адресов, использование которых декларировано описаниями ряда технологий, хотя только FDDI имеет в заголовке кадра флаг, указывающий размерность используемых адресов. Однако фактическим стандартом стало использование в локальных сетях 6-байтовых MAC-адресов.

Для определения локального адреса по IP-адресу используется протокол разрешения адреса Address Resolution Protocol, ARP. Протокол ARP поверх протокола канального уровня с возможностью широковещательного доступа одновременно ко всем узлам сети, а таковы все протоколы локальных сетей (Ethernet, Token Ring, FDDI), работает следующим образом.

Узел, которому нужно выполнить отображение IP-адреса на локальный адрес, формирует ARP запрос, вкладывает его в кадр протокола канального уровня, указывая в нем известный IP-адрес, и рассылает запрос широковещательно. Тот факт, что кадр содержит ARP запрос, индицируется значением 0x0806H в поле типа протокола заголовка LLC-SNAP или Ethernet II. Все узлы локальной сети получают ARP запрос и сравнивают указанный там IP-адрес с собственным. В случае их совпадения узел формирует ARP-ответ, в котором указывает свой IP-адрес и свой локальный адрес и отправляет его уже направленно, так как в ARP запросе отправитель указывает свой локальный адрес. ARP-запросы и ответы используют один и тот же формат пакета. Так как локальные адреса могут в различных типах сетей иметь различную длину, то формат пакета протокола ARP зависит от типа сети.



Формат ARP пакета для локальной сети:

Тип сети 2 байта (Тип ЛС)

Тип протокола 2 байта (IP= 0800H)

Длина локального адреса 1 байт

Длина сетевого адреса 1 байт

Тип операции 2 байта (1 – ARP-запрос, 2 – ARP-ответ.)

Локальный адрес отправителя

Сетевой адрес отправителя

Искомый локальный адрес

Искомый сетевой адрес

Узел, отправляющий ARP-запрос, заполняет в пакете все поля, кроме поля искомого локального адреса (для RARP-запроса не указывается искомый IP-адрес). Значение этого поля заполняется узлом, опознавшим свой IP-адрес.

Широковещательные ARP-запросы не являются единственным источником информации о соответствии между IP и MAC адресами. Записи в таблице могут создаваться вручную (большинство операционных систем имеют программу/команду ARP, позволяющую как просматривать, так и корректировать соответствующие таблицы). IP-Пакеты, приходящие от других узлов содержат IP-адрес отправителя и его MAC-адрес в заголовке кадра канального уровня, информация из чужих широковещательных ARP-запросов также полезна.

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

Существует также протокол, решающий обратную задачу – нахождение IP-адреса по известному локальному адресу. Он называется реверсивный ARP – RARP (Reverse Address Resolution Protocol) и используется при старте станций, не знающих в начальный момент своего IP-адреса, но знающих адрес своего сетевого адаптера.

Широковещательность и мультивещательность всеми технологиями локальных сетей поддерживаются, так что здесь проблем нет. В Ethernet даже существует специальный диапазон адресов для групповой рассылки IP-дейтаграмм: 01:00:5E:X:Y:Z, где ХYZ – младшие 23 бита мультивещательного IP-адреса.

Спецификации передачи трафика IP в глобальных сетях (WAN).

Упаковка IP-пакетов в кадры/пакеты технологий WAN принципиально не отличается от таковой для локальных сетей. При этом используется поле «тип вложения», например, для Frame Relay байт NLPID=0xCC. В случае ATM используется SNAP инкапсуляция, как в технологиях локальных сетей.



формат IP-пакета в кадре Frame Relay

В случае WAN существенным является ориентация технологий на механизм виртуальных каналов. Если канал предполагается использовать для передачи трафика только одного протокола, в частности, IP, можно указать этот протокол в пакете CALL REQUEST, и не указывать в последующих пакетах, передаваемых по установленному каналу. Например, в сетях технологии X-25 это указывается первым байтом поля данных пакета CALL REQUEST (сразу после адресов и опций). Для IP это значение равно 204(0x CC), а значение 128 (0x80) определяет SNAP-инкапсуляцию, в этом случае IP соответствуют OUI=0x000000, Etertype=0x8000.

CALL REQUEST




Или

д
GFI|LCN|I-frame SETUP

IP-пакет
анные

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

CALL REQUEST

данные

и
IP-пакет

,0x80|000000|0800
ли


В случае Frame Relay такой вариант не применяется, поскольку обычно виртуальные каналы в этих сетях устанавливаются вручную администратором¹⁴, поэтому идентификатор типа вложения присутствует в каждом кадре, но также допускается как NLPID-, так и SNAP-инкапсуляция. Спецификация, определяющая передачу трафика в сетях X.25 – RFC-1356, а в сетях Frame Relay – RFC-1490.

В случае использования ATM для Internet, поскольку размер ячейки слишком мал, пакет помещается в последовательности ячеек, составляющих сообщение AAL5. Значение MTU по умолчанию равно 9180 (RFC-1626), так как фрагментация IP-дейтограмм крайне нежелательна. Эта величина заимствована из RFC-1209, определяющего передачу IP-трафика через сети протокола SMDS. Разработчики RFC-1626 сочли, что нет причин, по которым следует выбирать другой размер. Разумеется, при установлении временного виртуального канала максимальный размер пакета должен быть согласован на этапе согласования параметров AAL5 (даже если он соответствует принятому по умолчанию). Работа протоколов TCP/IP поверх ATM описана в документах RFC-1483, -1577, -1626, -1680, -1695, -1754, -1755, -1821, -1926, -1932 (полужирным шрифтом выделены коды документов, являющиеся стандартами Internet).



пакет IP в протокольном блоке ATM

В глобальных сетях администратору сети обычно приходится вручную формировать ARP-таблицы, в которых он задает, например, соответствие IP-адреса адресу узла сети X.25, который имеет смысл локального адреса. Вышеупомянутые спецификации RFC-1356 и RFC-1490 не определяют никакого динамического протокола, который позволял бы автоматизировать этот процесс. Работа протокола ARP поверх ATM-сетей описана в RFC-1577. Особенностью сетей Frame Relay является преимущественное формирование виртуальных каналов вручную администратором, вследствие чего ARP-таблицы в этих сетях устанавливают соответствие IP-адресов не адресам узлов как таковым, а номерам заранее сформированных виртуальных каналов.

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

Широковещательная и групповая рассылка также, как правило, осуществляется через посредство выделенного для этой цели сервера, причем для более современных сетей FR, ATM используются их multicasting-возможности. В этом случае доступ узлов к корню (мультикастинг-серверу) осуществляется по схеме «1 к 1» а сервер, получив широковещательный или групповой пакет, рассылает его по схеме «1 к N». В ATM в ряде случаев такой подход используется и для рассылки ARP-запросов, подобно технологиям локальных сетей. В Х.25 единственным способом эмуляции широковещательный или групповой рассылки является уникаст-рассылка каждому узлу сети или члену группы.

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

Мы ранее подробно рассматривали такую зависимость на примере протокола TCP. В Х.25 размер окна, связанного с одним виртуальным каналом, всегда невелик – по умолчанию он составляет 2 пакета, а всегда не более 8 либо 128 пакетов, что связанно с размерностью поля номера пакета. В сочетании с небольшим стандартным размером пакета по умолчанию (128 байт), это существенно ограничивает пропускную способность виртуального канала Х.25. Передача TCP/IP-траффика в этом случае может быть существенно ускорена, если использовать для одного TCP/IP соединения несколько виртуальных каналов Х.25.

Передача IP трафика через произвольные цифровые каналы. Протоколы SLIP и PPP.

Передача IP-трафика возможна поверх цифровых каналов, не являющихся элементом сети какой-либо из базовых сетевых технологий. В частности, при доступе к Internet через телефонную сеть и модем – через цифровой канал, образованный модемом. (Несмотря на то, что обмен между модемами осуществляется с использованием протоколов канального уровня (MNP, LAPM), для оконечного оборудования данных эти протоколы “прозрачны”, и передаваемые данные представляются ООД просто потоком байт.) Это требует организации для передачи пакетов сетевого уровня (IP) какого-то протокола канального уровня (в терминах TCP/IP – уровня сетевых интерфейсов).

Исторически первым таким протоколом был SLIP (Serial Line IP). Это простейший и, внешне, очень примитивный протокол. IP-дейтограмма в случае SLIP должна завершаться специальным символом 0xC0, называемым конец. Хотя это описанием протокола и не требуется, во многих реализациях дейтограмма и начинается с этого символа. Если какой-то байт дейтограммы равен символу конец, то вместо него передается двухбайтовая последовательность 0xDB, 0xDC. Если же байт дейтограммы равен 0xDB, то вместо него передается последовательность 0xDB, 0xDD. Таким образом, в протоколе SLIP используется байтстаффинг, байт 0xDB выполняет в SLIP функцию ESC-символа.

Использование протокола SLIP предполагает, что каждый партнер должен знать IP-адреса свой и адресата, поскольку не существует метода обмена такой информацией. Кадр SLIP не имеет поля “тип вложения”, поэтому его нельзя использовать для инкапсуляции пакетов других протоколов, кроме IP. SLIP не использует контрольных сумм, поэтому обнаружение и коррекция ошибок целиком ложится на программное обеспечение верхних уровней.

Впервые протокол SLIP был реализован в 1984 году в 4.2BSD. Максимальный размер передаваемого блока (MTU) для SLIP 256512 байт. Новой версией CSLIP (Compressed SLIP, RFC-1144), предложенной Ван Джекобсоном в 1990 году, обеспечивается сжатие IP и TCP заголовков. Это особенно важно для программ эмуляции терминала, поскольку им приходится передавать удаленному компьютеру каждый код нажатия и отпускания клавиши, перемещения мыши и т.д. немедленно по его поступлении. При этом для передачи одного символа (нажатая клавиша) используется 20 байт заголовка IP-пакета и 20 байт заголовка TCP-сегмента. С учетом издержки формирования SLIP-кадра, накладные расходы составят не менее 41 байта. В CSLIP заголовок сокращается до 35 байт (против 40 в SLIP)¹⁵. Эта версия протокола способна поддерживать до 256 TCP-соединений на каждом из концов последовательного канала, что обычно вполне достаточно. Многие современные SLIP-драйверы поддерживают и CSLIP. Применительно к протоколам удаленного управления SLIP обеспечивает еще одно средство повышения их оперативности – он помещает их пакеты в очереди на отправку впереди пакетов неинтерактивных протоколов. Поскольку на момент появления SLIP многие системы не поддерживали параметры типа сервиса IP, драйвер SLIP решал эту проблему самостоятельно, ориентируясь по номеру протокола (6=TCP) и порта назначения (25=Telnet). Ряд драйверов SLIP выполняют и другие дополнительные функции, например, фильтрацию исходящего и/или входящего трафика.

В настоящее время протокол SLIP используется все реже, а некоторые ОС его не поддерживает вообще. На смену ему пришел протокол PPP (Point-to-Point Protocol; RFC-3544,-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, -1171).

Протокол PPP включает:

Метод инкапсуляции пакетов различных протоколов для передачи по последовательным коммуникационным каналам.

Протокол LCP (Link Control Protocol) для установления, конфигурирования и тестирования каналов передачи данных (конфигурирование канального уровня).

Набор протоколов NCP (Network Control Protocol) для установки и конфигурирования различных протоколов сетевого уровня.

Формат кадра PPP следующий:



Кадр обрамляется флагами <0x7E>, однобайтное поле адреса всегда содержит широковещательный адрес – шестнадцатиричное значение x0FF, означающее, что все станции должны принимать этот кадр. Таким образом, при соединении точка-точка индивидуальные адреса не используются.

Поле управления содержит стандартное для HDLC-подобных протоколов однобайтное управляющее поле ненумерованного кадра (UI – ненумерованная информация) со сброшенным битом P/F, т.е. 03 (установлены только 2 младших бита). Использование ненумерованных кадров означает, что в протокол не включаются средства коррекции ошибок. Это оправданно, поскольку в случае использования PPP поверх каналов цифровых систем передачи вероятность ошибки невелика, и коррекцию ошибок можно без ущерба для производительности возложить на протоколы высших уровней. В случае модемов для аналоговых каналов коррекция ошибок реализуется модемом (MNP-24, LAPM). Протоколу PPP в этом случае остается только обнаружение ошибок и отбрасывание кадров, принятых с ошибкой, аналогично технологиям Frame Relay, ATM и др.

Двухбайтовое поле указывает, как интерпретировать поле данных. Например, значение 0x0021 этого поля говорит о том, что информационное поле содержит IP-пакет. Значения кодов поля протокола от 0xxx до 3xxx идентифицируют протоколы сетевого уровня, а значения в интервале 8xxx – Bxxx говорят о том, что протокол соответствует NCP (Network Control Protocol), соответствующий сетевому со сброшенным старшим битом (например IP – 0021  IPCP – 8021). Коды из диапазона 4xxx – 7xxx используются для протоколов с низким уровнем трафика, а коды от Cxxx до Fxxx соответствуют управляющим протоколам (например, LCP). Двухбайтовое поле протокола является типичным для протоколов канального уровня, ориентированных на инкапсуляцию пакетов сетевого уровня, либо кадров других протоколов канального уровня в режиме удаленного моста. Оно аналогично такому полю в кадрах локальных сетей (например Ethernet, LLC+SNAP), и в кадрах Frame Relay.

Поле представляет собой циклическую контрольную сумму (2байта), предназначенную для выявления ошибок при транспортировке PPP-кадра.

Протокол PPP может применяться как в синхронном, так и в асинхронном режиме, что делает его пригодным для работы по любым последовательным каналам. В синхронном режиме проблема появления флага в теле кадра решается посредством битстаффинга. В асинхронном режиме используется ESC-символ 0x7D, который определяет, что шестой бит в следующем за ним байте подлежит инверсии. Таким образом, байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D – в 0x7D, 0x5D. Кроме того, преобразуются в ESC-последовательности символы с кодами меньше 0x20. Например, 0x0D (возврат каретки) будет преобразован в 0x7D, 0x2D. Это исключает их интерпретацию как управляющих. Именно асинхронный вариант PPP используется модемом.

Для случая модема важно, что таким образом исключается появление в потоке данных, передаваемом модему, управляющих символов XON (17₁₀=11₁₆) и XOFF (19₁₀=13₁₆), обеспечивающих управление потоком. Ведь даже если мы на своей стороне установили аппаратное управление потоком, если обмен между локальным и удаленным модемом осуществляется с использованием протоколов коррекции ошибок (в этом случае управление потоком между модемами осуществляется супервизорными кадрами RR и RNR протокола коррекции ошибок), мы не можем гарантировать, что удаленный модем и его DTE также использует аппаратное управление потоком. В этом случае символы управления потоком, присутствующие в передаваемых данных, будут удаляться из потока и интерпретироваться удаленным DTE как управляющие. Конверсия управляющих кодов в ESC-последовательности позволяет этого избежать. Платой за это становится вносимая ESC-последовательностями избыточность – если разные кодовые комбинации в потоке равновероятны, в ESC-последовательностью будет заменяться примерно каждый 8-й символ. На этапе установления соединения по протоколу LCP можно договориться, какие из этих символов будут скрываться. По умолчанию скрываются все 32.

Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной¹⁶. Необходимость аутентификации согласовывается протоколом LCP.

LCP-протокол служит для установления соединения на канальном уровне путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации. Аутентификацию обеспечивают протоколы PAP
(Password Authentication Protocol) или CHAP (Challenge-Handshake Authentication Protocol). Затем, при необходимости, согласуются дополнительные услуги, например Callback (протокол CBCP) шифрование данных (протокол ECP) сжатие передаваемых данных (протокол CCP) и т.п. После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала. Затем следует обмен данными. Процедура закрытия соединения осуществляется протоколами NCP (освобождение используемых ресурсов сетевого уровня, например, адресов) и LCP (разрыв соединения уровня канала данных).

В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021(Link Control Protocol). Формат LCP-пакета следующий: заголовок (код, идентификатор, длина (2 байта))+данные. Код(1байт) – код операции; Идентификатор (1 байт) служит для соотнесения запросов и ответов. Длина (2 байта) – определяет длину поля данных, избыточные данные будут игнорироваться. Поле данных содержит список параметров (опций) в виде: тип(1байт)–длина(1байт)–значение.

Вот некоторые значения поля тип:

0 – Зарезервировано;

1 – Maximum-Receive-Unit (указывает максимальный размер блока данных, который может быть принят);

3 – Authentication-Protocol (протокол аутентификации);

4 – Quality-Protocol (протокол качества);

5 – Magic-Number (магическое число, служит для выявления каналов с петлями обратной связи);

6 – Protocol-Field-Compression (компрессия поля протокола);

7 – Address-and-Control-Field-Compression (компрессия управляющих полей)¹⁷;

Аналогичным образом согласуются параметры сетевого уровня протоколом NCP. Нас в данном случае больше всего интересует протокол IPCP (NCP для IP).

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

При подключении персональной ЭВМ к серверу через модем, после того как модем провайдера ответит на вызов модема клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. В случае доступа в Интернет мы будем работать со стеком протоколов TCP/IP, и по этой причине нуждаемся в IP-адресе. Если провайдер имеет в распоряжении N IP-адресов, он может подключить одновременно до N ЭВМ. Кроме того, для полноценной работы в сети, мы нуждаемся в адресе маршрутизатора по умолчанию, адресах серверов имен DNS (если они не установлены статически) и возможно, некоторой дополнительной информации. Присвоение IP-адреса, запрос и получение других необходимых для работы в сети сведений осуществляется в рамках IPCP (NCP)-протокола. На этой же стадии согласуются протоколы сжатия заголовков TCP/IP, если они используются¹⁸. После этого наша ЭВМ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения канального уровня осуществляет протокол LCP.

Протокол PPP поддерживает и многоканальные соединения (MLP – Multi Link Protocol, RFC-1990). Это особенно полезно при работе через ISDN, базовый комплект которого содержит 2 информационных DS-0 канала (B-канала), которые в этом случае можно объединить в составной канал (транк) с пропускной способностью 128 Кбит/с. Вообще возможность при необходимости расширить пропускную способность за счет подключения нескольких параллельных каналов следует признать весьма полезной.

Протокол PPP настолько популярен в современном провайдинге, что его часто используют не только при доступе через телефонную или иные первичные сети, но и там, где существуют свои канальные протоколы (главным образом, ради LCP и NCP). Так при организации доступа в Internet через Ethernet используется протокол PPPoE (PPP over Ethernet), а при доступе через ADSL – PPPoA (PPP over ATM).

Факультативный материал – сжатие заголовков TCP/IP на примере сжатия Ван Джакобсона.

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

Итак, рассмотрим стандартный заголовок IP+TCP.





Цветом выделены поля, которые в рамках одного соединения не меняются. Действительно, пара адресов плюс пара номеров портов как раз и идентифицирует соединение. Для кодирования номера соединения в алгоритме Ван Джакобсона используется один байт, что позволяет идентифицировать 256 соединений, но, как правило, согласуется еще меньшее число (обычно 16). Поле версии всегда 4, поля длин – всегда 5 (заголовки с опциями не сжимаются), поле резерва обнулено. Тип сервиса в рамках соединения не меняется (сегментам одного соединения бессмысленно присваивать разные приоритеты, либо разные предпочтения по обслуживанию), то же относится и ко времени жизни. Протокол всегда 6 (TCP). Заголовки фрагментированных пакетов не сжимаются, так что поле, содержащее флаги фрагментации и смещение фрагмента тоже неизменно.

Далее, из флагов протокола TCP 3 (SYN,FIN,RST) установлены только в пакетах, осуществляющих установление и разрыв соединения (заголовки таких пакетов не сжимаются), в остальных случаях сброшены. Еще один флаг – ASK – наоборот, в информационных пакетах всегда установлен (всегда есть, что подтверждать). Таким образом, из TCP-флагов нуждаются в передаче только 2 – PUSH и URG (в последнем случае потребуется передать и срочный указатель). Еще 2 поля могут быть опущены – общая длина пакета (она может быть определена из размера кадра, переносящего пакет), и контрольная сумма IP заголовка (она в любом случае перерассчитывается в каждом узле).

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


Заголовок сжатого пакета имеет вид:




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

Передача в каждом сжатом заголовке неизмененного значения контрольной суммы TCP-сегмента позволяет распознать случаи потери пакетов при передаче по последовательному каналу. В этом случае смещения будут отсчитаны не от того основания, контрольная сумма не совпадет, и сегмент будет отброшен модулем TCP на приеме¹⁹. Синхронизация может быть восстановлена посылкой пакета типа «несжатый TCP»(см. далее), либо неизменного TCP/IP-пакета.

Есть два важных особых случая:

• Ask Number и Seq Number оба увеличиваются на длину поля данных последнего пакета, окно и срочный указатель не меняются;
  
• только Seq Number увеличивается на длину поля данных последнего пакета, окно и срочный указатель не меняются.
  

Для опознания этих особых случаев используются две редко встречающиеся комбинации младших 4-х битов: S W U (0xB) для первого случая, и S A W U (0xF) – для второго. Разумеется, в случае, когда заголовок пакета изменяется так, что как раз эти комбинации востребованы, приходится передавать несжатый заголовок.

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