курсач / текст_к_презентации
.pdf2 слайд
«В современной веб-разработке существует два доминирующих подхода к организации обмена данными: протокол SOAP и архитектурный стиль REST. Зачастую выбор между ними делается на основе привычек разработчиков или устаревших мифов, а не реальных технических требований.»
«Актуальность нашей работы обусловлена тем, что эти технологии занимают
разные |
ниши, |
но |
часто |
|
пересекаются. |
|
С одной стороны, у нас есть SOAP — стандарт де-факто для банковских |
||||||
систем и |
госуслуг, |
где |
важны строгие контракты и |
безопасность. |
||
С другой стороны — REST, который стал стандартом для мобильных |
||||||
приложений |
и |
микросервисов |
благодаря |
своей |
легкости. |
|
Однако, на практике редко проводятся "чистые" эксперименты, показывающие, сколько именно ресурсов мы теряем или приобретаем, выбирая ту или иную технологию. Например, как сильно XML-парсинг нагружает процессор мобильного телефона по сравнению с JSON?»
Поэтому целью работы стала не просто теоретическое описание, а практическая реализация и инструментальное сравнение производительности этих подходов.
1.Во-первых, была разработана серверную часть на Node.js, которая предоставляет доступ к одним и тем же данным через два разных интерфейса — SOAP и REST. Это гарантирует чистоту эксперимента: база данных одна, бизнес-логика одна, отличается только транспортный слой.
2.Во-вторых, была создано клиентское приложение на современном фреймворке Vue 3, которое умеет "общаться" с обоими сервисами и, что самое важное, умеет точно замерять время обработки запросов.
3.И, наконец, были проведены серию нагрузочных тестов на объемах данных до 20 тысяч записей, имитируя как идеальные условия локальной сети, так и плохие условия мобильного интернета, чтобы получить объективные цифры.
3 слайд
Для корректной интерпретации результатов эксперимента необходимо понимать принципиальные различия рассматриваемых технологий.
«SOAP — это протокол обмена сообщениями. Его ключевая особенность — строгая стандартизация.
Все сообщения передаются исключительно в формате XML и должны быть обернуты в специальный "конверт" (Envelope).
Взаимодействие регламентируется строгим контрактом WSDL,
который описывает типы данных и методы.
1
Главное преимущество SOAP — это поддержка семейства
стандартов WS-* (WS-Security, WS-Transaction), которые обеспечивают безопасность и транзакционность на уровне самого протокола, независимо от транспортного канала. Именно поэтому он доминирует в банковском секторе.»
«REST, в свою очередь, не является протоколом. Это архитектурный стиль, который использует уже существующие возможности протокола HTTP.
Вместо сложных конвертов здесь используются стандартные методы: GET для получения данных, POST для создания и так далее.
В качестве формата данных чаще всего используется JSON, который значительно легче XML и нативно поддерживается браузерами.
REST фокусируется на ресурсах и их представлениях, поддерживает кэширование на уровне HTTP, что делает его идеальным выбором для высоконагруженных веб-систем.»
«Таким образом, мы сравниваем "тяжелый", но функциональный протокол (SOAP) с "легким" и гибким архитектурным стилем (REST). В
данной работе основной упор делается на анализ того, как эта фундаментальная разница в архитектуре влияет на конечную производительность системы.»
4 СЛАЙД
«Перейдем к практической реализации. Для решения поставленных задач был спроектирован и разработан программный комплекс, построенный по клиентсерверной архитектуре.»
Про Бэкенд (Центральная часть):
«Центральным элементом системы является сервер на платформе Node.js. Архитектура сервера спроектирована таким образом, чтобы обеспечить максимальную чистоту эксперимента. Была реализована общая бизнес-
логика и единый слой доступа к данным (Repository), который работает с базой данных SQLite.
Это критически важно: когда мы сравниваем производительность, мы должны быть уверены, что разница во времени обусловлена именно протоколом передачи данных (SOAP или REST), а не скоростью работы разных баз данных или алгоритмов на сервере.»
Про Интерфейсы (Точки входа):
2
«Сервер предоставляет два параллельных интерфейса для доступа к одним и тем же данным:
1.Стандартный REST API, работающий с JSON.
2.SOAP Endpoint, работающий строго по WSDL-контракту.»
Про Клиент (Левая часть):
«Клиентская часть представляет собой одностраничное приложение (SPA) на фреймворке Vue 3.
Особенностью клиента является реализация двух независимых модулей взаимодействия: один использует стандартный fetch для REST, другой реализует формирование и парсинг XML-сообщений для SOAP непосредственно в браузере.
Весь проект, как серверная, так и клиентская часть, написан на
языке TypeScript, что позволило использовать общие интерфейсы данных
(DTO).»
Микро-вывод:
«Такая архитектура позволяет проводить "честное" тестирование, меняя только способ взаимодействия, при прочих равных условиях.»
5 СЛАЙД
Про подход к разработке:
«Серверная часть реализована на платформе Node.js с использованием фреймворка Express.
При разработке использовался слоистый архитектурный подход. Вся работа с базой данных изолирована в слое Репозиториев, что позволяет сервис-слою не зависеть от источника данных.»
Про реализация SOAP (Contract First):
«Особое внимание было уделено реализации SOAP-сервиса. Был применен подход Contract First ("Контракт превыше всего").
Сначала был спроектирован файл WSDL, описывающий типы данных Student и методы getStudents, createStudent.
Затем, с помощью библиотеки soap, этот контракт был "оживлен" на сервере. Библиотека автоматически валидирует входящие XML-запросы на соответствие схеме и маршрутизирует их в методы бизнес-логики.»
Про реализацию REST:
3
«Параллельно был реализован REST-сервис, использующий стандартные механизмы маршрутизации Express и формат JSON.
Оба сервиса обращаются к одному и тому же инстансу репозитория, что обеспечивает работу с общим набором данных.»
Про данные (Важный момент для тестов):
«Для проведения нагрузочного тестирования был реализован
механизм массовой генерации данных. Использование SQL-транзакций позволило оптимизировать процесс вставки и генерировать тестовые наборы по 20 000 записей менее чем за 2 секунды, что необходимо для создания существенной нагрузки при передаче данных.»
6 СЛАЙД
«Клиентское приложение разработано как Single Page Application (SPA) на базе фреймворка Vue 3 и библиотеки компонентов Vuetify. Это обеспечило высокую реактивность интерфейса, необходимую для отображения метрик в реальном времени.»
Про главную сложность (SOAP в браузере):
«Основной технической сложностью этапа стала реализация SOAP-клиента. Современные браузеры и API, такие как fetch, оптимизированы для работы с JSON и не имеют встроенных механизмов для работы с SOAP.
Поэтому логика взаимодействия была реализована "с нуля":
1.XML-конверты (Envelope) формируются вручную с помощью шаблонных строк, строго следуя спецификации WSDL.
2.Для обработки ответов используется нативный DOMParser, который преобразует полученную XML-строку в DOM-дерево.
3.Далее реализован алгоритм обхода этого дерева для извлечения данных и приведения их к типам TypeScript.»
Про замеры (подвод к тестам):
«Также на клиенте была реализована специальная функция-обертка measure. Она использует High Resolution Time API (performance.now()) для точного измерения двух ключевых фаз:
Времени сетевого ожидания.
Времени, которое процессор тратит на парсинг данных (преобразование текста в объекты).
Именно это разделение позволило выявить скрытые накладные расходы протоколов.»
4
7 СЛАЙД
«Для получения объективных данных была разработана методика тестирования, включающая два сценария и четыре уровня нагрузки.»
Про Сценарии:
«Первый сценарий проводился на локальном сервере без ограничений сети. Его цель — исключить влияние интернета и измерить "чистую" производительность браузера и сервера: как быстро процессор может "переварить" входящий поток данных.
Второй сценарий имитирует реальные условия использования мобильного веб-приложения. Мы использовали профиль "Slow 3G" (медленный 3G) в инструментах разработчика Chrome. Это позволило оценить, как избыточность протокола влияет на скорость загрузки при плохом канале связи.»
Про Данные:
«Тестирование проводилось на объемах данных от 100 до 20 000 записей. Объем в 20 тысяч записей был выбран как стресс-тест, генерирующий ответ размером около 2 мегабайт, что является существенной нагрузкой для текстовых форматов.»
Про Метрики:
«В каждом тесте фиксировались три показателя:
1.Payload Size — физический размер данных, переданных по сети.
2.Parsing Time — чистое время, затраченное JavaScript-движком на десериализацию ответа.
3.Total Duration — полное время ожидания пользователя.»
8 СЛАЙД
«Перейдем к результатам. Первый и самый показательный график демонстрирует время парсинга — то есть время, которое браузер тратит на превращение полученного текста в объекты JavaScript.»
Анализ графика:
5
«Как мы видим, время обработки JSON в REST-сервисе (синие столбцы) остается ничтожно малым даже на больших объемах данных. На 20 тысячах записей оно составляет всего 5 миллисекунд. Это объясняется тем, что JSON является родным форматом для JS, и его парсинг оптимизирован на уровне движка браузера.
В то же время, обработка XML в SOAP (оранжевые столбцы) растет линейно и на максимальной нагрузке достигает 150 миллисекунд.»
Интерпретация (Почему это важно):
«150 миллисекунд — это уже ощутимая задержка. В этот момент процессор полностью занят разбором дерева тегов, что может приводить к микрофризам интерфейса, пропуску кадров анимации и быстрому разряду батареи на мобильных устройствах.
Вывод: С точки зрения вычислительной сложности REST эффективнее в 30
раз.»
9 СЛАЙД
Мы видим, что SOAP-сообщение весит стабильно больше. Разница составляет около 15-20%.
Например, на максимальной нагрузке REST передает 1.4 МБ данных, а SOAP
— 2.3 МБ.»
Причина (Техническая):
«Причина кроется в синтаксисе XML. В JSON мы передаем структуру один раз или не передаем вовсе (в массивах). В XML для каждого поля каждой записи требуется открывающий и закрывающий тег.
Например, чтобы передать имя "Ivan" (4 байта), в SOAP нам нужно обернуть его в теги <name>Ivan</name>, что добавляет еще 13 байт служебной информации. На объемах в тысячи записей эти байты складываются в мегабайты.»
Вывод:
«Хотя 15% могут показаться небольшой разницей, в условиях лимитированного мобильного трафика или роуминга это существенный фактор.»
6
10 СЛАЙД
«Самый важный тест — имитация реальных условий использования. Мы ограничили скорость сети до уровня Slow 3G (500 кбит/с) и замерили полное время ожидания пользователя.»
Анализ диаграммы:
«Результаты говорят сами за себя.
Загрузка 20 тысяч записей через REST заняла 30 секунд, что соответствует физическому пределу пропускной способности канала.
Тот же самый запрос через SOAP выполнялся почти 49 секунд. Разница составила 18 секунд — это колоссальное время для вебинтерфейса.»
Объяснение (Почему так много?):
«Почему разница в весе всего 15%, а во времени — почти 60%? Здесь работает кумулятивный эффект:
1.Во-первых, лишние 300 килобайт данных на такой низкой скорости передаются около 5-6 секунд.
2.Во-вторых, тяжелый парсинг XML (который мы видели ранее) блокирует интерфейс в момент получения данных.
3.В-третьих, большее количество пакетов увеличивает риск их потери и повторной отправки (TCP Retransmission), что характерно для нестабильных сетей.»
Вывод:
«Таким образом, в плохих условиях "тяжеловесность" SOAP становится критической проблемой, делая приложение практически непригодным для использования.»
11 СЛАЙД
«На слайде представлен интерфейс разработанного программного комплекса. Приложение позволяет не только проводить тесты, но и гибко управлять параметрами эксперимента.»
Функционал:
«В верхней части реализована панель администратора. Она позволяет одним кликом генерировать тестовые наборы данных (от 100 до 20 000
7
записей) или полностью очищать базу. Это дает возможность быстро переключаться между сценариями тестирования.»
Визуализация:
«Результаты каждого запроса отображаются в виде интерактивных карточек. Пользователь может раскрыть детализацию (так называемые "метрики") и увидеть точные значения времени сети, времени парсинга и размера данных, которые мы обсуждали ранее.
Система также поддерживает отображение сырого ответа (Raw Response), что полезно для отладки и визуального сравнения форматов JSON и XML.»
Микро-вывод:
«Интерфейс спроектирован так, чтобы наглядно демонстрировать разницу между подходами в режиме реального времени.»
12 СЛАЙД
«Подводя итог исследованию, можно свести результаты в сравнительную таблицу.»
По пунктам:
«1. Производительность: REST одержал безоговорочную победу. Он быстрее передается по сети, в 30 раз быстрее обрабатывается на клиенте и значительно меньше нагружает канал связи.
2.Сложность: REST проще в реализации. Для SOAP потребовалось написание сложных WSDL-схем и ручная реализация парсера на клиенте.
3.Безопасность: Однако, стоит отметить, что SOAP выигрывает в вопросах стандартизации безопасности и надежности доставки сообщений благодаря протоколам WS-*, чего нет в REST "из коробки".»
Финальный вердикт:
«Таким образом, гипотеза подтвердилась:
Для современных веб-приложений и мобильных систем, где важна скорость и отзывчивость интерфейса, REST является безальтернативным стандартом.
Использование SOAP в 2025 году оправдано только в специфических нишах (банковский сектор, госуслуги), где требования к формальному контракту перевешивают недостатки производительности.»
8