HTTP в сравнении с HTTPS и SEO


Оглавление (нажмите, чтобы открыть):

Чем отличается https от http?

Мы предлагаем:

Новые тарифы хостинга — «Минимальный» и «Безлимитный»

— Всего 60 рублей за ГОД;

— Идеально подойдет небольшим сайтам;

— Поддержка популярных CMS

190 рублей в месяц;

— Количество сайтов — не ограничено;

— Дисковое пространство — не ограничено;

— Базы данных — не ограничено;

Содержание

Чем отличаются протоколы — разница в безопасности

Буквы HTTP в начале адресной строки означают, что клиент и сервер обмениваются данными по прикладному протоколу – hypertext transfer protocol. Это стандартный протокол для обмена любыми данными в Интернете. Внешне аббревиатура HTTP ничем не выделяется – она такого же черного цвета, что и остальная часть адресной строки. Либо незащищенный протокол вообще не указывается в адресной строке браузера.

Если в адресной строке вместо черной надписи HTTPS появилась зеленая HTTPS, значит, данные передаются по тому же HTTP протоколу, но с дополнительной надстройкой, обеспечивающей криптографическую защиту (отсюда и буква «s», означающая «security», т.е. безопасность). Передаваемые данные шифруются с помощью протоколов SSL и TLS, которые невозможно расшифровать без ключа. Узнать защищенное соединение просто – помимо зеленого цвета букв, в адресной строке появляется изображение закрытого замка и надпись «Надежный».

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

Основные преимущества и недостатки HTTPS

Помимо собственно защиты данных, HTTPS выполняет дополнительную задачу – увеличивает приток посетителей на сайт. Еще в 2014 г. компания Google объявила, что будет повышать выдачу в поисковике сайтов, использующих https, и многие сайты купили цифровой сертификат для шифрования информации. К сожалению, из-за разницы в принципах работы поисковых систем Яндекс и Гугл при замене HTTP на HTTPS у некоторых ресурсов наблюдалась просадка позиций из-за некорректно выполненного переноса.

Приобретение уникального цифрового сертификата увеличит расходы на содержание сайта – в среднем на 10-100 долларов в год, в зависимости от типа выбранного сертификата. Также стоит учесть, что на шифрование данных расходуется часть мощности сервера, поэтому сайт с HTTPS может работать несколько медленнее. Для ускорения скорости загрузки сайта стоит оптимизировать изображения и настроить кеширование.

Однако новые клиенты и посетители, который придут на ваш сайт с HTTPS благодаря повышению его позиции при ранжировании, компенсируют эти небольшие неудобства.

Чем HTTPS лучше HTTP?

Возможно, вы задумывались о переходе с HTTP к HTTPS, но не находили полного разъяснения, для чего это нужно и чем HTTPS лучше. В данной статье мы расскажем о всех преимуществах и различиях данного протокола и его расширенной версии.

Предисловие

Начнем с разъяснения обоих типов соединений и покажем, что представляет из себя каждый из них. HTTP — это аббревиатура от английского HyperText Transfer Protocol — «протокол передачи гипертекста». Изначально он разрабатывался для передачи гипертекстовых документов в формате HTML. На данный момент он используется для передачи произвольных данных. HTTP обеспечивает транспорт между клиентом и сервером. Клиентом может быть ваш браузер, а сервером — машина, на которой установлен запрашиваемый сайт. При наборе адреса сайта отправляется запрос на соединение с сервером. Сервер в свою очередь ожидает запроса, выполняет определенные действия при запросе и возвращает клиенту результат.

Посредством данного протокола на сервер отправляются все введенные вами данные. Например, логин и пароль в открытом виде, номера кредитных карт и все остальное. Одним словом, все данные, которые вы вводите в любую форму на каком-то сайте, который использует HTTP протокол.

Как вы уже могли догадаться, ключевой фактор использования HTTPS – это безопасность. Он максимально предотвращает хищение ваших данных на пути от вашего устройства к серверу. Теперь ознакомим вас с несколькими пунктами, объясняющими из-за чего вам стоит перейти с HTTP на HTTPS.

1. Забота о ваших клиентах

Основной пункт перехода с HTTP на HTTPS — его преимущество в защите и способности предотвращения хищения данных на пути от клиента к серверу. Ваши клиенты должны быть в безопасности, чтобы их логины и пароли никто не смог перехватить по пути. А если у вас на сайте есть платежная форма, которая требует ввода платежных данных клиента, то вы 100% должны использовать HTTPS и минимизировать риски хищения платежных данных ваших клиентов.

Для обычного сайта блога, где регистрация нужна исключительно для возможности комментирования, вы можете подумать: «Ну украдут данные от учетной записи пользователя, ну и что? Удалят комментарии?» Не все так однозначно. Во-первых, сам факт несанкционированного доступа от имени вашего пользователя — уже плохой знак. Во-вторых, не забывайте, что большая часть людей (особенно в возрасте от 40 лет) используют идентичные данные на разных ресурсах и даже в платежных сервисах. Таким образом, невинный логин/пароль от учетной записи в вашем блоге, может сильно навредить пользователю. Уважаете вашу аудиторию? Заботьтесь о ней!

2. Принуждения Рекомендации Google

С 15 января 2020 года, Google ввел в новую версию браузера Google Chrome предупреждающий красный значок возле адресной строки, который будет информировать пользователей о том, что ваш сайт работает не по защищенному протоколу. Если раньше строка браузера просто была «серой», то сейчас табличка имеет ярко-красный вид, который привлекает внимание и осведомляет пользователя о незащищенном соединении с вашим сайтом. Чему это мешает? Во-первых, вашим продажам, если вы интернет магазин. Будет создавать ощущение, что ваш сайт «не серьезный» и на нем не стоит оставлять реальные персональные данные. А многие люди вовсе будут бояться вашего сайта, так как они где-то наслышались о хакерах, взломах и кражах личных данных. Они попросту уйдут к вашим конкурентам, где соединение защищено.

Еще одно нововведение Google, которым они хотят убедить всех перейти на HTTPS, заключается в том, что Google также начал в ранжировании сайтов учитывать тип подключения. Если ваш сайт и сайт конкурента имеют идентичное качество контента, но у конкурента сайт работает через HTTPS, то при выдаче результатов поиска, сайт конкурента будет в приоритете.

3. HTTPS работает быстрее HTTP

Кроме защищенности, HTTPS также обеспечивает более быстрый транспорт. Очень часто соединение к одному и тому же сервису через HTTP и HTTPS имеет разницу в скорости в 2-3 раза. Тем самым, HTTPS также уменьшит скорость загрузки вашего сайта, что тоже очень сильно может влиять на конверсию. Вы можете проверить данное убеждение через сервис для сравнения скорости протоколов HTTP и HTTPS.

4. Имидж вашей компании

Как вы бы отнеслись к люксовой компании, которая продает одеяло за $1,500 и не имеет SSL сертификат за $10-100, который бы обеспечивал безопасность и сохранность данных своих клиентов? Подобные мелочи отличают хорошую компанию от не очень хорошей. Вашим вниманием к мелочам, вашей заботой и реальным желанием обезопасить своих посетителей и клиентов, вы сможете добиться большего уважения в ответ.

Представьте, вы зашли на официальный сайт топовых брендов, а браузер уведомляет вас, что соединение не безопасное. Ваши первые мысли? Скорее всего они будут смешанные. Если к бренду у вас большое доверие, вы можете подумать, что у вас вирус или вы попали не туда. Или же вы трезво оцените ситуацию и поймете, что компания в последнюю очередь думает о вас.. Печально. А что отличает вас от топовых брендов? Вы должны стараться быть лучше их, чтобы встать с ними в ряд или же вовсе обойти их!

Как https влияет на SEO продвижение сайта

Влияет ли использование HTTPS на SEO

В середине 2014 года Google объявил о появлении нового фактора, влияющего на позиции веб-сайта в поисковой выдаче – использование протокола HTTPS.

Было заявлено, что если использовать протокол HTTPS, для сайта будут доступны существенные бонусы ранжирования в виде преимущества перед теми, кто его не использует. При этом в официальном объявлении делался упор на заботу Google о безопасности пользователей во время посещения интернета.

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

В этой статье мы попытаемся разобраться, важен ли вид протокола передачи данных (HTTP или HTTPS) для SEO–продвижения.

Что дает использование HTTPS для SEO

Google призывает впредь использовать протокол HTTPS для сайтов, которые создаются, а также переносить на него старые ресурсы.

При этом сообщается, что после переноса сайта на HTTPS его позиции могут временно упасть, потому что ботам поисковиков придется его переиндексировать.

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

Но это лишь обещания, которые имеют мало общего с существующим положением дел.

Рассмотрим данные по изменению видимости некоторых веб-ресурсов, использующих протокол HTTPS, спустя полгода после внедрения нового алгоритма:

Как видите, прирост позиций действительно наблюдается, но он настолько незначительный (максимум 5%), что эти улучшения позиций можно списать как на влияние HTTPS на продвижение сайтов, так и на вполне естественные результаты (ведь все это время работы по продвижению скорее всего не прекращались).

Получается, то какой протокол использует сайт (HTTP или HTTPS) для SEO–продвижения не особо важно. Хотя однозначных выводов по этому поводу сделать нельзя. Ведь это лишь суждения, которые базируются на нашем собственном опыте и примерах случайных выборок сайтов.

Положительные моменты от использования HTTPS для SEO

  1. Повышение доверия посетителей. Если логически подумать, то использование протокола HTTPS для сайта все же может улучшить его позиции в результатах поиска путем влияния на поведенческие факторы. Ведь разница между HTTPS и HTTP в первую очередь выражается высоким уровнем доверия к веб-сайтам, использующим более безопасный из этих двух протоколов.

В результате, если использовать протокол HTTPS для сайта, можно существенно снизить количество отказов и тем самым косвенно повлиять на его продвижение. Также это поможет увеличить конверсию.

Доверие со стороны поисковых систем. В любом случае, HTTPS – один из факторов ранжирования по официальным данным. Поэтому значимость его будет расти со временем. Озадачиться переходом сейчас или позже, решать Вам. Но сделать это рано или поздно придется.

Отрицательные стороны использования протокола HTTPS

В случае с новыми сайтами, которые сразу же разрабатываются с поддержкой HTTPS, для SEO не будет проблем. Но для тех, кто будет переделывать уже существующие веб-ресурсы, могут быть заметны следующие моменты:

  1. Учитывая, что во всех адресах страниц произойдет замена http на https, для SEO это на некоторое время обернется настоящей катастрофой – поначалу поисковики будут воспринимать измененный веб-ресурс как совершенно новый со всеми вытекающими из этого последствиями. И до того момента, как произойдет «склейка» старого и нового сайта, последнему не стоит рассчитывать на сильный рост позиций.
  2. После введения нового протокола передачи данных скорость работы сайта снизится. Правда, не слишком существенно – добавится 10 «лишних» КБ для каждой сессии. А это всего 2% задержки.
  3. Затраты на оплату SSL-сертификатов могут составлять от 13 до 1000$, что для некоторых является довольно существенной дополнительной финансовой нагрузкой.


Так что же выбрать: HTTPS или HTTP?

Учитывая, что влияние HTTPS на продвижение сайтов на сегодняшний день не до конца определено, можете не бежать после прочтения статьи переносить уже существующие веб-сайты на новый протокол. Но если что, мы это уже сделали 🙂

И в то же время, если выбор осуществляется на этапе разработки сайта, то логичнее будет остановиться на безопасном и современном протоколе передачи данных.

Не забудьте высказать свое мнение по теме статьи чуть ниже в комментариях!

Как HTTPs влияет на SEO и нужно ли это контентным сайтам

HTTP -протокол повсеместно используется в сети для получения данных с сайтов. Сообщения, переданные с помощью HTTP -протокола являются обычной текстовой информацией, что делает её уязвимой. В первую очередь об этом стоит беспокоиться ресурсам, оперирующими персональной информацией пользователей, например, номерами кредитных карт, логинами-паролями и прочее. Для защиты от атак, основанных на прослушивании и подмене контента, был создан защищенный HTTP s-протокол, по сути являющийся обычным HTTP , но работающий через шифрованные транспортные механизмы SSL и TLS .

Но что, если ваш сайт не является сайтом платежной системы, банка или хостинга? Стоит ли заморачиваться переходом на HTTP s? Основной аргумент, из-за которого многие до сих пор не перешли на защищенный протокол — “у нас просто контент, мы не опериреуем персональными данными”. На этом моменте рассмотрим подробней, как злоумышленники монетизируют ваши сайты и ваших пользователей, а также подумаем, как это может влиять на SEO .

Все мы знаем, что сейчас происходит бум мобильных технологий и мобильного интернета. Также растет потребность в бесперебойном доступе к Wi-Fi. Если раньше основными потребностями по Маслоу были “поесть и поспать”, то сейчас в пирамиде базовыми являются “уровень заряда батареи” и “наличие wi-fi”… Каждый уважающий себя локальный бизнес обеспечивает пользователей бесплатным Wi-Fi, это различные кафе и рестораны, гостиницы и хостелы, магазины и торговые центры, любые общественные места.

Вы можете полностью доверять гостинице, в которой проживаете, но при этом вы не знаете её технического администратора и какие у него отношения с босом. Ведь все-таки кто-то просит ваших друзей от вашего имени в соцсетях срочно выслать денег на мобильную связь, лечение или другие нужды. Даже если вы раньше с этим ни разу не сталкивались, при постоянном использовании дырявой системы вероятность встречи с проблемами повышается. Использование защищенного HTTP s-протокола в данном случае решает проблему. Но вернемся к вопросу, когда у нас просто контентный проект или интернет-магазин без личного кабинета.

Если текст передается через провайдера в прямом виде, то ничего не стоит модифицировать его, например, встроив свой скрипт или фрейм, добавляя дополнительный функционал. Билайн, например, так добавляет свою брендовую кнопочку (даже на сайте конкурентов – МТС ).

Также одно время они добавляли в браузер пользователей форму поиска от mail.ru, красиво встраивая её в сайт. Пользуясь Wi-Fi в метро вы обязательно увидите рекламу какого-нибудь такси или банка, причем на вполне себе авторитетном сайте, который никогда в жизни не размещал рекламных баннеров. Здесь кто-то обязательно подумает, что Apple рекомендует GetTaxi. Для GetTaxi это плюс, для Apple не очень.

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

Иногда эта реклама закрывает весь нужный вам контент.

Также, читая seo-статьи в хостеле или антикафе, вы определенно столкнетесь с тем, что вас захотят сделать более финансово-успешным.

Многие бесплатные Wi-Fi-точки в вашем городе созданы не совсем для того, чтобы вы постоянно имели доступ в интернет. Это специальные проекты, имеющие свою модель монетизации через рекламу. И вот их тарифы на инбраузерные баннеры. И только на странице для рекламодателей честно описаны цели проекта — “инновационная площадка интернет-рекламы”.

Вы не видите баннеров на своем сайте, потому как заходите на него со своего рабочего компьютера. А потестируйте отображение с других устройств и провайдеров. Если у вас сайт гостиницы или пиццерии, то наверняка наибольший процент пользователей приходит с мобильных устройств, и наверняка они используют бесплатный городской Wi-Fi, чтобы узнать ваш адрес или телефон, либо хотят сделать заказ. Даже если у вас простой блог, то часть аудитории все равно читает его с мобильника/сотового.

Наконец-то про SEO

Как же HTTP s может влиять на SEO ? Напрямую пока никак, но через поведенческие факторы влияет. Основной из них это dwell-time, использующийся поисковиками в различных ранжирующих и антиспам-алгоритмах. Реклама на сайте очень сильно портит dwell-time, что снижает, с одной стороны, авторитет сайта, с другой стороны портит ПФ. И то и другое плохо для SEO . Чем больший процент аудитории у вас использует бесплатный Wi-Fi, тем хуже для вашего незащищенного HTTP -сайта. А реклама через Wi-Fi сейчас только развивается, её ещё используют не все.

В основном, проблема конечно касается мобильной выдачи. И мы её не видим, так как не отслеживаем позиции и видимость своих сайтов в мобильном поиске (пока нет общедоступных инструментов). Но как только у нас появятся метрики, HTTP s станет намного популярней.

Сейчас вы можете зайти в свою систему статистики и сравнить для сайта два сегмента – мобильный и десктопный трафик. Посмотрите на количество отказов и время проведенное на сайте, здесь вы быстрей всего поймете, насколько критична ваша проблема и как срочно надо переходить на HTTP s. Лучше эти вопросы решить пораньше ваших конкурентов.

Что выбрать HTTPS или HTTP для сайта. Как влияет на СЕО ваш выбор.

Уже давно еще в 2014 году Гугл заявил что защита в интернете прежде всего, и от протокола зависит индексация сайта – появился протокол HTTPS более защищенный для пользователей.

Гугл обещал приоритет тем кто использует данный протокол.

Но года прошли и всем интересно что все же стало с теми кто последовал совету Гугл.

Использование нового протокола влияет на СЕО.

Гугл навязывал это веяние для свежесобранных и перенесенных сайтов.

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

Но как и везде это только слова.

Так как проанализировав перенесенные ресурсы на новый протокол , они в среднем дали 3% прироста по сравнению с обычным протоколом, т.е. такого чтобы супер не замечено.

Вывод можно сделать, что для обычного сайта протокол HTTPS или HTTP не имеет никакого значения. Но все же есть некие отличия:

Плюсы нового протокола :

1. Более лояльные посетители. Т.к. новый протокол более защищен и не опасен для посетителей, что не сказать про прошлого брата, где есть куча шансов нацеплять чего попало. Что даст прирост интернет магазину к примеру.

2. Поисковики тоже таким ресурсам доверяют больше. Просто значение сейчас мизерное, но в последствии будет расти. А значит вы все равно перейдете, все таки тренд, который станет нормой.

Минусы тоже есть:

Если новый ресурс сразу разрабатывается на этом протоколе, то норма, но если перенесем старый, то:

1. Изменение адреса на всех страницах, для поисковиков потерей ресурса из индекса, до тех пор пока склейка не завершится, но это время, а значит деньги.

2. Новый протокол более емкий, поэтому скорость работы ниже чем при старом, примерно на 3%

3. Но самый наверно существенный минус это SSL сертификат стоит от 12 до 1000 баксов, что очень заметно для простых пользователей интернета.

Все таки на чем остановится

Мое мнение очень субъективно, т.к. я считаю что для сайта где нужно доверие, то HTTPS, т.к. все таки на таких сайтах чаще всего предлагается оплата и все в этом духе, но чтобы обезопасить пользователя и сделать ему комфортную обстановку. Для остальных же я думаю можно оставить HTTP , т.к. на данном этапе нет ничего существенного, что препятствует продвижению данного протокола .

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

Протокол HTTPS и SEO-оптимизация

Достаточно много современных сайтов сейчас обязательно нужно переводить на новый протокол HTTPS. По сути, это стандартный HTTP, который поддерживает шифрование и обеспечивает защиту в данных. Это стало одним из современных факторов ранжирования для двух крупнейших поисковиков.

Соединение через HTTPS обеспечивает прямое общение сервера с единственным адресатом – сайтом, не допускает в канал передачи данных третьих лиц, шифрует все коммуникации, включая ссылки. Так как этот фактор относительно новый, многие владельцы сайтов еще не разобрались во всех тонкостях. В частности, самый распространенный вопрос – как сообщить поисковикам (и, в частности, Яндексу), что сайт уже работает с поддержкой шифрования.

Для объяснения воспользуемся официальной информацией от представителей поисковой системы.

Особенности переезда на HTTPS

После перехода на HTTPS для поисковой системы ничего не меняется: сайт по факту тот же, его название и наполнение не меняется. Но на самом деле робот воспринимает сайт, который передает данные по 2-м разным протоколам, как два отдельных ресурса.

В связи с этим, переходя на новый протокол, можно ощутить спад посещаемости, изменение количества проиндексированных страниц и позиций в поисковой выдаче. С точки зрения поисковика, смена протокола представляет собой объединение сайтов типа http://site.ru и https://site.ru в группу зеркал, либо же смену главного зеркала (если до этого они были распознаны как два зеркала друг для друга).

Чтобы сделать сайты зеркалами и объединить их в группу, нужен одинаковый контент на всех версиях. Есть несколько советов и правил по корректному перемещению ресурса на домен с протоколом HTTPS:

Подготовка и переезд сайта на https

1. Подправить код сайта до перехода на новый сертификат – иначе есть риск возникновения технических проблем: нужно сменить ссылки внутренней перелинковки с абсолютных на относительные вне зависимости от используемого протокола.

  • Относительные ссылки вне зависимости от домена: https://сайт.ru/about/ — абсолютная, /about/ — относительная.
  • Относительные ссылки вне зависимости от протокола: https://сайт.ru/about/ — абсолютная, //сайт.ru/about/ — относительная.

Важно применять внутренние ссылки второго типа, если исключается название протокола. Если поступать так, не имеет значения, на каком протоколе сайт: он в любом случае будет ссылаться на страницы с аналогичным протоколом.

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

2. Так же необходимо исправить вложения медиа-контента. Для начала следует проверить, по какому протоколу запрашивается медиа-контент и перевести его на относительные адреса. Если речь идет о контенте, загружаемом с внешних ресурсов (например, изображениях), следует проследить, чтобы эти источники поддерживали HTTPS.


3. Следующий шаг – корректировка подключений внешних скриптов. В них также важно применять относительные урлы. Подготовительные работы сложные, а у больших проектов они занимают максимальную часть времени и бюджета, выделяемых на перенос сайта. К примеру, для Query, вместо:

4. Необходимо убедиться в отсутствие перелинковки между версиями сайта с https и http версиями сайтов. Это правило не действует, если ресурс с http и раннее ссылался на версию сайта с https — в этом случае только https не должен содержать ссылок на http версию.

5. Необходимо купить или получить и настроить официальный сертификат безопасности в авторизированном центре сертификации.

6. В файле sitemap на https версии заменить все ссылки на версию сайта с https;

7. На обоих ресурсах (http, https) определить нужное главное зеркало, используя директиву Host в robots.txt.

8. Дать знать поисковому роботу о том, что ресурс уже доступен по протоколу HTTPS, добавив его в список своих сайтов в Вебмастере или указав о том, что сайт «переезжает на https. (Процесс определения главного зеркала может занять несколько недель. Проконтролировать результат можно в Яндекс.Вебмастере.

9. ПОСЛЕ склейки, следует настроить редиректы со страниц второстепенного зеркала на главное. На период склейки зеркал необходимо оставить ресурс доступным для поискового робота по адресам HTTPS и HTTP.

10. Необходимо выполнить проверку доступности файла robots.txt на домене http без редиректов. Поисковые системы должны иметь возможность обращаться к этому файла в дальнейшем для определения главного зеркала в группе сайтов.

11. Необходимо выполнить проверку для редиректов без определения протокола или с его неверным определением. Таким образом любая страница сайта в любой момент времени при запросе её по протоколу http должна перенаправлять пользователя на https протокол. Это касается в том числе новых страниц сайта https. К слову, процесс перехода HTTPS для поисковой системы Google идентичный.

Установка сертификата

После подготовительных работ наступает время выбора и покупки нужного SSL-сертификата, подходящего по специфике ресурса. Отличают

  • стандартные сертификаты – для юридических и физических лиц, предназначенные для одного домена, оформление занимает несколько минут;
  • EV (Extended Validation)
    – сертификаты с расширенной проверкой: для покупки нужно предоставить свидетельство о госрегистрации компании, данные для проверочных звонков. Такой сертификат позволяет получить зеленую адресную строку в браузере;
  • Wildcard
    – сертификат для всех поддоменов одного и того же домена. Важен для сайтов, у которых, в частности, много региональных подразделений с адресами на поддоменах;
  • с IDN поддержкой
    – для доменов с кириллическими названиями.

Приобретенный сертификат устанавливают на сервере. У большинства хостеров эта возможность предоставлена в виде набора удобных функций. Это дело пары минут, но если разобраться не удается – можно пообщаться с техподдержкой или обратиться к специалисту. Финальный этап – проверка доступности ресурса по новому протоколу. Он должен быть доступен по обоим адресам: http:// и https://.

Что это дает в плане SEO?

Внедрение HTTPS связано с рисками и сложностями, которые сопоставимы с переездом авторитетного сайта на новый домен. Однако если через сайт проводят платежные операции, если он хранит данные пользовательских аккаунтов – наличие HTTPS уже является обязательным фактором оптимизации. Внедряя HTTPS, следует учитывать его влияние на сайт. Одно из самых главных – это снижение скорости загрузки, так как безопасное соединение требует дополнительных коммуникаций между серверами. Это отразится на громоздких ресурсах, которые и до этого загружались не быстро. Учитывая, что скорость загрузки страниц – еще один ключевой фактор ранжирования, придется проводить дополнительную оптимизацию. С другой стороны, загрузка ресурса по HTTPS требует всего лишь 10 дополнительных Кб на одну сессию.

Мастер Йода рекомендует:  10 проверенных способов заработка в Интернете без вложений

SSL-сертификаты – достаточно дорогое удовольствие, и это тоже надо учитывать. Средняя цена в год колеблется в пределах 1-80 тыс. руб. Такая разница объясняется разными размерами ключа шифрования, наличием или отсутствием поддержки интернационализированных доменов и другими факторами. Переход на HTTPS уже точно является обязательным для коммерческих ресурсов и сайтов, хранящих пользовательские данные. Без наличия сертификата безопасности возможна пессимизация ресурса. Чтобы осуществить переход грамотно, с минимумом потерь и эффективным результатом, лучше доверять процесс специалистам.

Материал устарел и находится в процессе обновления.

HTTPS и SSL для SEO: преимущества, недостатки, проблемы и решение.

Только ленивый не писал о https протоколе, его преимуществах и недостатках. Если вы не знаете что это, или не уверены нужно ли вам использовать защищенный протокол на своем сайте — читаем материал.

Что такое HTTPS?

HTTPS (англ. HyperText Transfer Protocol Secure) — это расширение протокола HTTP, которое поддерживает шифрование. Информация, которая передается по этому протоколу «упаковывается» в криптографический протокол SSL или TLS. Как результат — все данные, которые есть на вашем сайте будут защищены от стороннего вмешательства. В блоге Яндекса есть наглядная информация об отличиях обычного протокола и зашифрованного:

В этой же статье написано о том, как работает обмен данных на SSL и особенности распространения защищенных соединений в сети интернет.

Преимущества HTTPS для SEO

HTTPS вошел в жизнь сеошника довольно давно. Еще в 2014 году Google рекомендовал всем сайтам перейти на защищенное соединение. Он сделал это сам и сподвиг другие сайты использовать более безопасное соединение. После этого начались дискуссии о необходимости использования зашифрованного соединения, целесообразности и выгоде от перехода на SSL. Осенью 2014 года Google включил HTTPS в алгоритм ранжирования сайтов и с этого момента HTTPS неотрывно связан с SEO и комплексным продвижением сайта.

В 2020 году уже не стоит вопрос о необходимости перехода на HTTPS, так как наличие SSL сертификата это «must have» для каждого сайта или проекта. Не важно, банк вы или интернет-магазин, блог о рыбалке или сайт правительства — защита данных вашего сайта и персональных данных пользователей обязательное условие в современном интернете.

Среди явных преимуществ защищенного соединения можно выделить:

  • целостность данных и невозможность стороннего вмешательства;
  • идентификация вашего домена. Некоторые сертификаты позволяют получить такой вид адресной строки:
  • при прочих равных, Google отдает предпочтение сайту, который работает на HTTPS. Вот что по этому поводу написано в справке:
  • точность данных статистики:

Малоизвестный факт. Если сайт А не использует защищенный протокол [HTTPS], а сайт Б, который использует и при этом ссылается на А, такой трафик будет считаться прямым, а не реферальным. Об отличиях трафика читаем тут.

  • повышенное доверие пользователей к сайту.

Также, совсем недавно Google объявил, что с января 2020 года будет отмечать сайты, использующие HTTP как небезопасные.

Недостатки HTTPS для SEO

Несмотря на наличие явных преимуществ, у многих владельцев сайтов может возникнуть ряд проблем в использовании SSL на своих сайтах:

  • Цена вопроса. SSL сертификаты есть как бесплатные, так и платные. При этом цена может существенно различаться: от 300 грн/год до 12000 грн/год. Все зависит от уровня сертификата и количества доменов, на которые приобретается лицензия. Также, можно использовать бесплатные сертификаты, с технической точки зрения они ничем не отличаются, да и нет доказательств того, что Google ранжирует платные сертификаты выше чем бесплатные.
  • Технические сложности. При переходе с HTTP на HTTPS меняется адрес всех страниц сайта. Соответственно, нужно настроить не только редиректы с одного протокола на другой, но и менять урлы на всех страницах сайтов [если вы используете абсолютные ссылки на сайте]. Кроме того, требуются дополнительные настройки в вебмастере Яндекса и Search Console.
  • Посещаемость сайта снизиться. На первых порах, в течении недель или месяца после переезда, на сайте будет наблюдаться спад трафика из органики. Это связано в первую очередь с обработкой поисковыми системами сайта на с https://. После того, как сайт с новым протоколом обработает Google, позиции восстановятся и даже вырастут [не забываем: кроме SSL сертификата на сайте не должно быть технических ошибок и обязательно должен присутствовать интересный контент].

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

Как получить HTTPS для сайта

Где взять SSL сертификат? В интернете полно компаний, которые предлагают купить у них SSL сертификат и нередко — за дополнительную плату перевести ваш сайт на защищенный протокол. Но не спишите выкладывать свои деньги первому встречному. Есть как минимум три варианта получения сертификата.

1. Самоподписной SSL сертификат

Самоподписной сертификат(self-signed) можно сгенерировать прямо на своем сервере. В популярных панелях управления хостингом (Cpanel, ISPmanager, Directadmin) эта опция доступна по умолчанию, поэтому не будем углубляться в техническую сторону вопроса. Плюсы: бесплатность. Минусы: непроверенная цифровая подпись такого сертификата будет вызывать ошибки в браузере:

2. Бесплатный SSL сертификат с подписью

Можно легко получить бесплатный SSL сертификат, который не будет выдавать ошибки в браузерах и подтверждать ваше право на владение доменом. Для этого нужно обратиться на сайты, которые позволяют получить сертификат бесплатно. В интернете полно материалов о том, как получить SSL сертификат. Могу порекомендовать 3 самых популярных центра регистрации:

  • Let’s Encrypt. Один из самых распространенных и популярных сервисов, который поддерживают Google, HP, Mozilla, Facebook и многие другие. Наш сайт тоже использует сертификат Let’s Encrypt. Официальный сайт: letsencrypt.org
  • StartSSL. Еще один сервис бесплатных сертификатов. Бесплатное продление, так же как и в Let’s Encrypt, но есть подвох — бесплатный ssl сертификат StartSSL нельзя использовать в коммерческих целях. Официальный сайт: >www.startssl.com
  • WoSign. Бесплатный сертификат можно получить и тут. Он выдается до 20 доменов и длительность его работы — 3 года. Отличие платных сертификатов от бесплатных — в подписи эмитента. Бесплатный сертификат от WoSign будет подписан от имени WoSign CA Free SSL Certificate G2, в то время как платный — WoSign Class 1 DV Server CA G2.

3. Платный SSL сертификат

Платный сертификат многие считают более надежным и трастовым решением. Покупка сертификата осуществляется каждый год, цены и виды сертификатов тоже существенно отличаются. Центров сертификации существует достаточно много, вот перечень самых популярных: Comodo, Symantec [самая крупная компания, владеет Thawte, Verisgin и Geotrust], Trustwave, Norton и другие.

По типу валидации можно купить такие сертификаты:

  1. Сертификаты, которые подтверждают только доменное имя (Domain Validation — DV).
  2. Сертификаты, которые подтверждают домен и организацию (Organization Validation — OV).
  3. Сертификаты, с расширенной проверкой (Extendet Validation — EV).

В Украине, один из центров сертификации предлагает следующий уровень цен:


В том же Comodo, цены на сертификаты начинаются от €76.95, при этом есть возможность получить бесплатный сертификат Comodo на 90 дней.

Еще на одном сайте есть возможность приобрести Comodo Positive SSL за 234 грн, GeoTrust QuickSSL Premium за 1950 грн., а Thawte SSL123 за 780 грн. При этом, самый простой сертификат Symantec обойдется в 9100 грн.

Использовать платный или бесплатный сертификат — это только ваш выбор. Самое важное — вы получите HTTPS соединение, которое имеет ряд преимуществ в SEO.

Как перевести сайт на HTTPS и не потерять в трафике

Чтобы не потерять в трафике, нужно следовать рекомендациям Google по использованию HTTPS. Скорость перехода зависит от размера сайта, а потому — нужно запастись терпением. Чтобы ускорить процесс перехода на новый протокол, нужно обратить внимание на ряд действий, которые сохранят трафик вашего сайта:

  • Сайт должен быть доступен по http:// и https://. Зайдите на сайт по разным урлам.
  • Настройте постраничный 301 редирект на HTTPS.
  • В Яндекс.Вебмастере в разделе «Настройка индексирования» — «Главное зеркало» главным зеркалом установите https. Сайт по новому протоколу нужно добавить и в Search Console Google.
  • В robots.txt ссылки на Host и Sitemap укажите с HTTPS.
  • Проверьте XML-карту, чтобы в ней формировались верные URL адреса с протоколом HTTPS.
  • В абсолютных ссылках на сайте заменить HTTP на HTTPS.
  • Проверить rel=canonical. У страниц должен быть указан верный протокол.
  • Проверить вызов скриптов, картинок, стилей и других элементов — чтобы они работали через HTTPS.
  • На сервере настроить или включить HSTS — для ускорения загрузки сайта с шифрованием.
  • Проверьте код ответа сервера на HTTPS страницах [200 и 404].

Данные действия помогут существенно сократить время перехода сайта на защищенный протокол. Кроме того, проверив сайт по этим пунктам, вы сможете найти и исправить несколько технических ошибок, которые помогут продвижению вашего сайта.

Как HTTP/2 сделает веб быстрее

Протокол передачи гипертекста (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 — методы, коды статусов и большинство заголовков остаются теми же. Мы лишь переработали его с точки зрения повышения эффективности использования, чтобы он был более щадящим по отношению к интернету…»

Важно отметить, что новая версия 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. В качестве аналогии можно привести сравнение вакуумного поезда с обычным: отсутствие трения и сопротивления воздуха позволяет транспортному средству перемещаться быстрее, брать больше пассажиров и эффективнее использовать доступные каналы без установки более мощных двигателей. Также снижается вес поезда и улучшается его аэродинамика.

Технологии наподобие мультиплексирования помогают одновременно передавать больше данных. Как большой пассажирский самолёт, с несколькими этажами, напичканными сиденьями.

Мастер Йода рекомендует:  5 малоизвестных особенностей jQuery-методов Javascript

Что происходит, когда механизмы передачи данных сметают все преграды на пути к повышению производительности сети? У высокой скорости работы сайтов есть побочные явления: пользователи получают больше удовольствия, улучшается оптимизация для поисковых сервисов, ресурсы используются эффективнее, растёт аудитория и объёмы продаж, и многое другое.

К счастью, внедрение 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 на своём сайте воспользуйтесь этой простой инструкцией:

  1. Проверьте, чтобы был включен HTTPS:
    • Приобретите в проверенной организации сертификат SSL или TLS.
    • Активируйте сертификат.
    • Установите сертификат.
    • Обновите сервер для включения протокола HTTPS.
  2. Проверьте, чтобы базовая сетевая инфраструктура включала в себя поддержку HTTP/2 на уровне серверного ПО. Серверы Nginx имеют нативную поддержку, в Apache она появилась в октябре 2015 (в версии 2.4). В более ранних версиях для поддержки HTTP/2 нужно установить дополнительные модули.
  3. Обновите, сконфигурируйте и протестируйте ваши серверы. Здесь описана конфигурация и процедуры тестирования для серверов Apache. Свяжитесь со своим хостинг-провайдером и удостоверьтесь, что ваш сайт готов к использованию HTTP/2.
  4. Для проверки правильности конфигурации HTTP/2 воспользуйтесь этим инструментом.

Заключение

Нас ждёт неизбежное доминирование и превосходство HTTP/2. Протокол уровня приложения, похоже, несёт в себе наследие HTTP 1.x, который когда-то изменил сеть благодаря своим революционным возможностям по передаче данных. Но HTTP/2 демонстрирует гораздо более значительное технологическое превосходство над своим предшественником, чем HTTP 1.x в своё время.

Тем не менее, использование HTTP/2 — это лишь один шаг на пути к увеличению скорости загрузки страниц. В нашем Пособии по оптимизации скорости работы веб-сайта для начинающих описано, как создавать быстрые сайты, как исключать узкие места производительности, а также какие стратегические бизнес-преимущества даёт высочайшая производительность веб-сайта.

Комментарии 41

К сожалению, еще много районов с низко-скоростным интернетом, это оптимизация поможет. + забывая об оптимизации мы сами пришли к тому, что нам не хватает пропускной способности каналов связи даже с оптикой в некоторых районах.

с 1997 по 2009 особых проблем сеть не испытывала?

Будем честны — мы сейчас весело боремся с проблемами, который не было, пока https не стал внедряться повсеместно. http/1.1 отлично себе справлялся, и к нему за 11 лет уже притерпелись. Ан нет, решили теперь поиграть в игру «Гугл придумывает протокол, потом его же частично перестает поддерживать ради более продвинутого», а производители ПО к этому внезапно не готовы со своим софтом.

Скажем, nginx с экспериментальным модулем http/2, известным отсутствием поддержки push — это не беда, это просто недофича, а вот браузеры, которые без TLS не хотят поднимать http/2 — это уже ломка правил игры. И ладно еще на десктопах, но ведь мобильные устройства расплачиваются за ненужное многим шифрование увеличением расхода батареи!

Да, еще по поводу:

Приобретите в проверенной организации сертификат SSL или TLS

Ну если уж о справедливости, то внедрение SPDY, http/2 и прочих протоколов все же продвинулось сильно дальше. IPv6 забуксовало достаточно, чтобы не считать его «в среднем живым».

Даже если в сети какого-то оператора IPv6 и есть, ТП не способна ни дать совет, как настроить оборудование клиента (обычно есть одна-две «референсные» модели железок, которые понятно как настроить; модели эти обычно уже не продаваемые, по остальным никто ничего не знает, «читайте форумы»), ни даже проверить, что на стороне оператора IPv6 работает успешно (обычно говорят «это же опционально, нет гарантий, что он всегда будет работать хорошо»). Сравните с состояние дел с http/2 — сайты-то открываются у всех 🙂

P.S. Впрочем, Вы, кажется, отвечали не на мой коммент )

Да, че-то из мобильного клиента промахнулся. Но давайте поговорим? )

Дело тут в простом: внедрение http/2 требует по сути только проапгредить софт. Взять поновее nginx или application server какой-нить.

Внедрение IPv6 же требует сурьезного вложения в железо. Кроме того, с момента первой публикации там вышло несколько обновлений, часть из которых ломали совместимость. Формально имели право, ибо это ещё не стандарт, а лишь standart tracks, но всё же.

Кроме того, протоколы сетевого уровня — это своего рода клей, ведь протоколы L2 ограничены сегментом сети, протоколы L5 (и http) ограничены соединением. А L3 — они везде, а чем больше охват, тем тяжелее мигрировать.

Тем не менее, тихонько-тихонько, но и он к нам приходит. Стата гугла уже говорит, что уверено за 10%, а по выходным 12%. В СГА уже 28%. https://www.google.com/intl/en/ipv6/statistics.html — кстати, очень интересно наблюдать, что в выходные на 2% больше. Это означает, что когда юзеры сидят из дома, то через IPv6, а когда с работы — IPv4. Впрочем открытием это не назовешь: консерватизм Enterprise непобедим.

IPv6 забуксовало достаточно, чтобы не считать его «в среднем живым»

Да ладно вам. По грубым оценкам годичной давности планировалось иметь 12%, реально имеем 11.5% — я бы не назвал это такой уж большой «пробуксовкой».

Сравните с состояние дел с http/2 — сайты-то открываются у всех 🙂

Аналогичное мнение. Протокол преподносится как нечто невероятно крутое и фичастое, но по факту это все тот же HTTP/1, только в бинарном виде и с парой плюшек. POP->IMAP, IPv4->IPv6 — вот это действительно прогресс и действительно новая парадигма, построенная исходя из реальных потребностей людей и возможностей технологий, а то, что выкатили под видом HTTP/2 — карманный протокол для обслуживания собственных нужд гугла и близлежащих корпораций, который решили навязать всем в качестве стандарта, не в последнюю очередь — разработчикам браузеров.

Протокол как бизнес-план — решение просто отличное: благодаря фактической принудиловке с шифрованием будет меньше фильтраций рекламы на уровне провайдеров, благодаря push можно затолкать пользователю в кеш баннеров на полгода вперед, а благодаря приоретизации — затолкать баннеры одними из первых, благодаря мультиплексированию котятки на ютубе будут грузиться быстрее. А вот куки убирать не будем, хотя многие и просили, считая эту фичу небезопасной.

Не отлично то, что IETF из арбитра между компаниями, пользователями и реальностью превратили в резинотехническое изделие №2. Ведь нет же у HTTP/1 никаких несовместимых с жизнью проблем или критичного недостатка фич, и то, что HTTP/2 практически полностью слизан с HTTP/1 это только доказывает. Ведь могли же стимулировать IETF на разработку действительно нового протокола, но тогда бы со 100%-ой гарантией поломалась бы обратная совместимость, и полный переход занял бы лет 10 как минимум. Но кому-то надо немного разгрузить сервера и немного больше заработать здесь и сейчас, и это уже является достаточным основанием для того, чтобы навязывать разработчикам браузеров свои костыльные детища.

По факту получили забавный момент: народ, приученный, что нужно иметь статический IP для каждого сайта с HTTPS, начал уползать с shared хостингов на ВПСки (с выделенными, конечно, IP), и IPv4 начали сокращаться еще шустрее. Не за горами момент, когда массовые VPS-хостинги начнут из IPv4 выдавать только серые адреса, ставить перед ними прокси и NAT-ы, а клиент в панели управления будет себе заказывать проброс или http-проксирование нужных портов. IPv6 останется безлимитным, что хоть как-то, наверное, сподвигнет его юзать.

А если серьезно, пока домашний юзер не получит легкую в настройке и надежную в работе схему использования IPv6, сервера можно не бежать и не настраивать. Увы.

Потому что даже у одного вендора домашнего роутера даже на одной ревизии железа (привет, Длинку с его тремя-пятью аппаратными ревизиями под одним названием!) но на разных версиях прошивок настройка IPv6 мало что может отличаться, так еще может и не работать при внешне одинаковых настройках.

А если серьезно, пока домашний юзер не получит легкую в настройке и надежную в работе схему использования 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 мало что может отличаться, так еще может и не работать при внешне одинаковых настройках.

создателей сервера не волнуют

Напомнили старое доброе:


Послали админов на армейскую переподготовку.
Выдали по автомату, патронов как никогда, и — на стрельбище.
Стреляли-стреляли — куда угодно попали, только не по мишеням.
Командир их строит:
— Вы, блин, связисты так вашу разэтак! Кто ж так стреляет! Чему вас учили?
И тут голос из строя:
— Командир! У нас пуля из ствола вылетела — проблемы на вашей стороне.

А если честно, ваш подход мне нравится. Настроить сервер — дело важное. Но клиентам-то как?

Итак, дано: есть домашний юзер, который вчера подключил себе инет одного из операторов. Есть (да-да, есть!) IPv6 в сети оператора. Вопрос: сколькими методами клиент может на своей железке (давайте для определенности, что он через wifi-роутер работает) может настроить этот самый IPv6?

Если бы речь шла об IPv4, настройка несложна: операторы поднимают обычно у себя в сети PPPoE или PPtP. Первое «само работает», второе с чуть большим волнением, но технологии привычные (разве что в первом случае сервер подключения указывать не надо).

IPv6 имеет варианты. Сами посчитаете, или сказать число комбинаций технологий? А число «домашних» железок, на которых все эти (даже «самые частые») комбинации работают подскажете в ответ?

IPv6 в сети оператора так и не стало рекламной фичей. Может, «пока», может, «уже» не стало. Раз не стало (как 3G и 4G), то операторы не видят денежной (кроме экономии IPv4-пулов) нужды вылизывать проблемы с IPv6. Более того, часты ситуации, когда неработа IPv6 в сетях аплинков не беспокоит ТП, вплоть до «не знаем, когда они починят».

Так что сайты на IPv6 настраивать надо. Громких слов про него надо поменьше, а вот дела — побольше. Но раз сдать девайс в магазин со словами «на нем IPv6 в сети моего провайдера не работает», нельзя, то и повода у Д-Лика и иже с ним. делать нормальный IPv6-enabled софт как бы и нет.

А если честно, ваш подход мне нравится. Настроить сервер — дело важное. Но клиентам-то как?

А клиенты пусть пинают провайдеров если им 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 тоже отказаться?

Да-да, его-то я и забыл. Я бы от такого оператора постарался уйти (точнее, везде, где мог себе позволить, ушел и ухожу), а не от IPv-что-то там. «Пакеты не виноваты», да.

Хорошо, краткая выжимка такова: пока, сев на IPv6, клиент не перестанет переживать, почему у него часть сайтов не открывается, радости нам всем не будет. Сам видел, и не раз, как вконтактик (а это тот еще генератор трафика, сами понимаете) в локальной сети по IPv6 начинает быть то медленным, то вообще пропадает со связи, а по IPv4 тот же ресурс отлично открывался. В общем, преднастроенная железка от оператора будет отличным решением, но я часто вижу операторов, которые не в сторону IPv6 смотрят, а вводят «добровольно-принудительно» CGN. Не самые гнилые из операторов при этом хотя бы позволяют эту «фичу» бесплатно отключать, самые же «добрые» отвечают — «интернет у вас есть? значит, договор мы выполняем», и CGN не отключают никак.

Впрочем, будем надеяться. Юзерам тем временем нужно культуру файрволлов прививать — за NAT-ами разбаловались, что роутер на 99% атаки извне гасит.

Я бы от такого оператора постарался уйти (точнее, везде, где мог себе позволить, ушел и ухожу), а не от IPv-что-то там.

Тогда зачем отказываться от стабильно работающего провайдера?

Сам видел, и не раз, как вконтактик (а это тот еще генератор трафика, сами понимаете) в локальной сети по IPv6 начинает быть то медленным, то вообще пропадает со связи, а по IPv4 тот же ресурс отлично открывался.

И я видел. И так и будет продолжаться пока некоторое количество сервисов не окажутся людям недоступными без, скажем, «белого» IPv6 адреса.

Ровно то же самое происходило с мобильниками: ещё несколько лет назад предложение «отключить нафиг 3G, чтобы батарейка не садилась» не вызывало у людей удивления. А потом — оказалось что без 3G много вещей отказываются работать. И выход — не выключать 3G, а купить новый мобильник (если проблема в мобильнике) или сменить оператора (если проблема в плохом покрытии).

Ну не придумали ещё никакого другого способа внедрения новинок! Увы.

Не самые гнилые из операторов при этом хотя бы позволяют эту «фичу» бесплатно отключать, самые же «добрые» отвечают — «интернет у вас есть? значит, договор мы выполняем», и CGN не отключают никак.

Ну дык. Особенно когда «эффективные манагеры» начинают «резать косты». Тут нельзя ничего посоветовать кроме как ждать. Если вам очень нужно общаться с подобным провайдером, то придётся какое-то время его терпеть, пробрасывать туннели и прочее. Но со временем — он просто умрёт. По очень простой причине: у него прибыль «высохнет». Потому что подобный подход означает, что если для кого-то IPv6 не блажь, а необходимость (ну например вам Android нужно разрабатывать и IPv6 просто необходим для запуска тестов), то он должен будет обращаться к провайдеру, который ему этот IPv6 предоставит (даже если ради этого нужно будет не просто сменить провайдера, а, скажем, перенести разработку в другой город) — таким образом потихоньку-полегоньку самые выгодные клиенты от такого провайдера уйдут, а через какое-то время — имущество уйдёт с молотка.

Причём вариант: «эффективные манагеры заметят что происходят и одумаются», увы, почти исключён. Потому что обычно они осознают, что отстали и что нужно «срочно что-то делать» тогда, когда уже поздно: самые выгодные клиенты уже ушли, а тех, которые остались — уже не хватает на то, чтобы оплатить замену оборудования. Иногда, впрочем, неимоверным усилием и с залезанием в долги процесс удаётся остановить.

Переход на 4G таким образом убил Билайн. Причём он отстал давно, но при этом «сохранял спокойствие» и несколько лет даже казалось что «всё идёт по плану», но сейчас, когда 4G перешёл из категории «что-то чем мы хвастаемся» в категорию «что-то, без чего мы теряем клиентов» стало видно что это — тупик. Описанная выше спираль фактически без надежд на спасение. Причём до момента формального банкроства могут пройти ещё годы — но что «процесс пошёл» было видно уже пару лет назад…

То же самое и с «умными» провайдерами с GCN: те, кто используют GCN, чтобы купить себе «передышку» на пару лет — выживут, те, кто будут продолжать пытаться продвигать GCN лет так через 5 — умрут. Главное — не заставляйте людей, которым IPv6 пока не нужен метаться и менять провайдера раньше времени: когда придёт пора они сами всё увидят…

Юзерам тем временем нужно культуру файрволлов прививать — за NAT-ами разбаловались, что роутер на 99% атаки извне гасит.

А что в 4G такого, без чего жить нельзя? И почему Би без него умирает? Насколько я понимаю, умирает он немного по другой причине. Интернет у них, кстати, получше чем у конкурентов, но, возможно, у вас там другая картина.А лично мне была бы востребованы функции вроде Wi-Fi Calling, но это не к Билайну, а еще и к «товарищу майору», который, как говорят, не успевает определять место нахождения абонента и т.д.

Мастер Йода рекомендует:  Как индексировать, разбивать и манипулировать строками в Javascript

Дело в том, что «косты резать» мозгов много не надо. И IPv6 для этого не нужен (если бы не говорим о людях пытливых и которым что-то надо). Выдали бабушке роутер, он работает, ноутбук цепляется, «какие проблемы, интернет же есть?» А вот когда роутер решат перешить (удаленно, да!) на поддержку IPv6-first вариант, вот тут провайдер поимеет массу плавающих проблем, и никогда поэтому на такое не пойдет.

Да, можно провайдерам повыкручивать руки (вы понимаете, что по факту траблы получит не провайдер, а клиенты его, и провайдера поменяют, конечно — может, один на тысячу, а может, и еще меньше), и зарубить на своем сайте IPv4. Но пока сайт не будет суперважен (вконтактик с фейсбуком, например, хотя как они могут считаться действительно важными — это вопрос хороший), сайт не людей лишит себя, а себя — людского внимания. А ВК отрубать IPv4 не станет, им кушать надо.

Против кого дружим? Здесь типичная проблема курицы и яйца, да еще отягощенная жутким техническим долгом. Вендоры все обещали, что, как IPv6 устаканится, выйдут апдейты, и всё-всё заработает, но…

Домашние роутеры сильно отстали от прогресса. Даже операторские — отстали, и никто домашний парк обновлять не будет.

Да что говорить, у дуал-стека до сих пор есть ахилесова пята: если браузеру, скажем, кажется, что у сайте есть IPv6-адрес, то он будет стучаться на него до потери пульс истекания таймаута, прежде чем постучится на IPv4. На выходе это дает чехарду и кучу жалоб. Каждая ОСь по этому поводу себя ведет как хочет, и одинаковости поведения здесь не ждем.

В общем, по уму если, ждем лет 10, потом пробуем перевести мир на «вэ-шестой». За 10 лет обновятся и ОСи, и роутеры, и оборудование операторов. Только за 10 лет костылей столько наделают на v4…

А что в 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…

В общем, по уму если, ждем лет 10, потом пробуем перевести мир на «вэ-шестой».

А смысл? Что через 10 лет вдруг такого радикального произойдёт?

За 10 лет обновятся и ОСи, и роутеры, и оборудование операторов.

Почему именно через 10? почему не через 3 или 100?

Вы задаете вопрос к предложению, пояснение к которому дается в следующем. Мне кажется, это все, что нам с вами нужно знать о нашей ветке дискуссии.

Время решит вопрос с адресацией. И v6, и хоть v26 однажды появятся в сети, и будут работать у всех, но — не сразу. Потому что сегодня я не наблюдаю ни поголовной поддержки v6 со стороны имеющегося оборудования, ни со стороны софта, ни банальных толковых инструкций на сайтах провайдеров. Может, конечно, Бельгия в этом смысле либо дисциплинированнее, либо меньше, либо там операторы как-то очень правильно себя ведут, но… Посмотрим!

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

Странно. Я почему-то всё это наблюдаю. Может вы не туда смотрите?

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

Вы хотите сказать что видите инструкции, объясняющие как подключиться через IPv4. Я в основном вижу инструкции многолетней давности, многие из которых уже не действуют. Мир изменился: сегодня провайдеры просто выдают вам роутер и всё. Как он там соединяется с внешним миром и что у него внутри — написано только во внутренней инструкции для монтажников…

Может, конечно, Бельгия в этом смысле либо дисциплинированнее, либо меньше, либо там операторы как-то очень правильно себя ведут, но…

Бельгия опережает ситуацию «в среднем по миру» на примерно на два года, Россия — отстаёт где-то на три. Самое важное: Штаты и Япония — впереди «средней позиции» на год. Вряд ли кто-то сделает особо популярный сервис, работающий только в Бельгии, а вот сделать что-то, что поначалу будет работать только в США и Японии — могут легко (сервес тестирования Андроида, требующий IPv6 уже сейчас, я назвать «популярным» всё же не могу, LOL).

Я ожидаю, что это произойдёт где-то в 2020-2021м году (как и писал год назад). А дальше — всем остальным (кроме «отрезанного от мира» Китая) придётся подтягиваться.

P.S. А насчёт «поголовной поддержи IPv6 со стороны оборудования»… всё зависит от заказчика. Сказал Verizon что всё железо с поддержкой LTE обязано поддерживать IPv6 — поставщики взяли под козырёк, у Verizon’а уже больше половины пользователей IPv6 имеют, сказал T-Mobile, что без этого «кина не будет» — и получил. Понятно что старые сети нужно как-то поддерживать и перевести за месяц-другой всех на новое оборудование не получится, но почему ISP в России по прежнему продолжают устанавливать новое оборудование без поддержки IPv6 — мне непонятно. Хотят попасть в ситуацию когда клиенты будут требовать IPv6, а они его им дать не смогут? Попадут — и даже примерно ясно когда.

Тьфу ты, не понял сначала, что это перевод. Расходимся.

А запостившему, всё-равно минус, перевод-переводом, но содержимое — откровенный bullshit.

коллективная система (collective system) позволяет серверам эффективно передавать клиентам больше контента, чем они запросили

Сама по себе статья написана не слишком приятно, да и полезной информации в ней маловато.
А вот сам http/2 получше. У нас некоторое время уже работает, полет нормальный.

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

На нашем проекте проблема решилась изменением в файле apache2.conf.
Для этого нужно указать вот это:


BrowserMatch «yandex\.com/bots» noh2
Header unset Upgrade env=noh2

>>Для защиты данных, передаваемых между клиентом и сервером, в HTTP/2 используется подход «Безопасность через непонятность» (Security by Obscurity): команды представлены в двоичном виде, применяется сжатие метаданных HTTP-заголовков.

Вокруг этого 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 создавался с учётом повышения эффективности клиент-серверного обмена данными, что позволяет бизнесменам увеличить охват своих сегментов рынка, а пользователям — быстрее получить доступ к качественному контенту. Помимо прочего, сегодня веб ситуативен как никогда ранее.
Просто маркетинговый буллшит какой-то.

Дальше тоже только маркетинговый буллшит в всё.

Вокруг этого HTTP/2 очень много намеренного введения в заблуждение, и откровенной лжи. Я не могу допустить обычной некомпетентности в этой теме.

Вместо этого вы добавите свою?

Это просто чушь собачья! Представьте 5 пользователей. Трое четверо читают эту статью на Хабре, пятый же загружает страницу с большим количеством фоток котиков. Четверо уже освободили канал, а пятый страдает из-за того, что все котики продираются по одному соединению. А ведь если бы браузер создал 3-4 дополнительных соединения, котики бы уже загрузились!

Ага. За счёт того, что те трое, которые читают эту статью сидели и ждали бы у моря погоды.

Чудес ведь не бывает: TCP так устроен, что он занимает всю ширину канала, которая есть! Так что если «котики» грузятся быстрее, то что-то другое грузится медленнее. Вопрос: что? Правильно — как раз вот те сайты, которые не генерят много траффика и не включают в себя тысячи картинок котиков и страдают.

Кому это всё выгодно. Только хозяевам серверов с миллионами пользователей — Гуглу и Мордокниге. Но уж точно не пользователям.

Как раз наоборот: Гугл и Мордокнига тут скорее в потерпевших окажутся. Другие вещи в HTTP/2 идут им на пользу, но вот это мультиплексирование — как раз нет. С HTTP/2 выигрывают более лёгкие сайты, а не те, которые могут поднять 100500 серверов.

«Развивающейся сети уже не хватает возможностей», надо честно говорить «наши сервера не справляются, пусть страдают пользователи, взвалим на них»

Вот только в вашей теории заговора есть один пробел: как раз сервера Гугла со всем справляются, выигрыш собственно для самого Гугла меньше чем для других сайтов у которых, действительно, может не хватать серверов.

Сейас очень много говносайтов, с неоптимизированными картинками, из-за которых титульная страница сайта весит 10-12Мб. Здравствуй паразитный трафик.

И, как уже говорилось выше, именно эти сайты и страдают больше всего от HTTP/2 и именно они могут уменьшить количество «паразитного трафика» за счёт отказа от разных трюков (типа склеивания 100500 иконок в одну картинку). Захотят ли они это сделать — это уже другой вопрос.

А какие преимущества HTTP/2 вообще дает самим пользователям?

Быстрее работающие сайты и меньше счёт за траффик — не считается?

Тот факт, что вы нашли в статье некоторое количество неточностей не означает что вашу чушь все должны принимать за чистую монету. Весь пост, в общем, посвящён одной-единственной «проблеме»: HTTP/2 не позволяет мне «урвать» больше от канала, чем его достаётся другим. Ата-та, ах какой-нехороший HTTP/2!

Быстрее работающие сайты и меньше счёт за траффик — не считается?

Больший расход батарей мобильных устройств за счет (по факту повсеместного) использования шифрования в http/2 добавить в «якобы плюсы юзерам» не забудьте ))

Не говоря что TLS несколько менее устойчив к качеству канала, а возня с сертификатами добавила «радости» большому числу админов сайтов.

Это я к тому, что и плюсы, и минусы есть, и надо это понимать.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.


Стоит ли переходить на httpS и улучшает ли перевод сайта на протокол https его SEO характеристики?

Как известно, с 1 января 2020 года поисковик Google в своей выдаче будет помечать ВСЕ сайты, не перешедшие на работу по https-протоколу как потенциально небезопасные. Очевидно, это будет несколько отпугивать посетителей, а соответственно у сниппета сайта неизбежно упадет CTR, что повлечет падение пользовательских факторов и понижение позиций в выдаче.

Кроме того, сам по себе факт работы по http протоколу внутри алгоритма ранжирования гугл не позволяет сайту рассчитывать на высокие позиции в выдаче.

Что же делать владельцам сайтов? Срочно переходить на работу по httpS протоколу? Но стоит ли оно того?

Чтобы ответить на эти вопросы, мы провели несколько тестов на реальных сайтах. И сегодня я готов поделиться с вами результатами и выводами.

Итак. Начнем. Сразу покажу график.

Это наиболее яркий пример изменения позиций сайта по одному из ключевых запросов в Google. Был у нас такой сайт, на котором мы сначала включили https, а потом пришлось его отключить. По другим продвигаемым ключам такого сильного движения позиций не было, но суть изменений в Гугле была та же самая: при включении httpS сайт поднялся, а потом при отключении просел. Проседание было меньше, чем рост просто потому, что мы при отключении httpS поставили обратную склейку — для передачи веса с уже проиндексированных https-страниц на старые http-страницы сайта.

Дальнейший рост в Google после отключения https никак не связан с переключением протоколов, он отражает только наш профессионализм ��

Итак, казалось бы, ответ очевиден. НО! Почему нам все-таки пришлось отключить SSL на этом сайте?

Потому, что в Яндексе после включения httpS сайт просел. Более того, в той или иной степени после такого переключения проседают практически любые сайты!

Почему? После серьезных мозговых штурмов и долгих и нудных разборок с самим Платоном нам удалось найти ответ на этот вопрос. Дело в том, что Яндекс до сих пор считает httpS://вашсайт.ру и http://вашсайт.ру РАЗНЫМИ САЙТАМИ! Со всеми вытекающими отсюда последствиями. Даже если вы сразу настраиваете правильную полную склейку, то все-равно после перехода ваш сайт потеряет бОльшую часть внешнего ссылочного. А если не дай бог склейку не настроите или настроите не сразу, то можете обвалить сайт в выдаче Яндекса очень сильно.

Кроме того, даже если у вас все ссылки стоят, например, с ваших же сайтов, и вы можете легко и быстро заменить в них протокол с http на httpS, вы все-равно потеряете довольно значительную часть передаваемого ссылочного веса за счет того, что такой важный фактор ссылок как возраст, сбросится в ноль.

Вот как-то так все получается. Поисковики, как это часто бывает в последнее время, действуют с точностью до наоборот ��

И что же делать в конечном итоге, спросите вы? А я вам отвечу ��

Итак. Есть два варианта.

  1. Если ваш сайт получает бОльшую часть трафика из Google, а из Яндекса мало или не дай бог в Яндексе сайт вообще под фильтром, то вам однозначно нужно переводить сайт на работу по httpS протоколу, при чем сделать это желательно до нового года, чтобы гугл не стал его помечать как небезопасный.
    Для тех же, у кого сайт под фильтром Яндекса, в этом варианте есть даже небольшой бонус: по нашим наблюдениям есть некоторый шанс автоматического снятия фильтра после перехода на работу по защищенному протоколу и настройки склейки.
  2. Если же ваш сайт в Google стоит плохо и основная часть трафика идет из Яндекса, то так же однозначно вам не стоит дергаться, по крайней мере пока, ждать, пока Яндекс доведет до ума свои алгоритмы и интерфейсы.
    Знаком к тому, что что-то поменялось в отношении Яндекса к SSL станет я думаю то, что хотя бы в панели вебмастера он начнет считать httpS://вашсайт.ру и http://вашсайт.ру все-таки ОДНИМ И ТЕМ ЖЕ сайтом, а не разными, как сейчас.

Вот такие выводы и рекомендации. А что же делать тем, у кого трафик более-менее одинаково идет и с Яндекса и с Гугла? Однозначного ответа на этот вопрос нет. Но я бы все-таки порекомендовал подождать нового года и посмотреть, что будет с трафом. А только потом уже принимать взвешенное решение.

Есть еще один вариант — обратиться за советом и помощью к профессионалом, например к нам �� Будем рады помочь, обращайтесь. ��

HTTP в сравнении с HTTPS и SEO

Что то Вы как то все заморочено описываете.
Вам нужно приобрести сертификат, установить его, в файле robots указать главное зеркало
В .htaccess 301 редирект c http на https (он работает для всех страниц одинаково, все запросы к сайту идут по https )
Вот пример кода:

Если возникает циклический редирект, попробуйте этот код

один из двух в любом случае работает

Проверяем все — если все хорошо
Идем в Я Вебмастер и Search Console и добавляем там версию сайта с https
После того как появятся данные для https версии , старые версии с http можно удалять

Ждем переиндексации и все готово. (переиндексация занимает от 1 до 30 дней чаще всего)

И все нужно сделать сразу, а не постепенно, так как если делать постепенно, то Яндекс начнет думать что сайт не доделан и точно пессемизирует его в выдаче.

Что то Вы как то все заморочено описываете.
Вам нужно приобрести сертификат, установить его, в файле robots указать главное зеркало
В .htaccess 301 редирект c http на https (он работает для всех страниц одинаково, все запросы к сайту идут по https )
Вот пример кода:

Если возникает циклический редирект, попробуйте этот код

один из двух в любом случае работает

Проверяем все — если все хорошо
Идем в Я Вебмастер и Search Console и добавляем там версию сайта с https
После того как появятся данные для https версии , старые версии с http можно удалять

Ждем переиндексации и все готово. (переиндексация занимает от 1 до 30 дней чаще всего)

И все нужно сделать сразу, а не постепенно, так как если делать постепенно, то Яндекс начнет думать что сайт не доделан и точно пессемизирует его в выдаче.

Добрый вечер. Вы немного заблуждаетесь.

Согласно рекомендациям самого Яндекса — https://yandex.ru/blog/platon/2778, (пункт 6), так делать не рекомендуется.
Причина, почему он так не рекомендует делать скорее всего в том, что у него недостаточно мощностей обработать на одном ip множество (80к) 301 перенаправлений. То есть, например, он может обработать редирект, выбросить страницу из поиска и новую не добавить, что в итоге выльется в просадку трафика.

22.12.2020, 20:16 #3

Жендосье, как именно ломаются их скрипты? По какой причине они не могут работать и на обычной версии, и на защищенной? Спросите, что конкретно не так в данном случае, так как обычно с этим проблем нет (если пути не полные, а прописываются относительно).

Переезд обычно прост — обновляете файл robots.txt (конкретно директива Host), дальше ставите новое главное зеркало в панели вебмастера, когда поисковая выдача обновится и главным зеркалом станет новый адрес, можно поставить переадресацию, так как если это сделать до, то страницы действительно повыпадают из поисковой выдачи.

23.12.2020, 00:27 #4
Евгений Русаченко
Посмотреть профиль
Найти ещё сообщения от Евгений Русаченко

Может быть не буду спорить.
Мы всегда делаем вот так, и через 2 недели все страницы в индексе снова, просадки не случались.

1000 людей — 1000 мнений ))

23.12.2020, 00:44 #5

Жендосье, как именно ломаются их скрипты? По какой причине они не могут работать и на обычной версии, и на защищенной? Спросите, что конкретно не так в данном случае, так как обычно с этим проблем нет (если пути не полные, а прописываются относительно).

Переезд обычно прост — обновляете файл robots.txt (конкретно директива Host), дальше ставите новое главное зеркало в панели вебмастера, когда поисковая выдача обновится и главным зеркалом станет новый адрес, можно поставить переадресацию, так как если это сделать до, то страницы действительно повыпадают из поисковой выдачи.

Некоторые комментарии разработчика

«за все цмс не скажу, но joomla, вордпрес, у них в конфигах включение/выключение ssl, и одновременно и то и то, такого нет»

«если в nginx не будет склейки, то скорее всего только главная будет открываться и с http и https, откроется http, а все ссылки внутри будут https движок с включенным ssl так сгенерирует, тут беда с может быть со скриптами и стилями»

Не могли бы Вы прокомментировать?

adel92, я полностью согласен с 301-перенаправлением в том случае, когда сайт небольшой (до 1-2к страниц), здесь же, как уже оговаривалось 80к урлов и 18 поддоменов. Естественно, все на одном ip.

23.12.2020, 10:13 #6

Некоторые комментарии разработчика

«за все цмс не скажу, но joomla, вордпрес, у них в конфигах включение/выключение ssl, и одновременно и то и то, такого нет»

«если в nginx не будет склейки, то скорее всего только главная будет открываться и с http и https, откроется http, а все ссылки внутри будут https движок с включенным ssl так сгенерирует, тут беда с может быть со скриптами и стилями»

Не могли бы Вы прокомментировать?

Такая проблема действительно есть (по крайне мере я раньше с ней сталкивался). Поставил WordPress 4.7, чтобы протестировать: http://wp.p-host.in

В настройках прописан адрес http://wp.p-host.in, но сайт доступен также и по https://wp.p-host.in, проблем на вид нет. Еще как вариант, можно прописать адрес //wp.p-host.in, именно просто с двумя слешами в начале. В данном случае, если страница открыта через защищенное соединение, все такие ссылки будут грузиться через защищенное соединение, если через обычное, то всё будет грузиться через обычное. Еще момент — через панель администратора такие ссылки не задать, пишет, что адрес неверный, делается это через базу данных, таблицу wp_options.

Но как хорошо воспринимают такое поисковые системы не знаю.

Если у Вас хорошие специалисты, то попросите просто выпилить на время систему переадресации в WordPress (чтобы она не мешала Вам во время переезда)

Добавить комментарий
23.12.2020, 17:17 #7