Рубрика «Сетевые технологии» - 81

5G против Wi-Fi: ожидание и реальность - 1

В последнее время все чаще обсуждается вопрос о будущем сетей Wi-Fi в связи с ожидаемым массовым строительством сотовых сетей пятого поколения. Действительно, зачем нужен Wi-Fi в мире, где сотовые сети обеспечивают миллиарды людей высокоскоростным доступом в интернет? Остановится ли в развитии семейство стандартов Wi-Fi с приходом 5G? Уйдет ли технология с рынка, завершив свою «историческую миссию»? Всем, кто ответил на эти вопросы утвердительно, посвящается эта статья. Всем остальным, кто разбирается в сетевых технология, надеемся, тоже будет интересно почитать.

Спойлер

Проиллюстрировать текст о «борьбе» двух технологий мы решили кадрами из бессмертной трилогии «Матрица», в которой борьба между машинами и людьми закончилась сосуществованием.

Несмотря на кажущуюся важность и логичность, вопросы о соперничестве Wi-Fi и 5G построены на искусственном противопоставлении родственных по сути, но различных по моделям применения технологий. Большинство утверждений о недолговечности Wi-Fi принадлежит представителям сотовых операторов, в конце статьи мы расскажем, почему.

А пока попробуем вместе развеять два заблуждения – «5G гораздо быстрее Wi-Fi» и «Wi-Fi очень скоро умрет». Для начала вернемся в прошлое и разберемся, что же такое 5G и что такое Wi-Fi.

Читать полностью »

Введение

В этой статье мы попробуем разобраться чем на практике отличается механизм epoll от портов завершения (Windows I/O Completion Port или IOCP). Это может быть интересно системным архитекторам, проектирующим высокопроизводительные сетевые сервисы или программистам, портирующим сетевой код с Windows на Linux или наоборот.

Обе эти технологии весьма эффективны для обработки большого количества сетевых соединений.

Они отличаются от других методов по следующим пунктам:

  • Нет ограничений (кроме общих ресурсов системы) на общее количество наблюдаемых дескрипторов и типов событий
  • Масштабирование работает достаточно хорошо — если вы уже мониторите N дескрипторов, то переход к мониторингу N + 1 займёт очень мало времени и ресурсов
  • Достаточно легко задействовать пул потоков для параллельной обработки происходящих событий
  • Нет никакого смысла использовать при единичных сетевых соединениях. Все преимущества начинают проявляться при 1000+ соединений

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

5. Check Point на максимум. IPS. Часть 1 - 1

Продолжаем нашу серию уроков по Check Point. На этот раз мы обсудим одну из моих любимых тем, а именно — IPS (Intrusion Prevention System) По-русски — система предотвращения вторжений. Причем акцент именно на Prevention (т.е. предотвращение)! Одно из главных кредо компании Check Point это: “We Prevent, not detect!”. Лично я согласен с такой позицией. Какой толк от детекта, если вас атаковал например шифровальщик? Зашифрованный компьютер и так вам сообщит, что была атака. В текущих реалиях нужно позаботиться именно о Prevent. И IPS здесь может очень хорошо помочь.
Однако, в последнее время наблюдается некое пренебрежение этим классом защиты, мол “IPS больше не актуален и использовать его бессмысленно”. На мой взгляд это мнение является непростительной ошибкой. Собственно в этом уроке я постараюсь описать основные бытующие заблуждения на счет IPS. Затем в рамках лабораторной работы покажу каким образом IPS поможет усилить защиту вашей сети. Ну и конечно же постараюсь рассказать, как получить максимум от этого полезного инструмента, на какие настройки обратить внимание и о чем нужно помнить включая IPS.
Урок получился весьма длинным поэтому я разбил его на две части. Первая часть будет чисто теоретическая, а вторая уже полностью посвящена практике в виде лабораторной работы. Надеюсь, что будет интересно.
Спойлер — В конце статьи видео урок, если кому-то удобнее смотреть, а не читать.Читать полностью »

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

В этой статье мы рассмотрим:

  • select()
  • poll()
  • epoll()
  • libevent

Читать полностью »

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

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

Но у каждого метода есть свои минусы. За СМС надо платить. Email забивает пользователю глаза постоянным приходом и пользователь перестает реагировать. Отдельное приложение на телефон надо сделать под каждую платформу, установить и организовывать регистрацию токенов на внутренних серверах компании. Решение с telegram этих минусов лишено, хотя приложение должно конечно быть установлено на мобильном, десктопе или еще где-то. Впрочем у Telegram тоже есть минус. Это наш уважаемый Роскомнадзор, который очень его не любит. Это вносит некую дополнительную пикантность реализации.

Итак.
Читать полностью »

КДПВ: LLTR Часть 0 - пневмотранспорт из Футурамы

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

Начну с причины возникновения LLTR (Link Layer Topology Reveal).

У меня был один “велосипед” - синхронизатор больших файлов “на полной скорости сети”, способный за 3 часа целиком залить 120 GiB файл по Fast Ethernet (100 Мбит/с; 100BASE‑TX; дуплекс) на 1, 10, 30, или 200 ПК. Это был очень полезный “велосипед”, т.к. скорость синхронизации файла почти не зависела от количества ПК, на которые нужно залить файл. Все бы хорошо, но он требует знания топологии сети для своей работы.

Подробнее в статье про него:

Ладно, а зачем понадобилось “гонять” 120 GiB файл по сети на такое количество ПК?


Этим файлом был VHD с операционной системой, программами, и т.п. Файл создавался на мастер‑системе, а затем распространялся на все остальные ПК. VHD был не только способом доставки системы на конечные ПК, но и давал возможность восстановления исходного состояния системы при перезагрузке ПК. Подробнее в статье: “Заморозка системы: история перехода с EWF на dVHD”.


Можно продолжить цепочку дальше, но на этом я прервусь.

Существующие протоколы обнаружения топологии канального уровня (LLDP, LLTD, CDP, …) для своей работы требуют соответствующей поддержки их со стороны всех промежуточных узлов сети. То есть они требуют как минимум управляемых свитчей, которые бы поддерживали соответствующий протокол. На Хабре уже была статья, как используя эти протоколы, “определить топологию сети на уровнях 2/3 модели OSI”.

Но что же делать, если промежуточные узлы – простые неуправляемые свитчи?

Если интересно как это можно сделать, то добро пожаловать под кат. Обещаю наличие множества иллюстраций и примеров.

Читать полностью »

image

Введение:

По работе мне часто приходится работать с перепрошитыми роутерами на DD-WRT или OpenWRT. Все время как-то получалось обходиться без роутера дома, но те возможности, которые дают эти прошивки, реально классные. Вот и задумался о приобретении роутера, такого чтоб тянул все сервисы, которые мне могут понадобиться.  Остановился на выборе Asus RT-N16, но, правда, дороговата эта игрушка оказалась для меня. Это при том, что реальной необходимости в роутере не было, т.к. отлично спасала сетевая Wi-Fi карточка TP-LINK WN851ND.

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

Читать полностью »

Последнее время большую популярность приобрёл программно-аппаратный комплекс Arduino, который предназначен для разработки различных интересных электронных конструкций. Конструкции изготовляются путём соединения базовой платы Arduino с дополнительными необходимыми модулями. На базовой плате Arduino находится микроконтроллер, прошивка на который пишется в специальной среде разработки для Arduino с использованием, как правило, готовых библиотек на тот или иной модуль.

Один из модулей – W5500 – предназначен для изготовления электронных конструкций, которые будут связаны с Интернет. При этом чаще всего, подразумевается удалённое управление своей конструкцией. Например, это может быть «умный дом», робот и тому подобное. Самый тривиальный проект (кроме Hello world) – удалённое включение светодиодов через web-браузер (рис. 1). Если вместо светодиодов подключить транзисторные ключи и реле, можно коммутировать более мощные нагрузки. Таким образом, по сути, программа (прошивка) данной конструкции представляет собой web-сервер, обрабатывающий http-запросы удалённого пользователя.
Читать полностью »

image

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

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

image

В состав практически любой системы ИБ входят традиционные системы (по отдельности или в комбинации):

• Межсетевой экран (Firewall)
• Система предотвращения вторжений (IPS)
• Списки контроля доступа (ACL)
• Система контроля доступа в сеть (NAC)
• Антивирусные системы (Antivirus/Antimalware)
• Cистемы управления события ИБ (SIEM)

Все эти системы хороши как по отдельности для решения своих задач, так и в комплексе. Однако существует различные классы задач обеспечения ИБ, которые данные системы решить увы не состоянии. Тем более, что традиционный сетевой периметр, где обычно применялись традиционные средства защиты в современной сетевой инфраструктуре размыт, так как за это время появились облачные технологии, да и пользователи стали гораздо более мобильными.
Какие задачи могут решить традиционные системы, а с какими им будет справиться крайне проблематично или даже невозможно?

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js