Что такое Input Lag и как он влияет на впечатления от игры
Объясняем и показываем, как устроен Input Lag и почему это важно.
Абрикос Абрикосовый для Skillbox Media
Input Lag — задержка ввода. Время, которое проходит с момента получения команды до отображения того или иного действия на экране. После нажатия кнопки на контроллере электронике требуется время на просчёт сигнала и вывода картинки на дисплей — из-за этого и происходит задержка ввода.
Как устроен Input Lag?
Задержка ввода состоит из обработки сигнала контроллером, компьютером и дисплеем.
Объяснение от NVIDIA
Сценарист и копирайтер. Утверждает, что видел все фильмы и прошёл все игры, но редакция отказывается ему верить.
Для кого важен Input Lag?
Максимально важен для киберспортивных дисциплин — шутеров, файтингов, MOBA. Запаздывание реакции персонажа на команды влияет на соревнования не меньше, чем скорость реакции игрока. Input Lag — один из важнейших параметров в киберспорте наравне с частотой кадров в секунду. Про FPS мы писали ранее в другой статье.
Киберспортсмен Джордан n0thing Гилберт объясняет важность низкого Input Lag
Задержка ввода влияет на регистрацию выстрелов, низкий лаг позволяет делать фликшоты — это техника, при которой игрок в шутере очень резко целится во врага и метко стреляет.
В соревновательных дисциплинах существует понятие Peeker’s Advantage — преимущество подглядывающего. Заглядывающий за угол игрок имеет преимущество перед противником с другой стороны, что влияет на тактику в шутерах. Peeker’s Advantage зависит от задержки ввода.
Как снизить Input Lag?
Input Lag не прописывают в официальных спецификациях, параметр меняется в зависимости от «железа». На любом ПК есть несколько способов снизить лаг:
Чтобы снизить Input Lag на ТВ и консоли, следует отключить все программные средства улучшения видеосигнала — например, искусственное повышение плавности в динамичных сценах. По умолчанию все подобные параметры включены.
На время считывания данных из буфера кадров влияет скорость обновления дисплея. У монитора с высокой скоростью обновления задержка будет меньше.
Стоит использовать соответствующее ЖК-панели разрешение. Например, лаг повышается, если 4К-монитор сжимает изображение до Full HD.
Во многих современных телевизорах есть особый игровой режим. При подключении консоли используйте вход HDMI Game.
Для большей скорости отклика на любой платформе имеет смысл отключить HDR — о том, как устроен высокий динамический диапазон, мы писали в другом материале.
Производители «железа» разрабатывают технологии, специально заточенные под киберспорт. Например, NVIDIA Reflex измеряет и оптимизирует задержки системы в соревновательных играх.
Что делать, если лагают сетевые игры. Как снизить инпут лаг и задержки сети
Чтобы успешно играть и побеждать в сетевых играх, важно добиться максимальной отзывчивости управления и плавности картинки. Ощущения от игры полностью зависят от нескольких независящих друг от друга факторов. Сюда можно отнести производительность оборудования, задержки системы и ввода на стороне пользователя (т.е. время от нажатия на клавишу мыши до отображения выстрела на экране) и качество сетевого соединения. Чтобы добиться идеального отклика, нужно оптимизировать каждый из этих пунктов.
Как снизить системные задержки (инпут лаг)
Системные задержки — это время, которое проходит от нажатия клавиши до отображения результата на экране. Если максимально упростить, то это инпут лаг. Однако только задержками ввода дело не ограничивается. Системные задержки зависят еще и от особенностей работы компонентов ПК и быстроты монитора.
Используйте проводные клавиатуру и мышь. По проводу подключение всегда будет быстрее и стабильнее. Впрочем, беспроводные геймерские модели тоже есть, но они стоят дороже проводных аналогов.
Выключите обработку картинки (шумоподавление, уплавнялка и т.п.) или переключите режим изображения на игровой. Если вы играете на телевизоре, то это особенно актуально. Но на мониторе тоже может быть переключатель режимов. Например, у MSI есть специальный игровой режим, который называется Zero Latency. Чтобы понять, если такой режим на вашей модели монитора, обратитесь к инструкции или на официальный сайт производителя.
Выставьте максимально возможную частоту обновления дисплея. Некоторые дисплеи могут не поддерживает частоту более 60 Гц при максимальном разрешении, в таком случае стоит опуститься до 1080p. Например, именно так работают консоли PlayStation 5 и Xbox Series X с телевизорами, у которых есть только вход HDMI 2.0. В совместимых играх таким образом можно выставить режим 120 Гц. Кроме того, некоторые мониторы могут работать при повышенной частоте, даже если она официально не поддерживается. К примеру, монитор BenQ GW 2470 может работать при 75 Гц, если выставить кастомный режим изображения в драйверах видеокарты.
Отключите вертикальную синхронизацию в настройках игры. Из-за этого картинка может быть менее приятной, так как будут возникать разрывы кадра — так называемый тиринг. Однако отзывчивость может увеличиться. Обратите внимание, что при наличии у вашего монитора и видеокарты функций VRR, G-Sync или FreeSync разрывов быть не должно.
Включите технологию NVIDIA Reflex. Чтобы снизить задержку на стороне пользователя, стоит включить технологию NVIDIA Reflex, которая поддерживается многими сетевыми играми. Она работает на всех видеокартах GeForce начиная с 900 серии. Кроме того, для нее не нужно специальное оборудование вроде монитора и мышки. Наибольший эффект технология дает на высоких настройках графики. Подробнее о работе технологии мы писали в отдельной статье «Как перестать сливать катки и начать тащить».
Включите режим низкой задержки. Также в панели управления NVIDIA можно включить режим низкой задержки. По своему эффекту он похож на NVIDIA Reflex, но работает только в DirectX 11. Про все настройки панели управления мы писали в гайде «Как настроить видеокарту NVIDIA для игр». У видеокарт AMD есть схожая функция — Radeon Anti-Lag, которую тоже можно включить в настройках дрйвера.
Как снизить сетевые задержки
Другой вид задержек — сетевые. Качество соединения в основном зависит от вашего провайдера. В первую очередь здесь важен такой показатель, как пинг.
Важно! Высокий пинг и нестабильное соединение — разные вещи. Если часть пакетов теряется, то это ощутимо влияет на геймплей. К примеру, вас отбрасывает назад или игровой мир замирает на некоторое время. При плохом пинге, как правило, таких проблем нет, но есть ощутимая задержка в действиях. Грубо говоря, вас будут убивать раньше, чем вы сможете среагировать.
Как проверить пинг
Проверить пинг можно с помощью специализированных сайтов или мобильных приложений. Один из наиболее популярных — speedtest.net. Однако этот инструмент лучше подходит для измерения скорости. Именно пинг лучше проверить штатными средствами операционной системы Windows.
Как настроить сетевой адаптер для снижения пинга
Если у вас проблемы с пингом, то стоит настроить сетевой адаптер. Перейдите в диспетчер устройств и найдите свой сетевой адаптер. Как правило, это Realtek, Intel, Qualcomm, Killer или другой. Также в списке может быть беспроводной Wi-Fi адаптер.
Зайдите в свойства адаптера и перейдите на вкладку «Управление электропитанием». Снимите галочку с «Разрешить отключение устройства для экономии энергии». Далее перейдите в дополнительно и отключите следующие пункты:
Буферы передачи и приема нужно поставить на максимальное значение — 128 и 512 соответственно. Максимальное число очередей RSS должно быть выставлено на доступный максимум. Выгрузка протокола ARP и NS должны быть включены.
Можно настроить и Wi-Fi адаптер, если вы им пользуетесь для игр. Сначала нужно также выключить «Разрешить отключение устройства для экономии энергии» и далее перейти на вкладку «Дополнительно». Здесь нужно также отключить настройки, связанные с энергосбережением. Для «Режима энергосбережения MIMO» выберите «Нет SMPS». Отключите также:
Программы для снижения пинга
В сети можно найти множество программ для снижения пинга. Суть их работы можно свести к выбору оптимального маршрута соединения, благодаря чему и снижается задержка. Одна из популярных программ — ExitLag. Она платная, но есть бесплатный трехдневный период для теста. Чудес от нее ждать не стоит и если у вас уже неплохой пинг, то программа вряд ли существенно его уменьшит. Однако попробовать все же стоит. В настройках программы вам нужно выбрать игру и регион сервера, для которого требуется оптимизация.
Общие советы
Если дело не в провайдере, то кое-что все же можно сделать для уменьшения задержек. Как правило, проблемы с соединением связаны с роутером.
Перейдите на диапазон 5 ГГц. Многие современные роутеры работают в двух диапазонах: 2,4 ГГц и 5 ГГц. Последний — более продвинутый. Он устойчив к помехам и лучше работает в многоквартирных домах, где в каждой квартире по роутеру. Если ваше оборудование поддерживает 5 ГГц, попробуйте переключиться на эту частоту. Обратите внимание, что приемник сигнала тоже должен поддерживать этот стандарт.
Смените канал Wi-Fi. При помощи бесплатной утилиты WifiInfoView можно проверить, насколько загружены разные каналы Wi-Fi в вашем доме. В настройках роутера стоит выбрать наименее загруженный канал.
Обновите прошивку роутера. Стоит также обновить прошивку роутера. Если вы купили новое устройство, то это стоит сделать первым делом. Зайдите на официальный сайт производителя и найдите свежую прошивку для своей модели роутера. Обратите внимание, что нужно точно выяснять модель устройства, включая ревизии. Возможно, наилучшим вариантом будет установить стороннюю прошивку. Если у вашей модели роутера мощное комьюнити, стоит поискать информацию на профильных форумах.
Измените DNS-сервер. Также можно попробовать поменять стандартный DNS-сервер от провайдера на альтернативный от Google. Предпочитаемый сервер — 8.8.8.8, альтернативный — 8.8.4.4.
Перезагрузите роутер. Если возникают какие-либо неполадки с роутером, стоит его перезагрузить. Возможно, после этого проблема уйдет сама собой.
Подключитесь к роутеру по проводу. Если размещение роутера и вашего ПК позволяет подключиться по проводу, то именно так и стоит сделать. Проводное соединение — самое стабильное.
Играем через телевизор. Что такое INPUT LAG и как от него избавиться
Содержание
Содержание
Успех виртуальных баталий напрямую зависит от скорости реакции игрока. Но не менее важно, чтобы и информация выводилась с минимальной задержкой. Плохое интернет-соединение и долгая обработка сигнала на мониторе, телевизоре — все это мешает классной игре. Последнее явление получило название INPUT LAG.
Высокая задержка ввода — неприятная проблема. После замены телевизора или в гостях у друзей в глаза бросается запаздывание, с которым персонаж на экране реагирует на команды с геймпада. К небольшим тормозам можно привыкнуть, но слишком большая задержка значительно портит впечатления от игрового процесса.
Что такое input lag
Любому устройству вывода, будь то монитор или телевизор, требуется время на обработатку поступающегоий видеосигнала. Разница в том, что электроника современных игровых мониторов адаптирована для трансляции с минимальной задержкой на входе. Это достигается путем транслирования исходного сигнала, получаемого с видеокарты.
Архитектура телевизоров выполнена намного сложнее. Перед тем, как попасть на матрицу, сигнал подвергается значительной коррекции центральным процессором ТВ. В некоторых сценариях обработка занимает до 150 мс. Такая разница отчетливо заметна пользователю любого уровня. Не обязательно быть профессиональным геймером, чтобы уловить лаг в 1/7 секунды.
Таким образом, INPUT LAG — это время с момента получения сигнала устройством вывода до его отображения на экране.
Наиболее важное влияние время задержки оказывает на динамичные игры. Фанатам шутеров и файтингов критически важен низкий инпут лаг. От него напрямую зависит успех виртуальных баталий. В on-line дуэли выигрывает тот, кто первый увидит врага. И разница даже 50 мс окажется решающей.
Для любителей размеренных жанров — стратегий, RPG — низкое время задержки менее критично, но лишним тоже не будет.
Какую панель можно считать медленной? Однозначного ответа на этот вопрос не существует. Там, где профессиональный геймер заметит долгую задержку, обычный пользователь будет играть с комфортом. Условной границей принято считать отметку 50 мс. Модели с большим значением лучше избегать.
При выборе монитора этот параметр часто путают со временем отклика матрицы, которое показывает, сколько времени требуется пикселю, чтобы изменить своей цвет. Для современных ЖК-панелей значение чаще всего не превышает 12 мс.
Инпут лаг редко прописывают в официальных спецификациях по ряду причин. Во-первых, точно измерить параметр достаточно сложно. В интернете много независимых ресурсов, занимающихся этим вопросом. Значения, полученные в разных источниках для одной модели, часто различаются. Во-вторых, инпут лаг зависит от режима и настроек телевизора. Указание только основных вариантов займет значительную часть в спецификациях модели.
Подробная база с телевизорами и мониторами представлена на https://displaylag.com/display-database/. Ресурс позволяет быстро найти интересующую модель с помощью фильтров и сравнить ее параметры с другими вариантами. Единственный недостаток — приведено наименьшее значение задержки без указания используемых настроек. Ресурс https://www.rtings.com/tv/tools/table/ позволит сравнить инпут лаг в разных режимах.
Как измерить input lag
Техника измерения сводится к сравнению тестируемого устройства с эталонным, время обработки сигнала на котором условно равно нулю. Наиболее подходящим вариантом для этой задачи является монитор на ЭЛТ, подключенный без использования переходников к разъему DVI.
В случае отсутствия, подойдет любой монитор или экран ноутбука. Но в таком случае результат окажется ниже реального. Фактически, вы не получите достоверное значение инпут лага, а сравните устройства по этому параметру.
Порядок измерений:
В случае сравнения с монитором на ЭЛТ, результатом тестирования станет точное значение инпут лага. Иначе: Инпут лаг = Разница в показаниях секундомера + Инпут лаг устройства с меньшим показанием секундомера.
Как снизить input lag
Если в системе замечена высокая задержка, и управление ощущается «желейным», не надо сразу начинать поиски нового телевизора или монитора. Первым делом стоит попытаться снизить инпут лаг «подручными» способами. Их можно разделить на две категории, применять которые необходимо комплексно.
В первом случае комплекс мер выглядит следующим образом:
В телевизоре основная задача — отключить все программные средства улучшения видеосигнала. Такие как искусственное повышение плавности в динамичных сценах, улучшение цвета и т. д. Набор параметров у каждого производителя свой. Стоит помнить, что из коробки такие «улучшалки» чаще всего включены. Универсальное средство — использование игрового режима, который есть в любой современной модели ТВ.
Используйте разрешение, соответствующее ЖК-панели. Растягивание Full-HD сигнала до 4К или сжатие 4К в Full-HD заметно повышают инпут лаг.
При подключении консоли через ресивер на последнем используйте вход HDMI, помеченный надписью Game.
Предпринятые меры если не устранят Input Lag полностью, то многократно снизят его до приемлемых значений, которые позволят играть в самые динамичные проекты.
Does the latency matter?
Есть исследование от Google, которое говорит, что если ваш сайт открывается больше трех секунд, то вы потеряете около 40% десктопных пользователей и более 50% — мобильных. Еще есть репорт от Amazon, который говорит, что для Amazon каждые 100 мс дополнительного latency стоит им 1% продаж. В объемах Amazon это миллионы долларов.
В зависимости от вашего бизнеса вам стоит тоже ответить на вопрос: Does the latency matter?
Я работаю как системный инженер уже более 8 лет. Хочу поделиться опытом, который получил в процессе решения задач в компании Big Data Technologies. У нас есть какой-никакой highload. В пике это 30 тысяч rps, и вопрос с latency довольно остро стоит перед бизнесом.
Когда разработчику ставят задачу улучшить latency, он идет на Google PageSpeed Insights, прогоняет свой домен и смотрит, сколько выдало попугаев и какие этот сервис дает советы. Например, минифицировать JS, CSS, использовать изображения правильного формата и более 20 других советов.
Но что делать, если все эти советы уже выполнены? На локалхосте уже все летает, а в проде для каких-то пользователей вы испытываете высокое latency? Или, например, вам вообще этот сервис не подходит, у вас API. Первое, что вам нужно сделать — это нажать F12 в вашем браузере, открыть девелопер-консоль, зайти в раздел Network Timings и там ваш браузер сам расскажет структуру latency от вашего приложения со стороны клиента.
Browser Network Timings
Тут вы увидите много пунктов, которые вашего приложение вроде как не касаются — DNS, latency на установку TCP-соединений, установка шифрования. На все это уходит сотни миллисекунд. И только последний блок (Sending, Waiting, Receiving) — ответ от вашего приложения.
Сейчас мы пройдемся по всем этим пунктам, я посоветую bestpractises и протоколы, которые помогут вам протюнить latency.
Делая статистику, я использовал следующую методологию:
Утилита DIG с ключом trace, которая позволяет получить некэшированные DNS-ответы;
Делал всегда 1000 запросов;
Считал 99 перцентиль.
Output утилита HTTPSTAT, которая показывает красивую визуализацию.
После всех настроек, которые я сегодня посоветую, вы сможете получить буст от 2 до 10 раз. В абсолютных значениях это около секунды для клиентов на оптике. Для клиентов на мобильных телефонах эти цифры могут быть значительно больше. Вот так получилось у нас:
Final Stats
Как решить, какой name-сервер быстрый, и вообще как понять, стоит ли использовать текущего провайдера, хороший ли он? Можно воспользоваться, например, публичными сервисами — такими, как dnsperf.com или solvedns.com. Там есть топ, который показывает latency.
DNS resolution
Но зачем нам его использовать, если мы можем легко сами измерить?
Я взял 7 различных DNS-провайдеров из трех основных облаков: GCP, AWS, Azure. Добавил CloudFlare как лидера и Afraid.org как аутсайдера рейтингов. А также добавил по одному российскому и белорусскому провайдеру DNS. После проверил домены, которые хостятся у этих DNS провайдеров.
DNS resolvers
У DNS есть две стороны — это resolver и name-сервер. Чтобы не проверять Google им же и иметь более честную статистику, я взял еще 4 популярных DNS-resolver и прогнал кросс-тестом 1000 запросов на все DNS name-серверы.
99% NS responce time (ms)
Публичные рейтинги нас не обманули — CloudFlare как был в топе, так и остался. При этом видно, что у Amazon на 40 мс latency лучше, чем у Google, а Reg.ru в два раза лучше, чем Hoster.by. Если вы захотите сэкономить и возьмете максимально дешёвый name-сервер, не зная рейтинга, то можете получить разницу 400 мс на каждый запрос.
Вы можете подумать, что 50-100 мс — это очень мало, можно не обращать на это внимания. Но если, например, ваш бизнес производит какие-то live-транзакции, как биржа или банк, то это существенно.
Также бизнес имеет свойство расширяться. Возможно, вы пойдете в другие географические регионы, например, в Азию или в Южную Америку. Вы внезапно можете увидеть рост latency, который будет очень сложно затраблшутить, просто потому что ваш текущий DNS-провайдер не представлен в этих регионах и DNS-запросы гоняются через океан.
Первый шаг мы рассмотрели — это DNS-resolution или DNS-Lookup. Возьмите топовый name-сервер и проверьте, какой вообще у вас.
Следующий шаг, который делает ваш браузер — это устанавливает TCP-соединение. На установку handshake всегда требуется 1 RTT (Round-trip time), и вроде бы с этим ничего не сделать.
Но есть здравый смысл, который подсказывает: чем ближе наши пользователи локально к нашим серверам, тем более короткая сеть маршрутов. Поэтому логично хостить ваше приложение близко к большинству ваших пользователей.
Но если они геораспределены, классически будет использовать CDN для статики, а менее классически — включить CDN для динамики. Это стоит сделать, потому что у вас все равно будет буст за счет того, что между CDN и вашим сервером уже будет всегда установлено TCP-сессия, а пользователи будут ходить до ближайшего CDN-сервера.
Но самый интересный вариант — это разнести вашу инфраструктуру по геопринципу. Предположим, вы подняли свою инфраструктуру в разных регионах, но как донести пользователям, чтобы они ходили до ближайших до них серверов?
GEO DNS
С этим нам поможет GEO DNS — extension в DNS, который позволяет DNS-резолверу пробрасывать к name-серверу маску подсети клиента. То есть DNS-провайдер может вычислять клиента по IP, определять его геолокацию и отдавать для разных клиентов разные значения A-записей.
Многие DNS-провайдеры не поддерживают GEO DNS, но в AWS Route 53 такой функционал есть. В данном случае сайт по дефолту хостится в Японии, но для пользователей из Европы будет отдаваться IP европейского сервера. Я провел кросс-тест latency сервера AWS в Европе и Японии как клиент, до сервера Google Cloud в Европе и Японии.
TCP connection time depending on Geolocation
Тест показал, что даже на таком небольшом расстоянии, как Европа-Азия получаем за счет GEO DNS буст по latency 250-300 мс, и это на каждый round-trip. Это уже намного больше, чем 50 мс от выбора DNS-resolver.
TCP Fast Open (TFO)
В рамках TCP есть малоизвестный протокол TCP Fast Open (TFO), который позволяет сократить один round-trip на установку handshake для второго и последующих соединений до 0. TCP-соединение будет устанавливаться сразу же при ответе сервера.
Checking on client:
Сhecking on server:
Здесь видно, как это работает. Первый запрос занимает 260 мс, а второй уже с ключом TCP Fast Open — 4 мс.
Сам TCP Fast Open настраивается довольно легко:
Этот протокол работает с помощью так называемой TFO-куки, когда при первом соединении генерируется файл куки, который в последующем переиспользуется. Когда сервер видит валидный куки от клиента на стадии SYN, то на стадии SYN acknowledge сразу устанавливается соединение и можно не ждать полный handshake.
Но у него есть ряд проблем. Основные — это middleboxes и трекинг.
Middleboxes — это старое или дорогое ПО или железо, которое не знает про протокол TFO. TCP так устроен, что если железо видит непонятные настройки, оно просто отбрасывает эти пакеты, и сессию придется устанавливать заново.
Получается, мы, наоборот, проиграем во времени на установку TCP-соединения. Так как таких middleboxes в интернете довольно много. Согласно исследованию — порядка 14% трафика проходит через них, то есть нам потребуется повторное TCP соединение.
Но еще больше проблем вызовет трекинг. В браузерах есть приватные вкладки. Если мы будем использовать TCP Fast Open, они будут полностью скомпрометированы, потому что сервер сможет по TFO-куке определить пользователя вне зависимости от того, в приватной он вкладке или нет. Для браузеров это неприемлемо. Тем не менее, в браузерах есть суппорт TFO. По умолчанию он выключен, его нужно включать в настройках.
Кейс, где можно использовать TFO свободно — это общение сервер-сервер. Когда вы предоставляете какое-то API, ваши клиенты — это тоже сервера, и расположены вы географически далеко, то можно просто включить TFO и выигрывать 1 round-trip. Например, от Европы до Японии — это 300 мс.
Второй шаг TCP мы рассмотрели — это initial connection, или connecting: используем CDN, пробуем GEO DNS и, если вам подходит, можете попробовать TFO.
TLS — очень старый протокол, он развивается. Но все его развитие до версии 1.2 было направлено только на улучшение безопасности: отказ от скомпрометированных алгоритмов шифрования, добавление более сложных и устойчивых алгоритмов.
На апрель 2020, по данным CCLabs, только 22% из ТОП 150 тысяч веб-сайтов использовали TLS 1.3. Через год эта цифра стала уже 44%. Этот было обусловлено, скорее всего, тем, что не так давно браузеры депрекейтили старые протоколы TLS 1.1, и администраторам было несложно вместе с депрекейтом старых протоколов добавить суппорт TLS 1.3.
До его выхода на latency это не влияло абсолютно — всегда было полноценных два round-trip time. Но с выходом TLS 1.3 протокол изменили, и из коробки он стал тратить один round-trip. Теперь для установки шифрованного соединения достаточно одного пути: клиент — сервер — клиент.
TLS 1.2 (2 RTT) vs TLS 1.3 (1RTT)
Но все же 44% — это даже не половина интернета, которая перешла на этот протокол.
Посмотрим, как это работает.
TLS Handshake
При TLS 1.3 клиент сразу же при запросе «Client Hello» генерирует так называемый PSK-ключ (Pre-Shared Key) и отправляет его на сервер, а сервер с помощью этого PSK шифрует свой ответ «Server Hello», добавляет туда необходимую информацию. Клиент уже следующим вторым запросом вместе с «Finished» может отправлять шифрованный HTTP запрос.
HTTPSTAT наглядно показывает, чем отличаются TLS 1.2 и TLS 1.3:
При TLS 1.2 мы получаем 600 мс latency, а при TLS 1.3 — 300 мс. Это полноценный round-trip time. Но только разовым запросам нельзя верить, поэтому мы соберем статистику.
TLS 1.2 vs TLS 1.3
Явно видно, что мы получаем один round-trip benefit просто за счет включения этого протокола. Но у TLS 1.3 есть еще такой функционал, как Zero Round Trip.
TLS 1.3 0-RTT
TLS 1.3 Zero Round Trip
Это включается довольно просто:
nginx > 1.15.4, OpenSSL 1.1.1 or higher or BoringSSL
Вам нужен не древний веб-сервер и ОС, где OpenSSL > 1.1.1, например Ubuntu 18, и три строчки в конфиге Nginx:
ssl_protocols TLSv1.3 — версия протокола;
Этот хэдер необходим для защиты от так называемых replay-атак, когда человек в середине может взять слепок шифрованного трафика и начать его повторять. Если ваше приложение уязвимо — например, вы банк и явно не хотите, чтобы запросы с транзакциями повторялись бесконечно, — то вам нужно на бэкенде обрабатывать этот кастомный хэдер. И это не очень большой limitation, чтобы получить отличный буст.
К сожалению, с помощью curl нельзя проверить TLS 1.3 с early_data, но мы можем проверить с помощью утилиты OpenSSL. При первом запросе мы генерируем файл session.pem, а при втором — используем с ключом early_data.
Checking
Если на сервере правильно все настроено, вы увидите «Early data was accepted». Early data, в отличие от TFO, включена во всех браузерах по умолчанию. Вы получите буст от ваших клиентов сразу же.
RSA key length
Также в рамках TLS хочется поднять тему длины RSA ключа.
По дефолту сертификаты, например от Let’s Encrypt, шифруются ключом длиной 2048 бит. Вы можете купить более секьюрный сертификат, шифрованный ключом в 3072 или 4096 бит. Но при этом всегда надо держать в уме, что время на терминацию трафика будет увеличиваться в 6-7 раз за каждое удвоение длины ключа.
RSA key length
У меня есть реальный кейс из практики — security team купила за недорого, как они считали, более секьюрный сертификат и выкатили его на прод. Пришел вечерний load и началась деградация прода — сервера задыхались под CPU. Это решилось только увеличением процессорных мощностей. А root cause про новые SSL сертификаты мы поняли только на следующий день.
TLS config best practice
Последнее, что я хотел бы затронуть в рамках TLS — это прекрасный сайт Mozilla SSL Configuration Generator, в котором можно просто накликать конфигурацию вашего веб-сервера.
TLS config best practice, https://ssl-config.mozilla.org
Например, можно взять Nginx, выбрать Modern, указать версию OpenSSL и вы получите сгенерированный конфиг — пользуйтесь!
Третий шаг — TLS setup, или же SSL мы рассмотрели: включаем TLS 1.3 и Early-Data.
Мы пришли к самом интересному — это наш HTTP-запрос от клиента в браузере.
По данным W3Techs на апрель этого года 49% от ТОП 10 млн веб-сайтов поддерживают HTTP/2, то есть 51% интернета не поддерживает HTTP/2. А мы в с вами 2021 году, и с 2018 года уже идет активная разработка протокола HTTP/3, на который уже очень скоро нужно будет переходить. Но сначала обсудим, зачем нам HTTP/2.
HTTP/2
По дефолту все веб-сервера настроены на HTTP/1, и многие не знают, что включение протокола HTTP/2 может улучшить response для ваших клиентов. Например, один из бенефитов, который нам дал HTTP/2 — это возможность параллельно отправлять ответы и запросы по одному TCP соединению.
Для протокола HTTP/1.1 у каждого браузера есть захардкоженная цифра от 6 до 9 TCP-соединений на один домен, и запросы/ответы идут последовательно в рамках этих TCP-соединений. В протоколе HTTP/2 вы можете для второго и последующих запросов отправлять ответы в рамках одного соединения.
Также есть технология HTTP/2 Server Push, которая позволит отправлять клиенту больше данных, чем он даже запрашивал. Например, вы точно знаете, что с запросом на индекс HTML нужно отправить JS и CSS, и вы можете преднастроить так, что к юзеру будут отправляться дополнительные данные. Это может дать хороший performance boost, но на самом деле Server Push почти не используется, потому что есть проблемы с браузерным кэшом. Вы не можете знать, что есть в кэше у вашего пользователя. Поэтому отправка CSS может стать, наоборот, лишней, если пользователь уже имеет этот CSS у себя в кэше.
Если взять большую картинку, разбитую на множество маленьких для увеличения скорости загрузки, то такой кейс отлично показывает лимит из-за последовательных запросов и ответов. Наглядно разницу между HTTP/1.1 и HTTP/2 можно увидеть по ссылке:
Но сегодня мы уже очень близки к HTTP/3.
HTTP/3
HTTP/3, он же QUIC (Quick UDP Internet Connections) — протокол, который изначально придумали в Google, чтобы решить проблему с растущим трафиком на YouTube. А теперь это уже почти законченный официальный протокол. Под капотом HTTP/3 все, что есть при классическом TCP-соединении, но только завернутое в UDP.
А когда мы слышим UDP, мы вспоминаем анекдот который, если до вас не дошел, то я его не повторю. Потому что проблема UDP — это потеря пакетов и Congestion Control (контроль потока).
В QUIC это решено за счет так называемой абстракции QUIC Streams, которая, кроме этого, решает проблему свитчинга сетей у ваших клиентов. Например, клиент пользуется Wi-Fi с телефона, потом переключится на 3G, на 4G и обратно на Wi-Fi. В рамках TCP, где определение клиента — это его IP-адрес и порт, при смене сети каждый раз нужно устанавливать соединение заново. А при QUIC Streams, которые присваиваются клиенту, можно продолжать переиспользовать соединение.
Давайте протестим как работает HTTP/3 и как его нам внедрить. Так как на текущий момент поддержка QUIC в nginx в разработке, то, чтобы ее включить в nginx, нам нужно его скомпилить.
К счастью, есть мануал, по которому довольно легко это сделать. А можно переиспользовать мой docker image: ymuski/nginx-quic и просто добавить в nginx две строки в конфиг:
Nginx config:
listen 443 quic reuseport;
add_header alt-svc ‘h3-29=»:443″; ma=86400’;
В хэдере указывается версия протокола (h3-29 — это версия драфта) и порт, на котором у нас HTTP/3. Когда вы это включите, скорее всего, ничего не заработает (или хочется верить, что не заработает), потому что вы точно забудете открыть на firewall 443/UDP (кто вообще открывает UDP?). Открываем порт и идем тестировать.
Для теста можно зайти на сайт HTTP/3 Check и посмотреть, включен ли у вас HTTP/3 и на какой версии. Но онлайн тесты — это не наш путь. Давайте сами проверим с помощью curl — что нам мешает?
Для этого и curl тоже скомпилить. Открываем другой мануал или используем docker image, который я скомпилил — docker image: ymuski/curl-http3
Видим, что на мой запрос в nginx log HTTP/3 — 200.
Более наглядно output от curl:
Тут нет привычной установки TLS-соединения. Есть блок h3, который создает QUIC Streams.
В браузерах на сегодняшний день уже впилена поддержка HTTP/3, ее нужно включить в настройках. Но хороший вопрос — вообще зачем нужен HTTP/3, дает ли он вообще какой-то буст по latency?
Я провел тест на один и тот же домен на HTTP/2 и HTTP/3.
HTTP/2 vs HTTP/3
Буст показал из разных точек мира, что HTTP/3 отвечает в 1.14x-1.5x быстрее, чем HTTP/2 — это от 14 до 50% преимущество. Вроде бы неплохо. Но первый запрос по дефолту прилетит вам на HTTP/1.1. Там он увидит редирект на HTTPS (если вы его сконфигурировали), хэдер Alt-Svc, и только потом уже перейдет на HTTP/3 или HTTP/2.
Как этого избежать? У нас есть новые DNS-записи.
Сейчас идет утверждение в Internet Engineering Task Force новых DNS-записей HTTPS. Поэтому мы можем создать дополнительную DNS-запись, и браузер ее будет запрашивать вместе с A-записью. И наш самый первый запрос прилетит уже по HTTP/3.
Например, в CloudFlare уже можно добавлять записи и наслаждаться. Это довольно крутой буст, который нас ждет. Mozilla и Safari уже поддерживают DNS-запись HTTPS, в Chrome это еще пока в разработке.
HTTP Compression
Кажется, тут все понятно — чем меньше наши данные, тем быстрее они будут у клиента. Но это не совсем так, нам нужно добавить время на сжатие этого контента.
Я сравнил два протокола: старый добрый Gzip и модный Brotli:
Json 137kb file check
В принципе, получились схожие цифры. На разных уровнях сжатия они ведут себя по-разному — что-то лучше сжимает, что-то быстрее отдает. На моем тестовом файле лучший response time я получил на среднем уровне сжатия.
Вам нужно понять, какой у вас трафик и эмпирически поиграться с компрессией, но включать ее определенно нужно.
HTTP Cache
Его очень легко включить, он гибок. Если вы будете использовать так называемый strong caching headers, то latency будет 0 мс, потому что все будет закэшено в браузере клиента.
Это был последний шаг. Подключайте HTTP/2, включайте компрессию и кэш. Попробуйте потестить HTTP/3 — он может вам дать значительный буст, плюс первого редиректа вы тогда тоже лишитесь.
Итого
Useful links
Мой сайт на HTTP/3 и github repo, где я считал статистику. Там есть все скрипты, как я это делал, настройки Nginx для каждого случая и дополнительные данные, например, не по 99, а по 50 перцентилю. Видео моего выступления на HighLoad++ Весна 2021.
Тех, кто соскучился по профессиональному нетворкингу и хочет быть в курсе всех передовых решений ждёт ещё два HighLoad++ в этом году: 20-21 сентября в Санкт-Петербурге и 25-26 ноября — в Москве. Питерское расписание уже готово.
И еще доступен — бандл из двух конференций: Saint HighLoad и HighLoad++ 2021 c 20% cкидкой. Предложение действительно до 19 сентября 2021 года.
