Для чего нужен http

Зачем нужен HTTP/2 для сайтов

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

Что такое HTTP/2 и зачем он нужен

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

Действительно ли HTTP/2 работает быстрее?

Специалисты из HttpWatch провели несколько тестов и выявили серьезное ускорение от использования HTTP/2.

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

А на этом скриншоте — результат с использованием HTTP/2:

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

Существует еще несколько сервисов, которые предоставляют демо или дают возможность проверить разницу в скорости на живом сайте: HTTPvsHTTPS и LoadImpact.

Специалисты Айри.рф также провели тестирование в январе-феврале 2016 года, чтобы выяснить, сколько может выиграть реальный (небольшой или средний) сайт после перевода на протокол HTTPS + HTTP/2. В среднем по нескольким сайтам, которые уже прошли предварительную оптимизацию по скорости (сжатие и объединение файлов, сетевая оптимизация), клиентская скорость загрузки выросла на 13-18% только за счет включения HTTP/2.

Стоит упомянуть, что не все эксперименты были столь однозначны. На Хабре уже был описан эксперимент, поставленный командой Яндекс.Почты. Тестировался протокол SPDY, но напомним, что HTTP/2 разрабатывался на основе SPDY и очень близок к нему в плане используемых методов.

Команда «Яндекс.Почты», протестировав SPDY на части своих реальных пользователей, установила, что среднее время загрузки изменилось всего лишь на 0,6% и не превысило статистической погрешности. Однако специалисты «Яндекс.Почты» обнаружили, тем не менее, положительный момент от использования SPDY. Поскольку число соединений с серверами уменьшилось (это ключевая особенность SPDY и HTTP/2), то нагрузка на серверы заметно сократилась).

Почему важно искать возможности ускорить загрузку страниц сайта?

Джон Мюллер, аналитик из команды Google Webmaster Trends, в своем блоге Google+ написал, что наличие на сайте поддержки HTTP/2 не является напрямую ранжирующим фактором в Google. В то же время, скорость загрузки — сама по себе значительный фактор ранжирования, поэтому имеет смысл начать использовать HTTP/2 для SEO-продвижения.

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

Джон Мюллер также сообщил, что Googlebot скоро начнет поддерживать HTTP/2. И кто знает — может, в будущем наличие HTTP/2 на сайте и станет ранжирующим фактором. Ведь поисковики постоянно меняют алгоритмы.

Какие браузеры уже поддерживают HTTP/2?

IE 11 в Windows 10;
Edge 12 и 13;
Firefox 36 — 45;
Chrome 41 — 49;
Safari 9;
Opera 28 — 34;
Safari для iOS 9.1;
Opera 30 для Android;
Chrome 46 для Android;
Firefox 41 для Android.

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

Безопасность сайтов

Переход на HTTP/2 (сейчас) автоматически означает переход на HTTPS (защищенный режим работы сайта), другие режимы не поддерживаются браузерами. HTTPS шифрует весь трафик сайта и требует установленного сертификата (нормальный DV-сертификат можно получить и абсолютно бесплатно, например, через WoSign или Let’s Encrypt).

Шифрование сайта поможет не только HTTP/2. Google уже объявил, что шифрование сайта является положительным сигналом ранжирования.

Дает ли что-то HTTP/2 веб-разработчикам?

Как подключить HTTP/2

Эпоха HTTP/2 совсем близко: многие браузеры уже поддерживают этот протокол. Его внедрение не требует никаких изменений в самом сайте: не нужно менять URL страниц, не нужно менять ссылки, ставить редиректы, добавлять или менять какую-то разметку или указывать дополнительные данные для Google Search Console или «Яндекс.Вебмастер» (если ваш сайт уже используется HTTPS). Если ваш сайт пока не использует защищенный режим, то для использования HTTP/2 нужно будет подключить HTTPS (со всеми сопутствующими действиями).

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

Если вы используете собственный виртуальный или выделенный сервер, то поддержка HTTP/2 добавляется на уровне модуля к nginx (дополнительно потребуется установить SSL-сертификат и ключ на сервер): на Хабре уже публиковали неплохую инструкцию и здесь.

Проверить поддержку HTTP/2 можно либо через браузерные расширения для Firefox или Chrome, либо через проверку скорости на сайте Айри.рф: в случае поддержки HTTP/2 в результатах проверки будет зеленая плашка [HTTP/2.0].

Источник

Протокол HTTP¶

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) — символьно-ориентированный клиент-серверный протокол прикладного уровня без сохранения состояния, используемый сервисом World Wide Web.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier – уникальный идентификатор ресурса) в запросе клиента. Основными ресурсами являются хранящиеся на сервере файлы, но ими могут быть и другие логические (напр. каталог на сервере) или абстрактные объекты (напр. ISBN). Протокол HTTP позволяет указать способ представления (кодирования) одного и того же ресурса по различным параметрам: mime-типу, языку и т. д. Благодаря этой возможности клиент и веб-сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

Структура протокола¶

Структура протокола определяет, что каждое HTTP-сообщение состоит из трёх частей (рис. 1), которые передаются в следующем порядке:

Рис. 1. Структура протокола HTTP (дамп пакета, полученный сниффером Wireshark)

Стартовая строка HTTP¶

Cтартовая строка является обязательным элементом, так как указывает на тип запроса/ответа, заголовки и тело сообщения могут отсутствовать.

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

Стартовая строка ответа сервера имеет следующий формат:

Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:

Методы протокола¶

Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами (Табл. 1). Названия метода чувствительны к регистру.

Таблица 1. Методы протокола HTTP

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

Для того чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Результат выполнения этого метода не кэшируется.

Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса. Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»: GET /path/resource?param1=value1¶m2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[4] — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.

Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно.

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

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

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

В отличие от метода GET, метод POST не считается идемпотентным[4], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).

При результатах выполнения 200 (Ok) и 204 (No Content) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствуют находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

Аналогично PUT, но применяется только к фрагменту ресурса.

Удаляет указанный ресурс.

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

Устанавливает связь указанного ресурса с другими.

Убирает связь указанного ресурса с другими.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Наиболее востребованными являются методы GET и POST — на человеко-ориентированных ресурсах, POST — роботами поисковых машин и оффлайн-браузерами.

Прокси-сервер

Коды состояния¶

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

Рис. 1. Структура кода состояния HTTP

Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

Применяемые в настоящее время классы кодов состояния и некоторые примеры ответов сервера приведены в табл. 2.

Таблица 2. Коды состояния протокола HTTP

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

Примеры ответов сервера:

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

Примеры ответов сервера:

Коды статуса класса 3xx сообщают клиенту, что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. «редирект»).

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

Примеры ответов сервера:

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Примеры ответов сервера:

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

Примеры ответов сервера:

Заголовки HTTP¶

Заголовок HTTP (HTTP Header) — это строка в HTTP-сообщении, содержащая разделённую двоеточием пару вида «параметр-значение». Формат заголовка соответствует общему формату заголовков текстовых сетевых сообщений ARPA (RFC 822). Как правило, браузер и веб-сервер включают в сообщения более чем по одному заголовку. Заголовки должны отправляться раньше тела сообщения и отделяться от него хотя бы одной пустой строкой (CRLF).

Название параметра должно состоять минимум из одного печатного символа (ASCII-коды от 33 до 126). После названия сразу должен следовать символ двоеточия. Значение может содержать любые символы ASCII, кроме перевода строки (CR, код 10) и возврата каретки (LF, код 13).

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

Пример заголовков ответа сервера:

Все HTTP-заголовки разделяются на четыре основных группы:

Сущности (entity, в переводах также встречается название “объект”) — это полезная информация, передаваемая в запросе или ответе. Сущность состоит из метаинформации (заголовки) и непосредственно содержания (тело сообщения).

В отдельный класс заголовки сущности выделены, чтобы не путать их с заголовками запроса или заголовками ответа при передаче множественного содержимого (multipart/ * ). Заголовки запроса и ответа, как и основные заголовки, описывают всё сообщение в целом и размещаются только в начальном блоке заголовков, в то время как заголовки сущности характеризуют содержимое каждой части в отдельности, располагаясь непосредственно перед её телом.

В таблице 3 приведено краткое описание некоторых HTTP-заголовков.

Таблица 3. Заголовки HTTP

В листинге 1 приведен фрагмент дампа заголовков при подключении к серверу http://example.org

Листинг 1. Заголовки HTTP

Тело сообщения¶

Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи сущности, связанной с запросом или ответом. Тело сообщения (message-body) отличается от тела сущности (entity-body) только в том случае, когда при передаче применяется кодирование, указанное в заголовке Transfer-Encoding. В остальных случаях тело сообщения идентично телу сущности.

Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) может быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body).

Все ответы содержат тело сообщения, возможно нулевой длины, кроме ответов на запрос методом HEAD и ответов с кодами статуса 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified).

Источник

HTTP и HTTPS: в чём разница, и что использовать?

10 минут на чтение

Оглавление

Чем опасно использование HTTP?

Для того чтобы ответить на вопрос о целесообразности отказа от HTTP, необходимо понять, каким образом функционирует этот протокол.

Начнем с определения. HTTP — это аббревиатура, образованная от «Hypertext Transfer Protocol» («Протокол передачи гипертекста»). Веб-браузеры и серверы, используя протокол HTTP, указывают, что они являются частью Всемирной паутины (WWW). Проблема с HTTP заключается в том, что его изобрели в 1989 году. В то время разработчиков, как и пользователей, не очень беспокоил вопрос интернет-безопасности. Гораздо важнее было разработать унифицированный стандарт, который позволит пользователям со всего мира выходить онлайн и пользоваться нужными сайтами.

Проблемы с HTTP начались уже в 1990-х, одновременно с глобальным распространением интернета. Появилось много популярных сайтов, на некоторых ввели систему онлайн-платежей. Тогда и начали активно действовать злоумышленники. Они похищали пользовательские данные либо рушили серверы с сайтами. Киберпреступность процветала, в частности, из-за уязвимости в протоколе HTTP. Чтобы понять её суть, нам необходимо подробнее рассмотреть матчасть, и узнать, в чём отличие HTTP от HTTPS.

Принцип действия HTTP

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

Еще хуже, что хакеры могут перехватить трафик на сайт и добавить небольшие фрагменты кода (сниппеты) к каждому пакету данных. В марте 2015 года по такой схеме хакеры реализовали DDoS-атаку на сайты GreatFire.org и GitHub. Через серверы, которые предположительно имеют связь с «Великим китайским файерволом», хакеры смогли обрушить серверы GitHub. Сайт не работал на протяжении 5 минут, пока системные администраторы подключали резервный сервер. Это крупнейшая, но не единственная атака на сайт, которая стала возможной из-за использования протокола HTTP.

Сейчас, во время повсеместного распространения высокоскоростного интернета, использовать HTTP не нужно даже домохозяйкам, которые ведут небольшой блог о кулинарии. Впрочем, возможная атака на сайт — это не единственная угроза для владельца. Об этом мы скажем ниже.

Буква «s» в названии протокола HTTPS означает «secure», т.е. защищенный. Веб-браузеры и сайты, которые используют протокол HTTPS, отправляют данные, защищенные криптошифрованием. То есть на пути от компьютера пользователя до сервера веб-приложения информация курсирует в нечитабельном виде. Это рандомный набор знаков. Основное достоинство протокола заключается в том, что дешифровка данных происходит в рамках одной веб-сессии. То есть невозможно подобрать универсальный дешифровщик, который позволит приводить любые данные в удобочитаемый вид.

Рассмотрим подробнее, как функционирует протокол HTTPS. Для передачи данных используется подслой — криптографический протокол, который обеспечивает шифровку/дешифровку данных.

В вебе используют криптографические протоколы SSL (secure sockets layer) и TLS (transport layer security). Эти протоколы построены на алгоритме асиметричного ключа, который состоит из двух ключей — публичного и частного. Публичные ключи доступны и сайтам и браузерам, частные — хранятся на собственных серверах веб-приложений.

Сайты, которые используют HTTPS, имеют уникальный цифровой сертификат (например, SSL-сертификат), который выдан центром сертификации (Certification authority, CA). Когда интернет-пользователь заходит на такой сайт, сервер передает браузеру данные о сертификате и публичный ключ. Веб-браузер использует публичный ключ, чтобы установить цифровую подпись в сертификате. Затем веб-браузер сравнивает подпись с данными, которые получены от CA. Если сертификат действительный, будет установлено соединение с сайтом, а в адресной строке браузера появится пиктограмма в виде зеленого замка. В случае, если на сайте сертификат отсутствует или он не подтвержден браузером, появится соответствующее уведомление, а в адресной строке появится красный замок.

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

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

Источник

• Популярная книга Круть доступна для чтения прямо сейчас на нашем сайте boochi.ru. Скачать книгу в формате FB2, TXT, PDF, EPUB бесплатно без регистрации. →