Файл: Модель «клиент - сервер» ..pdf

Рисунок 1. Опрос (polling)

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

• очень много лишних запросов, посылаемых клиентом, когда на сервере еще нет новых данных;
• серверу приходится хранить информацию о произошедших событиях до тех пор, пока клиент не запросит их или пока они не устареют;
• события всегда приходят с опозданием, ввиду заданного интервала и времени, требуемого на открытие соединения.

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

К таким техникам относится другой способ обмена сообщениями, называемый длительный опросом (англ. long polling). После загрузки веб-страницы, клиентский код выполняет запрос, но сервер не отвечает и не закрывает соединение, пока не появятся новые данные или пока клиент не отключится самостоятельно. Как только данные появились – отправляется ответ и соединение закрывается. После чего клиент сразу же отправляет следующий запрос, снова запуская процесс ожидания (рисунок 2).

Рисунок 3. Длинный опрос (long-polling)

Достоинства этого метода по сравнению с классическим опросом (polling):

• минимальное количество запросов;
• высокая временная точность событий;
• отсутствие необходимости длительного хранения событий сервером.

После создания объекта EventSource с указанием адреса подключения браузер отправит запрос на установление соединения серверу. Чтобы соединение успешно открылось, сервер должен ответить с HTTP-заголовком "Content-Type: text/event-stream" и не закрывать соединение. После этого сервер может отправлять в открытое соединение сообщения, когда появляется новая информация (рисунок 3).

Рисунок 4. Server-Sent Events

В Server-Sent Events включена возможность отправлять идентификатор сообщения, который помогает восстановить утраченные события в случае обрыва соединения. В поддерживающих стандарт браузерах доступен удобный событийно-ориентированный программный интерфейс (API) для обработки получаемых сообщений и ошибок.

После того как установлено соединение по протоколу WebSocket, сервер и клиент могут посылать друг другу сообщения, когда новая информация доступна на одной из сторон (рисунок 5). Таким образом, обеспечивается своевременная передача необходимой информации и поддержание ее в актуальном состоянии.

Рисунок 5. WebSocket

Протокол WebSocket подробно описан в RFC 6455 [3]. Здесь лишь отметим, что формат пакета (фрейма) данных имеет компактную структуру, обеспечивая минимум накладных расходов на передачу и повышая тем самым производительность. Кроме того, фреймы делятся на два больших типа: фреймы с данными и управляющие фреймы, предназначенные для проверки связи (ping) и закрытия соединения. Помимо передачи текстовой информации, фреймы с данными могут содержать и бинарные данные.

ГЛАВА 2. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ ПОЛНОДУПЛЕКСНОГО СОЕДИНЕНИЯ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ НА РАЗЛИЧНЫХ ЯЗЫКОВЫХ ПЛАТФОРМАХ

2.1 Технология Server Push

Вторая версия протокола передачи данных HTTP предоставляет функционал Server Push. Данная технология позволяет оптимизировать работу и время загрузки веб-страниц. Доступ к веб-сайтам по протоколу HTTP всегда осуществляется по шаблону «Запрос – ответ»: клиент (браузер) отправляет запрос на удаленный сервер, который с некоторой задержкой присылает ответ с запрошенным контентом.

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

Рисунок 6. Стандартный обмен данных в протоколе HTTP/1

Очевидным недостатком такого подхода является временная задержка между получением клиентом первоначального HTML-документа и остальных файлов, необходимых для корректного отображения веб-страницы. Технология HTTP/2 Server Push позволяет отправлять ресурсы клиенту до того, как тот явно их запросит. Например, если для корректного отображения веб-страницы необходим внешний файл с таблицей стилей some-styles.css, веб-сервер может передать этот файл клиенту сразу после того, как он начал передавать изначальный HTML-документ.

Рисунок 7. Обмен данных с используя технологию Server Push протокола HTTP/2

2.2 Технология Multiplexing

HTTP/2 - это бинарный протокол. Каждому HTTP/2 запросу и ответу присваивается уникальный идентификатор, называемый “идентификатор стрима”, и каждый запрос и ответ разделяется на фреймы. Идентификатор стрима используется для определения, к какому запросу или ответу принадлежит фрейм. Стрим - это набор фреймов с одинаковым идентификатором.

Чтобы отправить запрос серверу, клиент разделяет запрос на бинарные фреймы и присваивает идентификатор стрима каждому фрейму. Затем клиент устанавливает TCP соединение с сервером, после чего начинает отправку фреймов. Сервер также отправляет ответ фреймами.

Возможность разбить HTTP запрос на независимые фреймы, расслоить их, и собрать воедино на другом конце - очень важное нововведение HTTP/2.

2.3 Технология Server-Sent Events

SSE - технология, позволяющая осуществлять передачу данных в формате text/event-stream с сервера на клиент в одностороннем порядке без дополнительных запросов от браузера и не закрывая соединение. Для получения таких событий на клиенте используется интерфейс EventSource. Основная разница с методом Polling - последний создает новое соединение на каждый запрос. Server-Sent Events - события реального времени, в этом они схожи с протоколом WebSockets. Разница состоит в одностороннем порядке передачи данных, тогда как WebSockets позволяет отправлять данные с клиента на сервер. SSE имеет ряд преимуществ:

• Если соединение прерывается, интерфейс EventSource “кидает” ошибку и автоматически пытается восстановить соединение. Также, сервер может контролировать время, после которого клиент попытается восстановить соединение.
• Для передачи данных используется стандартный протокол HTTP.
• Клиенты могут отправлять уникальный идентификатор с сообщениями. Когда клиент будет пытаться восстановить соединение, он будет знать идентификатор последнего сообщения. Таким образом, сервер может вычислить, какие сообщения не были доставлены на клиент, и отправить их.

Простейший пример клиентского кода:

// подписка на события

    var source = new EventSource('http://somesite.com/events');

    // обработка сообщений

    source.onmessage = function(event) {

            event.data; };

Каждый объект EventSource имеет свойства:

• URL - передается в конструктор класса
• Request - запрос, изначально равен null
• ReconnectionTime - время на восстановление соединения, мс
• LastEventID - идентификатор последнего события
• ReadyState - состояния соединения (connecting/open/closed)

У технологии SSE есть ряд известных недостатков. Так, например, не все современные браузеры ее поддерживают. Также для Server-Sent Events отсутствует стандартный интерфейс для реализации передачи данных с приложениями на мобильных платформах, что приводит к неконсистентности кода между проектами и отсутствию единого подхода к разработке в сообществе. В сравнении с WebSocket, недостатком Server-Sent Events является ограниченность типа передаваемой информации, а именно возможность передачи только текста в кодировке UTF-8, тогда как по протоколу WebSocket возможна передача как текста любой кодировки, так и бинарных данных. Также существенным недостатком SSE является ограниченное количество возможных одновременно открытых соединений между клиентом и сервером. Это описано в самом протоколе. Для обхода этого недостатка авторы советуют использовать сложный механизм, который подразумевает использование уникального домена для каждого соединения, или же использовать один экземпляр объекта соединения EventSource с помощью технологии “shared worker”.

Для того, чтобы оценить тренды использования приведенных выше технологий, был использован веб-сервис http://npm-stats.org. В качестве объекта исследования были взяты две самые популярные в сообществе библиотеки для языка JavaScript для Server-Sent Events и WebSocket. В первом случае это библиотека sse, во втором socket.io. В качестве временной рамки исследования был выбран период с 1 мая 2017 года по 1 мая 2018 года.

1. SSE

Рисунок 8. Количество загрузок пакета SSE в неделю

Рисунок 9. Количество загрузок пакета SSE в месяц

2. Socket.IO

Рисунок 10. Количество загрузок пакета Socket.io в неделю

Рисунок 11. Количество загрузок пакета Socket.io в месяц

Как видно из графиков, количество загрузок пакета socket.io значительно превышает количество загрузок пакета sse. Так, например, за апрель 2018 года библиотека socket.io была установлена более семи миллионов раз, тогда как библиотека sse была установлена сто сорок тысяч раз. Также исходя из количества загрузок можно оценить текущую и дальнейшую тенденцию использования данных технологий. Обе библиотеки на апрель 2018 года находятся на пике количества загрузок, что говорит о том, что, скорее всего, популярность обеих технологий будет расти в дальнейшем.

ГЛАВА 3. КЛИЕНТ-СЕРВЕРНЫЙ ПОДХОД К ЗАЩИТЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМ ИНТЕРНЕТА ВЕЩЕЙ

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

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

Использование существующих программно-аппаратных платформ, таких как Arduino, Raspberry Pi, Digi XBee и др., традиционно применяемых для прототипирования систем Интернета вещей сопряжено с наличием уязвимостей в них, обусловленных особенностями самой платформы. В  продемонстрирована незащищенность устройства Arduino Yun, построенного на базе двухуровневой архитектуре со средой выполнения Arduino на базе микроконтроллера ATmega32u4 и Linux-процессором и связующим компонентом. Arduino отличающаяся открытой, достаточно гибкой и расширяемой архитектурой (в том числе возможностью запуска требовательных к ресурсам и коммуникациям Linux-приложений на некоторых видах устройств), широкими и несложными в осуществлении возможностями прошивки устройств и подключения внешних электронных компонентов (RFID-сканеров, разнообразных сенсоров физической среды, многошаговых двигателей, модулей беспроводной связи и пр.), а также большим числом доступных программных библиотек и технической документации. В Alberca) показано, что обратной стороной открытости Arduino является ее подверженность ряду атакующих воздействий. В частности, на Arduino Yun возможна атака по компрометации ОС Linux путем эксплуатации уязвимостей на нижнем уровне прошивки (скетча), что возможно вследствие отсутствия аутентификации и выполнении с root-правами команд Linux, вызываемых из скетча через bridge-компонент. При этом если нарушитель получает неограниченный доступ к файловой системе Linux, то путем модификации системных файлов он способен влиять на параметры отображения IP-адресов и имен хостов, включение/отключение ssh-аутентификации, параметры и ключи Wi-Fi, идентификаторы процессов pid, изменять bridge-компонент, вносить изменения, которые будут сохраняться даже после возврата устройства к фабричным установкам.