Амато В. - Основы организации сетей Cisco. Том 1 (2002)(ru)

Формат сегмента протокола TCP

На рис. 10.4 показаны поля TCP-сегмента, которые определяются следующим образом.

∙Порт источника — номер вызывающего порта.

∙Порт назначения — номер вызываемого порта.

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

∙Номер подтверждения — следующий ожидаемый ТСР-октет.

∙HLEN — количество 32-разрядных слов в заголовке.

∙Зарезервированое (поле) — все биты установлены в значение 0.

∙Биты кода — служебные функции (например, установка и завершение сеанса).

∙Окно — количество октетов, с которым отправитель готов согласиться.

∙Контрольная сумма — расчетная контрольная сумма заголовка и полей данных.

∙Указатель срочных данных — указывает конец срочных данных.

∙Опция — в настоящее время определена одна: максимальный размер ТСР-сегмента.

∙Данные — данные протокола более высокого уровня.

Количество битов

16		16		32		32	4	6		6
Порт		Порт		Порядковый номер		Номер	HLEN		Зарезервированное	Биты
источника		назначения				подтверждения				кода
16		16		16		0 или 32
Окно		Контрольна		Указатель срочных		Опция			Данные
		я сумма		данных

Рис. 10.4 Формат ТСР-сегмента включает 12 полей

Номера портов

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

Разработчики прикладного программного обеспечения договорились пользоваться широко известными номерами портов, определенными в документе RFC 1700. Например, любой обмен, связанный с пересылкой файлов по протоколу FTP, использует стандартный номер порта 21 (см. рис. 10.5).

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

Таблица 10.1 Зарезервированные номера портов в протоколах NCP и UDP

Десятичн	Ключевое	Описание
ый номер	слово
0	—	Зарезервирован
1-4	—	He назначен
5	пе	Удаленный ввод заданий
7	echo	Эхо
9	discard	Отбросить
11	users	Активные пользователи
13	daytime	Днем
15	netstat	Кто активен, или сетевая статистика
17	quote	Кавычки дня
19	chargen	Генератор символов
20	ftp-data	Протокол FTP (данные)
21	ftp	Протокол FTP
23	telnet	Терминальное соединение
25	smtp	Простой протокол передачи почтовых сообщений (SMTP)
37	time	Время суток
39	rip	Протокол указания местонахождения ресурсов (RLP)
42	nameserver	Сервер имен хост-машин
43	nicname	Кто?
53	domain	Сервер имен домена (DNS)
67	bootps	Сервер задачи начальной загрузки
68	bootpc	Клиент задачи начальной загрузки
69	tftp	Протокол TFTP
75	—	Любая частная служба подключения к внешним сервисам по
77	—	телефонной линии
		Любая частная служба удаленного ввода задания

79	finger	Служба определения активных клиентов в сети
123	ntp	Протокол сетевого времени (NTP)
133-159	—	Не назначены
160-223	—	Зарезервированы
224-241	—	Не назначены
242-255	—	Не назначены

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

•Номера меньше 255 предназначаются для приложений общего пользования.

•Номера от 255 до 1023 отданы компаниям для продаваемых приложений.

•Использование номеров более 1023 не регламентируется.

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

Открытое TCP-соединение с трехсторонним квитированием

Для установления или инициализации соединения как бы два протокола TCP используют не сам TCP, а процессы или конечные станции, и должны синхронизировать начальные порядковые номера (ISN) сегментов друг друга для данного соединения. Порядковые номера используются для того, чтобы отслеживать последовательность обмена и гарантировать отсутствие потерянных фрагментов данных, которые требуют для пересылки нескольких пакетов. Начальный порядковый номер представляет собой стартовый номер, используемый при установлении TCP-соединения. Об-

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

Синхронизация выполняется путем обмена сегментами, несущими номера ISN и управляющий бит, называемый SYN (от английского synchronize — синхронизировать). (Сегменты, содержащие бит SYN, тоже называются SYN.) Для успешного соединения требуется наличие подходящего механизма выбора начального порядкового номера и слегка запуганный процесс квитирования, который обеспечивает обмен значениями ISN.

Процесс синхронизации требует, чтобы каждая сторона послала свой номер ISN и получила потверждение и ISN от другой стороны соединения. Каждая сторона должна принимать ISN от другой стороны и посылать положительное подтверждение (АСК) в определенном порядке, который

описан в следующей последовательности шагов.

1.А > В SYN — мой порядковый номер X.

2.А < В АСК — твой порядковый номер X.

3.А < В SYN — мой порядковый номер Y.

4.А > В АСК — твой порядковый номер Y.

Так как второй и третий шаги могут объединяться в одном сообщении, то такой обмен называется открытым с трехсторонним квитированием (three-way handshake/open). Как показано на рис. 10.7, обе стороны соединения синхронизируются, выполняя последовательность открытого соединения с трехсторонним квитированием.

Эта последовательность похожа на разговор двух людей. Первый хочет поговорить со вторым и говорит: "Я бы хотел с вами поговорить" (SYN). Второй отвечает: "Хорошо, я хочу с вами говорить" (SYN, ACK). Тогда первый говорит: "Прекрасно, давайте поговорим" (АСК).

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

SYN.

В этот момент времени любая из сторон либо может начать обмен данными, либо разорвать связь, поскольку протокол TCP является методом одноранговой (равноправной) связи.

Простое подтверждение и работа с окнами в протоколе

TCP

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

Размер окна определяет объем данных, который может принять принимающая станция за один раз. Если размер окна равен 1, подтверждаться должен каждый сегмент, и только после этого передается следующий. Это приводит к неэффективному использованию хост-машиной полосы пропускания.

Целью введения механизма окон является улучшение управления потоком И надежности. К сожалению, и это видно из рис. 10.8, при размере окна, равном 1, наблюдается неэффективное использование полосы пропускания.

Скользящие окна в протоколе TCP

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

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

Порядковые номера и номера подтверждений в протоколе TCP

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

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

Формат сегмента в протоколе UDP

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

К протоколам, которые используют UDP, относятся TFTP, SNMP, сетевая файловая система (NFS) и система имен домена (DNS). Как видно из рис. 10.11, размер заголовка в протоколе UDP относительно небольшой.

TCP/IP и межсетевой уровень

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

Как показано на рис. 10.12, на межсетевом уровне протокола TCP/IP (который соответствует сетевому уровню модели OSI) функционирует несколько протоколов.

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

•Межсетевой протокол управляющих сообщений (Internet Control Message Protocol, ICMP), который обеспечивает возможности по управлению и передаче сообщений.

•Протокол преобразования адреса (Address Resolution Protocol, ARP), определяющий канальный адрес по известному IP-адресу.

•Протокол обратного преобразования адреса (Reverse Address Resolution Protocol, RARP),

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

IР-дейтаграмма

На рис. 10.13 изображен формат IP-дейтаграммы, которая содержит IP-заголовок и данные, окруженные с одной стороны заголовком уровня управления доступом к среде (MAC), а с другой — концевым завершителем МАС-уровня.

Количество битов

4

4

8

16

16

3

13

8

Тип

Общая

Метка

Смещение

VERS

HLEN

идентифика

Флаги

TTL

сервиса

длина

фрагмента

ции

8

16

32

32

var

Протокол

Контрольная

IP-адрес

IP-адрес

IP опции

Данные

сумма

отправителя

получателя

заголовка

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

Определения полей внутри этой IP-дейтаграммы выглядят следующим образом.

∙VERS — номер версии.

∙HLEN — длина заголовка в 32-разрядных словах.

∙Тип сервиса — как дейтаграмма должна обрабатываться.

∙Общая длина — общая длина (заголовок плюс данные).

∙Метка идентификации, флаги и смещение фрагмента — обеспечивают фрагментацию

дейтаграмм с целью обеспечения возможности подстройки под различные размеры максимального блока передачи (MTU) в сети Internet.

∙TTL — поле времени жизни (Time To Live) пакета с обратным отсчетом. Каждая станция должна уменьшать значение этого поля на единицу или на то количество секунд, которое было ею потрачено на пакет. При достижении счетчиком нулевого значения время жизни пакета истекает, и он уничтожается. Этот параметр времени жизни не дает пакетам бесконечно путешествовать по сети Internet в поисках несуществующих пунктов назначения.

∙Протокол — протокол более высокого уровня (уровня 4), который посылает дейтаграмму. Поле протокола определяет протокол уровня 4, который переносится внутри IP-дейтаграммы. Хотя большинство IP-трафика пользуется протоколом TCP, протокол IP могут использовать и другие протоколы. Каждый IP-заголовок должен идентифицировать для дейтаграммы протокол уровня

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

∙Контрольная сумма заголовка — контроль целостности заголовка.

∙IP-адрес отправителя и IP-адрес получателя — 32-разрядные IP-адреса, идентифицирующие конечные устройства, участвующие в обмене.

∙IP опции — защита, тестирование и отладка в сети и другие функции.

Протокол ICMP

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

В протоколе ICMP используются следующие фиксированные типы сообщений (некоторые из которых приведены на рис. 10.15).

•Пункт назначения недостижим.

•Время истекло.

•Проблемы с параметром.

•Гашение отправителя.

•Перенаправление.

•Эхо-запрос.

•Эхо-ответ.

•Запрос временной метки.

•Ответ на запрос временной метки.

•Информационный запрос.

•Информационный ответ.

•Запрос адреса.

•Ответ на запрос адреса.

Существуют и другие типы сообщений, которые не включены в данный перечень.

Проверка пункта назначения с помощью протокола ICMP

Если маршрутизатор получает пакет, который не может быть доставлен в конечный пункт назначения, то он посылает отправителю ICMP-сообщение "Пункт назначения недостижим". Но сначала он пошлет маршрутизатору-получателю эхо-запрос. Как показано на рис. 10.16 и 10.17, сообщение может быть не доставлено из-за того, что маршрут к пункту назначения неизвестен, а эхо-ответ представляет собой успешный ответ на выдачу команды ping. Однако результатом выполнения этой команды могут быть и другие сообщения, например сообщение о недостижимости или сообщение об окончании времени ожидания.

Протокол ARP

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

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

Протокол RARP

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