Прочитал пост Пауло Кальвано про эвристическое кеширование в браузерах — "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/