Введение (стр. 5 )

2.5.1. Канальный уровень TCP/IP

В этой архитектуре TCP/IP нет единого стандарта для обеспечения построения системы передачи данных, т. е. соединения «точка–точка», однако без такого соединения, которое обычно выполняется по телефонным каналам с использованием стандартных модемов, популярность Internet была бы ниже. Действительно, основная масса пользователей Internet использует обычный домашний телефон и свою ПЭВМ. Наиболее простым является подключение ПЭВМ с использованием последовательного порта по протоколу SLIP (Serial Line Internet Protocol, RFC 1055). Его можно применять как на выделенных, так и на коммутируемых каналах связи, на скоростях от 1200 до 19200 бит/с. Существует несколько разновидностей протокола SLIP.

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

Протокол dial-up SLIP обеспечивает установление соединения через ТФОП.

В отличие от протоколов канального уровня ЭМВОС (LAPB — разновидность HDLC, BSC), протокол SLIP «не заворачивает» IP-пакет в свою оболочку, т. е. не добавляет своего заголовка и концевика. SLIP-кадр начинается однобайтовым символом ESC или десятичным 219, а кончается символом END (также один байт) или десятичное 192.

В протоколе SLIP для обеспечения прозрачности используется байтстаффинг. Если внутри SLIP-кадра встречаются символы ESC или END, то к ним добавляется ещё один символ ESC. Длина SLIP-кадра большая и составляет 1006 байт или 8048 разрядов. Протокол SLIP не выполняет каких-либо действий с адресами, не различает пакеты по типу протокола, не корректирует ошибки, т. к. не имеет соответствующих полей.

Следующим протоколом канального уровня является протокол PPP (Point-to-Point Protocol, RFC-1661). Этот протокол является более поздним и, соответственно, более сложным и состоит из трёх частей:

-  механизм инкапсуляции;

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

-  протокол управления сетью.

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

 

Рис. 2.4. Формат кадра в протоколе РРР

В поле «протокол» указывается тип инкапсулированной дейтаграммы, в поле «информация» записывается IP-пакет. В поле «хвостовик» добавляется заполнитель для выравнивания на 32-разрядную границу, т. е. длина PPP-кадра должна быть кратна 32-разрядному слову. По умолчанию длина PPP-кадра равна 1504 байта.

Следующий механизм — протокол управления соединением, предназначен для достижения согласования между узлами сети о параметрах инкапсуляции, например, о размере кадра. Кроме того, этот механизм обеспечивает идентификацию узлов. И, наконец, этот же механизм проверяет готовность физического уровня и производит установление соглашения с протоколом межсетевого обмена (IP, IPX и т. д.).

Третий механизм: процедура управления сетью обеспечивает управление конфигурацией сетевых модулей, например, протокол PPP при работе через модем сам восстанавливает соединение при потере несущей (повторный вызов), кроме того, этот протокол может передавать данные с защитой от ошибок. Большинство современных IP-шлюзов поддерживает PPP.

На канальном уровне может использоваться и стандартный протокол МСЭ-Т — Х.25/2 или LAPB. Он применяется на синхронных сетях, IP-пакеты в сетях с Х.25 передаются по виртуальным соединениям стандартного канального уровня ЭМВОС в виде конечных последовательностей кадров. Используя одно виртуальное соединение в Х.25 путём мультиплексирования, можно передать весь IP-трафик между двумя хостами. Соответствие между IP-адресами и адресами Х.25 задаётся в виде специальных таблиц, которые хранятся в шлюзах.

2.5.2. Межсетевой уровень TCP/IP

Этот уровень в архитектуре TCP/IP является базовым, т. к. обеспечивает возможность стандартизации верхних уровней. Название протокольной единицы (некоторого массива данных) в архитектуре TCP/IP несколько отличается от тех же названий в ЭМВОС. Рассмотрим название протокольных единиц на различных уровнях TCP/IP.

Протокольная единица между сетевым адаптером или модемом и протоколами канального уровня (Enet, SLIP, PPP, X.25/2) называется, как и в ЭМВОС, кадром или фреймом. Протокольная единица между службами Enet, SLIP, PPP и модулем IP, называется IP-пакетом. Протокольная единица между модулем IP и модулем UDP называется UDP-дейтаграммой. Протокольная единица между модулем IP и модулем ТСР называется TCP-сегментом (или транспортным сообщением). Протокольные единицы выше транспортного уровня называются прикладными сообщениями.

Отобразим это на рис. 2.5.

Межсетевой протокол IP (Internet Protocol, RFC-791, 922, 919, 950) предназначен для использования в системе связанных между собой шлюзами сетей, в которых используется КП. Такие сети, как уже отмечалось, называются подсетями Internet. Основным назначением IP-протокола является передача от источников к адресатам межсетевых дейтаграмм и IP-пакетов. Модуль IP обеспечивает также сборку и разборку длинных межсетевых дейтаграмм при необходимости их передачи в сетях с малой максимальной длиной пакета.

По своим функциям протокол IP, в рамках ЭМВОС, можно отнести к протоколам сетевого уровня. В архитектуре TCP/IP этот протокол вместе со вспомогательным протоколом ICMP (Internet Control Message Protocol — протокол межсетевых управляющих сообщений; RFC 792, 1256, 1788, 1885) образует отдельный межсетевой уровень. Каждая межсетевая дейтаграмма обрабатывается модулем IP как независимая единица данных. Для выполнения своих функций модуль IP обращается к сетевым модулям объединяемых сетей с запросом на передачу межсетевой дейтаграммы и передаёт эти дейтаграммы между шлюзами или в хост получателя. Поэтому модуль IP должен быть реализован в каждом хосте и в каждом шлюзе сети.

 

Рис. 2.5. Названия протокольного блока (единицы) данных

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

Рассмотрим межсетевые услуги более подробно.

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

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

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

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

Рассмотрим полный формат IP-пакета, приводимый на рис. 2.6.

Назначение полей заголовка IP-пакета.

Поле «версия» указывает номер версии данного протокола межсетевого уровня. В настоящее время наряду с 4-й версией протокола (т. е. в поле — 0100) начинается использование протокола 6-й версии (т. е. в поле — 0110).

Поле «длина IP-заголовка» указывает длину заголовка межсетевой дейтаграммы в тридцатидвухразрядных словах. Минимальная длина — пять слов, максимальная длина — пятнадцать тридцатидвухразрядных слов (на рисунке заголовок имеет шесть слов).

Поле «тип сервиса» указывает параметры требуемого качества обслуживания и имеет формат, отображённый на рис. 2.7.

Поле «общая длина» указывает на длину МД в байтах (октетах), включая заголовок и данные. Рекомендуется использовать дейтаграмму длиной 576 байт (т. е. 4608 разрядов) — 552 байта данные плюс 24 байта заголовок.

Поле «идентификатор» предназначено для сборки фрагментов межсетевых дейтаграмм.

Поле «смещение фрагментов» указывает место данного фрагмента в межсетевой дейтаграмме. Первый фрагмент имеет смещение, равное нулю.

Поле «время жизни» — это время задаётся в секундах — максимально 255 секунд (приблизительно 4,3 минуты). Однако часто в этом поле указывается максимальное количество хостов, через которые может пройти дейтаграмма. Это является полезным в том случае, когда задержки в сети имеют достаточно большие значения; тогда даже при суммарной задержке более 255 секунд есть вероятность доставки дейтаграммы получателю, если количество транзитных хостов не превысило максимально допустимое значение, определённое в данном поле.

Заголовок	(24байт)	Версия (4)	Длина IP-заголовка (4)	Тип сервиса (8)	Общая длина IP-пакета (16)
Идентификатор (16)	Флаги (3)	Смещение фрагмента (13)
Время жизни (8)	Тип протокола (8)	Контрольная сумма заголовка (16)
Адрес отправи
Адрес получа
Дополнительные услуги	Заполнитель
		Данные пользователя

Рис. 2.6. Формат дейтаграммы Internet

0	1	2	3	4	5	6	7
			D	T	R	C	Резерв (0)
Приоритет

Обозначения:

Приоритет — предоставляет возможность присвоить код приоритета каждой дейтаграмме; D (delay) — задержка: 0 — нормальная задержка, 1 — высокая задержка; Т (throughput) — производительность: 0 — нормальная производительность, 1 — высокая производительность; R (reliability) — надёжность: 0 — нормальная надёжность, 1 — высокая надёжность: С (cost) — стоимость, 0 — нормальная стоимость, 1 — высокая стоимость.

Рис. 2.7. Поле тип сервиса

Поле «тип протокола» определяет тип протокола вышележащего уровня, который будет использован при обработке поля данных межсетевой дейтаграммы.

Поле «контрольная сумма заголовка» содержит проверочные разряды заголовка IP-пакета. Поскольку некоторые поля заголовка меняются в процессе движения пакета (например, время жизни), то проверочные разряды пересчитываются в каждой точке обработки МД. Чаще всего эта контрольная последовательность представляет собой обратный код суммы обратных кодов всех шестнадцатиразрядных слов заголовка, но т. к. для контрольной суммы отводится шестнадцать разрядов, можно с успехом применить и код, рекомендованный V.42 МСЭ-Т (код БЧХ).

Поля «адрес отправителя» и «адрес получателя» содержат по 32 разряда и представляют собой цифровые IP-адреса.

Поля «дополнительные услуги» имеют переменную длину и могут присутствовать или отсутствовать в МД.

Поле «заполнитель» применяется для выравнивания заголовка на 32 разрядную границу.

В процессе передачи данных в сети Internet может возникнуть необходимость передать некоторые управляющие сообщения отправителю, например, об ошибках, обнаруженных в МД. Для этого используется протокол ICMP, который является составной частью протокола IP и должен быть реализован в каждом межсетевом модуле IP. Формат протокола ICMP имеет следующие особенности:

-  поле «протокол» должно быть равно 1;

-  поле «тип сервиса» должно быть равно 0;

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

Управляющие сообщения о недостижимости адресата, истечении времени жизни, о возникновении ошибки в заголовке, а также о переадресации МД имеют следующий формат протокола ICMP.

0	8	16	31
Вид	Код	Контрольная сумма
Не используется (резерв)
Межсетевой заголовок
64 разряда данных
Исходная МД

Рис. 2.8. Общая структура ICMP-сообщений

2.6. Транспортный уровень архитектуры TCP/IP

На транспортном уровне используется два основных транспортных протокола UDP — User Datagram Protocol, RFC 768 (протокол пользовательских дейтаграмм) и TCP — Transmission Control Protocol, RFC 793 (протокол управления передачей). Эти протоколы предоставляют разные услуги прикладным процессам, причём, большинство хостов активно используют только один из них.

Если требуется надёжная и эффективная доставка сообщений по длинному и ненадёжному каналу ПД, то применяется протокол ТСР. Если требуется передавать сообщения на высокоскоростных сетях с короткими соединениями, то лучше подходит протокол UDP.

2.6.1. Протокол UDP

Данный протокол иногда называют протоколом ненадёжной доставки. Этот протокол предоставляет прикладным процессам транспортные услуги, которые немногим отличаются от услуг протокола IP (сетевого уровня).

Протокол UDP обеспечивает только доставку дейтаграммы и не гарантирует её выполнение. Протокол не поддерживает виртуального соединения с удалённым модулем UDP. Основное достоинство — простота.

Формат протокола UDP имеет следующий вид (рис. 2.9).

0	16	31
Межсетевой заголовок IP-пакета
Порт источника	Порт получателя
Длина	Контрольная сумма
Данные

Рис. 2.9. Формат UDP-дейтаграмм

Видно, что формат протокола UDP размещается в поле данных IP-пакета (или после заголовка IP-пакета) и содержит следующие поля.

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

Поле «порт получателя» является частью межсетевого адреса.

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

В поле «длина» указывается размер данной дейтаграммы с учётом длины заголовка в байтах.

Поле «контрольная сумма» обеспечивает контроль правильности данных в заголовке.

Прикладные процессы и модули UDP взаимодействуют через UDP-порты, порты нумеруются, начиная с 0. Прикладной процесс ожидает сообщение в порт, специально выделенный для этих услуг. Номер этого порта является общеизвестным и определяется стандартами сети Internet. Например, протокол SMTP (Simple Mail Transfer Protocol, RFC 821) протокол электронной почты имеет номер UDP-порта — 161.

Используя интерфейс UDP/IP можно реализовать обмен МД. Для этого модуль IP передаёт поступивший IP-пакет модулю UDP, когда в заголовке этого пакета в поле «тип протокола» указано — “UDP” [17].

2.6.2. Протокол ТСР

Данный протокол является сквозным и ориентирован на создание соединений, то есть в данном протоколе создаётся виртуальное соединение. Он работает в широком спектре систем связи — от выделенных каналов до сетей с КП или КК. Протокол TCP размещается над сетевым протоколом IP, который даёт возможность TCP посылать и принимать сегменты информации различной длины, вложенные в межсетевые дейтаграммные «конверты» (пакеты). Протокол TCP идентифицируется в поле «протокол» заголовка IP значением, равным 6.

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

Протокол TCP, в отличие от протокола UDP, создаёт виртуальные соединения или каналы. Подобно модулю UDP, прикладные процессы взаимодействуют с модулем TCP через порты, которые имеют общеизвестные адреса (номера). Когда прикладной процесс начинает использовать TCP, то этот модуль на хосте и модуль TCP на сервере приложений начинают взаимодействовать. Эти два оконечных модуля, прежде всего, создают виртуальное соединение, которое является дуплексным и расходует ресурсы обоих оконечных модулей TCP. Протокол TCP разбивает поток двоичных разрядов (поступающих с вышележащего уровня) на TCP-сегменты, которые передаются по виртуальному соединению. На приёмном конце производится обратная операция. Данный протокол не сохраняет границ между введенными данными, например, можно ввести пять записей по 80 байт в TCP-порт, а на другом конце виртуального соединения прочитать одну запись длиной 400 байт.

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

Формат сегмента протокола ТСР представлен на рис. 2.10.

Кратко рассмотрим назначение полей сегмента ТСР.

Поля «порт источника» и «порт получателя» указывают номера портов в TCP-модулях.

Поле «последовательный номер» содержит номер байта, с которого начинают передаваться данные в этом сегменте.

0

10

16

31

Межсетевой заголовок IP-пакета

IP-пакет

ТСР-сегмент

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

Порт получателя

Заголовок 20 байт

Последовательный номер

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

Смещение данных (4)

Резерв (6)

Поле управляющих флагов

Окно (16)

URG

ACK

PSH

RST

SYN

FIN

Проверочная сумма (16)

Указатель срочности (16)

Модификаторы

Заполнитель

Данные

Рис. 2.10. Формат ТСР-сегмента

Поле «номер подтверждения» при установленном флаге АСК содержит значение последовательного номера, который отправитель данного сегмента собирается принимать. После установления виртуального соединения это поле обязательно заполняется. С помощью этого поля отмечается байт, с которого начнется окно приёма данных от источника (механизм скользящего окна).