Недавно у меня вышла статья «Суверенный российский протокол на замену TCP/IP? Путин одобряэ!», в которой я рассказал, что некая компания (ГК ООО «Техноджет») предложила свою замену набору протоколов TCP/IP в области цифровой связи с беспилотниками, которая усиливает кибербезопасность цифровых каналов связи (кибербезопасность — не в обобщённом смысле этого слова, а исключительно на своём уровне применительно к передаче пакетов) а также улучшает скоростные характеристики цифрового канала передачи данных, в частности, за счёт некоторого изменения алгоритмов работы их нового протокола по отношению к протоколу TCP.
Раз уж зашла тема про цифровую передачу данных, то сегодня я хочу чуть подробнее коснуться её основы — протоколов связи. Постараюсь дать популярное понимание того, что из себя представляет самая распространённая среда цифровой связи на основе протоколов TCP/IP, принятая основной в Интернете. Думаю, это поможет лучше понять, замену чему готовит ГК ООО «Техноджет».
Физический и канальный уровни
Итак, начнём с самого интересного — снизу! :-) Чтобы передать цифровую информацию по сети, её надо как-то закодировать физически для передачи через определённую физическую среду.
Кодирование происходит разными методами в зависимости от свойств самой физической среды, через которую предполагается передавать цифровой сигнал (электрическими импульсами через медный кабель, световыми импульсами через оптоволокно или электромагнитными волнами через пространство).
Кодирование происходит для каждой среды по определённым правилам. Этот уровень сети больше относится к «железу», и программистам он обычно неинтересен. В классической модели сетевых уровней TCP/IP этот физический уровень просто объединили с программным уровнем — канальным, назвав всё это просто канальным уровнем (или уровнем сетевых интерфейсов).
Однако, надо понимать, что различий между физическим и канальным (логическим) уровнем больше, чем между всеми остальными логическими уровнями, которые мы рассмотрим позже. Всё же одно дело — логическая среда, а другое дело — физическая. Совсем разные вещи.
Итак, для программиста физический уровень зачастую является чёрным ящиком. Он зашит в сетевые карты, wi-fi-передатчики и т.п. Наружу физический уровень торчит только цифровыми интерфейсами физических устройств связи и, в частности, физическими адресами этих устройств, т.н. MAC-адресами, которые уникальны для каждого сетевого устройства. Через эти интерфейсы этими сетевыми устройствами управляет логический, программный уровень. Делается это по определённым правилам, описанным протоколом Ethernet.
Протокол Ethernet действует внутри одного сегмента сети, формируя и передавая между устройствами этого сегмента готовые кадры данных (фреймы), не вникая в их содержимое. Задача канального уровня — забрать пакет с вышестоящего уровня (сетевого), заключить его в кадр (фрейм) вместе с MAC-адресом сетевого устройства адресата и спустить на физическую часть уровня, где этот кадр будет просто передан в сеть побитово и принят только тем устройством, MAC-адрес которого совпадёт с MAC-адресом назначения, указанном канальным уровнем в кадре.
Дальше сегмента сети, выше за маршрутизатор, кадр не пойдёт, ибо MAC-адреса видны только в рамках одного сегмента сети. Для адресации в масштабах всей сети используется IP-адреса, а ими оперируют уже на более высоком уровне — сетевом.
Сетевой уровень
Сетевой уровень называют ещё межсетевым, потому что он позволяет адресовать пакеты между различными сетями (сегментами глобальной сети). На сетевой уровень, работающий по протоколу IP, пакеты приходят с транспортного уровня (TCP). Сетевой уровень отвечает только за адресацию и передачу пакета. За доставку пакета этот уровень не отвечает. Что называется, отправил, и забыл. Функционал контроля доставки пакетов возложен на более высокий транспортный уровень, но о нём позже.
Сетевой уровень получает IP-пакет, и определяет его дальнейший маршрут в виде IP-адреса следующего маршрутизатора. Затем он запрашивает его MAC-адрес, и передаёт этот адрес вместе с пакетом на канальный уровень, где тот упаковывается в кадр уже с MAC-адресом, и передаётся по этому MAC-адресу на конкретный сетевой интерфейс маршрутизатора, как я об этом писал в предыдущей главе.
Затем новый маршрутизатор на канальном уровне распаковывает кадр, определяет IP следующего маршрутизатора для доставки пакета, запрашивает его MAC-адрес, опять передаёт этот адрес вместе с пакетом на канальный уровень, и так далее, пока пакет не попадёт к адресату... или не потеряется где-нибудь по дороге.
А вот за то, что делать, если пакет потерялся, отвечает уже следующий, транспортный уровень.
Транспортный уровень
Этот уровень манипулирует IP-пакетами сетевого уровня, проверяя их доставку, отправляя потерянные пакеты повторно, а при получении пакетов устраняет дубликаты и выстраивает их в правильной последовательности. Правила манипулирования пакетами определяются протоколом транспортного уровня TCP (или UDP).
Пожалуй, это самый ответственный уровень, отвечающий за надёжность связи. Собственно, он и реализует готовое рабочее соединение, которое могут использовать уже более высокоуровневые протоколы прикладного уровня, такие, как, например, HTTP или FTP.
Сетевой и транспортный уровни можно было бы, наверное, функционально рассматривать и как один, просто транспортный уровень. Оба уровня всегда работают в плотной связке и их работа чаще всего описывается протоколами TCP и IP, принадлежащими этим уровням.
Из-за этой плотной связи протоколов и центральному месту этих уровней в технологии передачи данных, этим же именем (TCP/IP) названа и вся иерархическая модель протоколов, иначе называемая стеком протоколов:
Стек протоколов — это иерархический набор протоколов, через которые проходят данные сверху вниз перед их передачей адресату, или в обратном порядке при их получении.
Прикладной уровень
Этот уровень просто описывает способы использования рабочего сетевого соединения, организованного протоколом TCP. Например, протоколы HTTP и HTTPS описывает правила запроса и получения данных c сайтов, которыми пользуются браузеры. Протокол SMTP отвечает за отправку почты, протокол FTP — за передачу по сети файлов.
Заключение
В статье я не оговаривал все многочисленные нюансы, которые не важны для понимания сущности работы стека протоколов, поэтому у профессионалов, как обычно, могут возникнуть масса дополнений и уточнений. Я же постарался избежать лишнего перегруза — всё-таки текст писался больше, как популярный, нежели как учебный.
На этом всё. Ставьте нравлики, пишите свои важные дополнения в комментариях и подписывайтесь на канал. Удачи! :-)