Чернега В., Платтнер Б. Компьютерные сети. Учебное пособие для вузов

Подождите немного. Документ загружается.

Раздел 4. Компьютерная сеть Интернет

279

транспортного сообщения из каждого пакета FDDI и делит его еще пополам,

чтобы каждая часть уместилась в поле данных кадра Ethernet. Затем он фор-

мирует новые IP-пакеты, каждый из которых имеет длину 1400 + 20 = 1420

байтов, что меньше 1500 байтов, поэтому они нормально помещаются в поле

данных кадров Ethernet.

В результате в компьютер 2 по сети Ethernet приходит четыре IP-

пакета с общим идентификатором 486, что позволяет протоколу IP, рабо-

тающему в компьютере 2, правильно собрать исходное сообщение. Если па-

кеты пришли не в том порядке, в котором были посланы, то смещение ука-

жет правильный порядок их объединения.

Отметим, что IP-маршрутизаторы не собирают фрагменты пакетов в

более крупные единицы, даже если на пути встречается сеть, допускающая

такое укрупнение. Это связано с тем, что отдельные фрагменты сообщения

могут перемещаться в объединенной IP-сети по различным маршрутам, по-

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

точный маршрутизатор на их пути.

При приходе первого фрагмента пакета узел назначения запускает

таймер, определяющий максимально допустимое время ожидания прихода

остальных фрагментов этого пакета. Если таймер истекает раньше прибытия

последнего фрагмента, то все полученные к этому моменту фрагменты паке-

та отбрасываются, а в узел, пославший исходный пакет, направляется сооб-

щение об ошибке с помощью протокола ICMP.

4.2.3. Межсетевой протокол IPv6

Изменения, внесенные в протокол IPv6 по сравнению с IPv4, сводятся

к следующему:

1) произведено расширение адресации;

2) изменена спецификация формата заголовков;

3) введена возможность задания нескольких заголовков;

4) улучшена поддержка расширений и опций;

5) введена возможность пометки потоков данных;

6) добавлена идентификация и защита частных обменов.

Рассмотрим эти изменения более детально.

Расширение адресации. В IPv6 длина адреса расширена до 128 битов

(против 32 в IPv4), что позволяет обеспечить больше уровней иерархии ад-

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

Для расширения возможности групповой маршрутизации в адресное поле

введено субполе "scope" (группа адресов). Определен новый тип адреса –

Компьютерные сети

280

серверный групповой ("anycast address"), который используется для посылки

запросов клиента любой группе серверов. Групповая адресация предназна-

чена для использования с набором взаимодействующих серверов, чьи адреса

не известны клиенту заранее.

Адресное пространство IPv6 распределяется комиссией по стандарт-

ным числам в Интернет IANA (Internet Assigned Numbers Authority). IANA

делегирует права выдачи IP-адресов региональным сервис-провайдерам,

субрегиональным структурам и организациям. Отдельные лица и организа-

ции могут получить адреса непосредственно от регионального распредели-

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

Спецификация формата заголовков. Некоторые поля заголовка IPv4

исключаются или делаются опционными. Таким образом, снижаются из-

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

шить влияние расширения длины адресов в IPv6.

Наличие нескольких заголовков. Дейтаграмма может содержать

один основной (базовый) и несколько вспомогательных заголовков, за кото-

рыми следуют данные.

Улучшенная поддержка расширений и опций. Изменение кодиро-

вания опций IP-заголовков позволяет облегчить переадресацию пакетов, ос-

лабляет ограничения на длину опций, и делает более доступным введение

дополнительных опций в будущем.

Возможность пометки потоков данных. Она позволяет помечать па-

кеты, принадлежащие определенным транспортным потокам, для которых

отправитель запросил определенную процедуру обработки, например, не-

стандартный тип, вид услуг или обработку данных в реальном масштабе

времени. Это сделано для осуществления возможности передачи по сети с

коммутацией пакетов видео- и аудиоинформации.

Идентификация и защита частных обменов. В IPv6 введена специ-

фикация идентификации сетевых объектов или субъектов, для обеспечения

целостности данных и при желании защиты частной информации.

Основной заголовок протокола IPv6 содержит меньше информации,

чем его предшественник, однако в два раза длиннее заголовка пакета IP.

Формат пакета показан на рисунке 4.10. Большую часть заголовка занимают

адреса отправителя и получателя, длина каждого из которых составляет 16

байт. Остальные поля имеет следующее назначение: Версия (4 бита) – номер

версии Интернет-протокола (для IPv6= 6).

Класс трафика (8 битов) определяет класс пути, который использует-

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

чтобы сеть создала маршрут с минимальной задержкой распространения, что

очень важно, например, при передаче видео- или аудиоинформации.

Раздел 4. Компьютерная сеть Интернет

281

Метка потока (20 битов) служит для использования с новыми прило-

жениями, которые гарантируют заданное качество обслуживания. Метка

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

ленным сетевым маршрутом.

Размер поля данных (16 битов) – код длины поля данных в октетах,

которое следует сразу после заголовка пакета. Если код равен нулю, то дли-

на поля данных записана в специальном поле данных jumbo, которое в свою

очередь хранится в поле опций.

Следующий заголовок (8 битов) идентифицирует тип заголовка, ко-

торый следует непосредственно за IPv6 заголовком. Если дейтаграмма со-

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

заголовка. В случае наличия в пакете только основного заголовка в поле

"Следующий заголовок" указывается код протокола верхнего уровня (TCP

или UDP). Для обозначения протоколов верхнего уровня используются те же

значения, что и в протоколе IP.

Предельное число шагов (8 битов) соответствует полю "Время жиз-

ни" IP-пакета. Оно уменьшается на 1 в каждом узле, через который проходит

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

удаляется.

4.2.3. Способы адресации IPv6

Протоколом IPv6 предусмотрено использовать три типа адресов.

1. Индивидуальный (unicast) адрес соответствует единственному

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

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

2. Адрес набора интерфейсов (anycast) соответствует группе компь-

Рисунок 4.10

–

Формат заголовка пакета IPv6

Компьютерные сети

282

ютеров, имеющих одинаковый адресный префикс (это означает, что они на-

ходятся в одной и той же сети). Пакет, отправленный по этому типу адреса,

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

дится ближе всего к отправителю (в соответствии с мерой, определенной

протоколом маршрутизации).

3. Групповой (multicast) соответствует многим компьютерам, при-

надлежащих разным узлам. Пакет, посланный по групповому адресу, дос-

тавляется всем интерфейсам, заданным этим адресом.

В IPv6 не существует широковещательных адресов, их функции пере-

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

и все единицы, если только не оговорено исключение.

Индивидуальные (уникастные) адреса отличаются от групповых зна-

чением старшего октета: значение FF (11111111) идентифицирует групповой

адрес; любые другие значения свидетельствуют о том, что адрес индивиду-

альный. Наборы адресов (anycast-адреса) берутся из пространства индивиду-

альных адресов, и синтаксически неотличимы от них.

Существует три стандартные формы для представления IPv6 адресов в

виде текстовых строк.

1. Основная форма имеет вид x:x:x:x:x:x:x:x, где “x” шестнадцате-

ричные 16-битовые числа. При этом разрешается не писать начальные нули в

каждом из конкретных полей, но в каждом поле должна быть, по крайней

мере, одна цифра (за исключением случая, описанного в пункте 2).

Например: caf4:defc:ba98:4758:fbdc:632f:4d7e:f3c2 или

2175:0:0:0:6:400:df0C:851b.

2. Специальная форма принята по причине того, что из-за метода за-

писи некоторых типов IPv6 адресов, они часто содержат длинные последова-

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

нулевые биты, более удобной, имеется специальный синтаксис для удаления

лишних нулей. Применение записи вида "::" указывает на наличие групп из

16 нулевых битов. Комбинация "::" может появляться только при записи ад-

реса. Последовательность "::" разрешается также использовать для удаления

из записи начальных или завершающих нулей в адресе. Например: вместо

последовательности ff01:0:0:0:0:0:0:43 можно применять ff01::43.

3. Альтернативная форма записи, которая более удобна при работе с

IPv4 и IPv6; она имеет вид x:x:x:x:x:x:d.d.d.d, где 'x' шестнадцатиричные 16-

битовые коды адреса, а 'd' десятичные 8-битовые, составляющие младшую

часть адреса (стандартное IPv4 представление). Например:

0:0:0:0:0:0:172.3.47.12 или 0:0:0:0:0:facd:64.137.35.44.

IPv6 адреса всех типов ассоциируются с интерфейсами, а не узлами.

Так как каждый интерфейс принадлежит только одному узлу, индивидуаль-

ный (уникастный) адрес интерфейса может идентифицировать узел. IPv6 ин-

Раздел 4. Компьютерная сеть Интернет

283

дивидуальный адрес соотносится только с одним интерфейсом. Одному ин-

терфейсу могут соответствовать много IPv6 адресов различного типа (инди-

видуальный адрес хоста, широковещательные и групповые). Существует два

исключения из этого правила.

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

ским интерфейсам, если приложение рассматривает эти несколько интер-

фейсов как единое целое при представлении его на уровне Интернет.

2. Маршрутизаторы могут иметь ненумерованные интерфейсы (на-

пример, интерфейсу не присваивается никакого IPv6 адреса) для соединений

по схеме точка-точка, чтобы исключить необходимость вручную конфигу-

рировать и объявлять эти адреса. Адреса не нужны также для маршрутизато-

ров, соединенных по схеме точка-точка, если эти интерфейсы не использу-

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

грамм.

Специфический тип IPv6 адресов идентифицируется начальными би-

тами адреса. Поле переменной длины, содержащее эти начальные биты, на-

зывается префиксом формата FP (Format Prefix).

Индивидуальный адрес хоста вида 0:0:0:0:0:0:0:1 называется адресом

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

мому себе. Его нельзя использовать в качестве идентификатора интерфейса.

Адрес обратной связи не должен применяться в качестве адреса отправителя

в IPv6 дейтаграммах, которые посылаются за пределы узла. IPv6 дейтаграм-

ма с адресом обратной связи в качестве адреса места назначения также не

может быть послана за пределы узла.

4.3. Протоколы транспортного уровня UDP и TCP

4.3.1. Назначение и разновидности протоколов транспортного уровня

Протоколы транспортного уровня предназначены для обеспечения не-

посредственного информационного обмена между двумя пользовательскими

процессами. Для организации информационного взаимодействия на транс-

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

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

интерфейсом транспортного уровня.

В качестве протоколов транспортного уровня в сети Интернет исполь-

зуются два протокола:

 протокол передачи пользовательских дейтаграмм UDP (User

Datagram Protocol);

Компьютерные сети

284

 протокол управления передачей TCP (Transmission Control

Protocol).

Протокол UDP реализует негарантированную доставку сообщений в

сети Интернет. Протокол может быть использован в тех приложениях, кото-

рые либо не нуждаются в таком качестве, либо гарантия доставки обеспечи-

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

кол UDP, являются службы TELNET и TFTP. Протокол TCP применяется

для создания надежного информационного обмена на транспортном уровне в

сетях Интернет.

Протокол пользовательских дейтаграмм передает сообщение в виде

отдельных независимых информационных блоков – дейтаграмм. Каждая

порция данных (запись), которую приложение передает модулю UDP, вос-

принимается последним, как отдельное сообщение. UDP формирует из него

дейтаграмму, длина которой соответствует размеру полученной порции дан-

ных. Таким образом, протокол UDP при передаче данных сохраняет границы

сообщений. При дейтаграммной связи нет необходимости устанавливать и

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

таграмм прост в реализации, однако, не обеспечивает гарантированной и

безошибочной доставки сообщений.

Существует достаточно много причин, которые могут помешать паке-

ту, передаваемому в сети, успешно достичь станции назначения. Поэтому,

если не будут использованы специальные методы для обеспечения гаранти-

рованной доставки, принятое сообщение может существенным образом от-

личаться от переданного.

В протоколе гарантированной доставки решаются следующие задачи:

 реализация потокового обмена;

 установка виртуальных соединений;

 буферизация передачи данных;

 защита от ошибок;

 обмен в режиме полного дуплекса;

 установка таймеров обмена;

 контроль потока данных.

Потоковый обмен протокола характеризуется тем, что протокол ТСР

рассматривает данные приложения, как поток байтов (октетов). ТСР делит

этот поток на части, равные заданной длине сегмента. Если входной поток

меньше длины сегмента, то модуль ТСР буферизирует входные данные,

стремясь сформировать полноразмерный сегмент. По этой причине протокол

ТСР не сохраняет границы сообщений. Так, если приложение передало N

блоков данных, то это не означает, что модуль ТСР отправит N сегментов.

Реализация потокового обмена позволяет обеспечить такой режим информа-

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

Раздел 4. Компьютерная сеть Интернет

285

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

Протокол ТСР управляет логическим сеансом связи. Он устанавливает,

поддерживает и закрывает соединение между процессами, проводит по мере

необходимости процедуры аутентификации. В процессе информационного

обмена через установленное соединение обе стороны контролируют его ка-

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

цесс разрыва соединения и формируют соответствующие сообщения для

протоколов верхних уровней.

Применение буферизации позволяет согласовать скорость информаци-

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

пользователя.

В транспортном протоколе TCP осуществляется расчет контрольной

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

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

рируется. Получатель ожидает, пока отправитель выждет тайм-аут и осуще-

ствит повторную передачу.

TCP не интерпретирует содержимое байтов и не проверяет, происхо-

дит ли обмен двоичными данными, символами ASCII, EBCDIC либо другими

символами. Эта интерпретация потока байтов осуществляется приложения-

ми на каждой стороне соединения.

Для обеспечения требования доставки трафика, чувствительного к

временным задержкам, в дополнение к буферу может быть реализован до-

полнительный механизм проталкивания "push". Использование данного

механизма обеспечивает немедленную выдачу содержимого буфера в тот

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

держкам.

TCP осуществляет контроль потока данных, позволяя источнику по-

сылать данные только в том случае, если получатель имеет возможность по-

местить их в буфер. Это предотвращает переполнение буферов медленных

хостов информацией от быстрых источников.

Для обеспечения гарантированной доставки сообщений протокол TCP

использует аппарат позитивного квитирования с повторной передачей (ре-

шающая обратная связь). Обычно при использовании данной схемы получа-

тель информации посылает специальный сигнал (квитанцию) ACK в под-

тверждение ее получения. Дальнейшее выполнение информационного обме-

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

чит такое подтверждение.

В случае процедуры с ожиданием подтверждения передающая сторона

приостанавливает передачу очередного сегмента до получения сигнала под-

тверждения АСК о приеме предыдущего сегмента (рисунок 4.11).

Компьютерные сети

286

Интервал ожидания устанавливается равным значению задержки по-

вторной передачи – Retransmit Timer. Если в течение этого интервала време-

ни не будет получено подтверждение о приеме переданного сегмента, пере-

дача данного сегмента выполняется повторно.

Применение процедуры ожидания квитанции подтверждения (квити-

рования) не обеспечивает достаточную эффективность использования про-

пускной способности каналов передачи данных. Около половины времени

сеанса связи системы ожидают получения подтверждения. Более эффектив-

ной в этом смысле является процедура квитирования с применением сколь-

зящего окна, позволяющая передающей стороне отправить несколько сег-

ментов сообщения, не дожидаясь получения подтверждения о приеме.

Максимальное число сегментов, которые передающая сторона может

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

ОКНОМ. При использовании механизма окна принимающая сторона может

передавать подтверждение на получение сразу нескольких сегментов. В

транспортном протоколе TCP процедура скользящего окна реализуется

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

порядковый номер.

Для реализации процедур управления процессом передачи применяет-

ся три указателя (см. п.1.5.3):

 первый указывает границу между последним байтом, который был пе-

редан и получение которого подтверждено, и первым переданным, но непод-

твержденным байтом;

 второй – указывает границу между последним переданным байтом,

Рисунок 4.11

–

Процедура передачи сегментов с ожиданием подтвержден

Раздел 4. Компьютерная сеть Интернет

287

подтверждение о получении для которого еще не получено, и первым бай-

том, который может быть выдан в канал, до получения подтверждения о

приеме предыдущих переданных байтов;

 третий – указывает границу между последним байтом, который может

быть передан до получения подтверждения о приеме предыдущих передан-

ных байтов и остальной частью информационного потока.

Процедура управления потоком заключается в согласовании скорости

передачи данных с пропускной способностью канала. Для обеспечения

управления потоком в протоколе TCP предусмотрена возможность измене-

ния размера окна. Каждое сообщение подтверждения содержит в себе значе-

ние представляемого размера окна – (window advertisement), определяющее

размер буфера, который может быть использован в текущий момент для

приема информации.

Применение скользящего окна для управления информационным по-

током делает ненужным реализацию дополнительных механизмов для

управления переполнением.

Большинство протоколов приложений используют услуги ТСР, среди

них Webserver (HTTP-протокол, порт 80), FTP-Server (FTP-протокол, порт

21), Электронная почта (SMTP-протокол, порт 25) и др.

4.3.2. Протокол передачи пользовательских дейтаграмм UDP

Протокол передачи пользовательских дейтаграмм UDP (User Datagram

Protocol) яляется одним из основных протоколов, расположенных непосред-

ственно над IP. Он предоставляет прикладным процессам транспортные ус-

луги, немногим отличающиеся от услуг протокола IP. Протокол UDP обес-

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

UDP-протокол также не требует соединения с удаленным модулем UDP. К

заголовку IP-пакета агент udp добавляет поля "Порт отправителя" и "Порт

получателя", которые обеспечивают мультиплексирование информации ме-

жду различными прикладными процессами, а также поля "Длина UDP-

дейтаграммы" и "Контрольная сумма", позволяющие проверять целостность

данных. Таким образом, если на уровне IP для определения места доставки

пакета используется адрес, на уровне UDP – номер порта.

Примерами сетевых приложений, использующих UDP-протокол, яв-

ляются сетевая файловая система NFS, упрощенный протокол передачи фай-

лов TFTP, удаленный вызов процедуры RPC (Remote Procedure Call), про-

стой сетевой протокол управления SNMP и доменная служба имен DNS.

Широкое применение протокола обусловлено невысокой избыточностью

Компьютерные сети

288

дейтаграммы и отсутствием необходимости подтверждения получения па-

кета.

Прикладные процессы и модули UDP взаимодействуют через UDP-

порты. Эти порты нумеруются, начиная с нуля. Прикладной процесс, пре-

доставляющий некоторые услуги (сервер), ожидает сообщений, направлен-

ных в порт, специально выделенный для этих услуг. Программа-сервер на-

ходится в состоянии ожидания до тех пор, пока какая-нибудь программа-

клиент запросит услугу. Например, сервер snmp всегда ожидает сообщения,

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

сылает запрос в UDP-порт 161 на компьютер, где работает сервер. На каж-

дом компьютере может быть только один агент snmp, так как существует

только один порт 161. Данный номер порта является общеизвестным, т.е.

имеющий фиксированный номер, официально выделенный в сети Интернет

для услуг SNMP.

Данные, отправляемые прикладным процессом через модуль UDP,

достигают места назначения как единое целое. Например, если процесс-

отправитель производит 5 записей в порт, то процесс-получатель должен бу-

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

дать с размером каждого записанного. Протокол UDP сохраняет границы

сообщений, определяемые прикладным процессом. Он никогда не объеди-

няет несколько сообщений в одно и не делит одно сообщение на части. Фор-

мат UDP-дейтаграммы изображен на рисунке 4.12.

Протокол использует заголовок минимального размера (8 байтов).

Длина сообщения равна числу байт в UDP-дейтаграмме, включая заголовок.

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

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

Модуль IP передает поступающий IP-пакет модулю UDP, если в заго-

ловке этого пакета указан код протокола UDP. Когда модуль UDP получает

дейтаграмму от модуля IP, он проверяет контрольную сумму, содержащуюся

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

Рисунок 4.12 – Формат UDP-дейтаграммы