Анализ и оптимизация безопасного вебсокетного соединения

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

Подход, при котором существует конкретная реализация инициатора и обработчика называется программированием реакции. Все протокольные языки являются в том или ином виде реализацией программирования реакции. В ней четко распределены роли и измеряется практически все - от времени формирования запроса, до общего времени получения ответа. Подход к программированию реакции называют линейным функциональным подходом, и не смотря на его простоту - при использовании его в огромных серверных API сложность системы практически невозможно контролировать. Эта проблема появилась еще в 2000-х годах, и породила волну стандартов и архитектур. Что объясняется стремлением сделать управление подобными системами проще.

Одним из глобальных стандартов (ICC 6x) принято считать REST API. Конечно, и классический API будет считаться программированием реакции, но REST показал себя настолько удобным - что сейчас тяжело найти серверную систему без использования текущего подхода. На текущий момент существует больше 20 реализаций подходов к именованию функциональны параметров, а кол-во архитектур, реализующий REST API тяжело посчитать.

На текущий момент стандартов для интерактивных систем практически не существует, а те что есть либо следуют REST подходу, что накладывает некоторые ограничения, либо решают узконаправленные задачи, не применимые для широкого круга. В качестве примера можно рассмотреть APNS сервера, которые реализуют интерактивность, но на уровне архитектуры не учитывают наличие реакции на запрос. Что делают систему абсолютно неспособной с моментальному реагированию на события, вынуждает разработчиков проверять доставленность сообщения и следовать протоколам используемых платформ. Следующие легко продемонстрировать в любом платформе, имеющей APNS сертификацию:

interface IMessageCallback

{

[OperationContract(IsOneWay = true)]

void OnMessageAdded(int senderId, string message, DateTime timestamp);

}

Создаём сервис контракт:

[ServiceContract(CallbackContract = typeof(IMessageCallback))]

public interface IMessageService

{

[OperationContract]

void AddMessage(int senderId, int recipientId, string message);

[OperationContract]

bool Subscribe();

}

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

От выбора базовой архитектуры зависит степень быстродействия и потребность в ресурсах системы. Чтобы быть объективным, все собранные системы мы будем тестировать в одинаковых условиях - две независимые серверные стойки Dell PowerEdge R610, (2x Xeon X5650 2.66GHz Six Core Processors, 64GB Memory, 6x 2.5" Hard Drive Trays With Screws, PERC 6/I Controller, IDRAC6 Enterprise, 2x Power Supplies, Rails, Front Bezel). Это не самые лучшие комплектующие, но учитывая что нам нужно определить лучший метод - нам и не нужны высокие требования к ресурсам, достаточно одинаковых. Две стойки будут независимыми и общаться по протоколу TCP IP, который и будет единственным каналом связи. Перед каждым тестом машины будут перезапущены. Тестирование будем проводить для общих условий - 1000 запросов попеременно, обмен флагами.

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

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

Также условимся что обе стойки обладают идентичным программным обеспечением, соединены оба к одному порту - 8080.

Для расширения протокла до безопасного мы будем использовать стандарт AES. Этот алгоритм преобразует один 128-битный блок в другой, используя секретный ключ который нужен для такого преобразования. Для расшифровки полученного 128-битного блока используют второе преобразование с тем же секретным ключом. Выглядит это так:

cipher = encrypt(block, key) // шифруем block с помощью key

block = decrypt(cipher, key) // расшифровываем cipher с помощью key

Размер блока всегда равен 128 бит. Размер ключа также имеет фиксированный размер. Чтобы зашифровать произвольный текст любым паролем можно поступить так:

1. получить хеш от пароля,

2. преобразовать хеш в ключ по правилам описанным в стандарте AES,

3. разбить текст на блоки по 128 бит,

4. зашифровать каждый блок функцией cipher.

Это можно записать так:

hash = md5(password) // MD5 хеш имеет длину 128 бит

key = keyexpansion(hash) // преобразуем хеш в ключ

blocks = split(text, 16) // разбить текст на блоки по 16 байт

for (i = 0; i < blocks.length; i++)

cipher[i] = encrypt(blocks[i], key)

Чтобы расшифровать массив блоков cipher нужно применить к каждому блоку decrypt:

hash = md5(password)

key = keyexpansion(hash)

for (i = 0; i < cipher.length; i++)

blocks[i] = decrypt(cipher[i], key)

Мы смогли реализовать интерактивную систему, используя расширение канала HTTP, что означает что все текущие расширения так же будут поддерживаться и WS. Система является полностью интерактивной и промышленно применимой.

Проводя тестирование мы увидели что LoongPooling не может быть использован в промышленном стеке, так как требует большого объема оперативной памяти и довольно быстро достигает критической точки. Эта зависимость будет работать для любого объема оперативной памяти.

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

WS же держит нагрузку линейно, что важно для промышленного применения. Так же оба клиента поддерживают протоколы килентов, что означает избыточность канала и гарантированность доставки. Callback предусматривается протоколом, что позволяет говорить о преимуществе над двумя другими системами.

Расширение канала до безопасного позволит использовать закрытое соединение для аунтификации и передачи важной информации. Так же это показатель для использования в промышленных серверных системах и проектах.

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

В качестве сфер применения можно обозначить использование WWW, построение экосистемы из судов (для обмена и корректировки информации) и других отраслях, где используется модель сообщения об изменениях.