Главная › Услуги › Какие существуют протоколы. Протоколы связи в АСУ ТП. Что представляет собой протокол PPP

Какие существуют протоколы. Протоколы связи в АСУ ТП. Что представляет собой протокол PPP

Прежде всего определим области применения каналов передачи данных в электроэнергетике и задачи, которые решаются с их помощью. В настоящее время к основным областям применения систем передачи данных можно отнести системы релейной защиты и автоматики (РЗА), диспетчерского и автоматизированного технологического управления электроэнергетическими объектами (АСТУ), а также системы автоматизированного учета энергоресурсов. В рамках этих систем решаются следующие задачи:

Системы АСТУ

Передача данных между локальными устройствами телемеханики (ТМ), устройствами РЗА и центральной приемопередающей станцией (ЦППС).
Передача данных между объектом и диспетчерским центром.
Передача данных между диспетчерскими центрами.

Системы учета

Передача данных от приборов учета в устройства сбора и передачи данных (УСПД).
Передача данных от УСПД на сервер.

В части систем РЗА можно отметить следующее: несмотря на то, что сбор данных с устройств РЗА в АСТУ в цифровом формате стал внедряться с момента появления цифровых устройств РЗА, связи между устройствами по-прежнему организуются аналоговыми цепями.

В РЗА системы передачи информации могут выполнять следующие функции:

Передача дискретных сигналов.
Передача данных между устройствами РЗА и ЦППС.

Другим важным каналом передачи, общим как для систем РЗА, так и для систем АСТУ и учета, является канал, по которому осуществляется передача измерений от измерительных трансформаторов тока и напряжения. До последнего времени о внедрении цифровых протоколов связи на данном уровне речь не шла, однако, имея в виду появление протокола для передачи мгновенных значений тока и напряжения МЭК 61850-9-2, на проблемах этого информационного канала также стоит остановиться.

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

Передача измерений от ТТ и ТН

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

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

Передача дискретных сигналов между устройствами

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

Такой способ передачи информации имеет следующие недостатки :

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

Передача данных между РЗА и ЦППС

Обмен данными между РЗА и ЦППС на объекте осуществляется в цифровом формате. Однако ввиду необходимости интеграции большого количества различных устройств этот способ имеет следующие особенности:

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

Передача данных между ЦППС объекта и диспетчерским центром

Передача данных между объектом и диспетчерским центром также ведется в цифровом формате. Обычно для этих целей используют протоколы МЭК 60870-101/104. Особенности реализации этих систем связи:

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

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

Рис. 1. Схема организации передачи данных.

Охарактеризуем кратко показанные стандартные протоколы.

Modbus

Modbus – один из наиболее распространенных сетевых протоколов для интеграции устройств РЗА в систему АСТУ, построенный на архитектуре «клиент–сервер». Популярность этого протокола во многом обусловлена его открытостью, поэтому большинство устройств поддерживают этот протокол.

Протокол Modbus может применяться для передачи данных по последовательным линиям связи RS-485, RS-433, RS-232, а также сети TCP/IP (Modbus TCP).

Стандарт Modbus состоит из трех частей, описывающих прикладной уровень протокола, спецификацию канального и физического уровней, а также спецификацию ADU для транспорта через стек TCP/IP.

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

МЭК 60870-5-101/103/104

МЭК 60870-5-101 – протокол телемеханики, предназначенный для передачи сигналов ТМ в АСТУ. Он также построен на архитектуре «клиент–сервер» и предназначен для передачи данных по последовательным линиям связи RS-232/485.

Протокол МЭК 60870-5-104 является расширением протокола 101 и регламентирует использование сетевого доступа по протоколу TCP/IP. Стандарты МЭК 60870-5-101/104 не подразумевают наличие семантической модели данных.

Протокол МЭК 60870-5-103 предназначен для обеспечения возможности интеграции в систему управления энергообъекта устройств РЗА. В отличие от стандартов МЭК 60870-5-101/104, он определяет семантику для фиксированного набора данных, формируемых устройствами РЗА. Одним из основных недостатков протокола МЭК 60870-5-103 является относительно невысокая скорость передачи данных.

Протоколы МЭК 60870-5-101/103/104 обеспечивают достаточно высокую функциональность при решении задач телеуправления, телесигнализации и телеизмерений, интеграции данных устройств в системы управления. В отличие от Modbus они позволяют также осуществлять спорадическую передачу данных с устройств.

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

В целом протоколы хорошо подходят для решения описанного выше спектра задач, однако обладают рядом недостатков :

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

DNP3

В России этот стандарт распространен слабо, однако некоторые устройства автоматизации все же поддерживают его. Долгое время протокол не был стандартизован, но сейчас он утвержден как стандарт IEEE-1815.

DNP3 поддерживает и последовательные линии связи RS-232/485, и сети TCP/IP. Протокол описывает три уровня модели OSI: прикладной, канальный и физический. Его отличительной особенностью является возможность передачи данных как от ведущего устройства к ведомому, так и между ведомыми устройствами. DNP3 также поддерживает спорадическую передачу данных от ведомых устройств.

В основу передачи данных положен, как и в случае с МЭК-101/104, принцип передачи таблицы значений. При этом с целью оптимизации использования коммуникационных ресурсов ведется посылка не всей базы данных, а только ее переменной части.

Важным отличием протокола DNP3 от рассмотренных ранее является попытка объектного описания модели данных и независимость объектов данных от передаваемых сообщений. Для описания структуры данных в DNP3 используется XML-описание информационной модели.

В дано подробное сравнение протоколов, но мы в табл. 1 приведем краткие выдержки применительно к рассмотренным выше протоколам.

Таблица 1. Протоколы передачи данных

Параметр	Протокол
Параметр	Modbus	МЭК-101/103/104	DNP3
Линии связи	RS-232/485/422 TCP/IP (Modbus TCP)	RS-232/485/422 TCP/IP (104)	RS-232/485/422 TCP/IP
Архитектура	Клиент – сервер	Клиент – сервер	Клиент – сервер
Принцип передачи данных	Обмен индексированными точками данных
Спорадическая передача данных	Нет	Да	Да
Семантическая модель данных	Нет	Нет Базовая (103)	Да
Передача данных в режиме реального времени	Нет	Нет	Нет

Выводы

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

Большое количество проприетарных протоколов приводит к усложнению процесса интеграции устройств в единую систему:

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

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

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

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

Основные положения при создании стандарта МЭК 61850

Работа над стандартом МЭК 61850 началась в 1995 году, причем изначально велась двумя независимыми, параллельно работающими группами : одна из них, образованная UCA , занималась разработкой общих объектных моделей подстанционного оборудования (GOMFSE); вторая, образованная в рамках технического комитета 57 МЭК, занималась созданием стандарта на протокол передачи данных для подстанций.

Позднее, в 1997 году, работы обеих групп были объединены под эгидой рабочей группы 10 ТК 57 МЭК и вошли в основу стандарта МЭК 61850.

В основе стандарта лежат три положения:

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

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

На сегодняшний день МЭК 61850 состоит из 25 различных документов (в том числе разрабатываемых), которые охватывают широкий круг вопросов и делают его гораздо больше, чем просто спецификацией ряда коммуникационных протоколов. Отметим основные особенности стандарта :

Определяет не только то, как должен производиться обмен информацией, но и то, какой информацией должен производиться обмен. Стандарт описывает абстрактные модели оборудования объекта и выполняемых функций. Информационная модель, лежащая в основе стандарта, представляется в виде классов объектов данных, атрибутов данных, абстрактных сервисов и описания взаимосвязей между ними.
Определяет процесс проектирования и наладки систем.
Определяет язык описания конфигурации системы (System Configuration description Language – SCL). Данный язык обеспечивает возможность обмена информацией о конфигурации устройств в стандартизованном формате между программным обеспечением различных фирм-производителей.
Описывает методики испытаний и приемки оборудования.

Работая с МЭК 61850, необходимо понимать, что стандарт:

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

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

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

Список литературы

Баглейбтер О.И. Трансформатор тока в сетях релейной защиты. Противодействие насыщению ТТ апериодической составляющей тока КЗ // Новости ЭлектроТехники. 2008. № 5(53).
Schaub P., Haywood J., Ingram D., Kenwrick A., Dusha G. Test and Evaluation of Non Conventional Instrument Transformers and Sampled Value Process Bus on Powerlink’s Transmission Network. SEAPAC 2011. CIGRE Australia Panel B5.
Шевцов М. В. Передача дискретных сигналов между УРЗА по цифровым каналам связи // Релейщик. 2009. № 1.
Schwarz K. Comparison of IEC 60870-5-101/-103/-104, DNP3, and IEC 60870-6-TASE.2 with IEC 61850 (электронный документ: http://bit.ly/NOHn8L).
Brunner C., Apostolov A. IEC 61850 Brand New World. PAC World Magazine. Summer 2007.
IEC 61850-1: Introduction and Overview.

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

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

В идеале, протокол должен быть абстрагирован от более нижнего уровня взаимодействия, будь то передача по 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) могут дать фору любым другим решениям. Но относительно попытки повсеместного их применения позволю себе процитировать Вирта:
Инструмент должен соответствовать задаче. Если инструмент не соответствует задаче, нужно придумать новый, который бы ей соответствовал, а не пытаться приспособить уже имеющийся.

Протокол - это совокупность правил, в соответствии с которыми происходит передача информации через сеть.

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

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

На самом деле TCP/IP является целым набором протоколов, работающих совместно. Он состоит из двух уровней. Протокол верхнего уровня, TCP, отвечает за правильность преобразования сообщений в пакеты информации, из которых на приемной стороне собирается исходное послание. Протокол нижнего уровня, IP, отвечает за правильность доставки сообщений по указанному адресу. Иногда пакеты одного сообщения могут доставляться разными путями.

Протокол HTTP (Hypertext Transfer Protocol - Протокол передачи гипертекста) является протоколом более высокого уровня по отношению к протоколу TCP/IP - протоколом уровня приложения. HTTP был разработан для эффективной передачи по Интернету Web-страниц. Именно благодаря HTTP мы имеем возможность просматривать страницы Сети. Протокол HTTP является основой системы World Wide Web.

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

Чтобы текст, составляющий содержимое Web-страниц, отображался на них определенным образом - в соответствии с замыслом создателя страницы - он размечается с помощью особых текстовых меток - тегов языка разметки гипертекста (HyperText Markup Language, HTML). Адреса ресурсов Интернета выглядит примерно следующим образом: http://www.tut.by

Протокол FTP (File Transfer Protocol - Протокол передачи файлов по Интернету. Протокол пересылки файлов FTP (File Transfer Protocol) реализует удаленный доступ к файлу. Для того, чтобы обеспечить надежную передачу, FTP использует в качестве транспорта протокол с установлением соединений - TCP.

Протокол telnet обеспечивает передачу потока байтов между процессами, а также между процессом и терминалом. Наиболее часто этот протокол используется для эмуляции терминала удаленной ЭВМ.

С помощью этого протокола вы можете подключиться к удаленному компьютеру как пользователь и производить действия над его файлами и приложениями точно так же, как если бы работали на своем компьютере. Работа с ним ведется из командной строки. Telnet-клиент поставляется, например, в комплекте Windows 98.

WAIS (Wide-Area Information Servers). Этот протокол был разработан для поиска информации в базах данных. Информационная система WAIS представляет собой систему распределенных баз данных, где отдельные базы данных хранятся на разных серверах. Сведения об их содержании и расположении хранятся в специальной базе данных - каталоге серверов. Просмотр информационных ресурсов осуществляется с помощью программы - клиента WAIS.

Поиск информации ведется по ключевым словам, которые задает пользователь. Эти слова вводятся для определенной базы данных, и система находит все соответствующие им фрагменты текста на всех серверах, где располагаются данные этой базы. Результат представляется в виде списка ссылок на документы с указанием того, насколько часто встречается в данном документе искомое слово и все искомые слова в совокупности. Адрес ресурса WAIS в Интернете выглядит примерно так: wais://site.edu

Протокол Gopher - протокол уровня приложения, разработанный в 1991 году. До повсеместного распространения гипертекстовой системы World Wide Web Gopher использовался для извлечения информации (в основном текстовой) из иерархической файловой структуры. Gopher был провозвестником WWW, позволявшим с помощью меню передвигаться от одной страницы к другой, постепенно сужая круг отображаемой информации. Программы-клиенты Gopher имели текстовый интерфейс. Однако пункты меню Gopher могли указывать и не только на текстовые файлы, но также, например, на telnet-соединения или базы данных WAIS. Современные Web-браузеры поддерживают этот протокол. Адреса информационных ресурсов Gopher имеют примерно следующий вид: gopher://gopher.tc.umn.edu

WAP (Wireless Application Protocol) был разработан в 1997 году группой компаний Ericsson, Motorola, Nokia и Phone.com для того, чтобы предоставить доступ к службам Интернета пользователям беспроводных устройств, использующих различные стандарты связи. Набрав на вашем мобильном телефоне адрес нужной Web-страницы, вы можете увидеть ее (в упрощенном виде) прямо на дисплее телефона.

Система доменных имен DNS

DNS (англ. Domain Name System - система доменных имён) - компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).

Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.

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

DNS была разработана Полом Мокапетрисом в 1983 году.

Ключевыми понятиями DNS являются:

Доме́н (англ. domain - область) - узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имен. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости), корневым доменом всей системы является точка ("."), ниже идут домены первого уровня (географические или тематические), затем - домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org домен первого уровня - org , второго wikipedia , третьего ru). На практике точку в конце имени часто опускают, но она бывает важна в случаях разделения между относительными доменами и FQDN.

Поддомен (англ. subdomain ) - подчинённый домен (например, wikipedia.org - поддомен домена org , а ru.wikipedia.org - домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru , mysite2.mydomain.ru и т. д.

Ресурсная запись - единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определенному Доменному имени, узлу в дереве имен), тип и поле данных , формат и содержание которого зависит от типа .

Зона - часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имен, а чаще - одновременно на нескольких серверах. Целью выделения части дерева в отдельную зону является передача ответственности за соответствующий домен другому лицу или организации. Это называется делегированием. Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имен DNS как структуру из зон, а не отдельных узлов/имен, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчиненных. На практике, большинство зон 0-го и 1-го уровня (".", ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчиненных уровней без выделения их в дочерние зоны.

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

DNS-сервер - это специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.

DNS-клиент - это специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.

Авторитетность - признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные , когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).

DNS-запрос - запрос от клиента (или сервера) серверу.

Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS , на котором расположена информация о домене.

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

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются. Протокол DNS использует для работы TCP- или UDP-порт для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется для AXFR-запросов.

Похожая информация.

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

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

Кто разрабатывает и стандартизирует все эти протоколы и программное обеспечение?

Новые протоколы для Интернета утверждаются IETF (Internet Engineering Task Force - Специальная комиссия инженерии Интернета), а прочие протоколы — IEEE (nstitute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и радиоэлектронике) или ISO - (International Organization for Standardization - Международная организация по стандартизации). ITU-T (Международный союз электросвязи) занимается телекоммуникационными протоколами и форматами.

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

Прикладной уровень (Application layer). Верхний (7-й) уровень модели, обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя доступ к сетевым службам, таким как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Также отвечает за передачу служебной информации, предоставляет приложениям информацию об ошибках и формирует запросы к уровню представления. Пример: HTTP, POP3, SMTP.
Уровень представления (Presentation layer). 6-й уровень отвечает за преобразование протоколов и кодирование/декодирование данных. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные преобразует в формат, понятный приложениям. На уровне представления может осуществляться сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально.
Сеансовый уровень (Session layer). 5-й уровень модели отвечает за поддержание сеанса связи, что позволяет приложениям взаимодействовать между собой длительное время. Сеансовый уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия.
Транспортный уровень (Transport layer). 4-й уровень модели, предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. При этом неважно, какие данные передаются, откуда и куда, то есть он предоставляет сам механизм передачи. Блоки данных он разделяет на фрагменты, размер которых зависит от протокола, короткие объединяет в один, а длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка. Пример: TCP, UDP
Сетевой уровень (Network layer).3-й уровень сетевой модели OSI, предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и заторов в сети. На этом уровне работает такое сетевое устройство, как маршрутизатор.
Уровень звена данных (Data Link layer). Часто это уровень называется канальным. Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Данные, полученные с физического уровня, он упаковывает во фреймы, проверяет на целостность, если нужно исправляет ошибки и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня — MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. На этом уровне работают коммутаторы, мосты. В программировании этот уровень представляет драйвер сетевой платы, в операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровней между собой, это не новый уровень, а просто реализация модели для конкретной ОС. Примеры таких интерфейсов: ODI, NDIS
Физический уровень (Physical layer). Самый нижний уровень модели, предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и соответственно их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Другими словами, осуществляет интерфейс между сетевым носителем и сетевым устройством. На этом уровне работают концентраторы (хабы), повторители (ретрансляторы) сигнала и медиаконверторы. Функции физического уровня реализуются на всех устройствах, подключенных к сети. Со стороны компьютера функции физического уровня выполняются сетевым адаптером или последовательным портом.

Уровни взаимодействуют сверху вниз и снизу вверх посредством интерфейсов и могут также взаимодействовать с таким же уровнем другой системы с помощью протоколов.

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

Сигнальный протокол используется для управления соединением - например, установки, переадресации, разрыва связи. Примеры протоколов: RTSP , SIP . Для передачи данных используются такие протоколы как RTP .

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

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

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

HTTP (Hyper Text Transfer Protocol) - это протокол передачи