Канальный уровень сети X.25. Канальный уровень в локальных сетях

Привет, посетитель сайта сайт! Продолжаем рубрику Сервера и протоколы. Продолжаем разбираться с тем как работают компьютерные сети в целом и сеть Интернет в частности. И в данной публикации мы поговорим о функциях, особенностях и процессах, которые происходят на втором уровне модели OSI или как его еще называют канальный уровень . Мы уже знаем, что на физическом уровне модели сетевого взаимодействия данные представлены в виде битов, то есть последовательности логических нулей и единиц. Отмечу, что ноль и единица логические, так как им соответствует какой-то определенный уровень напряжения, у логического нуля уровень сигнала не нулевой. Эти логические нули и единицы на канальном уровне превращаются в кадры, которые состоят из трех частей: заголовок кадра (определенная последовательность бит, которая сообщает устройству о начале кадра), тело кадра, в котором содержится полезная для человека информация и окончание кадра (опять же это служебная последовательность нулей и единиц, которая делает передаваемое , но которое помогает определить конец кадра).

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

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

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

1. Технология DSL. Это целый набор протоколов и стандартов, описывающих взаимодействие между устройствами на физическом и канальном уровнях модели OSI. Средой передачи данных технологии DSL является медный кабель.
2. Point-to-Point Protocol (PPP). PPP – это двухточечный протокол канального уровня, который используется для установления соединения между двумя устройствами. Протокол PPP позволяет шифровать данные, реализует аутентификацию и сжатие данных. У данного протокола есть несколько подвидов, об одном из подвидов мы немного поговорим ниже.
3. Point-to-Point Protocol over Ethernet (PPPoE). Протокол PPPoE описывает процесс передачи кадров канального протокола PPP через сети, построенные по технологии Ethernet.
4. IEEE3 (Ethernet). Технологий Ethernet включает в себя набор стандартов и протоколов, описывающих взаимодействие между устройствами как на физическом, так и на канальном уровнях модели OSI. Изначально принцип взаимодействия в сетях Ethrenet был похож на радиотрансляцию, когда одно устройство передавало данные, а все остальные устройства эти данные принимали, с появлением коммутаторов этот принцип изменился.
5. И многие другие.

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

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

Оборудование канального уровня модели OSI

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

Давайте приведем несколько примеров оборудования канального уровня модели OSI , чтобы окончательно разобраться с функциями и назначением второго уровня эталонной модели сетевого взаимодействия:

1. Отметим, что хотя драйверы сетевых карт не являются аппаратной частью, но они работают именно на втором уровне модели OSI.
2. Коммутаторы доступа, которые есть в каждом многоквартирном доме крупного города.
3. Роутеры и маршрутизаторы, установленные у нас в квартирах для подключения к сети Интернет, частично выполняют функции канального уровня.
4. Сетевые платы компьютера помимо функций третьего уровня выполняют функции канального уровня модели OSI.

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

Подуровень Управление логической связью (Logical Link Control, LLC) устанавливает и разрывает канал связи, управляет потоком данных, производит упорядочение и вырабатывает подтверждение

приема кадров.

Подуровень Управление доступом к среде (Media Access Control, MAC) контролирует доступ к среде передачи, определяет границы кадров, обнаруживает ошибки, распознает адреса кадров. Он также

обеспечивает совместный доступ плат СА к Физическому уровню. Этот подуровень напрямую связан с платой СА и отвечает за безошибочную передачу данных между двумя компьютерами сети.

1. Сетевые протоколы. Среда клиент-сервер

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

Различают три определяющих свойства протоколов:

1. Каждый протокол предназначен для различных задач и имеет свои преимущества и недостатки.

2. Протоколы работают на разных уровнях модели OSI. Функции протокола определяются уровнем, на котором он работает.

3. Несколько протоколов могут работать совместно. В этом случае они образуют так называемый стек, или набор протоколов. Как сетевые функции распределяются по всем уровням модели OSI, так и протоколы совместно работают на различных уровнях стека.

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

TCP/IP - стандартный промышленный набор протоколов, обеспечивающий связь в неоднородной среде, т.е. между компьютерами разных типов. У TCP/IP есть два главных недостатка: большой размер и недостаточная скорость работы. Но для современных ОС это не является проблемой, а скорость работы сравнима со скоростью работы протокола IPX.

Стек TCP/IP включает и другие протоколы:

SMTP (Simple Mail Transfer Protocol) - для обмена E-mail;

FTP (File Transfer Protocol) - для обмена файлами;

SNMP (Simple Network Management Protocol) - для управления сетью.

Протокол TCP/IP в точности не соответствует модели OSI. Вместо семи уровней в нем используется только четыре:

1. Уровень сетевого интерфейса.

2. Межсетевой уровень.

3. Транспортный уровень.

4. Прикладной уровень.

Уровень сетевого интерфейса , относящийся к Физическому и Канальному уровням модели OSI, напрямую взаимодействует с сетью.

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

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

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

Сеть архитектуры клиент-сервер - это сетевая среда, в которой компьютер-клиент инициирует запрос компьютеру-серверу, выполняющему этот запрос. В модели клиент-сервер ПО клиента использует язык структурированных запросов SQL (Structured Query Language), который переводит запрос с языка, понятного пользователю, на язык, понятный машине. SQL близок к естественному английскому.

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

Сервер в клиент-серверной среде обычно предназначен для хранения данных и управления ими. Именно сервер выполняет большинство операций с данными. Сервер называют также прикладной

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

пользователя. ПО предусматривает также обновление, удаление, добавление и защиту информации.

1. Internet как иерархия сетей. Протоколы Internet

Слово Internet происходит от выражения interconnected networks (связанные сети). Это глобальное сообщество малых и больших сетей. В широком смысле - это глобальное информационное

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

Подключение к Интернету домашнего компьютера выполняется, как правило, с помощью модема.

При этом чаще всего осуществляется так называемое сеансовое соединение с провайдером по телефонной линии. Набирается один из телефонных номеров, предоставленных провайдером, для соединения с одним из его модемов. У провайдера имеется набор модемов, так называемый модемный пул. После того, как вы соединились с ISP (Internet Service Provider), ваш компьютер становится частью сети данного ISP Каждый провайдер имеет свою магистральную линию или backbone.

Провайдеры подключаются к так называемым точкам доступа NAP (Network Access Points) в разных городах, и трафик между двумя сетями течет через NAP. Аналогично организуется подключение к другим магистральным сетям, в результате чего образуется объединение множества сетей высокого уровня.

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

Различают два типа протоколов: базовые и прикладные . Базовые протоколы отвечают за физическую пересылку сообщений между компьютерами в сети Internet. Это протоколы IP и TCP.

Прикладными называют протоколы более высокого уровня, они отвечают за функционирование специализированных служб. Например, протокол HTTP служит для передачи гипертекстовых сообщений, протокол FTP - для передачи файлов, SMTP - для передачи электронной почты.

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

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

На нижнем уровне используются два основных протокола: IP (Internet Protocol - протокол Интернет) и TCP (Transmission Control Protocol - протокол управления передачей).

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

1. Адресация в Internet. Доменные имена

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

Присвоение адреса компьютеру на время сеанса связи называется динамическим .

IP-адрес имеет формат ххх.ххх.ххх.ххх, где ххх - числа от 0 до 255.Четыре числа в IP-адресе называются октетами, поскольку в каждом из них при двоичном представлении имеется восемь разрядов: 4 8=32. Октеты делят на две секции: Net и Host. Net-секция используется для того, чтобы определить сеть, к которой принадлежит компьютер. Host, который называют узлом, определяет конкретный компьютер в сети.

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

Для перевода буквенного доменного имени в IP-адрес цифрового формата служат DNS-серверы.

Каждая страна имеет свой домен. Это географические домены верхнего уровня. Помимо географического признака используется организационный признак.

Внутри каждого доменного имени первого уровня находится целый ряд доменных имен второго уровня. Домен верхнего уровня располагается в имени правее, а домен нижнего уровня - левее.

Во время приема запроса на перевод доменного имени в IP-адрес DNS-сервер выполняет одно из следующих действий:

Отвечает на запрос, выдав IP-адрес, если знает IP-адрес запрашиваемого домена;

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

Выдает сообщение: «Я не знаю IP-address домена, запрашиваемого вами, но вот IP-address DNS-сервера, который знает больше меня»;

Сообщает, что такой домен не существует.

1. Варианты доступа в Internet. Система адресации URL

DSL-технология (Digital Subscriber Line - цифровая абонентская линия) позволяет использовать более широкую полосу пропускания для передачи данных без ущерба для использования телефонной линии по прямому назначению. Существует целое семейство технологий под общим названием xDSL, где приставка х указывает на конкретную спецификацию семейства DSL. Эта технология весьма

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

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

Одним из основных преимуществ технологии xDSL является высокоскоростной доступ в Интернет.

ADSL (Asymmetrical DSL), или асимметричный DSL, позволяет передавать данные пользователю со скоростью, на порядок превышающую скорость передачи данных от пользователя. При этом сигнал от пользователя в Сеть передается на более низких частотах, чем сигнал из Сети к пользователю.

Достоинства ADSL : легкость установки (используется уже имеющаяся телефонная линия), постоянный доступ в Интернет (пользователи ADSL не разделяют полосу пропускания с другими абонентами).

Недостаток ADSL: ограничения по дальности. Скорость передачи потока данных в обратном направлении существенно зависит от расстояния.

Выделенная телефонная линия - это арендованная телефонная линия связи, соединяющая без коммутации двух абонентов. Наиболее распространенной технологией выделенной линии является

технология ISDN (Integrated Services Digital Network). Передача информации может осуществляться по обычному медному проводу. Пользователи, которые устанавливают ISDN-адаптер вместо модема, могут получить доступ в Интернет со скоростью до 128 Кбит/с.

Сеть кабельного телевидения .

Основным достоинством этой технологии является то, что

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

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

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

можно подключить как индивидуальных пользователей, так и ЛВС. Преимущества радиоканала: быстрая инсталляция, мобильность (нет кабеля), высокая скорость (несколько Мбит/с в зависимости от оборудования), затраты (первоначальные затраты на оборудование выше, чем в случае выделенной линии, но абонентская плата ниже).

NUMBEREDHEADINGS__

Временная диаграмма последовательности обмена кадрами

Настоящая глава посвящена описанию основной процедуры второго (канального) уровня сети X.25 (X.25/2) – обеспечению безошибочного обмена информационными кадрами, передаваемых по подверженным помехам каналам связи . Эта функция называется управление потоками и используется не только для сети пакетной коммутации стандарта Х.25, но и для других сетей, обеспечивающих службу передачи данных. При этом алгоритм реализации этой функции отличается в сетях разных технологий. Для сетей связи, обеспечивающих службу телефонии или видео, управление потоком не производится. Основной принцип управления потоками в Х.25/2 состоит в следующем. Передаваемый информационный кадр сохраняется в памяти передающего узла, ожидая приема квитанции о правильном приеме кадра узлом-получателем. В качестве этих узлов могут быть смежные транзитные коммутаторы или оконечный коммутатор. В следующей главе приводится описание структурных схем программного обеспечения по реализации функции управления потоками в Х.25/2. Поэтому в настоящей главе приводится относительно подробное описание этой функции. Под кадром понимается элемент данных протокола PDU X.25/2 (между оконечным пунктом и ЦКП или между смежными ЦКП). Помехи в канале связи могут вызывать потерю, дублирование, искажение кадра, нарушение порядка прибытия кадра адресату. Кадр состоит из последовательности байтов. В начале и в конце кадра устанавливается синхронизирующий байт для определения начала и конца кадра. Этот синхронизирующий байт («01111110») называется флагом, а процедура обеспечения синхронизации бит-стаффингом. Для того чтобы можно было передавать байт такого содержания в информационной части кадра перед передачей после пяти непрерывных информационных «1» производится вставка «0» и изъятие этого бита на приеме.

Выполнение функции безошибочного обмена информационными кадрами обеспечивается подмножеством высокоуровневого протокола управления каналом HDLC (High-level Data Link Control) - процедурой сбалансированного доступа LAP-B (Link Access Protocol-Balanced). Этот протокол обеспечивает режим работы, в котором оба взаимодействующих в соединении узла равноправны.

Для описания алгоритма работы канального уровня сети Х.25 используются примитивы . Примитивами являются блоки данных определенного вида, которые передаются между уровнями системы для вызова различных процедур. Примитивы определяются согласно рекомендации ITU-T Х.210 . На рис. 1 представлен обмен примитивами между уровнями модели OSI. Показаны четыре типа примитивов – запрос, индикация, ответ, подтверждение.

Рис. 1. Обмен примитивами между уровнями модели OSI

В некоторых случаях достаточно двух типов примитивов (запрос, подтверждение).

На рис. 2 приведена временная диаграмма последовательности обмена кадрами при установлении соединения, передача одного информационного кадра и разъединение соединения. Приведём эту последовательность.

Рис. 2. Временная диаграмма последовательности обмена кадрами при установлении соединения, передаче информационного кадра и разъединении канального соединения

1. С сетевого уровня на канальный уровень станции A передаётся примитив «Запрос соединения». При выполнении этого примитива в канал связи с канального уровня передаётся кадр SABM о запросе соединения.
2. При поступлении этого кадра на станцию Б он передаётся канальным уровнем на сетевой уровень в виде примитива «Индикация запроса соединения», в ответ на который выдается примитив «Ответ на запрос соединения». В результате в канал с канального уровня отправляется кадр UA о согласии на соединение.
3. После приёма этого кадра с канального уровня на сетевой уровень станции Б направляется примитив «Подтверждение соединения».
4. С сетевого уровня на канальный уровень станции А передаётся примитив «Запрос на посылку пакета данных». При выполнении этого примитива в канал связи с канального уровня передаётся информационный кадр «I» на противоположную станцию.
5. Кадр «I», поступивший со станции А, передаёт сетевому уровню пакет данных с помощью примитива «Индикация прибытия правильного пакета данных».
6. С канального уровня станции Б в канал передаётся кадр «RR» подтверждения приёма правильного пакета данных.

Формат кадра

На рис. 3 приведен формат информационного кадра Х.25. Этот формат включает заголовок кадра З2, концевик кадра К2 и пакет данных третьего уровня. Кадр обрамляется флагами (F ). Основным полем заголовка З2 является поле управления потоком, в котором основными характеристиками являются тип кадра и номера передаваемого и принимаемого информационного кадра: соответственно – N(S) и N(R).

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

Поле «Данные» (пакет сетевого уровня «Д») присутствует только в информационном кадре («I»). З3 означает заголовок пакета «Д». Концевик включает в себя контрольно-проверочную комбинацию КПК (К2), необходимую для выявления кадров, искаженных помехами в канале. Кроме информационных кадров в процедуре используются супервизорные кадры RR, REJ для подтверждения или запроса повторной передачи «I» кадров, принятых с искажениями из-за помех в канале, а также кадр RNR для приостановки передачи информационных кадров при перегрузке принимающей стороны. Эти кадры включают только параметр N(R). Ненумерованные кадры (SABM , DISK , UA и др.) служат, например, для установления или разъединения соединений между смежными узлами коммутации.

Рис. 3. Формат информационного кадра Х.25

Убедимся в необходимости применения при службе передачи данных схем обнаружения ошибок в принимаемых кадрах. Для этого определим вероятность появления таких искаженных кадров. Обозначим вероятность единичного ошибочного бита через Рв – эта характеристика канала, именуемая также частотой ошибочных битов (bit error rate – BER ). При использовании каналов в сети Х.25 эта величина может составлять Рв=0,0001. Если считать, что в канале возникают одиночные ошибки, статически независимые, то при длине кадра Х.25 порядка L=128 байт вероятность безошибочного приема кадра P = (1 − P B) ≈ (0 , 9999) 1024 ≈ 0 , 9 {\displaystyle P=(1-P_{B})\approx (0,9999)^{1024}\approx 0,9} , т.е. каждый десятый кадр искажен на приеме.

Частота появления ошибочных бит в аналоговом канале сети Х.25 нередко составляет даже P B = 0 , 001 {\displaystyle P_{B}=0,001} . Ошибки в каналах связи чаще бывают не единичными, а групповыми, то есть имеет место пакетирование ошибок. Это значительно уменьшает частоту искаженных кадров.

Полученный результат свидетельствует о необходимости применения схем обнаружения ошибок. Работа всех методов обнаружения ошибок основывается на использовании помехоустойчивого кодирования. На передающей стороне заголовок З2 и информационная часть, которая присутствует только в информационных кадрах, представляется как последовательность из k бит, которую требуется защитить от ошибок. К данной последовательности добавляется контрольно-проверочная комбинация КПК, которая вычисляется по определенному алгоритму как функция k битов передаваемого кадра. В результате формируется кодовая комбинация, имеющая длину n бит и включающая контрольно-проверочную комбинацию (n-k) бит (рис. 4). На приеме из кадра выделяется КПК. На основании принятых k бит приемник вычисляет КПК и сверяет результат вычисления с принятой КПК. Если принятая и вычисленная КПК не совпадают, кадр считается искаженным и аннулируется. В сети Х.25 используется один из наиболее широко используемых методов обнаружения ошибок – с помощью циклического избыточного кода CRC (Cyclic redundancy check). В сети X.25 n-k = 16 бит.

Рис. 4. Контрольно-проверочная комбинация в составе кадра из n бит

В разделе 4 приводится описание кода CRC тремя способами: с помощью арифметики по модулю 2, с использованием полинома, аппаратная реализация. Циклический код используется не только в сетях X.25, но и в IP - сетях, в беспроводных сетях стандарта GSM и др.

Восстановление информационных кадров

Приведем описание алгоритма передачи последовательности кадров Х.25 в условиях помех в каналах связи. Такой алгоритм называется управлением потоками на канальном уровне . Все передаваемые «I» кадры заносятся в буфер передатчика и ожидают получения положительного подтверждения от противоположной принимающей стороны. По запросу противоположной стороны производится повторная выдача из буфера принятых с искажениями «I» кадров. В измененном алгоритме восстановление блоков данных из-за помех в каналах связи применяется и в других технологиях сетей связи как, например, на транспортном уровне IP-сети, в сети ТфОП и др. Достаточно подробное изложение алгоритма управления потоками в Х.25 приводится для описания в следующей главе принципов составления алгоритмов программного обеспечения.

На канальном уровне Х.25 восстановление искаженных кадров предусматривает нумерацию передаваемых «I» кадров. Для описания метода в рекомендации ITU-T Х.25 введены следующие обозначения:

• V(S) – переменная состояния передачи.
• N(S) – порядковый номер передаваемого кадра «I». N(S) устанавливается равным V(S).
• V(R) – переменная состояния приема.
• N(R) - порядковый номер I-кадра, ожидаемого на прием.

V(S) означает текущий порядковый номер кадра «I», содержащего пакет данных и подлежащего передаче на физический уровень. Переменная V(S) в нормальном режиме функционирования звена данных принимает значения по модулю 8 (в цикле от 0 до 7), в расширенном режиме - по модулю 128 (в цикле от 0 до 127). Расширенная нумерация применяется в каналах с большим временем задержки (межконтинентальная связь или спутниковые каналы). По окончании передачи кадра значение V(S) увеличивается на единицу.

Переменная V(R) содержит текущее значение порядкового номера очередного кадра «I», который ожидают на приеме. Для V(R), как и для V(S), приняты нормальный и расширенный режимы нумерации. После приема I-кадра, в котором не обнаружены ошибки, и номер которого совпадает с ожидаемым приемной стороной N(S)=V(R), значение V(R) увеличивается на единицу.

N(R) – порядковый номер I-кадра, ожидаемого на прием. N(R) содержится в заголовке (З2) принимаемых кадров «I» и в супервизорных кадрах RR, REJ, RNR. N(R) в кадрах RR и «I» указывает, что переданные с противоположной стороны канала кадры «I» с номерами N(S)

Информационный кадр «I» содержит оба параметра N(S) и N(R). Информационные кадры стираются из буфера повторной передачи при подтверждении правильного приема.

Супервизорный кадр готовность к приему RR (receive ready) является положительной квитанцией, поступающей от принимающей стороны, и указывает на то, что переданные «I» кадры с номерами N(S)

Супервизорный кадр отказ REJ (reject) является отрицательной квитанцией и указывает, что «I» кадры, с номерами N(S)шириной окна W . В этом случае очередной пакет данных с сетевого уровня не инкапсулируется в кадр «I» для передачи в канал.

Если в приемник поступил «I» кадр, в котором не обнаружены ошибки и с ожидаемым номером N(R), то служебные поля канального уровня (З2 и К2) отбрасываются, и входящий в кадр пакет данных передается с канального на сетевой уровень. На рис. 5 приведена временная диаграмма обмена «I» кадрами между пунктами А и Б (случай приема «I» кадров без искажения, исходное состояние V(S)=V(R)=0, буферы повтора пустые).

Рис. 5. Временная диаграмма обмена «I» кадрами, принятыми с канала без искажений

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

• I (i, j) – информационный кадр с параметрами N(S)=i, N(R)=j
• RR(j) – кадр RR с параметром N(R)=j

Крестиком отмечен искаженный в канале кадр. Ниже приведено описание последовательности операций.

1. Передача «I» кадра с параметрами N(S)=0, N(R)=0. Запись кадра «I» в буфер станции А. Изменение текущего значения V(S):=V(S) + 1, т.е. V(S)=1 (на станции А).
2. Прием без ошибок I (0,0) на станции Б. Номер кадра N(S) совпадает с ожидаемым номером V(R), то есть N(S)=V(R)=0. Изменение текущего состояния приема V(R):=V(R)+1, т.е. V(R)=1 в Б.
3. Подтверждение приема кадра I (0,0), т.е. передача положительной квитанции RR(1).
4. Прием RR(1) и стирание из буфера кадра I (0,0).
5. Передача кадра I (1,0), запись его в буфер, V(S)=2.
6. Прием без ошибок I (1,0) на станции Б, V(R)=2.
7. Подтверждение приема I (1,0), т.е. передача квитанции RR(2).
8. Прием искаженного в канале кадра RR(2). Кадр отбрасывается.
9. Передача очередного «I» кадра I (2,0), запись его в буфер (в буфере станции А теперь записаны два кадра I (1,0), I (2,0), которые ждут подтверждения об их приеме на станции Б), V(S)=3.
10. Прием безошибочного I (2,0) на станции Б, V(R)=3.
11. Передача «I» кадра со станции Б на станцию А с параметрами N(S)=0, N(R)=3, т.е. I (0,3). V(S)=1 (на станции Б), запись в буфер I (0,3) на станции Б. Этот кадр одновременно является квитанцией правильного приема станцией Б «I» кадров с номерами 1 и 2.
12. Прием без ошибок I (0,3), стирание из буфера станции А кадров I (1,0) и I(2,0).

В приведенной на рис. 5 диаграмме все «I» кадры принимаются неискаженными. Поэтому операции приема этих кадров (2, 6, 10 на станции Б и 12 на станции А) завершаются передачей входящих в них пакетов данных на сетевой уровень.

На рис. 6 представлена диаграмма, включающая прием некоторых искаженных кадров «I». Для наглядности диаграммы параметры V(S) и V(R) на рисунке не приведены.

Как видно из диаграммы, искаженные в канале кадры I(2,0), I(3,0), I(4,0) при получении кадра REJ(1) передаются на станцию Б повторно из буфера. Кадры I(0,0) со станции А и I(0,4), I(1,5) со станции Б повторно из буферов не передаются, поскольку они подтверждаются соответственно кадрами RR(1), I(4,1) и RR(2). Необходимо отметить, что нумерация кадров N(S) и N(R) циклическая. При нормальной нумерации для этого отводится 3 бита, а при расширенной - 7 бит. Напомним, что под шириной (размером) окна W понимается максимальное число неподтвержденных кадров в буфере. При заполнении такого числа кадров в буфере согласно алгоритму требуется перейти к повторной передаче этих кадров из буфера. Чем выше пропускная способность канала и больше протяженность канала, тем размер окна выше.

Рис. 6. Временная диаграмма восстановления «I» кадров при приеме отрицательной квитанции REJ

Рассчитаем величину задержки кадра длинной порядка 128 байт при скорости передачи 64 кбит/с. Задержка составляет 128 байт / 64 кбит/с = 16 мсек. Сравним эту величину со временем задержки распространения кадра по спутниковому каналу протяженностью 72000 км, приняв скорость распространения сигнала равной скорости света в вакууме – 300000 км/с. Эта величина составляет 72000 км / 300000 км/с = 240 мсек, т.е. в канале одновременно могут находиться 15 кадров (240/16). Отсюда ясно, почему при использовании спутниковых каналов в сети Х.25 применяется расширенная нумерация и соответственно большая ширина окна W , чем при нормальной нумерации.

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

На рис. 7 и рис. 8 приведены диаграммы повтора «I» кадров из буфера по истечении тайм-аута. Примеры приведены для случая запрета передачи очередного кадра «I» при числе ожидающих в буфере повтора «I» кадров равном окну W (W=4).

Как видно из диаграммы, по истечении тайм-аута кадр «I» повторяется из буфера. Причиной повторения по таймеру может быть искажение только «I» кадров (рис. 7), либо искажение кадров «I» и кадров подтверждения RR (рис. 8). В случае правильного приема кадра I(0,0) пакет сетевого уровня должен быть отправлен на сетевой уровень, но повторный прием кадра I(0,0) считается копией уже принятого кадра, а поэтому он сбрасывается, т.е. не пересылается на сетевой уровень.

Рис. 7. Временная диаграмма восстановления кадра «I» по истечении тайм-аута

Рис. 8. Временная диаграмма сброса копии «I(0,0)» кадра, принятого повторно из станции Б по истечении тайм-аута на А

Обнаружение ошибок с помощью избыточного циклического кода

Ниже приводятся три способа описания определения кода CRC: с использованием арифметики по модулю 2, с использованием полинома и аппаратная реализация .

Пример с использованием арифметики по модулю 2

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

Введем следующие обозначения:

• T – n-битовый кадр, который необходимо передать;
• D – k-битовый блок сообщения (k первых бит кадра T );
• R – (n-k) – битовая контрольная последовательность кадра (последние (n-k) бит кадра T ). Значение R необходимо вычислить;
• P - (n-k+1) – битовый делитель.

Пример:

Пример с использованием полинома

Используя предыдущий пример, получаем: последовательности D = 1010001101 соответствует полином , последовательности Р = 110101 - полином , последовательности R = 01110 − R (X) = X 3 + X 2 + X {\displaystyle R=01110-R(\mathrm {X})=\mathrm {X} ^{3}+\mathrm {X} ^{2}+\mathrm {X} } .

Рис. 9. Пример полиномиального деления

Приведем примеры длин п-к КПК (FCS) используемых полиномов Р(Х) в сетях связи:
CRC – 3: в GSM.
CRC – 16: в ОКС№7, X.25, Интернет (на межсетевом уровне, на транспортном уровне по протоколу TCP).
CRC – 32: в ATM.

Пример аппаратной реализации

Процесс циклической проверки четности с избыточностью можно представить как схему деления, состоящую из элемента исключающего ИЛИ (сложение по модулю 2) и регистра сдвига. Регистр сдвига представляет собой строку 1-битовых ячеек памяти. Каждая ячейка имеет выходную шину, показывающую текущее хранимое значение, и входную шину. В дискретные моменты времени, которые называют тактами, значения ячеек памяти замещаются значениями, указанным во входной шине. Замена происходит синхронно во всем регистре, так что в результате значения ячеек регистра сдвигаются на один бит.

Реализация схемы выглядит следующим образом.

1. Регистр, содержащий (n - k) бит (по размеру контрольно-проверочной комбинации).
2. До (n - k) элементов исключающего ИЛИ.
3. Наличие или отсутствие логического элемента соответствует наличию или отсутствию члена в полиноме-делителе Р (Х), исключая члены 1 и X n − k {\displaystyle \mathrm {X} ^{n-k}} .

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

сообщение D = 1010001101 {\displaystyle D=1010001101} ; D (X) = X 9 + X 7 + X 3 + X 2 + 1 {\displaystyle D(\mathrm {X})=\mathrm {X} ^{9}+\mathrm {X} ^{7}+\mathrm {X} ^{3}+\mathrm {X} ^{2}+1} ; делитель P = 110101 {\displaystyle P=110101} ; P (X) = X 5 + X 4 + X 2 + 1 {\displaystyle P(\mathrm {X})=\mathrm {X} ^{5}+\mathrm {X} ^{4}+\mathrm {X} ^{2}+1} .

На рис. 10,а представлена реализация регистра сдвига. Процесс начинается с очистки регистра (все ячейки обнуляются). После этого передаваемое сообщение (делимое) побитово вводится в регистр, начиная со старшего бита. На pис. 10,б приведена таблица, которая иллюстрирует пошаговую работу схемы по мере введения отдельных битов. Строки таблицы содержат значения пяти ячеек регистра сдвига в соответствующие моменты времени. Кроме того, в строках таблицы приводятся значения на выходе трех схем исключающего ИЛИ. Последнее число в каждой строке - значение следующего входного бита, который станет доступен для работы на следующем этапе.

Отметим, что операция исключающее ИЛИ влияет на значения ячеек С4, С2 и С0 при следующем сдвиге, что идентично рассмотренному ранее процессу двоичного деления. Процесс выполняется для всех битов передаваемого сообщения. Для обеспечения корректности выходного сигнала используются два ключа. При вводе битов данных оба ключа находятся в положении А. В результате за первые 10 шагов входные биты подаются в регистр сдвига и также используются в качестве выходных битов. По окончании обработки последнего бита данных регистр сдвига содержит остаток деления - содержание регистров после этапа 10. При вводе последнего бита данных в регистр оба ключа устанавливаются в положение В. В этом случае.

9) Маршрутизация: статическая и динамическая на примере RIP, OSPF и EIGRP.
10) Трансляция сетевых адресов: NAT и PAT.
11) Протоколы резервирования первого перехода: FHRP.
12) Безопасность компьютерных сетей и виртуальные частные сети: VPN.
13) Глобальные сети и используемые протоколы: PPP, HDLC, Frame Relay.
14) Введение в IPv6, конфигурация и маршрутизация.
15) Сетевое управление и мониторинг сети.

P.S. Возможно, со временем список дополнится.

Как вы помните, я уже говорил о том, что в сетях важно строгое соблюдение всех правил для корректной работы. А именно процесс инкапсуляции и деинкапсуляции. Поэтому, когда в предыдущей статье говорили о протоколах верхних уровней, я вскользь упоминал о некоторых протоколах нижних уровней, так как они постоянно вылезали и напоминали о себе. Объясню почему. Посмотрите сейчас на картинку выше. Тут приведена работа почты. Взгляните на двух лысых дядек вверху, которые написали письмо и светятся от счастья. Но толку не будет от письма, если его не увидит адресат. Для этого они воспользуются почтовой службой. Их письмо примет сотрудница почтового отделения и положит в конверт. Конверт она подпишет, чтобы было понятно от кого оно и кому. Дальше это письмо заберет курьер и отнесет в сортировочный центр. Ниже стоит мужичок в фуражке и фартуке, который жонглирует письмами. Он знает, куда положить письмо, чтобы оно дошло до адресата. И в самом низу поезд, который является транспортным узлом. Заметьте, что тут важна роль каждого для удачной отправки и доставки письма.

В сетях все тоже самое. Решили вы залезть на сайт и почитать новости. Набираете в строке браузера адрес сайта. Дальше ваш компьютер как то должен эти страницы запросить. И тут уже на помощь придут протоколы пониже, которые являются транспортным узлом. Здесь каждый уровень можно сравнить с вышеописанными личностями на рисунке.

Подведу я всю эту канитель к общему знаменателю и поделюсь примером, который я когда-то для себя вывел. У вас есть оконечное сетевое устройство. Не важно компьютер, ноутбук, планшет смартфон или еще что. Каждое из этих устройств работает по стеку TCP/IP. А значит, оно соблюдает его правила.

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

2) Транспортный уровень. У приложения или службы должен быть порт, который он слушает и по которому с ним можно связаться.

3) Сетевой уровень. Здесь присутствует IP-адрес. Его еще называют логическим адресом устройства в сети. При помощи него можно связаться с компьютером, на котором запущен этот самый браузер, а значит, и достучаться до самого приложения. Имея данный адрес, он является участником сети и может связываться с другими участниками

4) Канальный уровень. Это сама сетевая карточка или антенна. То есть передатчик и приемник. У него есть физический адрес для идентификации этой сетевой карты. Кабели, коннекторы тоже относятся сюда. Это среда, которая свяжет компьютер с другими участниками.

Начнем с самого нижнего уровня. Это канальный и физический уровень, если рассматривать с точки зрения модели OSI и уровень доступа, если смотреть с высоты стека протоколов TCP/IP. Пользуемся мы TCP/IP, поэтому я буду говорить с ее точки зрения. Уровень доступа, как вы поняли, объединяет в себе физический и канальный уровень.

Физический уровень. Или как его любят называть «электрический уровень». Задает параметры сигнала, а также какой вид и форму имеет сигнал. Если, например, используется Ethernet (который передает данные при помощи провода), то какая модуляция, напряжение, ток. Если это Wi-Fi, то какие использовать радиоволны, частоту, амплитуду. К этому уровню можно отнести сетевые карты, Wi-Fi антенны, коннекторы. На этом уровне вводится такое понятие, как биты. Это единица измерения передаваемой информации.

Канальный уровень. Этот уровень используется для того, чтобы передать не просто биты, а осмысленные последовательности из этих бит. Используется для передачи данных в одной канальной среде. Что это значит, я опишу чуть позже. На этом уровне работают MAC-адреса, которые еще называют физические адреса.

Термин «физические адреса» ввели не просто так. Каждая сетевая карта или антенна имеет вшитый адрес, который ей присваивает производитель. В предыдущей статье я упоминал термин «протоколы». Только там это были протоколы верхнего уровня, а если точнее, то прикладного. На канальном уровне работают свои протоколы и количество их не маленькое. Самые популярные - это Ethernet (используется в локальных сетях), PPP и HDLC (они используются в глобальных сетях). Это конечно далеко не все, но Cisco в своей сертификации CCNA рассматривает только их.

Тяжело все это понять в виде сплошного сухого текста, поэтому объясню на картинке.

Забудьте сейчас про IP-адреса, модель OSI и стек протоколов TCP/IP. У вас есть 4 компьютера и коммутатор. На коммутатор внимания не обращайте, так как это обычная коробка для соединения компьютеров. У каждого компьютера есть свой MAC-адрес, который идентифицирует его в сети. Он должен быть обязательно уникальный. Хоть я и представил их 3-х значными, это далеко не так. Сейчас эта картинка только для логического понимания, а как это работает в реальной жизни, напишу чуть ниже.

Итак. Если один из компьютеров захочет что-то отправить другому компьютеру, то ему потребуется знать только MAC-адрес компьютера, на который он отправляет. Если верхнему левому компьютеру с MAC-адресом 111 захочется что-то отправить нижнему правому компьютеру, то он без проблем отправит это, если будет знать, что у адресата MAC-адрес 444.

Эти 4 компьютера образуют простенькую локальную сеть и одну канальную среду. Отсюда и название уровня. Но для корректной работы узлов в сетях TCP/IP, недостаточно адресации на канальном уровне. Важна еще адресация на сетевом уровне, которая всем известна, как IP-адресация.

Теперь вспоминаем про IP-адреса. И присвоим их нашим компьютерам.

Адреса я присвоил символически, чтобы на базовом уровне понять, как они работают. Вот эти две адресации (канальная и сетевая) работают в тесной связке между собой и по отдельности работать не смогут. Сейчас объясню почему. Мы в повседневной жизни работаем только с IP-адресами или именами, о которых была целая глава в предыдущей статье. С MAC-адресами мы фактически не работаем. С ними работают сами компьютеры. Сейчас смоделирую ситуацию. Я сижу за верхним левым компьютером с IP: 1.1.1.1 и MAC: 111. Захотел я связаться с нижним правым компом и проверить живой он или нет. Я смогу связаться с ним, если буду знать его IP-адрес. MAC-адрес мне его не интересен. Я знаю, что IP-адрес у него 1.1.1.4. И решаю воспользоваться утилитой ping (утилита проверки доступности узла).

Теперь важная вещь. Компьютер понимает, что он не знает MAC-адрес компьютера, доступность которого надо проверить. Для того, чтобы узнать MAC-адрес по IP-адресу, придумали протокол ARP. Я о нем напишу подробно позже. Сейчас я хочу, чтобы вы поняли зависимости MAC-адреса и IP-адреса. Итак, он на всю сеть начинает кричать: «Кто такой 1.1.1.4». Этот крик услышат все участники сети и, если найдется тот узел, который имеет данный IP-адрес, он отзовется. У меня такой компьютер присутствует и в ответ на этот крик, он ответит: «1.1.1.4 - это я. Мой MAC - 444». Мой компьютер получит это сообщение и сможет продолжить то, что я ему сказал.

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

Если вы когда-нибудь залезали в настройки сетевых адаптеров или прописывали статический адрес, который вам сообщал провайдер, то видели поле «маска подсети». Она записывается в том же формате, что и IP-адрес, основной шлюз и DNS. Это четыре октета разделенных между собой точками. Если вы этого никогда не видели, то можете открыть командную строку и набрать в ней ipconfig. Вы увидите, что-то похожее.

Это скриншот из командной строки моего ноутбука. Я сижу за домашней точкой доступа, у которой маска 255.255.255.0. Это, наверное, самая простая маска для объяснения и скорее всего у вас она точно такая же. В чем суть. Первые 3 октета (они фиксированы) показывают адрес сети, а 4 октет (он динамический) показывает адрес хоста. Иными словами, данная маска показывает, что нужно проверять первые 3 октета полностью, а четвертый может быть свободным от 0 - 255. Вообще это грубая формулировка. Потому, что с такой маской свободны будут от 1 до 254, где 0 уйдет под адрес сети, а 255 под широковещательный адрес. Но в любом случае это предел одной канальной среды. То есть, когда узлу надо отправить другому узлу сообщение, он берет его адрес и накладывает на него маску и если адрес сети (фиксированная часть) сходится с его адресом, то значит они в одной канальной среде. Объясняю на примере той же картинки.

Сижу я за верхним левым компом и хочу отправить нижнему правому. Знаю я и IP-адрес его и MAC-адрес. Мне надо понять, в одной канальной среде мы или нет. Его адрес 1.1.1.4 и маска 255.255.255.0. Маска мне говорит, что 3 октета фиксированы и не должны меняться, а четвертый может быть любым в пределах от 1 до 254. Я накладываю маску на его адрес и на свой адрес и смотрю совпадения и различия.

Красным подсвечено та область, которая отвечает за сеть. Как видим, у 2-х хостов она одинакова. Значит, они находятся в одной подсети.

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

Добавилась круглое устройство. Оно называется роутер или маршрутизатор. Слово всем знакомое. Основная его роль - это соединение сетей и выбор лучшего маршрута, о чем будет в дальнейшем рассказано более подробно. И добавился, справа, один коммутатор, с которым соединены 2 компьютера. Маска для всех устройств не изменилась (255.255.255.0).

Посмотрите внимательно на адреса всех устройств. Можно заметить, что у новых узлов и старых отличается 3-ий октет. Давайте разберемся с этим. Я также сижу за компом с MAC:111 и IP:1.1.1.1. Хочу отправить информацию одному из новых узлов. Давайте пусть это будет верхний правый компьютер с MAC:555 и IP:1.1.2.1. Накладываю маску и смотрю.

И тут уже другая картина. 3-ие октеты различаются, а значит, узлы находятся в разных сетях (правильнее подсетях). Для разрешения таких ситуации, в настройках каждой операционной системы есть основной шлюз. Его еще называют «шлюз последней надежды». Используется он, как раз, в том случае, когда нужно отправить информацию узлу, находящемся в другой канальной среде. Для моего компа адрес шлюза - 1.1.1.254. А для компьютера, которому я отправляю данные 1.1.2.254. Логика работы здесь простая. Если узлу, который находился в одной канальной среде, информация доходила напрямую, то для узла находящегося в другой канальной среде, путь будет через маршрутизатор.

Мой комп знает, что адрес шлюза 1.1.1.254. Он крикнет на всю сеть: «1.1.1.254 отзовись». Это сообщение получат все участники канальной среды, но ответит только тот, кто сидит за этим адресом. То есть маршрутизатор. Он отправит ответ, и только после этого мой комп отошлет данные до адреса 1.1.2.254. Причем обратите внимание. На канальном уровне данные будут отправлены на MAC:777, а на сетевом, на IP:1.1.2.1. Это значит, что MAC-адрес передается только в своей канальной среде, а сетевой адрес не меняется на всем своем пути. Когда маршрутизатор получит инфу, он поймет, что на канальном уровне она предназначалась ему, но когда увидит IP-адрес, то поймет, что он промежуточное звено и передать надо в другую канальную среду. Его второй порт смотрит в нужную подсеть. Значит, ему все пришло верно. Но он не знает MAC-адрес адресата. Он начинает так же кричать на всю сеть: «Кто такой 1.1.2.1?». И комп с MAC-адресом 555 отвечает ему. Думаю, что логика работы понятна.

На протяжении двух предыдущих статей и текущей, много раз упоминался термин «MAC-адрес» . Давайте разберем, что это такое.

Как я уже говорил, это уникальный идентификатор сетевого устройства. Он уникален и не должен нигде повторяться. Состоит он из 48 бит, из которых первые 24 бита - это уникальный идентификатор организации, который присваивается комитетом IEEE(Институт инженеров электротехники и электроники). А вторые 24 бита назначаются производителем оборудования. Выглядит это так.

Записывают его по-разному. Например:

1) 00-50-56-C0-00-08
2) 00:50:56:C0:00:08
3) 0050.56С0.0008

Как видите, один и тот же адрес можно записать разными способами. Еще обычно его не разделяют, а записывают слитно. Главное знать, что MAC-адрес всегда состоит из 48 бит и состоит из 12 букв и/или цифр. Посмотреть его можно разными способами. Например, в ОС Windows, открыв командную строку, ввести ipconfig /all. Многие производители еще записывают его на коробке или на обратной стороне корпуса устройства.

Так что можете посмотреть на свою Wi-Fi точку доступа и увидеть похожую запись. В самом начале я показал MAC-адреса 3-х значными цифрами, что не правда. В том контексте я их употреблял только для простоты объяснения, чтобы не путать вас длинными непонятными записями. Чуть ниже, когда речь дойдет до практики, вы увидите их такими, какие они на самом деле.

Раз мы разобрали адрес на канальном уровне, пришло время разобрать протокол, работающий на данном уровне. Самый популярный на сегодняшний момент протокол, используемый в локальных сетях - это Ethernet . IEEE описала его стандартом 802.3. Так что, все версии, которые начинаются с 802.3, относятся именно к нему. Например, 802.3z - это GigabitEthernet через волоконно-оптический кабель; 1 Гбит/с, а 802.3af - это электропитание через Ethernet (PoE - Power over Ethernet).

Кстати, я не сказал об организации IEEE (англ. Institute of Electrical and Electronics Engineers) . Эта организация разрабатывает стандарты ко всему, что относится к радиоэлектронике и электротехнике. На их сайте можно найти много документации по существующим технологиям. Вот, что они выдают по запросу «Ethernet»

Давайте разберем, из чего он состоит. Так как сам протокол старый (придуман в 1973 году), то он много раз модернизировался и менял свой формат. В Интернете можно найти все его варианты, но я приведу тот, который приводила Cisco, когда я учился.

1) Преамбула. Поле, используемое для указания начала кадра. То есть, чтобы приемник смог понять, где начало нового кадра. Раньше, когда использовалась топология с общей шиной и были коллизии, преамбула помогала предотвращать коллизии.

2) MAC-адрес получателя. Поле, куда записывается адрес получателя.

3) MAC-адрес отправителя. Соответственно сюда записывается адрес отправителя.

4) Тип (длина). Раньше в этом поле указывалось, какому вышестоящему протоколу передается данный кадр, но в дальнейшем от этого отказались и ввели поле «Длина». Оно указывает длину поля данных, которое варьируется от 46-1500 байт.

5) Поле SNAP/LLC + данные. Как раз SNAP/LLC указывает какому вышестоящему протоколу передать кадр. Это может быть IP, IPX и другие протоколы сетевого уровня. Также в этом поле содержатся данные, полученные с высших уровней.

6) FCS (от англ. Frame Check Sequence - контрольная сумма кадра). Поле в котором подсчитана чек-сумма. По ней получатель понимает, побился кадр или нет.

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

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

IP (от англ. Internet Protocol). Протокол семейства TCP/IP, который был разработан в 80-х годах. Как я говорил ранее, используется для объединения отдельных компьютерных сетей между собой. Также важной его особенностью является адресация, которую называют

IP-адрес . На текущий момент существуют 2 версии протокола: IPv4 и IPv6. Пару слов о них:

1) IPv4. Использует 32-битные адреса, которые записываются в формате четырёх десятичных чисел (от 0 до 255), разделённых точками. Например, адрес 192.168.0.4. Каждое число разделенное точками называют октетом. Это самая популярная версия на сегодняшний день.

2) IPv6. Использует 128-битные адреса, которые записываются в формате восьми четырехзначных шестнадцатеричных чисел (от 0 до F). Например, адрес 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d. Каждое число разделенное точками называют хекстетом. На заре всеобщей компьютеризации появилась проблема. Стали заканчиваться IP-адреса и нужен был новый протокол, который смог бы обеспечить больше адресов. Так и появился в 1996 году протокол IPv6. Но благодаря технологии NAT, которая будет рассмотрена позже, была частична решена проблема нехватки адресов, и, в связи с этим, внедрение IPv6 затянулось по сегодняшний день.

Думаю понятно, что обе версии предназначены для одних и тех же целей. В этой статье будет разобран протокол IPv4. Про IPv6 будет написана отдельная статья.

Итак, протокол IP работает с блоком информации, который принято называть IP-пакет. Рассмотрим его структуру.

1) Версия. Протокол IPv4 или IPv6.

2) IHL (от англ. Internet Header Length - размер заголовка). Так как многие из показанных на картинке полей не фиксированы, то это поле считает размер заголовка.

3) Тип обслуживания. Обслуживает размер очередей QoS (Quality of Service - качество обслуживания). Делает он это при помощи байта, который указывает на определенный набор критериев (требование ко времени задержки, пропускной способности, надежности и т.д.)

4) Длина пакета. Размер пакета. Если IHL отвечает только за размер полей в заголовке (заголовком являются все поля на картинке, кроме поля данных), то длина пакета отвечает за весь пакет в целом, включая пользовательские данные.

5) Время жизни (TTL- Time To Live). Поле, используемое для предотвращения циклического пути пакета. При прохождении через маршрутизатор, значение уменьшается на единицу, и когда достигает нуля, пакет отбрасывается.

6) Протокол. Для какого вышестоящего протокола предназначается данный пакет (TCP, UDP).

7) Контрольная сумма заголовка. Здесь считается целостность полей заголовка. Не данных! Данные проверяются соответствующим полем на канальном уровне.

8) Опции. Это поле используется для расширения стандартного заголовка IP. Используется в привычных сетях редко. Сюда записываются данные для какого-нибудь специфического оборудования, которое читает это поле. Например, система управления дверными замками (где идет общение с контроллером), технология умного дома, интернет-вещи и так далее. Привычные сетевые устройства, как роутеры и коммутаторы, будут игнорировать это поле.

9) Смещение. Указывает, какому месту принадлежит фрагмент в оригинальном IP. Это значение всегда кратно восьми байтам.

10) Данные. Здесь как раз содержатся данные, полученные с вышестоящих уровней. Чуть выше я показал, что в Ethernet-кадре тоже есть поле данных. И в его поле данных будет включен данный IP-пакет. Важно помнить, что максимальный размер Ethernet-кадра равен 1500 байт, а вот размер IP пакета может быть 20 Кбайт. Соответственно весь пакет не вместится в поле данных Ethernet-кадра. Поэтому пакет делят и отправляют частями. И вот для этого используются 3 поля ниже.

11) Идентификатор. Это 4-х байтовое число, которое показывает, что все части разделенного пакета одно единое целое.

12) Флаги. Указывает, что это не единый, а фрагментированный пакет.

13) Смещение фрагмента. Сдвиг относительно первого фрагмента. То есть это нумерация, которая поможет собрать IP-пакет воедино.

14) IP-адрес отправителя и IP-адрес получателя. Соответственно эти 2 поля указывают от кого и для кого пакет.

Вот так выглядит IP-пакет. Конечно, для новичков значения многих полей покажутся не совсем понятными, но в дальнейшем это уложится в голове. Например: поле «Время жизни (TTL)». Его работа станет ясна, когда поймете, как работает маршрутизация. Могу дать совет, который я сам применяю. Если видите непонятный термин, выпишите его отдельно и, при наличии свободного времени, попробуйте разобрать. Если никак не лезет в голову, то отложите и вернитесь к его изучению чуть позже. Главное не забрасывать и в конечном итоге все таки добить.

Остался последний уровень из стека TCP/IP. Это транспортный уровень . Пару слов о нем. Он предназначен для доставки данных определенному приложению, которое он определяет по номеру порта. В зависимости от протокола, он выполняет разные задачи. Например, фрагментация файлов, контроль доставки, мультиплексирование потоками данных и управление ими. 2 самых известных протокола транспортного уровня - это UDP и TCP. Поговорим о каждом из них подробнее, и начну с UDP, в силу его простоты. Ну и по традиции показываю, из чего он состоит.

1) Порт источника. Порт, используемый клиентом или сервером для идентификации службы. На этот порт, при необходимости, будет посылаться ответ.

2) Порт назначения. Здесь указывается порт, который будет являться адресатом. Например, если клиент запрашивает страницу сайта, то порт назначения, по умолчанию, будет 80-ый (протокол HTTP).

3) Длина UDP. Длина заголовка UDP. Размер варьируется от 8 до 65535 байт.

4) Контрольная сумма UDP. Проверка целостности. Если нарушена, то просто отбрасывает без запроса о повторной отправки.

5) Данные. Здесь упакованы данные с верхнего уровня. Например, когда веб-сервер отвечает на запрос клиента и отправляет веб-страницу, то она будет лежать в этом поле.

Как видите, у него не так много полей. Его задачи - это нумерация портов и проверять побился кадр или нет. Протокол простой и не требовательный к ресурсам. Однако он не может обеспечивать контроль доставки и повторно запрашивать побитые куски информации. Из известных сервисов, которые работают с этим протоколом - это DHCP, TFTP. Они рассматривались в статье, когда разбирались протоколы верхнего уровня.

Переходим к более сложному протоколу. Встречаем протокол TCP. Смотрим, из чего состоит, и пробегаем по каждому полю.

1) Порт источника и порт назначения. Выполняют те же роли, что и в UDP, а именно нумерация портов.

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

3) Номер подтверждения. Это поле используется, когда ожидается доставка или подтверждается доставка. Для этого используется параметр ACK.

4) Длина заголовка. Используется для того, чтобы понять какой размер у TCP-заголовка (это все поля представленные на картинке выше, кроме поля данных), а какой у данных.

5) Зарезервированный флаг. Значение этого поля должно устанавливаться в ноль. Оно зарезервировано под специальные нужды. Например, чтобы сообщить о перегрузках в сети.

6) Флаги. В это поле устанавливаются специальные биты для установления или разрыва сессии.

7) Размер окна. Поле, указывающее, на сколько сегментов требовать подтверждения. Наверное, каждый из вас наблюдал такую картину. Вы скачиваете какой-то файл и видите скорость и время скачивания. И тут сначала он показывает, что осталось 30 минут, а через 2-3 секунды уже 20 минут. Еще спустя секунд 5, показывает 10 минут и так далее. Это и есть размер окна. Сначала размер окна устанавливается таким образом, чтобы получать больше подтверждений о каждом отправленном сегменте. Далее все идет хорошо и сеть не сбоит. Размер окна меняется и передается больше сегментов и, соответственно, требуя меньше отчетов о доставке. Таким образом, скачивание выполняется быстрее. Как только сеть даст краткий сбой, и какой то сегмент придет побитым, то размер опять изменится и потребуется больше отчетов о доставке. В этом суть данного поля.

8) Контрольная сумма TCP. Проверка целостности TCP-сегмента.

9) Указатель важности. Это смещение последнего октета важных данных относительно SEQ для пакетов с установленным флагом URG. В жизни применяется, когда необходимо осуществить контроль потока или состояния протокола верхнего уровня со стороны передающего агента (например, если принимающий агент может косвенно сигнализировать передающему, что не справляется с потоком данных).

10) Опции. Используется для каких нибудь расширенных или дополнительных параметров. Например, для параметра timestamp, который является своеобразной меткой, показывающей время произошедшего события.

11) Данные. Практически тоже самое, что и в протоколе UDP. Здесь инкапсулированы данные с вышестоящего уровня.

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

Я открываю CPT и соберу схему, аналогичную одному из рисунков выше.

Здесь наблюдаем первую сеть, состоящую из 4-х компьютеров и коммутатора, который объединяет эти компьютеры. И 2-ую сеть, состоящую из двух компьютеров и коммутатора. Объединяет эти 2 сети маршрутизатор. Перейдем к настройке устройств и после смоделируем ту ситуацию, которую мы рассматривали в самом начале на картинке.

Открываю компьютер PC1 и пропишу сетевые настройки.

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

1) IP-адрес - 192.168.1.1

Эту маску мы рассматривали выше. Напомню, что адрес сети у других хостов в той же локальной сети, должен быть 192.168.1, а адрес хоста может быть от 1 до 254.

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

Чтобы не было много однотипных картинок, я не буду приводить скриншоты остальных 3-х компьютеров, а только приведу их настройки.

PC2:
1) IP-адрес - 192.168.1.2
.
3) Основной шлюз - 192.168.1.254.

PC3:
1) IP-адрес - 192.168.1.3
2) Маска подсети - 255.255.255.0.
3) Основной шлюз - 192.168.1.254.

PC4:
1) IP-адрес - 192.168.1.4
2) Маска подсети - 255.255.255.0.
3) Основной шлюз - 192.168.1.254.

На данной настройке пока остановимся и посмотрим, как работает наша локальная сеть. Перевожу CPT в режим симуляции. Допустим, я сижу за компьютером PC1, и требуется проверить доступность PC4 командой ping. Открываю командную строку на PC1.

Как только нажимаю ENTER, на схеме появляются 2 конверта.

Один из них ICMP, с которым работает сама команда ping. Сразу открываю его и смотрю.

Вижу данные IP и ICMP. Тут нет ничего интересного, за исключением нескольких полей. А именно, цифра 4 в верхнем левом углу данных IP, которая говорит о том, что используется протокол IPv4. И 2 поля с IP-адресом источника и назначения (SRC:192.168.1.1 и DST:192.168.1.4).

Но тут ping сталкивается с проблемой. Он не знает MAC-адрес получателя. То есть, адрес канального уровня. Для этого он использует протокол ARP, который сможет опросить участников сети и узнать MAC-адрес. Мы про него вскользь говорили в предыдущей статье. Давайте поговорим о нем подробнее. Не буду изменять традиции. Картинку в студию!

1) Тип протокола канального уровня (Hardware type). Думаю понятно из названия, что тут указывается тип канального уровня. Мы пока рассматривали только Ethernet. Его обозначение в этом поле - 0x0001.

2) Тип протокола сетевого уровня (Protocol type). Тут, аналогично, указывается тип сетевого уровня. Код IPv4 - 0x0800.

3) Длина физического адреса в байтах (Hardware length). Если это MAC-адрес, то размер будет 6 байт (или 48 бит).

4) Длина логического адреса в байтах (Protocol length). Если это IPv4-адрес, то размер будет 4 байта (или 32 бита).

5) Код операции (Operation). Код операции отправителя. Если это запрос, то код 0001. В случае ответа - 0002.

6) Физический адрес отправителя (Sender hardware address). MAC-адрес отправителя.

7) Логический адрес отправителя (Sender protocol address). IP-адрес отправителя.

8) Физический адрес получателя (Target hardware address). MAC-адрес получателя. Если это запрос, то, как правило, адрес неизвестен и это поле остается пустым.

9) Логический адрес получателя (Target protocol address). IP-адрес получателя.

Теперь, когда мы знаем, из чего он состоит, можно посмотреть на его работу в CPT. Кликаю по второму конверту и наблюдаю следующую картину.

И вот протокол ARP во всей красе. На 2-ом уровне работает протокол Ethernet. Остановимся и посмотрим на его поля.

1) Преамбула - здесь битовая последовательность, которая говорит о начале кадра.

2) Далее идет MAC-адрес источника и получателя. В адресе источника записан MAC-адрес компьютера, который является инициатором, а в адресе получателя записан широковещательный адрес FF-FF-FF-FF-FF-FF (то есть для всех узлов в канальной среде).

3) Тип - здесь указан вышестоящий протокол. Код 0x806 означает, что выше стоит ARP. Я, если честно, не могу точно сказать, на каком уровне он работает. В разных источниках указано по-разному. Кто то говорит, что на 2-ом уровне OSI, а кто-то говорит, что на 3-ем. Я считаю, что он между ними работает. Так как тут есть адреса, присущие каждому из уровней.

Про данные и чек-сумму много говорить не буду. Данные здесь никак не указаны, а чек-сумма нулевая.

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

1) Hardware Type - код канального уровня. CPT убрала лишние нули и вставила 0x1 (тоже, что и 0x0001). Это Ethernet.
2) Protocol Type - код сетевого уровня. 0x800 - это IPv4.
3) HLEN - длина физического адреса. 0x6 означает 6 байт. Все верно (MAC-адрес занимает 6 байт).
4) PLEN - длина сетевого адреса. 0x4 означает 4 байта (IP-адрес занимает 4 байта).
5) OPCODE - код операции. 0x1 означает, что это запрос.
6) Source Mac - здесь MAC-адрес отправителя. Можно сравнить его с адресом в поле протокола Ethernet и убедиться в правильности.
7) Source IP - IP-адрес отправителя.
8) Target MAC - так как это запрос и канальный адрес не известен, то он пустой. CPT показала его нулями, что равносильно.
9) Target IP - IP-адрес получателя. Как раз тот адрес, который пингуем.

Протокол ARP опрашивает все хосты в локальной сети и только один отвечает на этот запрос. Это PC4. Посмотрим, чем он ответит.

Вот он выплевывает что-то на коммутатор. Открываю его и вижу некоторые изменения, а именно:

1) В поле источника протокола Ethernet теперь записан MAC-адрес PC4, а в поле назначения MAC-адрес инициатора, то есть PC1.
2) В поле OPCODE теперь значение 0x2, то есть ответ.
3) Поменялись поля логических и физических адресов в протоколе ARP. Source MAC и Destination MAC аналогичны тем, что в протоколе Ethernet. В поле Source IP - адрес 192.168.1.4 (PC4), а в поле Destination IP - адрес 192.168.1.1 (PC1).

Как только эта информация достигнет PC1, он сразу формирует ICMP-сообщение, то есть ping.

Открываю его и смотрю. Это блок данных, состоящий из работы 3-х протоколов: Ethernet, IP и Ping.

1) В Ethernet протоколе ничего нового, а именно MAC-адрес отправителя - PC1, MAC-адрес получателя - PC4, а в поле Type - 0x800 (протокол IPv4)
2) В IP протоколе, в поле Версия - 4, что означает протокол IPv4. IP-адрес отправителя - PC1, а IP-адрес получателя - PC4.
3) В ICMP протоколе, в поле Type - код 0x8 (эхо-запрос).

Посылает он эхо-запрос, а я смотрю, чем ответит PC4.

Перекосил у меня CPT, и пришлось перезапустить его. Только теперь ICMP конверт не светло-зеленового цвета, а смесь зеленого и синего. Но это без разницы. Это одни и те же данные.
Ну что же, смотрю, чем ответил PC4. Поля источника и назначения в протоколах Ethernet и IP поменялись местами. А в поле Type протокола ICMP изменилось значения с 0x8 на 0x0 (означает эхо-ответ).

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

И действительно. Появилась запись о доступности PC4, размер данных (32 байта), задержка по времени (8 мс) и TTL или время жизни (128). TTL показывает, сколько маршрутизаторов преодолел пакет. У меня пакет гулял в пределах локальной сети, поэтому данное поле не изменилось.

По умолчанию пинг отправляет 4 запроса. Следовательно, PC1 сформирует еще 3 аналогичных ICMP. Показывать путь каждого пакета я не буду, а приведу финальный вывод консоли на PC1.

И как видите, действительно 4 ответа. Заметьте, что первый пришел с задержкой в 8 мс, а 3 последних в 4 мс. Это связано с работой протокола ARP, так как сначала PC1 не знал MAC-адрес PC4 и ждал, когда ему сообщат. Хотя в CPT встречается ситуация, что в режиме реального времени, первый пакет вообще теряется. Особенно часто это проявляется, когда проверяется доступность хоста, находящегося в другой канальной среде.

Увидели мы, как работает передача данных в одной канальной среде. Теперь посмотрим, что произойдет, если хосты окажутся в разных канальных средах или подсетях. Напомню, что сеть настроена не до конца. А именно, нужно настроить маршрутизатор и вторую подсеть. Чем сейчас и займемся.

Открываю я компьютер с именем PC5 и пропишу сетевые настройки.

Заметьте, что сетевая адресация в первой канальной среде, была 192.168.1.X, а во 2-ой 192.168.2.X. При маске 255.255.255.0, это означает, что первые 3 октета фиксированы, а 4-ый октет в пределах от 1 до 254. И так как у нас 3-ие октеты различаются, то это разные канальные среды.

Привожу настройки PC6:

1) IP-адрес - 192.168.2.2
2) Маска подсети - 255.255.255.0
3) Основной шлюз - 192.168.2.254

Хосты во 2-ой канальной среде настроены и прекрасно работают. Для того, чтобы они смогли общаться с хостами из 1-ой канальной, нужно настроить маршрутизатор, который соединяет эти среды. Маршрутизатор настраивается через CLI (то есть в консольном виде) и проще будет приводить сюда не скриншоты, а команды.

1) Router>enable - переход в привилегированный режим
2) Router#configure terminal - переход в режим глобальной конфигурации
3) Router(config)#interface fastEthernet 0/0 - переходим к настройке порта 0/0, который смотрит на первую канальную среду
4) Router(config-if)#ip address 192.168.1.254 255.255.255.0 - вешаем на этот порт IP-адрес. Так как этот порт будет являться основным шлюзом для 1-ой канальной среды, то указываем ему тот IP, который прописали хостам
5) Router(config-if)#no shutdown - включаем этот интерфейс. По умолчанию все порты на цисковских маршрутизаторах выключены
6) Router(config-if)#exit - выходим из режима настройки fastEthernet 0/0
7) Router(config)#interface fastEthernet 0/1 - переходим к настройке порта 0/1, который смотрит на вторую канальную среду
8) Router(config-if)#ip address 192.168.2.254 255.255.255.0 - вешаем сюда адрес, который будет являться основным шлюзом для хостов во 2-ой канальной среде
9) Router(config-if)#no shutdown - аналогично включаем его
10) Router(config-if)#end - пишем команду, которая отбросит в привилегированный режим
11) Router#copy running-config startup-config - сохраняем настройки в памяти маршрутизатора

На этом этапе настройка маршрутизатора окончена. Немного забегу вперед и покажу полезную команду «show ip route». Она показывает все известные маршрутизатору сети и маршрут до них.

Исходя из этой таблицы, можно удостовериться, что он знает и про 1-ую канальную среду, и про 2-ую. Отлично. Осталось дело за малым - это проверить доступность PC5 из PC1. Пробую. Переключаю CPT в режим симуляции. Открываю командную строку и пингую 192.168.2.1.

Как только нажимаю ENTER, сразу появляется 2 конверта: ICMP и ARP. Остановимся и посмотрим на них подробнее. Сейчас может показаться, что передача между разными канальными средами ничем не отличается от передачи в одной канальной среде, но это не так. И сейчас вы это увидите.

Сначала посмотрим на ICMP.

Здесь пока в принципе ничего интересного. В поле источника - IP-адрес PC1, а в поле назначения - IP-адрес PC5.

Что же будет происходить дальше. PC1 видит, что проверяется доступность хоста, находящегося в другой канальной среде (путем наложения маски на свой IP-адрес и IP-адрес получателя). И кроме IP-адреса он не знает о получателе ничего. Соответственно в таком виде отправлять пакет ICMP нельзя. Зато он знает, что у него есть основной шлюз, который, скорее всего, знает что-то про канальную среду, в которой находится PC5. Но возникает еще одна сложность. Он знает IP-адрес шлюза (который я ему прописал в сетевых настройках), но не знает его MAC-адреса. Тут ему приходит на помощь протокол ARP, который опросит всех участников канальной среды и найдет его MAC-адрес. Посмотрим, как заполнены поля.

На канальном уровне (протокол Ethernet): Поле источника - MAC-адрес PC1, а в поле назначения - широковещательный адрес (то есть всем участникам).

И чуть повыше (протокол ARP):

1) SOURCE MAC - тот же PC1, а DESTINATION MAC пустой (его должен заполнить тот, для кого этот запрос предназначен).
2) SOURCE IP - адрес PC1, а вот DESTINATION IP - адрес основного шлюза.

3 компьютера отбросили пакет, и только маршрутизатор понял, что это для него. Смотрим, чем ответит.

Ethernet:

1) Source MAC - сюда он вставляет свой MAC-адрес (а именно MAC-адрес fastEthernet0/0).
2) Destination MAC - сюда записывает MAC-адрес PC1 (то есть того, кто запросил).
ARP:
1) Source MAC и Destination MAC аналогично записям в протоколе Ethernet.
2) Source IP - свой IP-адрес.
3) Target IP - IP-адрес PC1.

Как только ARP доходит от маршрутизатора к PC1, то сразу PC1 отсылает ICMP сообщение на маршрутизатор (или основной шлюз). И вот здесь прошу обратить особое внимание. А именно, на поля источника и назначения (и в протоколе Ethernet, и в протоколе IP).

1) SRC MAC: здесь указан MAC-адрес PC1.
2) DEST MAC: MAC-адрес маршрутизатора.
3) SRC IP: IP-адрес PC1.
4) DST IP: IP-адрес PC5.

Что это значит. Адреса на сетевом уровне (то есть IP-адреса) не меняются, чтобы знать от кого и кому предназначается информация. А адреса на канальном уровне (MAC-адреса) могут спокойно меняться, переходя из одной канальной среды в другую. Это очень важно понять и запомнить!

Смотрим, что происходит. Пакет доходит до маршрутизатора и сразу перечеркивается. А все из-за того, что он не знает MAC-адрес PC5. Теперь он формирует ARP-запрос и пытается его узнать. Привожу скриншот этого запроса.

Как только этот ответ дойдет до маршрутизатора, он будет знать канальный адрес PC5. Но вот что произошло. Пока тянулась канитель с ARP у маршрутизатора и PC5, у PC1 истекает время ожидания ответа отправленного ICMP. Показываю картинку.

После истечения времени ожидания, он формирует второе ICMP, ответ которого уже дойдет без проблем, так как MAC-адреса известны. Следом он сформирует 3-ье и 4-ое ICMP. Привожу конечный итог.

И если внимательно присмотреться, то можно заметить, что TTL снизился на единицу и теперь равен 127. Это произошло из-за того, что пакет преодолел один транзитный участок (маршрутизатор).

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

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

Начну, как всегда, с простого. И это протокол UDP. Как я уже говорил выше, он используется для того, чтобы передать данные определенному протоколу вышестоящего уровня. Делает он это при помощи портов. Один из протоколов, работающих с UDP - это TFTP(Trivial File Transfer Protocol). Протокол этот мы рассматривали в предыдущей статье. Поэтому трудностей возникнуть не должно. Для демонстрации потребуется добавить в сеть сервер с включенной службой TFTP.

Настройки сервера следующие:

1) IP-адрес - 192.168.1.5
2) Маска подсети - 255.255.255.0
3) Основной шлюз - 192.168.1.254

Служба TFTP включена по умолчанию, но лучше проверить. Далее переключаю CPT в режим симуляции и попробую сохранить конфигурацию маршрутизатора на TFTP-сервер:

1) Router>enable - переход в привилегированный режим.
2) Router#copy startup-config tftp: - пишу команду copy (то есть скопировать), далее startup-config (что именно скопировать) и tftp: (куда скопировать).
3) Address or name of remote host ? 192.168.1.5 - выходит сообщение с запросом адреса или имени сервера, где я пишу его адрес.
4) Destination filename ? - следом он спрашивает, под каким именем его сохранить на сервере и предлагает стандартное имя. Меня это устраивает, и я жму ENTER.

Сразу маршрутизатор формирует 2 конверта. Один из них - это перечеркнутый TFTP, а второй ARP. Думаю, догадались, что перечеркнут он из-за того, что не знает MAC-адрес сервера.

Пропущу я момент работы ARP, так как мы вдоволь на него насмотрелись.

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

Ethernet:
1) Source MAC - адрес маршрутизатора.
2) Destination MAC - адрес сервера.
3) Type - 0x800 (означает, что выше работает протокол IP).

IP:
1) Protocol - 0x11 (означает, что выше работает протокол UDP).
2) Source IP - адрес маршрутизатора.
3) Destination IP - адрес сервера.

UDP:
1) Source Port - динамически созданный порт (1025).
2) Destination Port - порт, который слушает TFTP-сервер (зарезервированный 69 порт).

TFTP:
Здесь находятся сами данные.

Так и работает протокол UDP. Он не устанавливает сессии, не требует подтверждения доставки, а если что-то потеряется, он не запрашивает повторно. Его работа - это указать номер порта и отправить. Что там будет происходить дальше, его не интересует. Но возникают случаи, когда это не устраивает и все эти параметры критически важны. Тогда на помощь приходит протокол TCP. Рассмотрим его на примере использования веб-сервера и веб-клиента. Веб-сервером у нас будет тот же TFTP-сервер. Включаем службу HTTP и запросим страницу с компьютера PC1. Не забываем переключить CPT в режим симуляции!

Набираю адрес веб-сервера и нажимаю ENTER.

Перед тем как продолжить, я расскажу про установление TCP-сессии. Постараюсь изложить этот процесс максимально просто. Этот процесс называют «трехстороннее рукопожатие» или «handshake». В чем суть. Клиент отправляет TCP-сегмент с флагом «SYN». Получив сегмент, сервер принимает решение. Если он согласен установить соединение, то он отправляет ответный сегмент с флагом «SYN+ACK». Если не согласен, то отправляет сегмент с флагом «RST». Далее клиент смотрим на ответный сегмент. Если там стоит флаг «SYN+ACK», то он в ответ отправляет сегмент с флагом «ACK» и устанавливается соединение. Если же там стоит флаг «RST», то он прекращает попытки соединения. После того, как потребуется разорвать установившееся соединение, клиент формирует и отправляет TCP-сегмент с флагом «FIN+ACK». Сервер на этот сегмент отвечает аналогичным флагом «FIN+ACK». И наконец, клиент отправляет последний TCP-сегмент с флагом «ACK». Сейчас вы увидите, как это работает на практике.

Переключаю внимание на сеть и вижу, как PC1 формирует TCP-сегмент.

Поля протоколов Ethernet и IP я рассматривать не буду, так как тут ничего нового, за исключением поля Protocol в протоколе IP. Там стоит значение - 0x6. Это говорит о том, что выше используется протокол TCP.

А вот в TCP уже поинтереснее.

1) Source Port - 1025 (это динамически сгенерированный порт веб-клиента).
2) Destination Port - 80 (это зарезервированный порт протокола HTTP).
3) Flag - SYN (запрос на установление сессии)

Смотрим, чем ответит веб-сервер.

Меняет он номера портов местами и отправляет сегмент с флагом «SYN+ACK».

Как только клиент получает этот сегмент, он сразу формирует 2 сообщения. Один из них TCP-сегмент, представленный ниже, который отправляется с флагом «ACK».

А второй - HTTP, где указана версия протокола, какая страница и адрес сервера.

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

Как только клиент получает желаемую страницу, ему больше нет смысла поддерживать соединение и он инициирует разрыв. Отправляет сегмент с флагом «FIN+ACK». Смотрим дальше.

Сервер согласен разорвать соединение и в ответ отправляет сегмент с аналогичным флагом «FIN+ACK».

И наконец, клиент формирует последний TCP-сегмент с флагом «ACK» и закрывает соединение.

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

Ну что же, статья подходит к концу. Хочу выразить благодарность пользователю под ником за предоставленную картинку и остальным пользователям, которые оставляют полезные комментарии к статьям. Очень приятно видеть, как люди интересуются, задают вопросы, ведут объективные и конструктивные споры. Хочется, чтобы русскоязычное IT-сообщество все больше развивалось и материалов для изучения в свободном доступе становилось все больше. Спасибо за прочтение и до встречи на следующей.

tcp/ip

icmp

Добавить метки
9) Маршрутизация: статическая и динамическая на примере RIP, OSPF и EIGRP.
10) Трансляция сетевых адресов: NAT и PAT.
11) Протоколы резервирования первого перехода: FHRP.
12) Безопасность компьютерных сетей и виртуальные частные сети: VPN.
13) Глобальные сети и используемые протоколы: PPP, HDLC, Frame Relay.
14) Введение в IPv6, конфигурация и маршрутизация.
15) Сетевое управление и мониторинг сети.

P.S. Возможно, со временем список дополнится.

Как вы помните, я уже говорил о том, что в сетях важно строгое соблюдение всех правил для корректной работы. А именно процесс инкапсуляции и деинкапсуляции. Поэтому, когда в предыдущей статье говорили о протоколах верхних уровней, я вскользь упоминал о некоторых протоколах нижних уровней, так как они постоянно вылезали и напоминали о себе. Объясню почему. Посмотрите сейчас на картинку выше. Тут приведена работа почты. Взгляните на двух лысых дядек вверху, которые написали письмо и светятся от счастья. Но толку не будет от письма, если его не увидит адресат. Для этого они воспользуются почтовой службой. Их письмо примет сотрудница почтового отделения и положит в конверт. Конверт она подпишет, чтобы было понятно от кого оно и кому. Дальше это письмо заберет курьер и отнесет в сортировочный центр. Ниже стоит мужичок в фуражке и фартуке, который жонглирует письмами. Он знает, куда положить письмо, чтобы оно дошло до адресата. И в самом низу поезд, который является транспортным узлом. Заметьте, что тут важна роль каждого для удачной отправки и доставки письма.

В сетях все тоже самое. Решили вы залезть на сайт и почитать новости. Набираете в строке браузера адрес сайта. Дальше ваш компьютер как то должен эти страницы запросить. И тут уже на помощь придут протоколы пониже, которые являются транспортным узлом. Здесь каждый уровень можно сравнить с вышеописанными личностями на рисунке.

Подведу я всю эту канитель к общему знаменателю и поделюсь примером, который я когда-то для себя вывел. У вас есть оконечное сетевое устройство. Не важно компьютер, ноутбук, планшет смартфон или еще что. Каждое из этих устройств работает по стеку TCP/IP. А значит, оно соблюдает его правила.

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

2) Транспортный уровень. У приложения или службы должен быть порт, который он слушает и по которому с ним можно связаться.

3) Сетевой уровень. Здесь присутствует IP-адрес. Его еще называют логическим адресом устройства в сети. При помощи него можно связаться с компьютером, на котором запущен этот самый браузер, а значит, и достучаться до самого приложения. Имея данный адрес, он является участником сети и может связываться с другими участниками

4) Канальный уровень. Это сама сетевая карточка или антенна. То есть передатчик и приемник. У него есть физический адрес для идентификации этой сетевой карты. Кабели, коннекторы тоже относятся сюда. Это среда, которая свяжет компьютер с другими участниками.

Начнем с самого нижнего уровня. Это канальный и физический уровень, если рассматривать с точки зрения модели OSI и уровень доступа, если смотреть с высоты стека протоколов TCP/IP. Пользуемся мы TCP/IP, поэтому я буду говорить с ее точки зрения. Уровень доступа, как вы поняли, объединяет в себе физический и канальный уровень.

Физический уровень. Или как его любят называть «электрический уровень». Задает параметры сигнала, а также какой вид и форму имеет сигнал. Если, например, используется Ethernet (который передает данные при помощи провода), то какая модуляция, напряжение, ток. Если это Wi-Fi, то какие использовать радиоволны, частоту, амплитуду. К этому уровню можно отнести сетевые карты, Wi-Fi антенны, коннекторы. На этом уровне вводится такое понятие, как биты. Это единица измерения передаваемой информации.

Канальный уровень. Этот уровень используется для того, чтобы передать не просто биты, а осмысленные последовательности из этих бит. Используется для передачи данных в одной канальной среде. Что это значит, я опишу чуть позже. На этом уровне работают MAC-адреса, которые еще называют физические адреса.

Термин «физические адреса» ввели не просто так. Каждая сетевая карта или антенна имеет вшитый адрес, который ей присваивает производитель. В предыдущей статье я упоминал термин «протоколы». Только там это были протоколы верхнего уровня, а если точнее, то прикладного. На канальном уровне работают свои протоколы и количество их не маленькое. Самые популярные - это Ethernet (используется в локальных сетях), PPP и HDLC (они используются в глобальных сетях). Это конечно далеко не все, но Cisco в своей сертификации CCNA рассматривает только их.

Тяжело все это понять в виде сплошного сухого текста, поэтому объясню на картинке.

Забудьте сейчас про IP-адреса, модель OSI и стек протоколов TCP/IP. У вас есть 4 компьютера и коммутатор. На коммутатор внимания не обращайте, так как это обычная коробка для соединения компьютеров. У каждого компьютера есть свой MAC-адрес, который идентифицирует его в сети. Он должен быть обязательно уникальный. Хоть я и представил их 3-х значными, это далеко не так. Сейчас эта картинка только для логического понимания, а как это работает в реальной жизни, напишу чуть ниже.

Итак. Если один из компьютеров захочет что-то отправить другому компьютеру, то ему потребуется знать только MAC-адрес компьютера, на который он отправляет. Если верхнему левому компьютеру с MAC-адресом 111 захочется что-то отправить нижнему правому компьютеру, то он без проблем отправит это, если будет знать, что у адресата MAC-адрес 444.

Эти 4 компьютера образуют простенькую локальную сеть и одну канальную среду. Отсюда и название уровня. Но для корректной работы узлов в сетях TCP/IP, недостаточно адресации на канальном уровне. Важна еще адресация на сетевом уровне, которая всем известна, как IP-адресация.

Теперь вспоминаем про IP-адреса. И присвоим их нашим компьютерам.

Адреса я присвоил символически, чтобы на базовом уровне понять, как они работают. Вот эти две адресации (канальная и сетевая) работают в тесной связке между собой и по отдельности работать не смогут. Сейчас объясню почему. Мы в повседневной жизни работаем только с IP-адресами или именами, о которых была целая глава в предыдущей статье. С MAC-адресами мы фактически не работаем. С ними работают сами компьютеры. Сейчас смоделирую ситуацию. Я сижу за верхним левым компьютером с IP: 1.1.1.1 и MAC: 111. Захотел я связаться с нижним правым компом и проверить живой он или нет. Я смогу связаться с ним, если буду знать его IP-адрес. MAC-адрес мне его не интересен. Я знаю, что IP-адрес у него 1.1.1.4. И решаю воспользоваться утилитой ping (утилита проверки доступности узла).

Теперь важная вещь. Компьютер понимает, что он не знает MAC-адрес компьютера, доступность которого надо проверить. Для того, чтобы узнать MAC-адрес по IP-адресу, придумали протокол ARP. Я о нем напишу подробно позже. Сейчас я хочу, чтобы вы поняли зависимости MAC-адреса и IP-адреса. Итак, он на всю сеть начинает кричать: «Кто такой 1.1.1.4». Этот крик услышат все участники сети и, если найдется тот узел, который имеет данный IP-адрес, он отзовется. У меня такой компьютер присутствует и в ответ на этот крик, он ответит: «1.1.1.4 - это я. Мой MAC - 444». Мой компьютер получит это сообщение и сможет продолжить то, что я ему сказал.

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

Если вы когда-нибудь залезали в настройки сетевых адаптеров или прописывали статический адрес, который вам сообщал провайдер, то видели поле «маска подсети». Она записывается в том же формате, что и IP-адрес, основной шлюз и DNS. Это четыре октета разделенных между собой точками. Если вы этого никогда не видели, то можете открыть командную строку и набрать в ней ipconfig. Вы увидите, что-то похожее.

Это скриншот из командной строки моего ноутбука. Я сижу за домашней точкой доступа, у которой маска 255.255.255.0. Это, наверное, самая простая маска для объяснения и скорее всего у вас она точно такая же. В чем суть. Первые 3 октета (они фиксированы) показывают адрес сети, а 4 октет (он динамический) показывает адрес хоста. Иными словами, данная маска показывает, что нужно проверять первые 3 октета полностью, а четвертый может быть свободным от 0 - 255. Вообще это грубая формулировка. Потому, что с такой маской свободны будут от 1 до 254, где 0 уйдет под адрес сети, а 255 под широковещательный адрес. Но в любом случае это предел одной канальной среды. То есть, когда узлу надо отправить другому узлу сообщение, он берет его адрес и накладывает на него маску и если адрес сети (фиксированная часть) сходится с его адресом, то значит они в одной канальной среде. Объясняю на примере той же картинки.

Сижу я за верхним левым компом и хочу отправить нижнему правому. Знаю я и IP-адрес его и MAC-адрес. Мне надо понять, в одной канальной среде мы или нет. Его адрес 1.1.1.4 и маска 255.255.255.0. Маска мне говорит, что 3 октета фиксированы и не должны меняться, а четвертый может быть любым в пределах от 1 до 254. Я накладываю маску на его адрес и на свой адрес и смотрю совпадения и различия.

Красным подсвечено та область, которая отвечает за сеть. Как видим, у 2-х хостов она одинакова. Значит, они находятся в одной подсети.

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

Добавилась круглое устройство. Оно называется роутер или маршрутизатор. Слово всем знакомое. Основная его роль - это соединение сетей и выбор лучшего маршрута, о чем будет в дальнейшем рассказано более подробно. И добавился, справа, один коммутатор, с которым соединены 2 компьютера. Маска для всех устройств не изменилась (255.255.255.0).

Посмотрите внимательно на адреса всех устройств. Можно заметить, что у новых узлов и старых отличается 3-ий октет. Давайте разберемся с этим. Я также сижу за компом с MAC:111 и IP:1.1.1.1. Хочу отправить информацию одному из новых узлов. Давайте пусть это будет верхний правый компьютер с MAC:555 и IP:1.1.2.1. Накладываю маску и смотрю.

И тут уже другая картина. 3-ие октеты различаются, а значит, узлы находятся в разных сетях (правильнее подсетях). Для разрешения таких ситуации, в настройках каждой операционной системы есть основной шлюз. Его еще называют «шлюз последней надежды». Используется он, как раз, в том случае, когда нужно отправить информацию узлу, находящемся в другой канальной среде. Для моего компа адрес шлюза - 1.1.1.254. А для компьютера, которому я отправляю данные 1.1.2.254. Логика работы здесь простая. Если узлу, который находился в одной канальной среде, информация доходила напрямую, то для узла находящегося в другой канальной среде, путь будет через маршрутизатор.

Мой комп знает, что адрес шлюза 1.1.1.254. Он крикнет на всю сеть: «1.1.1.254 отзовись». Это сообщение получат все участники канальной среды, но ответит только тот, кто сидит за этим адресом. То есть маршрутизатор. Он отправит ответ, и только после этого мой комп отошлет данные до адреса 1.1.2.254. Причем обратите внимание. На канальном уровне данные будут отправлены на MAC:777, а на сетевом, на IP:1.1.2.1. Это значит, что MAC-адрес передается только в своей канальной среде, а сетевой адрес не меняется на всем своем пути. Когда маршрутизатор получит инфу, он поймет, что на канальном уровне она предназначалась ему, но когда увидит IP-адрес, то поймет, что он промежуточное звено и передать надо в другую канальную среду. Его второй порт смотрит в нужную подсеть. Значит, ему все пришло верно. Но он не знает MAC-адрес адресата. Он начинает так же кричать на всю сеть: «Кто такой 1.1.2.1?». И комп с MAC-адресом 555 отвечает ему. Думаю, что логика работы понятна.

На протяжении двух предыдущих статей и текущей, много раз упоминался термин «MAC-адрес» . Давайте разберем, что это такое.

Как я уже говорил, это уникальный идентификатор сетевого устройства. Он уникален и не должен нигде повторяться. Состоит он из 48 бит, из которых первые 24 бита - это уникальный идентификатор организации, который присваивается комитетом IEEE(Институт инженеров электротехники и электроники). А вторые 24 бита назначаются производителем оборудования. Выглядит это так.

Записывают его по-разному. Например:

1) 00-50-56-C0-00-08
2) 00:50:56:C0:00:08
3) 0050.56С0.0008

Как видите, один и тот же адрес можно записать разными способами. Еще обычно его не разделяют, а записывают слитно. Главное знать, что MAC-адрес всегда состоит из 48 бит и состоит из 12 букв и/или цифр. Посмотреть его можно разными способами. Например, в ОС Windows, открыв командную строку, ввести ipconfig /all. Многие производители еще записывают его на коробке или на обратной стороне корпуса устройства.

Так что можете посмотреть на свою Wi-Fi точку доступа и увидеть похожую запись. В самом начале я показал MAC-адреса 3-х значными цифрами, что не правда. В том контексте я их употреблял только для простоты объяснения, чтобы не путать вас длинными непонятными записями. Чуть ниже, когда речь дойдет до практики, вы увидите их такими, какие они на самом деле.

Раз мы разобрали адрес на канальном уровне, пришло время разобрать протокол, работающий на данном уровне. Самый популярный на сегодняшний момент протокол, используемый в локальных сетях - это Ethernet . IEEE описала его стандартом 802.3. Так что, все версии, которые начинаются с 802.3, относятся именно к нему. Например, 802.3z - это GigabitEthernet через волоконно-оптический кабель; 1 Гбит/с, а 802.3af - это электропитание через Ethernet (PoE - Power over Ethernet).

Кстати, я не сказал об организации IEEE (англ. Institute of Electrical and Electronics Engineers) . Эта организация разрабатывает стандарты ко всему, что относится к радиоэлектронике и электротехнике. На их сайте можно найти много документации по существующим технологиям. Вот, что они выдают по запросу «Ethernet»

Давайте разберем, из чего он состоит. Так как сам протокол старый (придуман в 1973 году), то он много раз модернизировался и менял свой формат. В Интернете можно найти все его варианты, но я приведу тот, который приводила Cisco, когда я учился.

1) Преамбула. Поле, используемое для указания начала кадра. То есть, чтобы приемник смог понять, где начало нового кадра. Раньше, когда использовалась топология с общей шиной и были коллизии, преамбула помогала предотвращать коллизии.

2) MAC-адрес получателя. Поле, куда записывается адрес получателя.

3) MAC-адрес отправителя. Соответственно сюда записывается адрес отправителя.

4) Тип (длина). Раньше в этом поле указывалось, какому вышестоящему протоколу передается данный кадр, но в дальнейшем от этого отказались и ввели поле «Длина». Оно указывает длину поля данных, которое варьируется от 46-1500 байт.

5) Поле SNAP/LLC + данные. Как раз SNAP/LLC указывает какому вышестоящему протоколу передать кадр. Это может быть IP, IPX и другие протоколы сетевого уровня. Также в этом поле содержатся данные, полученные с высших уровней.

6) FCS (от англ. Frame Check Sequence - контрольная сумма кадра). Поле в котором подсчитана чек-сумма. По ней получатель понимает, побился кадр или нет.

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

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

IP (от англ. Internet Protocol). Протокол семейства TCP/IP, который был разработан в 80-х годах. Как я говорил ранее, используется для объединения отдельных компьютерных сетей между собой. Также важной его особенностью является адресация, которую называют

IP-адрес . На текущий момент существуют 2 версии протокола: IPv4 и IPv6. Пару слов о них:

1) IPv4. Использует 32-битные адреса, которые записываются в формате четырёх десятичных чисел (от 0 до 255), разделённых точками. Например, адрес 192.168.0.4. Каждое число разделенное точками называют октетом. Это самая популярная версия на сегодняшний день.

2) IPv6. Использует 128-битные адреса, которые записываются в формате восьми четырехзначных шестнадцатеричных чисел (от 0 до F). Например, адрес 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d. Каждое число разделенное точками называют хекстетом. На заре всеобщей компьютеризации появилась проблема. Стали заканчиваться IP-адреса и нужен был новый протокол, который смог бы обеспечить больше адресов. Так и появился в 1996 году протокол IPv6. Но благодаря технологии NAT, которая будет рассмотрена позже, была частична решена проблема нехватки адресов, и, в связи с этим, внедрение IPv6 затянулось по сегодняшний день.

Думаю понятно, что обе версии предназначены для одних и тех же целей. В этой статье будет разобран протокол IPv4. Про IPv6 будет написана отдельная статья.

Итак, протокол IP работает с блоком информации, который принято называть IP-пакет. Рассмотрим его структуру.

1) Версия. Протокол IPv4 или IPv6.

2) IHL (от англ. Internet Header Length - размер заголовка). Так как многие из показанных на картинке полей не фиксированы, то это поле считает размер заголовка.

3) Тип обслуживания. Обслуживает размер очередей QoS (Quality of Service - качество обслуживания). Делает он это при помощи байта, который указывает на определенный набор критериев (требование ко времени задержки, пропускной способности, надежности и т.д.)

4) Длина пакета. Размер пакета. Если IHL отвечает только за размер полей в заголовке (заголовком являются все поля на картинке, кроме поля данных), то длина пакета отвечает за весь пакет в целом, включая пользовательские данные.

5) Время жизни (TTL- Time To Live). Поле, используемое для предотвращения циклического пути пакета. При прохождении через маршрутизатор, значение уменьшается на единицу, и когда достигает нуля, пакет отбрасывается.

6) Протокол. Для какого вышестоящего протокола предназначается данный пакет (TCP, UDP).

7) Контрольная сумма заголовка. Здесь считается целостность полей заголовка. Не данных! Данные проверяются соответствующим полем на канальном уровне.

8) Опции. Это поле используется для расширения стандартного заголовка IP. Используется в привычных сетях редко. Сюда записываются данные для какого-нибудь специфического оборудования, которое читает это поле. Например, система управления дверными замками (где идет общение с контроллером), технология умного дома, интернет-вещи и так далее. Привычные сетевые устройства, как роутеры и коммутаторы, будут игнорировать это поле.

9) Смещение. Указывает, какому месту принадлежит фрагмент в оригинальном IP. Это значение всегда кратно восьми байтам.

10) Данные. Здесь как раз содержатся данные, полученные с вышестоящих уровней. Чуть выше я показал, что в Ethernet-кадре тоже есть поле данных. И в его поле данных будет включен данный IP-пакет. Важно помнить, что максимальный размер Ethernet-кадра равен 1500 байт, а вот размер IP пакета может быть 20 Кбайт. Соответственно весь пакет не вместится в поле данных Ethernet-кадра. Поэтому пакет делят и отправляют частями. И вот для этого используются 3 поля ниже.

11) Идентификатор. Это 4-х байтовое число, которое показывает, что все части разделенного пакета одно единое целое.

12) Флаги. Указывает, что это не единый, а фрагментированный пакет.

13) Смещение фрагмента. Сдвиг относительно первого фрагмента. То есть это нумерация, которая поможет собрать IP-пакет воедино.

14) IP-адрес отправителя и IP-адрес получателя. Соответственно эти 2 поля указывают от кого и для кого пакет.

Вот так выглядит IP-пакет. Конечно, для новичков значения многих полей покажутся не совсем понятными, но в дальнейшем это уложится в голове. Например: поле «Время жизни (TTL)». Его работа станет ясна, когда поймете, как работает маршрутизация. Могу дать совет, который я сам применяю. Если видите непонятный термин, выпишите его отдельно и, при наличии свободного времени, попробуйте разобрать. Если никак не лезет в голову, то отложите и вернитесь к его изучению чуть позже. Главное не забрасывать и в конечном итоге все таки добить.

Остался последний уровень из стека TCP/IP. Это транспортный уровень . Пару слов о нем. Он предназначен для доставки данных определенному приложению, которое он определяет по номеру порта. В зависимости от протокола, он выполняет разные задачи. Например, фрагментация файлов, контроль доставки, мультиплексирование потоками данных и управление ими. 2 самых известных протокола транспортного уровня - это UDP и TCP. Поговорим о каждом из них подробнее, и начну с UDP, в силу его простоты. Ну и по традиции показываю, из чего он состоит.

1) Порт источника. Порт, используемый клиентом или сервером для идентификации службы. На этот порт, при необходимости, будет посылаться ответ.

2) Порт назначения. Здесь указывается порт, который будет являться адресатом. Например, если клиент запрашивает страницу сайта, то порт назначения, по умолчанию, будет 80-ый (протокол HTTP).

3) Длина UDP. Длина заголовка UDP. Размер варьируется от 8 до 65535 байт.

4) Контрольная сумма UDP. Проверка целостности. Если нарушена, то просто отбрасывает без запроса о повторной отправки.

5) Данные. Здесь упакованы данные с верхнего уровня. Например, когда веб-сервер отвечает на запрос клиента и отправляет веб-страницу, то она будет лежать в этом поле.

Как видите, у него не так много полей. Его задачи - это нумерация портов и проверять побился кадр или нет. Протокол простой и не требовательный к ресурсам. Однако он не может обеспечивать контроль доставки и повторно запрашивать побитые куски информации. Из известных сервисов, которые работают с этим протоколом - это DHCP, TFTP. Они рассматривались в предыдущей статье, когда разбирались протоколы верхнего уровня.

Переходим к более сложному протоколу. Встречаем протокол TCP. Смотрим, из чего состоит, и пробегаем по каждому полю.

1) Порт источника и порт назначения. Выполняют те же роли, что и в UDP, а именно нумерация портов.

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

3) Номер подтверждения. Это поле используется, когда ожидается доставка или подтверждается доставка. Для этого используется параметр ACK.

4) Длина заголовка. Используется для того, чтобы понять какой размер у TCP-заголовка (это все поля представленные на картинке выше, кроме поля данных), а какой у данных.

5) Зарезервированный флаг. Значение этого поля должно устанавливаться в ноль. Оно зарезервировано под специальные нужды. Например, чтобы сообщить о перегрузках в сети.

6) Флаги. В это поле устанавливаются специальные биты для установления или разрыва сессии.

7) Размер окна. Поле, указывающее, на сколько сегментов требовать подтверждения. Наверное, каждый из вас наблюдал такую картину. Вы скачиваете какой-то файл и видите скорость и время скачивания. И тут сначала он показывает, что осталось 30 минут, а через 2-3 секунды уже 20 минут. Еще спустя секунд 5, показывает 10 минут и так далее. Это и есть размер окна. Сначала размер окна устанавливается таким образом, чтобы получать больше подтверждений о каждом отправленном сегменте. Далее все идет хорошо и сеть не сбоит. Размер окна меняется и передается больше сегментов и, соответственно, требуя меньше отчетов о доставке. Таким образом, скачивание выполняется быстрее. Как только сеть даст краткий сбой, и какой то сегмент придет побитым, то размер опять изменится и потребуется больше отчетов о доставке. В этом суть данного поля.

8) Контрольная сумма TCP. Проверка целостности TCP-сегмента.

9) Указатель важности. Это смещение последнего октета важных данных относительно SEQ для пакетов с установленным флагом URG. В жизни применяется, когда необходимо осуществить контроль потока или состояния протокола верхнего уровня со стороны передающего агента (например, если принимающий агент может косвенно сигнализировать передающему, что не справляется с потоком данных).

10) Опции. Используется для каких нибудь расширенных или дополнительных параметров. Например, для параметра timestamp, который является своеобразной меткой, показывающей время произошедшего события.

11) Данные. Практически тоже самое, что и в протоколе UDP. Здесь инкапсулированы данные с вышестоящего уровня.

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

Я открываю CPT и соберу схему, аналогичную одному из рисунков выше.

Здесь наблюдаем первую сеть, состоящую из 4-х компьютеров и коммутатора, который объединяет эти компьютеры. И 2-ую сеть, состоящую из двух компьютеров и коммутатора. Объединяет эти 2 сети маршрутизатор. Перейдем к настройке устройств и после смоделируем ту ситуацию, которую мы рассматривали в самом начале на картинке.

Открываю компьютер PC1 и пропишу сетевые настройки.

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

1) IP-адрес - 192.168.1.1

Эту маску мы рассматривали выше. Напомню, что адрес сети у других хостов в той же локальной сети, должен быть 192.168.1, а адрес хоста может быть от 1 до 254.

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

Чтобы не было много однотипных картинок, я не буду приводить скриншоты остальных 3-х компьютеров, а только приведу их настройки.

PC2:
1) IP-адрес - 192.168.1.2
.
3) Основной шлюз - 192.168.1.254.

PC3:
1) IP-адрес - 192.168.1.3
2) Маска подсети - 255.255.255.0.
3) Основной шлюз - 192.168.1.254.

PC4:
1) IP-адрес - 192.168.1.4
2) Маска подсети - 255.255.255.0.
3) Основной шлюз - 192.168.1.254.

На данной настройке пока остановимся и посмотрим, как работает наша локальная сеть. Перевожу CPT в режим симуляции. Допустим, я сижу за компьютером PC1, и требуется проверить доступность PC4 командой ping. Открываю командную строку на PC1.

Как только нажимаю ENTER, на схеме появляются 2 конверта.

Один из них ICMP, с которым работает сама команда ping. Сразу открываю его и смотрю.

Вижу данные IP и ICMP. Тут нет ничего интересного, за исключением нескольких полей. А именно, цифра 4 в верхнем левом углу данных IP, которая говорит о том, что используется протокол IPv4. И 2 поля с IP-адресом источника и назначения (SRC:192.168.1.1 и DST:192.168.1.4).

Но тут ping сталкивается с проблемой. Он не знает MAC-адрес получателя. То есть, адрес канального уровня. Для этого он использует протокол ARP, который сможет опросить участников сети и узнать MAC-адрес. Мы про него вскользь говорили в предыдущей статье. Давайте поговорим о нем подробнее. Не буду изменять традиции. Картинку в студию!

1) Тип протокола канального уровня (Hardware type). Думаю понятно из названия, что тут указывается тип канального уровня. Мы пока рассматривали только Ethernet. Его обозначение в этом поле - 0x0001.

2) Тип протокола сетевого уровня (Protocol type). Тут, аналогично, указывается тип сетевого уровня. Код IPv4 - 0x0800.

3) Длина физического адреса в байтах (Hardware length). Если это MAC-адрес, то размер будет 6 байт (или 48 бит).

4) Длина логического адреса в байтах (Protocol length). Если это IPv4-адрес, то размер будет 4 байта (или 32 бита).

5) Код операции (Operation). Код операции отправителя. Если это запрос, то код 0001. В случае ответа - 0002.

6) Физический адрес отправителя (Sender hardware address). MAC-адрес отправителя.

7) Логический адрес отправителя (Sender protocol address). IP-адрес отправителя.

8) Физический адрес получателя (Target hardware address). MAC-адрес получателя. Если это запрос, то, как правило, адрес неизвестен и это поле остается пустым.

9) Логический адрес получателя (Target protocol address). IP-адрес получателя.

Теперь, когда мы знаем, из чего он состоит, можно посмотреть на его работу в CPT. Кликаю по второму конверту и наблюдаю следующую картину.

И вот протокол ARP во всей красе. На 2-ом уровне работает протокол Ethernet. Остановимся и посмотрим на его поля.

1) Преамбула - здесь битовая последовательность, которая говорит о начале кадра.

2) Далее идет MAC-адрес источника и получателя. В адресе источника записан MAC-адрес компьютера, который является инициатором, а в адресе получателя записан широковещательный адрес FF-FF-FF-FF-FF-FF (то есть для всех узлов в канальной среде).

3) Тип - здесь указан вышестоящий протокол. Код 0x806 означает, что выше стоит ARP. Я, если честно, не могу точно сказать, на каком уровне он работает. В разных источниках указано по-разному. Кто то говорит, что на 2-ом уровне OSI, а кто-то говорит, что на 3-ем. Я считаю, что он между ними работает. Так как тут есть адреса, присущие каждому из уровней.

Про данные и чек-сумму много говорить не буду. Данные здесь никак не указаны, а чек-сумма нулевая.

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

1) Hardware Type - код канального уровня. CPT убрала лишние нули и вставила 0x1 (тоже, что и 0x0001). Это Ethernet.
2) Protocol Type - код сетевого уровня. 0x800 - это IPv4.
3) HLEN - длина физического адреса. 0x6 означает 6 байт. Все верно (MAC-адрес занимает 6 байт).
4) PLEN - длина сетевого адреса. 0x4 означает 4 байта (IP-адрес занимает 4 байта).
5) OPCODE - код операции. 0x1 означает, что это запрос.
6) Source Mac - здесь MAC-адрес отправителя. Можно сравнить его с адресом в поле протокола Ethernet и убедиться в правильности.
7) Source IP - IP-адрес отправителя.
8) Target MAC - так как это запрос и канальный адрес не известен, то он пустой. CPT показала его нулями, что равносильно.
9) Target IP - IP-адрес получателя. Как раз тот адрес, который пингуем.

Протокол ARP опрашивает все хосты в локальной сети и только один отвечает на этот запрос. Это PC4. Посмотрим, чем он ответит.

Вот он выплевывает что-то на коммутатор. Открываю его и вижу некоторые изменения, а именно:

1) В поле источника протокола Ethernet теперь записан MAC-адрес PC4, а в поле назначения MAC-адрес инициатора, то есть PC1.
2) В поле OPCODE теперь значение 0x2, то есть ответ.
3) Поменялись поля логических и физических адресов в протоколе ARP. Source MAC и Destination MAC аналогичны тем, что в протоколе Ethernet. В поле Source IP - адрес 192.168.1.4 (PC4), а в поле Destination IP - адрес 192.168.1.1 (PC1).

Как только эта информация достигнет PC1, он сразу формирует ICMP-сообщение, то есть ping.

Открываю его и смотрю. Это блок данных, состоящий из работы 3-х протоколов: Ethernet, IP и Ping.

1) В Ethernet протоколе ничего нового, а именно MAC-адрес отправителя - PC1, MAC-адрес получателя - PC4, а в поле Type - 0x800 (протокол IPv4)
2) В IP протоколе, в поле Версия - 4, что означает протокол IPv4. IP-адрес отправителя - PC1, а IP-адрес получателя - PC4.
3) В ICMP протоколе, в поле Type - код 0x8 (эхо-запрос).

Посылает он эхо-запрос, а я смотрю, чем ответит PC4.

Перекосил у меня CPT, и пришлось перезапустить его. Только теперь ICMP конверт не светло-зеленового цвета, а смесь зеленого и синего. Но это без разницы. Это одни и те же данные.
Ну что же, смотрю, чем ответил PC4. Поля источника и назначения в протоколах Ethernet и IP поменялись местами. А в поле Type протокола ICMP изменилось значения с 0x8 на 0x0 (означает эхо-ответ).

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

И действительно. Появилась запись о доступности PC4, размер данных (32 байта), задержка по времени (8 мс) и TTL или время жизни (128). TTL показывает, сколько маршрутизаторов преодолел пакет. У меня пакет гулял в пределах локальной сети, поэтому данное поле не изменилось.

По умолчанию пинг отправляет 4 запроса. Следовательно, PC1 сформирует еще 3 аналогичных ICMP. Показывать путь каждого пакета я не буду, а приведу финальный вывод консоли на PC1.

И как видите, действительно 4 ответа. Заметьте, что первый пришел с задержкой в 8 мс, а 3 последних в 4 мс. Это связано с работой протокола ARP, так как сначала PC1 не знал MAC-адрес PC4 и ждал, когда ему сообщат. Хотя в CPT встречается ситуация, что в режиме реального времени, первый пакет вообще теряется. Особенно часто это проявляется, когда проверяется доступность хоста, находящегося в другой канальной среде.

Увидели мы, как работает передача данных в одной канальной среде. Теперь посмотрим, что произойдет, если хосты окажутся в разных канальных средах или подсетях. Напомню, что сеть настроена не до конца. А именно, нужно настроить маршрутизатор и вторую подсеть. Чем сейчас и займемся.

Открываю я компьютер с именем PC5 и пропишу сетевые настройки.

Заметьте, что сетевая адресация в первой канальной среде, была 192.168.1.X, а во 2-ой 192.168.2.X. При маске 255.255.255.0, это означает, что первые 3 октета фиксированы, а 4-ый октет в пределах от 1 до 254. И так как у нас 3-ие октеты различаются, то это разные канальные среды.

Привожу настройки PC6:

1) IP-адрес - 192.168.2.2
2) Маска подсети - 255.255.255.0
3) Основной шлюз - 192.168.2.254

Хосты во 2-ой канальной среде настроены и прекрасно работают. Для того, чтобы они смогли общаться с хостами из 1-ой канальной, нужно настроить маршрутизатор, который соединяет эти среды. Маршрутизатор настраивается через CLI (то есть в консольном виде) и проще будет приводить сюда не скриншоты, а команды.

1) Router>enable - переход в привилегированный режим
2) Router#configure terminal - переход в режим глобальной конфигурации
3) Router(config)#interface fastEthernet 0/0 - переходим к настройке порта 0/0, который смотрит на первую канальную среду
4) Router(config-if)#ip address 192.168.1.254 255.255.255.0 - вешаем на этот порт IP-адрес. Так как этот порт будет являться основным шлюзом для 1-ой канальной среды, то указываем ему тот IP, который прописали хостам
5) Router(config-if)#no shutdown - включаем этот интерфейс. По умолчанию все порты на цисковских маршрутизаторах выключены
6) Router(config-if)#exit - выходим из режима настройки fastEthernet 0/0
7) Router(config)#interface fastEthernet 0/1 - переходим к настройке порта 0/1, который смотрит на вторую канальную среду
8) Router(config-if)#ip address 192.168.2.254 255.255.255.0 - вешаем сюда адрес, который будет являться основным шлюзом для хостов во 2-ой канальной среде
9) Router(config-if)#no shutdown - аналогично включаем его
10) Router(config-if)#end - пишем команду, которая отбросит в привилегированный режим
11) Router#copy running-config startup-config - сохраняем настройки в памяти маршрутизатора

На этом этапе настройка маршрутизатора окончена. Немного забегу вперед и покажу полезную команду «show ip route». Она показывает все известные маршрутизатору сети и маршрут до них.

Исходя из этой таблицы, можно удостовериться, что он знает и про 1-ую канальную среду, и про 2-ую. Отлично. Осталось дело за малым - это проверить доступность PC5 из PC1. Пробую. Переключаю CPT в режим симуляции. Открываю командную строку и пингую 192.168.2.1.

Как только нажимаю ENTER, сразу появляется 2 конверта: ICMP и ARP. Остановимся и посмотрим на них подробнее. Сейчас может показаться, что передача между разными канальными средами ничем не отличается от передачи в одной канальной среде, но это не так. И сейчас вы это увидите.

Сначала посмотрим на ICMP.

Здесь пока в принципе ничего интересного. В поле источника - IP-адрес PC1, а в поле назначения - IP-адрес PC5.

Что же будет происходить дальше. PC1 видит, что проверяется доступность хоста, находящегося в другой канальной среде (путем наложения маски на свой IP-адрес и IP-адрес получателя). И кроме IP-адреса он не знает о получателе ничего. Соответственно в таком виде отправлять пакет ICMP нельзя. Зато он знает, что у него есть основной шлюз, который, скорее всего, знает что-то про канальную среду, в которой находится PC5. Но возникает еще одна сложность. Он знает IP-адрес шлюза (который я ему прописал в сетевых настройках), но не знает его MAC-адреса. Тут ему приходит на помощь протокол ARP, который опросит всех участников канальной среды и найдет его MAC-адрес. Посмотрим, как заполнены поля.

На канальном уровне (протокол Ethernet): Поле источника - MAC-адрес PC1, а в поле назначения - широковещательный адрес (то есть всем участникам).

И чуть повыше (протокол ARP):

1) SOURCE MAC - тот же PC1, а DESTINATION MAC пустой (его должен заполнить тот, для кого этот запрос предназначен).
2) SOURCE IP - адрес PC1, а вот DESTINATION IP - адрес основного шлюза.

3 компьютера отбросили пакет, и только маршрутизатор понял, что это для него. Смотрим, чем ответит.

Ethernet:

1) Source MAC - сюда он вставляет свой MAC-адрес (а именно MAC-адрес fastEthernet0/0).
2) Destination MAC - сюда записывает MAC-адрес PC1 (то есть того, кто запросил).
ARP:
1) Source MAC и Destination MAC аналогично записям в протоколе Ethernet.
2) Source IP - свой IP-адрес.
3) Target IP - IP-адрес PC1.

Как только ARP доходит от маршрутизатора к PC1, то сразу PC1 отсылает ICMP сообщение на маршрутизатор (или основной шлюз). И вот здесь прошу обратить особое внимание. А именно, на поля источника и назначения (и в протоколе Ethernet, и в протоколе IP).

1) SRC MAC: здесь указан MAC-адрес PC1.
2) DEST MAC: MAC-адрес маршрутизатора.
3) SRC IP: IP-адрес PC1.
4) DST IP: IP-адрес PC5.

Что это значит. Адреса на сетевом уровне (то есть IP-адреса) не меняются, чтобы знать от кого и кому предназначается информация. А адреса на канальном уровне (MAC-адреса) могут спокойно меняться, переходя из одной канальной среды в другую. Это очень важно понять и запомнить!

Смотрим, что происходит. Пакет доходит до маршрутизатора и сразу перечеркивается. А все из-за того, что он не знает MAC-адрес PC5. Теперь он формирует ARP-запрос и пытается его узнать. Привожу скриншот этого запроса.

Как только этот ответ дойдет до маршрутизатора, он будет знать канальный адрес PC5. Но вот что произошло. Пока тянулась канитель с ARP у маршрутизатора и PC5, у PC1 истекает время ожидания ответа отправленного ICMP. Показываю картинку.

После истечения времени ожидания, он формирует второе ICMP, ответ которого уже дойдет без проблем, так как MAC-адреса известны. Следом он сформирует 3-ье и 4-ое ICMP. Привожу конечный итог.

И если внимательно присмотреться, то можно заметить, что TTL снизился на единицу и теперь равен 127. Это произошло из-за того, что пакет преодолел один транзитный участок (маршрутизатор).

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

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

Начну, как всегда, с простого. И это протокол UDP. Как я уже говорил выше, он используется для того, чтобы передать данные определенному протоколу вышестоящего уровня. Делает он это при помощи портов. Один из протоколов, работающих с UDP - это TFTP(Trivial File Transfer Protocol). Протокол этот мы рассматривали в предыдущей статье. Поэтому трудностей возникнуть не должно. Для демонстрации потребуется добавить в сеть сервер с включенной службой TFTP.

Настройки сервера следующие:

1) IP-адрес - 192.168.1.5
2) Маска подсети - 255.255.255.0
3) Основной шлюз - 192.168.1.254

Служба TFTP включена по умолчанию, но лучше проверить. Далее переключаю CPT в режим симуляции и попробую сохранить конфигурацию маршрутизатора на TFTP-сервер:

1) Router>enable - переход в привилегированный режим.
2) Router#copy startup-config tftp: - пишу команду copy (то есть скопировать), далее startup-config (что именно скопировать) и tftp: (куда скопировать).
3) Address or name of remote host ? 192.168.1.5 - выходит сообщение с запросом адреса или имени сервера, где я пишу его адрес.
4) Destination filename ? - следом он спрашивает, под каким именем его сохранить на сервере и предлагает стандартное имя. Меня это устраивает, и я жму ENTER.

Сразу маршрутизатор формирует 2 конверта. Один из них - это перечеркнутый TFTP, а второй ARP. Думаю, догадались, что перечеркнут он из-за того, что не знает MAC-адрес сервера.

Пропущу я момент работы ARP, так как мы вдоволь на него насмотрелись.

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

Ethernet:
1) Source MAC - адрес маршрутизатора.
2) Destination MAC - адрес сервера.
3) Type - 0x800 (означает, что выше работает протокол IP).

IP:
1) Protocol - 0x11 (означает, что выше работает протокол UDP).
2) Source IP - адрес маршрутизатора.
3) Destination IP - адрес сервера.

UDP:
1) Source Port - динамически созданный порт (1025).
2) Destination Port - порт, который слушает TFTP-сервер (зарезервированный 69 порт).

TFTP:
Здесь находятся сами данные.

Так и работает протокол UDP. Он не устанавливает сессии, не требует подтверждения доставки, а если что-то потеряется, он не запрашивает повторно. Его работа - это указать номер порта и отправить. Что там будет происходить дальше, его не интересует. Но возникают случаи, когда это не устраивает и все эти параметры критически важны. Тогда на помощь приходит протокол TCP. Рассмотрим его на примере использования веб-сервера и веб-клиента. Веб-сервером у нас будет тот же TFTP-сервер. Включаем службу HTTP и запросим страницу с компьютера PC1. Не забываем переключить CPT в режим симуляции!

Набираю адрес веб-сервера и нажимаю ENTER.

Перед тем как продолжить, я расскажу про установление TCP-сессии. Постараюсь изложить этот процесс максимально просто. Этот процесс называют «трехстороннее рукопожатие» или «handshake». В чем суть. Клиент отправляет TCP-сегмент с флагом «SYN». Получив сегмент, сервер принимает решение. Если он согласен установить соединение, то он отправляет ответный сегмент с флагом «SYN+ACK». Если не согласен, то отправляет сегмент с флагом «RST». Далее клиент смотрим на ответный сегмент. Если там стоит флаг «SYN+ACK», то он в ответ отправляет сегмент с флагом «ACK» и устанавливается соединение. Если же там стоит флаг «RST», то он прекращает попытки соединения. После того, как потребуется разорвать установившееся соединение, клиент формирует и отправляет TCP-сегмент с флагом «FIN+ACK». Сервер на этот сегмент отвечает аналогичным флагом «FIN+ACK». И наконец, клиент отправляет последний TCP-сегмент с флагом «ACK». Сейчас вы увидите, как это работает на практике.

Переключаю внимание на сеть и вижу, как PC1 формирует TCP-сегмент.

Поля протоколов Ethernet и IP я рассматривать не буду, так как тут ничего нового, за исключением поля Protocol в протоколе IP. Там стоит значение - 0x6. Это говорит о том, что выше используется протокол TCP.

А вот в TCP уже поинтереснее.

1) Source Port - 1025 (это динамически сгенерированный порт веб-клиента).
2) Destination Port - 80 (это зарезервированный порт протокола HTTP).
3) Flag - SYN (запрос на установление сессии)

Смотрим, чем ответит веб-сервер.

Меняет он номера портов местами и отправляет сегмент с флагом «SYN+ACK».

Как только клиент получает этот сегмент, он сразу формирует 2 сообщения. Один из них TCP-сегмент, представленный ниже, который отправляется с флагом «ACK».

А второй - HTTP, где указана версия протокола, какая страница и адрес сервера.

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

Как только клиент получает желаемую страницу, ему больше нет смысла поддерживать соединение и он инициирует разрыв. Отправляет сегмент с флагом «FIN+ACK». Смотрим дальше.

Сервер согласен разорвать соединение и в ответ отправляет сегмент с аналогичным флагом «FIN+ACK».

И наконец, клиент формирует последний TCP-сегмент с флагом «ACK» и закрывает соединение.

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

Ну что же, статья подходит к концу. Хочу выразить благодарность пользователю под ником remzalp за предоставленную картинку и остальным пользователям, которые оставляют полезные комментарии к статьям. Очень приятно видеть, как люди интересуются, задают вопросы, ведут объективные и конструктивные споры. Хочется, чтобы русскоязычное IT-сообщество все больше развивалось и материалов для изучения в свободном доступе становилось все больше. Спасибо за прочтение и до встречи на следующей.

Добавить метки