Перечень сокращений, условных обозначений, символов, единиц и терминов 3
ВВЕДЕНИЕ 4
Постановка задачи 6
Обзор литературы 7
Глава 1. Описание основных транспортных протоколов в сети интернет 8
1.1 Транспортный протокол TCP 8
1.1.1 Установка соединения TCP 10
1.1.2 Передача данных 13
1.1.3 Закрытие соединения 14
1.1.4 Проблемы TCP 14
1.2 Транспортный протокол UDP 15
1.2.1 Проблемы UDP 16
Глава 2. Транспортный протокол QUIC 17
2.1 Потоки 18
2.2 Соединения 19
2.3 Преимущества и недостатки QUIC в сравнение с TCP + TLS 21
Глава 3. Улучшения HTTP/3 24
Глава 4. Использование протокола QUIC в веб-приложении 26
4.1 Имплементация QUIC в веб-приложение 27
4.2 Сравнительный анализ производительности QUIC и TCP 34
Выводы 40
Заключение 41
Список литературы 42
Купить

Многие годы весь интернет использовал TCP протокол для передачи данных, который начал устаревать еще в 2000-х годах. Данный протокол изначально не был создан для эффективной работы в современных сетях. Например, TCP соединение строго зависит от IP-адресов источника и получателя, что является хорошим решением, кода оба узла обмена статичны, как изначально планировалось, но с развитием коммуникационных технологий, появились беспроводные сети, и источник перестал быть привязан к одному IP. Таким образом, пользователь, подключенный к сети по LTE, может менять свой IP-адрес просто идя по улице, таким образом вынуждая TCP создавать новое соединение, что увеличивает задержку в получении данных. Еще одной проблемой TCP является то, что все данные, передаваемые по TCP, протокол передает как один файл или поток байтов, даже если на самом деле их несколько. Это привело к одной из самых известных проблем TCP - блокировке начала очереди.
В последние годы, большинство компаний, работающих в сфере веб-технологий пытались улучшить пользовательский опыт и безопасность коммуникации между пользователями и сервисами компании. Для этого, предпринимались попытки решить проблемы как на высоких, так и на более низких уровнях стека технологий в сети интернет. Так, некоторые компании создавали свой протокол поверх UDP, чтобы решить проблемы TCP, который сейчас использует преобладающее множество клиент-серверных приложений. Одной из таких попыток создать свой протокол был QUIC, разработанный компанией Google в 2012 году. Позже стандартизированный и легший в основу HTTP/3, протокол обещал решить большинство проблем стека TCP в связке с TLS.
На данный момент, QUIC активно развивается, сформированная в 2016 году рабочая группа рассмотрела более 23 версий спецификации и продолжает развивать ее. Сервисы Google, такие как YouTube, Search, Gmail и многие другие полностью переведены на инфраструктуру HTTP/3.
Постановка задачи
Целью работы является анализ существующих решений со стороны клиента и сервера для использования протокола QUIC в современном веб-приложении. Для достижения поставленной цели необходимо: проанализировать протокол в текущей спецификации draft-ietf-quic-transport- 27, создать клиент-серверное приложение в виде текстового чата с множеством пользователей, проанализировать сложности имплементации данного протокола, а также описать пути решения тех или иных задач, возникших при использовании данного протокола. На данный момент протокол имеет малое количество ресурсов и реализаций, а также достаточно низкоуровневые API, что может стать сложностью при имплементации нового решения в существующую архитектуру, так как устоявшиеся технологии имеют гораздо более высокий уровень абстракций как на стороне сервера, так и на стороне клиента.
Также при разработке веб-приложения поставлена задача реализовать упрощенную версию технологии WebSocket, но работающую поверх HTTP/3. Для этих целей предполагается использование клиентского WebTransport API для взаимодействия с сервером по HTTP/3 на низком уровне потоков. Необходимо написать клиентский модуль, инкапсулирующий сложности при управлении потоками, дающий возможности передавать данные между клиентом и сервером с помощью простых методов, близких к методам протокола WebSocket.

Купить