Путь к http/2

Преимущества перехода на HTTPS с точки зрения SEO

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

1. Повышение позиций в выдаче.

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

2. Реферальные данные.

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

3. Безопасность и конфиденциальность.

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

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

Возможные проблемы при переходе на HTTPS

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

Обязательно сообщите Google о том, что вы перешли с HTTP на протокол HTTPS.

Google предлагает воспользоваться следующими рекомендациями при переходе на HTTPS:

• Выберите подходящий вам тип сертификата безопасности: одиночный, мультидоменный или wildcard-сертификат (сертификат-шаблон для защищенного источника с несколькими динамическими субдоменами).
• Используйте сертификаты с 2048-битными ключами.
• Используйте относительные URL-адреса для ресурсов, находящихся на одном защищенном домене.
• Используйте относительные URL без указания протокола для всех остальных доменов.
• Не закрывайте от индексации HTTPS-страницы в файле robots.txt.
• По возможности разрешайте поисковым роботам индексирование страниц. Старайтесь не использовать noindex в метатеге «robots».
• Google обновил Google Webmaster Tools для более удобной работы с сайтами, использующими протокол HTTPS.
• Внимательно отслеживайте переход сайта с HTTP на HTTPS в программах аналитики и в Google Webmaster Tools.

Приведем краткий список последовательности шагов, чтобы в общих чертах обрисовать процесс:

1. Создайте запрос на получение сертификата (CSR).
2. Выберите серверное ПО, используемое для генерации запроса CSR.
3. Выберите алгоритм хэширования.
4. Выберите срок действия сертификата.

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

С подробной инструкцией по переходу на HTTPS вы можете ознакомиться в нашей статья «HTTP vs HTTPS. Как перейти на HTTPS без последствий?».

Общая информация: чем отличается http от https

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

HTTPS (Secure HyperText Transfer Protocol) был разработан для создания защищенных транзакций и авторизации через интернет. Обмен информацией, например номерами банковских карт, требует максимальной безопасности для предотвращения несанкционированного доступа.

HTTPS — это защищенная версия HTTP. В HTTPS используется дополнительный уровень безопасности протокол Secure Sockets Layer, или SSL.

HTTP и HTTPS: основы

Как для пользователя, так и для владельца сайта хорошее онлайн-взаимодействие обычно подразумевает качественное шифрование данных. Чтобы разобраться, почему Google отдает предпочтение этому элементу, рассмотрим основные различия между протоколами HTTP и HTTPS.

HTTP (HyperText Transfer Protocol)

HTTP («протокол передачи гипертекста») — это система передачи и получения информации в интернете. HTTP является протоколом прикладного уровня, то есть, по сути, его интересует в первую очередь то, как информация передается пользователю, при этом ему безразлично, как данные попадают из пункта А в пункт Б.

За один год Uber потерял из-за мобильного фрода 100 млн $

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

Спецпроект

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

Когда целесообразно использование HTTP?

HTTP чаще всего применяется для доступа к HTML-страницам

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

HTTPS (Secure HyperText Transfer Protocol)

Протокол HTTPS, то есть «безопасный HTTP», был разработан для авторизации и защищенных транзакциях. Обмен конфиденциальной информацией должен быть безопасным, чтобы предотвратить несанкционированный доступ, именно для этого и нужен HTTPS. Во многих отношениях HTTPS идентичен HTTP. В обоих протоколах клиент (например, ваш браузер) устанавливает соединение с сервером через стандартный порт. Однако HTTPS обеспечивает дополнительный уровень защиты, поскольку применяет криптографический протокол SSL при обмене данными.

С технической точки зрения есть еще одно различие протоколов: в отличие от HTTP, для HTTPS по умолчанию используется 443 TCP-порт, т.е. протоколы HTTP и HTTPS используют два разных порта для коммуникации.

HTTPS работает совместно с криптографическим протоколом Secure Sockets Layer (SSL). Вместе они обеспечивают надежную передачу данных, и именно это отличие от HTTP учитывает Google.

Обратите внимание: протоколу HTTP важно ЧТО передается, то есть сохраняется целостность данных, но сами данные могут оказаться под угрозой перехвата. Для SSL важно КАК передаются данные, при этом безразличен вид содержания, но надежен процесс передачи. HTTPS — это HTTP, обернутый в SSL

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

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

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

Взаимодействие по протоколу HTTP

Как упоминалось ранее, HTTP-сервер принимает запросы от клиентов через известный TCP-порт 80 (или порт 443 для HTTPS) . HTTP-клиенты могут использовать любой доступный TCP-порт для исходящих подключений. Общая последовательность событий HTTP выглядит следующим образом.

HTTP-запрос GET

1. Клиент отправляет запрос на TCP-подключение к порту 80 сервера (или 443 для HTTPS).
2. Если используется протокол HTTPS, то после установления TCP-подключения следует подтверждение TLS, чтобы проверить подлинность сервера и установить безопасный канал.
3. Клиент отправляет запрос GET ресурс HTTP/1.1 и другие сведения заголовка.
4. Сервер создает сообщение HTTP/1.1 200 OK с дополнительной информацией, за которой следует содержимое запрошенного ресурса (при наличии).
5. Сервер отключается от клиента (протокол TLS завершает работу, если используется протокол HTTPS).
6. Клиент отключается от сокета (протокол TLS завершает работу после оповещения об отключении от сервера).

HTTP-запрос PUT

1. Клиент отправляет запрос на TCP-подключение к порту 80 (или 443) сервера.
2. Если используется протокол HTTPS, то после установления TCP-подключения следует подтверждение TLS, чтобы проверить подлинность сервера и установить безопасный канал.
3. Клиент отправляет запрос PUT HTTP/1.1 и другие сведения заголовка, за которыми следует содержимое ресурса.
4. Сервер создает сообщение «HTTP/1.1 200 OK» с дополнительной информацией, за которой следует содержимое запрошенного ресурса.
5. Сервер разрывает подключение.
6. Клиент разрывает соединение.

Примечание

Как уже упоминалось, HTTP-сервер может изменить стандартный порт подключения (80 или 443) на любой другой порт с помощью службы nx_web_http_client_set_connect_port() , что позволяет веб-серверам, использующим альтернативные порты, подключаться к клиентам.

Уязвимости

У протокола HTTPS есть слабые места, зная о которых можно избежать серьезных проблем.

Одновременное применение HTTP и HTTPS

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

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

HSTS – это механизм, активирующий защищенное соединение посредством HTTPS протокола в принудительном порядке там, где изначально установлен HTTP

На заметку. HSTS – это механизм, активирующий защищенное соединение посредством HTTPS протокола в принудительном порядке там, где изначально установлен HTTP.

Атаки в ходе анализа трафика

Протокол имеет проблемы и при анализе трафика. В ходе атак с анализом трафика выводятся показатели защищенных данных канала. Достигается это благодаря измерению объема трафика и продолжительности передачи информации в нем. Анализировать трафик реально, потому что SSL и TLS шифруют данные так, чтобы в корне изменялось содержимое трафика, но его размер и время оставались практически неизменными.

Весной 2010 года сотрудники Microsoft Research провели исследование, в ходе которого обнаружили, что важные «скрытые» личные данные возможно заполучить из второстепенной информации, к примеру, из размеров пакетов.

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

Man-in-the-middle

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

Злоумышленники получают то, что им нужно, если пользователь не обращает внимание на предупреждения браузера после двойной проверки сертификата

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

1. Мошенник «располагается» между сервером и клиентом.
2. Отправляет сообщения пользователя к серверу, не меняя их.
3. Перехватывает сообщения от сервера.
4. Создает ложный сертификат и заменяет ним изначальный сертификат от сервера.
5. Отправляет пользователю подменный документ.
6. После подтверждения сертификата пользователем, устанавливается два «защищенных» соединения: между мошенником и посетителем, а также между мошенником и сервером.

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

Переход на https — зачем мне это?

Я бы выделил 4 причины:

1. Забота о безопасности данных: сейчас по этой теме сходят все с ума (раньше все клали с пробором, но теперь…). Для сайтов работающих с деньгами и онлайн оплатой — это острая необходимость, т.к. шифруются все данные. Для простых информационных ресурсов — вас все равно заставят перейти на https, т.ч. выбора особо нет.

2. Это фактор ранжирования: и Яндекс и Google открыто об этом говорили. Если раньше только Гугл заставлял переводить сайты на https, то сейчас за это взялось зеркало Рунета и с 24 января 2019 года в вебмастере уже многие увидели предупреждение:

   Т.е. это благотворно скажется на ваших позициях и трафике с поисковых систем (на самом деле нет, чаще вообще никак не скажется )

3. Больше доверия со стороны пользователей. Когда посетитель видит в браузере метку:

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

4. Ради HTTP/2 и большей скорости, которая так же является фактором ранжирования. В среднем прирост по скорости достигает 20-30% практически за 20-30 минут работы.

Ну а теперь перейдем к пошаговому плану по переходу с http на защищенный протокол https.

Создание постоянной переадресации 301 через настройки и плагины CMS

В большинстве популярных конструкторов сайтов и CMS (OpenCart, Joomla!, Битрикс, Wix, Тильда) предусмотрена настройка редиректов с помощью встроенных инструментов. Если сайт создан с помощью WordPress, для настройки переадресации можно воспользоваться следующими плагинами:

• Redirection — самый популярный плагин для настройки редиректов. Кроме основной функции обладает следующими возможностями: сбором статистики переадресаций, отслеживанием ошибок 404, поддержкой регулярных выражений.

• Safe Redirect Manager — простой плагин, который также поддерживает регулярные выражения, практически не влияет на производительность сайта.

• Quick Page/Post Redirect Plugin — еще один удобный инструмент оптимизации. Один из недостатков — отсутствие поддержки регулярных выражений. К ссылкам можно добавлять атрибут «nofollow».

• Simple 301 Redirects. Данный модуль обладает одним недостатком – url для переадресации необходимо прописывать вручную.

Настроить Permanent Redirect 301 в Вордпресс можно и через редактирование файла .htaccess в разделе управления хостингом. Чтобы подключиться к нему, потребуется использовать FTP-клиент. Сама кодировка производится по общим правилам настройки переадресации в .htaccess.

Чтобы настроить 301 редирект в CMS OpenCart в файле .htaccess необходимо прописать:

RewriteCond %{QUERY_STRING} ^_route_=адрес_старой_страницы.html$

RewriteRule ^(.*)$ http://ваш_домен.ru/новой_страницы/? 

Для Битрикс кодировка будет выглядеть следующим образом:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www.sng-it.ru$ 

RewriteRule ^(.*)$ http://sng-it.ru/$1 

В Joomla настройки переадресации производятся через панель администратора в разделе «Компоненты» => «Перенаправление». Здесь можно не только установить правила редиректа, но и отслеживать страницы с битыми ссылками и перенаправлять их на корректные адреса.

С конструкторами сайтов все не так однозначно. Например, один из наиболее популярных CMS-конструкторов WIX не предоставляет возможности создания файла .htaccess.

Но настроить редирект 301 довольно просто в базовом редакторе.

Требования для протокола HTTPS

Для правильной работы протокола HTTPS на основе пакета NetX Web HTTP требуется, чтобы были установлены NetX Duo 5.10 или более поздней версии и NetX Secure TLS 5.11 или более поздней версии. Кроме того, должен быть создан экземпляр IP, для которого включено использование протокола TCP для работы с протоколом TLS. Сеанс TLS необходимо будет инициализировать с помощью соответствующих криптографических процедур и сертификата доверенного ЦС. Кроме того, потребуется выделить пространство для сертификатов, которые будут предоставляться удаленными узлами сервера во время подтверждения TLS. Этот процесс показан в демонстрационном файле в разделе «Пример небольшой системы HTTPS» главы 2.

Для HTTPS-клиента из пакета NetX Web HTTP больше нет дополнительных требований.

Но HTTPS-сервер из пакета NetX Web HTTP определяет еще несколько дополнительных требований. Во-первых, ему требуется полный доступ к известному TCP-порту 443 для обработки всех HTTPS-запросов клиента (как и в случае протокола HTTP без шифрования, приложение может изменить этот порт). Во-вторых, потребуется инициализировать сеанс TLS с помощью соответствующих криптографических процедур и сертификата удостоверения сервера (или общего ключа). HTTPS-сервер также разработан для работы с внедренной файловой системой FileX. Если система FileX недоступна, пользователь может перенести используемые разделы FileX в собственную среду. Использование FileX рассматривается в последующих разделах этого руководства.

Дополнительные сведения о параметрах конфигурации TLS см. в документации по NetX Secure.

Если не указано иное, все функции HTTP, описанные в этом документе, также относятся к протоколу HTTPS.

Переходим на HTTPS

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

Шаг 1: Подготовка сайта

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

Чтобы избежать предупреждения, указанного выше, необходимо изменить все внутренние ссылки с абсолютных на относительные. Например, ссылку http://ssl.ru/testpage/ потребуется заменить на /testpage/. Также стоит внимательно проверить все ссылки на скрипты в коде страниц. 

Второй момент — проверка медиаконтента, в который входят изображения, видеоклипы, презентации и прочее. Необходимо посмотреть, какой на страницах сайта используется контент и по какому протоколу он запрашивается. Если используется HTTP, то рекомендуется загрузить все файлы на сервер и установить относительные ссылки. В противном случае указывайте только проверенные сайты: YouTube, Facebook, VK и так далее.

Теперь можно переходить к подключению SSL.

Шаг 2: Установка SSL-сертификата

Устанавливаем SSL:

Проверить подлинность сертификата можно на различных сервисах, например, Namecheap. Все просто: вводим домен с портом 443 и жмем «Check». При успешной проверке будет отображена надпись «It’s all good. We have not detected any issues».

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

Шаг 3: Настройка редиректа на HTTPS

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

Первый вариант:

RewriteEngine On

RewriteCond %{SERVER_PORT} !^443$

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} 

Второй вариант:

RewriteEngine On

RewriteCond %{HTTPS} =off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 

Третий вариант:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} 

Также мы можем сделать редирект с HTTP через административную панель CMS системы. В OpenCart для этого нужно открыть файл config.php и прописать в него следующее:

define('HTTPS_SERVER', 'https://yourdomain.com/');

В WordPress изменить wp-config.php:

define('FORCE_SSL_ADMIN', true);

Для получения подробной информации о редиректах на других CMS обратитесь к их документации.

Шаг 4: Настройка для поисковых систем

Если ваш сайт индексируется Google, Яндекс или другими поисковиками, то после перехода на HTTPS необходимо им об этом сообщить. В частности, нужно:

1. Изменить все теги «rel=canonical» в HTML-коде. Они должны указывать на ссылки с защищенным протоколом.
2. В файлы robots.txt и sitemap.xml необходимо добавить страницы с HTTPS.
3. Проверить корректность указанных данных в Яндекс.Метрика и Google Search Console.
4. Проверить отображение и доступность вашего сайта через поисковик.

Готово! На этом переход с HTTP на HTTPS завершен. Надеюсь, что у вас не возникло сложностей

Спасибо за внимание!

2019

Google придумала, как заставить сайты перейти на HTTPS

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

Загружаемые сайтами ресурсы по HTTPS и по HTTP называются «смешанным контентом» и представляют собой проблему с самого первого дня внедрения HTTPS

В течение нескольких лет браузеры игнорировали проблему «смешанного контента», для них было важно лишь, чтобы главный домен загружался по HTTPS.. Тем не менее, в последнее время компании Google и Mozilla, каждая по своему, активно продвигают HTTPS

Mozilla и ее партнеры запустили сервис Let’s Encrypt, предоставляющий бесплатные, простые в развертывании TLS-сертификаты. В свою очередь, Google Chrome стал обозначать загружаемые по HTTP сайты как небезопасные (Not Secure).

Тем не менее, в последнее время компании Google и Mozilla, каждая по своему, активно продвигают HTTPS. Mozilla и ее партнеры запустили сервис Let’s Encrypt, предоставляющий бесплатные, простые в развертывании TLS-сертификаты. В свою очередь, Google Chrome стал обозначать загружаемые по HTTP сайты как небезопасные (Not Secure).

Теперь же Google намерена пойти еще дальше и заставить сайты полностью перейти на HTTPS. Начиная с версии Chrome 79, в браузер постепенно будут вноситься изменения, которые в итоге приведут к полной блокировке «смешанного контента» по умолчанию. Уже в Chrome 80 «смешанные» аудио и видео будут автоматически обновляться до HTTPS. В случае невозможности загрузки контента по HTTPS, он будет блокироваться. В Chrome 81 этот подход будет также применяться к «смешанным» изображениям.

Власти Казахстана перехватывают трафик Facebook, Google и «ВКонтакте»

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

Правительство Казахстана начало перехватывать весь HTTPS-трафик в стране

17 июля 2019 года правительство Казахстана начало перехватывать весь интернет-трафик HTTPS в стране. Для этого местных телекоммуникационных операторов обязали к тому, чтобы заставлять пользователей на все свои устройства и в браузеры специальный сертификат, разработанный властями.

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

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

Без установки сертификата зайти на сайты с HTTPS (а таких большинство) нельзя — интернет-провайдер блокирует доступ и выдаёт страницу-заглушку, подобную той, которая представлена ниже.

Жителей Казахстана обязали установить сертификат безопасности «для защиты от хакерских атак и просмотра противоправного контента»

На этой странице выведено следующее сообщение:

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

Операторы Kcell и Activ заявили, что сертификат был внедрен из-за участившихся случаев хищения персональных данных казахстанцев и кражи денег с их банковских карт. Он защитит абонентов «от хакерских атак и просмотра противоправного контента». У сертификата не будет доступа к персональным данным абонента, утверждают Kcell.

Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git

Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою «копию» проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор).

Протокол https и в чем разница между https и http

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

Основные различия между https и http:

• безопасный протокол https является расширением основного протокола http, но никак не отдельной единицей;
• передача данных посредством безопасного протокола https защищена шифрованием;
• использование различных портов: 80 порт для http, 443 порт для https.

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

Как это работает?

Попробуем разобраться, как работает эта конфигурация htaccess редиректа http на https. Это поможет внести необходимые изменения:

RewriteEngine On

Первая строка позволяет Apache запустить механизм преобразования http-ссылок, необходимый для выполнения перенаправления:

RewriteCond %{HTTPS} off 
RewriteCond %{HTTP_HOST} !^www. 

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

Первое условие определяет, использует ли запрос URL не-HTTPS. Второе условие определяет, использует ли запрос URL www. Заметьте, я использовал www.а не www., потому что образец является регулярным выражением и точка здесь используется для экранирования. Следовательно, ее нужно оставить:

RewriteCond %{HTTP_HOST} ^(?:www.)?(.+)$ 

Четвертая строка — она соответствует имени хоста входящего запроса, и разделяет его на www часть (если таковая имеется), и остальную часть имени хоста. Мы будем ссылаться на нее позже с помощью %1 в RewriteRule.

Если вы знаете имя хоста заранее, то можно улучшить правило редиректа с http на https, встроив URL и пропустив это условие (пример ниже):

RewriteRule ^ https://www.%1%{REQUEST_URI} 

RewriteRule – центральный элемент перенаправления. С помощью этой строки мы предписываем Apache перенаправить любой запрос на новый URL, который состоит из:

• https: // WWW;
• %1: Ссылка на без-WWW часть хоста;
• %{REQUEST_URL}: URL-запрос, без имени хоста.

Все эти маркеры соединены друг с другом, и представляют собой конечный URL перенаправления. В конце мы добавляем три флага:

• NE — чтобы не выйти из специальных символов;
• R=301 — использовать HTTP статус 301 редиректа;
• L — прекратить обработку других правил, и немедленно перенаправить.

Настройка резервирования пространства имен

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

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

В следующем примере используется средство Netsh.exe:

Эта команда добавляет резервирование URL-адресов для указанного пространства имен URL-адреса для учетной записи DOMAIN\user. Для получения дополнительных сведений об использовании команды netsh введите в командной строке и нажмите клавишу ВВОД.

HTTP/2 работает быстрее?

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

На первом скриншоте вы видите скорость загрузки страницы посредством
протокола http/1.1:

А вот результаты тестирований загрузки документа при помощи HTTP/2:

Результат налицо – страница загрузилась на 23% быстрее, чем в
первом случае. Специалисты уверяют, что технология будет дорабатываться и они
смогут достичь ускорения практически на 30%.

Зимой 2016 года проводилось еще несколько исследований
ускорения ресурсов после их перевода на протокол http/2. По результатам тестирования
нескольких оптимизированных сайтов установлено, что у пользователей они стали
загружаться на 13-18% быстрее, чем во время использования http 1.1.

Но есть и эксперименты, противоречащие таким впечатляющим результатам. Так, на сайте habr.com был опубликован эксперимент специалистов Яндекс.Почта и сервера Nginx. Оговорюсь, что исследовался SPDY, но по используемым технологиям он очень похож на HTTP/2.

Команда Яндекса установила, что у большинства их пользователей скорость загрузки в среднем увеличилась лишь на половину процента. Но плюсы от внедрения SPDY эксперты почтового сервиса поисковика все же отметили. Из-за уменьшения количества соединений с серверами, чем и характерны протоколы http/2 и SPDY, существенно уменьшилась и нагрузка на них.

Как перейти на HTTPS

Выбор времени перехода

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

Подготовка сайта к переходу

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

1. Если на внутренних ссылках есть указание на протокол, уберите его. Это нужно, чтобы не возникло ошибок при индексации. К примеру, если раньше ссылка выглядела как «http://site.ru/text/», приведите ее в форму «//site.ru/text/».
2. То же самое нужно сделать со внешними ссылками, привести их url в относительный вид. Иначе могут появиться сбои при функционировании сайта.
3. Адреса медиаконтента тоже нужно перевести в относительные ссылки. Если объекты базируются на вашем сайте, то этого достаточно. Если некоторые медиа подгружаются со сторонних ресурсов, то проверьте, поддерживают ли они HTTPS. Не поддерживают — заменяйте, они не будут работать на вашем сайте после смены протокола. Это можно сделать быстрее, если исправить протокол на относительный сразу в базе данных для всех ссылок.
4. Ссылки в rel=»canonical» и rel=»alternate» также замените на относительные.
5. Проверьте, что сторонние сервисы, которые вы используете на сайте, поддерживают HTTPS. Популярные обычно поддерживают этот протокол, к примеру Яндекс.Метрика, Директ, Google Analytics, но другие стоит проверить.

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

Заключение

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

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

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