ИССЛЕДОВАНИЕ ПОТОКОЛА HTTP 3 OVER QUIC
Аннотация
РЕФЕРАТ
Черногоров Михаил Сергеевич, «Исследование протокола HTTP 3 over QUIC». Работа содержит 40 листов формата А4, включающих 2 таб-лицы, 15 литературных источников, 12 рисунков.
Ключевые слова: QUIC, ПРОТОКОЛ, HTTP, СКОРОСТЬ ПЕРЕДА-ЧИ, ШИФРОВАНИЕ, КЛИЕНТ, СЕРВЕР.
Целью работы является изучение протокола передачи информации QUIC, реализация базового сервера и клиента для его использования, проверка скорости относительно других протоколов.
Выпускная квалификационная работа содержит 7 глав. В первой главе произведен краткий обзор используемой литературы и источников информации. Во второй главе ставится задача данной работы. В третьей главе описана базовая реализация протокола шифрования TLS 1.3 и спо-собы его работы. В четвертой главе описана реализация сервисов HTTP, использующих разные версии протоколов для взаимодействия. В пятой главе проведено исследование скоростей передачи данных и их сравнение, использующих разные протоколы для передачи данных. Шестая глава содержит результаты работы текущей реализации сервисов и их дальней-шие улучшения. В седьмой главе представлен список используемых техно-логий.
МЕСТО ПРОВЕДЕНИЯ РАБОТЫ
Выпускная квалификационная работа была выполнена на кафедре вычислительной математики и компьютерных наук института естественных наук и математики уральского федерального университета имени первого президента России Б. Н. Ельцина.
СОДЕРЖАНИЕ
СОДЕРЖАНИЕ 5
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ 7
ОСНОВНАЯ ЧАСТЬ 10
1. Обзор литературы 10
2. Постановка задачи 11
3. Протокол TLS 1.3 12
3.1 Установка соединения 12
3.2 Алгоритмы шифрования 14
3.3 Реализация базового протокола QUIC 16
3.4 Построение пакета для передачи данных QUIC 17
3.5 Реализация клиента и сервера с поддержанием сессии 19
4. Реализация HTTP сервисов 21
4.1 HTTP 1 21
4.2 HTTP 2 21
4.3 HTTP 3 22
4.3.1 QUIC сервер 23
4.3.2 QUIC клиент 24
5. Проверка скорости передачи данных 26
5.1 Передача без потерь пакетов 26
5.2 Передача с потерей пакетов 28
6. Результаты 33
6.1 Результаты исследования скорости протокола 33
6.2 Идеи доработки HTTP 3 сервера и протокола QUIC 34
6.3 Дальнейшие шаги разработки 34
7. Используемые технологии 36
ЗАКЛЮЧЕНИЕ 37
СПИСОК ЛИТЕРАТУРЫ 38
ПРИЛОЖЕНИЯ 40
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ
В настоящей работе применяют следующие обозначения и сокраще-ния:
QUIC – протокол транспортного уровня передачи информации (изначаль-но Quick UDP Internet Connections), работающий на базе UDP.
Holl-блокировка – блокировка потока очереди.
TLS – криптографический протокол для обеспечения безопасной передачи данных.
Шифрование – процесс кодирования данных.
Фрейм – (или кадр) фрагмент данных канального уровня, помещаемый в пакет, содержит основную передаваемую информацию
Секретный ключ и сертификат – пара последовательностей символов, ис-пользующихся для кодирования информации
Клиент – устройство или приложение, которые запрашивает информацию у сервера и получает ответ.
Сервер – устройство или приложение, которое обрабатывает запросы кли-ентов.
Протокол – некий набор правил, описывающий взаимодействие устройств в сети.
UDP – (User Datagram Protocol) Протокол пользовательских датаграмм, не поддерживающий постоянного соединения.
TCP – (Transmission control protocol) протокол управления передачей ин-формации транспортного уровня, поддерживающий неразрывное соеди-нение.
HTTP – (Hypertext transfer protocol) – протокол передачи гипертекста.
RFC - (Request for comments) – документ, содержащий технические стан-дарты, применяемые в сети Интернет.
ВВЕДЕНИЕ
Современные приложения развиваются с невероятной скоростью, соответственно и растет количество информации, которые нужно переда-вать по сети. Чтобы повышать скорость отправки данных в Интернет также на постоянной основе совершенствуются способы передачи информации. За последние 10 лет от средней скорости в 1 Мбит в секунду она возросла более чем 10 раз [13]. Повысить скорость передачи данных можно двумя путями: увеличить пропускную способность канала связи, то есть провести улучшения на физическом уровне, или модернизировать алгоритмы, ко-торые используются для этого в сети. В настоящее время также очень важ-ную роль играет защита передаваемых по сети данных. Так как вычисли-тельные мощности современных устройств постоянно растут, многие ал-горитмы шифрования становятся небезопасны, о чем подробнее можно узнать в статье на Cloudfare [8].
В связи с вышеперечисленными требованиями, в 2012 году была разработана первая версия протокола передачи информации транспорт-ного уровня QUIC, который в настоящее время активно дорабатывается и становится стандартом в сети Интернет. Данный протокол является уни-версальным, и может прийти на замену TCP и UPD, из-за этого он являет-ся крайне динамическим, и может быть изменен под требования какого-либо проекта.
Так как крупные компании только разрабатывают свои первые вер-сии этого протокола, а большинство современных библиотек для работы c HTTP еще не реализовало данного протокола, становится не понятно, насколько эффективно будет его использовать в своем сервисе. Поэтому для точной оценки проделываемой работы требуется реализовать свой сервис.
ОСНОВНАЯ ЧАСТЬ
1. Обзор литературы
Для реализации сервисов, передающих информацию по протоколам HTTP 1, HTTP 2 и QUIC была изучена документация: RFC 9000 [1] для изучения основных алгоритмов работы протокола QUIC и его структуру пакета [6], RFC 8446 [2] для изучения алгоритмов работы протокола шифрования TLS 1.3, RFC 5246 [5] для изучения алгоритмов работы про-токола шифрования TLS 1.2, а также структуру пакета в протоколе HTTP 3 [7] и работа Александра Венедюхина «Как работает TLS» [12]. Во вре-мя изучения современных протоколов и их сравнения с предыдущими вер-сиями, а также возможностей HTTP 3 были использованы электронные ре-сурсы cloudfare [8], noorsoft [13], explained [10].
Для написания кодовой базы данный работы был использован язык программирования Python [4], библиотеки Pycryptodome [9], реализую-щая функциональность шифрования данных до протокола TLS версии 1.2 и Aioquic [14] для использования более проработанной версии протокола QUIC. Также была задействована система контроля версия git и GitHub [11] для хранения написанного кода.
2. Постановка задачи
Целью данного исследования являются сравнение скорости передачи данных с использованием разных версий протокола HTTP, в частности глубокое погружение в протокол транспортного уровня QUIC, который является базовой составляющей протокола HTTP 3, а также их изучение изнутри для выявления всех плюсов и минусов использования и самостоя-тельной реализации с доработками для использования в WEB-сервисах для более отзывчивого интерфейса и скорости работы приложения.
Для вышеуказанной задачи потребуется реализовать сервисы ис-пользующие разные протоколы передачи информации и шифрования дан-ных, сравнить скорость передачи данных в разных условиях сети, сделать выводы из проделанной работы.
3. Протокол TLS 1.3
Данный протокол защиты транспортного уровня является седьмой версией протокола шифрования TLS, ранее известного как ssl (Secure Sockets Layer — уровень защищённых сокетов). Он предназначен для за-щиты передаваемых данных в сети между ее узлами. А именно, данный протокол предоставляет шифрование данных, аутентификацию и целост-ность соединения.
3.1 Установка соединения
Общая схема установки соединения между клиентом и сервером в про-токоле TLS 1.3 выглядит следующим образом (См. рисунок 3.1)
● Клиент посылает на сервер сообщение ClientHello которое состоит из:
o Открытого ключа клиента, который получен по алгоритму Диффи-Хелмана или идентификаторы секретных ключей, если клиент и сервер, например, используют заранее известные сер-тификат и ключ
o Желаемый метод для обмена секретными ключами
o Метод цифровой подписи
● Сервер посылает клиенту сообщения
o Ответ для открытого ключа или идентификатор секретного ключа
o Если нужна аутентификация, сообщение CertificateRequest для получения сертификата от клиента
o Свой сертификат
o Сообщение Finished – рукопожатие завершено
● Клиент после проверки сертификата сервера генерирует секретный ключ и отправляет:
o Сообщение Finished – рукопожатие завершено
o Если сервер запрашивал сертификат, отправляет сертификат
o Первое зашифрованное сообщение
Соединение установлено, теперь все пересылаемые данные будут передаваться только в зашифрованном виде.
*Алгоритм Диффи-Хеллмана – алгоритм для получения между сторонами секретного ключа, по каналу связи, не защищенному от прослушивания.
Стоит отметить уникальную функцию TLS 1.3 которая получила название 0-RTT [2], она заключается в возможности клиента подключится к серверу, который был посещен ранее, без проводимой процедуры руко-пожатия для установки защищенного соединения и сразу начать пересы-лать полезные данные. Это возможно за счет хранения секретной инфор-мации на клиенте и сервере некоторое время после разрыва соединения. Отличие от TLS 1.2 в котором реализован 1-RTT [5] заключается в том, что в первом же пакете отсылаются полезные данные, но это может быть небезопасно. В QUIC доработана эта функция таким образом, что при первой отправке пакета сразу возможно отправить полезные данные.
По сравнению с прошлыми версиями, установка соединения проис-ходит на один полный цикл быстрее, за счет чего экономится от 0.1 секун-ды, удален лишний цикл подтверждения сообщения Finished через сооб-щение от сервера ChangeCipherSpec, ранее это происходило отельными сообщениями.
Рисунок 3.1 - Установка соединения между клиентом и сервером по прото-колу QUIC (TLS 1.3) по документации RFC [1]
3.2 Алгоритмы шифрования
В новой версии протокола отказались от старых небезопасных алго-ритмов шифрования, например от алгоритмов шифрования DES и 3DES или алгоритмов хеширования MD5 и SHA-1 [2].
Алгоритмы шифрования оцениваются сложностью памяти и быстро-действия, поэтому 3DES считается безопасным до 2030 года. На его взлом понадобится около 2^32 бит известного открытого текста, 2^113 шагов, 2^90 циклов DES-шифрования и 2^88 бит памяти [3]
В TLS 1.3 согласовано поддержание шифров [2]:
● TLS_AES_128_CCM_SHA256
● TLS_AES_256_GCM_SHA384
● TLS_AES_128_GCM_SHA256
● TLS_CHACHA20_POLY1305_SHA256
● TLS_AES_128_CCM_8_SHA256
Данные шифры реализуют так называемое «Блочное шифрование» или AEAD, где само сообщение шифруется либо с помощью блочного шифра и имитовставки (MAC) - символы, которыми подписывается сообщение, полученные после установки соединения, либо с помощью АЕ-схемы [3].
*AE-схема – аутентификация-шифрование схема (от англ. Authenticated encryption) [3]
В первом варианте воспользуемся методом Encrypt-then-mac: снача-ла шифруется сообщение M с использованием nonce N, затем заголовок H и зашифрованное сообщение аутентифицируются с помощью MAC с тем же nonce. (См. рисунок 3.2)
*Nonce – случайное неповторяющееся число.
Рисунок 3.2 - Алгоритм шифрования Encrypt-then-mac
Сами шифры отличаются длинной MAC и ключа шифрования, по-этому реализация сводится написанию алгоритма AEAD.
Для реализации протокола воспользуемся библиотекой на python Cryptodome. Напишем методы генерации nonce, шифрования и дешифро-вания сообщения.
3.3 Реализация базового протокола QUIC
Для проверки протокола шифрования, несовместимого с предыдущими версиями, нужно реализовать своих клиента и сервера работающих по протоколу QUIC.
● QUIC — это протокол транспортного уровня, на котором базируется протокол HTTP 3, он реализован как обертка на протокол UDP и реа-лизует шифрование данных по протоколу TLS 1.3 и несколько других функция, потенциально позволяющих передавать данные по сети быст-рее, и в более защищенном виде, чем при использовании более ранних версий HTTP [1].
Базовая реализация протокола будет включать в себя:
1. Построение фрейма(пакета) для передачи по сети точка-точка
2. Буфер для поддержания состояния и реализации 0-RTT (реализовано в TLS [2])
3. Поддержка секретного ключа для каждого фрейма данных, с посто-янным обновлением
3.4 Построение пакета для передачи данных QUIC
Для построения базового пакета для передачи данных по протоколу QUIC воспользуемся документацией RFC [6] для построения фрейма дан-ных, реализуем основную структуру пакета, полная реализация на GitHub [11]. Основные флаги и типы фреймов (См. рисунок 3.3, 3.4)
Рисунок 3.3 - Все возможные типы фреймов пакета QUIC по RFC
Рисунок 3.4 - Основная флаги и типы фреймов пакета QUIC в реализации
PING – Используется для поддержания соединения в рабочем состоянии
ASK – Набор идентификаторов пакетов, для подтверждения получения и обработки пакетов.
Padding – используются для увеличения размера пакета, например для увеличения начального пакета до минимального размера или для обеспе-чения защиты от анализа трафика
Reset stream – кадр, для сообщения о прекращении потока данных.
Blocked – используется, чтобы сообщить, что все входящие кадры отбра-сываются.
Connections close – используется, для уведомления о закрытии соединения
Window update – используется, для согласования используемой версии
Go away – общий фрейм ошибки (для упрощения).
Мы опустим фреймы для установки максимального размера потока данных и максимального размера пакета, задав стандартный размер. Так-же не будут использованы многие необязательные фреймы.
3.5 Реализация клиента и сервера с поддержанием сессии
Для реализации клиента и сервера воспользуемся нашим клиентом и сервером, которые умеют передавать данные. Достаточно создать объекты в памяти, и для прослушивания порта зациклить функции. Для этого вос-пользуемся библиотекой asyncio, для запуска клиента и сервера на отдель-ных потоках. Данный код можно посмотреть на GitHub [11].
Теперь мы можем передать первое наше сообщение, а именно – СlientHello, также сгенерируем ключ для шифрования данных на сервере, и передадим его клиенту (Так делать не рекомендуется, все в целях про-верки).
После запуска тестовой отправки сообщения получаем следующий результат:
client hello: 16030100a5010000a10303303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f20606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f000213040100005600000012001000000d33342e3235332e3234342e3736002b0003020304002d000201000029002f000a000431353231000000000021204a769821ad0aa2cabd1fdcbb5aee9e6293aec5abdf4498528323b7a07c56ff1b
Здесь мы видим сообщение client hello, которое передается от клиента сер-веру при первой установке соединения.
Что можно наблюдать и в Wireshark (См. рисунок 3.5)
Рисунок 3.5 - Вид реализованного пакета QUIC в Wireshark
4. Реализация HTTP сервисов
Для сравнения скорости передачи данных будем использовать стан-дартные HTTP-запросы, в данном случае GET-запрос на отправку файла со стороны сервера клиенту. Для этого понадобится реализовать простей-шие HTTP-сервисы, работающие по протоколам версий от первой до тре-тьей.
4.1 HTTP 1
Для начала был реализован базовые клиент и сервер, использующие для передачи данных протокол HTTP первой версии. Т. к. в протоколе HTTP 3 на транспортном уровне реализовано шифрование по протоколу TLS1.3, для более честного тестирования добавим шифрование пакетов по алгоритму TLS_AES_256_GCM_SHA384 из версии 1.2 и отключим не поддерживаемые способы, что видно в коде на GitHub [11]. Этот функцио-нал поддерживает готовая реализация протокола из библиотеки aiohttp на Python, сам же алгоритм реализован в библиотеке ssl. Для множественной нагрузки и ускорения передачи будем запрашивать соединения асинхрон-но(параллельно), для этого воспользуемся библиотекой asyncio.
4.2 HTTP 2
Аналогично напишем сервер и клиент, общающихся по протоколу HTTP второй версии. Его главное отличие будет состоять в возможности мультиплексирования на уровне протокола HTTP. А значит мы можем не блокировать потоки и передавать запросы параллельно.
4.3 HTTP 3
Протокол HTTP 3 довольно новый, некоторые браузеры начали поддерживать его с 2019–2020 года [10], и современные библиотеки для реализации HTTP-сервисов только начинают добавлять его в свой функ-ционал.
Сессия соединения стандартно поддерживается на транспортном уровне в протоколе QUIC [1], поэтому протокол прикладного уровня должен поддерживать основной функции HTTP, а именно, поля HTTP, представление стандартных методов HTTP (GET, POST и другие), обра-ботка ошибок запросов и ответов.
В данном случае для проверки скорости передачи данных и обра-ботки базовых ошибок нам достаточно уметь заново запрашивать данные при ошибке и воспроизвести метод для получения данных сервера клиен-том или наоборот.
Мы не будем реализовывать полноценный HTTP 3 сервис, а лишь воспользуемся клиентом и сервером QUIC, организуем передачу фреймов, простую обработку ошибок, обработку событий, которые предают между собой клиент и сервер, и механизм, поддерживающий целостность данных – в данном случае при ошибке получения пакета или его нехватке, сервер будет запрашивать потерянные данные повторно.
Также реализуем подтверждение передачи фреймов: при обработке пакета сервер будет посылать ответ с кодом или текстом ответа.
В ходе проведения эксперимента я выяснил, что ранее реализован-ный мной протокол с основными функциями не обладает оптимизациями и технологиями, обязательными для передачи многофреймовых сообщений, например, требуется хорошо оптимизированный буфер для хранения от-правки и обработки большого количества пакетов, поэтому далее я вос-пользуюсь библиотекой aioquic для реализации клиент-серверного прило-жения на протоколе QUIC.
4.3.1 QUIC сервер
Выделим основные функции севера, которые должны быть реализова-ны:
1. Прослушивание порта и ожидание сообщений от клиента
2. Отделение сообщений друг от друга, даже если они отправлены в одной сессии
3. Обработка входящих пакетов данных
4. Подтверждение доставки пакета от клиента
5. Индексирование фреймов, за счет чего мы решим проблему holl-блокировок
6. Логирование событий отправки и принятия пакетов
7. Базовая обработка ошибок
8. Поддержка шифрования данных
9. Разделение потоков данных
Для упрощения тестирования сервер будет принимать какой-то поток данных от клиента, в данном случае текстовые файлы размером до 30мб разбитые на какое-то количество фреймов, сами потоки будут отделены разделительным фреймом с полем data = «all», более подробно можно по-смотреть на GitHub [11].
Рассмотрим на примере, из-за чего возникает блокировка потока оче-реди: допустим мы посылаем два файла по протоколу HTTP 1.1. Он рабо-тает в один поток, и соответственно два файла будут объединены в один заголовок ответа. Пока сервер не загрузит оба файла, мы не увидим ни одного из них, хотя они могли занимать, например 1КБ и 10мб, но для по-лучения маленького файла мы все равно ждем большого. Это решалось открытием нескольких соединений для разных файлов, что соответственно не является хорошим решением. Эта проблема решилась в HTTP 2 за счет мультиплексирования, на уровне HTTP начали подписывать пакеты дан-ных и отсылать независимо, это позволило разделить данные и посылать их независимо, но протокол транспортного уровня все также шлет данные одним потоком, и при потере какой-то части данных, он будет ожидать их заново и не загрузит не потерянную часть, а оставит ее в буфере. Чтобы решить данную проблемы будем подписывать пакеты на транспортном уровне, что и предлагает алгоритм протокола.
4.3.2 QUIC клиент
Основные функции клиента:
1. Индексирование пакетов данных
2. Обработка входящих пакетов данных
3. Отправка данных на сервер
4. Логирование событий отправки и принятия пакетов
5. Поддержка шифрования данных
6. Временное сохранение отправленных пакетов данных, для повтор-ного запроса данных по id пакета
Реализация данных функций приведена на Github [11]
После запуска сервера при попытке отправить файл с клиента можно наблюдать поток данных, который распознается как пакеты формата QUIC, что говорит об успешной отправке данных и функциональности сервиса (См. рисунок 4.1)
Рисунок 4.1 - Поток передачи пакетов по протоколу QUIC
5. Проверка скорости передачи данных
Для возможности проверки скорости передачи данных воспользуем-ся текстовым файлом размером в 30мб. Искусственно будут добавлены проблемы потери пакетов в сети и засечено время передачи 10 файлов для вычисления математического ожидания и среднеквадратического отклоне-ния времени передачи данных между узлами сети.
5.1 Передача без потерь пакетов
Начнем с передачи данных без каких-либо проблем со стороны сер-вера и клиента. Будут производиться параллельные запросы со стороны клиента на сервер, для получения файлов text_{i}.txt, среди которых есть три «больших файла» под номерами 3, 6 и 9 размером 30мб и семь «ма-леньких». Результаты данных запросов отображены в Таблице А.1. Как мы видим, из-за «однопоточности» протокола HTTP 1 у нас возникают блокировки файлов, которые, казалось бы, должны быть получены быст-рее, т к. их размер меньше. Соответственно на клиенте, использующем протокол HTTP 2, такой проблемы нет, и файлы мы получаем параллель-но.
Блокировки потока очереди – главная проблема протокола HTTP 1, которые заключается в неспособности отделить разные файлы из одного потока фреймов. С данной проблемой справляется протокол HTTP 2 при помощи индексирования HTTP пакетов.
Проведем передачу файлов между узлами сети результаты данных запро-сов представлены в Таблице 1.1.
Матожидания и средние отклонения времени запросов файлов в дан-ном случае равны:
HTTP 1
М[x] = 0.217 секунд σ = 0.123 секунды max=0.39 секунды min=0.047 се-кунды
HTTP 2
М[x] = 0.2 секунды σ = 0.09 секунды max=0.344 секунды min=0.094 секун-ды
QUIC
М[x] = 1.275 секунд σ = 0.44 секунды max=2.031 секунды min=0.89 секун-ды
По этим данным мы можем сделать следующие выводы:
- Передача маленького фрейма данных происходит быстрее по протоколу HTTP 1
- Текущая реализация протокола QUIC и сервера взаимодействие по нему сильно уступает протоколам HTTP 1 и HTTP 2 (См. рисунок 5.1)
- В среднем передача по HTTP 2 происходит быстрее всего, а при исполь-зовании QUIC медленнее (См. рисунок 5.1)
- За счет индексирования пакетов данных и разбиения их на разные пото-ки, протоколу HTTP 2 удается получать маленькие файлы раньше, даже если они запрошены позже «больших» (См. рисунок 5.1)
Рисунок 5.1 - Сравнение скорости передачи данных без потерь пакетов
5.2 Передача с потерей пакетов
При потере пакета при передаче от источника к получателю возника-ет та же самая блокировка потока очереди, но лишь с тем отличием, что пакеты блокируется уже не на прикладном уровне, а на транспортном, эту проблему в как раз и пытается решить QUIC за счет того же индексирова-ния пакетов, но уже на транспортном уровне.
Еще раз повторим операции передачи файлов между клиентами и серверами, но добавим искусственную потерю пакетов при помощи утили-ты comcast. В командной строке Linux установим примерно 10-процентную потерю пакетов данных командой comcast –device=eth0 –packet-loss=10% --target-addr=127.0.0.1 –target-proto=tcp –target-port=4433.
Так мы получим потерю пакетов для HTTP 1 и HTTP 2 сервисов. Для QUIC сервера же достаточно в случайном порядке «терять пакеты» при помощи функции random, т. к. мы напрямую взаимодействуем с про-токолом транспортного уровня и управляем фреймами данных
Проведем передачу файлов между узлами сети (См рисунок 5.2), ре-зультаты данных запросов представлены в Таблице 1.2.
Матожидания и средние отклонения времени запросов файлов в дан-ном случае равны:
HTTP 1
М[x] = 0.246 секунды σ=0.15 секунды max=0.453 секунды min=0.032 се-кунды
HTTP 2
М[x] = 0.237 секунды σ=0.16 секунды max=0.672 секунды min=0.078 се-кунды
QUIC
М[x] = 1.335 секунд σ = 0.92 секунды max=2.844 секунды min=0.5 секунды
По этим данным мы можем сделать следующие выводы:
- Текущая реализация протокола QUIC и сервера взаимодействие по нему сильно уступает протоколам HTTP 1 и HTTP 2 (См. рисунок 5.2)
- Потеря 10 процентов пакетов в случайной выборке дали следующий по-тери в скорости в среднем: HTTP 1–12%, HTTP 2–16%, QUIC (HTTP 3) – 5%, из чего следует, что последний является самым стабильным при воз-можной потери пакетов.(См. рисунок 5.3, 5.4, 5.5)
Стоит отметить, что был реализован только базовый сервер QUIC без множества возможных оптимизаций, например таких как кэширование, от-сюда возникает большая разница в скорости передачи файлов между про-токолами.
● Первый файл является «маленьким», но на всех примерах может пере-даваться дольше, чем другие того же размера, это связано с установкой соединения между клиентом и сервером (рукопожатием)
Рисунок 5.2 - Сравнение скорости передачи данных с потерями пакетов
Рисунок 5.3 - Сравнение скорости передачи данных по протоколу HTTP 1
Рисунок 5.4 - Сравнение скорости передачи данных по протоколу HTTP 2
Рисунок 5.5 - Сравнение скорости передачи данных по протоколу QUIC
6. Результаты
После получения тестовых данных будет произведен анализ данных и сделаны некоторые выводы.
6.1 Результаты исследования скорости протокола
В результате проведенного исследования было замечено, что в про-центном соотношении при потере пакетов в сети протокол QUIC показыва-ет наиболее высокие показатели по сравнению с «идеальной» сетью. А са-мым стабильным остается “однопоточный” HTTP 1. Это показывает, что новый протокол передачи информации, несмотря на шифрование данных, может, как минимум, быть очень полезен при работе с нестабильной сетью, например для использования на смартфонах, поездах и т. п.
Также можно обратиться к версии протокола QUIC, которая в насто-ящее время разрабатывается ВКонтакте [15]. Сравнивая скорость рендера страницы, использующей протокол HTTP 2 и HTTP 3, удалось добиться следующего результата (См. рисунок 6.1)
Рисунок 6.1 - Сравнение скорости протоколов в Web-сервисе
Это говорит о том, что при должных улучшениях протокола HTTP 3 он может оказаться быстрее, чем его предыдущие версии. Скорее всего, данный протокол был оптимизирован для использования конкретно на Web-приложение, возможно задействовано несколько портов, что позво-ляет получать файлы быстрее. Но компания все еще не задействовала дан-ную разработку на своих сервисах.
6.2 Идеи доработки HTTP 3 сервера и протокола QUIC
Протокол QUIC является сильно динамическим протоколом, это дает возможность выстраивать клиент-серверные отношения в зависимости от задачи. Например, в данной работе он был использован аналогично TCP, и на каждый отправленный пакет клиент ждет подтверждения его обработ-ки от сервера, что не является оптимальным вариантом, но т. к. сам про-токол реализован как обертка над UDP, его можно использовать для пере-дачи информации без такой функциональности, например, для передачи видео.
В реализованном сервисе на базе протокола QUIC видно следующие доработки:
- Подтверждение принятия пакета клиентом или сервером через какой-то промежуток времени или несколько принятых пакетов
- Возможность сервера и клиента работать на нескольких портах автома-тически, что позволяло бы значительно увеличить скорость передачи
6.3 Дальнейшие шаги разработки
Следующими шагами разработки приложения станет полная совме-стимость с HTTP 3 и развертывание Web-сервиса, который сможет исполь-зовать реализованный сервер для передачи информации. Для доработки сервиса потребуется научиться обрабатывать ошибки прикладного и транспортного уровней, провести работу над оптимизациями скорости пе-редачи данных как на уровне QUIC-сервера, так и на уровне HTTP.
7. Используемые технологии
1. Aioquic – библиотека для многопоточного запуска кода на Python
2. Python – язык программирования
3. Git – система контроля версия
4. Openssl – утилита для генерации сертификатов и ключей
5. С – язык программирования
6. Wireshark – программа для отслеживания пакетов в сети
ЗАКЛЮЧЕНИЕ
В результате выполнения данной работы я успешно реализовал про-токолы TLS 1.3 и QUIC, углубился в языки программирования Python и C, изучил многие алгоритмы шифрования данных, например MD5 и DES, изучил большое количество документации RFC, углубился в протокол QUIC.
Были реализованы и протестированы клиент-серверные приложения, использующие протоколы передачи данных HTTP от первой версии до третьей, на скорость передачи данных. Проведено измерение скоростей передачи информации в сервисах, использующих разные протоколы для обмена данными, по эти наблюдениям сделаны соответствующие выводы. Сервер, использующий базовый протокол HTTP 3, описанный в до-кументации, позволяет получить выигрыш в некоторых случаях, напри-мер, при потере пакетов данных, за счет их индексирования.
Более ранние версии протокола же используют ту же технологию, но для других целей.
СПИСОК ЛИТЕРАТУРЫ
1. RFC 9000. Протокол QUIC [электронный ресурс] URL: https://datatracker.ietf.org/doc/html/rfc9000 (Дата обращения: 12.11.2022)
2. RFC 8446. Протокол TLS 1.3 [электронный ресурс] URL: https://www.rfc-editor.org/rfc/rfc8446#appendix-C.3 (Дата обращения: 03.01.2023)
3. Wikipedia. Протокол TLS 1.3 [электронный ресурс] URL: https://ru.wikipedia.org/wiki/TLS_1.3 (Дата обращения: 26.12.2022)
4. Python. Документация: [электронный ресурс] URL: https://docs.python.org/3/library/ssl.html#tls-1-3 (Дата обращения: 26.02.2023)
5. RFC 5246. Протокол TLS 1.2 [электронный ресурс] URL: https://www.rfc-editor.org/rfc/rfc5246 (Дата обращения: 21.03.2023)
6. RFC. Структура пакета QUIC [электронный ресурс] URL: https://datatracker.ietf.org/doc/html/draft-marx-quic-qlog-quic-events (Дата обращения: 15.03.2023)
7. RFC. Структура пакета HTTP 3 [электронный ресурс] URL: https://datatracker.ietf.org/doc/html/draft-marx-quic-qlog-h3-events (Дата обращения: 23.04.2023)
8. Cloudfare. История HTTP [электронный ресурс] URL: https://blog.cloudflare.com/the-state-of-http-in-2022/ (Дата обращения: 12.01.2023)
9. Pycryptodome. Документация библиотеки для шифрования данных [электронный ресурс] URL: https://pycryptodome.readthedocs.io/en/latest/src/cipher/cipher.html (Дата обращения: 14.05.2023)
10. HTTP 3. Краткая информация о протоколе и его развитии [элек-тронный ресурс] URL: https://http3-explained.haxx.se/ (Дата обращения: 03.02.2023)
11. Github. Реализация сервисов на Python [электронный ресурс] URL: https://github.com/MichailNonProgramer/Diplom (Дата обращения: 03.02.2023)
12. Александр Венедюхин, Ключи, шифры, сообщения: как работает TLS (Техническое описание TLS) [Электронный ресурс] URL: https://tls.dxdt.ru/tls.html (Дата обращения: 26.12.2023)
13. Скорость передачи данных в сети [Электронный ресурс] URL: https://noorsoft-mobile.ru/blog/kak-izmenilsya-internet-za-poslednie-10-let (Дата обращения: 21.05.2023)
14. Aioquic. Документация библиотеки на Python [Электронный ресурс] URL: https://aioquic.readthedocs.io/en/latest/ (Дата обращения: 12.04.2023)
15. QUIC от ВКонтакте. Реализация сервиса на С [Электронный ресурс] URL: https://github.com/VKCOM/nginx-quic (Дата обращения: 14.05.2023)
ПРИЛОЖЕНИЯ
Таблица 1.1 - Времена передачи данных без потерь пакетов 10 файлов
Имя файла HTTP 1, сек HTTP 2, сек QUIC (HTTP 3),
Сек
File1 0.047 0.141 0.891
File2 0.047 0.094 0.906
File3 0.14 0.328 1.750
File4 0.156 0.125 0.953
File5 0.172 0.141 0.969
File6 0.265 0.344 1.735
File7 0.281 0.172 1.547
File8 0.297 0.172 1.078
File9 0.375 0.344 2.031
File10 0.39 0.131 0.89
Таблица 1.2 - Времена передачи данных с потерями пакетов 10 файлов
Имя файла HTTP 1, сек HTTP 2, сек QUIC (HTTP 3),
Сек
File1 0.032 0.094 0.89
File2 0.047 0.266 0.735
File3 0.157 0.672 2.725
File4 0.172 0.078 0.547
File5 0.203 0.094 0.828
File6 0.297 0.297 2.844
File7 0.313 0.156 0.5
Продолжение таблицы 1.2
File8 0.344 0.156 0.781
File9 0.438 0.344 2.344
File10 0.453 0.672 1.156
Черногоров Михаил Сергеевич, «Исследование протокола HTTP 3 over QUIC». Работа содержит 40 листов формата А4, включающих 2 таб-лицы, 15 литературных источников, 12 рисунков.
Ключевые слова: QUIC, ПРОТОКОЛ, HTTP, СКОРОСТЬ ПЕРЕДА-ЧИ, ШИФРОВАНИЕ, КЛИЕНТ, СЕРВЕР.
Целью работы является изучение протокола передачи информации QUIC, реализация базового сервера и клиента для его использования, проверка скорости относительно других протоколов.
Выпускная квалификационная работа содержит 7 глав. В первой главе произведен краткий обзор используемой литературы и источников информации. Во второй главе ставится задача данной работы. В третьей главе описана базовая реализация протокола шифрования TLS 1.3 и спо-собы его работы. В четвертой главе описана реализация сервисов HTTP, использующих разные версии протоколов для взаимодействия. В пятой главе проведено исследование скоростей передачи данных и их сравнение, использующих разные протоколы для передачи данных. Шестая глава содержит результаты работы текущей реализации сервисов и их дальней-шие улучшения. В седьмой главе представлен список используемых техно-логий.
МЕСТО ПРОВЕДЕНИЯ РАБОТЫ
Выпускная квалификационная работа была выполнена на кафедре вычислительной математики и компьютерных наук института естественных наук и математики уральского федерального университета имени первого президента России Б. Н. Ельцина.
СОДЕРЖАНИЕ
СОДЕРЖАНИЕ 5
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ 7
ОСНОВНАЯ ЧАСТЬ 10
1. Обзор литературы 10
2. Постановка задачи 11
3. Протокол TLS 1.3 12
3.1 Установка соединения 12
3.2 Алгоритмы шифрования 14
3.3 Реализация базового протокола QUIC 16
3.4 Построение пакета для передачи данных QUIC 17
3.5 Реализация клиента и сервера с поддержанием сессии 19
4. Реализация HTTP сервисов 21
4.1 HTTP 1 21
4.2 HTTP 2 21
4.3 HTTP 3 22
4.3.1 QUIC сервер 23
4.3.2 QUIC клиент 24
5. Проверка скорости передачи данных 26
5.1 Передача без потерь пакетов 26
5.2 Передача с потерей пакетов 28
6. Результаты 33
6.1 Результаты исследования скорости протокола 33
6.2 Идеи доработки HTTP 3 сервера и протокола QUIC 34
6.3 Дальнейшие шаги разработки 34
7. Используемые технологии 36
ЗАКЛЮЧЕНИЕ 37
СПИСОК ЛИТЕРАТУРЫ 38
ПРИЛОЖЕНИЯ 40
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ
В настоящей работе применяют следующие обозначения и сокраще-ния:
QUIC – протокол транспортного уровня передачи информации (изначаль-но Quick UDP Internet Connections), работающий на базе UDP.
Holl-блокировка – блокировка потока очереди.
TLS – криптографический протокол для обеспечения безопасной передачи данных.
Шифрование – процесс кодирования данных.
Фрейм – (или кадр) фрагмент данных канального уровня, помещаемый в пакет, содержит основную передаваемую информацию
Секретный ключ и сертификат – пара последовательностей символов, ис-пользующихся для кодирования информации
Клиент – устройство или приложение, которые запрашивает информацию у сервера и получает ответ.
Сервер – устройство или приложение, которое обрабатывает запросы кли-ентов.
Протокол – некий набор правил, описывающий взаимодействие устройств в сети.
UDP – (User Datagram Protocol) Протокол пользовательских датаграмм, не поддерживающий постоянного соединения.
TCP – (Transmission control protocol) протокол управления передачей ин-формации транспортного уровня, поддерживающий неразрывное соеди-нение.
HTTP – (Hypertext transfer protocol) – протокол передачи гипертекста.
RFC - (Request for comments) – документ, содержащий технические стан-дарты, применяемые в сети Интернет.
ВВЕДЕНИЕ
Современные приложения развиваются с невероятной скоростью, соответственно и растет количество информации, которые нужно переда-вать по сети. Чтобы повышать скорость отправки данных в Интернет также на постоянной основе совершенствуются способы передачи информации. За последние 10 лет от средней скорости в 1 Мбит в секунду она возросла более чем 10 раз [13]. Повысить скорость передачи данных можно двумя путями: увеличить пропускную способность канала связи, то есть провести улучшения на физическом уровне, или модернизировать алгоритмы, ко-торые используются для этого в сети. В настоящее время также очень важ-ную роль играет защита передаваемых по сети данных. Так как вычисли-тельные мощности современных устройств постоянно растут, многие ал-горитмы шифрования становятся небезопасны, о чем подробнее можно узнать в статье на Cloudfare [8].
В связи с вышеперечисленными требованиями, в 2012 году была разработана первая версия протокола передачи информации транспорт-ного уровня QUIC, который в настоящее время активно дорабатывается и становится стандартом в сети Интернет. Данный протокол является уни-версальным, и может прийти на замену TCP и UPD, из-за этого он являет-ся крайне динамическим, и может быть изменен под требования какого-либо проекта.
Так как крупные компании только разрабатывают свои первые вер-сии этого протокола, а большинство современных библиотек для работы c HTTP еще не реализовало данного протокола, становится не понятно, насколько эффективно будет его использовать в своем сервисе. Поэтому для точной оценки проделываемой работы требуется реализовать свой сервис.
ОСНОВНАЯ ЧАСТЬ
1. Обзор литературы
Для реализации сервисов, передающих информацию по протоколам HTTP 1, HTTP 2 и QUIC была изучена документация: RFC 9000 [1] для изучения основных алгоритмов работы протокола QUIC и его структуру пакета [6], RFC 8446 [2] для изучения алгоритмов работы протокола шифрования TLS 1.3, RFC 5246 [5] для изучения алгоритмов работы про-токола шифрования TLS 1.2, а также структуру пакета в протоколе HTTP 3 [7] и работа Александра Венедюхина «Как работает TLS» [12]. Во вре-мя изучения современных протоколов и их сравнения с предыдущими вер-сиями, а также возможностей HTTP 3 были использованы электронные ре-сурсы cloudfare [8], noorsoft [13], explained [10].
Для написания кодовой базы данный работы был использован язык программирования Python [4], библиотеки Pycryptodome [9], реализую-щая функциональность шифрования данных до протокола TLS версии 1.2 и Aioquic [14] для использования более проработанной версии протокола QUIC. Также была задействована система контроля версия git и GitHub [11] для хранения написанного кода.
2. Постановка задачи
Целью данного исследования являются сравнение скорости передачи данных с использованием разных версий протокола HTTP, в частности глубокое погружение в протокол транспортного уровня QUIC, который является базовой составляющей протокола HTTP 3, а также их изучение изнутри для выявления всех плюсов и минусов использования и самостоя-тельной реализации с доработками для использования в WEB-сервисах для более отзывчивого интерфейса и скорости работы приложения.
Для вышеуказанной задачи потребуется реализовать сервисы ис-пользующие разные протоколы передачи информации и шифрования дан-ных, сравнить скорость передачи данных в разных условиях сети, сделать выводы из проделанной работы.
3. Протокол TLS 1.3
Данный протокол защиты транспортного уровня является седьмой версией протокола шифрования TLS, ранее известного как ssl (Secure Sockets Layer — уровень защищённых сокетов). Он предназначен для за-щиты передаваемых данных в сети между ее узлами. А именно, данный протокол предоставляет шифрование данных, аутентификацию и целост-ность соединения.
3.1 Установка соединения
Общая схема установки соединения между клиентом и сервером в про-токоле TLS 1.3 выглядит следующим образом (См. рисунок 3.1)
● Клиент посылает на сервер сообщение ClientHello которое состоит из:
o Открытого ключа клиента, который получен по алгоритму Диффи-Хелмана или идентификаторы секретных ключей, если клиент и сервер, например, используют заранее известные сер-тификат и ключ
o Желаемый метод для обмена секретными ключами
o Метод цифровой подписи
● Сервер посылает клиенту сообщения
o Ответ для открытого ключа или идентификатор секретного ключа
o Если нужна аутентификация, сообщение CertificateRequest для получения сертификата от клиента
o Свой сертификат
o Сообщение Finished – рукопожатие завершено
● Клиент после проверки сертификата сервера генерирует секретный ключ и отправляет:
o Сообщение Finished – рукопожатие завершено
o Если сервер запрашивал сертификат, отправляет сертификат
o Первое зашифрованное сообщение
Соединение установлено, теперь все пересылаемые данные будут передаваться только в зашифрованном виде.
*Алгоритм Диффи-Хеллмана – алгоритм для получения между сторонами секретного ключа, по каналу связи, не защищенному от прослушивания.
Стоит отметить уникальную функцию TLS 1.3 которая получила название 0-RTT [2], она заключается в возможности клиента подключится к серверу, который был посещен ранее, без проводимой процедуры руко-пожатия для установки защищенного соединения и сразу начать пересы-лать полезные данные. Это возможно за счет хранения секретной инфор-мации на клиенте и сервере некоторое время после разрыва соединения. Отличие от TLS 1.2 в котором реализован 1-RTT [5] заключается в том, что в первом же пакете отсылаются полезные данные, но это может быть небезопасно. В QUIC доработана эта функция таким образом, что при первой отправке пакета сразу возможно отправить полезные данные.
По сравнению с прошлыми версиями, установка соединения проис-ходит на один полный цикл быстрее, за счет чего экономится от 0.1 секун-ды, удален лишний цикл подтверждения сообщения Finished через сооб-щение от сервера ChangeCipherSpec, ранее это происходило отельными сообщениями.
Рисунок 3.1 - Установка соединения между клиентом и сервером по прото-колу QUIC (TLS 1.3) по документации RFC [1]
3.2 Алгоритмы шифрования
В новой версии протокола отказались от старых небезопасных алго-ритмов шифрования, например от алгоритмов шифрования DES и 3DES или алгоритмов хеширования MD5 и SHA-1 [2].
Алгоритмы шифрования оцениваются сложностью памяти и быстро-действия, поэтому 3DES считается безопасным до 2030 года. На его взлом понадобится около 2^32 бит известного открытого текста, 2^113 шагов, 2^90 циклов DES-шифрования и 2^88 бит памяти [3]
В TLS 1.3 согласовано поддержание шифров [2]:
● TLS_AES_128_CCM_SHA256
● TLS_AES_256_GCM_SHA384
● TLS_AES_128_GCM_SHA256
● TLS_CHACHA20_POLY1305_SHA256
● TLS_AES_128_CCM_8_SHA256
Данные шифры реализуют так называемое «Блочное шифрование» или AEAD, где само сообщение шифруется либо с помощью блочного шифра и имитовставки (MAC) - символы, которыми подписывается сообщение, полученные после установки соединения, либо с помощью АЕ-схемы [3].
*AE-схема – аутентификация-шифрование схема (от англ. Authenticated encryption) [3]
В первом варианте воспользуемся методом Encrypt-then-mac: снача-ла шифруется сообщение M с использованием nonce N, затем заголовок H и зашифрованное сообщение аутентифицируются с помощью MAC с тем же nonce. (См. рисунок 3.2)
*Nonce – случайное неповторяющееся число.
Рисунок 3.2 - Алгоритм шифрования Encrypt-then-mac
Сами шифры отличаются длинной MAC и ключа шифрования, по-этому реализация сводится написанию алгоритма AEAD.
Для реализации протокола воспользуемся библиотекой на python Cryptodome. Напишем методы генерации nonce, шифрования и дешифро-вания сообщения.
3.3 Реализация базового протокола QUIC
Для проверки протокола шифрования, несовместимого с предыдущими версиями, нужно реализовать своих клиента и сервера работающих по протоколу QUIC.
● QUIC — это протокол транспортного уровня, на котором базируется протокол HTTP 3, он реализован как обертка на протокол UDP и реа-лизует шифрование данных по протоколу TLS 1.3 и несколько других функция, потенциально позволяющих передавать данные по сети быст-рее, и в более защищенном виде, чем при использовании более ранних версий HTTP [1].
Базовая реализация протокола будет включать в себя:
1. Построение фрейма(пакета) для передачи по сети точка-точка
2. Буфер для поддержания состояния и реализации 0-RTT (реализовано в TLS [2])
3. Поддержка секретного ключа для каждого фрейма данных, с посто-янным обновлением
3.4 Построение пакета для передачи данных QUIC
Для построения базового пакета для передачи данных по протоколу QUIC воспользуемся документацией RFC [6] для построения фрейма дан-ных, реализуем основную структуру пакета, полная реализация на GitHub [11]. Основные флаги и типы фреймов (См. рисунок 3.3, 3.4)
Рисунок 3.3 - Все возможные типы фреймов пакета QUIC по RFC
Рисунок 3.4 - Основная флаги и типы фреймов пакета QUIC в реализации
PING – Используется для поддержания соединения в рабочем состоянии
ASK – Набор идентификаторов пакетов, для подтверждения получения и обработки пакетов.
Padding – используются для увеличения размера пакета, например для увеличения начального пакета до минимального размера или для обеспе-чения защиты от анализа трафика
Reset stream – кадр, для сообщения о прекращении потока данных.
Blocked – используется, чтобы сообщить, что все входящие кадры отбра-сываются.
Connections close – используется, для уведомления о закрытии соединения
Window update – используется, для согласования используемой версии
Go away – общий фрейм ошибки (для упрощения).
Мы опустим фреймы для установки максимального размера потока данных и максимального размера пакета, задав стандартный размер. Так-же не будут использованы многие необязательные фреймы.
3.5 Реализация клиента и сервера с поддержанием сессии
Для реализации клиента и сервера воспользуемся нашим клиентом и сервером, которые умеют передавать данные. Достаточно создать объекты в памяти, и для прослушивания порта зациклить функции. Для этого вос-пользуемся библиотекой asyncio, для запуска клиента и сервера на отдель-ных потоках. Данный код можно посмотреть на GitHub [11].
Теперь мы можем передать первое наше сообщение, а именно – СlientHello, также сгенерируем ключ для шифрования данных на сервере, и передадим его клиенту (Так делать не рекомендуется, все в целях про-верки).
После запуска тестовой отправки сообщения получаем следующий результат:
client hello: 16030100a5010000a10303303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f20606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f000213040100005600000012001000000d33342e3235332e3234342e3736002b0003020304002d000201000029002f000a000431353231000000000021204a769821ad0aa2cabd1fdcbb5aee9e6293aec5abdf4498528323b7a07c56ff1b
Здесь мы видим сообщение client hello, которое передается от клиента сер-веру при первой установке соединения.
Что можно наблюдать и в Wireshark (См. рисунок 3.5)
Рисунок 3.5 - Вид реализованного пакета QUIC в Wireshark
4. Реализация HTTP сервисов
Для сравнения скорости передачи данных будем использовать стан-дартные HTTP-запросы, в данном случае GET-запрос на отправку файла со стороны сервера клиенту. Для этого понадобится реализовать простей-шие HTTP-сервисы, работающие по протоколам версий от первой до тре-тьей.
4.1 HTTP 1
Для начала был реализован базовые клиент и сервер, использующие для передачи данных протокол HTTP первой версии. Т. к. в протоколе HTTP 3 на транспортном уровне реализовано шифрование по протоколу TLS1.3, для более честного тестирования добавим шифрование пакетов по алгоритму TLS_AES_256_GCM_SHA384 из версии 1.2 и отключим не поддерживаемые способы, что видно в коде на GitHub [11]. Этот функцио-нал поддерживает готовая реализация протокола из библиотеки aiohttp на Python, сам же алгоритм реализован в библиотеке ssl. Для множественной нагрузки и ускорения передачи будем запрашивать соединения асинхрон-но(параллельно), для этого воспользуемся библиотекой asyncio.
4.2 HTTP 2
Аналогично напишем сервер и клиент, общающихся по протоколу HTTP второй версии. Его главное отличие будет состоять в возможности мультиплексирования на уровне протокола HTTP. А значит мы можем не блокировать потоки и передавать запросы параллельно.
4.3 HTTP 3
Протокол HTTP 3 довольно новый, некоторые браузеры начали поддерживать его с 2019–2020 года [10], и современные библиотеки для реализации HTTP-сервисов только начинают добавлять его в свой функ-ционал.
Сессия соединения стандартно поддерживается на транспортном уровне в протоколе QUIC [1], поэтому протокол прикладного уровня должен поддерживать основной функции HTTP, а именно, поля HTTP, представление стандартных методов HTTP (GET, POST и другие), обра-ботка ошибок запросов и ответов.
В данном случае для проверки скорости передачи данных и обра-ботки базовых ошибок нам достаточно уметь заново запрашивать данные при ошибке и воспроизвести метод для получения данных сервера клиен-том или наоборот.
Мы не будем реализовывать полноценный HTTP 3 сервис, а лишь воспользуемся клиентом и сервером QUIC, организуем передачу фреймов, простую обработку ошибок, обработку событий, которые предают между собой клиент и сервер, и механизм, поддерживающий целостность данных – в данном случае при ошибке получения пакета или его нехватке, сервер будет запрашивать потерянные данные повторно.
Также реализуем подтверждение передачи фреймов: при обработке пакета сервер будет посылать ответ с кодом или текстом ответа.
В ходе проведения эксперимента я выяснил, что ранее реализован-ный мной протокол с основными функциями не обладает оптимизациями и технологиями, обязательными для передачи многофреймовых сообщений, например, требуется хорошо оптимизированный буфер для хранения от-правки и обработки большого количества пакетов, поэтому далее я вос-пользуюсь библиотекой aioquic для реализации клиент-серверного прило-жения на протоколе QUIC.
4.3.1 QUIC сервер
Выделим основные функции севера, которые должны быть реализова-ны:
1. Прослушивание порта и ожидание сообщений от клиента
2. Отделение сообщений друг от друга, даже если они отправлены в одной сессии
3. Обработка входящих пакетов данных
4. Подтверждение доставки пакета от клиента
5. Индексирование фреймов, за счет чего мы решим проблему holl-блокировок
6. Логирование событий отправки и принятия пакетов
7. Базовая обработка ошибок
8. Поддержка шифрования данных
9. Разделение потоков данных
Для упрощения тестирования сервер будет принимать какой-то поток данных от клиента, в данном случае текстовые файлы размером до 30мб разбитые на какое-то количество фреймов, сами потоки будут отделены разделительным фреймом с полем data = «all», более подробно можно по-смотреть на GitHub [11].
Рассмотрим на примере, из-за чего возникает блокировка потока оче-реди: допустим мы посылаем два файла по протоколу HTTP 1.1. Он рабо-тает в один поток, и соответственно два файла будут объединены в один заголовок ответа. Пока сервер не загрузит оба файла, мы не увидим ни одного из них, хотя они могли занимать, например 1КБ и 10мб, но для по-лучения маленького файла мы все равно ждем большого. Это решалось открытием нескольких соединений для разных файлов, что соответственно не является хорошим решением. Эта проблема решилась в HTTP 2 за счет мультиплексирования, на уровне HTTP начали подписывать пакеты дан-ных и отсылать независимо, это позволило разделить данные и посылать их независимо, но протокол транспортного уровня все также шлет данные одним потоком, и при потере какой-то части данных, он будет ожидать их заново и не загрузит не потерянную часть, а оставит ее в буфере. Чтобы решить данную проблемы будем подписывать пакеты на транспортном уровне, что и предлагает алгоритм протокола.
4.3.2 QUIC клиент
Основные функции клиента:
1. Индексирование пакетов данных
2. Обработка входящих пакетов данных
3. Отправка данных на сервер
4. Логирование событий отправки и принятия пакетов
5. Поддержка шифрования данных
6. Временное сохранение отправленных пакетов данных, для повтор-ного запроса данных по id пакета
Реализация данных функций приведена на Github [11]
После запуска сервера при попытке отправить файл с клиента можно наблюдать поток данных, который распознается как пакеты формата QUIC, что говорит об успешной отправке данных и функциональности сервиса (См. рисунок 4.1)
Рисунок 4.1 - Поток передачи пакетов по протоколу QUIC
5. Проверка скорости передачи данных
Для возможности проверки скорости передачи данных воспользуем-ся текстовым файлом размером в 30мб. Искусственно будут добавлены проблемы потери пакетов в сети и засечено время передачи 10 файлов для вычисления математического ожидания и среднеквадратического отклоне-ния времени передачи данных между узлами сети.
5.1 Передача без потерь пакетов
Начнем с передачи данных без каких-либо проблем со стороны сер-вера и клиента. Будут производиться параллельные запросы со стороны клиента на сервер, для получения файлов text_{i}.txt, среди которых есть три «больших файла» под номерами 3, 6 и 9 размером 30мб и семь «ма-леньких». Результаты данных запросов отображены в Таблице А.1. Как мы видим, из-за «однопоточности» протокола HTTP 1 у нас возникают блокировки файлов, которые, казалось бы, должны быть получены быст-рее, т к. их размер меньше. Соответственно на клиенте, использующем протокол HTTP 2, такой проблемы нет, и файлы мы получаем параллель-но.
Блокировки потока очереди – главная проблема протокола HTTP 1, которые заключается в неспособности отделить разные файлы из одного потока фреймов. С данной проблемой справляется протокол HTTP 2 при помощи индексирования HTTP пакетов.
Проведем передачу файлов между узлами сети результаты данных запро-сов представлены в Таблице 1.1.
Матожидания и средние отклонения времени запросов файлов в дан-ном случае равны:
HTTP 1
М[x] = 0.217 секунд σ = 0.123 секунды max=0.39 секунды min=0.047 се-кунды
HTTP 2
М[x] = 0.2 секунды σ = 0.09 секунды max=0.344 секунды min=0.094 секун-ды
QUIC
М[x] = 1.275 секунд σ = 0.44 секунды max=2.031 секунды min=0.89 секун-ды
По этим данным мы можем сделать следующие выводы:
- Передача маленького фрейма данных происходит быстрее по протоколу HTTP 1
- Текущая реализация протокола QUIC и сервера взаимодействие по нему сильно уступает протоколам HTTP 1 и HTTP 2 (См. рисунок 5.1)
- В среднем передача по HTTP 2 происходит быстрее всего, а при исполь-зовании QUIC медленнее (См. рисунок 5.1)
- За счет индексирования пакетов данных и разбиения их на разные пото-ки, протоколу HTTP 2 удается получать маленькие файлы раньше, даже если они запрошены позже «больших» (См. рисунок 5.1)
Рисунок 5.1 - Сравнение скорости передачи данных без потерь пакетов
5.2 Передача с потерей пакетов
При потере пакета при передаче от источника к получателю возника-ет та же самая блокировка потока очереди, но лишь с тем отличием, что пакеты блокируется уже не на прикладном уровне, а на транспортном, эту проблему в как раз и пытается решить QUIC за счет того же индексирова-ния пакетов, но уже на транспортном уровне.
Еще раз повторим операции передачи файлов между клиентами и серверами, но добавим искусственную потерю пакетов при помощи утили-ты comcast. В командной строке Linux установим примерно 10-процентную потерю пакетов данных командой comcast –device=eth0 –packet-loss=10% --target-addr=127.0.0.1 –target-proto=tcp –target-port=4433.
Так мы получим потерю пакетов для HTTP 1 и HTTP 2 сервисов. Для QUIC сервера же достаточно в случайном порядке «терять пакеты» при помощи функции random, т. к. мы напрямую взаимодействуем с про-токолом транспортного уровня и управляем фреймами данных
Проведем передачу файлов между узлами сети (См рисунок 5.2), ре-зультаты данных запросов представлены в Таблице 1.2.
Матожидания и средние отклонения времени запросов файлов в дан-ном случае равны:
HTTP 1
М[x] = 0.246 секунды σ=0.15 секунды max=0.453 секунды min=0.032 се-кунды
HTTP 2
М[x] = 0.237 секунды σ=0.16 секунды max=0.672 секунды min=0.078 се-кунды
QUIC
М[x] = 1.335 секунд σ = 0.92 секунды max=2.844 секунды min=0.5 секунды
По этим данным мы можем сделать следующие выводы:
- Текущая реализация протокола QUIC и сервера взаимодействие по нему сильно уступает протоколам HTTP 1 и HTTP 2 (См. рисунок 5.2)
- Потеря 10 процентов пакетов в случайной выборке дали следующий по-тери в скорости в среднем: HTTP 1–12%, HTTP 2–16%, QUIC (HTTP 3) – 5%, из чего следует, что последний является самым стабильным при воз-можной потери пакетов.(См. рисунок 5.3, 5.4, 5.5)
Стоит отметить, что был реализован только базовый сервер QUIC без множества возможных оптимизаций, например таких как кэширование, от-сюда возникает большая разница в скорости передачи файлов между про-токолами.
● Первый файл является «маленьким», но на всех примерах может пере-даваться дольше, чем другие того же размера, это связано с установкой соединения между клиентом и сервером (рукопожатием)
Рисунок 5.2 - Сравнение скорости передачи данных с потерями пакетов
Рисунок 5.3 - Сравнение скорости передачи данных по протоколу HTTP 1
Рисунок 5.4 - Сравнение скорости передачи данных по протоколу HTTP 2
Рисунок 5.5 - Сравнение скорости передачи данных по протоколу QUIC
6. Результаты
После получения тестовых данных будет произведен анализ данных и сделаны некоторые выводы.
6.1 Результаты исследования скорости протокола
В результате проведенного исследования было замечено, что в про-центном соотношении при потере пакетов в сети протокол QUIC показыва-ет наиболее высокие показатели по сравнению с «идеальной» сетью. А са-мым стабильным остается “однопоточный” HTTP 1. Это показывает, что новый протокол передачи информации, несмотря на шифрование данных, может, как минимум, быть очень полезен при работе с нестабильной сетью, например для использования на смартфонах, поездах и т. п.
Также можно обратиться к версии протокола QUIC, которая в насто-ящее время разрабатывается ВКонтакте [15]. Сравнивая скорость рендера страницы, использующей протокол HTTP 2 и HTTP 3, удалось добиться следующего результата (См. рисунок 6.1)
Рисунок 6.1 - Сравнение скорости протоколов в Web-сервисе
Это говорит о том, что при должных улучшениях протокола HTTP 3 он может оказаться быстрее, чем его предыдущие версии. Скорее всего, данный протокол был оптимизирован для использования конкретно на Web-приложение, возможно задействовано несколько портов, что позво-ляет получать файлы быстрее. Но компания все еще не задействовала дан-ную разработку на своих сервисах.
6.2 Идеи доработки HTTP 3 сервера и протокола QUIC
Протокол QUIC является сильно динамическим протоколом, это дает возможность выстраивать клиент-серверные отношения в зависимости от задачи. Например, в данной работе он был использован аналогично TCP, и на каждый отправленный пакет клиент ждет подтверждения его обработ-ки от сервера, что не является оптимальным вариантом, но т. к. сам про-токол реализован как обертка над UDP, его можно использовать для пере-дачи информации без такой функциональности, например, для передачи видео.
В реализованном сервисе на базе протокола QUIC видно следующие доработки:
- Подтверждение принятия пакета клиентом или сервером через какой-то промежуток времени или несколько принятых пакетов
- Возможность сервера и клиента работать на нескольких портах автома-тически, что позволяло бы значительно увеличить скорость передачи
6.3 Дальнейшие шаги разработки
Следующими шагами разработки приложения станет полная совме-стимость с HTTP 3 и развертывание Web-сервиса, который сможет исполь-зовать реализованный сервер для передачи информации. Для доработки сервиса потребуется научиться обрабатывать ошибки прикладного и транспортного уровней, провести работу над оптимизациями скорости пе-редачи данных как на уровне QUIC-сервера, так и на уровне HTTP.
7. Используемые технологии
1. Aioquic – библиотека для многопоточного запуска кода на Python
2. Python – язык программирования
3. Git – система контроля версия
4. Openssl – утилита для генерации сертификатов и ключей
5. С – язык программирования
6. Wireshark – программа для отслеживания пакетов в сети
ЗАКЛЮЧЕНИЕ
В результате выполнения данной работы я успешно реализовал про-токолы TLS 1.3 и QUIC, углубился в языки программирования Python и C, изучил многие алгоритмы шифрования данных, например MD5 и DES, изучил большое количество документации RFC, углубился в протокол QUIC.
Были реализованы и протестированы клиент-серверные приложения, использующие протоколы передачи данных HTTP от первой версии до третьей, на скорость передачи данных. Проведено измерение скоростей передачи информации в сервисах, использующих разные протоколы для обмена данными, по эти наблюдениям сделаны соответствующие выводы. Сервер, использующий базовый протокол HTTP 3, описанный в до-кументации, позволяет получить выигрыш в некоторых случаях, напри-мер, при потере пакетов данных, за счет их индексирования.
Более ранние версии протокола же используют ту же технологию, но для других целей.
СПИСОК ЛИТЕРАТУРЫ
1. RFC 9000. Протокол QUIC [электронный ресурс] URL: https://datatracker.ietf.org/doc/html/rfc9000 (Дата обращения: 12.11.2022)
2. RFC 8446. Протокол TLS 1.3 [электронный ресурс] URL: https://www.rfc-editor.org/rfc/rfc8446#appendix-C.3 (Дата обращения: 03.01.2023)
3. Wikipedia. Протокол TLS 1.3 [электронный ресурс] URL: https://ru.wikipedia.org/wiki/TLS_1.3 (Дата обращения: 26.12.2022)
4. Python. Документация: [электронный ресурс] URL: https://docs.python.org/3/library/ssl.html#tls-1-3 (Дата обращения: 26.02.2023)
5. RFC 5246. Протокол TLS 1.2 [электронный ресурс] URL: https://www.rfc-editor.org/rfc/rfc5246 (Дата обращения: 21.03.2023)
6. RFC. Структура пакета QUIC [электронный ресурс] URL: https://datatracker.ietf.org/doc/html/draft-marx-quic-qlog-quic-events (Дата обращения: 15.03.2023)
7. RFC. Структура пакета HTTP 3 [электронный ресурс] URL: https://datatracker.ietf.org/doc/html/draft-marx-quic-qlog-h3-events (Дата обращения: 23.04.2023)
8. Cloudfare. История HTTP [электронный ресурс] URL: https://blog.cloudflare.com/the-state-of-http-in-2022/ (Дата обращения: 12.01.2023)
9. Pycryptodome. Документация библиотеки для шифрования данных [электронный ресурс] URL: https://pycryptodome.readthedocs.io/en/latest/src/cipher/cipher.html (Дата обращения: 14.05.2023)
10. HTTP 3. Краткая информация о протоколе и его развитии [элек-тронный ресурс] URL: https://http3-explained.haxx.se/ (Дата обращения: 03.02.2023)
11. Github. Реализация сервисов на Python [электронный ресурс] URL: https://github.com/MichailNonProgramer/Diplom (Дата обращения: 03.02.2023)
12. Александр Венедюхин, Ключи, шифры, сообщения: как работает TLS (Техническое описание TLS) [Электронный ресурс] URL: https://tls.dxdt.ru/tls.html (Дата обращения: 26.12.2023)
13. Скорость передачи данных в сети [Электронный ресурс] URL: https://noorsoft-mobile.ru/blog/kak-izmenilsya-internet-za-poslednie-10-let (Дата обращения: 21.05.2023)
14. Aioquic. Документация библиотеки на Python [Электронный ресурс] URL: https://aioquic.readthedocs.io/en/latest/ (Дата обращения: 12.04.2023)
15. QUIC от ВКонтакте. Реализация сервиса на С [Электронный ресурс] URL: https://github.com/VKCOM/nginx-quic (Дата обращения: 14.05.2023)
ПРИЛОЖЕНИЯ
Таблица 1.1 - Времена передачи данных без потерь пакетов 10 файлов
Имя файла HTTP 1, сек HTTP 2, сек QUIC (HTTP 3),
Сек
File1 0.047 0.141 0.891
File2 0.047 0.094 0.906
File3 0.14 0.328 1.750
File4 0.156 0.125 0.953
File5 0.172 0.141 0.969
File6 0.265 0.344 1.735
File7 0.281 0.172 1.547
File8 0.297 0.172 1.078
File9 0.375 0.344 2.031
File10 0.39 0.131 0.89
Таблица 1.2 - Времена передачи данных с потерями пакетов 10 файлов
Имя файла HTTP 1, сек HTTP 2, сек QUIC (HTTP 3),
Сек
File1 0.032 0.094 0.89
File2 0.047 0.266 0.735
File3 0.157 0.672 2.725
File4 0.172 0.078 0.547
File5 0.203 0.094 0.828
File6 0.297 0.297 2.844
File7 0.313 0.156 0.5
Продолжение таблицы 1.2
File8 0.344 0.156 0.781
File9 0.438 0.344 2.344
File10 0.453 0.672 1.156