пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ IDS/IPS
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Чтобы понять сложные вещи, нам на помощь очень часто приходят простые примеры из жизни. Сейчас предлагаем просто посмотреть на свой шкаф: возможно там царит полный порядок, а возможно, анархия. Для нашего примера понадобятся оба! Для начала представим и заглянем в шкаф, где полный беспорядок: все намешано, найти что-то сложно (не говоря о том, чтобы это что-то еще и было не мятое). Переместимся в шкаф, где царит порядок, и там есть отдельные ящики для каждой категории одежды. Всё разложено по полочкам, и без труда можно найти всё, что нужно. Так вот, микросервисная архитектура по своей сути похожа на этот шкаф с идеальным порядком, только вместо шмоток — программные компоненты. Микросервисы — это не просто модный тренд в IT, а реальная необходимость для многих компаний. Почему? Потому что современные приложения становятся всё более сложными и большими, а пользователи всё более требовательными. Никто не хочет ждать, пока приложение загрузится, или терпеть сбои из-за одной маленькой ошибки. И тут то мир подарил нам микросервисную архитектуру, дабы все упорядочить.
Микросервисная архитектура — это подход к разработке программного обеспечения, при котором приложение делится на множество независимых компонентов (или сервисов). Каждый из них отвечает за свою конкретную задачу и может работать автономно. Как в нашем идеальном шкафу: отдельная полка для футболок, штанов, носков и так далее. Что еще более важно, если какой-то компонент вышел из строя: то все остальные продолжают свою работу как ни в чём не бывало. Погрузимся же глубже.
Почему именно микросервисная архитектура?
Чтобы понять, почему микросервисы стали такими популярными, стоит понять, чем они отличаются от монолитного подхода. Рассмотрим монолитное приложение как один огромный швейцарский нож. Да, он умеет всё: и резать колбаску, и открывать пиво, и чинить батарею. Но вот проблема: если один из инструментов сломается (например, лезвие затупится), то пользоваться ножом становится неудобно или даже невозможно. Но рассмотрим аналог швейцарскому ножу, т.е. простой набор инструментов: нож, открывашка, отвёртка — каждый из них работает независимо от другого. Если нож затупился, то всё ещё можно открыть бутылку. Неплохо, верно?
Монолитное приложение — это единый большой блок кода, где все части тесно связаны друг с другом. Например, если ты разрабатываешь интернет-магазин, то в монолите всё будет в одном месте: и корзина покупок, и система оплаты, и поиск товаров. Казалось бы, удобно? Только на первый взгляд. Проблемы начинаются, когда нужно внести изменения. Допустим, ты решил обновить алгоритм поиска товаров. Трогаешь одну часть кода, а что-то неожиданно ломается в корзине или на странице оплаты. Напоминает игру в дженгу и бесконечные попытки поймать все баги.
Микросервисы же работают по-другому. Здесь каждая функция приложения — это отдельный сервис. Есть отдельный «сервис корзины», «сервис оплаты», «сервис поиска». Они общаются друг с другом через чётко определённые интерфейсы (обычно через API), но при этом остаются независимыми. Если нужно обновить алгоритм поиска, просто меняешь код в соответствующем сервисе. Остальные части приложения даже не замечают этого.
Основные принципы микросервисной архитектуры
Если микросервисы — это оркестр, то принципы, о которых мы сейчас поговорим, — это дирижёрская палочка. Без этого вся система превратится в хаотичное звучание, где барабанщик ушёл в нирвану, скрипач — в классику, а пианист вообще ушёл пить кофе. Чтобы всё работало слаженно и красиво, существуют некоторые правила, о которых сейчас и пойдёт речь.
Начнём с того, что уже частично затронули выше, а именно - независимость компонентов. Каждый микросервис — это самостоятельный механизм, который просто работает свою работу. Да, это немного, но это честная работа. Независимость позволяет командам разработчиков работать автономно. Ты можешь обновлять или чинить один сервис, не боясь, что где-то в другом месте что-то сломается.
Далее в списке идёт возможность развертывания отдельных модулей. В микросервисах ты можешь развернуть (или обновить) только один конкретный сервис, а не всё приложение целиком. Поиграем снова в имадженариум, вообразим в этот раз интернет-магазин. Нужно улучшить алгоритм рекомендаций товаров. В монолите вам пришлось бы обновить весь код приложения, протестировать его и переживать за возможные сбои. А с микросервисами ты просто выкатываешь обновление для «сервиса рекомендаций», и всё остальное продолжает работать как ни в чём не бывало. Звучит как сказка, ну… почти)
Чёткие границы ответственности. Каждый микросервис отвечает за свою чётко определённую задачу. Что также удобно при работе в команде, ведь видно сразу разделение обязанностей не только в программных компонентах, но и среди разработчиков. Чёткие границы ответственности делают систему понятной и предсказуемой. Если что-то пошло не так (например, клиент не может оформить заказ), то не нужно ковыряться в монолите кода, искать, где конкретно и кто писал эту функцию, достаточно понять, какой именно это микросервис.
Окей, это было просто понять, но вот как микросервисы между собой вообще работают? Они же не должны работать всё равно вместе. Ответ прост и состоит из трёх букв – API (а вы о чём подумали?). Микросервисы общаются друг с другом через API (Application Programming Interface) — это чётко определённый язык общения между сервисами. Он позволяет каждому сервису быть независимым и при этом эффективно взаимодействовать с другими.
Познакомились с базой, так, а что там по соотношениям плюсов к минусам? Ща разложим карты и на это.
Плюсы, минусы и вызовы микросервисной архитектуры
Конечно же, начнем с плюсов микросервисной архитектуры (а ведь их реально много). Вот они, сверху вниз:
Масштабируемость.
В случае, если вашему приложению пришло время «подрасти», то с микросервисами достаточно просто добавить воды! Ладно, на самом деле увеличить мощность только необходимых сервисов или же написать новые, и не трогать остальные. Аналогично работает и с простыми обновлениями.
Независимость разработчиков по отдельности или же команд по отдельности
(в зависимости от масштаба). Они могут работать над своим микросервисом, не мешая другим. Результат? Быстрее, чище и без лишнего стресса. Тут в целом все просто. Как и во всем, если разобраться)
Надёжность
. Этого нам всем не хватает, а вот микросервесы умеют и делают. Если один сервис упал, остальные продолжают работать. Например, если в приложении временно недоступен сервис рекомендаций товаров (потому что кто-то где-то накосячил), пользователи всё равно смогут оформить заказ.
Плюсы простые, но безумно нужные. А теперь пришло время минусов.
Сложность управления.
Чем больше микросервисов, тем сложнее ими управлять. Прикинь, если бы у тебя было 50 котиков: каждый требует внимания, ухода и еды. В итоге ты больше времени тратишь на организацию, чем на саму работу.
Сетевые задержки.
Микросервисы взаимодействуют друг с другом через сеть, а это значит, что могут возникать задержки. Например, если «сервис корзины» медленно отвечает «сервису заказов», пользователь может подумать, что приложение зависло. А если сервисов много (как и предполагается), и если хотя бы некоторые из них медленно передают друг другу API, то скорости нам не видать.
Затраты
… Всего... Каждый микросервис требует своих ресурсов: серверов, баз данных и инструментов мониторинга, людей и печенек. В итоге можно потратить больше денег на инфраструктуру, что не всегда возможно, да и вообще нужно, особенно в небольших проектах.
Сложность тестирования
. Тестировать микросервисы сложнее, чем монолитное приложение. Это нужно убедиться не только в том, что каждый сервис работает правильно, но и в том, что они корректно взаимодействуют друг с другом. А это все тянет за собой все тот же пункт про затраты.
С глобальными минусами на этом все. Согласись, они были не столь очевидны. Немаловажным вопросом так же является вопрос «А когда микросервисы могут быть избыточными?»
Когда нужны микросервисы
Не всегда стоит бежать за модой и переходить на микросервисы только потому, что «все так делают, значит круто». Иногда это просто лишняя головная боль. И так, когда же?
Небольшие проекты или стартапы. Если проект небольшой (например, приложение для учёта личных расходов), то микросервисы будут избыточны. Также, если у команды банально нет опыта. Если команда никогда раньше не работала с микросервисами, переход на них может превратиться в кошмар из бесконечных багов и срывов сроков. Не того мы хотели ведь, правда? Исходя из статьи про затраты, не трудно догадаться, что если ресурсы ограничены, то микросервисы не наш выбор, ведь они требуют больше серверов, инструментов мониторинга и специалистов по DevOps, что не сочетается с маленькой командой и небольшим бюджетом.
Собственно, микросервисы – это очень крутая тема, но, как и все в этом мире, она хорошо работает только там, где нужна. Микросервисная архитектура – относительно новый тренд и как мы поняли, это очень классный тренд, помогающий увеличить эффективность разработки многократно на больших проектах. Следим за новшествами и дальше, кто знает, что изобретут уже завтра?
Сейчас существует очень много различных программ, которые помогают правильно настроить то или иное программное обеспечение. Для того, чтобы программа эффективно работала, необходимо воспользоваться реальной или виртуальной машиной. Также, имеет смысл воспользоваться программным окружением Vagrant, которое поставляется вместе с программой Ansible после покупки лицензии. Прежде чем приступать непосредственно к настройке программы, необходимо узнать, что это вообще такое и какие функции выполняет.
Что такое программа Ansible и для чего она нужна?
Данная программа нужна для того, чтобы управлять различными программными конфигурациями для того, чтобы разрабатывать приложения на языке Python. Ansible представляет собой список программ, объединенных в пакет для управления специальными конфигурациями. Благодаря данному пакету программ можно настраивать те или иные удалённые машины и управлять ими на большом расстоянии. На сегодняшний день настройка программы Ansible осуществляется путём изучения пособия по следующим главам:
Прежде всего, специалисты обучают новичка работе с установщиком. При этом, нужно будет установить программу Ansible вместе с утилитой под названием Vagrant.
Далее идет полное изучение так называемого файла инвентаризации.
После того, как файл инвентаризации был настроен и как следует изучен пользователем, необходимо перейти к непосредственному сбору факторов, переменных, copy и shell. Всё это нужно установить и настроить, дабы не возникало никаких проблем, связанных с дальнейшей эксплуатацией пакета Ansible для настройки удалённых машин.
После этого осуществляется процесс, в который входит детальная настройка нескольких хостом.
Немаловажным этапом идёт настройка плейбуков.
В качестве примера стоит вспомнить настройку кластера через Apache, который включает в себя поэтапный балансировщик уровня нагрузки на удалённую машину.
После того, как все предыдущие 6 шагов были совершены, необходимо перейти к откату и изучению ошибок.
С каждым запуском ошибок должна становится всё меньше, что приведет к формированию паттерна действий системы.
Установка программы Ansible завершается установкой и настройкой ролей каждого узла.
Сама по себе, данная программа (один из вариантов графического интерфейса) выглядит так:
В чём заключается настройка программы Ansible на практике?
Утилита Ansible работает в проталкивающимся режиме. Он включает в себя использование всех настроек главной машины, с которой и осуществляются все наработки и разработки узлов. Основная машина тянет определенные узлы и ветки, осуществляя поэтапную постепенную нагрузку системы вместе с ее настройкой.
Какие пакеты и модули нужны для работы утилиты Ansible?
Как показала практика, для работы данной утилиты достаточно иметь следующие типы модулей:
Модуль под названием jinja2
Вспомогательный модуль типа yaml
Следует сказать, что прежде чем устанавливать данную программу, необходимо понять, что она работает исключительно на Linux и его дистрибутивах. Как правило, самыми популярными дистрибутивами Linux для работы программы Ansible являются Ubuntu или дебиан. Через командную строку нужно запустить соответствующую команду, которая отправить запросы на запуск установщика Ansible. Внутри нужно будет найти соответствующие пакеты, которые потом должны быть переписанные в командную строку. После того, как программа Ansible было установлена, нужно будет постепенно перейти к установке дополнительной утилиты, которое было упомянута выше. Данная утилита носит название Vagrant.
Как правильно установить Vagrant на Linux систему?
В качестве основной среды для установки данной программы лучше всего использовать так называемую виртуальную машину. Виртуальная машина нужна для того, чтобы не нагружать основную систему и создать дополнительную среду для Vagrant. Сам по себе, процесс установки данной программы включает в себя скачивание следующего софта:
Непосредственно сама виртуальная машина или Virtualbox.
В том случае, если после установки Virtualbox не возникло никаких проблем, стоит перейти к поиску ещё 1 немаловажной программы под названием Ruby. Если речь идёт о современных дистрибутивах Linux, таких, как Debian или Ubuntu, то стоит с уверенностью сказать, что программа уже имеется в системе. Если же я говорится о старых версиях Ubuntu или Debian, то нужно будет перейти на файлообменники и скачать Ruby на свой персональный компьютер.
Завершающим этапом установки является скачивание на персональный компьютер ещё 1 немаловажной программы под названием Vagrant 1.1+. Ее можно найти на официальном сайте.
Дальнейшим этапом будет создание работающего файла виртуальной машины. Команда, запускающая программу в виртуальной машине, выглядит таким образом: «vagrant up». После ее активации процесс запустится и можно переходить к другим шагам. Для некоторых систем потребуется получить права суперпользователя или ввести Root ключ. Его нужно заранее узнать у администратора или вспомнить, если речь идёт о домашнем персональном компьютере. В виртуальной машине нужно будет добавить соответствующие ключи SSH, дабы продолжить процесс. Процесс будет запущен спустя несколько минут после того, как соответствующие команды будут введены. Программа взаимодействует следующим образом:
Дальнейшим этапом будет создание файла inventory. Для того, чтобы создать соответствующий файл, необходимо прописать в нём следующие команды.
host0.example.org ansible_ssh_host=192.168.33.10 ansible_ssh_user=root
host1.example.org ansible_ssh_host=192.168.33.11 ansible_ssh_user=root
host2.example.org ansible_ssh_host=192.168.33.12 ansible_ssh_user=root
Следует сказать, что строка под названием «ansible_ssh_host» содержит в себе уникальный адрес IP хоста. Его должен знать каждый человек, который устраивает полную настройку системы.
Завершающим этапом всех манипуляций, которые были приведены выше, является полная проверка путем вписывания соответствующих строк кода в командную строку. Первым делом нужно будет выполнить следующую команду:
ansible -m ping all -i step-01/hosts
При первых этапах проверки Ansible пытается запустить модуль под названием ping. В том случае, если программа работала верно, то и результат будет выглядеть следующим образом:
host0.example.org | success >> {
"changed": false,
"ping": "pong"
}
host1.example.org | success >> {
"changed": false,
"ping": "pong"
}
host2.example.org | success >> {
"changed": false,
"ping": "pong"
}
Если данного кода нет, то что-то не так и необходимо будет искать решение проблемы на сторонних ресурсах. Консультирование со специалистом поможет избежать проблем в будущем. Всё, узлы настроены и теперь можно переходить к дальнейшим действиям.
Как правильно настраивать отдельные узлы, используя основную машину?
Для того, чтобы узлы могли взаимодействовать между собой, необходимо воспользоваться одноимённой командой ansible. После того, как она была введена, узлы будут взаимодействовать между собой и передавать друг другу определенные массивы зашифрованной информации.
Как запустить много хостов, если использовать всего лишь одну команду?
Использование одной команды для запуска нескольких узлов является очень важной вещью в создании качественно работающих систем. Если в одну систему были собраны определённые машины под управлением одной и той же операционной системы, то стоит ввести следующую команду, так как вся информация будет собрана на одну машину, с которой эта самая команда и была введена.
ansible -i step-02/hosts -m shell -a 'uname -a' host0.example.org
Если всё было правильно сделано, то все хосты должны дать следующий вывод касательно своего статуса:
host1.example.org | success | rc=0 >>
DISTRIB_RELEASE=12.04
host2.example.org | success | rc=0 >>
DISTRIB_RELEASE=12.04
host0.example.org | success | rc=0 >>
DISTRIB_RELEASE=12.04
Каждый элемент будет подсвечен, а также будет передан его статус. Для того, чтобы получить гораздо больше информации касательно того или иного элемента, нужно вести другую команду с модулем setup. Данный модуль собирают гораздо больше информации с каждого узла, точно также передавая ей на основную платформу. В качестве примера ответа будет следующая конструкция:
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"192.168.0.60"
],
"ansible_all_ipv6_addresses": [],
"ansible_architecture": "x86_64",
"ansible_bios_date": "01/01/2007",
"ansible_bios_version": "Bochs"
},
---snip---
"ansible_virtualization_role": "guest",
"ansible_virtualization_type": "kvm"
},
"changed": false,
"verbose_override": true
Выводы можно сокращать для того, чтобы получать более простые конструкции, однако их суть останется прежней.
Особенности архитектуры программы Ansible
Архитектура Ansible включает в себя следующие разнообразные модули:
Модуль Cloud позволяет управлять публичными или частными облаками от таких компаний, как Amazon, Azure , Docker, Openstack и другие;
Command делает выполнение консольных команд максимально простым и отлаженным;
Monitoring занимается мониторингом всех данных.
Также, сюда можно включить еще множество различных модулей для правильной работы удаленных машин. И, как мы уже говорили, Ansible работает исключительно на дистрибутивах Linux и не содержит в себе протоколов для работы с Windows или Mac OS. Основными дистрибутивами для работы Ansible являются Debian и Ubuntu. Удачи вам в освоении мира DevOps!
Почитать лекцию №20 про протоколы передачи данных нижнего уровня можно тут.
Обычно называется и маркируется как Wi-Fi 802.11, который широко используется для передачи данных по беспроводной сети в радиочастотах 2,4 и 5 ГГц. Микроволновые печи, радиолокационные системы, Bluetooth, некоторые любительские радиосистемы и даже радионяня также используют радиочастоту 2,4 ГГц, поэтому WiFi может создавать помехи и мешать работе другим системам.
Мультиплексирование
Спецификации 802.11 обычно используют форму частотного мультиплексирования для передачи большого количества информации по одному каналу или набору частот. Частота сигнала-это просто скорость, с которой сигнал меняет полярность в течение одной секунды; следовательно, сигнал 2,4 ГГц-это электрический сигнал, передаваемый по проводу, оптическому волокну или воздуху, который меняет полярность с положительной на отрицательную (или отрицательную на положительную) 2,4 × 109 раз в секунду.
Чтобы понять основы беспроводной передачи сигналов, лучше всего начать с рассмотрения идеи несущей и модуляции. Рисунок 1 иллюстрирует эти концепции.
На рисунке 1 выбрана одна центральная частота; канал будет представлять собой диапазон частот по обе стороны от этой центральной частоты. В результирующем канале две несущие частоты выбираются таким образом, чтобы они были ортогональны друг другу-это означает, что сигналы, передаваемые на этих двух несущих частотах, не будут мешать друг другу. Они обозначены на рисунке как OSF 1 и OSF 2. Каждая из этих несущих частот, в свою очередь, фактически является более узким каналом, позволяя модулировать фактический сигнал "0" и "1" на канале. Модуляция, в данном случае, означает изменение фактической частоты сигнала вокруг каждой из частот.
Модуляция просто означает изменение несущей таким образом, чтобы сигнал передавался так, чтобы приемник мог его надежно декодировать.
Таким образом, в спецификации 802.11 используется схема мультиплексирования с ортогональным частотным разделением каналов (Orthogonal Frequency Division Multiplexing- OFDM), а фактические данные кодируются с использованием частотной модуляции (Frequency Modulation-FM).
Важно
Один из сбивающих с толку моментов мультиплексирования заключается в том, что оно имеет два значения, а не одно. Либо это означает размещение нескольких битов на одном носителе одновременно, либо возможность одновременного взаимодействия нескольких хостов с использованием одного и того же носителя. Какое из этих двух значений подразумевается, можно понять только в конкретном контексте. В этой лекции применяется первое значение мультиплексирования, разбиение одного носителя на каналы, чтобы можно было передавать несколько битов одновременно.
Скорость, с которой данные могут передаваться в такой системе (полоса пропускания), напрямую зависит от ширины каждого канала и способности передатчика выбирать ортогональные частоты. Таким образом, для увеличения скорости 802.11 были применены два разных метода. Первый - просто увеличить ширину канала, чтобы можно было использовать больше несущих частот для передачи данных. Второй - найти более эффективные способы упаковки данных в один канал с помощью более сложных методов модуляции. Например, 802.11b может использовать канал шириной 40 МГц в диапазоне 2,4 ГГц, а 802.11ac может использовать канал шириной 80 или 160 МГц в диапазоне 5 ГГц.
Пространственное мультиплексирование
Другие формы мультиплексирования для увеличения пропускной способности между двумя устройствами также используются в серии спецификаций 802.11. Спецификация 802.11n представила Multiple Input Multiple Output (MIMO), которые позволяют сигналу проходить разными путями через единую среду (воздух). Это может показаться невозможным, поскольку в комнате только один "воздух", но беспроводные сигналы фактически отражаются от различных объектов в комнате, что заставляет их проходить через пространство разными путями. Рисунок 2 демонстрирует это.
На рисунке 2, если предположить, что передатчик использует антенну, которая будет передавать во всех направлениях (всенаправленная антенна), есть три пути через одно пространство, помеченные 1, 2 и 3. Передатчик и приемник не могут "видеть" три отдельных пути, но они могут измерять силу сигнала между каждой парой антенн и пытаться посылать различные сигналы между внешне разделенными парами, пока не найдут несколько путей, по которым могут быть отправлены различные наборы данных.
Второй способ использования нескольких антенн - это формирование луча. Обычно беспроводной сигнал, передаваемый от антенны, охватывает круг (3D-шар). При формировании луча, он формируется с помощью одного из различных методов, чтобы сделать его более продолговатым. Рисунок 3 иллюстрирует эти концепции.
В несформированном узоре сигнал представляет собой шар или шар вокруг кончика антенны- нарисованный сверху, он выглядит как простой круг, простирающийся до самой дальней точки в форме шара. С помощью отражателя луч может быть сформирован или сформирован в более продолговатую форму. Пространство позади отражателя и по бокам луча будет получать меньше (или вообще не получать, для очень плотных лучей) мощности передачи. Как можно построить такой отражатель? Самый простой способ - это физический барьер, настроенный на отражение силы сигнала, подобно тому, как зеркало отражает свет или стена отражает звук. Ключ - это точка в сигнале передачи, в которой устанавливается физический барьер. Рисунок 4 будет использоваться для объяснения ключевых моментов в форме сигнала, отражении и гашении.
Типичная форма волны следует за синусоидальной волной, которая начинается с нулевой мощности, увеличивается до максимальной положительной мощности, затем возвращается к нулевой мощности, а затем проходит цикл положительной и отрицательной мощности. Каждый из них представляет собой цикл- частота относится к числу повторений этого цикла в секунду. Вся длина волны в пространстве вдоль провода или оптического волокна называется длиной волны. Длина волны обратно пропорциональна частоте- чем выше частота, тем короче длина волны.
Ключевой момент, который следует отметить на этой диаграмме, - это состояние сигнала в точках четверти и половины длины волны. В четвертьволновой точке сигнал достигает наивысшей мощности; если объект или другой сигнал интерферирует в этой точке, сигнал будет либо поглощен, либо отражен. В точке полуволны сигнал находится на минимальной мощности; если нет смещения или постоянного напряжения на сигнале, сигнал достигнет нулевой мощности. Чтобы отразить сигнал, вы можете расположить физический объект так, чтобы он отражал мощность только в точке четверти волны. Физическое расстояние, необходимое для этого, будет, конечно, зависеть от частоты, так же как длина волны зависит от частоты.
Физические отражатели просты. Что делать, если вы хотите иметь возможность динамически формировать луч без использования физического отражателя? Рисунок 5 иллюстрирует принципы, которые вы можете использовать для этого.
Светло-серые пунктирные линии на рисунке 5 представляют собой маркер фазы; два сигнала находятся в фазе, если их пики выровнены, как показано слева. Два сигнала, показанные в середине, находятся на четверть вне фазы, так как пик одного сигнала совпадает с нулевой точкой или минимумом второго сигнала. Третья пара сигналов, показанная в крайнем правом углу, является комплементарной, или на 180 градусов вне фазы, так как положительный пик одного сигнала совпадает с отрицательным пиком второго сигнала. Первая пара сигналов будет складываться вместе; третья пара сигналов будет погашена. Вторая пара может, если она правильно составлена, отражать друг друга. Эти три эффекта позволяют сформировать пучок, как показано на рисунке 6.
Одна система формирования луча может использовать или не использовать все эти компоненты, но общая идея состоит в том, чтобы ограничить луч в пределах физического пространства в среде - как правило, свободное распространение в воздухе. Формирование луча позволяет использовать общую физическую среду в качестве нескольких различных каналов связи, как показано на рисунке 7.
На рисунке 7 беспроводной маршрутизатор использовал свои возможности формирования луча для формирования трех разных лучей, каждый из которых направлен на другой хост. Маршрутизатор теперь может отправлять трафик по всем трем из этих сформированных лучей с более высокой скоростью, чем если бы он обрабатывал все пространство как единую совместно используемую среду, потому что сигналы для A не будут мешать или перекрываться с информацией, передаваемой в B или C.
Совместное использование канала
Проблема мультиплексирования в беспроводных сигналах связана с совместным использованием одного канала, как в системах проводных сетей. В решениях, разработанных для совместного использования единой беспроводной среды, преобладают две специфические проблемы: проблема скрытого узла и проблема мощности передачи / приема (которую также иногда называют перегрузкой приемника). На рисунке 8 показана проблема со скрытым узлом.
Три круга на рисунке 8 представляют три перекрывающихся диапазона беспроводных передатчиков в точках A, B и C. Если A передает в сторону B, C не может слышать передачу. Даже если C прослушивает свободный канал, A и C могут передавать одновременно, что вызывает конфликт в B.
Проблема скрытого узла усугубляется из-за того, что мощность передачи по сравнению с мощностью принятого сигнала, и реальность воздуха как среды. Главное практическое правило для определения мощности радиосигнала в воздухе - сигнал теряет половину своей мощности на каждой длине волны в пространстве, которое он проходит. На высоких частотах сигналы очень быстро теряют свою силу, что означает, что передатчик должен послать сигнал с мощностью на несколько порядков больше, чем его приемник способен принять.
Очень сложно создать приемник, способный "слушать" локальный передаваемый сигнал в полную силу, не разрушая приемную схему, а также способный "слышать" сигналы очень низкой мощности, необходимые для расширения диапазона действия устройства. Другими словами, передатчик насыщает приемник достаточной мощностью, чтобы во многих ситуациях "уничтожить" его. Это делает невозможным в беспроводной сети для передатчика прослушивать сигнал во время его передачи и, следовательно, делает невозможным реализацию механизма обнаружения коллизий, используемого в Ethernet (как пример).
Механизм, используемый 802.11 для совместного использования одного канала несколькими передатчиками, должен избегать проблем со скрытым каналом и приемником. 802.11 WiFi использует множественный доступ с контролем несущей / предотвращение конфликтов (Carrier Sense Multiple Access/Collision Avoidance -CSMA/CA) для согласования использования канала. CSMA/CA похож на CSMA/CD:
Перед передачей отправитель прослушивает сообщение, чтобы определить, передает ли его другое устройство.
Если слышна другая передача, отправитель "замирает" на определенный случайный период времени перед повторной попыткой- эта отсрочка предназначена для предотвращения того, чтобы несколько устройств, слышащие одну и ту же передачу, не пытались передать данные одновременно.
Если никакой другой передачи не слышно, отправитель передает весь кадр- отправитель не может принять сигнал, который он передает, поэтому в этой точке нет способа обнаружить коллизию.
Получатель отправляет подтверждение кадра при получении; если отправитель не получает подтверждения, он предполагает, что произошла коллизия, отключается на случайное количество времени и повторно отправляет кадр.
Некоторые системы WiFi также могут использовать Request to Send/Clear to Send (RTS / CTS). В таком случае:
Отправитель передает RTS.
Когда канал свободен, и никакая другая передача не запланирована, получатель отправляет CTS.
Получив CTS, отправитель передает данные
Какая система будет обеспечивать более высокую пропускную способность, зависит от количества отправителей и получателей, использующих канал, длины кадров и других факторов.
Маршалинг данных, контроль ошибок и управление потоком данных
Маршалинг данных в 802.11 аналогичен Ethernet; в каждом пакете есть набор полей заголовка фиксированной длины, за которыми следуют транспортируемые данные и, наконец, четыре октетная Frame Check Sequence (FCS), которая содержит CRC для содержимого пакета. Если получатель может исправить ошибку на основе информации CRC, он это сделает, в противном случае получатель просто не подтверждает получение кадра, что приведет к повторной передаче кадра отправителем.
Порядковый номер также включен в каждый кадр, чтобы гарантировать, что пакеты принимаются и обрабатываются в том порядке, в котором они были переданы. Управление потоком обеспечивается в системе RTS / CTS приемником, ожидающим отправки CTS, пока у него не будет достаточно свободного места в буфере для приема нового пакета, чтобы промежуточные системы могли обнаруживать конечные системы; это называется протоколом End System to Intermediate System (ES-IS).