Протокол передачи гипертекста (HTTP) — это простой, ограниченный и невероятно скучный протокол, лежащий в основе Всемирной паутины. По сути, HTTP позволяет считывать данные из подключённых к сети ресурсов, и в течение десятилетий он выступает в роли быстрого, безопасного и качественного “посредника”.
В этой обзорной статье мы расскажем об использовании и преимуществах HTTP/2 для конечных пользователей, разработчиков и организаций, стремящихся использовать современные технологии. Здесь вы найдёте всю необходимую информацию о HTTP/2, от основ до более сложных вопросов.
Содержание:
- Что такое HTTP/2?
- Для чего создавался HTTP/2?
- Чем был плох HTTP 1.1?
- Особенности HTTP/2
- Как HTTP/2 работает с HTTPS?
- Различия между HTTP 1.x, SPDY и HTTP/2
- Основные преимущества HTTP/2
- Сравнение производительности HTTPS, SPDY и HTTP/2
- Браузерная поддержка HTTP/2 и доступность
- Как начать использовать HTTP/2?
Что такое HTTP/2?
HTTP был разработан создателем Всемирной паутины Тимом Бернерсом-Ли. Он сделал протокол простым, чтобы обеспечить функции высокоуровневой передачи данных между веб-серверами и клиентами.
Первая задокументированная версия HTTP — HTTP 0.9 — вышла в 1991. В 1996 появился HTTP 1.0. Годом позже вышел HTTP 1.1 с небольшими улучшениями.
В феврале 2015 Рабочая группа HTTP Инженерного совета Интернета (IETF) пересмотрела протокол HTTP и разработала вторую основную версию в виде HTTP/2. В мае того же года спецификация реализации была официально стандартизирована в качестве ответа на HTTP-совместимый протокол SPDY, созданный в Google. Дискуссия на тему «HTTP/2 против SPDY» будет вестись на протяжении всей статьи.
Что такое протокол?
Чтобы говорить «HTTP/2 против HTTP/1», давайте сначала вспомним, что означает сам термин «протокол», часто упоминаемый в этой статье. Протокол — это набор правил, регулирующих механизмы передачи данных между клиентами (например, веб-браузерами, запрашивающими данные) и серверами (компьютерами, содержащими эти данные).
Протоколы обычно состоят из трёх основных частей: заголовка (header), полезных данных (payload) и футера (footer). Заголовок идёт первым и содержит адреса источника и получателя, а также другую информацию, например размер и тип. Полезные данные — это информация, которая передаётся посредством протокола. Футер передаётся в последнюю очередь и выполняет роль управляющего поля для маршрутизации клиент-серверных запросов к адресатам. Заголовок и футер позволяют избегать ошибок при передаче полезных данных.
Если провести аналогию с обычным бумажным письмом: текст (полезные данные) помещён в конверт (заголовок) с адресом получателя. Перед отправкой конверт запечатывается, и на него наклеивается почтовая марка (футер). Конечно, это упрощённое представление. Передача цифровых данных в виде нулей и единиц не так проста, она требует применения нового измерения, чтобы справиться с растущими технологическими вызовами, связанными со взрывным использование интернета.
Протокол HTTP изначально состоял из двух основных команд:
GET — получение информации с сервера,
POST — принимает данные для хранения.
Этот простой и скучный набор команд — получение данных и передача запроса — лёг в основу и ряда других сетевых протоколов. Сам по себе протокол является ещё одним шагом к улучшению UX, а для его дальнейшего развития необходимо внедрить HTTP/2.
Для чего создавался HTTP/2?
С момента своего возникновения в начале 1990-х, HTTP лишь несколько раз подвергался серьёзному пересмотру. Последняя версия — HTTP 1.1 — используется уже более 15 лет. В эру динамического обновления контента, ресурсоёмких мультимедийных форматов и чрезмерного стремления к увеличению производительности веба, технологии старых протоколов перешли в разряд морально устаревших. Все эти тенденции требуют значительных изменений, которые обеспечивает HTTP/2.
Главная цель разработки новой версии HTTP заключалась в обеспечении трёх свойств, которые редко ассоциируются с одним лишь сетевым протоколом, без необходимости использования дополнительных сетевых технологий, — простота, высокая производительность и устойчивость. Эти свойства обеспечены благодаря уменьшению задержек при обработке браузерных запросов с помощью таких мер, как мультиплексирование, сжатие, приоритезация запросов и отправка данных по инициативе сервера (Server Push).
В качестве усовершенствований HTTP используются такие механизмы, как контроль потоков (flow control), апгрейд (upgrade) и обработка ошибок. Они позволяют разработчикам обеспечивать высокую производительность и устойчивость веб-приложений. Коллективная система (collective system) позволяет серверам эффективно передавать клиентам больше контента, чем они запросили, что предотвращает постоянные запросы информации, пока сайт не будет целиком загружен в окне браузера. Например, возможность отправки данных по инициативе сервера (Server Push), предоставляемая HTTP/2, позволяет серверу отдавать сразу весь контент страницы, за исключением того, что уже имеется в кэше браузера. Накладные расходы протокола минимизируются за счёт эффективного сжатия HTTP-заголовков, что повышает производительность при обработке каждого браузерного запроса и серверного отклика.
HTTP/2 разрабатывался с учётом взаимозаменяемости и совместимости с HTTP 1.1. Ожидается, что внедрение HTTP/2 даст толчок к дальнейшему развитию протокола.
Марк Ноттингем, Глава Рабочей группы HTTP IETF и член W3C TAG:
«… мы не меняем весь HTTP — методы, коды статусов и большинство заголовков остаются теми же. Мы лишь переработали его с точки зрения повышения эффективности использования, чтобы он был более щадящим по отношению к интернету…»
Важно отметить, что новая версия HTTP идёт в качестве расширения для своего предшественника, и вряд ли в обозримом будущем заменит HTTP 1.1. Реализация HTTP/2 не подразумевает автоматической поддержки всех типов шифрования, доступных в HTTP 1.1, но определённо поощряет использование более интересных альтернатив, или дополнительное обновление совместимости шифрования в ближайшем будущем. Тем не менее, в сравнениях «HTTP/2 против HTTP 1» и «SPDY против HTTP/2» герой этой статьи выходит победителем по производительности, безопасности и надёжности.
Чем был плох HTTP 1.1?
HTTP 1.1 позволяет обрабатывать лишь один поступивший запрос на одно TCP-соединение, поэтому браузеру приходится устанавливать несколько соединений, чтобы обрабатывать одновременно несколько запросов.
Но параллельное использование многочисленных соединений приводит к перегрузке TCP, следовательно, к несправедливой монополизации сетевых ресурсов. Браузеры, использующие многочисленные соединения для обработки дополнительных запросов, занимают львиную долю доступных сетевых ресурсов, что приводит к снижению сетевой производительности для других пользователей.
Отправка браузерами многочисленных запросов приводит к дублированию данных в сетях передачи, что, в свою очередь, требует использования дополнительных протоколов, позволяющих безошибочно извлекать на конечных узлах нужную информацию.
Сетевой индустрии фактически пришлось хакнуть эти ограничения с помощью таких методик, как доменный шардинг (domain sharding), конкатенация, встраивание и спрайтинг (spriting) данных, а также ряд других. Неэффективное использование HTTP 1.1 базовых TCP-соединений является причиной плохой приоритезации ресурсов, и в результате — экспоненциальной деградации производительности по мере роста сложности, функциональности и объёма веб-приложений.
Развивающейся сети уже не хватает возможностей HTTP-технологий. Разработанные много лет назад ключевые свойства HTTP 1.1 позволяют использовать несколько неприятных лазеек, ухудшающих безопасность и производительность веб-сайтов и приложений.
Например, с помощью Cookie Hack злоумышленники могут повторно использовать предыдущую рабочую сессию для получения несанкционированного доступа к паролю пользователя. А причина в том, что HTTP 1.1 не предоставляет инструментов конечного подтверждения подлинности. Понимая, что в HTTP/2 будут искать аналогичные лазейки, его разработчики постарались повысить безопасность протокола с помощью улучшенной реализации новых возможностей TLS.
Особенности HTTP/2
Мультиплексированные потоки
Пересылаемая через HTTP/2 в обе стороны последовательность текстовых фреймов, которыми обмениваются между собой клиент и сервер, называется “потоком”. В ранних версиях HTTP можно было транслировать только по одному потоку за раз, с небольшой задержкой между разными потоками. Передавать таким способом большие объёмы медиа-контента было слишком неэффективно и ресурсозатратно. Для решение этой проблемы в HTTP/2 применяется новый бинарный слой фреймов.
Этот слой позволяет превратить данные, передаваемые от сервера к клиенту, в управляемую последовательность маленьких независимых фреймов. И при получении всего набора фреймов клиент может восстановить передаваемые данные в исходном виде. Эта схема работает и при передаче в обратном направлении — от клиента к серверу.
Бинарные фреймовые форматы позволяют одновременно обмениваться многочисленными, независимыми последовательностями, передаваемыми в обе стороны, без какой-либо задержки между потоками. Этот подход даёт массу преимуществ:
- Параллельные мультиплексированные запросы и ответы не блокируют друг друга.
- Несмотря на передачу многочисленных потоков данных, для наибольшей эффективности использования сетевых ресурсов используется одиночное TCP-соединение.
- Больше не нужно применять оптимизационные хаки, наподобие спрайтов, конкатенации, фрагментирования доменов и прочих, которые негативно сказываются на других сферах сетевой производительности.
- Задержки ниже, производительность сети выше, лучше ранжирование поисковыми системами.
- В сети и IT-ресурсах уменьшаются операционные расходы и капитальные вложения.
Благодаря описанной возможности, пакеты данных из разных потоков вперемешку передаются через единственное TCP-соединение. В конечной точке эти пакеты затем разделяются и представляются в виде отдельных потоков данных. В HTTP 1.1 и более ранних версиях для параллельной передачи многочисленных запросов пришлось бы устанавливать такое же количество TCP-соединений, что является узким местом с точки зрения общей производительности сети, несмотря на быструю передачу большего количества потоков данных.
Отправка данных по инициативе сервера (Server Push)
Эта возможность позволяет серверу отправлять клиенту дополнительную кэшируемую информацию, которую тот не запрашивал, но которая может понадобиться при будущих запросах. Например, если клиент запрашивает ресурс Х, который ссылается на ресурс Y, то сервер может передать Y вместе с Х, не дожидаясь от клиента дополнительного запроса.
Полученный от сервера ресурс Y кэшируется на клиенте для будущего использования. Этот механизм позволяет экономить циклы «запрос-ответ» и снижает сетевую задержку. Изначально Server Push появился в протоколе SPDY. Идентификаторы потоков, содержащие псевдозаголовки наподобие
:path, инициируют передачу сервером дополнительной информации, которая должна быть закэширована. Клиент должен либо явным образом позволить серверу передавать себе кэшируемые ресурсы посредством HTTP/2, либо прервать инициированные потоки, имеющие специальный идентификатор.Другие возможности HTTP/2, известные как Cache Push, позволяют с упреждением обновлять или аннулировать кэш на клиенте. При этом сервер способен определять ресурсы, которые могут понадобиться клиенту, которые он на самом деле не запрашивал.
Реализация HTTP/2 демонстрирует высокую производительность при работе с инициативно передаваемыми ресурсами:
- Инициативно передаваемые ресурсы сохраняются в кэше клиента.
- Клиент может многократно использовать эти ресурсы на разных страницах.
- Сервер может мультиплексировать инициативно передаваемые ресурсы вместе с запрошенной информацией в рамках того же TCP-соединения.
- Сервер может приоритезировать инициативно передаваемые ресурсы. Это ключевое отличие с точки зрения производительности между HTTP/2 и HTTP 1.
- Клиент может отклонить инициативно передаваемые ресурсы для поддержания эффективности репозитория, или может вообще отключить функцию Server Push.
- Клиент может также ограничивать количество одновременно мультиплексированных потоков с инициативно передаваемыми данными.
В неоптимальных методиках наподобие встраивания (Inlining) также используются push-функциональности, позволяющие заставить сервер откликаться на запросы. При этом Server Push представляет собой решение на уровне протокола, помогающее избежать возни с оптимизационными хаками.
HTTP/2 мультиплексирует и приоритезирует поток с инициативно передаваемыми данными ради улучшения производительности, как и в случае с другими потоками запросов-откликов. Имеется встроенный механизм безопасности, согласно которому сервер должен быть заранее авторизован для последующей инициативной передачи ресурсов.
Двоичный протокол
Последняя версия HTTP претерпела значительные изменения с точки зрения возможностей, и демонстрирует преобразование из текстового в двоичный протокол. Для завершения циклов запрос-отклик HTTP 1.x обрабатывает текстовые команды. HTTP/2 решает те же задачи с помощью двоичных команд (состоящих из единиц и нулей). Это облегчает работу с фреймами и упрощает реализацию команд, которые могли путать из-за того, что они состоят из текста и необязательных пробелов.
Читать двоичные команды будет труднее, чем аналогичные текстовые, но зато сети будет легче их генерировать и парсить фреймы. Семантика остаётся без изменений. Браузеры, использующие HTTP/2, перед отправкой в сеть конвертируют текстовые команды в двоичные. Двоичный слой фреймов не имеет обратной совместимости с клиентами и серверами, использующими HTTP 1.x. Он является ключевым фактором, обеспечивающим значительный прирост производительности по сравнению с SPDY и HTTP 1.x. Какие преимущества даёт интернет-компаниям и онлайн-сервисам использование двоичных команд:
- Низкие накладные расходы при парсинге данных — критически важное преимущество HTTP/2 по сравнению с HTTP 1.
- Ниже вероятность ошибок.
- Меньше нагрузка на сеть.
- Эффективное использование сетевых ресурсов.
- Решение проблем с безопасностью, наподобие атак с разделением запросов (response splitting attack), проистекающих из текстовой природы HTTP 1.x.
- Реализуются прочие возможности HTTP/2, включая сжатие, мультиплексирование, приоритезацию, управление потоками и эффективную обработку TLS.
- Компактность команд упрощают их обработку и реализацию.
- Выше эффективность и устойчивость к сбоям при обработке данных, передаваемых между клиентом и сервером.
- Снижение сетевой задержки и повышение пропускной способности.
Приоритезация потоков
HTTP/2 позволяет клиенту отдавать предпочтения конкретным потокам данных. Хотя сервер и не обязан следовать подобным клиентским инструкциям, тем не менее этот механизм помогает серверу оптимизировать распределение сетевых ресурсов согласно требованиям конечных пользователей.
Приоритезация осуществляется с помощью присваивания каждому потоку зависимостей (Dependencies) и веса (Weight). Хотя все потоки, по сути, и так зависят друг от друга, ещё добавляется присваивание веса в диапазоне от 1 до 256. Детали механизма приоритезации всё ещё обсуждаются. Тем не менее, в реальных условиях сервер редко управляет такими ресурсами, как ЦПУ и подключения к БД. Сложность реализации сама по себе не даёт серверам выполнять запросы на приоритезацию потоков. Продолжение работ в этом направлении имеет особенное значение для успеха HTTP/2 в долгосрочной перспективе, потому что протокол позволяет обрабатывать многочисленные потоки в рамках единственного TCP-соединения.
Приоритезация поможет разделять одновременно приходящие на сервер запросы в соответствии с потребностями конечных пользователей. А обработка потоков данных в случайном порядке только подрывает эффективность и удобство HTTP/2. В то же время, продуманны и широко распространённый механизм приоритезации потоков даст нам следующие преимущества:
- Эффективное использование сетевых ресурсов.
- Снижение времени доставки запросов первичного контента.
- Повышение скорости загрузки страниц.
- Оптимизация передачи данных между клиентом и сервером.
- Снижение отрицательного эффекта от сетевых задержек.
Сжатие заголовков с сохранением состояния
Чтобы произвести на пользователей наилучшее впечатление, современные веб-сайты должны быть богаты контентом и графикой. HTTP — это протокол без сохранения состояния, то есть каждый клиентский запрос должен содержать как можно больше информации, необходимой серверу для выполнения соответствующей операции. В результате потоки данных содержат многочисленные повторяющиеся фреймы, потому что сервер не должен хранить информацию из предыдущих клиентских запросов.
Если веб-сайт содержит много медиа-контента, то клиент отправляет кучу практически одинаковых фреймов с заголовками, что увеличивает задержку и приводит к избыточному потреблению не бесконечных сетевых ресурсов. Без дополнительной оптимизации сочетания приоритезированных потоков данных мы не сможем достичь желаемых стандартов производительности параллелизма.
В HTTP/2 это решается с помощью сжатия большого количества избыточных фреймов с заголовками. Сжатие осуществляется с помощью алгоритма HPACK, это простой и безопасный метод. Клиент и сервер хранят список заголовков, использовавшихся в предыдущих запросах.
HPACK сжимает значение каждого заголовка перед отправкой на сервер, который потом ищет зашифрованную информацию в списке ранее полученных значений, чтобы восстановить полные данные о заголовке. Сжатие с помощью HPACK даёт невероятные преимущества с точки зрения производительности, а также обеспечивает:
- Эффективную приоритезацию потоков.
- Эффективное использование механизмов мультиплексирования.
- Снижает накладные расходы при использовании ресурсов. Это один из первых вопросов, обсуждаемых при сравнении HTTP/2 с HTTP 1 и SPDY.
- Кодирование больших и часто используемых заголовков, что позволяет не отправлять весь фрейм с заголовком. Передаваемый размер каждого потока быстро уменьшается.
- Устойчивость к атакам, например, CRIME — эксплойтам потоков данных со сжатыми заголовками.
Различия между HTTP 1.x и SPDY
Базовая семантика приложения HTTP в последней итерации HTTP/2 осталась без изменений, включая коды статусов, URI, методики и файлы заголовков. HTTP/2 основан на SPDY, созданной в Google альтернативе HTTP 1.x. Основные различия кроются в механизмах обработки клиент-серверных запросов. В таблице отражены основные различия между HTTP 1.x, SPDY и HTTP/2:
| HTTP 1.x | SPDY | HTTP2 |
|---|---|---|
| SSL не требуется, но рекомендуется. | Необходим SSL. | SSL не требуется, но рекомендуется. |
| Медленное шифрование. | Быстрое шифрование. | Шифрование стало ещё быстрее. |
| Один клиент-серверный запрос на одно TCP-соединение. | Много клиент-серверных запросов на одно TCP-соединение. Осуществляются одновременно на одном хосте. | Многохостовое мультиплексирование. Осуществляются на нескольких хостах в одном экземпляре. |
| Нет сжатия заголовков. | Введено сжатие заголовков. | Используются улучшенные алгоритмы сжатия заголовков, что повышает производительность и безопасность. |
| Нет приоритезации потоков. | Введена приоритезация потоков. | Улучшенные механизмы приоритезации потоков. |
Как HTTP/2 работает с HTTPS
HTTPS используется для установления сетевого соединения высокой степени безопасности, что играет большую роль при обработке важной деловой и пользовательской информации. Основные цели злоумышленников — банки, обрабатывающие финансовые транзакции, и учреждения здравоохранения, в которых накапливаются истории болезней. HTTPS работает в качестве слоя, защищающего от постоянных киберугроз, хотя отражение сложных атак, направленных на ценные корпоративные сети, обусловлено не только соображениями безопасности.
Браузерная поддержка HTTP/2 включает в себя HTTPS-шифрование, и фактически улучшает общую производительность обеспечения безопасности при работе с HTTPS. Ключевыми особенностями HTTP/2, позволяющими обеспечить безопасность цифровых коммуникаций в чувствительном сетевом окружении, являются:
- меньшее количество TLS-хэндшейков,
- меньшее потребление ресурсов на стороне клиента и сервера,
- улучшенные возможности повторного использования имеющихся веб-сессий, но без уязвимостей, характерных для HTTP 1.x.
HTTPS применяется не только в широко известных компаниях и для обеспечения кибербезопасности. Этот протокол также полезен владельцам онлайн-сервисов, обычным блогерам, интернет-магазинам и даже пользователям соцсетей. Для HTTP/2 необходима самая свежая, наиболее безопасная версия TLS, поэтому все онлайн-сообщества, владельцы компаний и вебмастеры должны удостовериться, что их сайты по умолчанию используют HTTPS.
Обычные процедуры настройки HTTPS включают в себя использование планов веб-хостинга, приобретение, активацию и установку сертификатов безопасности, а также обновление самого сайта, чтобы он мог использовать HTTPS.
Основные преимущества HTTP/2
Сетевая индустрия должна заменить устаревший HTTP 1.x другим протоколом, преимущества которого будут полезны для рядовых пользователей. Переход с HTTP 1.x на HTTP/2 почти целиком обусловлен максимальным увеличением потенциала технологических преимуществ, чтобы они соответствовали современным ожиданиям.
С точки зрения электронной коммерции и интернет-пользователей, чем больше в сети нерелевантного контента, насыщенного мультимедиа, тем медленнее она работает.
HTTP/2 создавался с учётом повышения эффективности клиент-серверного обмена данными, что позволяет бизнесменам увеличить охват своих сегментов рынка, а пользователям — быстрее получить доступ к качественному контенту. Помимо прочего, сегодня веб ситуативен как никогда ранее.
Скорость доступа к интернету варьируется в зависимости от конкретных сетей и географического местоположения. Доля мобильных пользователей быстро растёт, что требует обеспечивать достаточно высокую скорость работы интернета на мобильных устройствах любых форм-факторов, даже если перегруженные сотовые сети не в состоянии конкурировать с широкополосным доступом. Полноценным решением этой проблемы является HTTP/2, представляющий собой комбинацию из полностью пересмотренных и переработанных сетевых механизмов, а также механизмов передачи данных. Каковы основные преимущества HTTP/2?
Производительность сети
Это понятие отражает совокупный эффект всех нововведений HTTP/2. Результаты бенчмарков (см. главу «Сравнение производительности HTTPS, SPDY и HTTP/2») демонстрируют увеличение производительности при использовании HTTP/2 по сравнению с его предшественниками и альтернативными решениями.
Способность протокола отправлять и принимать больше данных в каждом цикле обмена данными клиент-сервер — это не оптимизационный хак, а реальное, доступное и практическое преимущество HTTP/2. В качестве аналогии можно привести сравнение вакуумного поезда с обычным: отсутствие трения и сопротивления воздуха позволяет транспортному средству перемещаться быстрее, брать больше пассажиров и эффективнее использовать доступные каналы без установки более мощных двигателей. Также снижается вес поезда и улучшается его аэродинамика.
Технологии наподобие мультиплексирования помогают одновременно передавать больше данных. Как большой пассажирский самолёт, с несколькими этажами, напичканными сиденьями.
Что происходит, когда механизмы передачи данных сметают все преграды на пути к повышению производительности сети? У высокой скорости работы сайтов есть побочные явления: пользователи получают больше удовольствия, улучшается оптимизация для поисковых сервисов, ресурсы используются эффективнее, растёт аудитория и объёмы продаж, и многое другое.
К счастью, внедрение HTTP/2 несравненно практичнее, чем создание вакуумных тоннелей для больших пассажирских поездов.
Производительность мобильной сети
Ежедневно миллионы пользователей выходят в сеть со своих мобильных устройств. Мы живём в «эру постПК», множество людей используют смартфоны в качестве основного устройства для доступа к онлайн-сервисам и выполнения большинства рутинных вычислительных задач прямо на ходу, вместо длительного сидения перед мониторами настольных компьютеров.
HTTP/2 проектировался с учётом современных тенденций использования сети. Задача нивелирования небольшой пропускной способности мобильного интернета хорошо решается благодаря снижению задержки за счёт мультиплексирования и сжатия заголовков. Благодаря новой версии протокола, производительность и безопасность обмена данными на мобильных устройствах достигают уровня, характерного для десктопов. Это сразу же положительно сказывается и на возможностях онлайн-бизнеса по охвату потенциальной аудитории.
Интернет подешевле
С момента создания Всемирной паутины стоимость использования интернета быстро снижалась. Главными задачами развития сетевых технологий всегда были расширение доступа и повышение его скорости. Однако снижение цен, судя по всему, застопорилось, особенно в свете утверждений относительно монополии телекоммуникационных провайдеров.
Рост пропускной способности и повышение эффективности обмена данными при внедрении HTTP/2 позволит провайдерам уменьшить операционные расходы без снижения скорости доступа. В свою очередь, снижение операционных расходов позволит провайдерам активнее продвигаться в низком ценовом сегменте, а также предлагать более высокие скорости доступа в рамках уже существующих тарифов.
Экспансивный охват
Густонаселённые регионы Азии и Африки всё ещё испытывают нехватку доступа в интернет с приемлемой скоростью. Провайдеры стараются извлечь максимальную прибыль, предлагая свои услуги только в крупных городах и развитых районах. Благодаря преимуществам HTTP/2 можно будет уменьшить нагрузку на сети, выделив часть ресурсов и пропускной способности каналов для жителей удалённых и менее развитых районов.
Насыщенность мультимедиа
Сегодня интернет-пользователи практически требуют контент и сервисы, насыщенные мультимедиа, с моментальной загрузкой страниц. При этом для успешной конкуренции владельцам сайтов необходимо регулярно обновлять их содержимое. Стоимость соответствующей инфраструктуры не всегда подъёмна для интернет-стартапов, даже при условии использования облачных сервисов по подписке. Преимущества и технологические особенности HTTP/2, вероятно, не помогут сильно уменьшить размеры файлов, но зато снимут по несколько байт с накладных расходов при передаче «тяжёлого» медиа-контента между клиентом и серверами.
Улучшение опыта использования мобильного интернета
Прогрессивные онлайн-компании ради эффективного охвата быстрорастущей мобильной аудитории следуют стратегии Mobile-First. Пожалуй, главным ограничением, влияющим на использование мобильного интернета, являются не самые выдающиеся характеристики аппаратных компонентов смартфонов и планшетов. Это выражается в более длительных задержках при обработке запросов. HTTP/2 позволяет уменьшить продолжительность загрузки и сетевых задержек до приемлемого уровня.
Более эффективное использование сети
«Тяжёлый» медиа-контент и сайты со сложным дизайном приводят к заметному росту потребления ресурсов при обработке клиентом и сервером браузерных запросов. Хотя веб-разработчики и выработали приемлемые оптимизационные хаки, всё же появление устойчивого и надёжного решения в виде HTTP/2 было неизбежным. Сжатие заголовков, инициативная отправка данных сервером, зависимости потоков и мультиплексирование — всё это ключевые особенности, улучшающие эффективность использования сети.
Безопасность
Преимущества HTTP/2 не ограничиваются одной лишь производительностью. Алгоритм HPACK позволяет обходить распространённые угрозы, нацеленные на текстовые протоколы уровня приложения. Для защиты данных, передаваемых между клиентом и сервером, в HTTP/2 используется подход «Безопасность через непонятность» (Security by Obscurity): команды представлены в двоичном виде, применяется сжатие метаданных HTTP-заголовков. Кроме того, протокол может похвастаться полноценной поддержкой шифрования и требует применения улучшенной версии Transport Layer Security (TLS1.2).
Инновационность
HTTP/2 является воплощением идеи высокопроизводительной сети. Этот протокол лежит в основе кибермира, каким мы его знаем сегодня. Изменения, вносимые HTTP/2, в основном базируются на свойствах SPDY, который стал огромным шагом вперёд по сравнению с HTTP 1.x. И в ближайшем будущем HTTP/2 полностью заменит как SPDY, так и предыдущие версии HTTP. Веб-разработчики смогут избавиться от сложных оптимизационных хаков при создании высокопроизводительных сайтов и сервисов.
Преимущества HTTP/2 с точки зрения SEO
SEO-маркетинг лежит где-то посередине между наукой и искусством. Из-за усложнения проприетарных алгоритмов, используемых популярными поисковиками, традиционные нечестные SEO-методики уже не позволяют манипулировать результатами поисковой выдачи. И в соответствии с этим онлайн-компаниям нужно менять свои стратегии маркетинга. Необходимо разумно инвестировать в созданные с нуля, тщательно проработанные сайты, оптимизированные с точки зрения не просто скорости, а превосходной производительности, безопасности и пользовательского опыта. Это более предпочтительные атрибуты, позволяющие формировать поисковые выдачи с наиболее точной информацией и сайтами, удобными в использовании для всей целевой аудитории.
Стандартные процессы поисковой оптимизации выходят за рамки маркетинговой фронтэнд-тактики. Теперь они охватывают полный цикл обмена данными между клиентом и сервером. SEO-оптимизаторы, которые ранее были ключевыми фигурами в командах интернет-маркетинга, потеряли свои позиции с появлением новых технологий цифровых коммуникаций. И преобладание среди них HTTP/2 свидетельствует о тектоническом сдвиге, который заставляет веб-разработчиков и маркетологов вернуться к чертёжным доскам.
Критически важным фактором для поисковой оптимизации сегодня является внедрение и оптимизация инфраструктуры для HTTP/2 и многообещающих преимуществ в производительности. Онлайн-компании, страдающие от недостаточности адекватной органической пользовательской базы, не могут позволить себе пренебрегать HTTP/2, а следовательно и улучшениями с точки зрения SEO. Ведь этим компаниям приходится конкурировать на почве инноваций с растущими сетевыми бизнес-империями, и высоко ранжированный онлайн-сервис поднимется ещё выше благодаря реализации HTTP/2 на стороне серверов.
Сравнение производительности HTTPS, SPDY и HTTP/2
Результаты бенчмарков ясно показывают ситуацию с улучшением производительности в новом протоколе.
Результаты бенчмарка HTTP/2 подтверждают, что сжатие заголовков, инициативная отправка данных сервером и прочие механизмы, используемые для ускорения загрузки страниц, действительно последовательно реализуются.
Подробности тестирования:
Результаты этого теста говорят нам следующее:
- Размеры заголовков клиентского запроса и серверного отклика: HTTP/2 демонстрирует, что использование сжатия позволяет значительно уменьшить размер заголовка. При этом SPDY уменьшает заголовок только серверного отклика для данного запроса. HTTPS вообще не уменьшает заголовки.
- Размер сообщения серверного отклика: размер отклика HTTP/2-сервера оказался больше, но зато в нём применялось более стойкое шифрование.
- Количество использованных TCP-соединений: при обработке многочисленных одновременных запросов(мультиплексирование) HTTP/2 и SPDY используют меньше сетевых ресурсов, следовательно, снижается задержка.
- Скорость загрузки страницы: HTTP/2 постоянно был быстрее SPDY. HTTPS был значительно медленнее из-за отсутствия сжатия заголовков и инициативной отправки данных сервером.
Браузерная поддержка HTTP/2 и доступность
HTTP/2 уже можно использовать при адекватной поддержке со стороны серверов и браузеров, в том числе мобильных. Работа технологий, использующих HTTP 1.x, не будет нарушена при реализации HTTP/2 на вашем сайте. Но их потребуется быстро обновить, чтобы они поддерживали новый протокол. Представьте, что сетевые протоколы — это языки общения. На новых языках можно общаться только тогда, когда как-то понимаешь друг друга. Так и здесь: клиент и сервер нужно обновить, чтобы обеспечить поддержку обмена данными с помощью протокола HTTP/2.
Клиентская поддержка
Пользователям не нужно заботиться о настройке поддержки HTTP/2 в своих браузерах — «полноценных» и мобильных. Chrome и Firefox давно поддерживают эту технологию, а в Safari поддержка HTTP/2 появилась в 2014. В IE данный протокол поддерживается только начиная с Windows 8.
Основные мобильные браузеры, включая Android Browser, Chrome для Android и iOS, а также Safari в iOS8 и выше, уже поддерживают HTTP/2. Рекомендуется на всякий случай поставить последние стабильные версии мобильных и настольных браузеров, чтобы получить максимальную производительность и преимущества в безопасности.
Серверная поддержка: Apache и Nginx
Владельцы онлайн-сервисов, работающих локально или в облаке, для добавления поддержки HTTP/2 должны обновить и сконфигурировать свои серверы. Согласно приведённой выше аналогии с языками, пользователи могут получить данные с серверов только посредством HTTP/2, потому что они были с этой целью обновлены и сконфигурированы.
Nginx-серверы, составляющие 66% всех активных веб-серверов, могут похвастаться встроенной поддержкой HTTP / 2. А для обеспечения браузерной поддержки HTTP/2 на Apache, нужно воспользоваться модулем mod_spdy. Он разработан Google для внедрения поддержки в Apache 2.2 таких функций, как мультиплексирование и сжатие заголовков. Это ПО было передано в дар Apache Software Foundation.
Как начать использовать HTTP/2?
Для настройки HTTP/2 на своём сайте воспользуйтесь этой простой инструкцией:
- Проверьте, чтобы был включен HTTPS:
- Приобретите в проверенной организации сертификат SSL или TLS.
- Активируйте сертификат.
- Установите сертификат.
- Обновите сервер для включения протокола HTTPS.
- Проверьте, чтобы базовая сетевая инфраструктура включала в себя поддержку HTTP/2 на уровне серверного ПО. Серверы Nginx имеют нативную поддержку, в Apache она появилась в октябре 2015 (в версии 2.4). В более ранних версиях для поддержки HTTP/2 нужно установить дополнительные модули.
- Обновите, сконфигурируйте и протестируйте ваши серверы. Здесь описана конфигурация и процедуры тестирования для серверов Apache. Свяжитесь со своим хостинг-провайдером и удостоверьтесь, что ваш сайт готов к использованию HTTP/2.
- Для проверки правильности конфигурации HTTP/2 воспользуйтесь этим инструментом.
Заключение
Нас ждёт неизбежное доминирование и превосходство HTTP/2. Протокол уровня приложения, похоже, несёт в себе наследие HTTP 1.x, который когда-то изменил сеть благодаря своим революционным возможностям по передаче данных. Но HTTP/2 демонстрирует гораздо более значительное технологическое превосходство над своим предшественником, чем HTTP 1.x в своё время.
Тем не менее, использование HTTP/2 — это лишь один шаг на пути к увеличению скорости загрузки страниц. В нашем Пособии по оптимизации скорости работы веб-сайта для начинающих описано, как создавать быстрые сайты, как исключать узкие места производительности, а также какие стратегические бизнес-преимущества даёт высочайшая производительность веб-сайта.
Комментарии (40)
tmnhy
01.07.2016 11:30+11По подаче материала, очень похоже на «втюхивание» )) Много цветных картинок и даже есть совершенно бесполезные графики.
Много тезисов, которые выдаются за аксиомы, без «пруфов». Интерес пропал еще до середины статьи.
bertmsk
01.07.2016 14:10+2+++
Такое ощущение что читаешь пресс-релиз какогонить гугла. Куча плоской material-графики и ничего по существу.
dmitry_ch
01.07.2016 11:37+3Судя по графику времени появления протоколов
вот этому
QDeathNick
10.11.2016 16:45Ну не сложно же дожить. Вот я собираюсь нажать кнопку передачи, настраиваю приёмник, и как настроил, вдруг раз, уже пошли данные, а я только потом нажимаю кнопку передачи.
И тут я передумал нажимать :)
Вот в этом по-моему фундаментальная трудность.dmitry_ch
01.07.2016 22:07+1Ну если уж о справедливости, то внедрение SPDY, http/2 и прочих протоколов все же продвинулось сильно дальше. IPv6 забуксовало достаточно, чтобы не считать его «в среднем живым».
Даже если в сети какого-то оператора IPv6 и есть, ТП не способна ни дать совет, как настроить оборудование клиента (обычно есть одна-две «референсные» модели железок, которые понятно как настроить; модели эти обычно уже не продаваемые, по остальным никто ничего не знает, «читайте форумы»), ни даже проверить, что на стороне оператора IPv6 работает успешно (обычно говорят «это же опционально, нет гарантий, что он всегда будет работать хорошо»). Сравните с состояние дел с http/2 — сайты-то открываются у всех :)
P.S. Впрочем, Вы, кажется, отвечали не на мой коммент )
wild_one
10.11.2016 17:05А откуда мы можем быть уверены, что вектор вообще не 4+n-мерный? (с моей дилетантской точки зрения)? Ведь в пространстве могут быть и «свернутые» измерения.
Кстати, а что по поводу квантования времени? Планковская длина есть, а «квант» времени?
khim
01.07.2016 22:43+1IPv6 забуксовало достаточно, чтобы не считать его «в среднем живым»
Да ладно вам. По грубым оценкам годичной давности планировалось иметь 12%, реально имеем 11.5% — я бы не назвал это такой уж большой «пробуксовкой».
Сравните с состояние дел с http/2 — сайты-то открываются у всех :)
Как видим тоже не всегда. Но вообще — внедрить HTTP/2 или даже HTTP/10 проще, чем IPv6, так как всё магистральное оборудование менять не нужно.
albik
04.07.2016 12:20Аналогичное мнение. Протокол преподносится как нечто невероятно крутое и фичастое, но по факту это все тот же HTTP/1, только в бинарном виде и с парой плюшек. POP->IMAP, IPv4->IPv6 — вот это действительно прогресс и действительно новая парадигма, построенная исходя из реальных потребностей людей и возможностей технологий, а то, что выкатили под видом HTTP/2 — карманный протокол для обслуживания собственных нужд гугла и близлежащих корпораций, который решили навязать всем в качестве стандарта, не в последнюю очередь — разработчикам браузеров.
Протокол как бизнес-план — решение просто отличное: благодаря фактической принудиловке с шифрованием будет меньше фильтраций рекламы на уровне провайдеров, благодаря push можно затолкать пользователю в кеш баннеров на полгода вперед, а благодаря приоретизации — затолкать баннеры одними из первых, благодаря мультиплексированию котятки на ютубе будут грузиться быстрее. А вот куки убирать не будем, хотя многие и просили, считая эту фичу небезопасной.
Не отлично то, что IETF из арбитра между компаниями, пользователями и реальностью превратили в резинотехническое изделие №2. Ведь нет же у HTTP/1 никаких несовместимых с жизнью проблем или критичного недостатка фич, и то, что HTTP/2 практически полностью слизан с HTTP/1 это только доказывает. Ведь могли же стимулировать IETF на разработку действительно нового протокола, но тогда бы со 100%-ой гарантией поломалась бы обратная совместимость, и полный переход занял бы лет 10 как минимум. Но кому-то надо немного разгрузить сервера и немного больше заработать здесь и сейчас, и это уже является достаточным основанием для того, чтобы навязывать разработчикам браузеров свои костыльные детища.dmitry_ch
04.07.2016 13:04По факту получили забавный момент: народ, приученный, что нужно иметь статический IP для каждого сайта с HTTPS, начал уползать с shared хостингов на ВПСки (с выделенными, конечно, IP), и IPv4 начали сокращаться еще шустрее. Не за горами момент, когда массовые VPS-хостинги начнут из IPv4 выдавать только серые адреса, ставить перед ними прокси и NAT-ы, а клиент в панели управления будет себе заказывать проброс или http-проксирование нужных портов. IPv6 останется безлимитным, что хоть как-то, наверное, сподвигнет его юзать.
А если серьезно, пока домашний юзер не получит легкую в настройке и надежную в работе схему использования IPv6, сервера можно не бежать и не настраивать. Увы.
Потому что даже у одного вендора домашнего роутера даже на одной ревизии железа (привет, Длинку с его тремя-пятью аппаратными ревизиями под одним названием!) но на разных версиях прошивок настройка IPv6 мало что может отличаться, так еще может и не работать при внешне одинаковых настройках.khim
04.07.2016 15:53А если серьезно, пока домашний юзер не получит легкую в настройке и надежную в работе схему использования IPv6, сервера можно не бежать и не настраивать.
Его уже сейчас нужно тестировать и проверять. И бежать с хостингов, которые его не поддерживают.
Посмотреть как происходит переход с одной технологии на другую можно на примере сотовых сетей. Последний случившийся там переход — с 2G на 3G. Следующий, в процессе — с 3G на 4G.
Всё происходит по одной и той же схеме: когда новые технологии появляются, то они, как правило — мало кому нужны. И те операторы, которые «рвутся в бой» в числе первых — часто «выкидывают деньги на ветер» и, в общем, лидерами не становятся. Когда Telenor запустил 3G сети в 2001 году новых клиентов он, в том году, вообще не получил. И дальше — много лет развитие идёт по тому же принципу «у нас есть фишка, но она никому не нужна». В газетах начинают появляться статьи о том, что «революция провалилась» и так далее.
А потом, со временем — собирается критическая масса. И в очень короткий срок операторы, не предоставляющие соответствующую услугу, разоряются (в случае с сотовыми операторами их обычно покупают ибо даже самый захудалый и самый «убитый» оператор имеет ценный актив — лицензии на частоты, ISP будут просто закрыты).
Когда именно это произойдёт? Это очень тяжело рассчитать в начале процесса, но когда пользователи «новинки» составляют 5-10% от всех пользователей… борьба, в общем-то, уже окончена.
Вспомните задачку: В стеклянной банке сидит микроб. Каждую минуту он делится пополам. Новые микробы, в свою очередь, через минуту снова делятся пополам — и так до бесконечности. Известно, что через 5 часов банка будет полна. Спрашивается: через какое время после начала деления микробы займут половину банки?
Ответ, с которым многим очень сложно примириться: 4 часа 59 минут. Вот в это время, когда мы уже «выбрали» 99.5% времени, а всё ещё наполовину пуста — многим кажется что «всё пропало» и в 5 часов никак не уложиться. Но нет — природа экспоненты такова, что «всё срастётся».
То же самое с 3G, 4G, 5G… и IPv6: конечно новые пользователи подключаются не так регулярно как делится микроб в задачке, так что сказать прямо с точностью до дня когда обанкротятся компании не поддерживающие IPv6 нельзя, но можно сказать достаточно точно когда можно будет забыть про IPv4: где-то в 2021м году. В крайнем случае — в 2022м. Вот примерно к этому моменту можно будет людей просить делать «ping6 ipv6.google.com» и отправлять их к провайдеру в случае отсутствия ответа…
Потому что даже у одного вендора домашнего роутера даже на одной ревизии железа (привет, Длинку с его тремя-пятью аппаратными ревизиями под одним названием!) но на разных версиях прошивок настройка IPv6 мало что может отличаться, так еще может и не работать при внешне одинаковых настройках.
Это — проблемы ISP, создателей сервера они не волнуют.dmitry_ch
04.07.2016 16:05создателей сервера не волнуют
Напомнили старое доброе:
Послали админов на армейскую переподготовку.
Выдали по автомату, патронов как никогда, и — на стрельбище.
Стреляли-стреляли — куда угодно попали, только не по мишеням.
Командир их строит:
— Вы, блин, связисты так вашу разэтак! Кто ж так стреляет! Чему вас учили?
И тут голос из строя:
— Командир! У нас пуля из ствола вылетела — проблемы на вашей стороне.
А если честно, ваш подход мне нравится. Настроить сервер — дело важное. Но клиентам-то как?
Итак, дано: есть домашний юзер, который вчера подключил себе инет одного из операторов. Есть (да-да, есть!) IPv6 в сети оператора. Вопрос: сколькими методами клиент может на своей железке (давайте для определенности, что он через wifi-роутер работает) может настроить этот самый IPv6?
Если бы речь шла об IPv4, настройка несложна: операторы поднимают обычно у себя в сети PPPoE или PPtP. Первое «само работает», второе с чуть большим волнением, но технологии привычные (разве что в первом случае сервер подключения указывать не надо).
IPv6 имеет варианты. Сами посчитаете, или сказать число комбинаций технологий? А число «домашних» железок, на которых все эти (даже «самые частые») комбинации работают подскажете в ответ?
IPv6 в сети оператора так и не стало рекламной фичей. Может, «пока», может, «уже» не стало. Раз не стало (как 3G и 4G), то операторы не видят денежной (кроме экономии IPv4-пулов) нужды вылизывать проблемы с IPv6. Более того, часты ситуации, когда неработа IPv6 в сетях аплинков не беспокоит ТП, вплоть до «не знаем, когда они починят».
Так что сайты на IPv6 настраивать надо. Громких слов про него надо поменьше, а вот дела — побольше. Но раз сдать девайс в магазин со словами «на нем IPv6 в сети моего провайдера не работает», нельзя, то и повода у Д-Лика и иже с ним. делать нормальный IPv6-enabled софт как бы и нет.khim
04.07.2016 16:54А если честно, ваш подход мне нравится. Настроить сервер — дело важное. Но клиентам-то как?
А клиенты пусть пинают провайдеров если им IPv6 нужен. Я же не сказал IPv4 выкидывать — рано пока. Вот лет через 5 — да, уже можно будет кое-какие вспомогательные фичи пользователям IPv4 не предоставлять. А лет через 10 — их можно будет уже и отключать начинать. А пока — рано ещё. Всему своё время.
Итак, дано: есть домашний юзер, который вчера подключил себе инет одного из операторов. Есть (да-да, есть!) IPv6 в сети оператора. Вопрос: сколькими методами клиент может на своей железке (давайте для определенности, что он через wifi-роутер работает) может настроить этот самый IPv6?
А какая разница? Раз этот, с позволения сказать, клиент, ищет приключений на свою задницу, то он и будет разбираться. 90% (если не 99%) пользователей получают железяку от провайдера настроенной и работающей.
Если бы речь шла об IPv4, настройка несложна: операторы поднимают обычно у себя в сети PPPoE или PPtP.
Обычно, но не всегда. У меня вот L2TP используется. Но это я знаю — как параноик купивший и настроивший свой роутер. Большинство пользователей об этом и не догадываются.
IPv6 в сети оператора так и не стало рекламной фичей. Может, «пока», может, «уже» не стало.
И «уже» и «пока». Мы сейчас в нижней точке разочарования в пресловутом цикле зрелости технологий. Говорить о том, что «они самые продвинутые! у них даже IPv6 есть! идите к ним!» — уже нельзя, говорить о том, что «у этих придурков даже IPv6 нет, о чём тут ещё говорить? бегите от них!» — ещё нельзя, так что, разумеется, шумиха утихла.
Более того, часты ситуации, когда неработа IPv6 в сетях аплинков не беспокоит ТП, вплоть до «не знаем, когда они починят».
3G тоже через это проходил несколько лет назад. И 4G (да собственно даже сегодня 4G воспринимается скорее как «бонус», чем как что-то, отключение чего может привести к отказу от ОпСоСа). И 5G пройдёт.
Но раз сдать девайс в магазин со словами «на нем IPv6 в сети моего провайдера не работает», нельзя, то и повода у Д-Лика и иже с ним. делать нормальный IPv6-enabled софт как бы и нет.
Да — но на какой процент пользователей это влияет? Большинству достаточно того, что этот самый DLink «с помощью лома и какой-то матери» провайдер заставил работать в своей сети — а чего им ещё нужно?
Больше скажу: мой Buffalo WZR-HP-G300NH «из коробки» L2TP поднять тоже не мог — и как-то продавец это гарантийным случаем тоже не считал. Мне теперь от IPv4 тоже отказаться?dmitry_ch
04.07.2016 17:45L2TP
Да-да, его-то я и забыл. Я бы от такого оператора постарался уйти (точнее, везде, где мог себе позволить, ушел и ухожу), а не от IPv-что-то там. «Пакеты не виноваты», да.
Хорошо, краткая выжимка такова: пока, сев на IPv6, клиент не перестанет переживать, почему у него часть сайтов не открывается, радости нам всем не будет. Сам видел, и не раз, как вконтактик (а это тот еще генератор трафика, сами понимаете) в локальной сети по IPv6 начинает быть то медленным, то вообще пропадает со связи, а по IPv4 тот же ресурс отлично открывался. В общем, преднастроенная железка от оператора будет отличным решением, но я часто вижу операторов, которые не в сторону IPv6 смотрят, а вводят «добровольно-принудительно» CGN. Не самые гнилые из операторов при этом хотя бы позволяют эту «фичу» бесплатно отключать, самые же «добрые» отвечают — «интернет у вас есть? значит, договор мы выполняем», и CGN не отключают никак.
Впрочем, будем надеяться. Юзерам тем временем нужно культуру файрволлов прививать — за NAT-ами разбаловались, что роутер на 99% атаки извне гасит.schetilin
04.07.2016 20:44Вот я прямо так себе и представил, как я своей бабушке (70+ лет) прививаю культуру файрволлов :) Любая технология, пока не дойдет до стадии «включил и оно заработало», популярной не станет.
dmitry_ch
04.07.2016 21:44Ну, я же не буду Вам рассказывать пользу и опасность наличия на ПК (в т.ч. на ПК бабушки) прямого белого IP, особенно IPv6 )) Особенно с учетом того, что половина защитного ПО пока не совсем в курсе, как с трафиком с/на него иметь дело )))
rerf2010rerf
11.11.2016 14:02+1Вдобавок уже пару дней назад была выдвинута другая гипотеза, которая эти расхождения объясняет лучше, без всяких темных материй.
Гипотез этих было выдвинуто уже десятки, если не сотни, и не только пару дней назад, а в течение десятилетий — ровно с момента обнаружения сих феноменов. Проблема всех этих гипотез в том, что, объясняя одно, они ломают другое, противоречат другим данным. Так что гипотеза тёмной материи самая «экономичная» из них.dmitry_ch
04.07.2016 23:31А что в 4G такого, без чего жить нельзя? И почему Би без него умирает? Насколько я понимаю, умирает он немного по другой причине. Интернет у них, кстати, получше чем у конкурентов, но, возможно, у вас там другая картина.А лично мне была бы востребованы функции вроде Wi-Fi Calling, но это не к Билайну, а еще и к «товарищу майору», который, как говорят, не успевает определять место нахождения абонента и т.д.
Дело в том, что «косты резать» мозгов много не надо. И IPv6 для этого не нужен (если бы не говорим о людях пытливых и которым что-то надо). Выдали бабушке роутер, он работает, ноутбук цепляется, «какие проблемы, интернет же есть?» А вот когда роутер решат перешить (удаленно, да!) на поддержку IPv6-first вариант, вот тут провайдер поимеет массу плавающих проблем, и никогда поэтому на такое не пойдет.
Да, можно провайдерам повыкручивать руки (вы понимаете, что по факту траблы получит не провайдер, а клиенты его, и провайдера поменяют, конечно — может, один на тысячу, а может, и еще меньше), и зарубить на своем сайте IPv4. Но пока сайт не будет суперважен (вконтактик с фейсбуком, например, хотя как они могут считаться действительно важными — это вопрос хороший), сайт не людей лишит себя, а себя — людского внимания. А ВК отрубать IPv4 не станет, им кушать надо.
Против кого дружим? Здесь типичная проблема курицы и яйца, да еще отягощенная жутким техническим долгом. Вендоры все обещали, что, как IPv6 устаканится, выйдут апдейты, и всё-всё заработает, но…
Домашние роутеры сильно отстали от прогресса. Даже операторские — отстали, и никто домашний парк обновлять не будет.
Да что говорить, у дуал-стека до сих пор есть ахилесова пята: если браузеру, скажем, кажется, что у сайте есть IPv6-адрес, то он будет стучаться на него допотери пульсистекания таймаута, прежде чем постучится на IPv4. На выходе это дает чехарду и кучу жалоб. Каждая ОСь по этому поводу себя ведет как хочет, и одинаковости поведения здесь не ждем.
В общем, по уму если, ждем лет 10, потом пробуем перевести мир на «вэ-шестой». За 10 лет обновятся и ОСи, и роутеры, и оборудование операторов. Только за 10 лет костылей столько наделают на v4…khim
05.07.2016 00:11А что в 4G такого, без чего жить нельзя?
В том-то и дело, что ничего. Но это то, чего требуют самые «денежные» клиенты.
А лично мне была бы востребованы функции вроде Wi-Fi Calling, но это не к Билайну, а еще и к «товарищу майору», который, как говорят, не успевает определять место нахождения абонента и т.д.
Нет, тут всё просто: Wi-Fi Calling — требует достаточно современной инфраструктуры, а тут у Билайна в принципе — проблемы. 4G — это одно из проявлений проблемы, но у Билайна в принципе всё плохо с оборудованием — оно давно не обновлялось и сейчас, в общем, это уже очень серьёзно влияет на качество связи.
Да, можно провайдерам повыкручивать руки (вы понимаете, что по факту траблы получит не провайдер, а клиенты его, и провайдера поменяют, конечно — может, один на тысячу, а может, и еще меньше), и зарубить на своем сайте IPv4.
Есть много других, гораздо более простых способов самоубийства.
На данном этапе заставлять обычных пользователей использовать IPv6 — это садизм по отношению к ним и мазохизм по отношению к сервису. А вот всякие шняги для разработчиков — уже можно переводить на IPv6.
Домашние роутеры сильно отстали от прогресса. Даже операторские — отстали, и никто домашний парк обновлять не будет.
Извините, но статистика говорит об обратном. Использование Ipv6 растёт на выходных и падает в будни. Причём в какой-нибудь Белгии уже почти половина населения использует IPv6 (в США — четверть).
В общем, по уму если, ждем лет 10, потом пробуем перевести мир на «вэ-шестой».
А смысл? Что через 10 лет вдруг такого радикального произойдёт?
За 10 лет обновятся и ОСи, и роутеры, и оборудование операторов.
Почему именно через 10? почему не через 3 или 100?
Смотреть нужно на ваш конкретный сервис и выбирать время когда конкретно вам будет выгоднее «послать пользователей IPv4 лесом». Понятно что сегодня, когда пользователей IPv4 сетей в 10 раз больше, чем пользователей IPv6 делать сервис, который работает только в IPv6 сетях — самоубийство, но когда разница окажется в 2-3 раза… может оказаться что вам дешевле и проще привлечь 2-3*X% пользователей IPv6 сетей, чем X% пользователей IPv4 сетей. Учитите ещё что IPv6 сети — это, в большинстве случаев, новые сети… и вы поймёте откуда пойдёт революция. Скорее всего — снова из игрушек. Игрушки начали требовать x64 за несколько лет до того, как пользователи отказались от Windows XP — думаю что и тут то же самое будет. Посмотрим.
Только за 10 лет костылей столько наделают на v4…
Это да. Тут ничего не поделать, увы. Забавно только что все попытки оттянуть исчерёпывание IPv4 привели только к тому, что процесс перехода сделали более болезненным. Посмотрите ещё раз на статистику: процесс перехода на IPv6 по настоящему стартовал, по большому счёту, только тогда, когда IPv4 адреса, в некотором смысле, «закончились» (красная и зелёная линии пересеклись в конце 2010го) — и это, увы, не случайно. Есть такая статья, которая описывает этот феномен — почитайте, если у вас английским всё хорошо: она старая, но актуальности не потеряла.dmitry_ch
05.07.2016 09:30В общем, по уму если, ждем лет 10, потом пробуем перевести мир на «вэ-шестой».
А смысл? Что через 10 лет вдруг такого радикального произойдёт?
За 10 лет обновятся и ОСи, и роутеры, и оборудование операторов.
Почему именно через 10? почему не через 3 или 100?
Вы задаете вопрос к предложению, пояснение к которому дается в следующем. Мне кажется, это все, что нам с вами нужно знать о нашей ветке дискуссии.
Время решит вопрос с адресацией. И v6, и хоть v26 однажды появятся в сети, и будут работать у всех, но — не сразу. Потому что сегодня я не наблюдаю ни поголовной поддержки v6 со стороны имеющегося оборудования, ни со стороны софта, ни банальных толковых инструкций на сайтах провайдеров. Может, конечно, Бельгия в этом смысле либо дисциплинированнее, либо меньше, либо там операторы как-то очень правильно себя ведут, но… Посмотрим!khim
05.07.2016 11:33Потому что сегодня я не наблюдаю ни поголовной поддержки v6 со стороны имеющегося оборудования, ни со стороны софта, ни банальных толковых инструкций на сайтах провайдеров.
Странно. Я почему-то всё это наблюдаю. Может вы не туда смотрите?
Потому что сегодня я не наблюдаю ни поголовной поддержки v6 со стороны имеющегося оборудования, ни со стороны софта, ни банальных толковых инструкций на сайтах провайдеров.
Вы хотите сказать что видите инструкции, объясняющие как подключиться через IPv4??? Я в основном вижу инструкции многолетней давности, многие из которых уже не действуют. Мир изменился: сегодня провайдеры просто выдают вам роутер и всё. Как он там соединяется с внешним миром и что у него внутри — написано только во внутренней инструкции для монтажников…
Может, конечно, Бельгия в этом смысле либо дисциплинированнее, либо меньше, либо там операторы как-то очень правильно себя ведут, но…
Бельгия опережает ситуацию «в среднем по миру» на примерно на два года, Россия — отстаёт где-то на три. Самое важное: Штаты и Япония — впереди «средней позиции» на год. Вряд ли кто-то сделает особо популярный сервис, работающий только в Бельгии, а вот сделать что-то, что поначалу будет работать только в США и Японии — могут легко (сервес тестирования Андроида, требующий IPv6 уже сейчас, я назвать «популярным» всё же не могу, LOL).
Я ожидаю, что это произойдёт где-то в 2020-2021м году (как и писал год назад). А дальше — всем остальным (кроме «отрезанного от мира» Китая) придётся подтягиваться.
P.S. А насчёт «поголовной поддержи IPv6 со стороны оборудования»… всё зависит от заказчика. Сказал Verizon что всё железо с поддержкой LTE обязано поддерживать IPv6 — поставщики взяли под козырёк, у Verizon'а уже больше половины пользователей IPv6 имеют, сказал T-Mobile, что без этого «кина не будет» — и получил. Понятно что старые сети нужно как-то поддерживать и перевести за месяц-другой всех на новое оборудование не получится, но почему ISP в России по прежнему продолжают устанавливать новое оборудование без поддержки IPv6 — мне непонятно. Хотят попасть в ситуацию когда клиенты будут требовать IPv6, а они его им дать не смогут? Попадут — и даже примерно ясно когда.
Ivan_83
01.07.2016 11:48Херня какая то.
«Последняя версия — HTTP 1.1 — используется уже более 15 лет. В эру динамического обновления контента, ресурсоёмких мультимедийных форматов и чрезмерного стремления к увеличению производительности веба, технологии старых протоколов перешли в разряд морально устаревших.»
выкиньте тогда уж и POP3, IMAP, SMTP, tcp, IPv4, IPv6 — они не новее.
Остальной бред даже комментировать не охота.
tmnhy
01.07.2016 11:55Тьфу ты, не понял сначала, что это перевод. Расходимся.
А запостившему, всё-равно минус, перевод-переводом, но содержимое — откровенный bullshit.
Suvitruf
01.07.2016 12:07коллективная система (collective system) позволяет серверам эффективно передавать клиентам больше контента, чем они запросили
Запросили картинку на 1мб, а сервер отдал 10мб? )bertmsk
01.07.2016 14:51+1Ну а вдруг юзер захочет посмотреть еще чтото? А тут — опа, чики-брики и в дамках.
Я бы пошел еще дальше и отправил ему кинцо какое на полтора гига. Чтобы не скучал.
Shifty_Fox
10.11.2016 00:40+2Можно попроще разжевать эксперимент с фотонами, полупрозрачным зеркалом и интерференцией? Это гипотеза, или реальная установка, демонстрирующая знание фотона о будущем?
fathom
01.07.2016 18:28А в чем именно была проблема с яндекс ботом? Подскажите куда смотреть и решение, буду благодарен? :)
frig
01.07.2016 18:32Насколько я помню, это была скорее ошибка конфигурации. По умолчанию включался http/2, который яндекс бот в упор не понимал. В панели вебмастера была «ошибка распаковки», но 200 код ответа веб сервера. Ошибку исправили, техподдержку уведомили. Они поблагодарили, но скорой поддержки http/2 не обещали, слишком слабо пока что распространен, да и в случае с поисковым роботом вряд ли нужен.
napname
11.11.2016 00:02-1Публикация заставила задуматься и соотнести некоторые моменты.
Фотон — квантовая частица.
Если для неё нет понятия времени, то она содержит в себе все возможные варианты развития событий одновременно.
Из квантовой механики вспоминается что квантовая частица имеет бесконечное множество состояний, в момент измерения можно выбрать только одно из этих состояний.
В случае с щелями получаем что фотон имеет информацию о всех возможных вариантах прохождения через них, а измерением мы отмечаем одно.
Ну и напоследок крутится в голове мысль — а не получится ли создать щелевой квантовый компьютер?
schetilin
02.07.2016 09:29+1> Как HTTP/2 сделает веб быстрее
Ура! Теперь дизайнеры смогут напихать в сайты еще больше г… на. А чтоб жизнь медом не казалась, включим предзагрузку еще пары страниц потяжелее.frig
02.07.2016 10:52Ну или можно будет перестать лепить css спрайты, лепить в кучу js, а отдавать клиенту только то, что ему нужно и вообще страница будет отдаваться целиком, со всем необходимым за один запрос, например. Что, естественно, скажется на времени ее загрузки.
freuser
03.07.2016 12:04+1>>Для защиты данных, передаваемых между клиентом и сервером, в HTTP/2 используется подход «Безопасность через непонятность» (Security by Obscurity): команды представлены в двоичном виде, применяется сжатие метаданных HTTP-заголовков.
Выставить то, что уже давно не рекомендуется как порочный подход, за инновацию — это сильное колдунство.
Тем более вроде как команд не так уж и много, угадать их, а по ним и восстановить ключи — наоборот, дыра, КМК…dmitry_ch
04.07.2016 13:07Мне кажется, что непонятность команд в протоколе никогда не была преградой. А за безопасность там отвечает TLS, если что — причем так отвечает, что при возможности и с, и без TLS поднять HTTP/2 по факту ни один браузер без него работать не хочет. Случайно ли это связано с тем, что с TLS третьей стороне труднее влезать в трафик и сделать какой-то анализ или модификацию его (прочитать referer, или вырезать рекламу) — не скажу, но… )
Revertis
03.07.2016 17:59-1Вокруг этого HTTP/2 очень много намеренного введения в заблуждение, и откровенной лжи. Я не могу допустить обычной некомпетентности в этой теме.
1. Картинка с подносом вводит в заблуждение. Все «продукты» «не поместятся» на один поднос. Не влезут в один пакет и так далее. Поднос должен быть растянут горизонтально. В реальности это будут три последовательных подноса. Ну, или все «продукты» будут поделены на куски и переданы вперемешку.
Не так красиво это уже представляется, правда ведь?
2. Далее говорится:
>>Но параллельное использование многочисленных соединений приводит к перегрузке TCP, следовательно, к несправедливой монополизации сетевых ресурсов. Браузеры, использующие многочисленные соединения для обработки дополнительных запросов, занимают львиную долю доступных сетевых ресурсов, что приводит к снижению сетевой производительности для других пользователей.
Это просто чушь собачья! Представьте 5 пользователей. Трое четверо читают эту статью на Хабре, пятый же загружает страницу с большим количеством фоток котиков. Четверо уже освободили канал, а пятый страдает из-за того, что все котики продираются по одному соединению. А ведь если бы браузер создал 3-4 дополнительных соединения, котики бы уже загрузились! А теперь, двое из первой четверки пошли писать комменты, посылают их через новые соединения, а пятый всё так же сидит и ждёт котиков. А если он спешит? Если он с трудом подключился к общей точке доступа и срочно нуждается не в котиках, а в загрузке объявления с некоторым количеством фоток? Через несколько соединений он бы скачал их быстро и освободил бы канал, но нет, тут уже HTTP/2 — «прогресс».
Кому это всё выгодно??? Только хозяевам серверов с миллионами пользователей — Гуглу и Мордокниге. Но уж точно не пользователям.
3. >> Развивающейся сети уже не хватает возможностей HTTP-технологий. Разработанные много лет назад ключевые свойства HTTP 1.1 позволяют использовать несколько неприятных лазеек, ухудшающих безопасность и производительность веб-сайтов и приложений.
Вот, опять об этом же. Только не надо завуалированно говорить «Развивающейся сети уже не хватает возможностей», надо честно говорить «наши сервера не справляются, пусть страдают пользователи, взвалим на них».
4. >> Эта возможность позволяет серверу отправлять клиенту дополнительную кэшируемую информацию, которую тот не запрашивал, но которая может понадобиться при будущих запросах. Например, если клиент запрашивает ресурс Х, который ссылается на ресурс Y, то сервер может передать Y вместе с Х, не дожидаясь от клиента дополнительного запроса.
Сейас очень много говносайтов, с неоптимизированными картинками, из-за которых титульная страница сайта весит 10-12Мб. Здравствуй паразитный трафик. Опять против пользователя.
5. >> Другие возможности HTTP/2, известные как Cache Push, позволяют с упреждением обновлять или аннулировать кэш на клиенте.
Здравствуйте новые возможности слежения за юзерами.
6. >> Какие преимущества даёт интернет-компаниям и онлайн-сервисам использование двоичных команд: и дальше целый список.
А какие преимущества HTTP/2 вообще дает самим пользователям?
7. >> В то же время, продуманны и широко распространённый механизм приоритезации потоков даст нам следующие преимущества:
Эффективное использование сетевых ресурсов. — Обман. Пользователю только хуже, он никак не управляет трафиком, не может быстро, в несколько потоков (соединений) закачать информацию.
Снижение времени доставки запросов первичного контента. — Угу, так и поверил. Грузится html и куча картинок. Всё грузится одновременно и вперемешку. Экономим миллисекунды на запросах?
Повышение скорости загрузки страниц. — Опять обман. Одно соединение — снижение эффективной скорости раз в 5.
Оптимизация передачи данных между клиентом и сервером. — Оптимизация, в смысле данных передается меньше и медленнее? О да :)
Снижение отрицательного эффекта от сетевых задержек. — Неужели ACK будет лететь быстрее? :)
8. >> Если веб-сайт содержит много медиа-контента, то клиент отправляет кучу практически одинаковых фреймов с заголовками, что увеличивает задержку и приводит к избыточному потреблению не бесконечных сетевых ресурсов.
По-моему, это проблема конкретного веб-приложения. Нахрена передавать такое количетсво Cookie? Всё остальное не может весить много. Затыкание крана пальцем вместо ремонта.
9. В таблице сравнения протоколов говорится про HTTP 1.x:
>> Один клиент-серверный запрос на одно TCP-соединение.
Кажется, у кого-то либо Альцгеймер, либо он опять пытается врать. Забыли про Keep-Alive и Http-Pipelining? Нет, кажется, именно врут.
10. >> Сетевая индустрия должна заменить устаревший HTTP 1.x другим протоколом, преимущества которого будут полезны для рядовых пользователей.
Ну где же эти «преимущества» для пользователей? Где?
11. >> С точки зрения электронной коммерции и интернет-пользователей, чем больше в сети нерелевантного контента, насыщенного мультимедиа, тем медленнее она работает.
Это вообще к чему? Значит требуется как-то решить проблему Ютуба с дебильными (нерелевантными) роликами, чтобы ускорить сеть?
12. >> HTTP/2 создавался с учётом повышения эффективности клиент-серверного обмена данными, что позволяет бизнесменам увеличить охват своих сегментов рынка, а пользователям — быстрее получить доступ к качественному контенту. Помимо прочего, сегодня веб ситуативен как никогда ранее.
Просто маркетинговый буллшит какой-то.
Дальше тоже только маркетинговый буллшит в всё.
khim
03.07.2016 20:03+1Вокруг этого HTTP/2 очень много намеренного введения в заблуждение, и откровенной лжи. Я не могу допустить обычной некомпетентности в этой теме.
Вместо этого вы добавите свою?
Это просто чушь собачья! Представьте 5 пользователей. Трое четверо читают эту статью на Хабре, пятый же загружает страницу с большим количеством фоток котиков. Четверо уже освободили канал, а пятый страдает из-за того, что все котики продираются по одному соединению. А ведь если бы браузер создал 3-4 дополнительных соединения, котики бы уже загрузились!
Ага. За счёт того, что те трое, которые читают эту статью сидели и ждали бы у моря погоды.
Чудес ведь не бывает: TCP так устроен, что он занимает всю ширину канала, которая есть! Так что если «котики» грузятся быстрее, то что-то другое грузится медленнее. Вопрос: что? Правильно — как раз вот те сайты, которые не генерят много траффика и не включают в себя тысячи картинок котиков и страдают.
Кому это всё выгодно??? Только хозяевам серверов с миллионами пользователей — Гуглу и Мордокниге. Но уж точно не пользователям.
Как раз наоборот: Гугл и Мордокнига тут скорее в потерпевших окажутся. Другие вещи в HTTP/2 идут им на пользу, но вот это мультиплексирование — как раз нет. С HTTP/2 выигрывают более лёгкие сайты, а не те, которые могут поднять 100500 серверов.
«Развивающейся сети уже не хватает возможностей», надо честно говорить «наши сервера не справляются, пусть страдают пользователи, взвалим на них»
Вот только в вашей теории заговора есть один пробел: как раз сервера Гугла со всем справляются, выигрыш собственно для самого Гугла меньше чем для других сайтов у которых, действительно, может не хватать серверов.
Сейас очень много говносайтов, с неоптимизированными картинками, из-за которых титульная страница сайта весит 10-12Мб. Здравствуй паразитный трафик.
И, как уже говорилось выше, именно эти сайты и страдают больше всего от HTTP/2 и именно они могут уменьшить количество «паразитного трафика» за счёт отказа от разных трюков (типа склеивания 100500 иконок в одну картинку). Захотят ли они это сделать — это уже другой вопрос.
А какие преимущества HTTP/2 вообще дает самим пользователям?
Быстрее работающие сайты и меньше счёт за траффик — не считается?
Тот факт, что вы нашли в статье некоторое количество неточностей не означает что вашу чушь все должны принимать за чистую монету. Весь пост, в общем, посвящён одной-единственной «проблеме»: HTTP/2 не позволяет мне «урвать» больше от канала, чем его достаётся другим. Ата-та, ах какой-нехороший HTTP/2!dmitry_ch
04.07.2016 13:12Быстрее работающие сайты и меньше счёт за траффик — не считается?
Больший расход батарей мобильных устройств за счет (по факту повсеместного) использования шифрования в http/2 добавить в «якобы плюсы юзерам» не забудьте ))
Не говоря что TLS несколько менее устойчив к качеству канала, а возня с сертификатами добавила «радости» большому числу админов сайтов.
Это я к тому, что и плюсы, и минусы есть, и надо это понимать.
mixailflash
Изменения по количеству запросов показано, а вот интересно изменение по размеру самого трафика присутствует и насколько оно значительно если есть?
khim
Трафик тоже экономится, но не так сильно — да и не так это важно: в оптику можно хоть терабит засунуть, а задержки никуда не денешь, это чисто физическое ограничение, так что борьба ведётся в основном с ними.
HatsuneAkeno
К сожалению, еще много районов с низко-скоростным интернетом, это оптимизация поможет. + забывая об оптимизации мы сами пришли к тому, что нам не хватает пропускной способности каналов связи даже с оптикой в некоторых районах.
khim
Это-то всё понятно. Но низкоскоростной и дорогой интернет — это временное явление. Были бы деньги — и всё поправимо. А задержки — вещь абсолютная, как смерть. Через скорость света не перепрыгнешь. Потому борьба с ними — всё равно важнее, как ни крути.