Лоит Бэллад из Cloudflare написал статью про то, как они тестируют разрабатываемые протоколы — "How to develop a practical transport protocol".

На данный момент Cloudflare участвует в разработке QUIC и HTTP/3. Отладка сетевого стека — нетривиальная задача, особенно, если речь идёт об отладке на реальных мобильных устройствах. В самом простом случае разрабатывать протокол можно на одном компьютере, используя сеть из docker-контейнеров. Но такой подход не может выявить проблемы, которые могут возникнуть в реальном мире. Поэтому для полноценного тестирования создаются специальные "лаборатории" — выделенные машины, соединённые между собой в сеть. Для эмуляции edge, 3g, lte используется netem (на Linux) и ipfw + dummynet (на FreeBSD). Меня немного позабавило, что ребята взламывают девайсы на iOS, для того, чтобы понять, как будут работать новые протоколы на реальном железе от Apple.

В общем, статья интересная. Рекомендую почитать, если хотите узнать, как разрабатываются протоколы.

#http #debug #net

https://calendar.perfplanet.com/2019/how-to-develop-a-practical-transport-protocol/

Эверт Пот провёл эксперимент по измерению скорости HTTP/1.1 и HTTP/2 в разных условиях — "Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs".

Основные выводы из статьи. Если очень критична скорость, то нужно продолжать компоновать множество запросов в один. Если вас интересует более элегантный дизайн API, то получение каждой сущности по уникальному URL вполне хорошее решение в условиях HTTP/2. Кэширование ответов в Firefox незначительно влияет на общий результат, в Chrome эксперимент с использованием кэша показал прирост скорости в 2.3 раза. Есть проблемы с HTTP/2 Push в Firefox — автор статьи пишет, что push в его экспериментах работал через раз.

В общем, эта статья — ещё один повод задуматься о переходе с HTTP/1.1 на HTTP/2, если вы этого ещё не сделали.

#http #benchmark #performance

https://evertpot.com/h2-parallelism/

Разработчики браузеров начинают задумываться о том, чтобы перевести HTTP-заголовок User-Agent в статус deprecated.

User-Agent не был надёжным средством для определения возможностей браузера, но тем не менее многие сайты его используют. Более того на некоторых логика работы с UA сломана, из-за чего возникают неприятные ошибки. Шима Видас решил проверить, как будут вести себя современные сайты, если на наделю отключить User-Agent. Что из этого получилось, он описал в статье "My findings after browsing the web without a User-Agent header for one week".

Большинство сайтов работало без каких-либо проблем, включая Amazon, Reddit, Instagram, Google Photos. Но в Google Docs выскакивало сообщение о том, что могут быть недоступны некоторые функции. iCloud рекомендовал использовать последние версии браузеров. Twitter переключал на старую версию сайта, а поиск Google отдавал HTML-only версию сайта. Были баги. В Google Docs перестали работать некоторые горячие клавиши, в Twitter сломалось копирование и вставка в текстовых полях. Twitch падал с ошибкой в JS из-за того, что не был учтён случай, когда navigator.userAgent пустая строка. Некоторые сайты начали воспринимать пользователя как бота и переставали открываться (Facebook, Arstechnica, Apple Developer).

Я лично поддерживаю начинание объявить устаревшим User-Agent. Но, думаю, что этот процесс может легко растянуться на несколько лет.

#http #web

https://webplatform.news/issues/2020-03-19

Недавно в Firefox была обнаружена проблема с кешированием данных в Twitter. Любой пользователь с физическим доступом к компьютеру теоретически мог прочитать чужие личные сообщения. Мартин Томсон из команды разработки Firefox рассказал, почему это произошло, в статье "Twitter Direct Message Caching and Firefox".

Чтобы предотвратить кеширование контента в браузерах, сайт должен отправить в ответе http-заголовок Cache-Control: no-store. В любом другом случае в Firefox начинает работать механизм эвристического кеширования. Этот механизм используется для предсказания, какой контент может быть закеширован и на какое время. Контент без Cache-Control: no-store сохраняется в кэше на семь дней. Как вы наверное уже догадались Twitter не отправлял этот заголовок в ответе из-за чего в Firefox включался механизм кеширования. Вместо него Twitter отправлял заголовок Content-Disposition, который используется для добавления метаинформации (например, имени файла) к загружаемым файлам. В статье говорится, что в "other browser" (как я понимаю Chrome) наличие этого заголовка отключает кеширование, но это поведение не является частью стандарта.

Какие можно сделать выводы из этой истории? Нужно проверять работу сайта в разных браузерах (Chrome, Firefox, Safari) и не стоит полагаться на поведение браузера, которое не соответствует стандартам.

#firefox #cache #http

https://hacks.mozilla.org/2020/04/twitter-direct-message-caching-and-firefox/

В блоге Cloudflare была опубликована статья со сравнением производительности HTTP/2 и HTTP/3 — "Comparing HTTP/3 vs. HTTP/2 Performance".

Cloudflare объявил об экспериментальной поддержке HTTP/3 в сентябре 2019 (подробнее про HTTP/3 можно почитать тут https://t.me/defront/268). За прошедшие полгода протокол был обновлён до 27-ой версии черновика протокола, а также были получены живые данные, которые помогли рабочей группе, занимающейся разработкой HTTP/3.

0-RTT — фича HTTP/3, которая позволяет сократить время при установке соединения. В сравнении с HTTP/2 метрика time to first byte (TTFB) для HTTP/3 при включённом RTT-0 улучшилась на 12%. С текущей реализацией алгоритма управления потоком (спецификация не накладывает на него ограничений) нельзя корректно сравнить время загрузки, но эксперименты показывают, что она как мининмум не хуже HTTP/2.

Экспериментальная поддержка HTTP/3 есть во всех основных браузерах: Chromium-based (Crhome, Edge, Opera), Firefox Nightly, Safari Technology Preview.

#http #performance

https://blog.cloudflare.com/http-3-vs-http-2/

Марк Ноттингэм — участвует в разработке http и других протоколов — написал статью про малоизвестный http-заголовок Prefer: Safe — "On RFC8674, the safe preference for HTTP".

Этот заголовок говорит о том, что в браузере включена опция "безопасного интернета" для упрощения механизма фильтрации контента со стороны владельцев сайтов, например, для родительского контроля. Тем не менее он поддерживается только в Firefox и Internet Explorer.

Заголовок Prefer: Safe не получил широкого распространения из-за того, что он может потенциально использоваться для идентификации пользователей. А также из-за того, что понятие "Safe" каждый воспринимает по-своему. В статье рассказывается про случай с youtube, который сделал похожую настройку в своём приложении. После её добавления пользователи стали массово жаловаться на то, что они не видят нужный контент. Как оказалось, понятие "Safe" очень субъективно. То что было "Non-Safe" для youtube, было вполне "Safe" для пользователей. Тем не менее Марк считает RFC8674 шагом в правильном направлении, так как он обеспечивает фильтрацию контента на стороне пользователя без участия третьих сторон.

Cтатья интересная. В ней также немного рассказывается про процесс принятия новых фич на уровне IETF.

#http #musings

https://www.mnot.net/blog/2019/12/05/safe_hint

Барри Поллард — специалист в области web-производительности и автор книги “HTTP/2 in Action” — рассказал, почему совет про упаковку html-кода в первых 14kb не стоит воспринимать как жёсткое правило.

Дело в том, что цифра 14kb основана не на реальных данных, а на теоретических вычислениях. В первой транзакции передачи tcp-пактов можно отправить 10 пакетов. Каждый пакет весит 1500 байт, в каждом пакете 40 байт занимает служебная информация. На основе этих данных и получается 14kb (10 * (1500 - 40)). Барри на примере показывает, что в реальных условиях это не всегда так. При использовании HTTPS и HTTP/2 служебные данные могут занимать до 5 пакетов, то есть половину всего теоретического лимита. Но это не означает, что нужно пренебрегать размером отправляемых ресурсов. Всё также достаточно важно размещать в первых ~14kb отправляемого html ссылки на критические ресурсы, чтобы браузер начал их загрузку во время парсинга html.

Очень прикольная статья. Рекомендую прочитать всем, кто занимается производительностью.

#performance #http

https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/

Прочитал пост Пауло Кальвано про эвристическое кеширование в браузерах — "HTTP Heuristic Caching (Missing Cache-Control and Expires Headers) Explained".

Для установки времени жизни контента в кэше браузера веб-серверы отправляют http-заголовки Cache-Control и Expires. Если установлены оба заголовка то приоритет получает Cache-Control. Есть ошибочное мнение, что если не отдавать эти заголовки, то браузеры не будут кэшировать контент, но на самом деле браузеры всё равно будут его сохранять. Время жизни обычно составляет 10% от промежутка времени между датой последнего изменения файла Last-Modified и текущей датой. Этот нюанс может принести много проблем, поэтому не рекомендуется удалять заголовки Cache-Conrol и Expires. Для отключения кэширования лучше всего использовать Cache-Control: no-store или Cache-Control: max-age=0.

Очень полезная статья. Рекомендую почитать.

#http #cache

https://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/

Энди Дэвис — автор книг про web-производительность — написал статью про проблемы хинта prefetch — "Rel=prefetch and the Importance of Effective HTTP/2 Prioritisation".

Prefetch используется для загрузки ресурсов с низким приоритетом, например, чтобы подгрузить шрифт, который с большой вероятностью будет использоваться на следующей странице. Проблема в том, что в некоторых случаях второстепенные ресурсы начинают конкурировать с основными ресурсами страницы, ухудшая метрики производительности.

Энди провёл несколько экспериментов. При использовании сервера с полноценной поддержкой приоритизации HTTP/2, второстепенные ресурсы были загружены без проблем, проблема была только с ресурсами, которые загружались с других доменов. Когда тестировался сервер без поддержки приоритизации HTTP/2 (Netlify, Amazon Cloudfront), в Chrome второстепенные ресурсы конкурировали с основными ресурсами страницы, а в Safari они конкурировали с запросами критических ресурсов страницы. У Firefox не было проблем с планированием загрузки ресурсов вне зависимости от типа сервера.

Если поменять сервер невозможно, то для решения этой проблемы нужно сделать так, чтобы браузер обнаружил prefetch-хинты как можно позднее. Например, их можно поместить в конце документа или вставить динамически после полной загрузки страницы.

#performance #http

https://andydavies.me/blog/2020/07/08/rel-equals-prefetch-and-the-importance-of-effective-http-slash-2-prioritisation/

Збигнев Банах написал статью про HSTS — "Why Websites Need HTTP Strict Transport Security (HSTS)".

Как правило, пользователи при переходе на сайт вводят его имя в адресную строку без протокола. Браузеры по умолчанию переходят на сайт по незащищённому протоколу HTTP. Для того чтобы браузер всегда использовал HTTPS-протокол, сервер на первый запрос должен отправить ответ с редиректом на HTTPS-версию сайта и с помощью заголовка Strict-Transport-Security передать дополнительную информацию о том, что сайт должен работать только HTTPS и закэшировать этот ответ. Время жизни кэша обычно устанавливают на год или два. В следующий раз при посещении сайта пользователь сразу попадёт на HTTPS-версию без редиректа.

Но есть небольшая проблема. Теоретически злоумышленник может перехватить первый запрос и заблокировать работу HSTS. Чтобы этого избежать, браузеры проверяют список сайтов, которые должны работать только по HTTPS (HSTS preload list). В этот список можно добавить свой сайт, но для этого нужно выполнить все условия, например, чтобы все поддомены работали по HTTPS.

Хорошая статья. Рекомендую почитать, если хотите узнать больше про HSTS.

#http #security

https://www.netsparker.com/blog/web-security/http-strict-transport-security-hsts/

Разработчики Chromium сообщили о своих планах полностью удалить поддержку Server Push и gQUIC — "Intent to Remove: HTTP/2 and gQUIC server push".

Server Push — фича HTTP/2, благодаря которой сервер может отправлять браузеру ресурсы, не дожидаясь от него явных запросов; gQUIC — нестандартный протокол, разработанный Google, который также позволяет пушить ресурсы. Пуши сложно настроить так, чтобы использующий их сайт всегда работал быстро, в самых плохих случаях они могут быть причиной деградации производительности.

Разработчики Chromium хотят удалить поддержку Server Push и gQUIC. Они ссылаются на проблемы производительности и на то, что оставлять их поддержку нет смысла, так как доля HTTP/2 соединений, использующих пуши, составляет 0.05%. Также реализация пушей в коде довольно сложная и её дорого поддерживать.

С другой стороны баррикад находятся разработчики, которые в комментариях пишут о том, что это проблема курицы и яйца, то есть просто ещё нет удобных средств для работы с пушами, чтобы они стали популярны. Также есть разработчики, которые успешно используют Server Push и не хотят, чтобы он был удалён из Chromium.

#performance #chromium #http

https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY

Марк Ноттингэм написал статью о текущем состоянии Early Hints — "Beyond Server Push: experimenting with the 103 Early Hints Status Code".

Обычно известно, какие ресурсы будут нужны на странице. Было бы полезно каким-то образом сообщить о них браузеру заранее, чтобы он мог начать загружать код, стили, шрифты, пока бэкенд выполняет свою работу. Для решения этой задачи предназначен Early Hints — стандарт, разработанный в 2018 году инженерами Fastly (RFC8297). По своей сути Early Hints это HTTP-ответ с кодом 103 и списком ресурсов, который браузер может начать загружать перед ответом бэкенда. В HTTP/2 есть похожий механизм Server Push, но по сравнению с Early Hints он гораздо сложнее в настройке и использовании.

Пока браузеры не поддерживают эту спеку, так как она сложна в реализации. Для оценки пользы её внедрения в Google Chrome начался сбор метрик с сайтов, отправляющих экспериментальный код 103 Early Hints. Марк призывает всех желающих поучаствовать в этом эксперименте.

#http #performance

https://www.fastly.com/blog/beyond-server-push-experimenting-with-the-103-early-hints-status-code

Рйо Ота рассказал, как можно сделать SSH-клиент, VNC-клиент и мессенджер без использования веб сокетов и WebRTC — "The Power of Pure HTTP – screen share, real-time messaging, SSH and VNC".

Обычно HTTP используется для передачи относительно небольших объёмов данных. Разработчики браузеров сейчас работают над возможностью отправки по сети ReadableStream с помощью fetch, то есть создания канала для передачи бесконечного потока данных. В статье разбираются примеры, как использовать эту фичу вместе с piping server, который позволяет организовать взаимодействие между двумя браузерами с помощью обычных GET- и POST-запросов. С помощью такого подхода можно сделать приложение просмотра удалённого рабочего стола, SSH-клиенты и другие подобные приложения, которые работают внутри браузера и используют обычный HTTP-канал в качестве транспорта.

На данный момент возможность передачи ReadableStream с помощью fetch есть только в Chrome в экспериментальном режиме.

#experimental #http #api

https://dev.to/nwtgck/the-power-of-pure-http-screen-share-real-time-messaging-ssh-and-vnc-5ghc

Мод Нальпас написала статью о том, в каких случаях следует использовать HTTPS для локальной разработки — "When to use HTTPS for local development".

Для разработки лучше всего использовать http://localhost, так как браузеры в этом случае разрешают использовать многие API, которые доступны только с HTTPS (сервис воркеры, Payments API, Credentials API и т.п.) Но если нужно протестировать Secure Cookies, HTTP/2, исправить проблему с mixed content или если в hosts-файле стоит резолвинг 127.0.0.1 в уникальное имя, то нужно использовать HTTPS.

Если используется уникальное имя, то оно не должно совпадать с доменом верхнего уровня, иначе могут быть проблемы с резолвингом. В качестве альтернативы Мод предлагает использовать специальные домены верхнего уровня .test и .localhost. Все имена с доменом верхнего уровня .localhost будут работать так же, как и http://localhost, но только в Chrome и Edge.

#http

https://web.dev/when-to-use-local-https/

Мод Нальпас во второй статье рассказала о том, как настроить HTTPS для локальной разработки — "How to use HTTPS for local development".

Для настройки локального HTTPS удобнее всего использовать утилиту mkcert. Mkcert — это zero-config утилита для настройки локального HTTPS. С помощью команды mkcert -install создаётся локальный certificate authority (CA), с помощью команды mkcert <domain_name> создаётся сертификат, который нужно использовать при настройке локального HTTP-сервера.

Ещё можно использовать самоподписанный сертификат или сертификат подписанный внешним CA. Но эти варианты не очень гибки и удобны по сравнению с mkcert.

#http #tool

https://web.dev/how-to-use-local-https/

Дэниэл Штенберг — автор curl — написал статью про текущую поддержку HTTP/3 — "Where is HTTP/3 right now?".

Черновик спецификации HTTP/3 вышел на финальный этап и совсем скоро станет официальным документом. HTTP/3 уже включён в Chromium. В Firefox он будет включён в ближайших версиях. По данным w3techs поддержка HTTP/3 на самых популярных сайтах составляет 14%, по данным Cloudflare — 9%.

Также Дэниэл пишет о том, что HTTP/3 быстрее HTTP/2, но пользователи, подключённые к широкополосному каналу с низкими задержками, навряд ли заметят какие-либо изменения.

#http

https://daniel.haxx.se/blog/2021/04/02/where-is-http-3-right-now/

Новые возможности управления кешом в HTTP

Тим Пэрри написал статью про новые HTTP-заголовки для управления кешом и упрощения отладки проблем кеширования — "New HTTP standards for caching on the modern web".

Современные веб-приложения используют разные уровни кеширования, начиная кешом браузера и заканчивая кешами балансера и CDN. Для упрощения отладки проблем кеширования был добавлен HTTP-заголовок Cache-Status, с помощью которого можно отследить прохождение запроса через все уровни кеширования.

Для более тонкого управления кешом в стандарт был добавлен Targeted Cache-Control. По сути это обычный Cache-Control, который можно использовать для точечного управления кешами. Akamai и Cloudflare уже поддерживают CDN-Cache-Control, Akamai-Cache-Control и Cloudflare-CDN-Cache-Control. В будущем возможно появление Client-Cache-Control и других подобных заголовков.

Тим пишет, что Cache-Status и Targeted Cache-Control находятся на стадии черновика, но спецификации уже не будут меняться кардинально.

#http #cache #spec

https://httptoolkit.tech/blog/status-targeted-caching-headers/

Ускорение установки HTTPS-соединений

Саймон Харн рассказал о том, как HTTPS-сертификаты влияют на производительность сайта — "The Performance Cost of EV Certificates".

Есть три основных типа HTPS-сертификатов: Domain Validation (DV), Organisation Validation (OV), Extended Validation (EV). DV-сертификаты выдаются на основе факта принадлежности домена, как в Let's Encrypt. OV- и EV-сертификаты выдаются организациям за оплату.

EV-сертификат предоставляет большее количество информации для пользователя, но по-большому счёту он не сильно отличается от OV. Вы могли видеть, что сайт использует EV-сертификат, когда в адресной строке рядом с иконкой замка зелёным текстом отображался владелец сертификата. С версии Chrome 77 такие сертификаты отображаются обычным значком замка без зелёного текста.

OV-сертификаты валидируются на стороне веб-сервера отправкой запроса на сервер организации, выдавшей сертификат. EV-сертификаты не могут валидироваться на стороне веб-сервера, поэтому их валидация происходит на клиенте, замедляя установку HTTPS-соединения. Задержка наиболее заметна в странах бывшего СССР, в Восточной Австралии, Канаде и большинстве стран Африки. Некоторые организации сталкивались с минутной задержкой для пользователей в Китае. Эта проблема решается переходом на OV-сертификат.

#http #performance #security

https://simonhearne.com/2020/drop-ev-certs/

Анализ производительности HTTP/3

В блоге requestmetrics была опубликована статья, посвящённая анализу производительности HTTP/3 — "HTTP/3 is Fast".

HTTP/3 — это новая версия протокола HTTP, работающая поверх транспортного протокола QUIC. Более подробно про HTTP/3 можно почитать в публикации HTTP/3: the past, the present, and the future.

В этой же статье проверялась скорость загрузки трёх видов сайтов: простой сайт, тяжёлый сайт, SPA. Ресурсы загружались с трёх разных серверов в Нью-Йорке, Лондоне и Бангалоре. Чем больше было расстояние, тем лучше всего показывал себя HTTP/3. Если для передачи данных между Миннесотой и Нью-Йорком выигрыш скорости составил более 200 мс, то для соединения между Миннесотой и Бангалором выигрыш был уже 3-4 секунды. Такой значительный разрыв в скорости загрузки объясняется тем, что в HTTP/3 решена проблема с “head-of-line blocking” — блокировкой передачи данных во время потери пакетов.

#http #performance #benchmark

https://requestmetrics.com/web-performance/http3-is-fast

Опыт ускорения VK

На хабре был опубликован транскрипт доклада Александра Тоболя про опыт ускорения VK — "Как мы отказались от JPEG, JSON, TCP и ускорили ВКонтакте в два раза".

Оптимизированы были все уровни от выбора нового формата изображений до выбора алгоритма управления передачей пакетов на сервере. Для изображений вместо JPEG стали использовать WebP, для передачи данных вместо JSON — MessagePack, сжатый с помощью zstd. Очень большая часть посвящена QUIC и его особенностям реализации. Самый интересный момент — с помощью QUIC улучшается утилизация пропускной способности клиента. Как побочный эффект это может привести к тому, что некий сервис может занять всю пропускную полосу клиента, затормаживая работу других сервисов.

После внедрения всех изменений на 55% ускорилась доставка изображений, количество просмотров увеличилось на 2,7% (на 10,8% для пользователей с медленной сетью), количество просмотров контента увеличилось на 250 миллионов.

#performance #http

https://habr.com/ru/company/vk/blog/594633/