Google AMP Cache и HTTP/2 - доставка контента через HTTP/2 на мобильные устройства?
Google AMP Cache обслуживает файлы размером до 12 МБ по умолчанию через HTTP / 2. Хотя AMP не связан с использованием на мобильных устройствах, они являются основной мотивацией AMP.
Я только что прочитал статью о производительности HTTP / 2 в сотовых сетях. Хотя они обнаружили, что HTTP / 2 быстрее, чем HTTP / 1.1 для небольших файлов (2 МБ), они также увидели, что потеря пакетов для файлов размером 8 МБ или больше оказывает большее влияние на HTTP / 2, чем HTTP / 1.1, что приводит к более высокое время загрузки страницы (т. е. HTTP / 1.1 в этом случае быстрее, чем HTTP / 2). В своих исследованиях 32% всех мобильных соединений испытали потерю пакетов.
Поэтому мне было интересно, действительно ли HTTP / 2 - это путь для (Google) AMP Cache.
3 ответа
Было доказано, что согласованность HTTP/2 быстрее для большинства сайтов. Есть ли определенные сценарии, где это хуже - абсолютно! - но стоит ли вам воздерживаться от улучшения большинства сайтов для меньшинства? Нет на мой взгляд.
Однако даже с этим, я думаю, есть и другие факторы, которые вы также должны принять во внимание:
Страницы AMP предназначены для большей производительности, и я бы сказал, что специально для них 8 МБ страниц должны быть исключением, а не нормой. Поэтому, хотя в определенных сценариях может быть более эффективно использовать HTTP/1.1 для больших страниц, для большинства небольших страниц более эффективно использовать HTTP/2.
Стоит ли вам использовать HTTP/1.1 для больших страниц? Возможно, но это сложнее, так как протокол сначала согласовывается, прежде чем вы узнаете, что страница и ее снижение потребуют перенаправления или чего-то подобного и определенно замедляют работу страницы.
Должны ли AMP и кэши AMP ограничиваться 8 МБ, а не 12 МБ, учитывая, что они используют HTTP/2, и в этом документе предлагается, что может быть лучшим ограничением? Возможно, но опять же, это не значит, что они не будут работать с HTTP/2, они отступят изящно, но могут загружаться не так быстро, как если бы они были на HTTP/1.1.
Кроме того, большинство самих страниц AMP должны быть небольшими и постепенно загружать ненужные ресурсы (например, изображения или видео). Таким образом, большой файл (который, вероятно, будет изображением или видео) может не блокировать критический рендеринг страницы AMP в любом случае, даже если есть потеря пакета.
Все ли мобильные страницы загружены через мобильные сети? Любые люди используют мобильные телефоны через сети Wi-Fi, где потеря пакета должна быть меньше (я знаю, что я делаю!). В документе неясно, является ли цифра 32% сотовой связью (т.е. не через WiFi) или всеми мобильными соединениями (то есть сотовой и WiFi)
Google также экспериментирует с QUIC, лежащим в основе HTTP/2, а не TCP - что устраняет основную причину медлительности одного соединения HTTP/2 (то есть, что потеря одного пакета TCP будет удерживать все потоки HTTP/2, а не только потоку этот пакет тоже принадлежит). Конечно, сейчас это работает только в Chrome, поэтому другие браузеры пока не получат от этого пользы, но опять же Chrome имеет значительную базу пользователей.
Исходя из всего вышесказанного, я думаю, что HTTP/2 - определенно правильный путь, особенно для страниц AMP. Как я сказал в начале, он не идеален, и есть некоторые страницы, которые могут работать медленнее в определенных условиях, но подавляющее большинство страниц должно работать быстрее, и поэтому его следует использовать.
Основное назначение HTTP/2 - производительность, во-первых, почему не HTTP / 1.1
HTTP / 1.1 ввел официальный стандарт IETF; К сожалению, простота реализации также сказывается на производительности приложений:
- Клиенты HTTP/1.x должны использовать несколько соединений для достижения параллелизма и уменьшения задержки;
- HTTP/1.x не сжимает заголовки запроса и ответа, вызывая ненужный сетевой трафик;
- HTTP/1.x не позволяет эффективно расставлять приоритеты ресурсов, что приводит к плохому использованию основного TCP-соединения; и так далее.
Эти ограничения не были фатальными, но поскольку веб-приложения продолжали расти в своих масштабах, сложности и важности в нашей повседневной жизни, они налагали все большую нагрузку как на разработчиков, так и на пользователей Интернета, что является именно тем разрывом, который имеет HTTP/2 был разработан для решения:
Источник: https://developers.google.com/web/fundamentals/performance/http2/
А теперь приведу исследование о потере пакетов в HTTP/2, которое я прочитал, когда мы начали внедрять AMP:
Потеря пакетов, соединения с высоким RTT и производительность HTTP/2 Подождите, я слышал, вы сказали, что мы перечислили преимущества использования одного TCP-соединения на источник, но есть ли потенциальные недостатки? Да это так.
Мы устранили блокировку заголовка строки из HTTP, но все еще существует блокировка заголовка строки на уровне TCP (см. Блокировка заголовка строки).
Влияние продукта с задержкой полосы пропускания может ограничить пропускную способность соединения, если масштабирование окна TCP отключено.
Когда происходит потеря пакета, размер окна перегрузки TCP уменьшается (см. Предотвращение перегрузки), что уменьшает максимальную пропускную способность всего соединения.
Каждый из элементов в этом списке может отрицательно повлиять как на пропускную способность, так и на производительность задержки соединения HTTP/2. Однако, несмотря на эти ограничения, переход к нескольким соединениям приведет к компромиссу с собственной производительностью:
Менее эффективное сжатие заголовка из-за различных контекстов сжатия
Менее эффективная расстановка приоритетов запросов из-за отличных потоков TCP
Менее эффективное использование каждого потока TCP и более высокая вероятность перегрузки из-за более конкурирующих потоков
Увеличение затрат ресурсов из-за большего количества потоков TCP
Приведенные выше плюсы и минусы не являются исчерпывающим списком, и всегда можно построить конкретные сценарии, в которых одно или несколько соединений могут оказаться полезными. Однако экспериментальное доказательство развертывания HTTP/2 в дикой природе показало, что единственное соединение является предпочтительной стратегией развертывания:
До сих пор в тестах отрицательные эффекты блокировки заголовка (особенно при наличии потери пакетов) перевешивались преимуществами сжатия и расстановки приоритетов.
Протокол передачи гипертекста версия 2, черновик 2
Как и во всех процессах оптимизации производительности, как только вы устраняете одно узкое место производительности, вы открываете следующий. В случае HTTP/2 может быть TCP. Вот почему, опять же, хорошо настроенный стек TCP на сервере является таким критическим критерием оптимизации для HTTP/2.
В настоящее время ведутся исследования, направленные на решение этих проблем и улучшение производительности TCP в целом: быстрое открытие TCP, уменьшение пропорциональной скорости, увеличенное начальное окно перегрузки и многое другое. Сказав это, важно признать, что HTTP/2, как и его предшественники, не требует использования TCP. Другие виды транспорта, такие как UDP, не выходят за рамки возможного, когда мы смотрим в будущее.
Источник: https://hpbn.co/http2/
Основываясь на этой документации, Google AMP Cache выполняет оптимизацию и модификации и работает по безопасному каналу (HTTPS) и использует новейшие веб-протоколы (SPDY, HTTP / 2). Также из этого блога Google AMP Cache представляет собой сеть доставки контента на основе прокси-сервера для доставки всех действительных документов AMP. Он извлекает AMP HTML-страницы, кэширует их и автоматически повышает производительность страницы. При использовании Google AMP Cache документ, все файлы JS и все изображения загружаются из того же источника, который использует HTTP 2.0 для максимальной эффективности.