 |
|
|
|
Альтернативные беспроводные средства связи
Альтернативные беспроводные средства связи Лидером в области беспроводных сетей на данный момент является стандарт Wi-Fi, который в будущем, возможно, будет заменен на WiMAX. Но, несмотря на распространенность, Wi-Fi обладает многими недостатками, есть ли альтернативные решения для организации беспроводной сети? Беспроводные сети все больше и больше вытесняют с рынка проводные решения. Связано это с тем, что идея использовать вместо проводной связи радиоволны крайне привлекательна, позволяя решать массу технических, экономических и административных проблем. Какие решения для организации беспроводных сетей можно найти сегодня на рынке? Несомненно, лидирующее положение сегодня занимает знакомый многим стандарт Wi-Fi (Wireless Fidelity, ieee 802.11), идеально подходящий для организации локальной сети там, где применение стандартного проводного оборудования нецелесообразно по экономическим соображениям или невозможно технически. К сожалению, к недостаткам данного стандарта можно отнести малую область покрытия – сотни метров, хотя очень многое зависит от используемых частот и оборудования (на практике энтузиасты, используя направленные антенны, расположенные «в чистом поле», добивались устойчивой связи на расстоянии 5 километров). Для организации беспроводной связи на значительные расстояния можно прибегнуть к продолжению стандарта Wi-Fi – WiMAX (Worldwide Interoperability for Microwave Access, ieee 802.16). Теоретически WiMAX позволяет «покрыть» область, равную 112,6 километра, при скорости передачи в 70 Мб/c. Правда, на практике цифры «немного» скромнее: радиус покрытия – до 10 километров, а скорость передачи всего несколько мегабит. Скромные технические характеристики объясняются тем, что стандарт с момента первой публикации в 2001 году множество раз дополнялся и изменялся, а производители оборудования, спешившие выпустить его, отталкивались от незавершённых вариантов ieee 802.16, что привело к множеству проблем. На данный момент сложилась ситуация, что оборудование разных производителей зачастую несовместимо друг с другом (выпущенное даже по одной спецификации). Несомненно только одно, что аналогично с Wi-Fi для достижения хороших показателей необходимы качественные антенны передатчики-приемники (к сожалению, очень дорогостоящие). У представленных стандартов радиосвязи (да и многих других) есть один явный недостаток – малая зона покрытия, низкая скорость передачи, но самое главное, при большом количестве помех между приемником и передатчиком (в городах – дома, на пересеченной местности – возвышенности) дальность зоны покрытия сильно сокращается либо вообще невозможна. Как же быть, если необходимо наладить связь в гористой местности или мегаполисе? Использовать спутник для двухсторонней связи крайне неэкономично, прокладка витой пары или оптоволокна зачастую невозможна технически. Кажется, что мы опять возвращаемся к старым проблемам, подобным проводным сетям. К счастью, для каждой задачи всегда есть альтернативные решения, сегодня мы рассмотрим один весьма перспективный стандарт RFC 1149 и его логическое продолжение RFC 2549. RFC 1149 Итак, стандарт RFC 1149 «A Standard for the Transmission of IP Datagrams on Avian Carriers» [1] был предложен Дэвидом Вейтцманом (David Waitzman) в 1991 г. В стандарте описывается экспериментальный метод инкапсуляции IP-дейтограмм в птичьих курьерах. С самого начала – о грустном. К недостаткам птичьих курьеров можно отнести: высокую задержку, низкую пропускную способность, низкое качество обслуживания, а также недостаточный контроль самого процесса и наличие так называемого птичьего фактора, который необходимо учитывать в создании данного метода. Организация сети ограничена топологией точка-точка (point-to-point) для каждого птичьего курьера, но возможно использовать многопоточность, так как трехмерный эфир связи позволяет использовать множество курьеров, при этом пакеты не перекрываются друг другом, как это бывает в проводных сетях (исключение – весна, в данный сезон почтовые курьеры могут перекрывать друг друга, что может привести к коллизии и полной потере пакета). Теперь о положительных моментах. Птицы имеют собственную систему предотвращения столкновения, которая увеличивает качество обслуживания. В отличие от радиоволн передача не ограничена обзором радиолуча и с легкостью огибает любые препятствия как естественного, так и искусственного происхождения (горы, дома, леса, глушители и другие). Последний критерий должен способствовать внедрению RFC 1149 в мегаполисах, где количество препятствий для радиоволн достаточно велико. Как это работает? IP-пакет печатается на листе бумаги в hex-формате, далее пакет скручивается вокруг ноги птичьего курьера и закрепляется либо специальным кольцом (подобные кольца можно купить в зоомагазинах), либо резинкой. Нужно сразу уточнить, что размер пакета будет ограничен длиною ноги птицы. MTU, к сожалению, точно не определен и, как это ни парадоксально, вообще увеличивается с возрастом курьера. Типичный MTU – 256 миллиграммов. Итак, после отправки пакета птичий курьер достигает получателя. Там напечатанный IP-пакет разворачивается, сканируется (подойдет даже ручной сканер) и вводится в ЭВМ. Нужно отметить, что возможна и ручная обработка пакета. Дэвид Вейтцман хоть и не уточняет, какое оборудование на канальном уровне модели OSI использовать лучше всего, но явно намекает, что для реализации спецификации лучше всего подходят почтовые голуби. С чем это связано? Почтовые голуби уже давно хорошо зарекомендовали себя для отправки коротких сообщений на большие расстояния (не путать с SMS!), связано это с тем, что за последние 200-300 лет селекционным путем были выведены специальные виды этих птиц, способные преодолевать расстояние до 3000 км! Даже WiMAX не может тягаться с такой зоной покрытия. Птицы с легкостью решают проблемы информационной безопасности, так как в них крайне эффективно реализованы механизмы уничтожения червей и других паразитов. Также в случае необходимости возможно шифрование пакета. При проведении аудита подобной сети, при поиске потерянных пакетов следует обращать внимание на крыши домов и телефонные столбы (в сельской местности), именно в таких местах чаще всего теряются пакеты. Связано это в первую очередь с упомянутым временем года – весна, так как в это время года голуби самогенерируются, что, с одной стороны, является минусом (временная потеря данных), а с другой – плюсом данной спецификации (прирост оборудования). Итак, рассмотрев рекомендации спецификации, уважаемый читатель, возможно, скептически отнесется к практической реализации данного стандарта, поэтому рассмотрим опыт европейских коллег по внедрению RFC 1149. Практическая реализация RFC 1149 Несмотря на весь скептицизм, нашлись энтузиасты, которые смогли по достоинству оценить возможные выгоды использования данного протокола и реализовали его на практике. Ими оказались представители норвежской пользовательской группы Bergen Linux User Group (BLUG) [2], которые смогли доказать, что RFC 1149 действительно работает. Итак, 28 апреля 2001 года в 12.00 начались испытания протокола. Для проведения эксперимента заранее было решено выполнить команду ping между двумя компьютерами, пересылая ICMP-запросы. Также было создано специальное ПО для вывода/ввода пакетов в ЭВМ под управлением ОС Linux (которое теперь доступно для загрузки с официального сайта BLUG). Пакеты печатались на обычной бумаге формата A4 небольшими блоками, далее необходимая информация вырезалась ножницами и пакет прикреплялся к голубям. Птицы выпускались с интервалом 7,5 минуты, чтобы избежать коллизии и накладок. Нужно заметить, что был прекрасный солнечный день и некоторые птицы (как выяснилось позже) присоединились к пролетающей стае голубей, которые так и не вернулись. Отправив ICMP Echo-Request-запрос, энтузиасты стали ждать информации от получателей. Через некоторое время первые голуби стали прибывать, и что же увидели получатели после сканирования пакета?
Начало было положено, все ждали оставшихся птиц, и, не заставив долго ждать, стали прибывать остальные пакеты. Несмотря на то что голуби выпускались с интервалом в 7,5 минуты, некоторые прибыли одновременно, что добавило энтузиастам немного хлопот. После ввода всех пакетов птицы отправлялись обратно с соответствующими ICMP Echo-Reply-ответами. В конце процедуры была получена статистика команды ping:
Итак, давайте вместе подсчитаем скорость передачи данных по голубиной сети. Среднее время передачи равно 64 байт в 5222 секунды (примерно 1 час 45 минут), тогда: 64/5222*8=0,1 бит в секунду. Нужно заметить, что в ходе эксперимента использовались почтовые голуби, которые давно не выполняли своих прямых обязанностей, в связи с этим и произошли курьезы: полная потеря пяти пакетов и длительные перелеты нулевого и первого пакетов. Сделаем небольшие подитоги. Несмотря на то, что из девяти голубей пакеты доставили только четыре (преодолев расстояние примерно в пять километров) и большое время передачи (около двух часов), спецификация RFC 1149 доказала свое право на жизнь, а это самое главное. Несмотря ни на что не стоит забывать, что описанные спецификации RFC исключительно экспериментальные, поэтому подлежат дальнейшей проработке и обсуждению. Полную статистику и другие подробности можно посмотреть на сайте группы норвежских энтузиастов [2], там же расположены фотографии процесса создания, отправки/получения пакетов и другие знаменательные моменты. Итоги В первую очередь хочется поблагодарить Дэвида Вейтцмана и IETF (Internet Engineering Task Force), эту знаменитую международную группу проектировщиков, инженеров, сетевых администраторов и провайдеров, ведь именно эти люди занимаются развитием протоколов и архитектуры Интернета. Итак, спецификация доказала свое право на жизнь, открывая пользователям и администраторам новые возможности. Несмотря на весь скептицизм, многие компании – лидеры по производству сетевого оборудования официально поддерживают обе спецификации. Например, компания Cisco, по достоинству оценившая RFC Дэвида Вейтцмана, согласилась в экспериментальных целях включать поддержку этих спецификаций, правда, только один раз в году – каждое 1 апреля. Приложение Альтернативные средства передачи данных В настоящее время многие организации испытывают нехватку мощностей выделенных линий, несмотря даже на то, что интернет-провайдеры постоянно снижают тарифы на каналы связи и поднимают скорости передачи данных – этого недостаточно. Мечта любого системного администратора – 100 мегабитная линия, ну а просто сказочный сон – гигабитное оптоволоконное соединение! Фантастика? Но давайте не будем спешить, возможно, есть альтернативы стандартным средствам передачи данных. Зачастую многие из нас для передачи больших объемов данных (дистрибутивы ОС, базы данных и другое) используют обычные оптические носители, воспользуемся данным методом и рассчитаем скорость передачи информации, передаваемой КамАЗом, груженным DVD-дисками и двигающимся со скоростью 100 километров в час. Итак, за основу возьмем КамАЗ модель 43118. Объем его кузова примерно равен 24 кубометра, исходя из этого диски будем укладывать в коробки, равные 1 кубометру. Один DVD-диск в стандартном боксе занимает размер 14,2х12,5х1 (длина/ширина/высота в сантиметрах). Произведем расчет технических параметров, по которым можно узнать, сколько дисков войдет в одну коробку:
Теперь рассчитаем один слой в коробке: 7*8=56 и умножим на количество слоев, то есть на 100, получим 5600. Итак, в одной коробке помещается 5600 дисков, умножим это число на количество коробок, то есть на 24, получим 134400 дисков. Умножим общее количество компакт-дисков на объем информации, расположенной в них: 134400*4,7 Гб получим 631680 Гб. Теперь рассчитаем скорость передачи в секундах, так как изначальная в часах, для этого разделим получившееся число на 3600, получаем 175.4 Гб в секунду. И последнее, переведем байты в биты. 175.4*8=1,403 Тб в секунду. Задумайтесь! 1,4 Тб в секунду! Пожалуй, эта скорость с лихвой опережает спутниковую связь. Конечно, мы пренебрегли такими параметрами, как время записи дисков и расстояние между точками, но это незначительные факторы. Для повышения скорости передачи данных можно организовывать автомобилям «зеленые» коридоры (чтобы избежать пробок). Для этого, например, выделим КамАЗы из общего автомобильного потока, сделав на кузове большими буквами надпись – Internet. Некоторые факты о RFC 2549 В 1999 году Дэвид Вейтцман выпустил дополнение к RFC 1149 – RFC 2549 (IP over Avian Carriers with Quality of Service) [3], рассказывая о некоторых рекомендациях к базовой спецификации. Итак, какие уровни качества обслуживания (тот самый QoS, который некоторым системным администраторам уже в ночных кошмарах снится) можно применить к данной спецификации, повысив эффективность передачи данных? Уровни качества обслуживания бывают: СВ, купе, плацкарт... Ну а если серьезно, Дэвид рекомендует использовать страусов в качестве оборудования на канальном уровне для доставки пакетов. Высокая скорость передачи данных, большой MTU, но это плюсы, есть и минусы, страусы не летают, поэтому между конечными узлами сети необходимо наличие мостов. Также Дэвид предупреждает: несмотря на высокую популярность пингвинов использовать их не рекомендуется – они так же, как и страусы, не летают (правда, в арктических условиях их применение может быть весьма актуально, так как «птицы»-амфибии лучше всего справятся с айсбергами). Использование Beastie (того самого демоненка), так же как и пингвина, весьма сомнительно и остается открытым вопросом, которым, несомненно, должно озаботиться сообщество Open Source. Продолжая тему оборудования, стоит заметить одну деталь: окна могут привлекать почтовых голубей, сбивая своим блеском их с пути. Исходя из этого стоит остерегаться прокладывать маршруты около окон и тем более не следует прокладывать маршруты через них. При практической реализации RFC 1149 специалисты из BLUG ссылались на то, что необходима очередь пакетов (подобная очереди в TCP/IP). Данный вопрос был освещен в RFC 2549, где рекомендуется маркировать птиц штрих-кодами (RFID-чипы тоже подойдут), а птиц, стоящих в очереди, метить гуашью, например красным цветом. Проведенные эксперименты показали, что применение NATs подобных технологий неприемлемо для эффективной организации сети на почтовых голубях, связано это с тем, что птицы могут просто съесть NATs. Также в ходе проведенных экспериментов удалось выяснить TTL, в среднем он составляет 15 лет, но опять же очень многое зависит от типа используемого оборудования. В основном RFC 2549 дает некоторые рекомендации, рассказывает о возможных подводных камнях при проектировании сети, но в основном первая спецификация остается базовой, именно на нее стоит опираться при создании сети. Более подробные рекомендации и схемы по RFC 2549 можно найти в самой спецификации.
|
Иван МаксимовКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
