Для чего необходимы протоколы

О протоколах передачи данных

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

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

Какими свойствами и особенностями обладает хороший, годный грамотный, качественный протокол?

В идеале, протокол должен быть абстрагирован от более нижнего уровня взаимодействия, будь то передача по TCP, UDP, по serial порту, USB, Bluetooth, через цифровой радиосигнал, или даже по голубиной почте. И надо учитывать, что далеко не все из них гарантируют доставку и\или достоверность передающихся данных.

Небольшой дисклеймер: говоря о достоверности данных, я имею ввиду их неискаженность вследствие помех и иных ошибок в среде передачи. В статье я не буду затрагивать темы пласта технологий, связанных с безопасностью в ИТ. Допустим что наши Алиса и Боб могут друг другу доверять, и никакая Ева им помешать не может. (Например у коллег вопрос безопасности решается включением всех территориально разделенных участников взаимодействия в хорошо защищенный VPN, не имеющий в свою очередь доступа наружу)

В большинстве протоколов реализована схема «Вопрос-Ответ». Это можно представить как разговор, в котором на каждую реплику своего собеседника вы реагируете вербально, и в том же смысловом ключе. Таким образом участниками взаимодействия достигается уверенность в том, что их сообщения переданы и адекватно восприняты. Однако эта схема допустима и эффективна не для всех задач: в случаях когда задержка в общении должна быть минимизирована, или ответ на каждую из многочисленных реплик признается избыточным (например для отладочных сообщений), реализуется схема «Старт-Стоп». При получении сообщения на «Старт» ваш собеседник начинает сыпать в вас потоком реплик, и замолкает лишь при слове «Стоп». Сообщения, отправляемые в потоке, обычно имеют инкрементируемый порядковый номер, и если при принятии потока сообщений были проблемы с обработкой\было пропущено одно из них, его можно перезапросить отдельно по этому самому номеру.

Все протоколы можно разделить на две группы, (по представлению данных): символьные и бинарные.
Символьные протоколы, с которыми мне приходилось встречаться, базировались либо на XML, либо на JSON-строках. Из их достоинств можно упомянуть о более простой отладке взаимодействия (вследствие их читаемости), о простоте реализации (наличия готовых парсеров), и пресловутой универсальности.
Теперь о недостатках. Очевидно, что такие протоколы являются крайне избыточными, мизерная доля полезной информации плавает в массивной, неэффективной обёртке. При передаче любой числовой информации приходиться заниматься их конвертацией в строковое представление и обратно. Больным местом является передача бинарных данных (и хорошо, что без них бывает можно обойтись, но в ряде случаев это невозможно). Составители протоколов обычно выкручиваются применением Base64, или даже просто передачей бинарной строки в её hex-овом представлении, по два символа на байт.
Также хочется отметить, что полная спецификация того же XML крайне обширна, и стандартные парсеры, при всей их полноте возможностей, достаточно громоздки и медлительны, поэтому распространена практика, когда отдел или контора в итоге пишет и пользуется собственным парсером.

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

Теперь бинарные протоколы. Сразу же надо вспомнить о Гулливерских войнах тупоконечников и остроконечников. Лично я симпатизирую big-endian, т.к. не считаю неявную типизацию little-endian «чем-то хорошим», да и в моей среде разработки big-endian является нативным.
Бинарные протоколы (не все, но те, которые я отношу к грамотным) можно разделить на два уровня: уровень контейнера и уровень данных. На плечи первого уровня ложится ответственность за целостность и достоверность передачи данных, а так же за доступность обнаружения сообщения в байтовом потоке, и, само собой, за хранение в себе сообщения уровня данных. Второй уровень должен содержать информацию, ради которой всё сетевое взаимодействие и затевалось, в удобном для обработки формате. Его структура в основном зависит от решаемых задач, но и по нему есть общие рекомендации (о которых ниже).

Размеры сообщений (дискретных пакетов байт, которые можно обрабатывать независимо от предыдущих и последующих принимаемых данных) бывают фиксированными и переменными. Понятно, что с фиксированным размером сообщений всё проще — вычитается, начиная с заголовка (о нём позже), определенное количество байт и отправляется на обработку. Зачастую, для обеспечения гибкости, составители таких протоколов включают в сообщение область фиксированного размера (иногда до 80% от общего объема), зарезервированное под модификации нынешнего протокола. На мой взгляд, это не самый эффективный путь обеспечения гибкости, зато избыточность появляется еще какая.
Рассмотрим сообщения переменной длины.
Тут уже можно подробней поговорить о непременном атрибуте бинарного сообщения в любом протоколе — о заголовке (Это вышеупомянутый уровень контейнера).
Обычно заголовки начинаются с константной части, позволяющей, с определенной вероятностью обнаружить начало сообщения в непрерывном байтовом потоке. Очевидно, что имеется риск появления такой константы в произвольном потоке байт, и, хотя увеличение объема этот риск снижает (я встречал константы вида 0123456789VASIA9876543210), целесообразней использовать проверки на основе подсчета контрольной суммы.
За константой обычно следует номер версии протокола, который дает нам понять, в каком формате должно происходить дальнейшее считывание (и имеем ли мы вообще возможность обработать это сообщение — вдруг такая версия нам неизвестна). Следующая важная часть заголовка: информация о самом содержимом контейнера. Указывается тип содержимого (по факту, тот же номер версии протокола для уровня данных), его длина и контрольная сумма. Имея эту информацию, можно уже без проблем и опасений считать содержимое и приступить к его разбору.
Но не прямо сразу! Заголовок должна заключать контрольная сумма его самого (исключая из расчета конечно саму контрольную сумму) — только так мы можем быть уверены в том, что считали только что не белиберду, а валидный заголовок, за которым следуют предназначенные нам данные. Не совпала контрольная сумма? Придётся искать следующее начало нового заголовка дальше по потоку…

Представим, что мы дошли до этапа, что получили наконец неискаженное сообщение уровня данных. Его структура зависит от той области задач той системы, в которой реализован ваш сетевой обмен, однако в общем виде у сообщения тоже бывает быть свой заголовочек, содержащий информацию о типе сообщения. Можно различить как общую специфику сообщения, (например «Запрос Set», «Утвердительный Ответ на Set», «Отрицательный Ответ на Set», «Запрос Get», «Ответ Get», «Потоковое сообщение»), так и конкретную область применение сообщения. Попробую привести пример с потолка:
Тип запроса: Запрос Set (0x01)
Идентификатор модуля-адресата сообщения: PowerSupplyModule (0x0A)
Идентификатор группы сообщений: UPS Management (0x02)
Идентификатор типа сообщения: Reboot (0x01)
Дальше тело сообщения может содержать информацию об адресе ИБП, который Модуль управления энергообеспечением должен перезагрузить, через сколько секунд это сделать и т.п.
На это сообщение мы рассчитываем получить ответное сообщение с типом запроса «Утвердительный Ответ» и последующими 0x0A0201 в заголовке.
Конечно, такое подробное описание типа сообщения может быть избыточным когда межсетевое взаимодействие не предусматривает большого числа команд, так что формировать структуру сообщения надо исходя из требований ТЗ.
Так же будет полезно, если сообщение с «Отрицательным Ответом» будет содержать код ошибки, из-за которой не удалось ответить на команду утвердительно.

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

upd.
Имел удовольствие пообщаться с критиком своей статьи, и теперь прихожу к осознанию, что я осветил вопрос со своей если можно так выразиться, «байтолюбской», точки зрения. Конечно, раз идет курс на универсальность обработки хранения и передачи данных, то в таком ключе символьные протоколы (в первую очередь говорю об XML) могут дать фору любым другим решениям. Но относительно попытки повсеместного их применения позволю себе процитировать Вирта:
Инструмент должен соответствовать задаче. Если инструмент не соответствует задаче, нужно придумать новый, который бы ей соответствовал, а не пытаться приспособить уже имеющийся.

Источник

Протоколы передачи данных

Протоколы передачи данных

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

Содержание

Сетевой протокол

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

Разные протоколы зачастую описывают лишь разные стороны одного типа связи; взятые вместе, они образуют стек протоколов. Названия «протокол» и «стек протоколов» также указывают на программное обеспечение, которым реализуется протокол.

Новые протоколы для Интернета определяются IETF, а прочие протоколы — IEEE или ISO. ITU-T занимается телекоммуникационными протоколами и форматами.

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

Общие сведения

Сетевые протоколы предписывают правила работы компьютерам, которые подключены к сети. Они строятся по многоуровневому принципу. Протокол некоторого уровня определяет одно из технических правил связи. В настоящее время для сетевых протоколов используется модель OSI (Open System Interconnection — Взаимодействие Открытых Систем, ВОС).

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

Протоколы

Протокол TCP/IP — это два протокола нижнего уровня, являющиеся основой связи в сети Интернет. Протокол TCP (Transmission Control Protocol) разбивает передаваемую информацию на порции и нумерует все порции. С помощью протокола IP (Internet Protocol) все части передаются получателю. Далее с помощью протокола TCP проверяется, все ли части получены. При получении всех порций TCP располагает их в нужном порядке и собирает в единое целое.

Наиболее известные протоколы, используемые в сети Интернет:

Источник

Зачем компьютерам протоколы?

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

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

Компьютерные протоколы помогают зафиксировать:

какие данные и в каком формате передаются;

алгоритм действий на каждом этапе обмена информацией.

Что еще нужно помнить о протоколах

Каждый протокол определяет правила выполнения конкретных задач. К примеру, HTTP (Hyper Text Transfer Protocol) дает возможность просматривать веб-страницы и файлы в интернете, а SSH (secure shell) используется для защищенного удаленного доступа к ОС.

Стандарты развиваются. Раньше для передачи данных через интернет компьютеры использовали сразу несколько моделей транспортных протоколов: TCP/IP, NWLink IPX/SPX, NetBEUI. Сейчас же есть единый стандарт — TCP/IP. В нем протокол TCP (Transmission Control Protocol) отвечает за надежность соединения между компьютерами и доставки сообщений, а IP (Internet Protocol) — за поиск компьютеров в рамках сети.

Для работы с каждым протоколом предназначено свое программное обеспечение. Например, для протокола HTTP это браузер.

Источник

Что такое протокол и зачем он нужен

Что такое протокол и зачем он нужен

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

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

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

Все протоколы можно разделить на низкоуровневые и высокоуровневые.

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

Примечание

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

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

Примечание

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

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

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

Наибольшую популярность приобрели такие стеки протоколов, как NetBIOS/NetBEUI, IPX/SPX, TCP/IP, DECnet и др.

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Читайте также

Зачем нужен break flag [%] при описании policy

Зачем нужен break flag [%] при описании policy Для версий netams 3.1.xx, 3.2.xx и 3.3.xx до build 2117:Если вы задаете последовательность из нескольких политик фильтрации трафика подряд, то по умолчанию их действие суммируется, т.е. в случаеservice processorpolicy name all–ip target proto ippolicy name tcp target proto tcpunit host name HOST1 ip

1.3. Что такое Windows Product Activation, и зачем он нужен?

1.3. Что такое Windows Product Activation, и зачем он нужен? Это новая технология, разработанная Microsoft для борьбы с нелегальными копиями их программного обеспечения. Впервые подобный механизм был опробован на Terminal Service, из W2k Server, теперь же, похоже, подобным образом будут защищаться

Зачем вашей компании может быть нужен корпоративный блог?

Зачем вашей компании может быть нужен корпоративный блог? Не знают, зачем нужен корпоративный блог, всего семь человек. «Создание имиджа компании» повторяется в ответах категории «Другое» несколько раз как дополнение к влиянию на соискателей, инвесторов. Один из

Зачем нужен Интернет?

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

Зачем Windows нужен свой собственный голосовой мессенджер?

Зачем Windows нужен свой собственный голосовой мессенджер? Разработчики Windows почему-то решили, что в их операционной системе обязательно должно быть все свое, как говорится, родное. Все самые интересные компьютерные возможности: запись CD/DVD-дисков, монтаж фильмов, голосовое и

Зачем нужен Radmin

Зачем нужен Radmin Radmin — это сокращение от Remote Administrator, что дословно переводится как удаленный администратор. Да, существуют такие программы, которые позволяют нам, находясь за своим компьютером, видеть рабочий стол другого, и не только видеть, но и управлять его мышью и

7.1. Что такое бастион и зачем он нужен?

7.1. Что такое бастион и зачем он нужен? Бастион (он же брандмауэр, он же firewall) – это пакетный фильтр, позволяющий защитить ваш компьютер от действия вредоносных программ, сетевых червей, нежелательного трафика и всевозможных атак.Разберемся, как работает бастион. Данные по

1.3. Зачем нужен интернет-маркетинг

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

Зачем нужен файловый менеджер

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

26.1. Зачем нужен Web-сервер в домашней сети?

26.1. Зачем нужен Web-сервер в домашней сети? Некоторым Linux-пользователям Ubuntu не нравится: уж больно она проста. Но простота не означает примитивность, что мы и докажем в этой главе, превратив обычную рабочую станцию в сервер сети — настроим Web-сервер с поддержкой PHP, FTP-сервер и

Зачем нужен дистрибьютор, или Кому полезен кризис Леваков Владимир

Зачем нужен дистрибьютор, или Кому полезен кризис Леваков Владимир Дистрибуция воспринимается многими как достаточно «инертный» по сравнению с другими сегментами ИТ-рынка бизнес. Это не совсем так: безусловно, дистрибьютор может занимать пассивную

Глава 1 Кому и зачем нужен ноутбук

Глава 1 Кому и зачем нужен ноутбук Ответ прост: скорее всего, ноутбук нужен именно вам! Так же, как и большинству пользователей, проводящим за компьютером значительную часть времени.Сказанное требует внятной и доходчивой аргументации. Причем объяснять необходимость

Зачем нужен кулер

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

Что это такое и зачем оно вам

Что это такое и зачем оно вам У Интернета есть много различных определений, в том числе и таких, которые могут только напугать. Я предпочитаю следующее: « Интернет – это огромное хранилище информации, которая содержится на разных компьютерах по всему миру, а также способы

Источник

Сетевой протокол и видеонаблюдение

Общие сведения

Сетевой протокол – это набор правил, который позволяет обмениваться данными нескольким устройствам связанным сетью. Ни одно удалённое подключение не может обойтись без работы протоколов, без них система просто не знала бы как взаимодействовать и общаться. Если обобщать, то можно сказать что это семейство стандартов, предписывающее методы общения, а также спецификации оборудования.

Для описания и деления протоколов используется семиуровневая модель OSI (Open System Interconnection — взаимодействие открытых систем, ВОС). В этой классификации описываются все формы взаимодействия необходимые для полноценной работы оборудования:
• Приложение;
• Представление;
• Сеанс;
• Транспорт;
• Сеть;
• Передача данных;
• Физическое воплощение.

Стандраты и группы

Некоторые протоколы образуют отдельные группы, с подгруппами в которые входит ряд непосредственно протоколов. Всем известный TCP/IP включает в себя десятки протоколов разного уровня в том числе для работы оборудования, некоторые из них вы наверняка слышали: DNS, HTTPS, IPv6, POP3 и много других. Сюда же входит RTSP (Потоковый протокол реального времени (англ. real time streaming protocol, сокр. RTSP) который используется для управления потоками медиаданных, в нем включены методы play, pause, record и прочие что очень важно в видеонаблюдении, и в том числе используется в программах клиентах: Skype, Медиапроигрыватель VLC и т.д.

Технологии и альянсы

ONVIF

Из-за сложности структуры, переплетения стека технологий некоторые вещи мы называем протоколами, хотя она таковыми не являются. ONVIF – эту аббревиатуру часто можно встретить в видеорегистраторах и камерах видеонаблюдения, на самом деле не протокол. Open Network Video Interface Forum – это организация, которая занимается разработкой стандартов и протоколов для систем безопасности. Их спецификации построены на веб-сервисах, описываемых языком WSDL, протоколах RTP/RTSP, SOAP (XML), стандартах видеосжатия H.264, MPEG-4, MJPEG. Прелесть ONVIF заключается в совместимости оборудования поддерживающего этот стандарт.

ZigBee

Покупая умный дом можете встретить протокол ZigBee который описывает спецификации сетевых протоколов верхнего уровня. Эта технология отличается поддержкой высокого уровня безопасности передачи данных в сочетании с невысокими скоростями и возможностью длительной автономной работы устройств. В ZigBee реализована поддержка ячеистой (mesh) топологии, кроме стандартных: «точка-точка», «дерево» и «звезда». Протоколы разработаны на алгоритмах AODV и NeuRFon. ZigBee – это целый альянс, который сотрудничает с рядом разработчиков и приводит работу оборудования к единому стандарту.

PPPoE

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

Новый протокол XVI (AXVI) от известного разработчика XM Xiongmai Technology.

Источник