По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Классификация сама по себе не приводит к определенному состоянию переадресации со стороны сетевого устройства. Скорее, классификация трафика - это первый необходимый шаг в создании основы для дифференцированного поведения пересылки. Другими словами, пакеты были классифицированы и дифференцированы, но это все. Выявление различий - это не то же самое, что дифференцированные действия с этими классами.
Наше обсуждение QoS теперь переходит в сферу политики. Как управлять перегруженными интерфейсами? Когда пакеты ожидают доставки, как сетевое устройство решает, какие пакеты будут отправлены первыми? Точки принятия решения основаны в первую очередь на том, насколько хорошо пользовательский интерфейс может выдерживать джиттер, задержку и потерю пакетов. Для решения этих проблем возникают различные проблемы и инструменты QoS.
Своевременность: организация очередей с малой задержкой
Сетевые интерфейсы пересылают пакеты как можно быстрее. Когда трафик проходит со скоростью, меньшей или равной пропускной способности выходного интерфейса, трафик доставляется по одному пакету за раз, без каких-либо проблем. Когда интерфейс может соответствовать предъявляемым к нему требованиям, перегрузки не возникает. Без перегрузок нет необходимости беспокоиться о дифференцированных типах трафика. Отметки на отдельных пакетах можно наблюдать в статистических целях, но политики QoS, которую нужно применять, нет. Трафик поступает на выходной интерфейс и доставляется.
Как было рассказано ранее в лекции "Коммутация пакетов", пакеты доставляются в кольцо передачи после коммутации. Физический процессор исходящего интерфейса удаляет пакеты из этого кольца и синхронизирует их с физической сетевой средой. Что произойдет, если будет передано больше пакетов, чем может поддерживать канал связи? В этом случае пакеты помещаются в очередь, выходную очередь, а не в кольцо передачи. Политики QoS, настроенные на маршрутизаторе, фактически реализуются в процессе удаления пакетов из очереди вывода на кольцо передачи для передачи. Когда пакеты помещаются в очередь вывода, а не в кольцо передачи, интерфейс считается перегруженным.
По умолчанию перегруженные сетевые интерфейсы доставляют пакеты в порядке очереди (FIFO). FIFO не принимает стратегических решений на основе дифференцированных классов трафика; скорее, FIFO просто обслуживает буферизованные пакеты по порядку настолько быстро, насколько это позволяет выходной интерфейс. Для многих приложений FIFO - неплохой способ удаления пакетов из очереди. Например, в реальном мире может быть небольшое влияние, если пакет протокола передачи гипертекста (HTTP, протокол, используемый для передачи информации World Wide Web) с одного веб-сервера передается раньше, чем пакет с другого веб-сервера.
Для других классов трафика большое внимание уделяется своевременности. В отличие от FIFO, некоторые пакеты следует переместить в начало очереди и отправить как можно быстрее, чтобы избежать задержки и влияния на работу конечного пользователя. Одно из последствий - это пакет, прибывающий слишком поздно, чтобы быть полезным. Другой удар заключается в том, что пакет вообще не поступает. Стоит рассмотреть каждый из этих сценариев, а затем несколько полезных инструментов QoS для каждого.
Голосовой трафик по IP (VoIP) должен вовремя. При рассмотрении голосового трафика подумайте о любом голосовом чате в реальном времени, который осуществляется через Интернет с помощью такого приложения, как Skype. В большинстве случаев качество связи приличное. Вы можете слышать другого человека. Этот человек может вас слышать. Разговор протекает нормально. С таким же успехом вы можете находиться в одной комнате с другим человеком, даже если он находится на другом конце страны.
Иногда качество звонков VoIP может снижаться. Вы можете услышать серию субсекундных заиканий в голосе человека, при этом скорость передачи голоса нерегулярна. В этом случае вы испытываете джиттер, что означает, что пакеты не поступают стабильно вовремя. Чрезмерно длинные промежутки между пакетами приводят к слышимому эффекту заикания. Хотя пакеты не были потеряны, они не были своевременно доставлены по сетевому пути. Где-то по пути пакеты задерживались достаточно долго, чтобы появились слышимые артефакты. На рисунке 5 показан джиттер при пакетной передаче.
Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением.
Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением.
Когда трафик VoIP отбрасывается, слушатель слышит результат потери. Есть пробелы, в которых голос говорящего полностью отсутствует. Отброшенные пакеты могут проходить в виде тишины, поскольку последний бит принятого звука зацикливается, чтобы заполнить пробел, продолжительное шипение или другой цифровой шум. На рисунке ниже показаны отброшенные пакеты через маршрутизатор или коммутатор.
Чтобы обеспечить стабильное качество вызовов даже в условиях перегруженности сетевого пути, необходимо применять схему приоритезации QoS. Эта схема должна соответствовать следующим критериям.
Трафик VoIP должен быть доставлен: потеря пакетов VoIP приводит к слышимому прерыванию разговора.
Трафик VoIP должен доставляться вовремя: задержка или прерывание пакетов VoIP приводит к слышимым заиканиям.
Трафик VoIP не должен ограничивать пропускную способность других классов трафика: так же важно, как и VoIP, хорошо написанные политики QoS уравновешивают своевременную доставку голосовых пакетов с необходимостью для других классов трафика также использовать канал.
Распространенной схемой, используемой для определения приоритетов трафика, чувствительного к потерям и jitter, является организация очередей с низкой задержкой (LLQ). Никакие RFC IETF не определяют LLQ; скорее, поставщики сетевого оборудования изобрели LLQ в качестве инструмента в наборе политик QoS для определения приоритетов трафика, требующего низкой задержки, jitter и потерь, например, голоса.
LLQ есть два ключевых элемента.
Трафик, обслуживаемый LLQ, передается как можно быстрее, чтобы избежать задержки и минимизировать джиттер.
Трафик, обслуживаемый LLQ, не может превышать определенный объем полосы пропускания (обычно рекомендуется не более 30% доступной полосы пропускания). Трафик, превышающий предел пропускной способности, скорее отбрасывается, чем передается. Этот метод позволяет избежать потери трафика других классов.
В этой схеме подразумевается компромисс для услуг классов трафика посредством LLQ. Трафик будет обслуживаться как можно быстрее, эффективно перемещая его в начало очереди, как только он обнаруживается на перегруженном интерфейсе. Загвоздка в том, что существует ограничение на то, сколько трафика в этом классе будет обрабатываться таким образом. Это ограничение налагается сетевым инженером, составляющим политику QoS.
В качестве иллюстрации предположим, что канал WAN имеет доступную пропускную способность 1024 Кбит/с. Этот канал соединяет головной офис с облаком WAN поставщика услуг, которое также соединяет несколько удаленных офисов с головным офисом. Это загруженный канал WAN, по которому проходит трафик VoIP между офисами, а также трафик веб-приложений и резервный трафик время от времени. Кроме того, предположим, что система VoIP кодирует голосовой трафик с помощью кодека, требующего 64 Кбит/с на разговор.
Теоретически, этот канал с пропускной способностью 1024 Кбит/с может обеспечить одновременные разговоры VoIP 16 × 64 Кбит/с. Однако это не оставит места для других типов трафика, которые присутствуют. Это занятое соединение WAN! Решение должно быть принято при написании политики QoS. Сколько голосовых разговоров будет разрешено LLQ, чтобы избежать нехватки оставшегося трафика полосы пропускания? Можно было бы сделать выбор, чтобы ограничить LLQ пропускной способностью только 512 Кбит/с, что было бы достаточно для обработки восьми одновременных разговоров, оставив остальную часть канала WAN для других классов трафика.
Предполагая, что канал перегружен, что произойдет с девятым разговором VoIP, если он должен находиться в ситуации, чтобы политика QoS была эффективной? Этот вопрос на самом деле наивен, потому что он предполагает, что каждый разговор обрабатывается отдельно политикой QoS. Фактически, политика QoS рассматривает весь трафик, обслуживаемый LLQ, как одну большую группу пакетов. После присоединения девятого разговора VoIP будет трафик на 576 Кбит/с, который будет обслуживаться LLQ, которому выделено только 512 Кбит/с. Чтобы найти количество отброшенного трафика, вычтите общий трафик, выделенный для LLQ, из общего предлагаемого трафика: 576 Кбит/с - 512 Кбит/с = 64 Кбит/с трафик LLQ будет отброшен в соответствии с ограничением полосы пропускания. Отброшенные 64 Кбит/с будут исходить от класса трафика LLQ в целом, что повлияет на все разговоры VoIP. Если десятый, одиннадцатый и двенадцатый разговор VoIP присоединиться к LLQ, проблема станет более серьезной. В этом случае 64 Кбит/с × 4 = 256 Кбит/с несоответствующего трафика, который будет отброшен из LLQ, что приведет к еще большим потерям во всех разговорах VoIP.
Как показывает этот пример, для управления перегрузкой необходимо знать состав приложений, время пиковой нагрузки, требования к полосе пропускания и доступные варианты сетевой архитектуры. Только после того, как будут учтены все моменты, можно найти решение, отвечающее бизнес-целям. Например, предположим, что 1024 Кбит/с - это максимальное значение, которое вы можете сделать для линии дальней связи из-за ограничений по стоимости. Вы можете увеличить ограничение полосы пропускания LLQ до 768 Кбит/с, чтобы обеспечить 12 разговоров со скоростью 64 Кбит/с каждый. Однако для другого трафика останется только 256 Кбит/с, чего, возможно, недостаточно для удовлетворения потребностей вашего бизнеса в других приложениях.
В этом случае можно согласовать с администратором системы голосовой связи использование голосового кодека, требующего меньшей полосы пропускания. Если новый кодек, требующий только 16 Кбит/с полосы пропускания на вызов, развернут вместо исходных 64 Кбит/с, 32 разговора VoIP могут быть перенаправлены без потерь через LLQ с выделенной полосой пропускания 512 Кбит/с. Компромисс? Качество голоса. Человеческий голос, закодированный со скоростью 64 Кбит/с, будет звучать более четко и естественно по сравнению с голосом, закодированным на скорости 16 Кбит/с. Также может быть лучше кодировать со скоростью 16 Кбит/с, чтобы отбрасывать меньше пакетов и, следовательно, общее качество лучше. Какое решение применить, будет зависеть от конкретной ситуации.
Через интерфейс может пройти больше трафика, чем указано в ограничении полосы пропускания LLQ. Если ограничение полосы пропускания для трафика, обслуживаемого LLQ, установлено на максимум 512 Кбит/с, возможно, что трафик класса более чем на 512 Кбит/с пройдет через интерфейс. Такое запрограммированное поведение проявляется только в том случае, если интерфейс не перегружен. В исходном примере, где используется кодек 64 Кбит/с, передача 10 разговоров со скоростью 64 Кбит/с по каналу приведет к передаче голосового трафика 640 Кбит/с по каналу пропускной способности 1024 Кбит/с (1024 Кбит/с - 640 Кбит/с = 384 Кбит/с осталось). Пока все другие классы трафика остаются ниже общего использования полосы пропускания 384 Кбит / с, канал не будет перегружен. Если канал не перегружен, политики QoS не вступают в силу. Если политика QoS не действует, то ограничение полосы пропускания LLQ в 512 Кбит/с не влияет на 640 Кбит/с агрегированного голосового трафика.
В этой статье о LLQ контекстом был голосовой трафик, но имейте в виду, что LLQ может применяться к любому желаемому виду трафика. Однако в сетях, где присутствует VoIP, VoIP обычно является единственным трафиком, обслуживаемым LLQ. Для сетей, в которых нет трафика VoIP, LLQ становится интересным инструментом, гарантирующим своевременную доставку с малой задержкой и дрожанием других видов трафика приложений. Однако LLQ - не единственный инструмент, доступный для составителя политики QoS. Также пригодятся несколько других инструментов.
Всем привет! Мы продолжаем рассказывать про протокол маршрутизации OSPF. В этой статье мы рассмотрим создание конкретных типов областей. Подробнее про области можно прочитать в предыдущей статье.
Предыдущие статьи:
Расширенные возможности OSPF: Области
Короткая Область (Stubby Area)
Рисунок 1 - топология OSPF
Пришло время сделать нашу область 1 из рисунка 1 короткой областью. Это внесение небольших настроек в конфигурацию. На каждом устройстве в этой области нам нужно установить область 1 в качестве заглушки. Вот наша конфигурация:
ATL2# configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router)#area 1 stub
ATL2 (config-router)#end
ATL2#
ORL# configuration terminal
Enter configuration commands, one per line. End with CNTL/Z .
ORL(config)#router ospf 1
ORL(config-router)#area 1 stub
ORL(config-router)#end
ORL#
Это вызовет сброс соседства. После внесения изменений настало время просмотреть таблицу маршрутизации и базу данных OSPF.
show ip route ospf
Как мы и надеялись, теперь таблица маршрутизации стала меньше! Больше нет детализации внешних префиксов из ASBR. Вместо этого у нас есть маршрут по умолчанию, автоматически генерируемый ABR. Этот маршрут по умолчанию конечно необходим, потому что маршрутизаторы в области 1 все еще должны иметь возможность доступа к удаленным префиксам (если это необходимо).
Теперь пришло время изучить базу данных OSPF. Это именно то, что мы ожидали бы увидеть в области заглушки:
show ip ospf database
Type 4 LSA и Type 5 LSA фильтруются, и теперь существует Type 3 LSA для маршрута по умолчанию.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Полностью Короткая Область (Totally Stubby Area)
Если мы хотим быть еще более эффективными в нашем примере, мы можем преобразовать область 1 в полностью короткую область. Это устранит Type 3 LSA, которые используются для объявления Loopback 0 на ATL и связей между ATL и AT2. Конечно, все равно будет объявлен маршрут по умолчанию, потому что теперь он нужен больше, чем когда-либо! Вот такая конфигурация и верификация:
ATL2# configuration terminal
Enter configuration commands , one per line . End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router )#area 1 stub no-summary
ATL2 (config-router )#end
ATL2#
show ip route ospf
show ip ospf database
Not So Stubby Area (NSSA)
Если вам необходимо ввести внешние префиксы в область заглушки, вы должны сделать ее Not So Stubby Area (NSSA). Это позволяет внешние префиксы, которые будут пересылаться через зону-заглушку, определять как LSA типа 7. Затем ABR преобразует их в LSA типа 5 для распространения через домен OSPF (потенциально).
Ниже настройка для нашей схемы:
ATL2# configuration terminal
Enter configuration commands , one per line. End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router)#no area 1 stub
ATL2 (config-router)#area 1 nssa
ATL2 (config-router)#end
ATL2#
ORL# configuration terminal
Enter configuration commands , one per line . End with CNTL/Z.
ORL(config)#router ospf 1
ORL(config-router)#no area 1 stub
ORL(config-router)#area 1 nssa
ORL(config)#interface loopback10
ORL(config-if)#ip address 172.16.10.З 255.255.255.0
ORL(config)#interface loopback20
ORL(config-if)#ip address 172.16.20.З 255.255.255.0
ORL(config-if)#exit
ORL(config)#router eigrp 200
ORL(config-router)#network 172.16.10.З 0.0.0.0
ORL(config-router)#network 172.16.20.З 0.0.0.0
ORL(config-router)#exit
ORL(config)#router ospf 1
ORL(config-router)#redistribute eigrp 200 subnets metric 1000
ORL(config-router)#end
ORL#
Интересно просмотреть результаты нашей настройки. Давайте начнем с изучения маршрутов OSPF и базы данных OSPF на ORL:
show ip route ospf
show ip ospf database
Из таблицы маршрутизации видно, что мы снова изучаем объявления Type 3 из области 0 (1.1.1.1 и 10.12.12.0). База данных OSPF доказывает, что NSSA работает так, как объявлено на данный момент. Мы можем видеть внешние префиксы, внесенные в область 1 как Type 7 в базе данных. Давайте быстро проверим ATL, чтобы увидеть, появляются ли они там как Type 5 LSA, как мы ожидаем.
show ip route ospf
show ip ospf database
Да, выводимая информация дает нам полное понимание, как работает NSSA. Префиксы существуют как Type 5s, и мы видим это в таблице маршрутизации.
Примечание: область NSSA не имеет динамически генерируемого маршрута по умолчанию без настройки этой функции. Так, наша сеть не будет работать! Чтобы создать маршрут по умолчанию, просто используйте следующую команду на маршрутизаторе ATL2:
area 1 nssa default-information-originate
Totally NSSA
Поскольку вы уже освоили Totally Stubby, скорее всего вы уже понимаете, что происходит с Totally NSSA. Здесь мы блокируем дополнительные типы LSA из этой области. К ним относятся Type 3 LSA. И снова для нас автоматически создается маршрут по умолчанию.
Вот настройки и результирующие проверки:
ATL2# configuration terminal
Enter configuration commands , one per line . End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router )#area 1 nssa no-summary
ATL2 (config-router )#end
ATL2#
show ip route ospf
show ip ospf database
Как видно из выводимой информации, что у нас невероятно сжатая таблица маршрутизации (для OSPF) на роутере ORL.
Как вы можете видеть, OSPF отлично справляется с автоматической фильтрацией маршрутов за счет использования специальных областей и типов LSA. В следующий раз мы рассмотрим варианты ручной фильтрации маршрутов в OSPF.
Система хранения данных - это программно-аппаратное решение для надежного и безопасного хранения данных, а также предоставления гарантированного доступа к ним.
Так, под надежностью подразумевается обеспечение сохранности данных, хранящихся в системе. Такой комплекс мер, как резервное копирование, объединение накопителей в RAID массивы с последующим дублированием информации способны обеспечить хотя бы минимальный уровень надежности при относительно низких затратах. При этом также должна обеспечиваться доступность, т. е. возможность беспрепятственной и непрерывной работы с информацией для санкционированных пользователей. В зависимости от уровня привилегий самих пользователей, система предоставляет разрешение для выполнения операций чтения, записи, перезаписи, удаления и так далее.
Безопасность является, пожалуй, наиболее масштабным, важным и труднореализуемым аспектом системы хранения данных. Объясняется это тем, что требуется обеспечить комплекс мер, направленный на сведение риска доступа злоумышленников к данным к минимуму. Реализовать это можно использованием защиты данных как на этапе передачи, так и на этапе хранения. Также важно учитывать возможность самих пользователей неумышленно нанести вред не только своим, но и данным других пользователей.
Топологии построения систем хранения данных
Большинство функции, которые выполняют системы хранения данных, на сегодняшний день, не привязаны к конкретной технологии подключения. Описанные ниже методы используется при построении различных систем хранения данных. При построении системы хранения данных, необходимо четко продумывать архитектуру решения, и исходя из поставленных задач учитывать достоинства и недостатки, присущие конкретной технологии в конкретной ситуации. В большинстве случаев применяется один из трех видов систем хранения данных:
DAS;
NAS;
SAN.
DAS (Direct-attached storage) - система хранения данных с прямым подключением (рисунок ниже). Устройство хранения (обычно жесткий диск) подключается непосредственно к компьютеру через соответствующий контроллер. Отличительным признаком DAS является отсутствие какого-либо сетевого интерфейса между устройством хранения информации и вычислительной машиной. Система DAS предоставляет коллективный доступ к устройствам хранения, однако для это в системе должно быть несколько интерфейсов параллельного доступа.
Главным и существенным недостатком DAS систем является невозможность организовать доступ к хранящимся данным другим серверам. Он был частично устранен в технологиях, описанных ниже, но каждая из них привносит свой новый список проблем в организацию хранения данных.
NAS (Network-attached storage) - это система, которая предоставляет доступ к дисковому пространству по локальной сети (рисунок выше). Архитектурно, в системе NAS промежуточным звеном между дисковым хранилищем и серверами является NAS-узел. С технической точки зрения, это обычный компьютер, часто поставляемый с довольно специфической операционной системой для экономии вычислительных ресурсов и концентрации на своих приоритетных задачах: работы с дисковым пространством и сетью.
Дисковое пространство системы NAS обычно состоит из нескольких устройств хранения, объединенных в RAID - технологии объединения физических дисковых устройств в логический модуль, для повышения отказоустойчивости и производительности. Вариантов объединения довольно много, но чаще всего на практике используются RAID 5 и RAID 6 [3], в которых данные и контрольные суммы записываются на все диски одновременно, что позволяет вести параллельные операции записи и чтения.
Главными преимуществами системы NAS можно назвать:
Масштабируемость - увеличение дискового пространства достигается за счет добавления новых устройств хранения в уже существующий кластер и не требует переконфигурации сервера;
Легкость доступа к дисковому пространству - для получения доступа не нужно иметь каких-либо специальных устройств, так как все взаимодействие между системой NAS и пользователями происходит через сеть.
SAN (Storage area network) - система, образующая собственную дисковую сеть (рисунок ниже). Важным отличием является то, что с точки зрения пользователя, подключенные таким образом SAN-устройства являются обычными локальными дисками. Отсюда и вытекают основные преимущества системы SAN:
Возможность использовать блочные методы хранения - базы данных, почтовые данные,
Быстрый доступ к данным - достигается за счет использования соответствующих протоколов.
Системы резервного копирования данных
Резервное копирование - процесс создания копии информации на носителе, предназначенном для восстановления данных в случае их повреждения или утраты. Существует несколько основных видов резервного копирования:
Полное резервное копирование;
Дифференциальное резервное копирование;
Инкрементное резервное копирование.
Рассмотрим их подробнее.
Полное резервное копирование. При его применении осуществляется копирование всей информации, включая системные и пользовательские данные, конфигурационные файлы и так далее (рисунок ниже).
Дифференциальное резервное копирование. При его применении сначала делается полное резервное копирование, а впоследствии каждый файл, который был изменен с момента первого полного резервного копирования, копируется каждый раз заново. На рисунке ниже представлена схема, поясняющая работу дифференциального резервного копирования.
Инкрементное резервное копирование. При его использовании сначала делается полное резервное копирование, затем каждый файл, который был изменен с момента последнего резервного копирования, копируется каждый раз заново (рисунок ниже).
К системам резервного копирования данных выдвигаются следующие требования:
Надежность - обеспечивается использованием отказоустойчивого оборудования для хранения данных, дублированием информации на нескольких независимых устройствах, а также своевременным восстановлением утерянной информации в случае повреждения или утери;
Кроссплатформенность - серверная часть системы резервного копирования данных должна работать одинаково с клиентскими приложениями на различных аппаратно-программных платформах;
Автоматизация - сведение участие человека в процессе резервного копирования к минимуму.
Обзор методов защиты данных
Криптография - совокупность методов и средств, позволяющих преобразовывать данные для защиты посредством соответствующих алгоритмов.
Шифрование - обратимое преобразование информации в целях ее сокрытия от неавторизованных лиц. Признаком авторизации является наличие соответствующего ключа или набора ключей, которыми информация шифруется и дешифруется. Криптографические алгоритмы можно разделить на две группы:
Симметричное шифрование;
Асимметричное шифрование.
Под симметричным шифрованием понимаются такие алгоритмы, при использовании которых информация шифруется и дешифруется одним и тем же ключом. Схема работы таких систем представлена на рисунке ниже.
Главным проблемным местом данной схемы является способ распределения ключа. Чтобы собеседник смог расшифровать полученные данные, он должен знать ключ, которым данные шифровались. Так, при реализации подобной системы становится необходимым учитывать безопасность распределения ключевой информации для того, чтобы на допустить перехвата ключа шифрования.
К преимуществам симметричных криптосистем можно отнести:
Высокая скорость работы за счет, как правило, меньшего числа математических операций и более простых вычислений;
Меньшее потребление вычислительной мощности, в сравнении с асимметричными криптосистемами;
Достижение сопоставимой криптостойкости при меньшей длине ключа, относительно асимметричных алгоритмов.
Под асимметричным шифрованием понимаются алгоритмы, при использовании которых информация шифруется и дешифруется разными, но математически связанными ключами - открытым и секретным соответственно. Открытый ключ может находится в публичном доступе и при шифровании им информации всегда можно получить исходные данные путем применения секретного ключа. Секретный ключ, необходимый для дешифрования информации, известен только его владельцу и вся ответственность за его сохранность кладется именно на него. Структурная схема работы асимметричных криптосистем представлена на рисунке ниже.
Ассиметричные криптосистемы архитектурно решают проблему распределения ключей по незащищенным каналам связи. Так, если злоумышленник перехватит ключ, применяемый при симметричном шифровании, он получит доступ ко всей информации. Такая ситуация исключена при использовании асимметричных алгоритмов, так как по каналу связи передается лишь открытый ключ, который в свою очередь не используется при дешифровании данных.
Другим местом применения асимметричных криптосистем является создание электронной подписи, позволяющая подтвердить авторство на какой-либо электронный ресурс.
Достоинства асимметричных алгоритмов:
Отсутствует необходимость передачи закрытого ключа по незащищенного каналу связи, что исключает возможность дешифровки передаваемых данных третьими лицами,
В отличии от симметричных криптосистем, в которых ключи шифрования рекомендуется генерировать каждый раз при новой передаче, в асимметричной их можно не менять продолжительное время.
Подведём итоги
При проектировании таких систем крайне важно изначально понимать какой должен получиться результат, и исходя из потребностей тщательно продумывать физическую топологию сети хранения, систему защиты данных и программную архитектуру решения. Также необходимо обеспечить резервное копирование данных для своевременного восстановления в случае частичной или полной утери информации. Выбор технологий на каждом последующем этапе проектирования, зачастую, зависит от принятых ранее решений, поэтому корректировка разработанной системы в таких случаях, нередко, затруднительна, а часто даже может быть невозможно.