Методические указания к ЛР №1-3_ГРУППА_94 (Методические указания по лабораторным работам 1, 2 и 3), страница 2
Описание файла
Файл "Методические указания к ЛР №1-3_ГРУППА_94" внутри архива находится в папке "Методические указания по лабораторным работам 1, 2 и 3". Документ из архива "Методические указания по лабораторным работам 1, 2 и 3", который расположен в категории "". Всё это находится в предмете "системы передачи данных" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "книги и методические указания", в предмете "системы передачи данных" в общих файлах.
Онлайн просмотр документа "Методические указания к ЛР №1-3_ГРУППА_94"
Текст 2 страницы из документа "Методические указания к ЛР №1-3_ГРУППА_94"
PSH – флаг «проталкивания» (push). TCP-модуль хоста назначения должен незамедлительно отдать данные из сегмента своему приложению.
RST – флаг сброса соединения.
SYN – флаг синхронизации позиционных номеров сегментов при установлении соединения.
FIN – флаг окончания передачи. Он означает, что источник сегмента закончил передачу данных и закрывает свой канал вывода в текущем соединении.
Темп передачи потока данных в каждом направлении по TCP-соединению регулируется обеими участвующими в обмене сторонами благодаря тому, что каждая сторона объявляет свой размер окна приема (window size), то есть количество байтов, которое она в данный момент готова принять вслед за байтом, номер которого указан в поле квитанция.
Поле контрольная сумма (TCP – checksum) содержит значение, подсчитанное для всего сегмента, включая его заголовок и данные.
Указатель границы срочных данных (urgent pointer) действует лишь при условии, что в сегменте установлен флаг URG. Это положительная константа, равная смещению номера последнего байта срочных данных относительно позиционного номера в заголовке сегмента. Срочный режим (urgent mode) предусмотрен в TCP, чтобы в поток передаваемых обычных данных приложение могло внедрять цепочки каких-либо особым образом интерпретируемых байтов (например, команд) так, чтобы они были обнаружены и выделены из потока на принимающей стороне.
1.4.1. Открытие TCP соединения
Открытие TCP-соединения состоит из трех фаз.
-
Запрашивающая сторона (обычно это клиент) посылает сегмент с флагом SYN, указывая номер порта получателя (сервера) с которым хочет соединиться, а также начальный позиционный номер ISN(initial sequence number).
-
Сервер отвечает сегментом SYN, где сообщает свой начальный позиционный номер и одновременно подтверждает получение сегмента SYN от клиента – он устанавливает флаг ACK, а в качестве подтверждаемого позиционного номера указывает номер, на единицу больше принятого, то есть ISN клиента плюс один.
-
Клиент подтверждает получение сегмента SYN от сервера, выслав сегмент с флагом ACK и номером квитанции, равным принятому от сервера начальному позиционному номеру ISN плюс один.
Обмен этими тремя сегментами и составляет процедуру установления соединения. Часто такой механизм называют троекратным рукопожатием (three-way handshake).
1.4.2. Закрытие TCP соединения
Если для установления соединения необходим обмен тремя сегментами, то для его закрытия таковых требуется четыре. Поскольку соединение TCP является полнодуплексным (то есть данные могут передаваться в обоих направлениях независимо), каждое направление необходимо закрывать по отдельности. Закрытие одного направления называется полузакрытием (half-close). Согласно протоколу любая из сторон, закончив передачу данных, может послать сегмент FIN. Когда TCP-модуль получает сегмент FIN, он обязан уведомить обслуживаемое приложение, что другая сторона закрыла свое направление передачи данных.
Приход FIN означает лишь то, что поступление данных от партнера по этому соединения прекращается. Но TCP-модуль может посылать данные и после получения им FIN. Предоставляемая приложению возможность продолжать передачу по полузакрытому соединению на практике используется редко.
Говорят, что сторона, первой закрывающая соединение (то есть посылающая первый FIN), производит активное закрытие соединения (active close). Другая сторона (которая получает этот FIN и отвечает на него своим FIN) выполняет пассивное закрытие соединения(passive close). Итак:
-
TCP-модуль одной из сторон посылает сегмент FIN и тем самым закрывает поток данных со своей стороны.
-
В ответ на пришедший FIN TCP-модуль второй стороны посылает подтверждение полученного позиционного номера плюс один.
-
Приложение на второй стороне закрывает свой поток данных, и его TCP-модуль посылает FIN.
-
Первый хост отвечает сегментом ACK с квитанцией, равной позиционному номеру полученного им сегмента FIN плюс один.
1.5. Протокол управляющих сообщений ICMP
Протокол ICMP (Internet Control Message Protocol) служит для обмена сообщениями об ошибках и различных особых случаях, требующих обработки. ICMP-сообщения содержат управляющие данные, используемые либо на IP-уровне, либо на более высоком уровне (TCP или UDP). Некоторые ICMP-сообщения трансформируются в коды ошибок, возвращаемых пользовательским процессам. В иерархии протоколов ICMP часто относят к сетевому уровню, наряду с IP, но ICMP-сообщения инкапсулируются в IP-диаграммы. Структура ICMP-сообщения представлена на рис.6.
| 0 7 | 8 15 | 16 31 |
| Тип (8 бит) | Код (8 бит) | Контрольная сумма(16 бит) |
| Содержание сообщения(зависит от типа и кода) | ||
Рис.6. Структура ICMP-сообщения
Первое слово(4 байта) содержит три поля, общие по смыслу и формату для любых разновидностей сообщений. Следующая затем содержательная часть сообщения форматируется по-разному в зависимости от типа сообщения.
Предусмотрено 15 различных значений для поля тип (type), которое идентифицирует разновидность ICMP-сообщения. Кроме того, некоторые типы ICMP-сообщений дополнительно используют значения поля код(code) для конкретизации тех или иных условий.
Поле контрольная сумма (checksum) относится ко всему ICMP-сообщению и является обязательным
1.5.1. Разновидности ICMP – сообщений
В таблице 1 приведены всевозможные разновидности ICMP-сообщений, определяемые полями тип(type) и код (code). Последние два столбца таблицы позволяют отличить запросы и отклики на них от сообщений об ошибках. Необходимо различать эти
Таблица 1 Разновидности ICMP-сообщений
| Тип | Код | Описание | Запрос/Ответ | Ошибка |
| 0 | 0 | Эхо-ответ (echo reply) | + | |
| 3 | Адресат недоступен(destination unreachable) | |||
| 0 | сеть недоступна | + | ||
| 1 | хост недоступен | + | ||
| 2 | протокол недоступен | + | ||
| 3 | порт недоступен | + | ||
| 4 | необходима фрагментация, но есть флаг DF | + | ||
| 5 | маршрутизация от источника невыполнима | + | ||
| 6 | сеть назначения неизвестна | + | ||
| 7 | хост назначения неизвестен | + | ||
| 8 | хост источника изолирован(устарело) | + | ||
| 9 | сеть назначения административно закрыта | + | ||
| 10 | хост назначения административно закрыт | + | ||
| 11 | сеть недоступна для данного типа сервиса TOS | + | ||
| 12 | хост недоступен для данного типа сервиса TOS | + | ||
| 13 | связь административно закрыта фильтром | + | ||
| 14 | нарушение старшинства хостов | + | ||
| 15 | действует отключение по старшинству | + | ||
| 4 | 0 | Прикрыть источник(source quench) | + | |
| 5 | Перенаправление(redirect) | |||
| 0 | перенаправить путь на сеть | + | ||
| 1 | перенаправить путь на хост | + | ||
| 2 | перенаправить путь на сеть для типа сервиса TOS | + | ||
| 3 | перенаправить путь на хост для типа сервиса TOS | + | ||
| 8 | 0 | Эхо-запрос(echo request) | + | |
| 9 | 0 | Объявление маршрутизатора(router advertisment) | + | |
| 10 | 0 | Запрос маршрутизатора(router solicitation) | + | |
| 11 | Срок истек(time exceeded) | |||
| 0 | срок истек на переходе(TTL = 0) | + | ||
| 1 | срок истек при сборке | + | ||
| 12 | Нарушены параметры дейтаграммы | |||
| 0 | испорчен IP-заголовок | + | ||
| 1 | отсутствует необходимая опция | + | ||
| 13 | 0 | Запрос отсчета времени(timestamp request) | + | |
| 14 | 0 | Отклик отсчета времени(timestamp reply) | + | |
| 15 | 0 | Запрос информации(устарело) | + | |
| 16 | 0 | Информационный отклик(устарело) | + | |
| 17 | 0 | Запрос адресной маски(address mask request) | + | |
| 18 | 0 | Ответ адресной маски(address mask reply) | + |
две разновидности, потому что обработка ICMP-сообщения об ошибке имеет свою специфику.
В ICMP-сообщении об ошибке всегда возвращается IP-заголовок и первые 8 байтов IP-дейтаграммы, признанной ошибочной. Это позволяет ICMP-модулю сопоставить полученное им сообщение об ошибке с конкретным протоколом TCP или UDP(по значению поля протокол в возвращенном IP-заголовке) и с конкретным пользовательским процессом (по номеру порта, который находится в TCP или UDP-заголовке в возвращенных первых 8 байтах IP-дейтаграммы)
ICMP-сообщение об ошибке никогда не генерируется в ответ на следующие пакеты:
-
На ICMP-сообщение об ошибке.
-
На дейтаграмму, посланную по широковещательному IP-адресу или групповому IP-адресу.
-
На какой-либо фрагмент дейтаграммы, кроме первого ее фрагмента.
-
На дейтаграмму, в которой адрес источника не определяет конкретный хост. Это означает, что адрес источника не может быть нулевым адресом, адресом внутренней петли хоста (loopback) и не может быть широковещательным или групповым адресом.
Эти правила предназначены для предотвращения так называемых широковещательных штормов(broadcast storms).
1.6. Как работает Ping
Программа проверяет доступность зондируемого ею объекта в сети подобно локатору: посылает хосту ICMP-сообщение эхо-запрос (echo request) и ждет от него эхо-отклик (echo reply).
Эта утилита внешне действует подобно клиенту, а адресуемый хост, от которого приходит отклик, выступает в роли сервера. Однако на самом деле обработка эхо-запросов и генерация откликов осуществляется не каким-либо пользовательским процессом, а непосредственно ядром.
Формат ICMP сообщений, содержащих эхо-запрос или эхо-отклик, представлен на рис.7
| 0 7 | 8 15 | 16 31 | |
| Тип (0 или 8) | Код (0) | Контрольная сумма | |
| Идентификатор | Порядковый номер | ||
| Необязательные данные | |||
Рис.7. Формат ICMP сообщений
Как и при обработке любых других ICMP-запросов, в ответном сообщении возвращаются поля идентификатор (identifier) и порядковый номер (sequence number) запроса. Также должны быть возвращены и содержащиеся в запросе необязательные данные(optional data), так как они используются источником запроса при интерпретации пришедшего на запрос ответа.
Unix-реализации программы Ping фиксируют в поле идентификатор (identifier) ICMP-сообщения свой системный идентификатор процесса (process ID), пославшего сообщение. Это в последствии позволяет правильно распределять возвращенные ответы, когда на одном хосте параллельно работают несколько копий Ping.
