Последнее обновление:
О протоколах передачи данных по сети
Для передачи данных по сети используется ряд протоколов. Наиболее известные из них входят в состав стека TCP/IP. Протоколы принято делить на «уровни», в зависимости от характера выполняемых ими задач.
Примечание. Строго говоря, задачи выполняют не сами протоколы, а соответствующие программы. Протоколы же представляют собой всего-навсего форматы представления данных того или иного уровня. А программы, выполняющие обработку (синтаксический анализ) данных в соответствии с уровнем, должны осуществлять ее в соответствии с правилами протокола этого уровня.
Существует модель OSI (Open System Interface или модель открытых систем), содержащая 7 уровней протоколов:
Несмотря на, казалось бы, избитость этой темы, все же, некоторые моменты изложены в книгах, интернетных ресурсах как-то туманно. Мы в этой статье постараемся немного прояснить ситуацию.
Модель OSI является семиуровневой. Однако, зачастую, на практике используются не все семь уровней, а меньше. Например, как правило, протоколы сеансового и представительского уровня, в силу небольшого объема выполняемых задач, объединяются с транспортным или прикладным уровнями. Поэтому, фактически, на практике используется 3…5 уровней протоколов.
Что часто интересует программиста, занимающегося сетевыми технологиями?
Надо сказать, что сетевые технологии в настоящее время, на самом деле, уже давно разделились, как минимум, на три отдельных, не особенно сильно пересекающихся, очень условных области:
Как правило (но, не всегда), специалисты, работающие в одной из трех областей, мало пересекаются друг с другом. Чему способствует, конечно, и широкое распространение в настоящее время различных прикладных библиотек. Поэтому, скажем, в 95% случаев Web-разработчики избавлены от «низкоуровневых раздумий» о том, какие детали, как работают транспортные, сетевые протоколы. И в этом плане им совершенно неинтересны языки С/С++, не говоря уже об Ассемблере. Тогда как разработчики физических сетевых устройств (сетевых карт, роутеров, модемов), а также программного обеспечения (драйверов) к ним, как правило, не беспокоятся о том, по каким высокоуровневым протоколам будет происходить соединение этих устройств друг с другом. Как раз для них актуален Ассемблер, отчасти С и некоторые другие низкоуровневые языки.
Разработчики «среднего уровня» - это те, кого интересуют программные среды, в которых будут функционировать и использоваться web-страницы. К ним относятся, в частности, браузеры и серверы. Речь идет, например, о таких серверах, как Apache, Ngnix и др. Что касается, браузеров, их перечень, видимо, не нуждается в разъяснении. Кроме того, на этом же уровне осуществляется настройка, физическое конфигурирование сетей (хотя, все то, что связано с администрированием сетей, как правило, не относится к области программирования).
Такое вот разделение обязанностей обусловлено тем, что работа осуществляется на соответствующих уровнях протоколов, где применяются свои методы, технологии и языки программирования. Существует, конечно, узкая «прослойка» программистов – мастеров на все руки, которые способны создавать программные коды и на Ассемблере (могут выполнить или подредактировать драйвер сетевого модема), а также вполне способны создать современный сайт (или иное клиент-серверное приложение). Но, таких широких специалистов, плюс к тому, детально разбирающихся во всех этих вопросах, на сегодняшний день не так уж и много. Ибо каждый для себя выбирает ту или иную нишу и уже работает там. Здесь в статье мы попробуем сделать обзор преемственности сетевых технологий, начиная с «самого малого».
Физический уровень
На этом уровне программист имеет дело непосредственно с настройкой работы сетевого устройства. Программа, которую он делает, будет называться драйвером (низко- или высокоуровневым). Программист имеет дело с электрическими сигналами (характеризующими логические 0 или 1) и, соответственно, их указанными битовыми представлениями. Задача программиста при считывании данных с сетевого устройства – правильным образом обработать поступающие от него электрические сигналы, преобразовать их в биты (если такое преобразование еще не было выполнено, например, контроллером устройства), организовать их передачу по сети и прием адресатом. Никаких сообщений, тем более, файлов на этом уровне нет, разработчик и не думает об этом. Он, конечно, может принимать во внимание, что впоследствии биты, с которыми имеет дело сетевое устройство, будут формироваться в байты, а последние будут входить в состав файлов, строковых сообщений и др. Однако, это – лишь для того, чтобы, быть может, сделать оптимальную конфигурацию сетевого устройства. Например, учитывая оптимальный размер блоков оперативной памяти, он может разработать такой контроллер устройства, который будет иметь объем памяти, кратный степени 2, например, 1024 байта.
Так как этот уровень имеет дело с электрическими сигналами в виде битов, соответственно, их источником и адресатом являются соответствующие физические сетевые устройства (например, модемы и/или сетевые карты). Эти физические устройства могут быть связаны друг с другом посредством той или иной среды передачи – USB-кабель, оптоволокно, радиоканал и т.п. На физическом уровне вообще не идет речи об IP-адресах, доменах, URL и т.п. Эти абстракции появляются на более высоких уровнях модели OSI.
Здесь играет роль правильность составления кадра из битов, для чего используются различные способы низкоуровневого или физического кодирования: манчестерский код, дифференциальное, потенциальное кодирование, NRZ, БВН и многие другие способы. Физическое кодирование осуществляется в рамках соответствующих стандартов, например, IEEE 802.3.
Для чего используется физическое кодирование? Для того, чтобы как-то подстраховать сетевую передачу битов (в составе кадра) от ошибок. Вследствие заторов в сети, а также ее возможной неисправности, наличия помех, не все биты кадра могут дойти до адресата. Предположим, клиент (источник) передал в сеть следующие биты:
11011000011011
Если все будет хорошо, то эти и именно эти биты должен бы принять приемник (сервер), находящийся на другом конце сетевого соединения. Но, зачастую, практика вносит свои коррективы. Например, вместо указанной последовательности битов может прийти:
11011000010011
Некоторые биты могут попросту затеряться, а некоторые – добавиться дополнительно взамен потерянных. В итоге - серверу придет не тот кадр, который был отправлен клиентом (источником). Так вот, физическое кодирование и служит для того, чтобы если не полностью избавиться от ошибок передачи кадров битов, то, по крайней мере, свести такие ошибки к минимуму. Если в процессе передачи возникла ошибка (по крайней мере, один бит передан неверно), то передачу кадра, содержащего этот бит, придется повторять – до тех пор, пока не будет передан правильный кадр или до тех пор, пока сетевое соединение не будет прервано.
Канальный уровень
На этом уровне происходит контроль правильности составления кадров (фреймов). Типичный размер фрейма – 1 кБ. При разработке стеков протоколов на канальном уровне осуществляется помехоустойчивое кодирование. К таким способам кодирования относится код Хемминга, блочное кодирование, код Рида-Соломона. В программировании этот уровень представляет драйвер сетевой платы, в операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровней между собой. Это не новый уровень, а просто реализация модели для конкретной операционной системы. Здесь, как и на физическом уровне, также пока нет ни байтов, ни файлов, ни т.п.
Однако, средств контроля правильности кадров, предоставляемых канальным уровнем, не застраховывает ото всех ошибок передачи. Поэтому дополнительные средства контроля используются в сетевых передачах на более вышележащем (транспортном) уровне. Только канального уровня для контроля правильности сетевой передачи недостаточно.
Взаимодействие на канальном уровне осуществляется, также как и на физическом, естественно, между физическими устройствами. Однако, для адресации используются так называемые МАС-адреса (аппаратные адреса). Они имеют следующий примерный вид (в шестнадцатеричном представлении):
52:f4:da:32:5c:77
Каждый компьютер в сети интернет имеет СВОЙ уникальный аппаратный адрес. МАС-адрес источника и адресата входят в состав кадра, формирующегося на канальном уровне. Отметим, что и здесь никаких IP-адресов, доменных имен и др. нет в помине. Речь идет просто о передаче битовых кадров от сетевого устройства с одним МАС-адресом другому устройству (с другим MAC-адресом). Именно так работает современный интернет в подавляющем большинстве случаев.
Следует иметь в виду, что сервер (компьютер-адресат), получая пакеты от клиента (например, от браузера), естественно, получает и МАС-адрес компьютера, на котором запущен... браузер. Так же, как и его IP-адрес. И если IP-адрес несложно подменить, например, путем соединения с сервером-адресатом через прокси-сервер, то подмена МАС-адреса представляет собой куда более сложное занятие. Ранние версии операционных систем Linux, как правило, позволяли делать такую подмену на пользовательском уровне. Тогда как современные версии это запрещают (надеемся, понятно, почему). Впрочем, конечно, никто никому не мешает заново собрать и перекомпилировать ядро операционной системы, в котором уже предусмотреть такую замену. Однако, сделать это способен далеко не каждый программист. Или же можно использовать такой прокси-сервер, который будет парсить заголовки протоколов канального уровня и записывать в них какой-нибудь другой МАС-адрес.
Поэтому КАЖДЫЙ, кто выходит в интернет со своего компьютера, на котором установлена стандартная операционная система, типа Windows, Linux, MacOS, Android и т.п., неважно, через прокси-сервер или напрямую, должен ясно понимать, что МАС-адрес его компьютера может быть известен серверу-адресату. Если только, повторимся, он не использует такой прокси-сервер, который способен сделать подмену МАС-адреса. В общем же случае ЛЮБОЙ сервер способен точно идентифицировать пользователя - именно по его MAC-адресу. Кстати, этот аргумент когда-нибудь вполне сможет использовать Раскомнадзор, если ему будет дана команда - заблокировать интернет. Тут же в СМИ возникнут статьи на тему: "А Вы знаете, что любой сервер знает о ВАС ВСЁ?". Вот, мол, Раскомнадзор стал настолько заботлив о пользователях интернета, что решил защитить их от него. Причем, отметим, что Яндекс- и Google-метрики - это сущий пустяк по сравнению с этим. Ни Google, ни Яндекс не собирают информацию о МАС-адресах посетителей сайтов. Ну, по крайней мере, с их слов.
Может возникнуть вопрос: а куда же делись HTTP-запросы (GET, POST), заголовки HTTP(S)-протоколов и многое другое, столь известное веб-разработчикам? Ответ: вся эта информация как раз и содержится в этих самых кадрах (в виде определенных последовательностей битов), путешествующим по сети от устройства с одним МАС-адресом к другому. Ниже, на схемах мы увидим область, в которой хранятся эти данные.
Сетевой уровень
На этом уровне протоколов появляется такая сетевая абстракция, как IP-адрес узла сети. Придумана она исключительно для того, чтобы компьютерам (точнее, пользователям компьютеров) проще было взаимодействовать друг с другом. Чтобы на основе IP-адресов можно было выделять классы сетей, осуществлять защиту от доступа и т.п. Хотя, повторимся, все это вполне можно было бы осуществить, используя исключительно МАС-адреса, не пользуясь технологией IP-адресов.
Раньше, когда интернет еще не был развит столь существенно, как сегодня, на каждом компьютере, подключенном к сети, хранились специальные файлы, содержащие соответствия MAC-адресов узлов сети их IP-адресам. В настоящее время такая информация хранится централизованно, на специальных серверах DNS. Если узел сети (источник) желает отправить сообщение на какой-либо IP-адрес, он вначале, при помощи протокола ARP, отсылает в сеть широковещательный запрос типа «какой из узлов имеет такой-то IP-адрес». Если такой узел в сети находится, источнику отсылается ответное сообщение, в котором фигурирует искомый MAC-адрес компьютера с указанным в запросе IP-адресом. Этот полученный МАС-адрес используется протоколами канального уровня (см. выше) для организации сетевого соединения.
Т.е. еще раз следует подчеркнуть: фактически, связь осуществляется на основе МАС-адресов. Тогда как IP-адреса используются больше для организации сетевого взаимодействия, понятного не только для компьютеров, но и для людей.
Транспортный уровень
Он используется для обеспечения доставки сообщений между узлами сети. Как уже говорилось, именно на этом уровне происходит контроль правильности получаемых данных - в случае, если используется протокол ТСР (имеется в виду стек TCP/IP). Тогда как при использовании протокола UDP практически никакого контроля не осуществляется; в таком случае транспортный уровень не играет своей основной роли: ведь, по сути-то, передача данных производится на канальном уровне.
На транспортном уровне появляется также такое понятие, как порт (точнее, логический порт). Которого не существовало на нижележащих уровнях. Порт в данном случае – это просто некое целое число из определенного диапазона значений, при помощи которого (а также при помощи IP-адреса узла) происходит адресация между узлами в сетевых соединениях. Наличие конкретного порта, а также IP-адреса – необходимо и достаточно для того, чтобы однозначно адресовать сетевой интерфейс и, соответственно, запрос к нему. Открытый порт на конкретном узле сети соответствует сокету, который находится в режиме прослушивания или, наоборот, приема сетевых запросов.
Впрочем, стоит отметить, что, на самом-то деле (на низком уровне), адресация все равно происходит при помощи МАС-адресов сетевых узлов и ТОЛЬКО при помощи них. Но, в силу удобства для пользователей компьютеров, да и разработчиков сетевых приложений, этими низкоуровневыми деталями пользоваться необязательно; проще, удобнее и нагляднее использовать порты (сокетов) и IP-адреса. Существуют немало решений, в которых используются не порты, а другие, на первый взгляд, технологии (например, службы RPC, PAP и др.). Однако, опять-таки, на «низком» уровне все сводится к портам и сокетам, которые открыты по этим портам. А на еще более низком уровне происходит преобразование IP-адреса и порта – в МАС-адрес.
В сообщении транспортного уровня фигурируют уже байты, точнее, дейтаграммы (в случае UDP-соединения) или потоки байт (для TCP). Если сетевая передача передает данные, закодированные с использованием однобайтовой кодировки (например, СР1251), то, по сути, можно говорить о передаваемых символах. Если же кодировка многобайтовая (например, UTF-8, UTF-16), то для того, чтобы из совокупности байт выделить символы (строки символов), необходимо делать соответствующее преобразование, которым, по идее, должен бы заниматься представительский уровень протоколов. Однако, как уже говорилось выше, он редко выделяется отдельно, поэтому такое преобразование выполняется уже на прикладном уровне, например, в соответствии со стандартом протокола НТТР, для чего применяется соответствующий заголовок этого протокола, обозначающий кодировку.
Итак, на транспортном уровне для облегчения управления взаимодействием узлов сети добавляется порт сокета, открытого на прием или передачу данных.
Прикладной уровень
На этом уровне делается вся остальная работа. А именно – принятые строки байт (символов) анализируются и адресат, получивший сообщение, начинает что-то делать, решать определенную задачу – в зависимости от того, какая информация содержится в поступившем к нему сообщении. Например, может идти речь о поиске какого-либо файла на компьютере-сервере для последующего его открытия, обработки (опять-таки, в соответствии с информацией, содержащейся в сообщении) и передаче его, через сетевое соединение, браузеру. На прикладном уровне появляются, наконец, доменные имена (например, site.ru), появляются заголовки НТТР-протоколов, GET-, POST-запросы и др. Соответствие доменных имен их IP-адресам содержится в централизованной системе DNS, находящейся где-то на серверах в интернете.
В общем, дело обстоит следующим образом:
Клиент (например, браузер) начинает открывать страницу, URL которой введен, к примеру, в его адресной строке. Для начала, браузер будет делать запрос в сеть на предмет того – какому IP-адресу соответствует сервер с доменными именем, содержащимся в открываемом URL. Далее, делается запрос (см. выше) о том, каков МАС-адрес узла сети, соответствующий этому IP-адресу. И только после этого, когда браузер получает в свое распоряжение MAC-адрес искомого узла, он и может выполнить запрос к нему.
Строго говоря, описание сетевого взаимодействия немного упрощено и не учитывает, например, прохождение запроса в локальных сетях, роутерах, маршрутизаторах.
После этого, HTTP-запрос, который собирается делать браузер, кодируется требуемым образом, разбивается на пакеты или дейтаграммы (в зависимости от того, какой транспортный протокол используется), а эти пакеты, в свою очередь, разделяются на кадры битов, которые и отправляются через сетевое соединение, используя физические возможности сетевого устройства, на выявленный МАС-адрес. При этом типичную схему передачи сетевого запроса можно было бы изобразить в следующем виде:
Как видно, на каждом из уровней протоколов существует «свое» средство адресации. Соответственно, и данные оформляются по-разному.
Инкапсуляция протоколов
Теперь мы добрались, наконец, до инкапсуляции протоколов. Протокол каждого уровня, как уже говорилось, выполняет свою задачу. Начиная с протокола прикладного уровня (например, НТТР), запрос в виде строки байт преобразуется в один или (при необходимости) несколько пакетов байт, которые затем преобразуются в битовые кадры и уже в таком виде (бит за битом) передаются в сеть. Выясним, в каком порядке расположены данные в кадрах. Ниже приведена структура кадра сообщения в формате протокола канального уровня:
Флаги нужны для распознавания кадра, адреса точек входа содержат, соответственно, МАС-адреса интерфейсов источника (клиента) и назначения (сервера). А в поле «Данные» и содержится, в том числе, и полезная информация, которая передается в сеть – например, страница веб-сайта. В каком же виде она там присутствует?
Если говорить о структуре сообщений любого сетевого протокола (не только канального уровня), можно выделить две основные области:
- Заголовок и
- Данные
Заголовок содержит управляющие параметры (свои для конкретного протокола), а данные – это полезная нагрузка (информация, сформированная в соответствии с правилами того или иного протокола), которая передается сообщением (запросом клиента или ответом сервера) через сеть.
В связи с этим предлагаем взглянуть на схему инкапсуляции протоколов:
Wi-Fi -> IEEE802.11 -> IP -> TCP -> HTTP
или, отображая в виде рисунка:
Для большей полноты изображения, покажем место IPv4-протокола в кадре канального протокола:
Если данные, содержащиеся в поле данных протокола IPv4, имеют достаточно большой размер (нередко так и бывает, когда по сети передаются большие объемы информации), тогда формируются не один, а несколько кадров в формате канального протокола.
Таким образом, сетевые протоколы являются, по сути, вложенными (инкапсулированными) друг в друга. Каждый i-й протокол имеет свое поле данных, в которое помещается вначале заголовок следующего (i+1 -го) протокола, а затем его данные. Иначе говоря, поле данных предыдущего (более низкоуровневого) протокола содержит заголовок следующего (более высокоуровневого) протокола и его данные, которые, в свою очередь… содержат заголовок и данные еще более высокоуровневого протокола и т.д. Именно в таком виде производится формирование сетевого сообщения перед его отправкой по тому или иному каналу связи от одного узла (интерфейса) сети к другому. Т.е. кадр, по сути, выполнен в виде «матрешки» (если не вдаваться в некоторые несущественные детали). Кадр содержит в себе всю информацию, необходимую для его «путешествия» по сети и получения узлом назначения и последующей идентификации. В нем есть информация о МАС-адресе, порте открытого сокета, IP-адресе, а также большое количество управляющей информации (флаги, иные параметры управления).
После получения кадра узлом назначения (адресатом или сервером) последний начинает обратный процесс. Вначале считывается кадр, из него извлекаются его данные. В итоге из них, в свою очередь, извлекаются данные, относящиеся к НТТР-сообщению, а они уже передаются программе-серверу, например, Apache. Последний проводит синтаксический анализ этих данных, идентифицирует URL запроса, извлекает заголовки и, при наличии, тело сообщения. Наконец, сервер начинает выполнять определенную работу, руководствуясь, в частности, правилами НТТР-протокола и извлеченной из полученных кадров информацией. Например, это может быть открытие определенного файла на сайте, обработка его и посылка, в виде вебстраницы, источнику запроса. Перед этим сервер, конечно же, упакует вебстраницу по аналогичному алгоритму, создавая один или несколько битовых кадров и начнет передавать их в сеть источнику запроса.
И, все-таки, где же данные HTTP(S) протокола?
Выше уже говорилось о том, что данные HTTP(S) протокола представляют собой не что иное, как просто набор параметров, передаваемых в виде сообщения протокола транспортного уровня (ТСР или UDP). Причем, синтаксис этого набора параметров выполнен (точнее, должен быть выполнен) по правилам, определяемыми стандартами для соответствующей версии протокола HTTP(S). На схемах выше эти данные отображены красным цветом (данные ТСР-протокола). Иными словами, данные HTTP(S)-протокола (представляющие собой НТТР-заголовки + html-код страницы + рисунки + JS-скрипты + ...) - это всего-навсего строка байт, передаваемых на основе ТСР/UDP протокола. Маршрутизация при передаче осуществляется при помощи IP-протокола, а сама передача технически осуществляется на основе протоколов канального уровня.