Русские Блоги
Расчет и принцип кода CRC (создание контрольной последовательности кадра FCS)
Мы знаем, что в конце кадра Ethernet есть нечто, называемое FCS.
Полное имя: Последовательность проверки кадров, китайское название: Последовательность проверки кадров
Эта вещь используется для проверки, не повреждены ли наши данные во время передачи (не обязательно из-за атаки или какого-либо физического вмешательства), чтобы лучше организовать повторную передачу.
Среди них наиболее часто используемый код с высокой способностью обнаружения ошибок — это CRC, код проверки циклическим избыточным кодом.
Операционные процедуры
Немного базовых знаний
Модульное деление на два или деление по числовому полю <1, 0>.
Подобно обычному делению, его также можно вычислить по вертикали, но единственная разница — шаг вычитания.
Наше деление здесь при вычитании следует следующим правилам:
- 1-1=0
- 1-0=1
- 0-1=1
- 0-0=0
- Без переноски, без займа
Например. 
Я считаю, что это должно быть ясно. (Нарисовано от руки, непросто)
генерировать
Во-первых, нам нужен делитель, который может быть основан на отраслевом стандарте, например:
CRC-16, используемый в процедуре IBM SDLC (Synchronous Data Link Control), — 11000000000000101, который используется в процедурах ISO HDLC (Advanced Data Link Control), ITU SDLC, X.25, V.34, V.41, V CCITT -16 используется в .42 и т. Д. Это: 11000000000100001.
Конечно, это эксперимент, мы тоже можем сгенерировать случайным образом, но есть требование,Самый высокий и самый низкий должен быть 1, Этот момент требует внимания.
Затем мы сдвигаем данные влево на (k-1) бит и добавляем нули — это наш дивиденд.
Затем используйте делимое и делитель, чтобы выполнить деление по модулю два, чтобы получить остаток.
Этот остаток (k-1 цифр, если недостаточно, дополненный нулями слева) представляет собой FCS, добавляемый в конец данных.
Затем мы можем добавить его в конец данных.
проверять
Так как же это проверить?
напрямую берем полученную строку (включая FCS) и снова делим делитель по модулю 2. Если остаток равен нулю, данные не повреждены. Если он не равен 0, это означает, что данные были уничтожены и необходимо организовать повторную передачу.
Я считаю, что после прочтения вышеизложенного кода будет легко реализовать код. Написанный мной код приведен ниже:
Если его можно улучшить, я не буду его дальше улучшать.
Некоторые математические принципы
Я уже говорил об истоках математики, но это просто для понимания процесса, но это не позволяет нам понять, почему это так.
Итак, вот расширенное содержание, читайте его в соответствии с вашими интересами!
Генераторный полином
Не знаю, как это сказать, приведу пример.
, например 
Соответствующие делители:
- 11000000000000101
- 10001000000100001
- 100000100110000010001110110110111
Я считаю, вам следует понять.
Почему остаток равен 0
Мы только что ввели модульное деление на два.
Здесь мы говорим о модульном сложении двух.
- 1+1=0
- 1+0=1
- 0+0=0
- Без переноски
Почему это так определяется?
по модулю два.
Итак, пока вы получаете результат по модулю 2, вы будете знать, почему это происходит.
Мы устанавливаем исходные данные равными t после сдвига влево, делителем — a, частным — s, а остатком — r.
Итак, есть: t = as+r
, и мы передаем t + r
т.е. t + r = as+r+r
В чем проблема?
Давайте посмотрим на r + r
Обратите внимание, что это сложение по модулю два, без переноса и 1 + 1 = 0 + 0 = 0,
И r и r одинаковы, поэтому после сложения по модулю два получится 0!
Итак, формула принимает следующий вид: t + r = a * s
В этом случае (t + r) по модулю два, деленное на a, естественный остаток равен 0.
Вот почему мы можем это сделать.
Проверка прошла успешно?
Не обязательно!
Могут быть некоторые ошибки, но результат верный.
Итак, какова вероятность?
Предполагается, что FCS составляет 32 бита (4 байта)
Размер данных, которые мы берем, составляет 8000 бит (1000 байтов, где размер данных является средним значением, данные в кадре Ethernet обычно составляют 46
1500 байтов) (конечно, фактически From следующие результаты, мы можем знать, что здесь нет никакого воздействия)
8000-битные данные, максимум — 8000 единиц, а минимум — 1 (7999 нулей).
выполняет двоичное деление, максимальное частное составляет 7969 бит, всего 2 7969 Возможное частное.
Общий возможный результат повреждения — 2 8000 .
Таким образом, вероятность ошибочной оценки P = (2 7969 -1)/2 8000
примерно 1/2 31 , Что составляет 1/2 147 483 648
Какова вероятность?
— это почти вероятность получения секстиплета.
Подумайте, сколько шестерок вокруг вас? О скольких секстах вы слышали?
Следовательно, его способность обнаруживать ошибки очень высока. Дело в том, что алгоритм также очень прост и удобен для практических приложений.
Заключительные замечания
Это сегодняшнее исследование CRC. Если вам это нравится, нажмите "Нравится"!
Любые вопросы можно обсудить со мной!
Базовая структура кадра Ethernet
Кадр, передаваемый каждым узлом, содержит данные маршрутизации, управления и коррекции ошибок. Для сетей Ethernetпараметры кадров определены стандартом 802.3IEEE.
Базовая длина кадра может изменяться от 72 до 1526 байтов при типовой структуре, показанной на Рис.2.
Рис.2. Базовая структура кадра Ethernet
• Преамбула — Каждый кадр начинается с преамбулы длиной семь байтов. Преамбула используется в качестве синхронизирующей последовательности для интерфейсных цепей и способствуетдекодированию битов. Преамбула используется для того, чтобы дать время и возможность схемам приемопередатчиков (transceiver) прийти в устойчивый синхронизм с принимаемыми тактовыми сигналами.
• SFD (Start—Frame Delimiter) — Разделитель начала кадра, состоящий из одного байта. ПолеSFDуказывает на начало полезной информации.Начальный ограничителькадра состоит из одного байта с набором битов 10101011. Появление этой комбинации является указанием на предстоящий прием кадра.
• Конечный МАС-адрес — Поле из шести байтов, содержащее адрес конечного узла.Адрес получателя — может быть длиной 2 или 6 байтов (MAC-адрес получателя). Первый бит адреса получателя — это признак того, является адрес индивидуальным или групповым: если 0, то адрес указывает на определенную станцию, если 1, то это групповой адрес нескольких (возможно всех) станций сети. При широковещательной адресации все биты поля адреса устанавливаются в 1. Общепринятым является использование 6-байтовых адресов.
• Исходный МАС-адрес — Поле из шести байтов, содержащее адрес исходного узла.Адрес отправителя— 2-х или 6-ти байтовое поле, содержащее адрес станции отправителя. Первый бит — всегда имеет значение 0.
Примечание: В письменном виде МАС-адреса записываются в виде шести пар шестнадцатеричных цифр, разделенных тире, например, 08-10-39-03-2F-C3.
• Длина/Тип — Поле из двух байтов, указывающее на число байтов, содержащихся в поле данныхуправления логическими связями (LLC — Logical Link Control). В большинстве Ethernet-протоколах это поле содержит постоянную величину, указывающую на тип протокола (в данном случае эта полеимеет обозначение EtherType). Двухбайтовоеполе длиныопределяет длину поля данных в кадре.
• Данные МАС-клиента — Это поле может содержать от 0 до 1500 байтов данных, предоставленныхпользователем. Поле данныхможет содержать от 0 до 1500 байт. Но если длина поля меньше 46 байт, то используется следующее поле — поле заполнения, чтобы дополнить кадр до минимально допустимой длины.
• Заполняющие байты — Необязательное поле для заполнения фиктивными данными, используемое для увеличения длины коротких кадров по меньшей мере до 64 байтов.Поле заполнениясостоит из такого количества байтов заполнителей, которое обеспечивает определенную минимальную длину поля данных (46 байт). Это обеспечивает корректную работу механизма обнаружения коллизий. Если длина поля данных достаточна, то поле заполнения в кадре не появляется.
• Контрольная последовательность кадра (FCS) — Поле, содержащее четыре контрольных байта, сгенерированных кодом циклического контроля избыточности (CRC). ПолеFCSиспользуется для обнаружения ошибок в данных, содержащихся в кадре.Поле контрольной суммы — 4 байта, содержащие значение, которое вычисляется по определенному алгоритму (полиному CRC-32). После получения кадра рабочая станция выполняет собственное вычисление контрольной суммы для этого кадра, сравнивает полученное значение со значением поля контрольной суммы и, таким образом, определяет, не искажен ли полученный кадр.
Тренинг Cisco 200-125 CCNA v3.0. День 6. Заполняем пробелы (DHCP, TCP, «рукопожатие», распространенные номера портов)
Прежде чем мы начнем сегодняшний видеоурок, хочу поблагодарить всех, кто способствовал популярности моего курса на YouTube. Когда я начал его около 8 месяцев назад, то не ожидал такого успеха – на сегодня мои уроки просмотрели 312724 человека, у меня 11208 подписчиков. Мне и не снилось, что это скромное начинание достигнет таких высот. Но не будем терять время и сразу перейдем к сегодняшнему занятию. Сегодня мы восполним пробелы, которые имели место в последних 7 видеоуроках. Хотя сегодня только 6 день, день 3 был разбит на 3 видеоурока, так что фактически сегодня вы посмотрите восьмой видеоурок.
Сегодня мы будем заниматься 3 важными темами: DHCP, передача TCP и наиболее употребительные номера портов. Мы уже говорили об IP-адресах, и одним из важнейших факторов конфигурации IP-адреса является DHCP.
DHCP расшифровывается как «протокол динамической настройки узла», это протокол, который помогает динамически настраивать IP-адреса для хостов. Итак, все мы видели это окно. При нажатии на параметр “получить IP-адрес автоматически” компьютер ищет DHCP-сервер, настроенный в одной подсети и отправляющий различные пакеты и запросы для IP-адреса. Протокол DHCP имеет 6 сообщений, из которых 4 имеют решающее значение для назначения IP-адреса.
Первое сообщение является сообщением обнаружения DHCP DISCOVERY. Сообщение обнаружения DHCP похоже на приветствие. Когда новое устройство заходит в сеть, оно спрашивает, присутствует ли в сети DHCP-сервер.
То, что вы видите на слайде, похоже на широковещательный запрос, кода устройство обращается ко всем устройствам в сети в поисках DHCP-сервера. Как я уже сказал, это широковещательный запрос, поэтому его слышат все устройства сети.
Если в сети есть DHCP-сервер, он отправляет пакет — предложение DHCP OFFER. Предложение означает, что DHCP-сервер в ответ на запрос обнаружения отправляет клиенту конфигурацию, предлагая клиенту принять определенный IP-адрес.
DHCP-сервер резервирует IP-адрес, в данном случае 192.168.1.2, не предоставляет, а именно резервирует за устройством данный адрес. Вместе с этим в пакете предложения содержится собственный IP-адрес DHCP-сервера.
Если в этой сети имеется более одного DHCP-сервера, другой DHCP-сервер, получив широковещательный запрос клиента, также предложил бы ему свой IP-адрес, например, 192.168.1.50. Обычно в одной и той же сети не настраиваются два разных DHCP-сервера, но иногда такое все же случается. Таким образом, когда предложение DHCP отправляется клиенту, он получает 2 предложения DHCP и теперь должен решить, какое предложение DHCP он хочет принять.
Давайте предположим, что клиент принимает первое приложение. Это означает, что клиент отсылает запрос DHCP REQUEST, в котором буквально говорится: «я принимаю IP-адрес 192.168.1.2, предлагаемый DHCP-сервером 192.168.1.1».
Получив запрос, DHCP-сервер 192.168.1.1 отвечает: «хорошо, я это признаю», то есть подтверждает запрос и направляет это подтверждение DHCP ACK клиенту. Но мы помним, что другой DHCP- сервер DHCP зарезервировал для клиента IP-адрес 1.50. Получив широковещательный запрос клиента, он узнает об отказе и поместит этот IP-адрес обратно в пул, чтобы он мог назначить его другому клиенту, если получит другой запрос.
Таковы 4 критических сообщения, которыми обменивается DHCP а начале назначения IP-адресов. Далее у DHCP имеются еще 2 информационных сообщения. Информационное сообщение выдается клиентом, если ему требуется больше информации, чем он получил в предложении DHCP OFFER на втором шаге. Если в предложении DHCP сервер предоставил недостаточно информации или если клиенту нужно больше информации, чем та, что содержалась в пакете предложения, он запрашивает дополнительную DHCP- информацию. Есть еще одно сообщение, которое клиент отсылает серверу – это освобождение DHCP RELEASE. В нем сообщается, что клиент хочет освободить имеющийся у него IP-адрес.
Однако чаще всего случается так, что пользователь отключается от сети раньше, чем клиент успевает послать на сервер DHCP RELEASE. Так происходит при выключении компьютера, которое осуществляем мы с вами. При этом сетевой клиент, или компьютер, просто не имеет времени на то, чтобы сообщить серверу об освобождении использовавшегося адреса, поэтому DHCP RELEASE не является обязательным шагом. Обязательными шагами для получения IP-адреса являются: обнаружение DHCP, предложение DHCP, запрос DHCP и подтверждение DHCP.
В одном из следующих уроков я расскажу, как мы настраиваем DHCP- сервер при создании DNCP- пула. Под пулом подразумевается, что вы сообщаете серверу о назначении IP-адресов в диапазоне от 192.168.1.1 до 192.168.1.254. Таким образом, DHCP-сервер создаст пул, поместит в него 254 IP-адреса и сможет назначать клиентам сети адреса только из этого пула. Так это что-то вроде административной настройки, которую может осуществить пользователь.
Теперь рассмотрим передачу TCP. Не знаю, знакомы ли вы с изображенным на картинке «телефоном», но в детстве мы использовали такие консервные банки, соединенные шнурком, чтобы разговаривать друг с другом.
К сожалению, сегодняшнее поколение не может позволить себе такой «роскоши». Я имею в виду, что сегодня дети находятся перед телевизором с годовалого возраста, они играют в PSP, и, возможно, это спорный вопрос, но я думаю, что у нас было лучшее детство, мы действительно выходили на улицу и играли в игры, а сегодняшних детей не оторвешь от дивана.
Моему сыну всего год, и я уже вижу, что он пристрастился к iPad, я имею в виду, что он еще очень маленький, но мне кажется, что сегодняшние дети уже рождаются со знаниями, как обращаться с электронными гаджетами. Итак, я хотел сказать, что в детстве, когда мы играли, мы дырявили консервные банки, и когда связывали их струной и произносили что-то в одну банку, то на другом конце человек мог услышать, что ему говорят, просто приложив банку к уху. Так что это очень похоже на сетевое соединение.
Сегодня даже для передачи TCP должно имеется соединение, которое необходимо установить до того, как начнется реальная передача данных. Как мы обсуждали в предыдущих уроках, TCP — это передача, ориентированная на предварительное установление соединения с сетью, в то время как UDP — это передача без необходимости установки соединения. Можно сказать, что UDP – это когда я бросаю мяч, и от вас зависит, сможете ли вы его поймать. Готовы вы это сделать или нет, это не моя проблема, я просто собираюсь его бросить.
ТСP больше похоже на то, что вы разговариваете с парнем и заранее предупреждаете его о том, что собираетесь бросить мяч, то есть между вами завязывается связь, и только затем вы бросаете мяч, так что с большой вероятностью ваш партнер будет готов его поймать. Таким образом, TCP фактически строит соединение, а затем начинает осуществлять реальную передачу.
Рассмотрим, как он создает такое соединение. Для создания соединения этот протокол использует 3-х этапное рукопожатие. Это не слишком технический термин, но он давно используется для описания TCP-соединения. 3-х этапное рукопожатие инициируется отправляющим устройством, при этом клиент отправляет серверу пакет с SYN-флагом.
Предположим, что девочка на переднем плане, чье лицо мы можем видеть – это устройство А, а девочка на заднем плане, лица которой не видно – устройство В. Девочка А посылает SYN- пакет девочке В, и та говорит: «отлично, кто-то хочет со мной общаться. Значит, мне нужно ответить, что я готова к общению!» Как это сделать? Можно было бы просто отправить обратно еще один SYN-пакет и затем подтверждение ACK, указывающее на получение исходного SYN- пакета. Но вместо того, чтобы отправлять ACK отдельно, сервер формирует общий пакет, в котором содержится SYN и ACK, и передает его по сети.
Итак, на данный момент устройство А отправило SYN-пакет и получило обратно пакет SYN/ACK. Теперь устройство А должно отправить устройству В пакет ACK, то есть подтвердить то, что оно получило согласие устройства В на установление связи. Таким образом, оба устройства получили пакеты SYN и ACK, и теперь можно сказать, что соединение установлено, то есть осуществлено 3-х этапное рукопожатие по протоколу TCP.
Далее мы рассмотрим технологию TCP Windowing. Проще говоря, это метод, используемый в TCP / IP для согласования возможностей отправителя и получателя.
Предположим, что в Windows мы пытаемся перенести большой файл, скажем, размером 2 ГБ, с одного диска на другой. В самом начале переноса система сообщит нам, что перенос файла займет примерно 1 год. Но несколько секунд спустя система исправится и скажет: «о, подождите минутку, я думаю, что это займет не год, а около 6 месяцев». Пройдет еще немного времени, и Windows сообщит: «я думаю, что возможно, смогу перенести файл за 1 месяц». Затем последует сообщение «1 день», «6 часов», «3 часа», «1 час», «20 минут», «10 минут», «3 минуты». В действительности весь процесс переноса файла займет всего 3 минуты. Как же так получилось? Изначально, когда ваше устройство попытался связаться с другим устройством, оно отправляет один пакет и ждет подтверждения. Если устройство ожидает подтверждения долгое время, оно думает: «если я должно совершить передачу 2 ГБ данных на такой скорости, то это займет около 2 лет». Спустя какое-то время ваше устройство получает ACK и думает: «хорошо, я послал один пакет и получил ACK, следовательно, получатель может принять 1 пакет. Теперь я попробую отправить ему 10 пакетов вместо одного». Отправитель посылает 10 пакетов и через какое-то время получает обратно от принимающего устройства подтверждение АСК, которое означает, что получатель ожидает следующий, 11-й пакет. Отправитель думает: «отлично, раз получатель справился сразу с 10-ю пакетами, теперь я попробую послать ему 100 пакетов вместо десяти». Он посылает 100 пакетов, и получатель отвечает, что получил их и сейчас ожидает 101 пакет. Таким образом, с течением времени количество передаваемых пакетов увеличивается.
Вот почему вы видите стремительное уменьшение времени копирования файла по сравнению с заявленным первоначально — это связано с увеличением возможности передачи большого объёма данных. Однако наступает момент, когда дальнейшее увеличение объема передачи становится невозможным. Предположим, вы передали 10000 пакетов, но буфер устройства получателя способен принять всего 9000. В этом случае получатель отправляет ACK с сообщением: «я принял 9000 пакетов и теперь готов принять 9001». Из этого отправитель делает вывод, что буфер принимающего устройства имеет емкость всего 9000, значит, с этого момента я буду посылать за раз не более 9000 пакетов. При этом отправитель быстро подсчитывает время, которое потребуется ему на передачу оставшегося объёма данных порциями по 9000 пакетов, и выдает 3 минуты. Эти три минуты и являются фактическим временем передачи. Вот что делает TCP Windowing.
Это один из тех механизмов регулирования трафика, где передающее устройство со временем понимает, какова фактическая пропускная способность сети. У вас может возникнуть вопрос, почему они не могут договориться заранее о том, какова емкость принимающего устройства? Дело в том, что технически это невозможно, потому что в сети имеются различные типы устройств. Предположим, у вас есть iPad, и у него скорость приема/передачи данных отличается от iPhone, у вас могут быть разные типы телефонов, или, может быть, у вас очень старый компьютер. Поэтому у всех разная пропускная способность сети.
Поэтому и была разработана технология TCP Windowing, когда передача данных начинается на небольшой скорости или с передачи минимального количества пакетов, постепенно увеличивая «окно» трафика. Вы отправляете один пакет, 5 пакетов, 10 пакетов, 1000 пакетов, 10000 пакетов и медленно приоткрываете это окно все больше и больше, пока «раскрытие» не достигнет максимального возможного значения отправки объема трафика в конкретный промежуток времени. Таким образом, концепция Windowing является частью работы протокола TCP.
Далее мы рассмотрим наиболее распространенные номера портов. Классической является ситуация, при которой у вас есть 1 главный сервер, возможно, это дата-центр. Он включает в себя файловый сервер, веб-сервер, почтовый сервер и DHCP-сервер. Теперь, если один из клиентских компьютеров свяжется с дата-центром, который расположен в середине картинки, тот начнет рассылать клиентским устройствам трафик файлового сервера. Этот трафик показан красным цветом, и для его передачи будет использоваться определенный порт для определенного приложения от определенного сервера.
Каким образом сервер узнал, куда должен идти определенный трафик? Он узнает об этом из номера порта назначения. Если вы посмотрите на фрейм, то увидите, что в каждой передаче данных имеется упоминание номера порта назначения и порта источника. Вы видите, что синий и красный трафик, а синий трафик – это трафик веб-сервера, оба поступают на один и тот же физический сервер, в котором установлены разные серверы. Если это дата-центр, то он использует виртуальные серверы. Так как же они узнали, что красный трафик должен был вернуться к этому левому ноутбуку с этим IP-адресом? Они знают это благодаря номерам портов. Если вы обратитесь к статье Википедии «Список портов TCP и UDP», то увидите, что в ней перечислены все стандартные номера портов.
Если прокрутить эту страницу, то у можно увидеть, насколько велик этот список. Он содержит примерно 61 000 номеров. Номера портов от 1 до 1024 известны как наиболее распространенные номера портов. Например, порт 21/TCP предназначен для передачи команд ftp, порт 22 для ssh, порт 23 – для Telnet, то есть для передачи незашифрованных сообщений. Очень популярный порт 80 служит для передачи данных по протоколу HTTP, а порт 443 служит для передачи зашифрованных данных по протоколу HTTPS, который похож на безопасную версию HTTP.
Некоторые порты предназначены одновременно для TCP и UDP, а некоторые выполняют разные задачи в зависимости от того, какое соединение используется – TCP или UDP. Так, официально порт 80 TCP используется для HTTP, а неофициально порт 80 UDP используется для HTTP, но по другому протоколу HTTP — QUIC.
Поэтому номера портов в TCP не всегда предназначены для того же, что и в UDP. Вам не нужно учить этот список наизусть, его невозможно запомнить, но некоторые популярные и наиболее распространенный номера портов нужно знать. Как я сказал, некоторые из этих портов имеют официальное предназначение, которое описано в стандартах, а некоторые – неофициальное предназначение, как в случае с Сhromium.
Итак, в этой таблице перечислены все распространенные номера портов, и эти номера служат для отправки и получения трафика при использовании конкретных приложений.
Теперь давайте рассмотрим, как данные перемещаются в сети, основываясь на той небольшой информации, которую знаем. Предположим, что компьютер 10.1.1.10 хочет связаться с этим компьютером, или этим сервером, который имеет адрес 30.1.1.10. Под IP-адресом каждого из устройств размещен его MAC-адрес. Я привожу в пример MAC-адрес только с последними 4 знаками, но на практике это 48-битное шестнадцатеричное число с 12 знаками. Так как каждое из этих чисел состоит из 4-х бит, 12 шестнадцатеричных цифр представляют собой 48-битное число.
Как мы знаем, если это устройство хочет связаться с этим сервером, сначала должен быть сделан первый шаг 3-этапного рукопожатия, то есть отправлен SYN-пакет. При создании этого запроса компьютер 10.1.1.10 укажет номер порта источника, который Windows создаёт динамически. Windows случайным образом выбирает номер порта в диапазоне от 1 до 65,000. Но поскольку начальные номера в диапазоне от 1 до 1024 являются широко известными, в данном случае система будет рассматривать номера больше 25000 и создаст случайный порт источника, например, под номером 25113.
Далее система добавит в пакет порт назначения, в данном случае это порт 21, потому что приложение, которое пытается подключиться к этому FTP-серверу, знает, что оно должно отправить FTP-трафик.
Далее наш компьютер говорит: «Хорошо, мой IP-адрес 10.1.1.10, а мне нужно связаться с IP-адресом 30.1.1.10». Оба эти адреса также включаются в пакет, формируя SYN-запрос, и этот пакет не будет изменяться до конца установления соединения.
Я хочу, чтобы вы поняли из этого видео, как данные перемещаются по сети. Когда наш компьютер, отправляющий запрос, видит IP-адрес источника и IP-адрес назначения, он понимает, что адрес назначения не находится в этой локальной сети. Я забыл сказать, что это все /24 IP-адреса. Так что, если вы посмотрите на IP-адреса /24, то поймете, что компьютеры 10.1.1.10 и 30.1.1.10 не находятся в одной сети. Таким образом, компьютер-отправитель запроса понимает, что для того, чтобы выйти из этой сети, он должен обратиться к шлюзу 10.1.1.1, который настроен на одном из интерфейсов маршрутизатора. Он знает, что он должен перейти к 10.1.1.1, и знает свой MAC-адрес 1111, но не знает MAC-адрес шлюза 10.1.1.1. Что же он делает? Он посылает широковещательный ARP-запрос, который получат все устройства в сети, но ответит на него только маршрутизатор с IP-адресом 10.1.1.1.
Маршрутизатор ответит ему своим MAC-адресом АААА, и оба MAC-адреса – источника и назначения — также будут помещены в этот фрейм. Как только фрейм будет готов, перед тем, как покинуть сеть, будет осуществлена проверка целостности данных CRC, представляющая собой алгоритм нахождения контрольной суммы с целью обнаружения ошибок.
Циклический избыточный код CRC означает, что весь этот фрейм, от SYN до последнего MAC-адреса, прогоняется через алгоритм хеширования, скажем, MD5, в результате чего получается значение хеша. Затем значение хеша, или контрольная сумма MD5, помещается в начало фрейма.
Я обозначил её FCS/CRC, потому что FCS – это последовательность проверки кадров, четырехбайтовое значение CRC. Некоторые люди употребляют обозначение FCS, а некоторые — CRC, поэтому я просто указал оба обозначения. Но в принципе это всего лишь значение хеша. Оно нужно для того, чтобы убедиться, что все данные, поступающие по сети, не содержат ошибок. Поэтому, когда этот фрейм достигает маршрутизатора, первое, что сделает маршрутизатор, это вычислит контрольную сумму самостоятельно и сравнит её со значением FCS или CRC, которое содержит полученный фрейм. Таким образом он сможет проверить, что данные, поступившие по сети, не содержат ошибок, после чего удалит контрольную сумму из фрейма.
Дальше роутер посмотрит на MAC-адрес и скажет: «Хорошо, MAC-адрес AAAA означает, что фрейм адресован мне», и удалит часть фрейма, содержащую MAC-адреса.
Посмотрев на IP-адрес назначения 30.1.1.10, он поймет, что этот пакет адресован не ему и должен пройти через маршрутизатор дальше.
Теперь роутер «думает» о том, ему нужно увидеть, где находится сеть с адресом 30.1.1.10. Мы еще не рассматривали полной концепции маршрутизации, но знаем, что роутеры имеют таблицу маршрутизации. В этой таблице есть запись для сети с адресом 30.1.1.0. Как вы помните, это не IP-адрес хоста, а идентификатор сети. Роутер «подумает» о том, что можно достичь адреса 30.1.1.0/24, пройдя через маршрутизатор 20.1.1.2.
Вы можете спросить, откуда он это знает? Просто учтите, что он узнает об этом либо из протоколов маршрутизации, либо из ваших настроек, если вы как администратор настроили статический маршрут. Но в любом случае, таблица маршрутизации этого роутера содержит нужную запись, поэтому он знает, что должен отправить этот пакет в 20.1.1.2. Предполагая, что роутер уже знает MAC-адрес назначения, мы просто продолжим пересылку пакета. Если же он не знает этого адреса, то снова запустит ARP, получит MAC-адрес роутера 20.1.1.2, и процесс отправки фрейма опять продолжится.
Итак, мы предполагаем, что он уже знает MAC-адрес, тогда у нас появится исходный MAC-адрес BBB и MAC-адрес назначения CCC. Роутер снова вычисляет FCS/CRC и помещает его в начало фрейма.
Затем он отправляет этот фрейм по сети, фрейм доходит до маршрутизатора 20.1.12, тот проверяет контрольную сумму, убеждается, что данные не повреждены, и удаляет FCS/CRC. Затем он «обрезает» MAC-адреса, смотрит на пункт назначения и видит, что это адрес 30.1.1.10. Он знает, что этот адрес подключен к его интерфейсу. Тот же процесс формирования фрейма повторяется, роутер добавляет значения MAC-адресов источника и назначения, делает хеширование, прикрепляет хэш к фрейму и отправляет его по сети.
Наш сервер, получив наконец-то адресованный ему SYN-запрос, проверяет контрольную сумму хеша, и если в пакете не содержит ошибок, удаляет хеш. Затем он удаляет MAC-адреса, смотрит на IP-адрес и понимает, что этот пакет адресован именно ему.
После этого он обрезает IP-адреса, относящиеся к третьему уровню модели OSI, и смотрит на номера портов.
Он видит порт 21, который означает FTP-трафик, видит SYN и поэтому понимает, что кто-то пытается установить с ним связь.
Теперь, в соответствие с тем, что мы узнали о рукопожатии, сервер 30.1.1.10 создает пакет SYN/ACK и отправит его обратно компьютеру 10.1.1.10. Получив данный пакет, устройство 10.1.1.10 создаст ACK, пропустит его через сеть таким же образом, как пакет SYN, и после получения ACK сервером соединение будет установлено.
Одна вещь, которую вы должны знать — все это происходит менее чем за секунду. Это очень и очень быстрый процесс, который я постарался замедлить, чтобы вам было все понятно.
Я надеюсь, вам пригодится то, что вы узнали из этого урока. Если у вас есть вопросы, пишите мне на адрес imran.rafai@nwking.org или оставляйте вопросы под этим видео.
Начиная со следующего урока, я буду отбирать по 3 самых интересных вопроса с YouTube, которые я буду рассматривать в конце каждого видео. С этого момента у меня будет раздел «Лучшие вопросы», так что я буду размещать вопрос вместе с вашим именем и отвечать на него в прямом эфире. Думаю, это пойдет на пользу.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до лета бесплатно при оплате на срок от полугода, заказать можно тут.
Для чего нужно значение crc в поле fcs кадра
Узлы взаимодействуют между собой путем обмена кадрами. В Ethernet кадр — это базовая единица обмена по сети. Любая информация, передаваемая между узлами, помещается в поле данных одного или нескольких кадров. Пересылка кадров от одного узла к другому возможна лишь при однозначной их идентификации. Каждый узел ЛВС имеет уникальный адрес (MAC-адрес). Любой кадр имеет минимум 3 поля.
Если узлы и обмениваются данными, то каждый узел получает все кадры. Узлы, для определения адресованных им кадров используют механизм фильтрации. При получении кадра узел сравнивает адрес получателя со своим собственным. Если адреса отличаются, то узел игнорирует (отбрасывает) кадр, иначе кадр принимается и обрабатывается. Эту операцию называют копированием, т.к. кадр действительно копируется из ЛВС в память узла. Широковещательный адрес предусмотрен в любой сетевой технологии. Такие кадры будут приниматься всеми узлами, у которых адрес совпадает с широковещательным. Используется при поиске необходимых ресурсов в сети. Пример — открытие адреса — если нужно узнать адрес конкретного ПК, то посылается широковещательное сообщение, на которое все узлы отвечают сообщением со своим адресом.
Циркулярный режим работы узла.
Узел отключает фильтрацию и принимает все полученные кадры, не зависимо от их адресов получателя. Этот режим используется для диагностики сети.
Протоколы — правила движения в сети.
Обмен кадрами — основной метод связи по сети. Существуют правила (протоколы), определяющие порядок пересылки кадров и информации, которая должна присутствовать в поле данных каждого из них.
Протокол — это набор правил, управляющих взаимодействием ПК.
Взаимодействие всегда можно представить в виде команд и реакций.
Протоколы и кадры относятся к различным уровням коммуникационной системы. Кадр — это механизм низкого уровня, привязанный к специфической технологии оборудования. В сетях Ethernet используется один и тот же формат кадра. В других сетевых технологиях он другой.
Сетевой протокол — это механизм более высокого уровня, не зависимый от технологии более низкого уровня.
Структура кадра технологии Ethernet.
Min — 64 байта (512 бит)
Max — 1518 байт (12144 бита)
Адресация кадров.