Главная » Все файлы » Просмотр файлов из архивов » Документы » Методические указания к ЛР №1-3_ГРУППА_93

Методические указания к ЛР №1-3_ГРУППА_93 (Методические указания по лабораторным работам 1, 2 и 3)

Описание файла

Файл "Методические указания к ЛР №1-3_ГРУППА_93" внутри архива находится в папке "Методические указания по лабораторным работам 1, 2 и 3". Документ из архива "Методические указания по лабораторным работам 1, 2 и 3", который расположен в категории "книги и методические указания". Всё это находится в предмете "системы передачи данных" из девятого семестра, которые можно найти в файловом архиве МГТУ им. Баумана. Не смотря на прямую связь этого архива с МГТУ им. Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "книги и методические указания", в предмете "системы передачи данных" в общих файлах.

Онлайн просмотр документа "Методические указания к ЛР №1-3_ГРУППА_93"

Текст из документа "Методические указания к ЛР №1-3_ГРУППА_93"

МГТУ им.Н.Э.Баумана

Кафедра “Системы обработки информации и управления”

Методические указания

к лабораторным работам по курсу “Системы передачи данных”

Лабораторная работа №1

Изучение возможностей сетевого анализатора.

Лабораторная работа №2

Исследование протоколов сетевого уровня IP-сетей с помощью анализатора протоколов.

Лабораторная работа №3

Исследование протоколов транспортного уровня IP-сетей с помощью анализатора протоколов.

Разработал: к.т.н., доцент Галкин В.А.

Москва 2008 г.

Цель работы. Развитие практических навыков работы с протоколами стека ТСР/IP и исследование возможностей протоколов ICMP, UDP, TCP.

Необходимое оборудование:

Аппаратные требования

  • IBM - совместимый ПК в составе сети Интернет.

  • 128 Мбайт оперативной памяти

  • 5 Мбайт свободного места на HDD

  • Используемый шлюз в Интернет должен пропускать ICMP, TCP и UDP трафик.

Программные требования

- Операционная система - Windows 2000/XP

- Доступ к ресурсам системы с правами администратора (в программе MFC-snif используются RAW сокеты)

- NetInfo v.3.5 – программа сетевого сервиса.

- Пакетные анализаторы Ethereal-0.99.0 и MFC-snif (Разработан студентами каф.ИУ5 МГТУ им. Н.Э.Баумана Тигановым Максимом, Самилло Николаем и Поляковым Евгением).

Требуемое время для выполнения: 9 часов. (1 час изучение возможностей и правил работы с сетевым анализатором, 4 часа с пакетным анализатором Ethereal и 4 часа с пакетным анализатором MFC-snif )

1. Общие сведения из теории.

Протоколы - это правила работы программного обеспечения.

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

Термин "стек протоколов" происходит из концепции представления сети в виде вертикально расположенных уровней и сложенных в стек протоколов и относится к любой комбинации сетевых уровней и соответствующих протоколов.

В настоящей лабораторной работе предметом исследований является стек протоколов TCP/IP – наиболее распространенный и являющийся основным в сети Интернет.

IP (Internet Protocol) - протокол межсетевого взаимодействия, является протоколом сетевого уровня модели OSI и отвечает за перемещение данных между сетевыми компьютерами в Интернет.

ТСР(Transmission Control Protocol) - протокол управления передачей, который перемещает данные между прикладными программами.

UDP (User Datagram Protocol) - протокол пользовательских дейтаграмм, который также перемещает данные между приложениями. Он - более простой и менее надежный, чем ТСР.

ICMP (Internet Control Message Protocol) - протокол управляющих сообщений Интернет, который управляет сетевыми сообщениями об ошибках и другими ситуациями, требующими вмешательства сетевых программ.

    1. Схема движения данных.

Данные по сети передаются в три этапа:

Информация должна пройти между приложениями и сетью. Это путь сквозь стек протоколов вниз к транспортному уровню.

Определение сетью адреса получателя данных.

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

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

Рис. 1. Схема движения данных пользователя.

    1. Протокол IP

Формат IP-дейтаграммы и поля заголовка представлены на рис.2.

Поля IP - протокола.

Номер версии VERS. Протокол IP постоянно развивается, необходимо знать, номер версии, чтобы правильно интерпретировать дейтаграмму.

Длина заголовка (HLEN) в 32 разрядных словах. Чаще всего длина IP-заголовка равна 20 байтам, поэтому данное поле обычно содержит число 5 (0101).

Тип сервиса (TOS). Поле "тип сервиса" разделено на 5 подразделов (рис.3).



Рис. 2. Формат IP-дейтаграммы и поля заголовка.

Рис. 3. Формат поля TOS.

Первое трехразрядное субполе приоритет(precedence) редко применяется на практике. Последнее безымянное одноразрядное субполе всегда содержит 0. Между ними находятся четыре одноразрядных субполя, которые и называют собственно битами TOS. Каждому из четырех битов TOS сопоставлен определенный критерий доставки дейтаграмм: минимальная задержка, максимум пропускной способности, максимум надежности и минимум стоимости. Только один бит TOS может быть установлен в 1. По умолчанию все четыре бита равны 0, что означает отсутствие особых требований, то есть обычный сервис.

Длина пакета. Поле "длина пакета" задает длину IP-пакета, включая сам заголовок. Если локальная сеть построена по технологии Ethernet, уровень соединения инкапсулирует IP-дейтаграммы в кадры Ethernet перед передачей их в Интернет. Спецификация Ethernet ограничивает длину пакета до 1500 байтов.

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

Флаги и смещение. Информация, содержащаяся в полях идентификации флагов и смещения фрагмента позволяет правильно собрать фрагментированный пакет.

Время существования (TTL). Время существования определяет «время жизни» пакета в сети и не дает пакету возможность быть вечным скитальцем.

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

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

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

Адрес получателя. Адрес получателя является 32-битным адресом пункта назначения пакета. В случае широковещательной передачи он состоит из единиц.

Опции IP. Это поле позволяет тестировать разнообразные сетевые приложения.

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

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

Рис. 4. Структура UDP – заголовка.

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

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

1.4. Протокол TCP

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

TCP пытается оптимизировать пропускную способность сети, то есть увеличивает производительность доставки пакетов в Интернет. Для этого он динамически управляет потоком данных в соединении. Если буфер приемника данных переполняется, TCP просит передающую сторону снизить скорость передачи.

Данные TCP всегда переносит IP, то есть данные TCP всегда упаковываются в IP-дейтаграммы.

Для обеспечения надежной доставки и правильной последовательности данных в потоке TCP пользуется принцип скользящего окна и тайм-аута. Принцип скользящего окна позволяет послать несколько сообщений и только потом ожидать подтверждения. ТСР накладывает окно на поток данных, ожидающих передачи, и передает все данные, попавшие в окно. Приняв подтверждение о доставке всех данных, ТСР перемещает окно дальше по потоку и передает следующие попавшие в него сообщения. Работая сразу с несколькими сообщениями, ТСР может одновременно "выставить" их на сетевой канал и только потом ожидать прихода подтверждения. Метод скользящего окна значительно увеличивает производительность соединения, а также эффективность циклов обмена сообщениями и подтверждениями об их доставке.

0 15

16 31

Порт источника 16 бит

Порт назначения 16 бит

Позиционный номер 32 бита

Квитанция 32 бита

Длина заголовка 4 бита

Резерв 16 бит

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

Размер окна приема 16 бит

Контрольная сумма 16 бит

Указатель границы срочных данных 16 бит

Опции (если таковые имеются)

Данные (если таковые имеются)

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

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

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

Как правило, модуль ТСР передает несколько сегментов, прежде чем скользящее окно заполнится целиком. Большинство систем в Интернет устанавливают окно равным по умолчанию 4096 байтам. Иногда размер окна равен 8192 или 16384 байтам

Заголовок сегмента TCP представлен на рис.5. Обычно (при отсутствии опций) заголовок имеет размер 20 байтов. Напомним, что передаваемый TCP – сегмент с данными инкапсулируется в IP – дейтаграмму.

Номера портов источника и назначения (source port number и destination port number) идентифицируют взаимодействующие приложения.

Позиционный номер (sequence number) сегмента указывает то место в потоке данных от источника до конечного получателя, которое занимает первый байт содержащихся в этом сегменте данных. В начальном сегменте, посылаемом при установлении соединения, присутствует флаг SYN, а в поле позиционный номер содержится так называемый начальный позиционный номер ISN(initial sequence number), выбранный данным хостом для этого нового соединения. Первому байту данных, переданному хостом по новому соединению, будет присвоен позиционный номер, равный ISN+1. Такой сдвиг в нумерации кратко формулируется правилом: флаг SYN поглощает одну позицию.

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

Поле размер заголовка (header length) необходимо, поскольку в заголовке далее могут следовать поля опций переменной длины. Записанная в этом поле константа означает число отводимых под заголовок 32-разрядных слов, и, следовательно, длина заголовка не превышает 60 байтов. При отсутствии опций размер заголовка всегда равен 20 байтам.

В TCP-заголовке предусмотрены 6 двоичных флагов (flags) , причем некоторые из них могут быть установлены одновременно.

URG – флаг срочных данных. Поле указатель границы срочных данных заголовка имеет смысл только при URG =1

ACK – флаг квитирования. Поле квитанция имеет смысл только при ACK = 1.

PSH – флаг «проталкивания» (push). TCP-модуль хоста назначения должен незамедлительно отдать данные из сегмента своему приложению.

RST – флаг сброса соединения.

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