Протокол QUIC (название расшифровывается как Quick UDP Internet Connections) — это совершенно новый способ передачи информации в Интернете, построенный поверх протокола UDP, вместо общепринятого ранее использования TCP. Некоторые называют это (в шутку) TCP/2 .
Переход на UDP — самая интересная и мощная функция протокола, из которой вытекают еще несколько возможностей.
Сегодняшняя сеть Интернет построена на протоколе TCP, который был выбран из-за его надежности и гарантированной доставки пакетов.
Для открытия TCP-соединения используется так называемое «трехкратное рукопожатие».
Это означает дополнительные повторы для каждого нового соединения, что увеличивает задержку.
Если вы хотите установить безопасное соединение TLS, вам придется пересылать еще больше пакетов.
Некоторые инновации, такие как TCP быстрое открытие , улучшит некоторые аспекты ситуации, но эта технология пока не получила большого распространения.
UDP же построен на идее «отправить пакет и забыть о нем».
Сообщение, отправленное по UDP, будет доставлено получателю (не гарантировано, с некоторой вероятностью успеха).
Явным преимуществом здесь является более короткое время установки соединения; таким же явным недостатком является отсутствие гарантии доставки или порядка поступления пакетов к получателю.
Это означает, что для обеспечения надежности вам придется построить какой-то механизм поверх UDP, гарантирующий доставку пакетов.
Именно здесь на сцену выходит QUIC от Google. Протокол QUIC может открывать соединение и согласовывать все параметры TLS (HTTP) в 1 или 2 пакетах (1 или 2 зависит от того, открыто ли соединение с новым сервером или с уже знакомым).
Это позволяет невероятно быстро открыть соединение и начать загрузку данных.
Зачем вам нужен QUIC?
Планы команды разработчиков протокола QUIC выглядят весьма амбициозными: протокол попытается совместить скорость UDP с надежностью TCP. Вот что об этом пишет Википедия:Улучшение TCP было долгосрочной целью Google, и QUIC спроектирован как эквивалент независимого TCP-соединения, но с уменьшенной задержкой и улучшенной поддержкой мультиплексирования в стиле SPDY. Если QUIC окажется эффективным, эти функции могут быть включены в следующие версии протоколов TCP и TLS (на разработку которых уходит больше времени).В этой цитате есть важный момент: Если QUIC докажет свою эффективность, то есть шанс, что опробованные в нем идеи станут частью следующей версии TCP. .
Протокол TCP достаточно сильно формализован.
Его реализации встречаются в ядрах Windows и Linux, в каждой мобильной ОС и во многих более простых устройствах.
Улучшить TCP непросто, поскольку все эти реализации должны его поддерживать.
UDP, с другой стороны, является относительно простым протоколом.
Гораздо быстрее разработать новый протокол поверх UDP, чтобы иметь возможность проверять теоретические идеи, работать в перегруженных сетях, обрабатывать потоки, заблокированные потерянным пакетом и т. д. Как только эти моменты будут прояснены, можно начинать работу по портированию лучшие части QUIC в следующую версию TCP.
Где находится QUIC сегодня?
Если вы посмотрите на уровни, составляющие современное HTTP-соединение, вы увидите, что QUIC заменяет весь стек TLS и часть HTTP/2. Да, протокол QUIC реализует собственный криптографический уровень, позволяющий избежать использования TLS 1.2.
Небольшой уровень API HTTP/2 работает поверх QUIC и используется для связи с удаленными серверами.
Он меньше полной реализации HTTP/2, поскольку мультиплексирование и установление соединения уже реализованы в QUIC. Осталось только реализовать протокол HTTP.
Блокировка начала линии
Протоколы SPDY и HTTP/2 используют одно TCP-соединение с сервером вместо отдельных соединений для каждой страницы.Это единственное соединение можно использовать для независимого запроса и получения отдельных ресурсов.
Поскольку вся связь теперь строится на одном TCP-соединении, мы автоматически получаем один недостаток: блокировку начала строки.
Протокол TCP требует, чтобы пакеты приходили (или, скорее, обрабатывались) в правильном порядке.
Если пакет потерян на пути к/от сервера, его необходимо отправить повторно.
TCP-соединение в это время должно ждать (блокироваться), и только после повторного получения потерянного пакета обработка всех пакетов в очереди продолжается — только так можно обеспечить правильный порядок обработки пакетов.
Протокол QUIC решает эту проблему кардинально — за счет отказа от протокола TCP в пользу UDP, который не требует соблюдения порядка обработки полученных пакетов.
И хотя потеря пакетов, конечно, все еще возможна, но это повлияет только на обработку тех ресурсов (отдельных файлов HTML\CSS\JS), которым принадлежит потерянный пакет. 
QUIC очень элегантно сочетает в себе лучшие стороны SPDY\HTTP2 (мультиплексирование) с неблокирующим транспортным протоколом.
Почему важно уменьшать количество отправляемых пакетов?
Если у вас быстрое подключение к Интернету, то задержки передачи пакетов между вашим компьютером и удаленным сервером составляют около 10-50 мс.Каждый пакет, отправленный от вас по сети, будет получен сервером по истечении этого периода времени.
Для такого порядка величин преимущества QUIC могут быть не очень очевидны.
Но как только мы рассматриваем вопрос обмена данными с сервером на другом континенте или использованием мобильных сетей, мы уже имеем задержки порядка 100-150 мс.
В результате на мобильном устройстве при обращении к удаленному серверу разница между 4 пакетами TCP+TLS и одним пакетом QUIC может составлять около 300 мс, что уже является значительной величиной, видимой невооруженным глазом.
Превентивное исправление ошибок
Элегантной особенностью протокола QUIC является прямое исправление ошибок (FEC).Каждый пересылаемый пакет содержит определенный объем данных из других пакетов, что позволяет восстановить любой потерянный пакет из данных его соседей без необходимости запрашивать повторную передачу потерянного пакета и ждать его содержимого.
По сути, это реализация RAID 5 на сетевом уровне.
Но уже сейчас виден недостаток такого решения: каждая упаковка становится немного больше.
Текущая реализация устанавливает этот оверхед на уровне 10%, т.е.
делая каждый отправленный пакет на 10% больше, мы тем самым получаем возможность восстановить данные без повторного запроса, если потеряно не более каждого десятого пакета.
Эта избыточность – это затраты пропускной способности сети на уменьшение задержек (что кажется логичным, ведь скорости соединения и пропускная способность каналов постоянно растут, но тот факт, что передача данных на другой конец планеты занимает сто миллисекунд, вряд ли можно как-то изменить без фундаментальная революция в физике).
Возобновление сеанса и параллельные загрузки
Еще одна интересная особенность использования протокола UDP — вы больше не привязаны к IP-адресу сервера.В протоколе TCP соединение определяется четырьмя параметрами: IP-адресами сервера и клиента, портами сервера и клиента.
В Linux вы можете увидеть эти параметры для каждого установленного соединения с помощью команды netstat:
Если какой-либо из этих четырех параметров необходимо изменить, нам нужно будет открыть новое TCP-соединение.$ netstat -anlp | grep ':443' .tcp6 0 0 2a03:a800:a1:1952::f:443 2604:a580:2:1::7:57940 TIME_WAIT - tcp 0 0 31.193.180.217:443 81.82.98.95:59355 TIME_WAIT - .
Вот почему сложно поддерживать стабильное соединение на мобильных устройствах при переключении между WiFi и 3G/LTE. 
В QUIC с использованием UDP такого набора параметров больше не существует. QUIC представляет концепцию идентификатора соединения, называемого Connection UUID. Становится возможным переключиться с Wi-Fi на LTE, сохраняя при этом UUID соединения, что позволяет избежать затрат на повторное создание соединения.
Это работает аналогичным образом Мош Шелл , сохраняя активное соединение SSH при изменении IP-адреса.
Этот подход также открывает возможности для использования нескольких источников для запроса контента.
Если UUID соединения можно использовать для перехода от Wi-Fi к мобильной сети, то теоретически мы могли бы использовать их оба одновременно для параллельного получения данных.
Больше каналов связи означает большую пропускную способность.
Практические реализации QUIC
В браузере Chrome имеется экспериментальная поддержка QUIC с 2014 года.Если вы хотите протестировать QUIC, вы можете включить его в Chrome и попробовать поработать с поддерживающими его сервисами Google. Это сильное преимущество Google — возможность использовать комбинацию своего браузера и собственных веб-ресурсов.
Включив QUIC в самом популярном в мире браузере (Chrome) и на сайтах с высокой нагрузкой (Youtube.com, Google.com), они смогут получать большую наглядную статистику использования протокола, что позволит им идентифицировать все существенные проблемы практического использования QUIC.
Есть Плагин Chrome , который в виде значка показывает поддержку сервером протоколов HTTP/2 и QUIC.
Посмотреть открытые подключения QUIC также можно, открыв вкладку хром://net-internals/#quic прямо сейчас (обратите внимание в таблице на упомянутый ранее параметр Connection UUID) 
Вы можете пойти еще дальше и увидеть все открытые соединения и все пакеты, отправленные по ним: chrome://net-internals/#events&q=type:QUIC_SESSION%20is:активный .
Как во всем этом работают брандмауэры?
Если вы системный администратор или сетевой инженер, возможно, вы немного вздрогнули, когда услышали, что QUIC использует UDP вместо TCP. Да, у вас, вероятно, есть свои причины.
Возможно, у вас (как, например, у нашей компании) настройки доступа к веб-серверу выглядят примерно так: 
Самое главное здесь, конечно, столбец протокола, в котором четко написано «TCP».
Эти типы настроек используются тысячами веб-серверов по всему миру, потому что они имеют смысл.
Порты 80 и 443, только TCP — и ничего больше не должно быть разрешено на рабочем веб-сервере.
Нет UDP. Что ж, если мы хотим использовать QUIC, нам придется добавить разрешение для UDP-соединений на порту 443. В крупных корпоративных сетях это может стать проблемой.
Как показывает статистика Google, UDP заблокирован в некоторых местах: 
Такие цифры были получены в ходе недавнего исследования, проведенного в Швеции.
Отметим несколько ключевых моментов:
- Поскольку QUIC тестировался только с сервисами Google, можно предположить, что недоступности из-за неправильно настроенного фаервола на сервере не было.
- Цифры отражают успешность исходящих запросов от пользователей на UDP-порт 443.
- QUIC может быть отключен в Chrome по разным причинам.
Могу поспорить, что в некоторых корпоративных средах он был отключен заранее, просто на всякий случай.
- Поскольку протокол QUIC по умолчанию использует шифрование, нам нужно беспокоиться только о доступе к порту 443; доступность или недоступность порта 80 не должна иметь никакого влияния.
Использование QUIC на стороне сервера
В настоящее время QUIC поддерживается веб-сервером.Кэдди (начиная с версии 0.9).
И клиентская, и серверная реализации QUIC все еще находятся в стадии экспериментальной поддержки, поэтому будьте осторожны при использовании QUIC на практике.
Поскольку ни у кого QUIC не включен по умолчанию, вероятно, можно безопасно включить его на своем сервере и поэкспериментировать с браузером (обновление: начиная с версии 52, QUIC включен по умолчанию в Chrome).
Производительность QUIC
В 2015 году Google опубликовал некоторые результаты измерений производительности QUIC.Как и ожидалось, QUIC превосходит классический TCP на плохих каналах связи, давая выигрыш в полсекунды при загрузке стартовой страницы.Особенно интересна статистика Youtube. Если улучшения такого масштаба действительно возможны, то мы увидим очень быстрое внедрение QUIC, по крайней мере, в сфере видеосервисов, таких как Vimeo, а также на рынке «видео для взрослых».www.google.com на 1% самых медленных соединений.
Этот прирост еще более заметен на видеосервисах, таких как YouTube. Пользователи на 30% меньше жаловался к задержкам из-за буферизации при просмотре видео при использовании QUIC.
выводы
Лично я считаю протокол QUIC просто потрясающим! Огромный труд, вложенный в него его разработчиками, не пропал даром — сам факт того, что крупнейшие сайты в Интернете уже сегодня поддерживают QUIC, немного ошеломляет. Мне не терпится увидеть окончательную спецификацию QUIC и ее дальнейшую реализацию во всех браузерах и веб-серверах.
Комментарий к статье Джима Роскинда, одного из разработчиков QUIC
Я потратил много лет на исследование, проектирование и разработку реализации протокола QUIC и хотел бы добавить к статье некоторые свои мысли.Дополнительная информация по теме:В тексте правильно отмечен момент о вероятной недоступности протокола QUIC для некоторых пользователей из-за жёсткой корпоративной политики в отношении протокола UDP. Именно по этой причине мы получили среднюю доступность протокола 93%.
Если мы вернемся немного назад во времени, то увидим, что совсем недавно корпоративные системы часто запрещали даже исходящий трафик на 80 порт, аргументируя это тем, что «это уменьшит количество времени, которое сотрудники тратят на серфинг в ущерб работе».
Позже, как известно, преимущества доступа к веб-сайтам (в том числе и в производственных целях) заставили большинство корпораций пересмотреть свои правила, разрешающие доступ в Интернет с рабочего места рядового сотрудника.
Нечто подобное я ожидаю и с протоколом QUIC: как только станет понятно, что с новым протоколом связь может быть быстрее, задачи можно выполнять быстрее, он проникнет и на предприятие.
Я ожидаю, что QUIC массово заменит TCP, и это даже помимо того, что он передаст ряд своих идей следующей версии TCP. Дело в том, что TCP реализован в ядрах операционных систем, аппаратно, а значит адаптация к новой версии может занять 5-15 лет, тогда как внедрение QUIC поверх общедоступного и повсеместно поддерживаемого UDP может быть выполнено за один раз.
продукт/услуга всего за несколько недель или месяцев.
- QUIC: Мультиплексная транспортировка нового поколения по UDP
- Опыт развертывания QUIC @ Google
- Дизайн и обоснование QUIC
- Проект IETF: QUIC: безопасный и надежный транспорт на основе UDP для HTTP/2
-
Почтовый Сервер Для Сайта
19 Oct, 24
