По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Подход DevSecOps с частым систематическим сканированием приложений на наличие уязвимостей значительно увеличивает процент программного обеспечения с исправленными уязвимостями и сокращает время, необходимое для выпуска исправлений, что особенно важно в контексте критических ошибок. Согласно Veracode State of Software Security Vol. 10, по сравнению с 2018 годом процент уязвимых приложений увеличился в 2019 году с 52 до 56%. С другой стороны, в случае приложений, сканируемых один раз в месяц или реже, среднее время обновления составляло 68 дней, в то время как приложения, сканируемые не реже одного раза в день, имели в среднем 19 дней для обновления.
Эти результаты, а также выводы исследования Enterprise Strategy Group подтверждают, насколько сегодня важно последовательно и как можно раньше расширять процесс разработки приложений до стадии тестирования безопасности. В прошлом эта задача входила в обязанности отдела безопасности и выполнялась после завершения программирования. Сегодня сами разработчики также должны продемонстрировать соответствующие компетенции.
Новые модели и способы доставки программного обеспечения - общедоступное облако, контейнеры и микросервисы - положили конец большим выпускам приложений и редким обновлениям. Вместо них у нас есть молниеносные циклы публикации, а приложения разделены на более мелкие, независимо работающие модули. В результате программное обеспечение просто создается слишком быстро, и новые версии приложения, так называемые выпуски могут идти "в производство" в оптовых количествах даже на один день, чтобы проверка безопасности по методологии WaterFall была эффективной. Ситуация дополнительно осложняется тем фактом, что конечный продукт, то есть приложение с определенной функциональностью, содержит как код, созданный внутри компании, так и элементы, заимствованные из открытых бесплатных репозиториев или через менеджеры пакетов).
Следовательно, функционирование разработки, операций и безопасности как отдельных организационных структур не существует и не может существовать. Разработчикам следует понимать, что поддержка и защита программного обеспечения также зависят от них.
Отчетность. Важная штука, не правда ли? Особенно в крупном контакт - центре, где контроль за SLA и работой тысяч операторов является критическим бизнес - узлом.
Ранее, мы рассказывали про UCCE. Это такой большой контакт - центр от Cisco для больших компаний. А сегодня мы поговорим Cisco Unified Intelligence Center (CUIC), как его еще называют “куик". Обзор возможностей, архитектура и термины продукта в статье.
Зачем нужен?
CUIC позволяет работать с историческими данными и данными реального времени. “Куик" можно установить по модели standalone, когда у вас будет только 1 сервер, или кластеризовать это решение, добавив в него до 8 серверов.
В CUIC можно добавлять различные отчеты, в том числе кастомизированные, править отображение отчетов, делать его в формате диаграмм, чартов, делать “пермалинки" (ссылки по web на отчет), дашборды и многие другие функции.
Архитектура
С точки зрения высокоуровневой архитектуры, CUIC работает вот так:
Итак, с точки зрения высокоуровневой архитектуры:
Пользователь (супервайзер) через браузер делает обращение в CUIC для генерации отчета;
Веб запрос обрабатывается web - сервером в кластере серверов Unified Intelligence Center;
Данные “парсятся" черед Data source (датасорс, источник данных);
Датасорс предоставляет отчеты реального времени или исторические с UCCE или CVP сервера отчетности;
Кстати, подключить CUIC можно и к данным UCCX
При подключении к UCCE (в CUIC есть отдельный пункт настройки Data Sources), мы указываем подключение серверу AWDB (Administrative Workstation DB). По факту, это просто SQL - плечо по 1433 порту (если не меняли).
Как мы сказали ранее, по факту, CUIC - визуализатор данных из БД источников. Предварительная настройка его в этом и заключается - настроить источники данных (data sources).
Разобрались с архитектурой. Теперь давайте посмотрим, как выглядит CUIC.
Как выглядит CUIC?
Давайте быстро пробежимся по UI интеледженс центра. Форма авторизации весьма стандартная:
Чуть раньше в статье мы говорили про создание Data Source для CUIC - источников данных. Вот как этот конфигуратор выглядит в реальности:
Тут совершенно ничего сложного. Просто плечо в БД.
Теперь про отчеты. Вот так выглядит дашборд в системе. Обратите внимание, на нем преднастроены отчеты, стикеры (позволяющие запинить важные данные, например), фреймы на нужные веб - ресурсы:
CUIC начиная с 12 версии
В 12 версии Cisco прокачала свои интерфейсы в контакт - центровых продуктах (ну или купила компанию, которая это делает, сами понимаете). Изменения в плоскости интерфейса коснулись так же и агентского рабочего места Finesse. Посмотрите еще раз на скриншот выше. А теперь посмотреть, как изменился UI интерфейс CUIC:
Задержка в сети, или сетевая задержка, - это временная задержка при передаче запросов или данных от источника к адресату в сетевой экосистеме. Давайте посмотрим, как вы можете выявить и устранить задержку в сети.
Любое действие, которое требует использование сети, например, открытие веб-страницы, переход по ссылке, открытие приложения или игра в онлайн-игру, называется активностью. Активность пользователя – это запрос, а время отклика веб-приложения – это время, которое требуется для ответа на этот запрос.
Временная задержка также включает в себя время, которое сервер тратит на выполнение запроса. Таким образом, временная задержка определяется как круговой путь – время для записи, обработки и получения пользователем запроса, где он уже декодируется.
Понятие «низкое значение задержки» относится к относительно недлительным временным задержкам при передаче данных. А вот длительные задержки, или чрезмерные задержки, не слишком приветствуются, так как они ухудшают процесс взаимодействия с пользователем.
Как исправить задержку в сети?
На просторах Интернета есть большое количество инструментов и программных средств, которые могут помочь в анализе и устранении неполадок в сети. Некоторые из них платные, некоторые бесплатные. Впрочем, есть инструмент под названием Wireshark – бесплатное приложение с общедоступной лицензией, которое используется для перехвата пакетов данных в режиме реального времени. Wireshark – это самый популярный и самый часто используемый в мире анализатор сетевых протоколов.
Это приложение поможет вам перехватывать сетевые пакеты и отображать их детальную информацию. Вы можете использовать эти пакеты для проведения анализа в режиме реального времени или в автономном режиме после того, как сетевые пакеты уже будут перехвачены. Это приложение поможет вам исследовать сетевой трафик под микроскопом, фильтруя и углубляясь в него в попытках найти корень проблемы. Оно помогает с сетевым анализом, и, как следствие, с сетевой безопасностью.
Что может вызывать задержку в сети?
Есть несколько основных причин медленного сетевого подключения. Вот некоторые из них:
Большая задержка
Зависимости приложений
Потеря пакетов
Перехватывающие устройства
Нерациональные размеры окон
В данной статье мы рассмотрим каждую из вышеприведенных причин задержки в сети, а также посмотрим, как можно решить эти проблемы с помощью Wireshark.
Проверка с помощью Wireshark
Большая задержка
Понятие «большая задержка» подразумевает время, которое требуется для передачи данных от одной конечной точки к другой. Влияние большой задержки на передачу данных по сети очень велико. На приведенной ниже диаграмме в качестве примера показано время кругового пути при загрузке файла по пути с высокой задержкой. Время задержки кругового пути часто превышает одну секунду, что является недопустимым.
Перейдите к разделу Wireshark Statistics.
Выберите опцию TCP stream graph.
Выберите Round Trip time graph, чтобы посмотреть, сколько времени необходимо для загрузки файла.
Wireshark используют для расчета времени кругового пути для того, чтобы определить, это ли является причиной плохой работы коммуникационной сети протокола управления передачей (TCP - Transmission Control Protocol). TCP используется для разных целей, например, для просмотра веб-страниц, передачи данных, протокола передачи файлов и многого другого. В большинстве случаев операционную систему можно настроить так, чтобы на каналах с большой задержкой она работала более эффективно, особенно когда хосты используют Windows XP.
Зависимости приложений
Некоторые приложения имеют зависимости, то есть они зависят от каких-то других приложений, процессов или от обмена данными с хостом. Допустим, что ваше приложение – это база данных, и оно зависит от подключения к другим серверам, которое необходимо для получения элементов базы данных. В таком случае слабая производительность на этих «других серверах» может негативно повлиять на время загрузки локального приложения.
Рассмотрим, например, просмотр веб-страниц при условии, что целевой сервер ссылается на несколько других веб-сайтов. Например, чтобы загрузить главную страницу сайта
www.espn.com
, вы должны сначала посетить 16 хостов, которые обеспечивают главную страницу рекламой и наполнением.
На приведенной выше картинке показано окно «HTTP/Load Distribution» в Wireshark. В нем отображается список всех серверов, которые использует главная страница сайта
www.espn.com
.
Потеря пакетов
Потеря пакетов – это одна из самых часто встречающихся проблем в сети. Потеря пакетов происходит, когда пакеты данных неправильно доставляются от отправителя к получателю через Интернете. Когда пользователь посещает некий веб-сайт и начинает загружать элементы сайта, потерянные пакеты вызывают повторную передачу, что увеличивает скорость загрузки веб-файлов и замедляет при этом общий процесс загрузки.
Более того, потеря пакетов оказывает крайне негативное влияние на приложение, когда оно использует протокол TCP. Когда TCP-соединение обнаруживает потерянный пакет, то скорость передачи данных автоматически снижается, чтобы компенсировать сетевые проблемы.
Потом скорость постепенно восстанавливается до более приемлемого уровня до следующего потерянного пакета, что снова приведет к существенному снижению скорости передачи данных. Загрузка объемных файлов, которая должна была легко проходить по сети, если бы не было потерянных пакетов, теперь заметно страдает от их наличия.
Что это значит – «пакет потерян»? Это неоднозначный вопрос. Если программа работает через протокол TCP, то потеря пакетов может быть обнаружена двумя способами. В первом варианте получатель отслеживает пакеты по их порядковым номерам и, таким образом, может обнаружить отсутствующий пакет. В таком случае клиент делает три запроса на этот отсутствующий пакет (двойное подтверждение), после чего он отправляется повторно. Во втором варианте потерянный пакет обнаруживает отправитель, когда понимает, что получатель не подтвердил получение пакета данных, и по истечении времени ожидания отправляет пакет данных повторно.
Wireshark указывает, что произошла перегрузка сети, а многократные подтверждения провоцируют повторную передачу проблематичного трафика, который выделен цветом. Большое количество продублированных подтверждений указывают на то, что пакет(ы) были потеряны, а также на существенную задержку в сети.
Для того, чтобы повысить производительность сети, важно определить точное место потери пакетов. Когда Wireshark обнаружил потерю пакетов, он начинает перемещаться по пути следования пакетов до тех пор, пока не найдет место их потери пакетов. На данный момент мы находимся «у истоков» точки потери пакетов, поэтому знаем, на чем нужно сосредоточиться при отладке.
Перехватывающие устройства
Сетевые перехватчики – это связующие устройства, такие как коммутаторы, маршрутизаторы и брандмауэры, которые заняты выбором направления передачи данных. При потере пакетов эти устройства необходимо проверить, потому что они могли стать причиной утери.
Задержка может возникнуть при работе этих связующих устройств. Например, если установлен приоритет трафика, то дополнительная задержка может возникнуть в потоке с низким уровнем приоритета.
Неэффективные размеры окон
Вдобавок к операционной системе Windows, в сетях TCP/IP есть и другие «окна».
Скользящее окно
Окно получателя
Окно отслеживания перегрузок сети
Все эти окна совместно отражают производительность сети на основе протокола TCP. Давайте посмотрим, что из себя представляет каждое из этих окон, и определим, как они влияют на пропускную способность сети.
Скользящее окно
Скользящее окно используется для широковещательной передачи последующих TCP-сегментов по сети по мере подтверждения данных. Как только отправитель получает подтверждение о том, что получатель получил переданные фрагменты данных, скользящее окно расширяется. До тех пор, пока в сети не обнаружатся потерянные данные, передавать можно достаточно большие объемы данных. При потере пакета скользящее окно сжимается, так как сеть уже не может справиться с таким большим объемом данных.
Окно получателя
Окно получателя TCP-стека – это пространство буфера. Когда данные получены, они сохраняются в этом буферном пространстве до тех пор, пока приложение их не перехватит. Окно получателя начинает заполняться, когда приложение не успевает принимать данные, что приводит к сценарию «нулевого окна». Когда получатель объявляет о состоянии «нулевого окна», вся передача данных на хост должна быть остановлена. Пропускная способность падает до нуля. Метод масштабирования окна (RFC 1323) позволяет хосту увеличить размер окна получателя и снизить вероятность наступления сценария «нулевого окна».
На приведенной выше картинке продемонстрирована 32-секундная задержка сетевого соединения из-за сценария «нулевого окна».
Окно отслеживания перегрузок сети
Окно отслеживания перегрузок сети определяет максимально возможный объем данных, с которым может справиться сеть. На это значение влияют следующие факторы: скорость передачи пакетов отправителя, количество потерянных пакетов в сети и размер окна получателя. В процессе корректной работы сети окно постоянно увеличивается до тех пор, пока передача данных не завершится или пока она не достигнет «потолка», установленного работоспособностью сети, возможностями передачи отправителя или размером окна получателя. Каждое новое соединение запускает процедуру согласования размера окна заново.
Рекомендации для хорошей работоспособности сети
Изучите, как можно использовать Wireshark в качестве меры первой помощи, чтобы можно было быстро и эффективно находить источник низкой производительности
Определите источник задержки в сети и по возможности сократите ее до приемлемого уровня
Найдите и устраните источник потери пакетов
Проанализируйте размер окна передачи данных и по возможности уменьшите его
Проанализируйте производительность перехватывающих устройств для того, чтобы посмотреть, увеличивают ли они задержку или, возможно, отбрасывают пакеты
Оптимизируйте приложение, чтобы оно могло передавать большие объемы данных и, если это возможно, извлекать данные из окна получателя
Заключение
В данной статье мы рассмотрели самые основные причины проблем с производительностью сети. Но есть один немаловажный фактор, который просто нельзя упускать, - это непонимание того, как работает передача данных по сети. Wireshark предоставляет визуализацию сети так же, как рентген или компьютерная томография, которая предоставляет визуализацию человеческого тела для точной и быстрой диагностики. Wireshark стал критически важным инструментом, который способен помочь в обнаружении и диагностике проблем в сети.
А теперь проверьте и устраните проблемы с производительностью своей сети с помощью нескольких фильтров и инструментов Wireshark.