💎 Дневник разработчика CRYSTAL #3: Сравнительное исследование производительности и кибербезопасности клиент-серверного взаимодействия в технологических стеках LARS и SAHAR

1. Введение

В рамках непрерывного совершенствования архитектуры социальной сети CRYSTAL и поиска оптимального технологического стека для версии CRYSTAL v3.0, мной было проведено исследование двух архитектурных решений: LARS и SAHAR.

Данный анализ включает комплексный аудит производительности, профилирование сетевой нагрузки и оценку уровня кибербезопасности клиент-серверного взаимодействия.

Целью исследования является обоснование выбора наиболее эффективной, отказоустойчивой и защищенной архитектуры для социальной сети CRYSTAL.

2. Описание прототипов

Для проведения объективного тестирования мной были разработаны два функционально и визуально идентичных прототипа. Оба приложения выполняют CRUD-операции (добавление, чтение, обновление и удаление текста в базе данных) в интерактивном режиме без полной перезагрузки страницы:

Архитектурная особенность прототипов

Прототипы были спроектированы с соблюдением стратегии Progressive Enhancement. Эмуляция жестких ограничений клиентской среды проводилась через настройки конфигурации браузера Firefox (переход по адресу - about:config). Отключение JavaScript выполнялось переключением параметра javascript.enabled в значение false. Дополнительно для стека LARS была протестирована принудительная блокировка WASM путем переключения параметра javascript.options.wasm в значение false.

Результаты тестирования подтвердили, что обе архитектуры сохраняют 100% функциональности при отключении технологий на стороне клиента. Стек SAHAR сохраняет работоспособность при отключении JavaScript. Стек LARS сохраняет работоспособность как при отключении JavaScript, так и при отключении WASM. Во всех этих случаях системы переходят на использование нативных HTML-форм с полной (классической) перезагрузкой страницы, что обеспечивает отказоустойчивость интерфейса.

3. Характеристики локального ПК и тестовая среда

Развертывание базы данных, серверной инфраструктуры, компиляция проектов и профилирование сетевого трафика осуществлялись на локальном ПК со следующими характеристиками:

• OS: Debian 12
• Browser: Mozilla Firefox Developer Edition 157.0b3 (64-bit), без плагинов
• Network environment: локальный loopback-интерфейс 127.0.0.1
• CPU: i5-12600K
• RAM: 80GB DDR4
• GPU: RTX 3050 8GB
• SSD: Kingston KC600 256GB

4. Профилирование прототипов (Dev/Debug и Release)

Этап 1: Профилирование в режиме разработки (Dev/Debug)

На первом этапе сборка и запуск проектов осуществлялись в режиме отладки через команды cargo leptos watch (LARS) и cargo run (SAHAR).

Мониторинг сетевого трафика выявил значительные накладные расходы архитектуры SPA. Суммарная сетевая нагрузка при первичной инициализации приложения составила 7.75 MB за 6 HTTP-запросов. Для первичной инициализации приложения браузер вынужден загружать неоптимизированный бинарный модуль WASM (.wasm) объемом 7.66 MB, содержащий полный движок реактивности и отладочные символы. Интеграция данного модуля с DOM-деревом требует наличия дополнительного JavaScript-моста объемом 58.28 kB. При этом базовый HTML-документ составляет 19.76 kB, так как включает в себя массив сериализованных данных, необходимых для процесса гидратации (восстановления состояния) на клиенте.

Скрин 1: Анализ метрик LARS (Dev/Debug)

Суммарная сетевая нагрузка при первичной инициализации приложения составила 91.11 kB за 4 HTTP-запроса. Переход на гипермедийную архитектуру продемонстрировал радикальную оптимизацию протокола обмена данными уже на этапе разработки. Стартовый объем HTML-документа составил 2.60 kB. Динамическое обновление интерфейса обеспечивается единственным статичным скриптом HTMX (используется базовая минифицированная версия htmx.min.js без дополнительного GZIP-сжатия) объемом 79.76 kB. Необходимость в загрузке WASM и использовании виртуального DOM отсутствует.

Скрин 2: Анализ метрик SAHAR (Dev/Debug)

Этап 2: Профилирование в режиме эксплуатации (Release)

На втором этапе к обоим прототипам были применены базовые релизные компиляторные оптимизации Rust (LLVM opt-level 3: Function Inlining, Constant Folding, Dead Code Elimination) запускаемые через команды cargo leptos serve --release (LARS) и cargo run --release (SAHAR). Команды запускались без дополнительных настроек в Cargo.toml.

Стандартная оптимизация релизной сборки продемонстрировала существенные результаты. Суммарная сетевая нагрузка при первичной инициализации приложения составила 806.31 kB за 5 HTTP-запросов. Объем передаваемого WASM-модуля сократился до 771.96 kB, размер JavaScript-моста уменьшился до 25.47 kB, а HTML-документа до 1.89 kB. Однако фундаментальная архитектурная проблема «Толстого клиента» сохраняется: при динамическом обновлении данных (сохранение/чтение текста) LARS инициирует два раздельных POST-запроса (save_content и get_content), осуществляя передачу сериализованных данных в формате JSON. Несмотря на малый объем пакетов (по 123 B), браузер вынужден выполнять синтаксический анализ (парсинг) переданного JSON, обрабатывать его посредством WASM-движка, вычислять разницу (diff) виртуального DOM и лишь затем инициировать перерисовку интерфейса.

Скрин 3: Анализ метрик LARS (Release)

Суммарная сетевая нагрузка при первичной инициализации приложения составила 91.11 kB за 4 HTTP-запроса. На стороне клиента архитектура сохранила максимальный уровень легковесности: стартовый HTML составляет 2.60 kB. Главное архитектурное преимущество раскрывается при взаимодействии клиента с сервером (сохранении или изменении текста): вместо обмена JSON-данными сервер возвращает готовый микрофрагмент HTML объемом всего 1.77 kB. Браузер нативно интегрирует данный фрагмент в целевой узел DOM-дерева без проведения дополнительных вычислительных операций.

Скрин 4: Анализ метрик SAHAR (Release)

5. Сравнение структуры первичного HTML-ответа

Структура первичного HTML-ответа LARS (Release)

<!DOCTYPE html>
<html lang="en">

<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<!>
		<link rel="modulepreload" href="/pkg/enter_text_lars.js" crossorigin="Lsr7NfkNhwfrD_wwUzAssQ">
		<link rel="preload" href="/pkg/enter_text_lars.wasm" as="fetch" type="application/wasm"
			crossorigin="Lsr7NfkNhwfrD_wwUzAssQ">
		<script type="module" nonce="Lsr7NfkNhwfrD_wwUzAssQ">(function (root, pkg_path, output_name, wasm_output_name) {
				import(`${root}/${pkg_path}/${output_name}.js`)
					.then(mod => {
						mod.default({ module_or_path: `${root}/${pkg_path}/${wasm_output_name}.wasm` }).then(() => {
							mod.hydrate();
						});
					})
			})
				("", "pkg", "enter_text_lars", "enter_text_lars");</script><!--HEAD-->
		<link id="leptos" rel="stylesheet" href="/pkg/enter_text_lars.css">
		<title>Enter Text (LARS)</title>
</head>

<body>
	<main>
		<div class="container">
			<h1 class="title">Enter Text (LARS)</h1>
			<div class="card">
				<p class="card-label">Text from ScyllaDB:</p>
				<h2 class="db-text">Sample text</h2>
				<hr class="separator">
				<div class="controls">
					<form action="/api/save_content18064880299772172936" method="post">
						<div class="input-row"><input type="text" name="content" placeholder="Enter text..."
								class="input-field"><button type="submit" class="btn btn-black">Update</button></div>
					</form>
					<form action="/api/delete_content18064880299772172936" method="post"><button type="submit"
							class="btn btn-red">Delete</button></form>
				</div>
			</div>
		</div>
	</main>
</body>

</html>
<script
	nonce="Lsr7NfkNhwfrD_wwUzAssQ">__RESOLVED_RESOURCES = []; __SERIALIZED_ERRORS = []; __PENDING_RESOURCES = [0,]; __RESOURCE_RESOLVERS = [];</script>
<script nonce="Lsr7NfkNhwfrD_wwUzAssQ">__RESOLVED_RESOURCES[0] = "\"Sample   text\"";</script>
<script nonce="Lsr7NfkNhwfrD_wwUzAssQ">__INCOMPLETE_CHUNKS = [];</script>

Архитектура LARS успешно реализует серверный рендеринг (SSR). Данные: <h2>Sample text</h2> уже встроены в DOM-дерево на момент отдачи страницы сервером. Это гарантирует отличные SEO показатели, так как поисковые роботы мгновенно индексируют контент без необходимости выполнять JavaScript.

Однако анализ выявляет фундаментальный архитектурный конфликт между механикой SPA-гидратации и современными стандартами кибербезопасности. Для того чтобы WASM-клиент не делал повторный «холостой» запрос в базу данных при первичной загрузке страницы, фреймворк Leptos вынужден сериализовать стартовое состояние базы данных (__RESOLVED_RESOURCES) и внедрять его прямо в HTML-документ в виде инлайнового (внутреннего) скрипта, туда же помещается скрипт инициализации самого WASM-модуля.

С точки зрения кибербезопасности, наличие любых инлайновых скриптов является главной уязвимостью для XSS-атак (Cross-Site Scripting). Чтобы защитить систему, внедряется строгая политика CSP (Content Security Policy), блокирующая выполнение любого встроенного кода. И именно здесь архитектура LARS сталкивается с неизбежным компромиссом: чтобы разрешить выполнение собственных системных скриптов Leptos, но заблокировать скрипты злоумышленников, сервер Actix Web при каждом HTTP-запросе вынужден тратить процессорное время на генерацию уникального криптографического ключа — nonce (например, nonce="Lsr7NfkNhwfrD_wwUzAssQ"). Сервер должен динамически внедрить этот ключ как в HTTP-заголовки, так и в каждый тег <script> в DOM-дереве. Этот механизм жизненно необходим LARS, но он неизбежно увеличивает вычислительную нагрузку на сервер и усложняет конвейер отдачи контента.

При этом стоит отметить высокий стандарт проектирования Leptos: фреймворк "из коробки" поощряет соблюдение стратегии Progressive Enhancement. Достаточно использовать базовый декларативный компонент <ActionForm action=save_content_action>, и при SSR-генерации Leptos автоматически сформирует правильную разметку с нативными HTML-атрибутами action и method. Это гарантирует, что если WASM-модуль не скачается из-за сетевого сбоя или блокировки, сохранение данных произойдет через классическую отправку формы с перезагрузкой страницы.

Структура первичного HTML-ответа SAHAR (Release)

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Enter Text (SAHAR)</title>
    <!-- HTMX Configuration: disable inline indicator styles to comply with strict CSP -->
    <meta name="htmx-config" content='{"includeIndicatorStyles": false}'>
    <link rel="stylesheet" href="/static/style.css" />
    <link rel="icon" type="image/x-icon" href="/static/favicon.ico" />

    <!-- Include HTMX -->
    <script src="/static/htmx.min.js?v=4.0.0"></script>
</head>

<body>
    <div class="container">
        <h1 class="title">Enter Text (SAHAR)</h1>

        <div class="card" id="content-card">
            <p class="card-label">Text from ScyllaDB:</p>

<div class="text-wrapper">
    <!-- Askama automatically escapes Sample text, preventing XSS attacks -->
    <h2 class="db-text">Sample text</h2>
</div>

<hr class="separator" />

<div class="controls">

    <!-- Save/Update form (works with JS via HTMX and without JS) -->
    <form action="/api/content" method="POST" hx-post="/api/content" hx-target="#content-card" hx-swap="innerHTML"
        hx-indicator="#content-card">

        <div class="input-row">
            <!-- Added maxlength="1000" for client-side protection against huge data inputs -->
            <input type="text" name="content" placeholder="Enter text..." class="input-field" autocomplete="off"
                required maxlength="1000" />
            <button type="submit" class="btn btn-black">
                Update
            </button>
        </div>
    </form>

    <!-- Delete text form (works with JS via HTMX and without JS) -->
    
    <form action="/api/content/delete" method="POST" hx-post="/api/content/delete" hx-target="#content-card"
        hx-swap="innerHTML" hx-indicator="#content-card">
        <button type="submit" class="btn btn-red">Delete</button>
    </form>
    
</div>
        </div>
    </div>
</body>

</html>

Архитектура SAHAR генерирует эталонно чистый, семантический HTML-код. Данные из ScyllaDB встраиваются в разметку на стороне сервера (Askama), что обеспечивает идеальную SEO-индексацию и мгновенную первую отрисовку контента.

В контексте кибербезопасности архитектура SAHAR демонстрирует максимальную надежность. Поскольку в разметке полностью отсутствуют инлайновые скрипты, встроенные блоки сериализованного JSON-состояния или модульные загрузчики, для HTML-документа отпадает необходимость в динамической генерации ресурсоемких nonce-хэшей. Вся интерактивность декларируется исключительно через безопасные атрибуты статического скрипта HTMX (hx-post, hx-target).

Отсутствие клиентского рендеринга позволяет внедрить бескомпромиссные настройки CSP, полностью исключив директиву 'unsafe-inline' как для скриптов (script-src 'self'), так и для стилей (style-src 'self').

Чтобы соответствовать жестким стандартам безопасности, я переопределил дефолтное поведение HTMX, запретив ему динамически внедрять стили в DOM-дерево (через конфигурацию <meta name="htmx-config" content='{"includeIndicatorStyles": false}'>) в файле index.html, и перенес всю визуальную логику в безопасный внешний CSS-файл (style.css). Такой архитектурный контроль превентивно сужает поверхность атаки до абсолютного минимума, делая систему полностью неуязвимой как для XSS (Cross-Site Scripting), так и для CSS-инъекций (UI Redressing).

Дополнительным и критически важным уровнем кибербезопасности стека SAHAR является защита от межсайтовой подделки запросов (CSRF). В отличие от классических SPA, где требуется сложный менеджмент CSRF-токенов, связка HTMX и Actix Web позволяет реализовать элегантный и надежный Anti-CSRF Middleware. Сервер на уровне каждого запроса жестко валидирует HTTP-заголовки Origin и Referer. Поскольку скрипт HTMX нативно и корректно передает эти заголовки при каждой мутации данных, бэкенд мгновенно блокирует любые POST/DELETE запросы, инициированные со сторонних доменов. Это полностью исключает возможность перехвата сессии и скрытого выполнения команд от лица авторизованного пользователя социальной сети.

Глобальная конфигурация безопасности

Для обеспечения комплексной защиты архитектуры на уровне HTTP-сервера, в конфигурацию Actix Web внедрен специализированный защитный слой (middleware). Данный блок настроек превентивно блокирует целый вектор уязвимостей: от DoS-атак до Clickjacking и попыток MIME-sniffing:

.app_data(app_state.clone())
            // Ограничение входящих данных (Защита от DoS-атак через огромные payload)
            .app_data(web::FormConfig::default().limit(4096))
            // Строгие заголовки безопасности (Нулевая терпимость к 'unsafe-inline')
            .wrap(
                middleware::DefaultHeaders::new()
                    // Защита от Clickjacking
                    .add(("X-Frame-Options", "DENY"))
                    // Защита от MIME-sniffing
                    .add(("X-Content-Type-Options", "nosniff"))
                    .add((
                        "Content-Security-Policy",
                        // Запрет инлайновых скриптов и стилей. Разрешен только собственный Origin ('self')
                        "default-src 'self'; script-src 'self'; style-src 'self';",
                    ))
                    .add((
                        "Strict-Transport-Security",
                        "max-age=31536000; includeSubDomains; preload",
                    ))
                    .add(("Referrer-Policy", "strict-origin-when-cross-origin")),
            )

Как и в случае с LARS, формы спроектированы по принципу Progressive Enhancement. Наличие стандартных атрибутов action и method гарантирует, что базовый функционал CRUD отработает безупречно даже в среде с полностью отключенным JavaScript:

<!-- Save/Update form (works with JS via HTMX and without JS) -->
    <form action="/api/content" method="POST" hx-post="/api/content" hx-target="#content-card" hx-swap="innerHTML"
        hx-indicator="#content-card">

        <div class="input-row">
            <!-- Added maxlength="1000" for client-side protection against huge data inputs -->
            <input type="text" name="content" placeholder="Enter text..." class="input-field" autocomplete="off"
                required maxlength="1000" />
            <button type="submit" class="btn btn-black">
                {% if is_empty %}Add{% else %}Update{% endif %}
            </button>
        </div>
    </form>

Сравнительная таблица структуры первичного HTML-ответа

6. Сравнительный анализ сетевого обмена при изменении данных

Механика обмена LARS (2 POST-запроса)

Архитектура LARS использует классическую изоморфную SPA-модель (Client-Side Hydration), которая разделяет процесс изменения данных и процесс обновления пользовательского интерфейса на два независимых RPC-шага:

• Запрос 1, размер: 123 B (POST /api/save_content...): При нажатии на кнопку обновления текста WASM-модуль перехватывает событие формы и вызывает сгенерированную серверную функцию. Клиент отправляет сериализованный JSON на сервер. Хэндлер Actix Web записывает новые данные в ScyllaDB и возвращает клиенту базовое подтверждение успешной транзакции (HTTP 200).
• Запрос 2, размер: 123 B (POST /api/get_content...): Получив подтверждение успешной записи, реактивная система Leptos автоматически помечает связанный ресурс (Resource) на клиенте как "устаревший" (инвалидирует его). Чтобы отобразить актуальные данные в интерфейсе, WASM-клиент вынужден инициировать второй RPC-запрос в базу данных. Он запрашивает свежее состояние, получает в ответ обновленный JSON, парсит его на стороне клиента и пересчитывает Virtual DOM для перерисовки.

Скрин 5: Профилирование сетевого обмена LARS при мутации данных: двухэтапный RPC-протокол (запись JSON и повторное чтение ресурса)

Механика обмена SAHAR (1 POST-запрос)

Архитектура SAHAR работает по принципам Hypermedia-Driven Application (HTMX + Askama + Actix Web), где мутация данных и рендеринг интерфейса объединены в одну атомарную серверную транзакцию:

• Единственный запрос, размер: 1.77 kB (POST /api/content): Библиотека HTMX перехватывает отправку формы и формирует один POST-запрос, явно указывая через атрибуты, что ожидает HTML-ответ для замены блока (hx-post="/api/content", hx-target="#content-card", hx-swap="innerHTML").
• Атомарная обработка на сервере: Серверный обработчик save_content в Actix Web принимает запрос и сразу сохраняет новый текст в базу данных ScyllaDB. Затем он проверяет наличие заголовка hx-request. Если заголовок присутствует, сервер в рамках этого же HTTP-соединения рендерит структуру ContentTemplate через шаблонизатор Askama и возвращает готовый HTML-код.
• Обновление UI без клиентского стейта: Браузер получает уже сформированный фрагмент HTML, а HTMX мгновенно заменяет им содержимое контейнера #content-card. Поскольку на клиенте нет состояния (State) и виртуального DOM, потребность во втором запросе для синхронизации данных полностью отпадает.

Скрин 6: Профилирование сетевого обмена SAHAR при мутации данных: одиночный Hypermedia-запрос (атомарное сохранение и возврат HTML)

Техническое обоснование разницы в сетевых запросах

Фундаментальное различие между двумя POST-запросами в LARS и одним POST-запросом в SAHAR обусловлено разницей архитектурных подходов к управлению состоянием (State Management) и формату передачи данных между клиентом и сервером.

Итоги сравнительного анализа сетевого обмена при изменении данных

Внедрение архитектуры SAHAR позволяет:

• 1. Сократить сетевые накладные расходы (Round-Trip Time) в 2 раза.
• 2. Снизить нагрузку на базу данных ScyllaDB за счет устранения холостых запросов на чтение сразу после записи.
• 3. Полностью освободить клиентское устройство от вычислительной нагрузки по парсингу JSON и сверке Virtual DOM.

7. Общие выводы

8. Сводная таблица сравнительных характеристик (LARS vs SAHAR)

9. Заключение