Для World Wide Web. Такие протоколы представляют собой структурированный текст, который использует логические связи (гиперссылки) между узлами, содержащими определенные данные. Таким образом, это способ обмена или передачи гипертекста.
HTTP-протокол работает как функция запрос-ответ в клиентско-серверной модели вычислений. Так, веб-браузер выступает в роли клиента, а хостинг сайта является сервером. Клиент отправляет сообщение запроса HTTP на сервер, предоставляющий определенные ресурсы (например, HTML-файлы и другие материалы), а затем возвращает ответное сообщение. Ответ содержит информацию о запросе, и также может содержать запрошенное содержимое в теле сообщения.
Браузер является основным примером агента пользователя (клиента). Другие типы пользовательских агентов включают в себя программное обеспечение, используемое для индексации поисковыми провайдерами, мобильные приложения и другие ресурсы, которые используют или отображают веб-контент.
HTTP-протокол предназначен для обеспечения промежуточных элементов сети для повышения или обеспечения связи между клиентами и серверами. Сайты с большим трафиком часто извлекают для себя выгоду из кэша веб-серверов, которые отображают контент от имени вышестоящих ресурсов, уменьшая время загрузки. Кэш веб-браузеров при этом позволяет пользователю уменьшить сетевой трафик. Прокси-сервера, которые использует HTTP-протокол в локальной сети, могут обеспечить связь для клиентов, не допускающих глобальную маршрутизацию адреса, путем ретрансляции сообщений с внешних серверов.
Сессия HTTP представляет собой последовательный процесс из запросов и ответов. Клиент инициирует запрос путем создания TCP-подключения к определенному порту на сервере, а последний прослушивает этот порт и ждет сообщение с запросом. При его получении сервер посылает в ответное сообщение. Тело этого сообщения, как правило, представляет собой запрошенный ресурс, хотя может быть отображено и сообщение об ошибке или другая информация.
Если рассматривать назначение протокола HTTP, следует отметить, что он определяет методы с целью указать нужное действие, выполняемое по выявленным ресурсам. При этом вид отображаемой информации (ранее существовавшие данные или генерируемые динамически) зависит от реализации сервера. Часто такой ресурс соответствует файлу или сценарию, расположенному на хостинге.
Некоторые методы, которые использует протокол передачи гипертекста HTTP, предназначены только для поиска информации и при этом не должны изменять состояние сервера. Другими словами, они не оказывают серьезного воздействия, за исключением относительно безвредных эффектов - кэширования или увеличения статистики посещений.
С другой стороны, HTTP-протокол может применять и такие методы, которые предназначены для действий, способных оказать влияние либо на сервер, либо на другие внешние ресурсы - активизировать финансовые операции или выполнить передачу электронной почты. Изредка такие способы используются веб-роботами или некоторыми сайтами и могут делать запросы вне зависимости от основной задачи.
.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
Прокси-серверы
История развития
HTTP/0.9
Кроме обычного метода GET , различают ещё и . Условные запросы GET содержат заголовки If-Modified-Since , If-Match , If-Range и подобные. Частичные GET содержат в запросе Range . Порядок выполнения подобных запросов определён стандартами отдельно.
HEAD
Аналогичен методу GET , за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных , проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.
POST
Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами - текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
В отличие от метода GET , метод POST не считается идемпотентным , то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location .
Сообщение ответа сервера на выполнение метода POST не кэшируется.
PUT
Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).
Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT , клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются.
PATCH
Аналогично PUT, но применяется только к фрагменту ресурса.
DELETE
Удаляет указанный ресурс.
TRACE
Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе.
LINK
Устанавливает связь указанного ресурса с другими.
UNLINK
Убирает связь указанного ресурса с другими.
CONNECT
Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через нешифрованный прокси.
Коды состояния
Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр . Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:
201 Webpage Created 403 Access allowed only for registered users 507 Insufficient Storage
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC . Введение новых кодов должно производиться только после согласования с IETF . Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния.
1xx Informational (рус. Информационный )В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
2xx Success (рус. Успех )Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
3xx Redirection (рус. Перенаправление )Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов , , , и относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location . При этом допускается использование фрагментов в целевом URI.
4xx Client Error (рус. Ошибка клиента )Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD , сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
Для запоминания значений кодов с 400 по 417 существуют приёмы иллюстративной мнемотехники
5xx Server Error (рус. Ошибка сервера )Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD , сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
Заголовки
Тело сообщения
Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения (message-body) отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.
Message-body = entity-body
|
Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding - это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.
Правила, устанавливающие допустимость тела сообщения в сообщении, отличны для запросов и ответов.
Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) МОЖЕТ быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body).
Включается или не включается тело сообщения (message-body) в сообщение ответа зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения (message-body), даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения (message-body). Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.
Примеры диалогов HTTP
Обычный GET-запрос
Различают два основных типа согласований:
- Управляемое сервером (англ. Server-Driven ).
- Управляемое клиентом (англ. Agent-Driven ).
Одновременно могут быть использованы оба типа или каждый из них по отдельности.
В основной спецификации по протоколу (RFC 2616) также выделяется так называемое прозрачное согласование (англ. Transparent Negotiation ) как предпочтительный вариант комбинирования обоих типов. Последний механизм не следует путать с независимой технологией Transparent Content Negotiation (TCN, рус. Прозрачное согласование содержимого , см. RFC 2295), которая не является частью протокола HTTP, но может использоваться с ним. У обоих существенное различие в принципе работы и самом значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN прозрачность означает доступность полного списка вариантов ресурса для всех участников процесса доставки данных.
Управляемое сервером
При наличии нескольких версий ресурса сервер может анализировать заголовки запроса клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном анализируются заголовки Accept , Accept-Charset , Accept-Encoding , Accept-Languages и User-Agent . Серверу желательно включать в ответ заголовок Vary с указанием параметров, по которым различается содержимое по запрашиваемому URI.
Географическое положение клиента можно определить по удалённому IP-адресу . Это возможно за счёт того что IP-адреса, как и доменные имена , регистрируются на конкретного человека или организацию. При регистрации указывается регион, в котором будет использоваться желаемое адресное пространство. Эти данные общедоступны, и в Интернете можно найти соответствующие свободно распространяемые базы данных и готовые программные модули для работы с ними (следует ориентироваться на ключевые слова «Geo IP»).
Следует помнить что такой метод способен определить местоположение максимум с точностью до города (отсюда определяется и страна). При этом информация актуальна только на момент регистрации адресного пространства. Например, если московский провайдер зарегистрирует диапазон адресов с указанием Москвы и начнёт предоставлять доступ клиентам из ближайшего Подмосковья, то его абоненты могут на некоторых сайтах наблюдать, что они из Москвы, а не из Красногорска или Дзержинского .
Управляемое сервером согласование имеет несколько недостатков:
- Сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, но не может знать точно, что именно нужно в данный момент (например, версия на русском языке или английском).
- Заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами - мало. Из-за этого оборудование испытывает избыточную нагрузку.
- Общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на идентичные запросы от разных пользователей.
- Передача заголовков Accept также может раскрывать некоторые сведения о его предпочтениях, таких как используемые языки, браузер, кодировка.
Управляемое клиентом
В данном случае тип содержимого определяется только на стороне клиента. Для этого сервер возвращает с кодом состояния 300 (Multiple Choices) или 406 (Not Acceptable) список вариантов, среди которых пользователь выбирает подходящий. Управляемое клиентом согласование хорошо, когда содержимое различается по самым частым параметрам (например, по языку и кодировке) и используется публичный кэш.
Основной недостаток - лишняя нагрузка, так как приходится делать дополнительный запрос, чтобы получить нужное содержимое.
Прозрачное согласование
Данное согласование полностью прозрачно для клиента и сервера. В данном случае используется общий кэш, в котором содержится список вариантов, как для управляемого клиентом согласования. Если кэш понимает все эти варианты, то он сам делает выбор, как при управляемом сервером согласовании. Это снижает нагрузки с исходного сервера и исключает дополнительный запрос со стороны клиента.
В основной спецификации по протоколу HTTP механизм прозрачного согласования подробно не описан.
Множественное содержимое
Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но в виде иерархии с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиатипы multipart/* . Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиа типом). Если получателю не известно как работать с типом, то он обрабатывает его так же, как multipart/mixed .
Параметр boundary означает разделитель между различными типами передаваемых сообщений. Например передаваемый из формы параметр DestAddress передает значение e-mail адреса, а последущий за ним элемент AttachedFile1 отправляет двоичное содержимое изображения формата.jpg
Со стороны сервера сообщения со множественным содержимым могут посылаться в ответ на при запросе нескольких фрагментов ресурса. В этом случае используется медиа тип multipart/byteranges .
Со стороны клиента при отправке HTML -формы чаще всего пользуются методом POST . Типичный пример: страницы отправки электронных писем со вложенными файлами. При отправке такого письма браузер формирует сообщение типа multipart/form-data , интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес получателя, сам текст и вложенные файлы:
POST /send-message.html HTTP/1.1 Host: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form-data; boundary="Asrf456BGe4h" Content-Length: (суммарный объём, включая дочерние заголовки) Connection: keep-alive Keep-Alive: 300 (пустая строка) (отсутствующая преамбула) --Asrf456BGe4h Content-Disposition: form-data; name="DestAddress" (пустая строка) [email protected] --Asrf456BGe4h Content-Disposition: form-data; name="MessageTitle" (пустая строка) Я негодую --Asrf456BGe4h Content-Disposition: form-data; name="MessageText" (пустая строка) Привет, Василий! Твой ручной лев, которого ты оставил у меня на прошлой неделе, разодрал весь мой диван. Пожалуйста, забери его скорее! Во вложении две фотки с последствиями. --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg" Content-Type: image/jpeg (пустая строка) (двоичное содержимое первой фотографии) --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg" Content-Type: image/jpeg (пустая строка) (двоичное содержимое второй фотографии) --Asrf456BGe4h-- (отсутствующий эпилог)
В примере в заголовках Content-Disposition параметр name соответствует атрибуту name в HTML-тегах и
Особенности протокола
Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies ; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.
При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов - в простейшем случае картинки в разных форматах).
Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.
Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это коммерциализировало Интернет, появились компании, основным полем деятельности которых стало предоставление доступа в Интернет (провайдеры) и создание сайтов.
Примечания
См. также
Ссылки
Если вы хотели узнать, как передаются данные в интернете - эта статья для вас. Я расскажу вам все что знаю о протоколах HTTP и HTTPS, покажу разницу и отличия между ними. Приятного чтения!
HTTP 1.1 - что это за протокол?
HTTP (англ. «протокол передачи гипертекста») - сетевой протокол верхнего уровня для передачи гипертекстовых и произвольных данных в интернете.
При помощи HTTP браузер получает данные от веб-серверов и может отображать их в приемлемом и понятном для интернет-пользователей виде. Точно также происходит и обратный процесс - отправку пользовательских данных обратно, на сервер (например, при регистрации).
Контент отправляемый с сервера и на сервер может быть представлен в любом виде: рисунков, файлов, документов, ссылок и кода - в любом случае, именно благодаря HTTP люди могут пользоваться интернетом и загружать в браузере сотни веб-страниц.
Актуальная версия протокола - 1.1. Ее описание находится в спецификации RFC.
HTTP используется в клиент-серверной инфраструктуре передачи данных. Как это работает? Приложение на стороне «клиент» формирует запрос для обработки на стороне «сервер», после чего ответ отправляется обратно «клиенту». Затем «клиент» может инициировать дополнительные запросы, получать новые ответы. И так далее.
Наиболее распространенное «клиентское» приложение это веб-браузер через который осуществляется доступ к веб-ресурсам. С развитием мобильных технологий к браузерам добавились еще мобильные приложения на разнообразных смартфонах и планшетах. Причем серверная сторона современных многопрофильных приложений может одновременно обрабатывать данные и из браузера, и со смартфона. Все это через протокол HTTP.
Более того, HTTP часто выступает как протокол-транспорт для трансфера других прикладных протоколов и их API: WebDAV, XML-RPC, REST, SOAP. Ну а данные передаваемые по API могут иметь самый разный формат: XML, JSON и другие.
Как передаются эти данные? Чаще всего по TCP/IP-соединению: приложение-клиент по умолчанию использует TCP-порт 80, а сервер может использовать любой другой, но обычно это тоже 80 порт.
Объект манипуляций в HTTP это ресурс, указываемый в URI запроса клиентского приложения, чтобы корректно идентифицировать «что вообще нужно». Обычно это файлы, данные или логические объекты, которые хранятся на сервере. При этом в запросе можно указать, как именно представить одни и те же данные: какой выбрать формат, кодировку, язык. Такая «фича» позволяет обмениваться не только гипертекстом, но и двоичными данными.
Второй особенностью HTTP является отсутствие сохранения состояния между последовательными парами «запрос-ответ». Но это не проблема, потому что компоненты приложений на клиентской или серверной стороне само могут хранить информацию о состоянии последних запросов и ответов. На стороне клиента такая информация называется cookies («куки»), на стороне сервера - sessions («сессии»).
При этом для клиентского браузера не проблема следить за задержкой ответа сервера, а для сервера - хранить заголовки последних запросов и IP-адреса клиентов. Но, еще раз подчеркну, сам протокол об этом ничего не знает - он только передает данные.
Принимать участие в передаче данных могут и посредники (прокси-сервера), для того чтобы отличить прокси от конечных серверов (т.н. «исходный сервер»).
Самое волшебство начинается, когда одна и та же программа (клиентская или серверная) может выполнять функции посредник, клиента, сервера - в зависимости от задач.
HTTP/2 - а это что за протокол?
Первоначальная версия протокола HTTP появилась в ЦЕРНЕ (CERN) в 1991 году. Уже в 1992 году была опубликована публичная версия HTTP 0.9 и его спецификация, благодаря чему были упорядочены правила взаимодействия между клиентскими и серверными приложениями, а также четкому разграничению функциональности.
В 1996 году появился HTTP/1.0, а современная версия протокола - HTTP/1.1 - в 1999 году. На рубеже тысячелетий, протокол HTTP научился поддерживать режим постоянного соединения, т.е. оставлять соединение открытым после того как получен ответ на запрос. Это позволило за одно соединение посылать сразу несколько запросов, а не открывать-закрывать сессию каждый раз.
Шло время и по мере развития интернета размер страниц увеличивался, росло количество запросов - требовалось все больше ресурсов. Так сформировалась потребность в новом протоколе.
И спустя шестнадцать лет, в 2015 году была опубликована финальная версия черновика спецификации следующей версии протокола - HTTP/2. Бинарный протокол HTTP/2 более подготовлен к современным реалиям, чем прародитель HTTP 1.1 потому что новый протокол решает наиболее существенную проблему передачи данных в интернете - несколько отрытых соединений.
А все потому что нынешние сайты подгружают много элементов, как со своего сервера, так и с CDN: JS-скрипты, CSS-стили, шрифты и картинки. При передаче полного комплекта файлов по протоколу HTTP 1.1 создается несколько соединений. Если мы в будущем перейдем на протокол HTTP/2 - передача будет происходить в рамках одного соединения между клиентом и сервером, что позволит существенно ускорить и оптимизировать загрузку содержимого сайта.
Ключевые особенности HTTP/2, которые будут полезны для сайтов:
- Расстановка и управление приоритетами запросов/потоков - клиент самостоятельно задает для сервера приоритетность ресурсов и данных
- Сжатие HTTP заголовков;
- Мультиплексирование запросов или параллельная загрузка по TCP-соединению нескольких элементов сайта - через одно соединение отправляется несколько запросов, а ответы клиент может получать в любом порядке т.е. теперь не нужны несколько открытых TCP-соединений;
- Наличие и поддержка со стороны сервера проактивных push-уведомлений - сервер самостоятельно может отправлять данные для клиента, которые тот еще не запросил (например на основании информации о том, какую страницу пользователь откроет после этой).
Конечно, главное здесь это мультиплексирование потоков. Принцип работы объяснить проще простого: пакеты TCP/IP-соединения смешиваются в рамках одного соединения. Так, в смешанном режиме происходит соединение нескольких «вагонов данных» в один «состав поезда», которые разделяются «по приезду». Ранее «вагоны» были вынуждены ехать дольше и раздельно, сейчас они будут ехать вместе и быстрее.
Вышеперечисленные преимущества протокола HTTP/2 позволят веб-разработчикам дышать полной грудью и отказаться от таких «костылей» как:
- Использование большего числа родственных доменов для обеспечения установки большого количества TCP/IP-соединений (для скачивания файлов);
- Спрайты картинок - когда изображения объединяются в один файл, чтобы снизить число запросов к веб-серверу (а сам файл «раздувается» ведь в него записано больше изображений);
- Объединение CSS- и JS-файлов, которые тоже делаются для уменьшения запросов.
Последнее очевидное преимущество заключается в том, что с самим сайтом (для включения HTTP/2) ничего дополнительно делать не нужно - все работы проводятся на сервере чуть ли не в «1 клик», а для клиентов shared- и VPS-хостингов вообще пройдут незаметно.
Словом, заживем!
HTTP/2 создан и разработан на основе черновика протокола SPDY/3 (Google) и превзошел его - компания Гугл признала преимущества HTTP/2 более многообещающими и в будущем откажется от поддержки SPDY/2.
Прогнозируемое ускорение ответа сервера по протоколу HTTP/2 составит порядка 30%, - реальные тесты уже показали скорости на 19-23% выше и это не предел.
По результатам тестов компании Айри.рф, только от включения протокола HTTP/2 прирост скорости составляет 13-18% (без оптимизации). Почему это важно?
Несмотря на то, что поддержка сайтом протокола HTTP/2 на данный момент не влияет напрямую на ранжирование сайтов в Гугле и Яндекса, на позиции в выдаче влияет скорость загрузки. И раз протокол показывает более высокую скорость загрузки (что является довольно значительным фактором), косвенно он влияет и на ранжирование.
Прежде всего за счет поведенческих факторов. Ускорение загрузки позволяет пользователям меньше уставать и больше концентрироваться на изучении сайта: просматривать больше страниц и не покидать сайт из-за долгой загрузки (уменьшаются отказы).
Большая часть современных браузеров уже поддерживает HTTP/2 - через них проходит ~70% интернет-трафика:
- Chrome 41-52 и Chrome 46+ в Android;
- Firefox 36-48 и Firefox 41+ в Android;
- Opera 28-34 и Opera 30+ в Android;
- Safari 9 и Safari в iOS 9.1;
- IE 11 в Windows 10 и браузер Edge 12, 13.
Когда произойдет полноценный переход на HTTP/2 пока непонятно - вероятнее всего в самом ближайшем будущем. Главное что от HTTP/1.x никто не собирается поспешно отказываться. Как говорится: «Работает - не трогай».
Что значит и где применяется HTTPS-протокол?
Ну, про обмен данными по протоколу HTTP вы уже все знаете: любая передача данных осуществляется через запросы по этому протоколу-транспорту. А зачем тогда нужен HTTPS и что он из себя представляет? Ведь жили же нормально и без него?
Проблема в том что данные по HTTP не защищаются и передаются в открытом виде. Интернет - глобальная распределенная сеть узлов. И если вы передаете открытые данные по незащищенному протоколу (Wi-Fi в ТРЦ сюда тоже относится), то один из этих узлов может перехватить их.
Не специально конечно, может быть просто взлом усилиями злоумышленников. HTTPS и создан для того чтобы соединение было безопасным, а данные передавались в зашифрованном виде по криптографическому протоколу SSL/TLS. Это специальная «обертка» поверх HTTP, она шифрует данные, делая их недоступными для злоумышленников и посторонних людей.
HTTPS - англ. «безопасный протокол передачи гипертекста».
Так что в отличие от 80 порта, используемого по умолчанию в HTTP, в HTTPS используется TCP-порт 443 и есть ключ для шифрования. Ключ может быть длиной 40, 56, 128 или 256 бит, достаточный уровень безопасности на данный момент начинается со 128-битных ключей.
Сейчас все браузеры поддерживают HTTPS - он включается автоматически, когда есть возможность и этого требует сервер.
Жизненно важно использовать HTTPS в следующих сервисах:
- Электронные платежные системы (банки, электронные деньги и прочее);
- Сервисы принимающие и отправляющие приватную информацию и персональные данные, например у Яндекса это: Паспорт, Такси, Директ , Метрика, Почта, Деньги , Вебмастер и другие;
- Социальные сети и личные кабинеты в интернет-сервисах;
- Поисковые системы.
Работает HTTPS просто. Объясню на примере.
Вы кладете важную информацию (логин, пароль, данные карты, персональные данные) в ячейку, «запираете ее на ключ»: ячейка шифрует ваши данные при помощи этого ключа.
Теперь отправляете ее почтой адресату. Адресат получает ячейку-посылку, но открыть ее не может - у него нет ключа. Тогда он запирает (шифрует) ячейку на второй замок и возвращает посылку вам обратно. Вы получаете посылку с двумя замками, при этом ключ к одному у вас есть. Теперь можно отпереть свой замок (расшифровать данные) и отправить посылку обратно еще раз - первоначальному адресату.
Данные при этом остаются защищенными - ведь они никем не просматривались и не менялись и до момента получения адресатом находятся под защитой зашифрованного им ключа. Адресат получает посылку, уже с одним замком, расшифровывает ее и обрабатывает ваши данные. Например, проводит вашу транзакцию.
Все - вот так просто работает HTTPS.
Фишка тут в том, что при первом таком обмене происходит обмен ключом шифрования, чтобы он был известен обоим конечным адресатам, но не известен ни одному из узлов по маршруту следования данных. После обмена шифром можно свободно обмениваться сообщениями (зашифрованными) без опасений о перехвате этих данных, ведь без ключа-шифра открыть и прочитать их не удастся.
Единственный нюанс здесь - надо знать, что вы отправляете данные именно туда, куда нужно. И что конечный пункт и является пунктом назначения. Но нужно подтвердить и точно знать, что конечный адресат существует и управляется тем самым сервером, куда отправляются данные.
Для этого серверы получают в центрах сертификации специальные HTTPS-сертификаты безопасности, которые подтверждают «конечность» пункта назначения (что сайт не является узлом передающим данные дальше) и работоспособность технологии шифрования SSL/TLS, т.е. безопасность соединения.
А вот как выглядит сам сертификат:
На текущий момент HTTPS встроен во все современные браузеры и все что требуется от пользователя для поддержания безопасности отправки данных по HTTPS - регулярно обновлять программное обеспечение для серфинга, приема и отправки важных данных в интернете.
Осуществляя взаимодействие «клиент-сервер» по протоколу HTTPS можно не беспокоиться за сохранность данных - вы надежно защищены от прослушивания сетевого соединения: атак снифферов и man-in-the-middle.
Что означает перечеркнутый значок HTTPS и зеленый значок HTTPS, в чем разница? В безопасности. Зеленый - безопасный, красный и перечеркнутый - небезопасный.
И очень удобно, что перечеркнутый значок HTTPS означает, что несмотря на использование этого протокола, соединение не безопасное. Так происходит когда элементы сайта подгружаются не по HTTPS или истек срок действия сертификата. Пользователю сразу видно - ага, небезопасно. И он может уйти с сайта, либо рисковать своими данными.
Что лучше HTTP 1.1, HTTP/2 или HTTPS?
В качестве подведения итога затрону тему предпочтительного использования протоколов.
Понятно, что на данный момент HTTP 1.1 - наиболее распространенный протокол и используется по умолчанию. Время HTTP/2 еще не пришло, но вскоре большая часть интернет-трафика будет идти через вторую версию протокола HTTP. Это упростит жизнь пользователям, потому что сайты будут загружаться быстрее. Администраторы серверов и сайтов тоже будут рады, потому что новый протоко позволяет по новому оптимизировать сайты, ускоряя загрузку и отдачу данных.
При этом, вряд ли возможно, что все сайты перейдут HTTPS, потому что для целей потребления развлекательного контента шифрование ни к чему. Да, сейчас уже 10% сайтов используют HTTPS в рейтинге наиболее посещаемых веб-ресурсов «Alexa». Но это всего десять процентов, среди которых такие гиганты как Гугл, ПейПал, Амазон, Алиэкспресс и другие. То есть множество сайтов, где не использовать HTTPS означает нарушать право интернет-пользователя на безопасность и сохранность данных.
А обычным сайтам типа блога семи блоггеров HTTPS ни к чему - нет приема персональных или платежных данных, нет регистрации и отправки важных сообщений.
Так что в ближайшем будущем мы станем постепенно отходить от HTTP 1.1 в пользу HTTP/2 и HTTPS.
Основной протокол для страниц в интернете — HTTP. Используется этот протокол каждый раз, когда вы заходите на новый сайт, когда на сайте отображается текст, картинка, когда вы нажимаете ссылки.
Весь интернет основывается на HTTP, пусть большая часть пользователей даже и не подозревают, насколько популярен в их привычной жизни HTTP.
HTTP — протокол, по которому передается гипертекст (HyperText Transfer Protocol).
На этом протоколе строится взаимодействие вашего браузера и сервера с информацией. Благодаря его простоте, браузер и сервер соединяются очень быстро. Но нам не обязательно вникать во все подробности работы протокола, мы объясним лишь базовый принцип его работы.
В Интернете можно пользоваться множеством протоколов, HTTP — лишь один многих, у которого собственные задачи с целями.
Все настолько просто, что вы уже знакомы с программным обеспечением, необходимым для работы с HTTP — это ваш браузер.
Независимо от названия браузера, к адресной строке всегда по умолчанию добавляется название протокола: «http://». Вы можете и не видеть эту надпись, если браузер ее скрывает. Но стоит только скопировать название сайта, вместе с ним в нужном месте вставится и протокол HTTP.
- Что значит приставка «http://» перед названием сайта?
- Это значит, что вы обращаетесь к ресурсу по HTTP протоколу.
Зачем создали протокол HTTP
С его помощью передают гипертекстовые документы, а проще говоря — страницы на нужных нам сайтах.
Принимает веб-страницы клиент (браузер), а отдаёт страницы сервер. Эта технология так и называется — клиент-серверная технология.
Благодаря HTTP стало возможно передавать веб-страницы в интернете. А что же содержится в самих страницах, которые пересылает нам сервер? Обыкновенный HTML-код, который поступает в браузер, которому остается только верно интерпретировать полученную информацию и показать вам готовый сайт.
Еще в 2006 году практически половина HTTP-трафика Северной Америки складывалась из потокового звука и видео.
Как работает HTTP
- Браузер отправляет запрос, запрашивая нужную страницу сервера.
- Сервер получает запрос и начинает искать страницу.
- Браузер получает ответ от сервера с результатами запроса:
- Код запрашиваемой страницы и служебная информация — если страница найдена.
- Код ошибки и служебная информация в случае сбоя.
Когда браузер дает запрос на файл, запрос содержит специальную команду HTTP. Если запрашиваемый файл и правда есть на сервере, файл отправляется. А вот принимающей странице уже стоит решить, показать файл на экране, сохранить на диск или сделать с результатом что-то еще.
Чтобы идентифицировать ресурсы в сети, протокол HTTP пользуется глобальными URI. Отличие HTTP от других протоколов — он не сохраняет свое состояние. То есть не сохраняется состояние между парой «запрос-ответ».
HTTP — это не единственный протокол, который используют в Интернете. Также используются:
- FTP (File Transfer Protocol) — протокол передачи файлов.
- POP (Post Office Protocol) и SMTP (Simple Mail Transport Protocol) — для обмена сообщениями электронной почты.
- SHTTP (Secure Hypertext Transfer Protocol) — шифрованная разновидность HTTP. Информация, которая передается по этому протоколу, кодируется. Обычно безопасность важна в случае обмена конфиденциальными данными.
И другие протоколы, у которых есть одно хорошее свойство — все они работают незаметно для нас с вами.
Март 1991 года — Тим Бернерс-Ли предложил использовать HTTP.
Именно Бернерс-Ли разработал все первое, что связано с Интернетом: браузер, сервер, гиперссылки, первый сайт (info.cern.ch) Как выглядел первый сайт, можно увидеть по ссылке.
Версии HTTP со временем совершенствуются, популярной стала версия HTTP 1.1, которая позволяет на долгое время оставлять открытым соединение сервера с браузером, что сделало протокол более эффективным.
В 2015 году появился HTTP/2, который стал бинарным, изменились способы, которыми информацию разбивали на фрагменты.
Безопасность протокола HTTP
Сам HTTP не подразумевает шифрование информации. Но есть расширение для протокола, которое умеет упаковывать данные в протокол SSL или TLS.
HTTPS (S — Secure) — популярное решение, которое не позволяет перехватывать передаваемую информацию и защитить информацию от MITM- атак «man-in-the-middle» или атака посредника.
MITM по сути испорченный телефон, в котором информация подменяется намеренно. О подмене не знает ни клиент ни сервер.
Из чего состоит HTTP
Мы много упоминали, что сервер и клиент отправляют и получают запросы. Так что же содержится в этих запросах? Каждое сообщение HTTP состоит из трех частей:
- Стартовая строка, которая определяет тип сообщения.
- Заголовки, с помощью которых характеризуют тело сообщения.
- Тело сообщения, где содержатся уже нужные данные.
Благодаря особенностям HTTP, сумели создать поисковые машины, форумы, интернет-магазины. В интернет пришла коммерция, начали появляться интернет провайдеры и другие компании, деятельность которых проходит в сети Интернет. А все благодаря протоколу HTTP, с которым вы теперь хорошо знакомы.
Протокол HTTP или HyperText Transfer Protocol это главный прокол (всемирной паутины). Основная задача протокола, обеспечить передачу гипертекста в сети. В протоколе точно описывается формат сообщений, для обмена клиентов и серверов.
Описан протокол HTTP в RFC 2616(HTTP1.1).
Основа протокола обеспечить взаимодействие клиента и сервера по средством одного ASCII-запроса, и следующего на него ответа в стандарте RFC 822 MIME.
На практике протокол HTTP работает на основе порт 80, но можно настроить и по-другому. И хоть TCP/IP не является обязательным, он остается предпочтительным, так как берет на себя разбиение и сборку сообщений на себя и не «напрягает» ни браузер, ни сервер.
Следует отметить, что протокол HTTP может использоваться не только в веб-технологиях, но и других ООП приложениях (объективно-ориентированных).
URL
Основой веб-общения клиент-сервер является запрос. Запрос отправляется при помощи URL– единого указателя ресурсов Интернет. Напомню, что такое URL адрес.
Понятная и простая структура URL состоит из следующих элементов:
- Протокол;
- Хост;
- Порт;
- Каталок ресурса;
- Метки (Запрос).
Примечание: Протокол http это протокол для простых, не защищенных соединений. Защищенные соединения работают по протоколу https. Он более безопасен для обмена данными.
Методы HTTP запросов
Один из параметров URL, определяет название хоста, с которым мы хотим общаться. Но этого мало. Нужно определить действие, которое нужно совершить. Сделать это можно при помощи метода определенного протоколом HTTP.
Методы HTTP
- Метод/Описание
- HEAD/Прочитать заголовок веб-страницы
- GET/Прочитать веб-страницу
- POST/Добавить к веб-странице
- PUT/Сохранить веб-страницу
- TRACE/Отослать назад запрос
- DELETE/Удалить веб-страницу
- OPTIONS/Отобразить параметры
- CONNECT/Зарезервировано для будущего использования
Разберем методы HTTP подробнее
Метод GET.
запрашивает страницу (файл, объект), закодированную по стандарту MIME. Это самый употребляемый метод. Структура метода:
GET имя_файла HTTP/1.1
Метод HEAD. Этот метод запрашивает заголовок сообщения. При этом страница не загружается. Этот метод позволяет узнать время последнего обновления страницы, что нужно для управления КЭШем страниц. Этот метод позволяет проверить работоспособность запрашиваемого URL.
Метод PUT. Этот метод может поместить страницу на сервер. Тело запроса PUT включает размещаемую страницу, которая закодирована по MIME. Это метод требует идентификации клиента.
Метод POST. Этот метод добавляет содержимое к уже имеющейся странице. Используется, как пример, для добавления записи на форум.
Метод DELETE. Этот метод уничтожает страницу. Метод удаления требует подтверждения прав пользователя на удаление.
Метод TRACE. Этот метод отладки. Он указывает серверу отослать запрос назад и позволяет узнать, искажается или нет, запрос клиента, вернувшись от сервера.
Метод CONNECT – метод резерва, не используется.
Метод OPTIONS позволяет запросить свойства сервера и свойства любого файла.
В общении клиента и сервера «запрос-ответ», сервер обязательно генерирует ответ. Это может быть веб-страница или строку состояния с кодом состояния. Код состояния вам хорошо известен. Один из кодов известный код 404 –Страница не найдена.
Группы кодов состояния
1хх: Готовность сервера, Код 100 – сервер готов обрабатывать запросы клиента;
2хх: Успех.
- Код 200 – запрос обработан успешно;
- Код 204 – Содержимого нет.
3хх: Перенаправление.
- Код 301 – Запрашиваемая страница перенесена;
- Код 304 – Страница в КЭШе еще актуальна.
4хх: Ошибка клиента.