Сетевые протоколы обмена данными. О протоколах передачи данных

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

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

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

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

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

• HTTP (Hyper Text Transfer Protocol) - это протокол передачи гипертекста . Протокол HTTP используется при пересылке Web-страниц между компьютерами, подключенными к одной сети.
• FTP (File Transfer Protocol) - это протокол передачи файлов со специального файлового сервера на компьютер пользователя. FTP дает возможность абоненту обмениваться двоичными и текстовыми файлами с любым компьютером сети. Установив связь с удаленным компьютером, пользователь может скопировать файл с удаленного компьютера на свой или скопировать файл со своего компьютера на удаленный.
• POP3 (Post Office Protocol) - это стандартный протокол почтового соединения. Серверы POP обрабатывают входящую почту, а протокол POP предназначен для обработки запросов на получение почты от клиентских почтовых программ.

1. протокол - Документ, представляющий объективное доказательство о проделанной работе или достигнутых результатах. Строительная терминология
2. протокол - -а, м. 1. Документ, содержащий запись всего происходившего на заседании, собрании, судебном процессе и т. п. Протокол допроса. Вести протокол собрания. 2. Документ, удостоверяющий какой-л. факт. Составили протокол осмотра, записали показания понятых. Малый академический словарь
3. протокол - протоко́л род. п. -а, уже у Куракина, 1707 г.; см. Христиани 30 и сл. Через франц. рrоtосоlе или нем. Рrоtоkоll (с 1536 г.; см. Шульц–Баслер 2, 708) из ср.-лат. рrоtосоllum от греч. πρωτόκολλον "приклеенный спереди лист на свитке папируса"; см. Смирнов 247. Этимологический словарь Макса Фасмера
4. Протокол - Акт, составляемый уполномоченными на то должностными лицами в удостоверение тех или иных событий. П. бывают судебные и административные. Энциклопедический словарь Брокгауза и Ефрона
5. протокол - сущ., кол-во синонимов: 6 админпротокол 1 акт 21 документ 82 интернет-протокол 1 протокольчик 1 соглашение 41 Словарь синонимов русского языка
6. протокол - протокол м. 1. Документ с записью происходящего (на собрании, заседании, допросе и т.п.). 2. Документ, удостоверяющий какой-либо факт, происшествие. 3. Письменное соглашение между государствами (обычно по частным вопросам). Толковый словарь Ефремовой
7. ПРОТОКОЛ - (от франц. protocole - первый лист) 1) документ, подписанный договаривающимися сторонами и фиксирующий результаты переговоров перед заключением договора; 2) запись происходившего на собрании с указанием участников и принятых решений. Экономический словарь терминов
8. протокол - ПРОТОКОЛ, а, м. 1. Документ с записью всего происходящего на заседании, собрании, допросе. П. заседания. П. допроса. Вести п. Занести в п. 2. Документ, к-рым удостоверяется какой-н. факт. П. медицинского вскрытия. 3. Акт о нарушении общественного порядка. Толковый словарь Ожегова
9. протокол - Протокол, протоколы, протокола, протоколов, протоколу, протоколам, протокол, протоколы, протоколом, протоколами, протоколе, протоколах Грамматический словарь Зализняка
10. ПРОТОКОЛ - ПРОТОКОЛ (франц. protocole, от греч. protokollon - первый лист манускрипта) - 1) официальный документ, в котором фиксируются какие-либо фактические обстоятельства (ход собрания, процессуальные или следственные действия, судебное заседание). Большой энциклопедический словарь
11. протокол - (фр. protocole, от гр. protokollon - первый лист манускрипта) 1) официальный документ, в котором фиксируются какие-либо фактические обстоятельства (ход собрания, процессуальные или следственные действия, судебное.заседание); 2) в международном праве... Большой юридический словарь
12. протокол - орф. протокол, -а Орфографический словарь Лопатина
13. Протокол - (от греч. protókollon - первый лист, приклеенный к свитку манускрипта) 1) в СССР официальный документ, в котором фиксируются: факт совершения административного проступка; ход и результаты процессуальных действий при расследовании уголовного дела... Большая советская энциклопедия
14. ПРОТОКОЛ - ПРОТОКОЛ (от греч. protokollon - первый лист) - англ. report/record; нем. Protokoll. 1. Документ, содержащий описание произведенных действий и установленных фактов. Социологический словарь
15. протокол - Документ, подписанный сторонами о результатах переговоров перед заключением договора или соглашения. Большой бухгалтерский словарь
16. протокол - Заимствование из французского, в котором protocole восходит к греческому protokollon (protos – "первый" и kollan – "клеить"). Буквальное значение этого слова в греческом "первый приклеиваемый лист рукописи", который обычно включал указание на владельца, время, имя переписчика и т. п. Этимологический словарь Крылова
17. протокол - Протокола, м. [новогреч. protokollon – первый лист, к которому приклеивается следующий в свитке] (офиц.). 1. Официальный документ, содержащий запись всего, что было сказано, сделано и решено на собрании, заседании, допросе. Протокол судебного заседания. Большой словарь иностранных слов
18. протокол - ПРОТОКОЛ -а; м. [от греч. prōtokollon - первый лист, приклеиваемый к свитку манускрипта] 1. Документ с краткой записью хода собрания, заседания и т.п. П. допроса. Вести п. собрания. Запись в протоколе. Сделать выписку из протокола. Занести... Толковый словарь Кузнецова
19. протокол - ПРОТОК’ОЛ, протокола, ·муж. (·новогреч. protokollon - первый лист, к которому приклеивается следующий в свитке) (офиц.). 1. Официальный документ, содержащий запись всего, что было сказано, сделано и решено на собрании, заседании, допросе. Толковый словарь Ушакова
20. протокол - ПРОТОКОЛ м. судебная записка, с изложением дела, применением законов и решением; но протокол составляется нередко и вместо журнала, постановления вообще, и даже, в виде постановления о выдаче денег и пр., на основании журнала, вдвойне. Толковый словарь Даля

Протоколы связи в АСУ ТП

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

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

Для организации промышленных сетей используется множество интерфейсов и протоколов передачи данных, например Modbus, Ethernet, CAN, HART, PROFIBUS и пр. Они необходимы для передачи данных между датчиками, контроллерами и исполнительными механизмами (ИМ); калибровки датчиков; питания датчиков и ИМ; связи нижнего и верхнего уровней АСУ ТП. Протоколы разрабатываются с учетом особенностей производства и технических систем, обеспечивая надежное соединение и высокую точность передачи данных между различными устройствами. Наряду с надежностью работы в жестких условиях все более важными требованиями в системах АСУ ТП становятся функциональные возможности, гибкость в построении, простота интеграции и обслуживания, соответствие промышленным стандартам.

Наиболее распространённой системой классификации сетевых протоколов является теоретическая модель OSI (базовая эталонная модель взаимодействия открытых систем, англ. Open Systems Interconnection Basic Reference Model ). Спецификация этой модели была окончательно принята в 1984 году Международной Организацией по Стандартизации (ISO). В соответствии с моделью OSI протоколы делятся на 7 уровней, расположенных друг над другом, по своему назначению — от физического (формирование и распознавание электрических или других сигналов) до прикладного (API для передачи информации приложениями). Взаимодействие между уровнями может осуществляться, как вертикально, так и горизонтально (Рис. 1). В горизонтальном взаимодействии программам требуется общий протокол для обмена данными. В вертикальном - посредством интерфейсов.

Рис. 1. Теоретическая модель OSI.

Прикладной уровень

Прикладной уровень - уровень приложений (англ. Application layer ). Обеспечивает взаимодействие сети и приложений пользователя, выходящих за рамки модели OSI. На этом уровне используются следующие протоколы: HTTP, gopher, Telnet, DNS, SMTP, SNMP, CMIP, FTP, TFTP, SSH, IRC, AIM, NFS, NNTP, NTP, SNTP, XMPP, FTAM, APPC, X.400, X.500, AFP, LDAP, SIP, ITMS, Modbus TCP, BACnet IP, IMAP, POP3, SMB, MFTP, BitTorrent, eD2k, PROFIBUS.

Представительский уровень

Представительский уровень (англ. Presentation layer ) - уровень представления данных. На этом уровне может осуществляться преобразование протоколов и сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные преобразует в формат, понятный приложениям. К этому уровню традиционно относят следующие протоколы: HTTP, ASN.1, XML-RPC, TDI, XDR, SNMP, FTP, Telnet, SMTP, NCP, AFP.

Сеансовый уровень

Сеансовый уровень (англ. Session layer ) управляет созданием/завершением сеанса связи, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия. Используемые протоколы: ASP, ADSP, DLC, Named Pipes, NBT, NetBIOS, NWLink, Printer Access Protocol, Zone Information Protocol, SSL, TLS, SOCKS.

Транспортный уровень

Транспортный уровень (англ. Transport layer ) организует доставку данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. Разделяет данные на фрагменты равной величины, объединяя короткие и разбивая длинные (размер фрагмента зависит от используемого протокола). Используемые протоколы: TCP, UDP, NetBEUI, AEP, ATP, IL, NBP, RTMP, SMB, SPX, SCTP, DCCP, RTP, TFTP.

Сетевой уровень

Сетевой уровень (англ. Network layer ) определяет пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, за определение кратчайших маршрутов, коммутацию и маршрутизацию, за отслеживание неполадок и заторов в сети. Используемые протоколы: IP, IPv6, ICMP, IGMP, IPX, NWLink, NetBEUI, DDP, IPSec, ARP, RARP, DHCP, BootP, SKIP, RIP.

Канальный уровень

Канальный уровень (англ. Data link layer ) предназначен для обеспечения взаимодействия сетей на физическом уровне. Полученные с физического уровня данные проверяет на ошибки, если нужно исправляет, упаковывает во фреймы, проверяет на целостность, и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня — MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. Используемые протоколы: STP, ARCnet, ATM, DTM, SLIP, SMDS, Ethernet, FDDI, Frame Relay, LocalTalk, Token ring, StarLan, L2F, L2TP, PPTP, PPP, PPPoE, PROFIBUS.

Физический уровень

Физический уровень (англ. Physical layer ) предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Используемые протоколы: RS-232, RS-422, RS-423, RS-449, RS-485, ITU-T, xDSL, ISDN, T1, E1, 10BASE-T, 10BASE2, 10BASE5, 100BASE-T, 1000BASE-T, 1000BASE-TX, 1000BASE-SX.

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

В мировой практике, среди сетей общего применения, наиболее широко распространен протокол HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста» ). Относится к прикладному и представительскому уровням теоретической модели OSI. HTTP базируется на технологии «клиент-сервер», то есть существует потребитель (клиент), который инициирует соединение и посылает запрос, и поставщик (сервер), который ожидает соединения для получения запроса, производит необходимые действия и возвращает обратно сообщение с результатом. Основным типом НТТР-клиента является браузер, например Mozilla Firefox, Opera или Microsoft Internet Explorer. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.

Рис. 2. Технология клиент сервер.

На базе HTTP разработаны расширенные протоколы: HTTPS (англ. Hypertext Transfer Protocol Secure ), поддерживающий шифрование, и HTTP-NG (англ. HTTP Next Generation ), увеличивающий быстродействие Web и расширяющий возможности промышленного применения.

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

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

создание удаленных диспетчерских пунктов, Web-приложения для SCADA систем, программное обеспечение промышленных контроллеров, организация видеонаблюдения.

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

В оборудовании компании Korenix серий JetNet, JetRock, JetPort, JetI/O, JetBox (построение сетей на базе промышленного Ethernet), JetWave (беспроводные решения) протоколы семейства HTTP используются для организации доступа, конфигурирования и управления устройствами.

Компания ICPDAS для работы с протоколом HTTP предлагает следующее оборудование и программное обеспечение. Контроллеры серии ХРАК, WinPAC, WinCon, LinPAC, ViewPAC работают под управлением операционных систем Windows и Linux, с встроенным HTTP-сервером. Программные пакеты InduSoft (SCADA), ISaGRAF, Web HMI, VXCOMM, MiniOS7 Studio, также используют HTTP-сервер для связи и взаимодействия с устройствами.

Управляемые коммутаторы, встраиваемые компьютеры, оборудование промышленных беспроводных сетей, производства компании Моха, не обходятся без использования протоколов семейства HTTP.

Рис. 3. Совместимость протоколов семейства Modbus.

Для организации взаимодействия между элементами автоматизации в промышленных сетях передачи данных широко применяется коммуникационный протокол Modbus. Существуют три основные реализации протокола Modbus, две для передачи данных по последовательным линиям связи, как медным EIA/TIA-232-E (RS-232), EIA-422, EIA/TIA-485-A (RS-485), так и оптическим и радио: Modbus RTU и Modbus ASCII, и для передачи данных по сетям Ethernet поверх TCP/IP: Modbus TCP.

Различие между протоколами Modbus ASCII и Modbus RTU заключается в способе кодирования символов. В режиме ASCII данные кодируются при помощи таблицы ASCII, где каждому символу соответствует два байта данных. В режиме RTU данные передаются в виде 8-ми разрядных двоичных символов, что обеспечивает более высокую скорость передачи данных. ASCII допускает задержку до 1 секунды в отличии от RTU, где сообщения должны быть непрерывны. Также режим ASCII имеет упрощенную систему декодирования и управления данными.

Протоколы семейства Modbus (Modbus ASCII, Modbus RTU и Modbus TCP/IP) используют один прикладной протокол, что позволяет обеспечить их совместимость. Максимальное количество сетевых узлов в сети Modbus - 31. Протяженность линий связи и скорость передачи данных зависит от физической реализации интерфейса. Элементы сети Modbus взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа.

Обычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов — «подчиненных» (slaves) устройств. Главное устройство инициирует транзакции (передаёт запросы). Подчиненные устройства передают запрашиваемые главным устройством данные, или производят запрашиваемые действия. Главный может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство формирует сообщение и возвращает его в ответ на запрос, адресованный именно ему.

Области промышленного применения:

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

Компания ICPDAS предлагает широкий спектр коммуникационного оборудования для организации сетей на базе протоколов семейства Modbus: серия I-7000 (шлюзы DeviceNet, серверы Modbus, адресуемые коммуникационные контроллеры); программируемые контроллеры серий ХРАК, WinPAC, WinCon, LinPAC, ViewPAC.

Операторские панели производства компании Weintek, частотные преобразователи Control Techniques для связи с контроллерами также используют протокол Modbus.

Традиционно протоколы семейства Modbus поддерживаются OPC серверами SCADA систем (Clear SCADA, компании Control Microsystems, InTouch Wonderware, TRACE MODE)для связи с элементами управления (контроллерами, ЧРП, регуляторами и др.).

Рис. 4. Сеть Profibus.

В Европе широкое распространение получила открытая промышленная сеть PROFIBUS (PROcess FIeld BUS). Изначально, прототип этой сети был разработан компанией Siemens для своих промышленных контроллеров.

PROFIBUS объединяет технологические и функциональные особенности последовательной связи полевого уровня. Она позволяет объединять разрозненные устройства автоматизации в единую систему на уровне датчиков и приводов. Сеть PROFIBUS основывается на нескольких стандартах и протоколах, использует обмен данными между ведущим и ведомыми устройствами (протоколы DP и PA) или между несколькими ведущими устройствами (протоколы FDL и FMS).

Сеть PROFIBUS можно ассоциировать с тремя уровнями модели OSI: физический, канальный и уровень приложений.

Единым протоколом для доступа к шине для всех версий PROFIBUS является реализованный на втором уровне модели OSI протокол PROFIBUS-FDL. Данный протокол использует процедуру доступа с помощью маркера (token). Так же, как и сети на базе протоколов Modbus, сеть PROFIBUS состоит из ведущих (master) и ведомых (slave) устройств. Ведущее устройство может управлять шиной. Когда у ведущего (master) устройства есть право доступа к шине, оно может передавать сообщения без удаленного запроса. Ведомые устройства - это обычные периферийные устройства, не имеют прав доступа к шине, то есть они могут только подтверждать принимаемые сообщения или передавать сообщения ведущему устройству по его запросу. В минимальной конфигурации сеть может состоять либо из двух ведущих, либо из одного ведущего и одного ведомого устройства.

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

PROFIBUS DP (Decentralized Peripheral - Распределенная периферия) — протокол, ориентированный на обеспечение скоростного обмена данными между ведущими DP-устройствами и устройствами распределённого ввода-вывода. Протокол характеризуется минимальным временем реакции и высокой стойкостью к воздействию внешних электромагнитных полей. Оптимизирован для высокоскоростных и недорогих систем.

PROFIBUS PA (Process Automation - Автоматизация процесса) — протокол обмена данными с оборудованием полевого уровня, расположенным в обычных или взрывоопасных зонах. Протокол позволяет подключать датчики и приводы на одну линейную шину или кольцевую шину.

PROFIBUS FMS (Fieldbus Message Specification - Спецификация сообщений полевого уровня) - универсальный протокол для решения задач по обмену данными между интеллектуальными сетевыми устройствами (контроллерами, компьютерами/программаторами, системами человеко-машинного интерфейса) на полевом уровне. Некоторый аналог промышленного Ethernet, обычно используется для высокоскоростной связи между контроллерами и компьютерами верхнего уровня.

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

Положительные стороны: открытость, независимость от поставщика, распространенность.

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

Основную массу оборудования использующего протокол PROFIBUS составляет оборудование компании SIEMENS. Но в последнее время этот протокол получил применение у большинства производителей. Во многом это обусловлено распространенностью систем управления на базе контроллеров Siemens.

Рис. 5. Сеть Profibus на базе оборудования ICP DAS.

Компания ICPDAS для реализации проектов на базе PROFIBUS предлагает ряд ведомых устройств: шлюзы PROFIBUS/Modbus серии GW, преобразователи PROFIBUS в RS-232/485/422 серии I-7000, модули и каркасы удаленного ввода/вывода PROFIBUS серии PROFI-8000. В настоящие время инженерами компании ICPDAS ведутся интенсивные разработки в области создания PROFIBUS ведущего устройства.

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

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

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

• Соединение - в сетях, соединение означает возможность передавать данные между устройствами. Перед тем как начнется передача данных, должно состоятся соединение, параметры которого описаны протоколом;
• Пакет - это основной структурный блок данных в сети. Все данные передаются в виде пакетов, большие данные разделяются на небольшие пакеты, фиксированного размера. В каждом пакете есть заголовок, в котором находится информация о данных, пункте назначения, отправителе, строке жизни пакета, времени отправки и т д;
• Сетевой интерфейс - это физическое или виртуальное устройство, которое позволяет компьютеру подключиться к сети. Если у вас есть две сетевые карты на компьютере, то вы можете настроить сетевой интерфейс для каждой из них. Также сетевой интерфейс может быть виртуальным, например, локальный интерфейс lo;
• LAN - это ваша локальная сеть, к ней подключены только ваши компьютеры и больше никто не имеет к ней доступа. Это может быть ваша домашняя или офисная сеть;
• WAN - это глобальная сеть интернет, обычно этот термин применяется для обозначения всей сети интернет, также этот термин может относиться к сетевому интерфейсу;
• Протокол - набор правил и стандартов, которые определяют команды и способ коммуникации между устройствами. Существует множество протоколов и мы их рассмотрим ниже. Самые популярные из них - это TCP, UDP, IP и ICMP, также есть протоколы сети интернет более высокого уровня, например, HTTP и FTP;
• Порт - это адрес на компьютере, который связан с определенной программой. Это не сетевой интерфейс и не местоположение. С помощью портов программы могут общаться между собой;
• Брандмауэр - это программное обеспечение, которое контролирует все сетевые пакеты, проходящие через компьютер. Проходящие пакеты обрабатываются на основе правил, созданных пользователем. Также брандмауэр может закрывать определенные порты, чтобы сделать работу компьютера более безопасной;
• NAT -это служба преобразования сетевых адресов между локальной и глобальной сетью. Количество свободных сетевых адресов в сети уменьшается, поэтому необходимо найти решение, и решением стало создания локальных сетей, где несколько компьютеров могут иметь один IP адрес. Все пакеты приходят на роутер, а он уже потом с помощью NAT распределяет их между компьютерами.
• VPN - это виртуальная частная сеть, с помощью нее можно объединить несколько локальных сетей через сеть интернет. Используется в большинстве случаев для обеспечения безопасности.

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

Уровни сетей и модель OSI

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

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

Модель OSI

Так сложилось исторически, что когда дело доходит до уровней работы сетей, используется модель OSI или Open Systems Interconnect. Она выделяет семь уровней:

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

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

Модель протоколов TCP/IP

Модель TCP/IP, еще известная как набор основных протоколов интернета, позволяет представить себе уровни работы сети более просто. Здесь есть только четыре уровня и они повторяют уровни OSI:

• Приложения - в этой модели уровень приложений отвечает за соединение и передачу данными между пользователям. Приложения могут быть в удаленных системах, но они работают как будто бы находятся в локальной системе;
• Транспорт - транспортный уровень отвечает за связь между процессами, здесь используются порты для определения какому приложению нужно передать данные и какой протокол использовать;
• Интернет - на этом уровне данные передаются от узла к узлу по сети интернет. Здесь известны конечные точки соединения, но не реализуется непосредственная связь. Также на этом уровне определяются IP адреса;
• Соединение - этот уровень реализует соединение на физическом уровне, что позволяет устройствам передавать между собой данные не зависимо от того, какие технологии используются.

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

Основные протоколы интернета

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

• MAC или (Media Access Control) - это протокол низкого уровня, который используется для идентификации устройств в локальной сети. У каждого устройства, подключенного к сети есть уникальный MAC адрес, заданный производителем. В локальных сетях, а все данные выходят из локальной сети и попадают в локальную сеть перед тем, как попасть к получателю, используются физические MAC адреса для обозначения устройств. Это один из немногих протоколов уровня соединения, с которым довольно часто приходится сталкиваться.
• IP (Internet Protocol) - расположен уровнем выше, за MAC. Он отвечает за определение IP адресов, которые будут уникальными для каждого устройства и позволяют компьютерам находить друг друга в сети. Он относится к сетевому уровню модели TCP/IP. Сети могут быть связанны друг с другом в сложные структуры, с помощью этого протокола компьютеры могут определить несколько возможных путей к целевому устройству, причем во время работы эти пути могут меняться. Есть несколько реализаций протокола, но наиболее популярной на сегодняшний день является IPv4 и IPv6.
• ICMP (Internet control message protocol) - используется для обмена сообщениями между устройствами. Это могут быть сообщения об ошибках или информационные сообщения, но он не предназначен для передачи данных. Такие пакеты используются в таких диагностических инструментах, как ping и traceroute. Этот протокол находится выше протокола IP;
• TCP (Transmission control protocol) - это еще один основной сетевой протокол, который находится на том же уровне, что и ICMP. Его задача - управление передачей данных. Сети ненадежны. Из-за большого количества путей пакеты могут приходить не в том порядке или даже теряться. TCP гарантирует, что пакеты будут приняты в правильном порядке, а также позволяет исправить ошибки передачи пакетов. Информация приводится к правильному порядку, а уже затем передается приложению. Перед передачей данных создается соединение с помощью так называемого алгоритма тройного рукопожатия. Он предусматривает отправку запроса и подтверждение открытия соединения двумя компьютерами. Множество приложений используют TCP, это SSH, WWW, FTP и многие другие.
• UDP (user datagram protocol) - это популярный протокол, похожий на TCP, который тоже работает на транспортном уровне. Отличие между ними в том, что здесь используется ненадежная передача данных. Данные не проверяются при получении, это может выглядеть плохой идеей, но во многих случаях этого вполне достаточно. Поскольку нужно отправлять меньше пакетов, UDP работает быстрее, чем TCP. Поскольку соединение устанавливать не нужно, то этот протокол может использоваться для отправки пакетов сразу на несколько машин или IP телефонии.
• HTTP (hypertext transfer protocol) - это протокол уровня приложения, который лежит в основе работы всех сайтов интернета. HTTP позволяет запрашивать определенные ресурсы у удаленной системы, например, веб страницы, и файлы;
• FTP (file transfer protocol) - это протокол передачи файлов. Он работает на уровне приложений и обеспечивает передачу файла от одного компьютера к другому. FTP - не безопасный, поэтому не рекомендуется его применять для личных данных;
• DNS (domain name system) - протокол того же уровня, используемый для преобразования понятных и легко читаемых адресов в сложные ip адреса, которые трудно запомнить и наоборот. Благодаря ему мы можем получить доступ к сайту по его доменному имени;
• SSH (secure shell) - протокол уровня приложений, реализованный для обеспечения удаленного управления системой по защищенному каналу. Многие дополнительные технологии используют этот протокол для своей работы.

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

Выводы

В этой статье мы рассмотрели основы сетей и протоколов, которые используются для организации их работы. Конечно, этого совсем недостаточно, чтобы понять все, но теперь у вас есть определенная база и вы знаете как различные компоненты взаимодействуют друг с другом. Это поможет вам понимать другие статьи и документацию. Если вас серьезно заинтересовали основы сети интернет, то тут не хватит нескольких статей. Вам нужна книга. Обратите внимание на Камер Д. Сети TCP/IP. Принципы, протоколы и структура. В свое время я ее прочитал и мне очень понравилось.

На завершение видео про модель OSI:

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

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

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