В компьютерных сетях надежный протокол — это протокол связи , который уведомляет отправителя об успешной доставке данных предполагаемым получателям. Надежность – это синоним гарантии , термина, используемого МСЭ и Форумом ОрВД .
Надежные протоколы обычно требуют больше накладных расходов, чем ненадежные, и в результате работают медленнее и с меньшей масштабируемостью. Зачастую это не является проблемой для одноадресных протоколов, но может стать проблемой для надежных многоадресных протоколов.
Протокол управления передачей (TCP), основной протокол, используемый в Интернете , является надежным протоколом одноадресной передачи; он обеспечивает приложениям абстракцию надежного потока байтов . UDP является ненадежным протоколом и часто используется в компьютерных играх , потоковом мультимедиа или в других ситуациях, когда скорость является проблемой и возможна некоторая потеря данных из-за временного характера данных.
Часто надежный одноадресный протокол также ориентирован на соединение . Например, TCP ориентирован на соединение, при этом идентификатор виртуального канала состоит из IP-адресов источника и назначения , а также номеров портов. Однако некоторые ненадежные протоколы ориентированы на соединение, например, асинхронный режим передачи и Frame Relay . Кроме того, некоторые протоколы без установления соединения, такие как IEEE 802.11 , надежны.
Основываясь на концепции коммутации пакетов , предложенной Дональдом Дэвисом , первый протокол связи в ARPANET представлял собой надежную процедуру доставки пакетов для соединения хостов через интерфейс 1822 . [1] [2] Главный компьютер просто упорядочил данные в правильном формате пакета, вставил адрес хост-компьютера-получателя и отправил сообщение через интерфейс на подключенный к нему интерфейсный процессор сообщений (IMP). Как только сообщение было доставлено на хост назначения, на отправляющий хост было доставлено подтверждение. Если сеть не сможет доставить сообщение, IMP отправит сообщение об ошибке обратно на отправляющий хост.
Тем временем разработчики CYCLADES и ALOHAnet продемонстрировали, что можно построить эффективную компьютерную сеть, не обеспечивая надежную передачу пакетов. Этот урок позже был усвоён разработчиками Ethernet .
Если сеть не гарантирует доставку пакетов, ответственность за обеспечение надежности путем обнаружения и повторной передачи потерянных пакетов ложится на хост. Последующий опыт работы в ARPANET показал, что сама сеть не может надежно обнаружить все сбои доставки пакетов, и это в любом случае возлагает ответственность за обнаружение ошибок на отправляющий хост. Это привело к разработке сквозного принципа , который является одним из фундаментальных принципов проектирования Интернета .
Надежная служба — это служба, которая уведомляет пользователя в случае сбоя доставки, тогда как ненадежная служба не уведомляет пользователя в случае сбоя доставки. [ нужна цитация ] Например, Интернет-протокол (IP) предоставляет ненадежную услугу. Вместе протокол управления передачей (TCP) и IP обеспечивают надежную услугу, тогда как протокол пользовательских дейтаграмм (UDP) и IP обеспечивают ненадежную услугу.
В контексте распределенных протоколов свойства надежности определяют гарантии, которые протокол предоставляет в отношении доставки сообщений предполагаемому получателю(ям).
Примером свойства надежности для одноадресного протокола является «по крайней мере один раз», т.е. по крайней мере одна копия сообщения гарантированно будет доставлена получателю.
Свойства надежности для протоколов многоадресной рассылки могут быть выражены для каждого получателя (простые свойства надежности) или они могут связывать факт доставки или порядок доставки между различными получателями (строгие свойства надежности). В контексте протоколов многоадресной рассылки сильные свойства надежности выражают гарантии, которые протокол предоставляет в отношении доставки сообщений различным получателям.
Примером сильного свойства надежности является отзыв последней копии , означающий, что до тех пор, пока хотя бы одна копия сообщения остается доступной у любого из получателей, каждый другой получатель, который не выходит из строя, в конечном итоге также получает копию. Сильные свойства надежности, подобные этому, обычно требуют, чтобы сообщения повторно передавались или пересылались между получателями.
Примером свойства надежности, более сильного, чем отзыв последней копии, является атомарность . Свойство гласит, что если хотя бы одна копия сообщения была доставлена получателю, все остальные получатели в конечном итоге получат копию сообщения. Другими словами, каждое сообщение всегда доставляется либо всем получателям, либо никому из них.
Одним из наиболее сложных свойств повышенной надежности является виртуальная синхронность .
Надежный обмен сообщениями — это концепция передачи сообщений через ненадежную инфраструктуру с возможностью предоставления определенных гарантий успешной передачи сообщений. [3] Например, если сообщение доставлено, оно будет доставлено не более одного раза или что все успешно доставленные сообщения прибудут в определенном порядке.
Надежную доставку можно противопоставить доставке с максимальными усилиями , когда нет никакой гарантии, что сообщения будут доставлены быстро, по порядку или вообще.
Надежный протокол доставки может быть построен на ненадежном протоколе. Чрезвычайно распространенным примером является наложение протокола управления передачей на Интернет-протокол , комбинация, известная как TCP/IP .
Высокие свойства надежности обеспечивают системы групповой связи (GCS), такие как IS-IS , Appia framework , JGroups или QuickSilver Scalable Multicast . QuickSilver Properties Framework — это гибкая платформа, которая позволяет выражать строгие свойства надежности чисто декларативным образом, используя простой язык, основанный на правилах, и автоматически переводить их в иерархический протокол.
Одним из протоколов, реализующих надежный обмен сообщениями, является WS-ReliableMessaging , который обеспечивает надежную доставку сообщений SOAP . [4]
Функция координации конкретных услуг ATM обеспечивает прозрачную гарантированную доставку с помощью AAL5 . [5] [6] [7]
IEEE 802.11 пытается обеспечить надежный сервис для всего трафика. Станция-отправитель повторно отправит кадр, если станция-отправитель не получит кадр подтверждения в течение заранее определенного периода времени.
Однако существует проблема с определением надежности как «доставки или уведомления об отказе» в вычислениях в реальном времени . В таких системах неспособность доставить данные в режиме реального времени отрицательно повлияет на производительность систем, и некоторые системы, например, критически важные для безопасности , связанные с безопасностью системы и некоторые безопасные критически важные системы, должны быть доказано , что они работают при некоторых заданных значениях. минимальный уровень. Это, в свою очередь, требует соблюдения установленной минимальной надежности доставки критически важных данных. Поэтому в этих случаях имеет значение только доставка; уведомление о невозможности доставки смягчает ситуацию. В системах жесткого реального времени все данные должны быть доставлены к установленному сроку, иначе это считается системным сбоем. В фирменных системах реального времени просроченные данные по-прежнему бесполезны, но система может допустить некоторое количество запоздалых или отсутствующих данных. [8] [9]
Существует ряд протоколов, которые способны удовлетворить требования в режиме реального времени для надежной доставки и своевременности:
MIL-STD-1553B и STANAG 3910 являются хорошо известными примерами таких своевременных и надежных протоколов для шин авионики . MIL-1553 использует общую среду передачи данных со скоростью 1 Мбит/с для передачи данных и управления этими передачами и широко используется в объединенных системах военной авионики . [10] Он использует контроллер шины (BC) для подачи команды подключенным удаленным терминалам (RT) на прием или передачу этих данных. Таким образом, BC может гарантировать отсутствие заторов и своевременность пересадок. Протокол MIL-1553 также допускает автоматические повторные попытки, которые по-прежнему могут гарантировать своевременную доставку и повысить надежность по сравнению с физическим уровнем. STANAG 3910, также известный как EFABus при использовании на Eurofighter Typhoon , по сути, представляет собой версию MIL-1553, дополненную общей медиа-шиной со скоростью 20 Мбит/с для передачи данных, сохраняя общую медиа-шину со скоростью 1 Мбит/с для передачи данных. целях контроля.
Асинхронный режим передачи (ATM), авиационный полнодуплексный коммутируемый Ethernet (AFDX) и Ethernet с синхронизацией по времени (TTEthernet) являются примерами сетевых протоколов с коммутацией пакетов, в которых сеть может гарантировать своевременность и надежность передачи данных. AFDX и TTEthernet также основаны на IEEE 802.3 Ethernet, хотя и не полностью с ним совместимы.
ATM использует виртуальные каналы с установлением соединения (VC), которые имеют полностью детерминированные пути через сеть, а также управление использованием и параметрами сети (UPC/NPC), которые реализованы в сети, чтобы ограничить трафик на каждом VC отдельно. Это позволяет заранее рассчитать использование общих ресурсов (буферов коммутатора) в сети на основе параметров передаваемого трафика, т. е. во время проектирования системы. То, что они реализуются сетью, означает, что эти вычисления остаются действительными, даже когда другие пользователи сети ведут себя неожиданным образом, т.е. передают больше данных, чем от них ожидается. Затем рассчитанное использование можно сравнить с возможностями этих ресурсов, чтобы показать, что, учитывая ограничения на маршруты и пропускную способность этих соединений, ресурс, используемый для этих передач, никогда не будет перегружен. Таким образом, на эти передачи никогда не повлияет перегрузка, и из-за этого не будет никаких потерь. Затем на основе прогнозируемого максимального использования буферов коммутатора можно также спрогнозировать максимальную задержку в сети. Однако для подтверждения надежности и своевременности, а также для обеспечения устойчивости доказательств к сбоям и злонамеренным действиям оборудования, подключенного к сети, расчеты использования этих ресурсов не могут основываться на каких-либо параметрах, которые активно не применяются сети, т.е. они не могут быть основаны на ожидаемых действиях источников трафика или на статистическом анализе характеристик трафика (см. сетевое исчисление ). [11]
AFDX использует распределение полосы пропускания в частотной области и контроль трафика , что позволяет ограничивать трафик на каждом виртуальном канале (VL), чтобы можно было прогнозировать требования к общим ресурсам и предотвращать перегрузку, чтобы можно было доказать, что она не влияет на критически важные данные. [12] Однако методы прогнозирования требований к ресурсам и доказательства предотвращения перегрузок не являются частью стандарта AFDX.
TTEthernet обеспечивает минимально возможную задержку при передаче данных по сети за счет использования методов управления во временной области: каждый раз инициируемая передача планируется в определенное время, чтобы контролировать конкуренцию за общие ресурсы и, таким образом, устранять возможность перегрузки. Коммутаторы в сети обеспечивают соблюдение этого времени, чтобы обеспечить устойчивость к сбоям и злонамеренным действиям со стороны другого подключенного оборудования. Однако «синхронизированные локальные часы являются фундаментальной предпосылкой для связи, синхронизированной по времени». [13] Это связано с тем, что источники критических данных должны иметь то же представление времени, что и коммутатор, чтобы они могли передавать в правильное время, и коммутатор воспринимал это как правильное. Это также требует, чтобы последовательность планирования критической передачи была предсказуемой как для источника, так и для коммутатора. Это, в свою очередь, ограничит график передачи строго детерминированным графиком, например, циклическим исполнительным механизмом .
Однако низкая задержка при передаче данных по шине или сети не обязательно приводит к низким задержкам при транспортировке между процессами приложений, которые отправляют и принимают эти данные. Это особенно верно, когда передача по шине или сети запланирована циклически (как это обычно бывает с MIL-STD-1553B и STANAG 3910 и обязательно с AFDX и TTEthernet), но процессы приложений не синхронизируются с этим расписанием.
Как для AFDX, так и для TTEthernet от интерфейсов требуются дополнительные функции, например, контроль разрыва распределения полосы пропускания AFDX и требование TTEthernet к очень тесной синхронизации источников синхронизированных по времени данных, что затрудняет использование стандартных интерфейсов Ethernet. Другие методы управления трафиком в сети, которые позволили бы использовать такие стандартные сетевые интерфейсы IEEE 802.3, являются предметом текущих исследований. [14]
Почти во всех отношениях первоначальное предложение Дэвиса, разработанное в конце 1965 года, было похоже на реальные сети, строящиеся сегодня.
Каждая система имеет свои собственные компьютеры, выполняющие свои собственные функции.
{{cite web}}: CS1 maint: архивная копия в заголовке ( ссылка )