#71. Сетевая модель OSI и Internet. Разбор ключевых протоколов обмена данными: | HTTP, DNS & DHCP | TCP | IP | Ethernet & ARP |

Это статья об основах программирования на Go. На канале я рассказываю об опыте перехода в IT с нуля, структурирую информацию и делюсь мнением.

Хой, джедаи и амазонки!

1. Введение

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

Модель Internet - то же самое, но информация проходит через четыре уровня.

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

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

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

Разделяемые ресурсы - это те ресурсы, к которым можно получить доступ по сети. Их можно разделить на два вида:

• Физические;
• Цифровые.

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

К физическим ресурсам можно отнести всё, что имеет материальную природу - например, можем напечатать на принтере фотографию.

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

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

Внучка полковника девочка Катя,

Кнопку на пульте нажала не кстати,

С рёвом ракеты в небо ушли,

Англию с Францией мы не нашли.

Иллюстрация: https://tass.ru/armiya-i-opk/4911274

Следует различать модель и стек. Если модель - это концептуальная схема, то стек (OSI или Internet) - набор конкретных протоколов с конкретными правилами реализации модели.

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

Основой стека Internet является стек протоколов TCP/IP, который в момент появления был одним протоколом. Сам проект по созданию этого протокола назывался "Internetting".

Над обеими моделями (и стеками) работали опытнейшие специалисты и учёные долгие годы: подготовка базы, старт работ и становление обеих моделей происходило в период примерно с 1970 по 1985 гг.

Модель Internet разрабатывалась с прикладной точки зрения, отбрасывая избыточную (академическую) сложность и предоставляя большую свободу действий производителям аппаратной части и разработчикам ПО.

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

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

Существовали и другие стеки протоколов обмена данными по сети, но они, как я понимаю, ушли в историю. Например, есть корпорация Novell, её сетевая ОС Novell NetWare и её сетевые протоколы IPX/SPX сохраняли лидерство в локальных сетях долгие годы. Или стек NetBIOS/SMB использовался в IBM и Microsoft. Были и другие стеки.

Ниже представлен график, иллюстрирующий долю организации сетей по тому или иному стеку протоколов. Ещё в 1996 г. лидером стала модель Interet, и с тех пор только укрепляется (на графике обозначена IP):

Стр. 361: https://djvu.online/file/74p9BJGTkrarM

В результате Интернет работает по модели Internet, а модель OSI используется в академических целях как эталонная модель, к которой нужно стремиться и которой невозможно достичь.

Визуализация обеих моделей в моём понимании выглядит примерно так:

Визуализация уровней моделей

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

Уровни должны были снизить монополию IT-гигантов, улучшить качество сетевых технологий и снизить их цену: одна компания занимается разработкой новых физических средств связи (оптоволокно, WiFi, 5G и т.д.), другая компания - протоколами сжатия данных для их компактной передачи, третья - разработкой пользовательского ПО и т.д. Но при этом взаимосвязь уровней строго регламентируется.

Далее я подробнее расскажу о каждом стеке. Проблема в чём - я буду приводить примеры реализации уровней OSI, транслируя теоретические аспекты каждого уровня на реальный мир. А в реальном мире нет OSI, а есть Internet. Поэтому многое из того, что будет в примерах, будет соответствовать сразу нескольким уровням OSI.

Почему я хочу разобраться с моделью OSI, раз она не применяется в реальности? Скажем так, не спроста она жива до сих пор. Есть у меня гипотеза, что разобравшись с "осью" хотя бы на поверхностном уровне, смогу стать более хорошим программистом. К примеру, когда в документации встречается описание L2 (Layer 2), имеется в виду 2 уровень OSI или 1-й уровень Internet.

В разделе о модели OSI я приведу больше теоретической информации, необходимой для понимания принципов; а в разделе о модели Internet приведу больше конкретики и разбор важных протоколов - DNS, HTTP, TCP и других.

2. Модель OSI

2.1. Предпосылки появления OSI

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

В то время разные компьютеры имели разную архитектуру и протоколы взаимодействия, не позволяющие связать сетью два компьютера разных производителей. Или собрать из микросети компьютеров одного производителя, сеть покрупнее. Объединение сетью компьютеров нужно было для обмена данными между пользователями из разных частей предприятия/города/страны/континентов. А производители компьютеров боролось за госконтракты и монополию в IT-бизнесе.

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

В 1984 г. вышел международный стандарт ISO 7498 (1-4) "Open Systems Interconnection model", русский вариант "Взаимосвязь открытых систем", который считается эталонной моделью сетевого взаимодействия компьютеров.

Стандарт ISO 7498 был разработан (и опубликован) за 7 лет в период с 1977 по 1984 г.

ВОС - отечественная аббревиатура OSI.

Модель OSI состоит из уровней и описания к ним, как информация передаётся между уровнями. Вся модель OSI описывается четырьмя томами ISO 7498.

Стек OSI - это конкретные протоколы, реализующие модель OSI.

Эти протоколы отличает большая сложность и неоднозначность. На нижних уровнях OSI нет собственных протоколов, они разработаны вне стека - это Ethernet, Token Ring, FDDI, X.25, ISDN. Протоколы средних уровней разрабатывались разными производителями, но не получили распространения. Прикладные протоколы OSI уже не используются, но ранее были популярны - FTAM для передачи файлов, VTP - для эмуляции терминала, X.400 для электронной почты, X.500 для справочной службы и др.

Также есть спецификации, описывающие правила реализации протоколов. Например, RFC 791, описывающий IP - эта спецификация вышла в 1981 г. Есть более новая, RFC 2460, описывающая IPv6, вышла в 1998 г. - хотя это по сути, другой протокол.

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

2.2. Структура модели OSI

Уровней семь:

Диаграмма уровней модели OSI. Иллюстрация с Википедии

На иллюстрации выше уровни не пронумерованы, но считают их с низа, т.е. физический уровень - 1-й, прикладной уровень - 7-й. Кстати, в официальной документации канальный уровень переводится, как "Уровень звена данных", а не "Канальный", - в частности, в ГОСТ Р ИСО/МЭК 7498-1-99.

Согласно модели OSI, информация при её передаче, проходит все уровни. Каждый уровень может общаться только с одним уровнем выше и ниже него. Например, уровень 3 "Сетевой" может общаться с уровнем 2 "Канальный" и уровнем 4 "Транспортный".

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

Три верхних уровня (прикладной, представления и сеансовый) - сетенезависимые, т.к. ориентированы на работу приложений и напрямую не зависят от технической реализации сети. Например, переход с витой пары на радиосвязь (например, 5G) не потребует изменений в ПО, реализующих функции трёх верхних уровней.

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

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

Далее примеры реализации каждого уровня. Начнём с верхнего для лучшего понимания процесса.

2.3. Прикладной уровень - L7

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

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

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

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

ISQ. Иллюстрация: https://dzen.ru/a/ZhK4MyBkSU6bKWlj

Прикладной уровень не ограничен веб-приложениями (условно - всем, что открывается в браузере). Есть протоколы для мгновенным обменом сообщениями - XMPP (вероятно, Telegram, WhatsAPP, Viber и т.д.), видеоконференциями - WebRTC (вероятно, Zoom, Google Meet, Discord и т.д.) и др., хотя никто не запрещает использовать эти протоколы и вебе.

Многие протоколы прикладного уровня появились в предшественнике интернета - ARPANET, например протокол для передачи файлов FTP, появившийся в 1971 г. и практически не изменившийся до сих пор. Хотя FTP постепенно вытесняется более современными протоколами.

На основе протоколов прикладного уровня разрабатываются конкретные реализации интерфейсов. Например, можно сказать, что есть два HTTP: как протокол и как интерфейс. Как протокол - это набор правил как реализовывать HTTP-интерфейс, чтобы другое приложение на основе HTTP могло взаимодействовать с ним. А как интерфейс HTTP - это конкретная реализация (конкретная программа), разработанный по протоколу HTTP. Протокол HTTP - один, интерфейсов (на основе) HTTP - может быть сколько угодно.

Когда пользователь совершает действие в приложении, обращаясь к сети, происходят две вещи:

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

2.4. Уровень представления - L6

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

Преобразование данных одновременно сжимает данные, для ускорения передачи данных. А пример протокола шифрования - SSL (Secure Socket Layer).

Сжатие - уменьшение количества бит, которые нужно передать по сети. Нужно для увеличения скорости передачи данных.

Сжатые данные нужно будет распаковать при приёме, это также выполняется на уровне представления.

Вспомните Телеграм или WhatsApp, которые сжимают фотографии при передаче. В то же время можно отправлять фото как файлы без потери качества. Это - реализация уровня представления OSI.

Кодеки - это программы для сжатия и распаковки сжатых медиафайлов.

Вот некоторые известные кодеки:

• MP3 - сжимает музыкальные файлы (работает с файлами формата .mp3);
• AAC - сжимает как MP3, но с лучшим качеством (.m4a и .aac);
• OGG Vorbis - аналог предыдущих аудио-кодеков (.ogg);
• H.264 - для видео (работает с форматами файлов .mp4, .mkv, .avi, .mov);
• JPEG - для иллюстраций ( .jpg, .jpeg);
• GIF - аналог JPEG, но поддерживает анимацию (.gif).

Визуализации здесь никакой нет, т.к. это ПО без графического интерфейса.

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

2.5. Сеансовый уровень - L5

Сеансовый уровень отвечает за создание, поддержание и завершение сеанса соединения компьютеров (открытых системам).

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

На сеансовом уровне могут использоваться точки синхронизации, чтобы в случае прерывания связи, можно было вернуться к точке синхронизации, а не начинать передачу данных с начала. Это как "save game" в компьютерной игре.

В реальности функции этого уровня скорее не используются в виде отдельных протоколов и реализующих их ПО. Эти функции объединяются с протоколом прикладного уровня.

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

Видеоконференция в Zoom. Иллюстрация с Википедии

Здесь происходит явное соединение - которое графически отображается "Соединение..."; сеанс поддерживается и сеанс явно завершается.

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

• PPTP (Point-to-Point Tunneling Protocol) - протокол для создания виртуальных частных сетей - VPN. Примеры реализаций протокола: всевозможные VPN-клиенты.
• RPC (Remote Procedure Call) - позволяет программам вызывать функции на удаленных серверах, как если бы они были локальными, абстрагируя детали сети. Используется в распределённых приложениях и создании микросервисов. Примеры реализаций протокола: gRPC, XML-RPC, JSON-RPC, Windows RPC.
• NetBIOS (Network Basic Input/Output System) - древний протокол для взаимодействия устройств по сети. Если открыть "Сетевое окружение" и найти там другие компьютеры - это может быть результатом работы NetBIOS, так как он позволяет выполнять запросы на имена устройств и устанавливать соединения. Примеры реализации протокола: Microsoft Windows сетевое окружение, Samba.

Перечень протоколов, которые можно отнести к сеансовому уровню менее явно, и они скорее относятся к прикладному уровню:

• WebSocket - протокол предоставляет возможность двусторонней постоянной связи между клиентом и сервером. Он хорошо подходит для приложений, требующих обмена данными в реальном времени, таких как чаты, онлайн-игры или финансовые приложения. Примеры реализаций протокола: библиотека gorilla/websoket для разработки приложений на Go и различные чаты/онлайн-игры и т.д., реализующие принципы протокола.
• RDP (Remote Desktop Protocol) - протокол, позволяющий пользователям удаленно подключаться к другим компьютерам и управлять ими, как если бы они находились перед ним. Примеры реализаций протокола: Microsoft Remote Desktop, Remote Desktop Services на сервере Windows, а также сторонние клиенты, такие как Royal TS и mRemoteNG.

Ещё раз: на сеансовом уровне может быть два режима - с установленным соединением и без него.

В режиме с установленным соединением, сеансовый уровень может выполнять следующие услуги:

1. Устанавливать соединение;
2. Освобождать соединение;
3. Передавать данных;
4. Передавать срочные данные;
5. Административное управление полномочиями;
6. Синхронизация соединения;
7. Передавать особое сообщение;
8. Административное управление активностью;
9. Передача служебных данных;
10. Повторная синхронизация.

В режиме без установленного соединения, сеансовый уровень может выполнять следующие услуги:

1. Передача данных с использованием услуг транспортного уровня;
2. Особое сообщение.

Каким образом реализуются эти услуги? Тут зависит от протоколов, но в общем случае идея такая: L5 может передавать на L4 не только данные, пришедшие с L6, но и свои собственные данные. Причём L5 не станет объединять свою служебную информацию с информацией от L6, а попридержит информацию с L6, пока будет создавать соединение. А уж когда соединение будет установлено, начнёт передавать информацию с L6 без изменений на следующий уровень. Сейчас об этом можно рассуждать только в теории, т.к. реально действующие протоколы объединяют сеансовый уровень, представления и прикладной уровень.

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

2.6. Транспортный уровень - L4

Транспортный уровень обеспечивает для верхних уровней модели OSI передачу данных в зависимости от приоритета потребностей: надёжность или экономичность (скорость) передачи данных.

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

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

В режиме с установленном соединением, транспортный уровень предоставляет услуги:

1. Установление соединения транспортного уровня;
2. Освобождение соединения транспортного уровня;
3. Передача данных;
4. Передача срочных данных;
5. Средства приостановления.

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

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

1. Создание/фрагментация модуля данных;
2. Управление скоростью передачи данных;
3. Управляет уровнем надёжности обмена данными;
4. Адресация данных процессу.

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

Один из элементов управления скоростью передачи данных - постепенное наращивание объёма данных при передаче. Есть конкретные реализации в виде алгоритмов. Если вы пользовались torrent'ами, то помните - как постепенно увеличивается скорость скачивания (хотя там параллельные соединения, но для понимания идеи - можно использовать). Это нужно, чтобы потенциально медленное принимающее или промежуточное устройство не перегружалось данными потенциально быстрого передающего устройства, и данные не терялись.

Уровень надёжности определяется главным образом наличием (есть/нет) проверки получения данных получателем и соответствующей обработкой отсутствия подтверждения. Это главная особенность. Хотя всего есть пять классов сервиса, они отличаются срочностью передачи данных, возможностью восстановить прерванную связь, мультиплексирования соединений нескольких прикладных протоколов с транспортным протоколом. Выбор класса происходит исходя из требований вышестоящих протоколов и надёжностью физического способа передачи данных, в т.ч. точностью обработки ошибок протоколами нижележащих уровней (L2 и L3).

В общем виде вот перечень физических сред от самой надёжной к наименее надёжной:

1. Оптоволокно;
2. Витая пара;
3. Коаксиальный кабель;
4. Wi-Fi;
5. Сотовые сети;
6. Прочие радиосигналы и лазеры.

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

Порт - это логический номер (от 0 до 65535 для TCP-протокола), который служит для идентификации процесса приложения на хосте в контексте сетевого взаимодействия.

Хост - это компьютер, который может отправлять или принимать данные, адресованные конкретным процессам. Т.е. работает с данными на трансПОРТном уровне.

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

Существуют общеизвестные порты. Вот некоторые из них:

Некоторые общеизвестные порты и соответствующие им протоколы

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

Узел - это устройство и программа, которое может использоваться для приёма и передачи данных.

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

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

Сервер (ПО) - программа, работающая на компьютере (сервере), использующая сокет для обработки запросов клиентов.

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

Клиент (ПО) - это программа, которая запрашивает услуги сервера, используя сокет. Например, веб-браузер или мессенджер.

Прокси-сервер (железо и ПО) - промежуточный сервер между клиентом и сервером для повышения эффективности и безопасности обработки запросов.

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

Под интерфейсом здесь понимаются элементы управления программами, реализующими транспортный уровень. Что это за элементы управления? Это системные вызовы:

1. socket() - создание нового сокета;
2. bind() - привязка сокета к IP-адресу и порту;
3. listen() - установка сокета в режим ожидания входящих соединений;
4. accept() - принятие входящего соединения;
5. connect() - установка соединения с удалённым сокетом;
6. send(), recv() - отправка и получение данных;
7. close() - закрытие сокета.

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

Более конкретно, сокет на стороне сервера позволяет слушать запросы (клиентов), получать от клиентов данные и отправлять в ответ разделяемые ресурсы. На стороне клиента всё наоборот: сокет позволяет отправлять запросы серверу и получать в ответ разделяемые ресурсы.

Широко используемые протоколы транспортного уровня - это TCP (Transmission Control Protocol) и UDP (User Datagram Protocol). Также существуют протоколы - ATP, CSTP, DCCP, FCP, IL и другие.

Протокол, например TCP (или UDP) - один, а реализаци сокетов на основе этого протокола могут варьироваться, например в зависимости от языка программирования.

По сути, сокет - это часть серверного и клиентского программного обеспечения. Сокет на основе конкретного протокола принято называть так: TCP-сокет или UDP-сокет или DCCP-сокет и т.д.

Когда в Go мы пишем:

http.ListenAndServe("127.0.0.1:8080", nil) //HTTP-сервер

или для HTTP-клиента

response, err := http.Get("http://127.0.0.1:8080/")

Это варианты создания TCP-сокетов "IP-адрес + порт", хотя детали реализации скрыты за протоколом HTTP, который более высокоуровневый, чем TCP. Другими словами, TCP - низкоуровневый протокол, а HTTP - высокоуровневый.

Можем и напрямую создать TCP-соединение в Go, без протокола HTTP:

listener, err := net.Listen("tcp", "127.0.0.1:8080") //TCP-сервер

или

conn, err := net.Dial("tcp", "127.0.0.1:8080") //TCP-клиент

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

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

Сырые байты - бинарная последовательность данных без их интерпретации. Исполняемый файл или файл формата .jpeg - последовательность сырых байт, например 0xFF, 0xD8, 0xFF и т.д.

Не сырые байты (обработанные данные) - бинарная последовательность данных, которая была создана или декодирована какой-либо программой.

Программы могут создавать бинарные последовательности для своего использования - это будут обработанными данными.

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

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

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

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

Разница между UDP-дейтаграммами и TCP-сегментами в заголовке и действиях при обработке заголовка: в TCP-сегменте заголовок содержит намного больше информации и предполагается больше действий с ним.

Заголовок TCP-сегмента позволяет восстанавливать потерянные данные.

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

2.7. Сетевой уровень - L3

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

Модель OSI переняла готовое решение из модели Internet для реализации протокола сетевого уровня - это был протокол IP (Internet Protocol).

Данные, полученные с L4, на L3 называются IP-дейтаграммой (не путать с UDP-дейтаграммой из уровня L4). Этот термин также характеризует данные, передаваемые с L3 на L4. Т.е. с сетевого уровня на транспортный передаётся IP-дейтаграмма.

Дейтаграмма/датаграмма - слово, образованное из двух слов:

Data - данные;

Gram - от греческого слова gramma - запись.

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

В предыдущем параграфе мы рассматривали узлы - ПО и "железо", которые могут обрабатывать сетевые запросы. Узел - это более широкое понятие. Специфичным узлом уровня L1-7 является хост. Специфичным узлом уровня L1-3 является маршрутизатор.

Данные движутся от хоста к хосту;

Между хостами есть маршрутизаторы.

Маршрутизаторы и хосты - это узлы сети.

Таким образом, хост - это клиент или сервер (и в плане аппаратной части, и ПО). Очевидно, что если (почти всегда) по пути между хостами будут маршрутизаторы, то данные пройдут и через эти узлы.

Маршрутизаторы (роутеры) - это класс устройств, которые управляют потоком данных (траффиком) для передачи данных разными маршрутами для повышения надёжности и скорости передачи данных.

Маршрутизаторы сами не создают и не запрашивают данные для передачи, а отправляют данные, полученные от хоста или другого маршрутизатора.

Магистральные маршрутизаторы. Фото: Википедия

Бытовой маршрутизатор. Такие маршрутизаторы как правило используются для подключения домашнего компьютера к интернету. Фото: Википедия

Ниже представлены подводные магистрали связи между узлами из разных материков. Если сервер и клиент на разных материках, то вероятнее всего обмен будет по одному из таких кабелей. Или через спутник если полярники выходят в интернет в экспедиции из Антарктиды:

https://www.telefonica.com/en/communication-room/blog/can-submarine-telecommunications-cables-save-lives/

В блоге Касперского есть много разнообразных интерактивных карт сетей интернета: *клик*

Пакет данных, формируемый на сетевом уровне из IP-дейтаграммы, поступившим с уровня L3, должен быть не больше размера (в байтах), определённого канальным уровнем L2. Этот параметр определяет, какой максимальный объём данных L2 может передать за раз и называется MTU (Maximum Transmission Unit) - максимальным единица передачи и зависит от параметров физической среды для передачи данных. MTU устанавливает максимальный размер для пакета.

Деление IP-дейтаграммы на пакеты заданного размера называется фрагментацией. Очевидно, что если суммарно IP-дейтаграмма + заголовок L3 будут меньше MTU, то формируется один пакет без фрагментации. Хотя протоколы L4 должны передавать на L3 данные не больше размера пакета, это не гарантированно.

Каждый канальный интерфейс уровня L2 имеет определённое MTU, но в целом он не превышает 1500 байт. Т.е. именно столько (или меньше) данных передаётся за одну операцию по сети: "вжух" - передали данные; "вжух" - передали ещё порцию данных и т.д.

Идея сетевого уровня в следующем:

1. На L3 формируется пакет для отправки данных. В заголовок пакета помещается IP-адрес отправителя и получателя. Тело пакета - это IP-дейтаграмма (сырые байты с L4). Если требуется - выполняется фрагментация IP-дейтаграммы.
2. Пакет/ы передаются на уровень L2.
3. Уровень L2 выполняет ряд манипуляций и отправляет данные по сети следующему устройству (узлу) по маршруту.
4. На каждом узле уровня L3 через модули IP (программы, реализующие протоколы IP), выполняется извлечение IP-адреса назначения из заголовка пакета, чтобы решить, по какому маршруту отправить пакет дальше оптимальнее. То есть разные пакеты одной IP-дейтаграммы могут двигаться разными маршрутами до конечного компьютера.
5. Хост, для которого была сформирована IP-дейтаграмма, при получении данных формирует из пакетов IP-дейтаграмму и передаёт её на L4.

IP-адрес (Internet Protocol Address) - это уникальный числовой идентификатор компьютера, который идентифицирует хост в сети.

Было несколько версий протокола IP, прежде чем он получился удачным. Такой широко используемый протокол IPv4, описанной в 1981 г. В нём для хранения IP-адреса использовалось 4 байта (32 бита). Пример IP-адреса протокола IPv4:

192.0.2.235 - форма записи десятичная с точками;

0xC00002EB - форма записи шестнадцатеричная.

32-битный адрес позволял создать 2^32 = 4 294 967 296 адресов устройств (чуть больше 4 млрд.).

В период 1993-1996 г. велась работа над IPv6. В ней для хранения IP-адреса используется 6 байт (128-бит), и этот IPv6-адрес и способен создать 2^128 ≈ 340 триллионов триллионов триллионов адресов, т.е. (340 282 366 920 938 463 463 374 607 431 768 211 456). Триллион - это тысяча миллиардов, т.е. единица + 12 нулей. Пример IPv6-адреса:

2001:0db8:85a3:0000:0000:8a2e:0370:7334 - форма записи шестнадцатеричная. В десятичную обычно не конвертируют.

Перевод сетей с IPv4 на IPv6 начался в 2008 г.

Сейчас (в 2024 г.), доля сетевого траффика по протоколу IPv6 чуть больше 40%, остальной сетевой трафик интернета реализуется по протоколу IPv4.

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

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

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

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

Когда сетевое устройство (маршрутизатор/сервер/клиент) получает данные, оно извлекает IP-адрес назначения и сверяет его со своей таблицей маршрутизации.

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

Примеры столбцов в таблице маршрутизации:

1. Целевой IP-адрес - IP-адрес устройства, которому предназначен кадр;
2. IP-адрес хопа - IP-адрес следующего сетевого устройства в маршруте, ведущего к устройству с целевым IP-адресом.
3. Метрика - число, выражающее "стоимость" маршрута. Метрика зависит от количества хопов к устройству назначения, времени задержки, пропускной способности и других параметров. Кадр будет направлен по маршруту целевого IP с наименьшей метрикой.

Упрощённый примет таблицы маршрутизации:

Пример таблицы маршрутизации

Если целевой IP-адрес 192.168.1.0, то маршрутизатор направит на следующее сетевое устройство с IP 192.198.1.1, т.к. у этого маршрута метрика меньше, чем у другого хопа, ведущего к этому же маршруту.

Метрики изменяются со временем, эти принципы и частота этих изменений регламентируются своими протоколами.

Может возникнуть вопрос - если в протоколе IPv4 больше 4 млрд адресов, то сколько же может быть вариантов маршрутов с разными хопами? Т.е. комбинаций движения между всеми этими узлами.

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

Сетевой уровень как и L5 и L4 работает в режиме с установленным соединением и без установленного соединения.

2.8. Канальный уровень - L2

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

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

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

Если упрощённо - то соседние узлы, это компьютеры, соединённые одним сетевым кабелем или другой физической средой, например по Wi-Fi.

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

Функции канального уровня в реальности реализует сетевой адаптер и его драйвер. Можно выделить четыре основные функции:

1. Создать объект данных;
2. Выполнить физическую адресацию;
3. Проверить доступность и захватить во временное пользование физическую среду передачи данных (среда для передачи данных L1 может физически передавать/получать данные);
4. Обнаружить и исправить ошибки передачи данных (опционально).

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

Структура кадра

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

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

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

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

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

Программа, реализующая протокол L2 общается с программой, реализующей уровень L1 (и L3, соответственно), и получает от L1 информацию о конкретной реализации сетевого интерфейса. На основе этого решается, какой использовать MTU (максимальный размер передачи, см. предыдущий параграф).

MTU влияет на производительность сети, в большинстве протоколов уровня L2 используется MTU равное 1500 байт. Вот несколько современных протоколов уровня L2:

• Ethernet (IEEE 802.3) - самый распространённый протокол для проводных сетей на основе оптоволокна, витой пары или коаксильного кабеля. Практически все офисы, домашние сети и межконтинентальные подводные кабели работают на этом протоколе. MTU 1500 байт.
• Wi-Fi (IEEE 802.11) - протокол беспроводных локальных сетей. Для подключения используется физическая реализация интерфейса на радиосигналах. MTU 2304 байт, но для более эффективной передачи - тоже часто используют 1500 байт.
• RLC (Radio Link Control) - протокол для 3G, LTE и 5G мобильных сетей. MTU зависит от настроек сети и состояния сигнала, варьируется 64-1500 байт.
• Bluetooth - протокол часто используется для общения с умными устройствами или между телефонами. MTU 251 байт.

В заголовок кадра в зависимости от протокола помещается различная служебная информация. Для адресации, в заголовке размещается MAC-адрес отправителя и получателя.

MAC-адрес (Media Access Control - adress) - идентификатор сетевого адаптера компьютера (или другого устройства, например - принтера или смартфона) для адресации данных в локальной сети.

Пример MAC-адреса: 02:42:4c:42:8e:6c

MAC-адрес используется в Ethernet-протоколах, в других протоколах могут быть аналоги идентификаторов, например RB ID в протоколе RLC.

Локальная сеть - это группа устройств, работающих на канальном уровне, ограниченная небольшой территорией.

Понятия локальная, городская, глобальная сеть - размыты, и часто их разделяет только территориальный признак. Пример локальной сети - ноутбук, смартфон, SMART-TV и умная колонка, подключённые к Wi-Fi-роутеру. Если есть более точная формулировка локальной сети - поделитесь в комментариях.

Когда канальное устройство готовится отправить данные другому канальному устройству, оно знает IP-адрес этого конечного устройства, и не знает физических адресов своих соседей, то оно использует протокол ARP. Суть этого протокола: направить известный IP-адрес всем соседям и тот, кто увидит свой IP, отправит свой MAC-адрес.

Если на сетевом уровне была таблица маршрутизации, то на канальном уровне таблица MAC-адресов, где происходит сопоставление выбранному на сетевом уровне устройству с IP-адресом (например, хопу) его MAC-адрес. Эта таблица хранится в КЭШе программы, реализующий ARP-протокол.

MAC-адреса прошиваются производителем сетевого адаптера и хранится в микросхеме сетевого адаптера.

Сетевой адаптер (сетевая карта) на старых компьютерах был в виде отдельной платы, а на современных компьютерах обычно это часть материнской платы (для унификации и удешевления).

Пример сетевой карты:

Сетевая карта. Иллюстрация с Википедии

Напомню, что материальное представление канального уровня - мост и его усовершенствованная форма - коммутатор.

Мост - это устройство для объединения компьютерных сетей.

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

Коммутатор на 24 порта. Фото: Википедия

Некоторые функции драйвера сетевого адаптера:

1. Конфигурирование - при загрузке ОС, драйвер настраивает параметры сетевого адаптера, например скорость передачи данных.
2. Обрабатывает данные - получает данные от ОС (данные для передачи + mac-адрес компьютера назначения), обогащает их дополнительной информацией (свой mac-адреса, контрольная сумма кадра) и формирует кадр.
3. Преобразует кадры в формат для передачи по физическому уровню в виде электрических/оптических/радио-сигналов и передаёт эти импульсы на физический уровень. А вот это уже физический уровень. Таким образом драйвер сетевого адаптера и сам сетевой адаптер работают на двух уровнях - канальном и физическом.
4. Управляет ошибками, возникающими при передаче кадров на физическом уровне.
5. Отслеживает события с сетевым адаптером и передаёт информацию ОС, например, о подключении и об отключении сетевого кабеля.

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

2.9. Физический уровень - L1

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

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

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

Варианты передачи данных на физическом уровне:

1. Металлическая жила (коаксиальный кабель или витая пара);
2. Инфракрасная связь;
3. Радиоволна (мобильные сети типа 3G, blututhes, Wi-Fi, микроволны для спутниковой связи);
4. В виде света по оптоволокну;
5. Лазерная передача (пока экзотика/эксперименты/наука).

Помню время, когда на телефонах появились ИК-порты, которые были сборку. Мы передавали в школе на переменах мелодии и картинки, а позднее - java-игры таким образом:

ИК-связь. Фото: https://dzen.ru/a/YQGEgzNOGSAAootQ

Помимо самих проводников в виде медного провода, оптоволокна и т.д., к физическому уровню относят разъёмы и соединители, например:

AUI разъёмы. Иллюстрация с Википедии

USB тип A. Иллюстрация с Википедии

Чисто на физическом уровне существуют три вида устройств, которые часто объединялись в одно, а сейчас объединяются в устройства более высокого уровня:

• Концентраторы (хабы) - для объединения нескольких устройств, где сигналы передаются всем устройствам хаба;
• Повторители - для восстановления формы сигнала и его усиления в проводнике при передаче на большое расстояние;
• Медиаконвертеры - преобразуют среду распространения сигнала из одной в другую; на практике используют преобразования из электричества по медному проводнику в свет по оптоволокну и обратно.

USB-концентратор. Иллюстрация с Википедии

Usb-концентраторы (хабы) используются (обычно) не для соединения компьютеров, а для подключения к компьютеру (у которого мало портов) различных устройств - мышки, клавиатуры, флешки, съёмного диска и т.д. Но для понимания вполне годятся. А концентраторы для компьютеров уже не используются, т.к. их вытеснили более совершенные устройства, работающие на следующем уровне модели OSI - коммутаторы. Но выглядели концентраторы для компьютеров и других сетевых устройств так:

4-х портовый концентратор с портами для витой пары времён 1990-х. Фото: Википедия

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

Топология - описание, как устройства соединены между собой.

Топология бывает полносвязная и неполносвязная.

Полносвязная топология - сеть, где каждый элемент напрямую связан с другим элементом. Неэффективна и едва ли используется, т.к. каждый компьютер должен иметь столько портов, сколько компьютеров в сети -1. Т.е., если в сети 6 устройств, то должно быть 5 входов для подключения. Если в сети 1 млн устройств, то должно быть 999 999 входов для подключения на кажом компьютере:

Полносвязная топология Схема полносвязной топологии. Иллюстрация с Википедии

У неполносвязной топологии множество подвидов, вот самые простые: шина, звезда, кольцо.

Для топологии "Шина" характерно наличие общего кабеля, к которому подключены компьютеры. На концах кабеля находятся терминаторы для предотвращения отражения сигнала:

Схема топологии "Шина". Иллюстрация с Википедии

Терминатор - это резистор на ~50 Ом, и обычно входит в состав сетевого оборудования.

Для топологии "Звезда" характерно наличие концентратора (хаба):

Схема топологии "Звезда". Иллюстрация с Википедии

Для топологии "Кольцо" характерно последовательное подключение каждого компьютера со следующим в цепи, а последний компьютер подключён к первому:

Схема топологии "Кольцо". Иллюстрация с Википедии

Ниже пример смешанной топологии:

Схема смешанной топологии. Иллюстрация с Википедии

Другие виды топологий: двойное кольцо, решётка, дерево, сеть Клоза и т.д.

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

2.10. Обобщение модели OSI

2.10.1. Общий итог

Подведя итог, можно сопоставить IP-адрес, MAC-адрес и порт со следующей ситуацией, чтобы разобраться, для чего нужны эта адресация на разных уровнях модели OSI:

Когда мы отправляем посылку/бандероль, то почтовый индекс для неё - это как IP-адрес в сети; MAC-адрес - это адрес, по которому нужно доставить, включая улицу, дом и квартиру. На одном почтовом индексе может быть много улиц/домов/квартир (MAC-адресов). А порт - это как человек, на имя которого пришла посылка.

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

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

Основное, что хотел показать, как на маршрутизаторе обрабатывается информация: она проходит пять этапов через три уровня L1->L2->L3->L2->L1. А на хостах информация проходит все семь уровней. Ещё сюда можно было добавить устройство канального уровня (коммутатор) и устройство физического уровня (хаб), и показать, как информация проходит по ним - соответственно, на L1-2-1 и только L1 уровне. Но это бы перегрузило иллюстрацию, а пример с маршрутизатором должен быть наглядным.

Ещё пока изучал, задался таким вопросом: зачем обязательно нужны и MAC-адреса, и IP-адреса? Да, есть уровни OSI, есть протоколы - но уровни проектировали не дураки, почему они решили сделать именно так, на первый взгляд - переусложняя?

Зачем нужны и MAC-адреса и IP-адреса?

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

2.10.2. Адресация

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

В общем виде, можно вывести требования к адресу:

1. Адрес должен однозначно идентифицировать устройство в сети любого масштаба: как из 2-х компьютеров, так из потенциальных 100 млрд устройств или больше;
2. Схема назначения адреса должна быть автоматизирована, или ручной труд должен быть сведён к минимуму;
3. Схема назначения адреса должна исключать (минимизировать) вероятность дублирования адреса;
4. Адрес должен иметь иерархическую структуру, удобную для построения больших сетей. Например: локальная сеть из устройств в квартире -> локальная сеть многоквартирного дома -> сеть городского провайдера -> сеть нескольких городских провайдеров -> сеть региональная -> сеть страны -> сеть материка -> всеобщая сеть. В сетях уже из тысяч устройств (даже не из миллионов), без иерархии адреса приведёт к большим издержкам при поиске адреса назначения.
5. Адрес должен быть удобен для пользователей сети: символьный адрес server1 или www.site.com удобнее, чем числовой 02:42:4c:42:8e:6c или 203.0.113.1.
6. Адрес должен быть компактным, чтобы не перегружать память коммуникационной аппаратуры.

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

Поэтому разные типы адресов полезно использовать для разных ситуаций. Есть три распространённых схемы адресации узлов в сети:

• Аппаратные (физические) адреса - без иерархической структуры для устройств в небольших сетях. Пример - MAC-адрес сетевого адаптера. Уникальность этого адреса обеспечивает само оборудование. При смене сетевого адаптера/материнской платы со встроенным адаптером (или перепрошивке адаптера) меняется и аппаратный адрес.
• Символьный адрес (имя) - предназначен для запоминания людьми и несут осмысленные образы. Имеют переменную длину. Используются и в маленьких и в больших сетях. Могут иметь иерархическую структуру. Неэкономичны при передаче по сети.
• Числовые составные адреса - адаптация символьного адреса с фиксированным компактным форматом. Основной пример - IP-адреса.

Пример применения всех трёх способов адресации:

1. Пользователь вводит в браузер символьный адрес vk.com и делает запрос нажатием клавиши Enter;
2. Происходит сопоставление через специальные протоколы и таблицы символьного адреса vk.com в числовой составной адрес, например - 87.240.132.67.
3. Запрос через числовой адрес легко интерпретируется компьютерами и передаётся между узлами сети, пока не попадает на узел с требуемым IP, который обслуживает локальную сеть. С этого узла он попадает на требуемое устройство с аппаратным адресом.

2.10.3. Что если будет только IP-адрес?

Это мои рассуждения на тему гипотетического отсутствия MAC-адресов, а не какие-либо факты.

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

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

Зачем нужны постоянные IP-адреса (также - фиксированный IP, белый IP или прямой IP) и какие это несёт опасности, можно почитать в блоге Касперского: *клик*

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

Итак, провайдер присвоил компьютеру IP-адрес. В реальности это происходит через протокол DHCP, который использует MAC-адрес, т.е. аппаратный адрес, но допустим присвоение будет осуществлено как-то иначе. Как?

Сценарий:

Можем предположить, что без MAC-адреса, компьютер при подключении к сети будет передавать на все доступные узлы в сети (контактирующие с ним по одному непрерывному кабелю) сигнал:

"Я хочу выходить в интернет и получать оттуда данные. Если кто-то меня слышит, дайте мне IP-адрес".

Это как будто крик через рупор в большую залу со множеством народа. Услышали все, ответить должен тот, кому предназначен запрос.

Запрос услышали все узлы в сети, но почти все промолчали, т.к. не могут назначать IP-адресов. А аналог DHCP-сервера, который может выдавать IP-адреса, отвечает также всем узлам:

"Кто спрашивает? Какой у тебя идентификатор? Кому мне дать IP-адрес?"

Все узлы сети услышали этот вопрос и промолчали, т.к. не спрашивали IP-адрес. А компьютер, который спрашивал, отвечает всем узлам сети:

Ну как это так, кому? Я - ноутбук последней модели с ЦП таким-то, видеокартой такой-то, монитором таким-то, клавиатурой такой-то. Какой тебе ещё дать идентификатор?

DHCP-сервер услышал этот запрос и отвечает всем доступным узлам:

У меня в базе по такому сложному принципу идентификации уже сорок компьютеров. Можешь себя как-то иначе идентифицировать?

И здесь возникает главная проблема такого сценария: нет механизма уникальной идентификации устройств.

Какие здесь могут быть варианты? Аналог DHCP-сервера может выдавать IP-адрес по принципу:

• Каждому уникальному набору данных о компьютере: его видеокарте, ЦП и другим параметрам, или например имени компьютера, которое пользователь сам ввёл при установке операционной системы;
• Сделать внутренний счётчик и увеличивать на 1 IP-адрес в своей таблице и каждый раз выдавать адрес, отличающийся на единицу.

Компьютер, получив IP-адрес сохранит его у себя в ПЗУ или в какой-то микросхеме на материнской плате, предназначенной для хранения IP-адресов.

Какие здесь возникнуть проблемы? Рассмотрим случай, где IP-адрес выдаётся по уникальным сведениям о компьютере - имени, которое ввёл пользователь, или данных о ЦП, видеокатре и т.д.:

• Могут быть одинаковые компьютеры в сети - тогда они будут идентифицированы одинаково и один компьютер будет получать не предназначенную для него информацию, а трафик по сети будет не знать куда идти, т.к. есть несколько точек назначения;
• При смене какой-то части компьютера (добавил ОЗУ или сменил hdd на ssd), или смене имени компьютера пользователем, аналог DHCP-сервер будет опознавать устройство как новое, и выдаст ему новый IP-адрес: быстрое исчерпание доступных IP-адресов.
• Рост сложности таблиц маршрутизации и увеличение задержек при передаче данных и проблема выдачи пула доступных IP-адресов вышестоящими операторами нижестоящим.

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

Рассмотрим случай, где IP-адрес выдаётся по внутреннему счётчику DHCP-сервера, когда каждый раз при получении запроса "выдай IP-адрес", DHCP-сервер будет отдавать по всем узлам созданный IP-адрес:

1. Два компьютера одновременно попросят создать им IP-адрес, и получится что два разных компьютера будут идентифицированы в сети одинаково;
2. При смене ПЗУ или материнской платы, где хранится информация об IP-адресе, пользователю нужно вручную копировать данные со старого ПЗУ на новый. А если ПЗУ сгорел? В общем, ручная работа, которая скорее всего приведёт к выдаче нового IP-адреса: быстрое исчерпание IP-адресов.

Опять, здесь главная проблема - риск назначения одного IP-адреса разным компьютерам.

Ну и в обоих случаях предполагается только постоянного IP, а не динамического - иначе появятся задержки в сети из-за сложности идентификации устройств по какому-либо признаку. А это - риск безопасности в сети.

2.10.4. Что если будет только MAC-адрес?

Итак, представим ситуацию, где в компьютерных сетях используется только аппаратный адрес. Для примера возьмём MAC-адрес.

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

Сценарий:

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

Привет! Я - 00:1A:2B:3C:4D:5E. Хочу узнать, какой прогноз погоды в Сочи на Сб и Вс. Компьютер 02:4B:9A:C8:12:34, если ты меня слышишь - сообщи.

Ответ не приходит. Компьютер с адресом 02:4B:9A:C8:12:34 не услышал запрос, т.к. запрос должен проделать переход между множеством узлов, а узлы, с которыми напрямую контактирует наш компьютер, имеют другие MAC-адреса. Тогда компьютер делает широковещательный запрос, т.е. доступный всем соседним узлам:

Всем привет! Я - 00:1A:2B:3C:4D:5E. Кто может передать мой запрос на 02:4B:9A:C8:12:34? Хочу узнать прогноз погоды в Сочи на Сб и Вс. А заодно назовись кто ты, чтобы я в следующий раз отправлял запрос на передачу персонально тебе, а не всем подряд.

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

Так, я могу пересылать запросы. Сообщу компьютеру с адресом 00:1A:2B:3C:4D:5E свой MAC-адрес, чтобы он отправлял в следующий раз запросы мне. Но вот где же находится адрес 02:4B:9A:C8:12:34, в котором хранятся данные о прогнозе погоды? Загляну в свою таблицу адресации размером триллиард пятилионнов пэтабайт для поиска лучшего маршрута. Подожди шестьдесят лет, пока я загружу эту таблицу и рассчитаю маршрут. Хоть у меня и 64 ядра на ЦП, быстрее не выйдет...

И тут возникает две проблемы.

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

Итак, первая проблема - может быть несколько устройств в сети с одинаковым MAC-адресом, и данные должны быть адресованы всем этим устройствам. Ведь по сути, у нас получилась одна большая локальная сеть.

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

Вторая проблема - таблица адресации, в которой должны содержаться данные всех адресов, будет просто неимоверного размера. Ведь мы не можем регулировать, что в таком-то городе устройства должны иметь MAC-адреса с 0 до 1000, в другом городе MAC-адреса с 1001 до 2000 и т.д.

У нас множество производителей оборудования, которые прошивают производимые ими компьютеры по определённым правилам, и невозможно обеспечить, чтобы такие-то устройства поставлялись только в город N, а другие устройства - в город L.

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

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

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

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

2.10.5. Примеры необходимости разных идентификаторов для одного объекта

Подытожим размышления о том, можно ли было бы использовать только IP-адреса или только MAC-адреса фактами не из IT-сферы:

• У каждого телефона есть уникальный IMEI, но для связи по телефону используются телефонные номера.
• В каждом паспорте гражданина уникальные серия и номер, но люди общаются по имени.
• У каждой книги есть уникальный ISBN, но (обычно) книги ищут по автору и названию.
• У каждого автомобиля уникальный VIN, но могут быть разные номера регистрации.
• У каждого предприятия уникальный ОГРН, но о компаниях обычно говорят по-названию.

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

Итак, здесь заканчиваем рассмотрение модели OSI.

3. Модель Internet

3.1. Введение

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

Визуализация уровней моделей

Вот некоторые важные протоколы или семейства протоколов:

• Прикладной уровень: DHCP, DNS, HTTP, SSL, gRPC, WebSocket, SSH.
• Транспортный: TCP, UDP.
• Сетевой: IPv4, IPv6.
• Канальный: Ethernet IEEE 802.3, ARP.

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

3.2. HTTP - прикладной уровень

3.2.1. Введение в HTTP

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

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

Версии протокола:

1. HTTP/0.9 - 1991 г., ЦЕРН.
2. HTTP/1.0 - 1996 г., описана в RFC 1945.
3. HTTP/1.1 - 1997 г. Текущая редакция в RFC 9112, 2022 г.
4. HTTP/2 - 2015 г. RFC 9113.
5. HTTP/3 - 2022 г. RFC 9114.

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

Протоколы HTTP работают в режиме запрос-ответ. Клиент запрашивает разделяемый ресурс, сервер отвечает. И ответ содержит запрошенный разделяемый ресурс. В запросе содержится вся необходимая для работы сервера информация, а информация о предыдущих HTTP-запросов клиента на сервере не хранится.

Все действующие HTTP-протоколы поддерживают режим шифрования (HTTPS, S - Secure), но реализован он по-разному.

Я рассмотрю только протокол HTTP/1.1.

3.2.2. HTTP/1.1

HTTP/1.1 структурирует запрос в текстовом формате в виде строк. Это удобно для понимания смысла запроса человеком, например, для отладки программы.

Версии протокола HTTP 2 и 3 используют бинарную форму запроса для повышения скорости передачи данных.

Как мы помним из раздела прикладного уровня OSI, на прикладном уровне формируется сообщение.

Сообщение по протоколу HTTP/1.1 может быть либо запросом клиента к серверу, либо ответом сервера для клиента, и имеют одну структуру:

1. Стартовая строка;
2. Заголовок;
3. Тело сообщения.

Синтаксически запрос и ответ различаются только стартовой строкой, которая является либо строкой запроса, либо строкой состояния ответа.

3.2.3. Формат HTTP-запроса

Пример сообщения-запроса клиента:

Сообщение от клиента

В сообщении от клиента обязательна стартовая строка и заголовок Host - адрес сервера, который выполнит запрос. В заголовке HOST указано символьное (доменное) имя, а не IP конкретного хоста.

Стартовая строка клиента (запрос) состоит из трёх элементов:

1. Метод запроса;
2. Строка запроса;
3. Версия HTTP-протокола.

Методы HTTP говорят о том, какие действия с ресурсом нужно совершить на стороне сервера.

Строка запроса включает параметры запроса и/или эндпоинт.

Эндпоинт - идентификатор конкретного разделяемого ресурса, например, путь к файлу /homepage.html или идентификатор запуска сервиса для обработки запроса.

С версией HTTP-протокола, думаю понятно - 1.1, 2 или 3 на данный момент.

Мы привыкли работать с несколькими методами: GET, POST, PUT, DELETE, ну ещё PATCH. А этих методов намного больше:

Перечень HTTP-методов: https://www.iana.org/assignments/http-methods/http-methods.xhtml

3.2.4. Формат HTTP-ответа

Пример сообщения-ответа сервера клиенту:

Сообщение сервера

Стартовая строка ответа содержит три поля:

1. Версия HTTP-протокола;
2. Код состояния ответа (Status Code) - это три цифры, определяющие как сервер смог обработать запрос клиента;
3. Пояснение - разъясняет код; необязательное поле, т.к. коды стандартизированы.

Код состояния - число от 100 до 599, они разделены на пять групп:

• 1xx - информационные;
• 2xx - запрос успешно выполнен;
• 3xx - запрос перенаправлен;
• 4xx - ошибка клиента;
• 5xx - ошибка сервера.

Некоторые часто применяемые статусы ответа:

1. 200 - запрос успешно выполнен;
2. 201 - ресурс создан, ответ содержит идентификатор созданного ресурса;
3. 204 - ресурс создан, ответ без идентификатора ресурса;
4. 400 - некорректный запрос клиента;
5. 403 - у клиента нет прав доступа к ресурсу;
6. 404 - запрошенный клиентом ресурс не найден (в т.ч. может использоваться вместо 403, если нельзя раскрывать существование ресурса в целях конфиденциальности для пользователя, у которого недостаточно прав);
7. 405 - некорректный метод запроса (не поддерживается сервером по заданному в заголовке запроса эндпоинту);
8. 500 - внутренняя ошибка сервера (например, не смогли подготовить json-объект в ответ или сохранить в БД).

Перечень кодов статуса представлен в RFC 9110.

Один из самых важных заголовков - Content-Type. С его помощью приложение прикладного уровня определяет, как расшифровывать полученные в теле данные. Например, сами данные могут выглядеть для человека так:

ÿØÿáJFIF...ÿÙ...ÿÛC...

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

3.2.5. Заключение об HTTP

HTTP-протокол реализован в языках программирования в виде готовых библиотек. В Go это библиотека net/http, через которую можно использовать весь функционал протокола. Разработчик ПО прикладного уровня использует эту библиотеку, чтобы обеспечить сетевое взаимодействие между приложениями, работающими по протоколу HTTP, и не важно на каких языках и какими компаниями они разработаны.

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

Здесь важный момент - в заголовок HTTP-запроса Host помещается символьное имя, но при адресации на сетевом уровне используется IP-адрес. Как происходит это сопоставление? С помощью технологии DNS.

3.3. DNS - прикладной уровень

3.3.1. Введение в DNS

DNS - Domain Name System - Система доменных имён - сетевая технология для автоматизированного получения информации о доменах.

Символьный адрес сетевого ресурса называется доменным именем, например www.wikipedia.org.

Полное доменное имя состоит из непосредственного имени домена (org в примере выше) и имён всех доменов, в которые он входит, разделённых точками:

Структура DNS. Иллюстрация: Википедия

Пример поддоменов для полного доменного имени www.wikipedia.org:

www - (под)домен третьего уровня, он входит в домен второго уровня wikipedia.

wikipedia - домен второго уровня, входит в домен верхнего уровня org.

org - домен верхнего уровня, входит в безымянный корневой домен . (dot/точка).

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

В первую очередь DNS используется для определения IP-адреса по символьному имени (полному доменному имени).

3.3.2. Реализация DNS

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

Описание DNS выполнено в RFC 1034 и RFC 1035, оба 1987 г. Расширения протоколов, касающиеся повышения безопасности описаны в RFC 4033, 4034 и 4035.

IP-адрес хоста - это небольшая часть той информации, которая хранится в БД DSN-сервера. Есть несколько десятков типов ресурсных записей Resource Records, RR) для каждого домена, и каждая такая запись регламентируется каким-то RFC. Вот некоторые важные виды записей:

1. Запись A (address record) связывает имя хоста с адресом протокола IPv4. Это конкретное сопоставление, где для имени хоста типа www.wikipedia.org будет соответствовать IPv4 типа XXX.XXX.XXX.XXX.
2. Запись AAAA (IPv6 address record) то же самое, но для IPv6.
3. Запись CNAME (canonical name record) или каноническая запись имени определяет, что у полного доменного имени может и не быть нижнеуровневого домена, но IP-адрес для них будет одинаковым. Например, для www.wikipedia.org можно указать привязку CNAME wikipedia.org - и запрос к wikipedia.org будет осуществляться также, как для www.wikipedia.org.
4. Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена. Отправляющая сторона будет узнавать с помощью MX на какой сервер отправить почту для указанного домена. С помощью MX можно задать несколько серверов, и когда приоритетный сервер будет недоступен, отправка будет на другой сервер, например: mail1.server.com с приоритетом 1 и mail2.server.com с приоритетом 2.
5. Запись NS (name server) указывает на IP-адреса DNS-сервера/ов для данного домена.
6. Запись PTR (pointer) обратная DNS-запись или запись указателя связывает IP-адрес хоста с его полным доменным именем.
7. Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене.
8. LOC-запись позволяет указать географическое положение сервера.

DNS-сервера с БД есть у каждого провайдера и у других компаний.

Перед отправкой HTTP-сообщения на транспортный уровень, клиентское приложение анализирует - есть ли у него информация, какой IP-адрес соответствует символьному адресу в заголовке его сообщения. Для этого он обращается к своему личному КЭШу, который обычно хранится на ПЗУ компьютера.

Если такое сопоставление доменного имени с IP-адресом хоста находится, то клиентское приложение сперва отправляет этот IP-адрес целевого хоста (сервера) на транспортный уровень для установления TCP-соединения с ним.

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

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

Но если в КЭШе клиентское ПО не находит сопоставление символьного имени хоста с его числовым адресом, то клиентское приложение обращается к сетевой технологии DNS.

Программа, реализующая DNS-протокол, может использовать на транспортном уровне как реализацию UDP-протокола, так и TCP-протокола. Базово используется UDP, но если ответ DNS-сервера слишком большой, произойдёт переподключение по TCP-протоколу.

На нижележащих уровнях модели Internet, это сообщение будет передано на DNS-сервер провайдера. Такой сервер называется "Resolver" или Распознаватель.

3.3.3. DNS-сервера

DNS-сервера связаны между собой. Как и БД каждого DNS-сервера, DNS-сервера имеют древовидную (иерархическую) связь между собой.

Есть четыре типа DNS-серверов:

1. Корневые DNS-сервера: в них хранятся IP-адреса серверов, обслуживающих домены первого уровня. В примере с Википедией - в корневом сервере будут храниться IP-адреса серверов, обслуживающих домен org или com и т.д.
2. TLD DNS-сервера: в них хранятся IP-адреса серверов, обслуживающих домены второго уровня. В примере с Википедией - это сервера, обслуживающие домен wikipedia.org или например сервера для домена vk.com или yandex.ru.
3. Авторитативные DNS-сервера: хранят ресурсные записи по которым можно найти полную информацию о домене, в частности - IP-адрес хоста по его доменному имени. В примере с Википедией это сервер, где хранится вся информация о домене www.wikipedia.org.
4. Распознователи: это DNS-сервера провайдеров, к которым напрямую поступает запрос от клиента, а распознаватель далее общается с другими типами серверов.

Схема следующая:

Иллюстрация: документация Яндекс https://yandex.cloud/ru/docs/glossary/dns

Распознаватель имеет КЭШ, в котором некоторое время хранятся записи "недавно" запрошенных доменов.

При получении запроса от клиента, если DNS-сервер провайдера (распознаватель) не обнаруживает нужного доменного имени в своём КЭШе, то он обращается к корневому серверу. Корневой отвечает, по какому IP-адресу следует обратиться к TLD-серверу. Далее распознаватель обращается к TDL-серверу и отвечает распознавателю к какому авторитативному серверу следует обратиться. И затем распознаватель обращается уже к авторитативному серверу и получает ответ.

Всего существует 13 корневых DNS-серверов. У этих 13 серверов есть ~110 копий, расположенных в разных частях мира. В Африке, например, находятся 3 таких сервера. В РФ есть пять таких серверов.

Запросы по DNS-протоколу бывают трёх видов.

3.3.4. Типы DNS-запросов

Тип запроса от клиента к рапознавателю, когда распознаватель не имеет в своём КЭШе информации о домене, называется рекурсивным. В этом случае распознаватель начинает обращаться к серверам, начиная с корневого и заканчивая авторитативным.

Тип запроса распознавателя к каждому из трёх типов DNS-серверов называется итеративным, т.к. происходит запрос-ответ и на этом общение закончено.

Тип запроса от клиента к распознавателю, когда в КЭШе распознавателя имеется информация о домене, называется нерекурсивным. Ответ сразу направляется клиенту.

При ответе DNS-сервера защищают свой ответ с помощью расширений базового протокола DNS. Они называются DNSSEC, т.е. security и защищают от подмены IP-адресов.

Сами сообщения запроса и ответа стандартизированы:

https://www.ietf.org/rfc/rfc1035.txt

Каждое поле содержит набор своих полей, я разбирать их здесь не буду, базовое сообщение описано в RFC 1035, и дополнено RFC для DNSSEC.

Ключевое здесь то, что в заголовке указывается идентификатор запроса и параметры запроса; и что раздел Question будет в DNS-сообщении запроса, а раздел Answer - в DNS-сообщении ответа.

Вот пример запроса и получения информации от DNS-сервера через терминал:

https://trendoceans.com/dns-toys/

В Go функции DNS доступны через библиотеку net:

Часть функций пакета net в Go

Пример работы с DNS-протоколом через поиск IP-адреса рассмотрен в этой публикации: *клик*.

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

3.4. DHCP - прикладной уровень

3.4.1. Введение в DHCP

DHCP - Dynamic Host Configuration Protocol - сетевая технология динамической настройки узла. Описан в RFC 2131, реализован в ядрах сетевых ОС. Обеспечивает настройку конфигурационных параметров хостов Internet.

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

DHCP поддерживает 3 режима выделения IP-адресов:

1. Клиенту автоматически выделяется постоянный IP-адрес;
2. Клиенту динамически выделяются меняющиеся со временем IP-адреса;
3. Администратор DHCP-сервера назначает постоянный IP-адрес.

На транспортном уровне используется UDP-протокол для формирования и передачи UDP-дейтаграммы.

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

По-умолчанию, запросы передаются на порт DHCP-сервера №67, а сервер отвечает на порт клиента №68. В ответе находится назначенный устройству IP-адрес, IP-адрес маршрутизатора, IP-адрес сервера DNS и другую служебную информацию.

DHCP-серверы в т.ч. являются частью маршрутизатора.

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

Поэтому, когда мы с компьютера или телефона хотим подключиться к интернету, происходит DHCP-запрос, и например wi-fi маршрутизатор (который одновременно DHCP-сервер) получает этот запрос и отдаёт информацию.

При этом маршрутизатор сам периодически обращается к вышестоящему DHCP-серверу за обновлёнными данными.

3.4.2. DHCP-сообщение

DHCP-сообщение запроса и ответа выглядит так:

DHCP-сообщение

Основные поля:

op - операция - определяет тип сообщения. 1 от клиента или 2 от сервера.

xid - идентификатор транзакции - случайное число, определяемое клиентом.

ciaddr - client IP address - существующий IP-адрес клиента, если он был получен ранее от DHCP-сервера.

yiaddr - your IP address - IP-адрес клиента, назначенный DHCP-сервером. Находится только в сообщении-ответе DHCP-сервера.

chaddr - MAC-адрес клиента.

options - служебная информация для сетевой работы. Опций больше 100, стандартные опции описаны в RFC 2132. Вот некоторые важные опции: №1 - маска подсети для присвоенного клиенту IP-адреса; №3 - IP-адреса маршрутизаторов сети, через которые клиенту можно выходить в интернет (в порядке предпочтения); №6 - IP-адреса DNS-серверов, которые может использовать клиент.

3.4.3. Порядок пересылки DHCP-сообщений

Чтобы IP-адрес был назначен, выполняется 2 серии запрос-ответ:

1. Клиент отправляет широковещательный запрос на присвоение IP-адреса и получение служебной информации.
2. DHCP-сервер отправляет персональный ответ по MAC-адресу клиента и передаёт предлагаемую конфигурацию.
3. Клиент отправляет DHCP-серверу персональный запрос по IP-адресу с сообщением о применении IP-адреса.
4. DHCP-сервер отвечает клиенту, что конфигурация ему назначена и сохранена. Теперь у клиента появился IP для обращение с компьютерами в интернете.

3.5. TCP - транспортный уровень

3.5.1. Введение в TCP

Первое описание TCP как протокола выполнено в RFC 793, изданного в 1981 г., и отменившего написанные ранее спецификации TCP. Более свежее описание протокола, можно сказать, объединившее актуальную информацию из всех ссылающихся друг на друга RFC - это RFC 9293 2022 г., где появилась уже связь с IPv6.

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

Процесс с прикладного уровня передаёт фиксированный объём данных или поток сырых байт на транспортный уровень, обращаясь к функциям TCP-протокола. В аргументы этих функций кладутся сообщения, сформированные на прикладном уровне.

Данные (поток или фиксированный объём) прикладного уровня формируются в сообщения TCP-протокола. Такие сообщения называются TCP-сегментами. На размер сегментов влияет множество параметров.

3.5.2. Сегментация TCP

TCP-сегмент - единица данных транспортного уровня для протокола TCP.

В общем случае, смысл создания больших сегментов в следующем:

• Снижение числа находящихся в сети фрагментов данных;
• Повышение производительности за счёт меньшего числа прерываний и межуровневых взаимодействий;
• снижение издержек, связанных с заголовками TCP.

Смысл создания маленьких сегментов в следующем:

• Предотвращение передачи TCP-сегментов на сетевой уровень больше MTU, чтобы не требовалась фрагментация IP-дейтаграмм;
• Выравнивание процесса передачи данных, если данные с прикладного уровня идут с задержками и большими объёмами;
• Потеря маленьких объёмов данных при передачи по сети менее вероятна, чем передача больших объёмов данных. Но если потеря произошла, то передать повторно маленький объём данных проще, чем большой.

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

Ошибки - это случаи, когда принимающая сторона не отправила подтверждения передающей стороне, что данные корректно получены.

Максимальный размер TCP-сегмента при "нарезании" полученных данных с прикладного уровня, рассчитывается каждый раз перед созданием нового сегмента. Идея расчёта в следующем:

Размер TCP-сегмента должен быть меньшим из двух значений:

- SendMSS - ответ от принимающей стороны, который сообщает максимальный размер буфера сборки сегмента.

- MTU - максимальный объём данных, которые физически возможно передать по сети за раз.

Изменение размера сегментов до максимально возможного обеспечивает "медленный старт" и "предотвращение перегрузок" алгоритма Van Jacobson. При выявлении ошибки передачи TCP-сегмента, размер для новых сегмента сбрасывается до минимально возможного с постепенным увеличением размера по мере успешной передачи сегментов.

По умолчанию SendMSS (максимальный размер сегмента) для IPv4 равен 536 байт, а для IPv6 1220 байт. Эти значения используются, если хост назначения не сообщил свой MSS при создании TCP-соединения до начала передачи самих данных.

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

Рассмотрим структуру TCP-сегмента.

3.5.3. Структура TCP-сегмента

TCP-сегмент состоит из псевдозаголовка, заголовка и данных прикладного уровня.

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

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

Может возникнуть вопрос, почему бы не рассчитывать контрольную сумму заголовка и данных только по ним самим? Ответ: для выявления ошибок, которые могут быть не найдены, если проверять данные только по заголовку + данным прикладного уровня.

Формат псевдозаголовка при использовании IPv4 на сетевом уровне:

Псевдозаголовок TCP-сегмента. Иллюстрация: https://vk.cc/cGPMQc

Source и Destination Address - это IP-адреса источника и хоста назначения.

zero - это 8 нулевых битов. Точное их назначение я не понял, но похоже на выравнивание объёма данных, что обеспечит оптимизацию обработки.

PTCL - Protocol Type - вид протокола транспортного уровня. В частности для протокола TCP устанавливается значение 6, а для UDP - 17.

TCP Length - размер TCP-заголовка и данных прикладного уровня.

Псевдозаголовок при использовании протокола IPv6 на сетевом уровне, будет другого формата, я рассматривать его здесь не стану.

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

Заголовок TCP-сегмента с данными прикладного уровня. Иллюстрация: https://vk.cc/cGPMQc

• Source Port - номер порта отправителя: 16 бит.
• Destination Port - номер порта получателя: 16 бит.
• Sequence Number - 32 бита - номер первого байта (октета) в TCP-сегменте. Нужен для упорядоченного сбора сообщения из TCP-сегментов принимающей стороной, пришедших в разнобой.
• Acknowledgment Number - номер подтверждения - 32 бита. Указывается принимающей стороной в её ответе и говорит отправляющей стороне о том, какие сегменты были получены. Используется для выявления ошибок.
• Data Offset - 4 бита - указывает на размер заголовка TCP, т.к. заголовок не имеет фиксированного размера (далее могут быть необязательные поля). Принимающая сторона по этому полю понимает, где заканчивается заголовок и начинаются данные прикладного уровня.
• Reserved - неиспользуемые поля, зарезервированные под развитие протокола TCP.
• Управляющие биты - их шесть штук. Пожалуй, можно выделить четыре самых важных. SYN необходим для установления соединения, а ACK указывает за наличие данных в поле Acknowledgment Number для подтверждения получения данных. Бит FIN указывает, что у отправителя больше нет данных для передачи и нужен для безопасного завершения соединения. Бит RST указывает на преждевременное завершение соединения, пока данные ещё не были полностью переданы отправителю или отправитель не ответил.
• Window - 16 бит - число байтов (октетов), которые получатель готов принять без отправки отправителю подтверждения принятых байтов. Отправитель когда отправил данные, равные полю Window, прервёт отправку и будет ждать подтверждения получения данных принимающей стороной. Для повышения эффективности передачи данных по сети, подтверждение принимающей стороной отправляется не после каждого принятого сегмента, а после некоторого количество сегментов.
• Checksum - 16 бит - контрольная сумма, необходима для проверки корректности полученных данных стороной получателя. В контрольную сумму входит информация о псевдозаголовке, заголовке и данных прикладного уровня.
• Urgent Pointer - указатель срочных данных. Используется, если указан флаг (управляющий бит) URG. Указывает на фрагмент данных, которые нужно обработать в первую очередь.
• Options - дополнительная информация, которая может присутствовать или отсутствовать. Если присутствует, то количество опций не является конкретным. Вот некоторые важные опции: "конец списка опций", "отсутствие опций", "максимальный размер сегмента, т.е. MSS". Также это могут быть временные метки, опции масштабирования Window и др.

3.5.4. Установка TCP-соединения

Для организации соединения используется процедура трёхэтапного согласования (three-way handshake, 3WHS).

Основной пример 3WHS представлен ниже:

Базовое 3-этапное согласование синхронизации соединения. Иллюстрация: https://vk.cc/cGPMQc

Есть два хоста: клиент - партнёр TCP A и сервер - партнёр TCP B. Разберём основное в процессе:

1. В строке 1 TCP-соединение клиента закрыто, а сервер в состоянии прослушивания всех входящих TCP-запросов на установление соединений.
2. В строке 2 клиент отправляет на сервер TCP-сегмент с флагом SYN для установки соединения.
3. В строке 3 сервер отправляет клиенту TCP-сегмент с флагом SYN для подтверждения получения запроса на установление соединения.
4. В строке 4 клиент отвечает серверу TCP-сегментом с пустым флагом AСK.
5. В строке 5 клиент уже передаёт TCP-сегмент с данными.

3.5.5. Закрытие TCP-соединения

TCP-соединение может быть закрыто двумя способами:

• Безопасное закрытие с флагом FIN в TCP-сообщении;
• Прерывание с передачей одного или нескольких TCP-сегментов с флагом RST.

В Go можно напрямую работать с TCP-протоколом через библиотеку net. Такой доступ минуя высокоуровневые протоколы, такие как HTTP, может быть нужно продвинутым разработчикам для каких-то особых настроек, например установки Window Size. Ну или технически если потребуется связаться с каким-то древним компьютером, который не работает по HTTP, а только по TCP, например.

На базовом уровне с TCP-протоколом всё.

3.6. Interet Protocol - сетевой уровень

3.6.1. Введение в IP

С момента публикации RFC 791 в 1981 году, протокол IPv4 не претерпел фундаментальных изменений.

Основные изменения касаются не столько самой спецификации, сколько методов управления адресами и маршрутизации, что отвечало на растущие потребности сетей и устройств. Например, были разработаны механизмы, такие как NAT (Network Address Translation), для решения проблемы ограниченного количества доступных IPv4-адресов.

Я рассказывал в разделе об OSI, что существует IPv4 и IPv6. Здесь разберём IPv4, т.к. он остаётся популярным и его доля в Российской Федерации больше 90%, и на его основе строится IPv6. Далее, когда я пишу IP, имею ввиду прежде всего IPv4, но почти всё это относится и к IPv6 - разве что, кроме структуры пакета.

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

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

А из пакетов формируется TCP-сегмент на транспортном уровне принимающим хостом.

Протокол IP выполняет две основных функции – адресацию и фрагментацию/сборку IP-дейтаграмм.

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

В общем, я подробно рассказал о протоколе IP в описании модели OSI. В частности там был важный раздел о таблице маршрутизации и определении направления (маршрута) по которому будут передаваться данные. Расскажу о структуре пакета.

3.6.2. Пакет IPv4

Единица данных IP-уровня - пакет:

Пакет IPv4. Иллюстрация: Википедия

Вот значение некоторых полей:

• IHL - длина заголовка пакета.
• Идентификатор - если была фрагментация данных с транспортного уровня, то у каждого полученного таким образом пакета будет один id.
• Время жизни - счётчик максимального числа маршрутизаторов. При прохождении пакета через маршрутизатор счётчик уменьшается на единицу. Если счётчик достиг нуля, но пакет не достиг хоста назначения, работа с пакетом прекращается и отправителю направляется соответствующее сообщение по протоколу ICMP.

3.6.3. Протокол ICMP

ICMP - Internet Control Message Protocol - является составной частью IP-протокола, а используется, когда пакеты не могут быть переданы и возвращает хосту-отправителю сообщение с ошибкой.

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

Примеры ошибок:

• Если получатель IP-дейтаграммы по указанному IP-адресу недоступен, маршрутизатор может передать хосту источника сообщение по ICMP "destination unreachebale".
• Если поле пакета TTL равно нулю, пакет отбрасывается, а обратно направляется ICMP-сообщение "time exeeted".
• Сетевое устройство при обработке пакета обнаруживает в заголовке параметры, которые не могут быть обработаны, что приводит к отбрасыванию IP-дейтаграммы. Хосту источника отправляется ICMP-сообщение "parameter problem".
• Если в сетевом устройстве недостаточно буферного пространства для размещения IP-дейтаграммы в очереди на передачу на следующий маршрутизатор, то такая IP-дейтаграмма может быть отброшена; а хосту источника отправлено ICMP-сообщение "source quench".

Всего таких случаев 11. Описание протокола ICMP в RFC 792 1981 г.

В целом об IP, всё.

3.7. Ethernet - канальный уровень

3.7.1. Введение в Ethernet

Изобретённая и опробованная в Xerox в 1973 г. сетевая технология Ethernet, как стандарт была опубликована в 1980 г.

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

Другими словами, Ethernet - это стек протоколов.

Сеть Ethernet рассчитана на параллельное подключение всех узлов к общей шине или древовидной структуре на основе общей шины и повторителей/хабов/концентраторов.

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

Суть случайного метода доступа в том, что компьютер может передавать данные в сети Ethernet, только если она свободна. Т.е. когда никакой другой компьютер не занимается передачей. Процедура определения доступности среды - важная часть сетевой технологии Ethernet. Для этого используется метод CSMA/CD, который я рассматривать здесь не буду.

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

Сеть Ethernet устроена так, что при попадании кадра в разделяемую среду, все устройства, имеющие доступ к этой среде, начинают принимать этот кадр. После приёма, они извлекают из кадра MAC-адреса назначения и сверяют со своими. Если это не их MAC-адрес, то кадр забывается.

Если же MAC-адрес устройства назначения в кадре совпадает с MAC-адресом сетевого адаптера, то кадр помещается в буфер сетевого адаптера.

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

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

Основное преимущество Ethernet, которое обеспечило ему будущее в эпоху зарождения технологии - его простота и экономичность: для построения сети на каждом компьютере достаточно одного сетевого адаптера и одного кабеля между адаптерами. Для других сетевых технологий, например, Token Ring, требовался ещё концентратор.

В 1980 г. в институте инженеров электротехники и электроники - IEEE, - был организован комитет 802. В результате его работы были разработаны стандарты IEEE 802.x, где х - номер рабочей группы, отвечающий за определённую технологию. Рабочая группа №3 отвечала за Ethernet.

Стандарты содержат рекомендации по проектированию сетей нижних уровней модели OSI (L1-2) и L1 для Internet. Позже эти рекомендации использовались для создания стандартов ISO 8802-1...5.

Вот несколько широко используемых стандартов:

• IEEE 802.3 - семейство протоколов Ethernet (несколько десятков);
• IEEE 802.11 - технология Wi-Fi;
• IEEE 802.15.1 - технология Bluetooth.

IEEE 802.3 мы и разберём далее.

3.7.2. IEEE 802.3: Ethernet

В зависимости от типа физической среды, стандарт имеет различные модификации: 10Base-5, 10Base-2, 10Base-T, 1000BASE-LH и др., которые отличаются не только типом среды (радиоволна, кабель или оптоволокно), но и особенностями их конструкции.

В физическом проявлении помимо изменённой конструкции кабеля и разъёмов, эти модификации отличаются максимальной длиной кабеля до необходимости усилить сигнал (подключить повторитель).

На программно-аппаратном уровне, эти модификации влияют на скорость передачи и способ кодирования кадра в серию сигналов.

На практике используют 4 вида кадра, и все современные сетевые адаптеры могут работать с каждым видом кадра:

• Кадр 802.3/LLC или кадр Novell 802.2;
• Кадр Raw 802.3 или кадр Novell 802.3;
• Кадр Ethernet DIX или кадр Ethernet II;
• Кадр Ethernet SNAP.

Для модели Internet важен Ethernet II, но остальные тоже посмотрим:

Визуализация кадров

DA - Destination Address - Адрес Назначения - это MAC-адрес устройства, которому предназначен кадр.

SA - Source Address - Адрес Источника - это MAC-адрес устройства отправителя кадра.

L - Length - Длина - длина поля данных в кадре.

T - Type - Тип - указывает тип протокола, вызвавшего Ethernet-протокол. Для протокола IPv4 значение в поле Type = 0x0800, для IPv6 Type = 0x86DD, для ARP Type = 0x0806; есть и другие вызывающие протоколы.

FCS - Frame Check Sequence - Поле контрольной суммы - контрольная сумма кадра. После получения кадра сетевой адаптер вычисляет свою FCS полученного кадра и сравнивает его с FCS, указанного в полученном кадре для определения не искажён ли кадр в процессе передачи сигналов.

Поля DSAP, SSAP и Control предназначены примерно для того же, что и одно поле T.

DSAP - Destination Service Access Point - адрес точки входа службы назначения.

SSAP - Source Service Access Poin - адрес точки входа службы источника.

Control - управляющее поле.

OUI - Organizationally Unique Identifier - определяет идентификатор организации, которая контролирует коды протоколов в поле T.

Распознавание сетевым адаптером разных кадров - простая процедура.

С протоколом Ethernet остаётся один важный вопрос: откуда берутся MAC-адреса назначения для кадра? Наискосок об этом сказано в разборе OSI, рассмотрим это чуть подробнее.

3.8. ARP - канальный уровень

3.8.1. Введение в ARP

ARP - Address Resolution Protocol - по известному IP-адресу устройства определяется его MAC-адрес.Описание протокола было опубликовано в ноябре 1982 года в RFC 826.

ARP нужен только для IPv4-сетей. В сетях IPv6 используется протокол ICMPv6.

Когда клиент создаёт например http-запрос, он уже благодаря сетевой технологии DHCP знает IP-адрес приоритетного маршрутизатора, и соответственно через ARP-протокол будет искать его. Это как пример сценария использования ARP-протокола.

Разберём структуру пакета ARP

3.8.2. Принцип работы и пакет ARP

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

Широковещательный запрос тоже имеет MAC-адрес: FF:FF:FF:FF:FF:FF. Запрос имеет следующую структуру:

Структура запроса пакета ARP. Иллюстрация: Википедия

HTYPE - тип канальной среды для передачи данных. Для Ethernet - IEEE 802.3 (оптоволокно/витая пара/коаксиальный кабель) это 0x0001, для Wi-Fi (IEEE 802.11) - это 0x0002.

PTYPE - идентификатор протокола сетевого уровня. Для IPv4 это 0x0800.

HLEN - длина идентификатора канальной среды.

PLEN - то же самое для сетевой среды.

OPER - id операции. Для запроса - 1, для ответа - 2; есть и другие операции.

SHA - MAC-адрес отправителя.

THA - MAC-адрес получателя. В запросе это нули, в ответе - конкретное значение, ради которого и создан запрос.

THA - IP-адрес получателя.

Отправитель ARP-запроса считывает поле THA из ответа и MAC-адрес требуемого устройства.

На этом с разбором основных протоколов модели Internet всё.

4. Итоги

В этой публикации я разобрал модель Internet и модель OSI. Начал я разбираться в конце ноября 2024 г., а заканчиваю 4 января 2025 г. Параллельно практиковал Go и Docker.

Для меня важно, что я разобрался в основах и начал понимать лучше, как устроена сеть и что существуют протоколы, которые определяют MAC-адрес устройства по IP-адресу; что такое MAC-адрес; что из Go можно обратиться к низкоуровневым протоколам типа TCP. Что при реализации клиентского приложения, которое общается с сетью через HTTP, нужно предусматривать обращение к DNS, и что такое вообще DNS помимо магазина электроники. Что это за OSI такая, о которой периодически слышал и думал, что это что-то из разряда вон.

Благодарю, что дочитали эту публикацию до конца. Это моя первая публикация в 2025 г. Успехов вам, счастья, и заветного оффера. Будем на связи.

https://ru.freepik.com/free-photo/asian-fisherman-friend-use-boat-fishing-net-fishing-river-early-morning-copy-space_22818359.htm

Бро, ты уже здесь? 👉 Подпишись на канал для начинающих IT-специалистов «Войти в IT» в Telegram, будем изучать IT вместе 👨‍💻👩‍💻👨‍💻