Для World Wide Web. Такие протоколы представляют собой структурированный текст, который использует логические связи (гиперссылки) между узлами, содержащими определенные данные. Таким образом, это способ обмена или передачи гипертекста.

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

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

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

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

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

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

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

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

Что это такое и зачем он нужен

HTTP, или HyperText Transfer Protocol, или протокол передачи гипертекста – набор правил и протоколов, по которым сегодня работает глобальная паутина. Он формирует правила для передачи графических файлов, текстовых сообщений, звуковых и мультимедийных файлов — иначе говоря, правила подачи визуального отображения информации в интернете. HTTP/2 – это новое поколение данных протоколов, ведь HTTP/1.1 служит с 1999 года, и с тех пор большинство современных сайтов уже не может довольствоваться поддержкой устаревшей технологии HTTP. Переход на новую версию не заставляет себя ждать.

Чем отличается http/2 от http

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

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

Следует понимать, что со времени появления HTTP1.1 прошло много времени, веб претерпел огромные изменения и необъятно расширился, поэтому необходимо залатать все те дыры, которые возникли за более чем десятилетний промежуток времени со времён разработки первой версии.

Возможности

Данный протокол серьёзно оптимизирует работу веб-сайтов за счёт нескольких преимуществ:

• постоянные соединения : ранее для запроса любого отдельного URL требовалось создавать отдельные TCP-соединения, теперь существует одно соединение на все;
• приоритеты потоков : можно устанавливать приоритетность на серверах — какие ресурсы для вас важнее;
• сжимание заголовков : можно сжать размер HTTP-заголовка;
• пуш-отправка данных : сервер способен отправлять вам те или иные данные ещё до запроса.

Мультиплексирование

Мультиплексирование — это метод в HTTP2 , при помощи которого возможно отправлять сразу несколько запросов, при этом ответы получаются асинхронно через единое соединение. Мультиплексирование — это сердце протокола http2. Оно позволяет вам одновременно посылать больше одного запроса, не запуская для каждого отдельное соединение.

При работе с http1, при загрузке странички, загружается HTML-страница, система видит, что ей нужны какие-то файлы: CSS, изображения, javasсriрt и т.п. Ваш браузер сначала прогружает страницу, а уже потом делает запрос на CSS. После этого запрашивается скрипт. Затем картинка и так далее. Вы можете работать только с одним из них по по очереди.

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

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

ВАЖНО: в HTTP/1.1 присутствует так так называемая конвейерная обработка, так же дающая возможность отправлять более одного запроса одновременно. Но она гораздо менее функциональна по сравнению с мультиплексированием.

Приоритетность

Возможность приоритизации — еще одно новшество в HTTP/2. Теперь каждому запросу может быть назначен приоритет . Существует два способа присвоения приоритета: по весу или на основе зависимостей.

При первой концепции каждому потоку присваивается вес. На основе этого веса сервер перераспределяет нагрузку меж потоками.

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

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

Что даёт приоритезация:

• Более эфективная работа в сети.
• Сокращение временных затрат.
• Ускорение времени загрузки веб-страниц.
• Оптимизация передачи данных между сервером-клиентом .

Сжатие заголовков

Сегодня веб-страницы — это в первую очередь сочетание огромного количества различных элементов: картинок, java-script, CSS и т.п. Каждый раз, когда браузер запрашивает один из таких элементов, он при этом отсылает соответствующий HTTP-заголовок. Сервер при этом присоединяет заголовок к запрошенным элементам. Это потребляет значительные ресурсы .

В HTTP/2 заголовки сжимаются . Это уменьшает объем обмена информацией между сервером и браузером. Вместо алгоритмов gziр/deflate используется HPACK, как самый удобный и простой подход к сжиманию заголовков. Это также уменьшает уязвимость от атак BREACH. Использование HPACK даёт множество преимуществ:.

• Снятие дополнительной нагрузки и расхода ресурсов.
• Сокращение индивидуального размера передающихся данных после сокращения заголовка.
• Неуязвимость перед атаками безопасности .

Server push

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

Как работает Push на примере: Ваш браузер запрашивает веб-траницу (index.html в нашем примере), а сервер возвращает вам три объекта: index.html, а также два дополнительных объектоа: scripts.js и styles.css, которые хранятся в специальном кеше, зарезервированном для этой цели. Затем клиент анализирует index.html и понимает, что для загрузки страницы нужны три объекта: scripts.js, styles.css и image.jpg. Первые два уже находятся в кеше браузера, поскольку они были сохранены сервером, поэтому клиенту просто нужно запросить image.jpg на сервере, чтобы отобразить страницу.

Данная функция имеет многочисленные плюсы:

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

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

Ssl и шифрование

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

Бинарность

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

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

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

Итак, вот основные преимущества бинарного протокола :

• Очень небольшие дополнительные расходы во время анализа данных .
• Гораздо меньшая подверженность ошибкам, по сравнению с предыдущей версией протокола.
• Большая лёгкость в освоении сетевого пространства.
• Большая эффективность в применении сетевых ресурсов.
• Ликвидация всех дыр в безопасности и шифровании и регулярных атак, которые были связаны с тем, что HTTP/1.1 базируется на текстовой основе.
• Сами по себе уникальные возможности HTTP/2, такие как push, мультиплексинг, выстраивание приоритетов, управление потоками, а также оптимизация работы в сети.
• Упрощение обработки команд и их реализации .
• Ускорение передачи данных между клиентом и сервером.
• Существенное снижение сетевых задержек и увеличение пропускной способности.

Поддержка браузерами

На сегодняшний день абсолютное большинство актуальных браузеров: как десктопных, так и мобильных, поддерживают технологию HTTP/2. Первыми из них стали такие гиганты, как Google Chrome и Mozzila Firefox, которые поддерживают данный протокол уже много лет. Позже, видимо следуя их примеру, компания Apple в 2014-м году добавила в свой браузер Сафари поддержку технологии. После этого уже и менее крупные браузеры стали работать в данном направлении. При этом браузер IE Explorer требует версии Windows не меньше 8, чтобы работать с данным протоколом.

Мобильные браузеры не отстают, и уже подключили протокол в большинство существующих платформ . Это касается Андроид-браузера, Хром для Андроида и iOS, Сафари, начиная с iOS 8 — данные мобильные браузеры уже поддерживают HTTP/2. При этом, с течением времени и прониканием технологии в повседневность, зона распространения также постоянно расширяется.

Поисковая оптимизация (SEO)

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

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

Оптимизация сайтов

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

1. Объединение картинок в CSS-спрайты . В первой версии протокола эффективно объединять маленькие и средние изображения в один спрайт, т.к. требуется единственное соединение. Зато если картинка только одна — прогрузить спрайт придётся полностью. В HTTP2 благодаря мультиплексу есть возможность многочисленных запросов и удобнее загружать несколько маленьких картинок одновременно. Хотя иногда по прежнему рекомендуется объединять изображения в спрайт, чтобы улучшить качество сжатия и загрузочный объём.
2. Возможность встраивания картинок в тело страницы при помощи data: URI . Это ещё одно распространённое решение проблемы с множественными запросами в старой версии протокола: картинки встраивались в CSS через data: URI. Размер файла при этом может заметно увеличиться, зато потребуется не так много соединений. В HTTP2 данный подход всё ещё может быть актуален, однако не послужит увеличению производительности.
3. Объединение файлов JS и CSS в единый файл . Таким образом когда загружается страница, сразу загружаются таблицы стилей и код javascript. Помимо этого, браузер кэширует весь этот файл и даже минимальные изменения в коде потребуют перезагрузки всего файла. Мультиплексирование полностью решает данную проблему и избавляет от этого неудобства.
4. Доменный шардинг . В старой версии http кол-во открытых соединений ограничено. Если необходимо загрузить множество ресурсов сразу, то часто можно прибегнуть к их получению с разных доменов.либо поддоменов основного домена. HTTP/2 создаёт возможность создавать столько ресурсов, сколько заблагорассудится, фактически избавляя от необходимости в данной функции, при этом доменный шардинг отрицательно сказывается на производительности из-за множества открытых TCP-соединений.

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

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

Для того чтобы проверить наличие поддержки в браузере протокола HTTP2 можно использовать специальные расширения для браузеров Mozzila Firefox и Google Chrome, а также использовать инструмент проверки скорость на веб-0сайте Айри.рф: после проверки должна загореться одна из плашек — если браузер поддерживает протокол HTTP2, то в итогах проверки появится зеленая плашка [НТTР/2.0]. Существуют и другие интернет-сервисы для проверки поддержки модернизированного протокола, один из них — это сервис от http2.pro.

Заключение

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

HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) был разработан как основа World Wide Web.

Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

Структура HTTP-запроса

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

Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.

Запрос в главной строке состоит из трех частей, разделенных пробелами:

Метод (иначе говоря, команда HTTP):

GET - запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

HEAD - запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

POST - этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

PUT - разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

Ресурс - это путь к определенному файлу на сервере, который клиент хочет получить (или разместить - для метода PUT). Если ресурс - просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия протокола -версия протокола HTTP, с которой работает клиентская программа.

Таким образом, простейший HTTP-запрос может выглядеть следующим образом:

Здесь запрашивается корневой файл из корневой директории web-сервера.

Строки после главной строки запроса имеют следующий формат:

Параметр: значениe .

Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).

Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

Connection (соединение)- может принимать значения Keep-Alive и close. Keep-Alive ("оставить в живых") означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером "скачать" html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.
close ("закрыть") - соединение закрывается после ответа на данный запрос.

User-Agent - значением является "кодовое обозначение" браузера, например:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Accept - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.

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

Referer - URL, с которого перешли на этот ресурс.

Host - имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.

Accept-Language - поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.

Формат HTTP-ответа

Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.

Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.

Основная строка запроса состоит из 3-х полей, разделенных пробелами:

Версия протокола - аналогичен соответствующему параметру запроса.

Код ошибки - кодовое обозначение "успешности" выполнения запроса. Код 200 означает "все нормально" (OK).

Словесное описание ошибки - "расшифровка" предыдущего кода. Например для 200 это OK, для 500 - Internal Server Error.

Наиболее употребительные параметры http-ответа:

Connection - аналогичен соответствующему параметру запроса.
Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.

Поэтому, на мой взгляд, правильной тактикой браузера является следующая:
1. выдать в запросе Connection: Keep-Alive;
2. о состоянии соединения судить по полю Connection в ответе.

Content-Type ("тип содержимого") - содержит обозначение типа содержимого ответа.

В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.

Некоторые типы содержимого:

text/html - текст в формате HTML (веб-страница);
text/plain - простой текст (аналогичен "блокнотовскому");
image/jpeg - картинка в формате JPEG;
image/gif - то же, в формате GIF;
application/octet-stream - поток "октетов" (т.е. просто байт) для записи на диск.

На самом деле типов содержимого гораздо больше.

Content-Length ("длина содержимого") - длина содержимого ответа в байтах.

Last-Modified ("Модифицирован в последний раз") - дата последнего изменения документа.

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

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

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

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

Что такое HTTP и как он работает?

Чтобы получить нужный документ в интернете, пользователю достаточно ввести в поисковую строку браузера нужный URL-адрес ( о структуре урлов подробности), который как раз содержит название протокола HTTP (или HTTPS).

3. HTTP/Версия — указывается действующая модификация протокола. На данный момент это HTTP 1.1 (вы можете ознакомиться с ее спецификацией). Однако, в черновом виде уже существует следующая версия протокола 2.0, который основан на .

Нижняя строка представляет собой заголовок Host в составе HTTP-запроса, отсылаемого браузером серверу в соответствии с полученным от ДНС IP. Для чего это надо? Для идентификации нужного сайта, поскольку на вебсерверах обычно расположен не один ресурс.

Разберем наглядный пример для закрепления пройденного. Скажем, браузер получил "задание" от пользователя отобразить страничку вот с таким адресом:

Http://subscribe.ru/group/

Тогда HTTP-запрос посредством метода GET может быть составлен следующим образом (в этом случае обычно тело сообщения отсутствует):

GET /group/ HTTP/1.1 Host: subscribe.ru

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

HTTP/Версия Код состояния Пояснение

Теперь пробежимся вкратце и по составу ответа сервера:

1. Версия HTTP указывается по аналогии с запросом.

2. Код состояния (Status Code) — три цифры, информирующие о том, каков статус документа, запрошенного браузером. Например, 200 — ОК, страница существует и будет отображена в браузере, 301 — осуществлен (перенаправление) на другой урл, — вебстранички по такому адресу нет (возможно, она удалена либо юзер ошибся при вводе URL).

3. Пояснение (Reason Phrase) — текст дополнения к коду ответа. В некоторых случаях пояснение может отличаться от стандартного либо отсутствовать вовсе. Это связано в том числе с настройкой ПО, размещенного на сервере.

Реальный пример? Пожалуйста. Попробуем получить ответ сервера на запрос, приведенный мною в качестве примера выше (урл «http://subscribe.ru/group/»). Он будет выглядеть так (начальная строка с заголовками):

HTTP/1.1 200 OK Server: nginx Date: Sat, 10 Jun 2017 06:36:38 GMT Content-Type: text/html; charset=utf-8 Connection: keep-alive Content-Language: ru Set-Cookie: Subscribe::Viziter=UQkivlk7k3YO3DgjAxM2Ag==; expires=Thu, 31-Dec-37 23:55:55 GMT; domain=subscribe.ru; path=/ P3P: policyref="/w3c/p3p.xml", CP="NOI PSA OUR BUS UNI"

В данном случае отсутствуют пояснение и тело сообщения, которое при использовании метода GET может содержать, например, HTML-код запрашиваемого документа (веб-странички). В зависимости от типа приложения клиента эти разделы могут присутствовать.

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

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

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

Он удобен тем, что дает полную картину взаимодействия «клиент-сервер», предоставляя в "одном флаконе" содержание HTTP запроса (request) и ответа (response) . Посмотрите, какой документ выдал этот плагин при переходе по ссылке с одной страницы моего блога на другую:

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

Интерес вызывают также HTTP Headers (заголовки) , отображенные ниже. Например, пункт «Referer» дает информацию в виде урла, откуда был осуществлен переход.

Заголовок «User Agent» отражает как раз клиентское приложение, отправившее запрос вебсерверу. В данном случае это браузер, но могут быть и другие (мобильные устройства, поисковые роботы и т.д.). Данные, представленные в Юзер Агенте, необходимы серверному программному обеспечению для идентификации приложения, посылающего запрос.

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

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

В чем особенность безопасного протокола HTTPS?

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

Если ввести адрес страницы какого-нибудь подобного сайта, то данное соединение будет особым образом обозначено. В Google Chrome (), например, отобразится замочек с надписью «Надёжный» зеленого цвета, при нажатии на который вы увидите некоторую информацию, связанную с защитой личных данных:

Что такое HTTPS? Строго говоря, он не является самостоятельным протоколом. Это стандартный HTTP, который действует через механизмы TLS или SSL , способные гарантировать шифрование, что исключает перехват и получение конфиденциальных данных злоумышленниками.

По умолчанию при работе защищенного протокола применяется порт 443 (если помните, для стандартного HTTP — 80). Для шифрования в HTTPS используется длина ключа в 40, 56, 128 и 256 бит (). Однако, первые два варианта даже не стоит рассматривать, поскольку они не могут обеспечить достаточного уровня безопасности.

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

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

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

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

Что такое HTTP протокол?

Давайте дадим определение тому, что такое HTTP протокол , но, прежде чем дать определение термину HTTP протокол, давайте разберемся со словом протокол. Слово протокол переводится с греческого дословно, как первый и клей. В древности это был листок, который клеился к свитку и на нем автор писал свое имя, дату написания и прочую никому ненужную информацию, вернее, служебную. Почему я говорю ненужную? Да потому, что рядовому обывателю интереснее само содержание свитка, а не то, кто его написал. Так и в HTTP протоколе : среднестатистическому пользователю вообще неинтересно как он получает страницы сайта, он просто открывает свой браузер. Еще одно определение слова протокол – это алгоритм, либо последовательность действий. Протокол – это свод правил и предписаний, которые регламентируют то или иное мероприятие. Протокол передачи данных – это стандарт, описывающий правила взаимодействия функциональных блоков при передаче данных.

Итак, мы определились, что HTTP – это протокол передачи данных, но что означает аббревиатура HTTP? HTTP или HyperText Transfer Protocol – это протокол передачи гипертекста. А теперь я приведу наиболее интересные определение HTTP протокола, которые когда-либо встречал.

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

HTTP протокол – это протокол передачи данных седьмого уровня модели OSI, работающий на основе технологии клиент-сервер.

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

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

HTTP протокол – это транспорт для других протоколов, например, так как JSON.

HTTP протокол – это технология, которую должен понимать любой веб-разработчик.

Что же, я думаю, мы разобрались с тем, что такое HTTP протокол и можем теперь посмотреть, где он используется.

Для чего используется HTTP протокол

Скажу прямо HTTP протокол – это основа интернета, точнее не так, это та основа, которую видит конечный потребитель: посетители сайтов. Поэтому HTTP протокол в интернете везде. Фраза странно звучит, но другой я придумать не смог. Читая новости на сайте, вы используете HTTP протокол. Слушая музыку Вконтакте, вы используете HTTP протокол. Когда вы смотрите видео на YouTube – вы используете HTTP протокол. Когда вы играете в браузерную игру, вы тоже используете HTTP протокол. Поэтому я и пишу, что HTTP протокол используется везде в интернете. Без него вы бы не смогли и этот текст прочитать. Подведем итог: HTTP протокол используется для передачи данных в интернете, изначально он использовался для передачи HTML документов, но сейчас он позволяет передавать различный контент и различные .

Характеристики HTTP протокола

Давайте перечислим технические характеристики HTTP протокола :

1. HTTP протокол работает по технологии .
2. HTTP протокол относится к седьмому уровню .
3. HTTP протокол относится к семейству протоколов TCP/IP.
4. Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.
5. Спецификация протокола RFC 2616.
6. Для идентификации ресурса HTTP протокол использует URI (читай про ).
7. HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.
8. HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили.

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

HTTP протокол работает по принципу клиент-сервер

Да, HTTP протокол работает по принципу клиент-сервер. Самый простой пример, что приходит мне сейчас в голову, дабы объяснить суть взаимодействия клиент-сервер, это пример покупателя и продавца в магазине. Покупатель приходит в магазин и говорит продавцу: Здрасти!. Если продавец грубый, он отвечает: забор покрасти!. Дальше покупатель улыбается, стоит, смотрит на витрину и выбирает: чего бы ему купить. А в это время продавец стоит и молчаливо ждет, пока клиент выберет. Клиент сделал выбор и говорит продавцу: а дайте мне вон ту коричневую хрень, что стоит на верхней полке в дальнем углу. Продавец говорит: щас. После чего берет табурет ставит его в дальний угол, снимает с полки коричневую хрень и несет покупателю. Покупатель берет коричневую хрень, отдает деньги и уходит. А продавец, получив деньги, кладет их в кассу.

Суть этой истории в том, чтобы показать взаимодействие клиент-сервер. (в данном случае покупатель) полностью управляет развитием событий, то есть (в нашем примере продавец) ни в коем случае сам не устанавливает контакт, он терпеливо ждет действий клиента и каким-то образом на них реагирует. Я привел самый простой пример. Но его можно и усложнить, например, покупатель дает сто рублей, а коричневая хрень стоит 90, в этом случае продавец даст клиенту сдачу. Продавец мог отреагировать на слова клиента: Здрасти!, как-нибудь по-другому. Или коричневая хрень могла быть не для продажи или для продажи, но только для особых клиентов. Я это веду к тому, что HTTP протокол – это протокол передачи данных основанный на взаимодействие клиент-сервер и он, в принципе, довольно полно описывает алгоритмы действия как для клиента, так и для сервера в различных ситуациях.

История HTTP: стандарты HTTP протокола

Давайте теперь рассмотрим историю HTTP протокола на его стандартах.

1. – версия протокола HTTP9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0).
3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Кстати, посылая информацию о себе в заголовке.
4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета.

Клиенты HTTP протокола

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

• Google Chrome;
• Mozilla FireFox;
• Opera;
• Internet Explorer;
• Яндекс Браузер;
• Safari.

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

Серверы HTTP протокола

Статусная строка отделяется от заголовка символом CRLF в конце этой самой строки от HTTP заголовка (этот символ в Windows вы можете получить, нажав клавишу Enter – перенос строки), а HTTP заголовок отделяется от тела сообщения строкой, в которой только один символ – CRLF.

У запросов и ответов есть общие служебные заголовки, которые могут быть использованы, как при запросе, так и при ответе HTTP сервера. Так же хочу заметить, что есть группа заголовков относящихся к объектам (телу сообщения), они все могут быть использованы, как в запросах, так и в ответах, за исключением поля заголовка Allow, которое используется только в ответах сервера при взаимодействие по протоколу HTTP. У HTTP сообщения есть длина, которая измеряется в байтах, если у вашего HTTP сообщения есть тело, то для определения длины сообщения действуют следующие правила по порядку:

1. Любое HTTP сообщение ответа сервера, которое не должно включать тело сообщения, всегда должно быть завершено пустой строкой после заголовков.
2. Если в заголовках HTTP сообщений присутствует поле Transfer-Encoding (кодирование HTTP) при это у этого поля значение chunked, то длину HTTP сообщения следует определять методом кодирования по кускам (chunked encoding).
3. Если у заголовка HTTP сообщения есть поле Content-Length, то значение, которое записано в Content-Length является длиной HTTP сообщения, измеряется в байтах.
4. Если HTTP сообщение использует медиа типы «multipart/byteranges», который само разграничен, то он и определяет длину.
5. Длина HTTP сообщения определяется закрытием соединения со стороны сервера.

Для ясности давайте рассмотрим примеры сообщений в HTTP протоколе и первое, что мы рассмотрим – пример запроса в HTTP протоколе:

POST /cgi-bin/process.cgi HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.example.com Content-Type: application/x-www-form-urlencoded Content-Length: length Accept-Language: ru-ru Accept-Encoding: gzip, deflate Connection: Keep-Alive licenseID=string&content=string&/paramsXML=string

POST / cgi - bin / process . cgi HTTP / 1.1 User - Agent : Mozilla / 4.0 (compatible ; MSIE5 . 01 ; Windows NT ) Host : www . example . com Content - Type : application / x - www - form - urlencoded Content - Length : length Accept - Language : ru - ru Accept - Encoding : gzip , deflate Connection : Keep - Alive licenseID = string & content = string & / paramsXML = string

Номер	Класс кода состояния в HTTP протоколе и его описание
1	HTTP коды состояний 1xx: информационные Такой код состояния сервер высылает в том случае, когда запрос получен, но еще не обработан.
2	HTTP коды состояний 2 xx : успешные Сервер отправит вам такой код в том случае, когда он успешно принял и обработал HTTP сообщение клиента.
3	HTTP коды состояний 3 xx : перенаправление Если вы получили от сервера код состояния, начинающийся на тройку, то это означает, что нужны дополнительные действия, чтобы завершить процесс обработки HTTP запроса.
4	HTTP коды состояний 4 xx : ошибка клиента Если вы увидели код состояния, который начинается с четверки, то это означает, что произошла ошибка по вине клиента.
5	HTTP коды состояний 5 xx : серверная ошибка Код состояния, начинающийся с пятерки, говорит о том, что произошла ошибка на стороне сервера.

Поля заголовка HTTP сообщения

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

Поля заголовка разделяются между собой символом CRLF. HTTP протокол делит поля заголовка на четыре группы:

1. Общие поля заголовка. Такие заголовки могут быть использованы в любых сообщениях, передаваемых по HTTP протоколу.
2. Поля заголовка запросов. Эти сообщения могут быть переданы только в запросах HTTP протокола.
3. Поля заголовка ответов. Как понятно из названия, эти поля используются только при HTTP ответах.
4. Поля заголовка тело сообщения. А эти поля используются тогда, когда необходимо определить, как и в каком виде будет представлена информация конечному пользователю, которая передается по HTTP.

Кэширование HTTP протокола

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

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

Номер	Директивы поля заголовка Cache — Control для клиента и их описание
1	no — cache Директива HTTP протокола no-cache говорит серверу о том, что для последующего запроса ответ не должен отправляться из кэша без проверки с содержимым исходного сервера.
2	no — store Директива HTTP протокола no-store говорит серверу о том, что ни запрос клиента, ни ответ сервера не должны кэшироваться. Это сделано для безопасности.
3	max — age = seconds Директива HTTP протокола max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах.
4	max — stale [ = seconds ] Директива HTTP протокола max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах.
5	min — fresh = seconds Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если время жизни кэша не больше указанных секунд.
6	Директива HTTP протокола min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований.
7	only — if — cached Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо.

А теперь взглянем на директивы, позволяющие .

Номер	Директивы поля заголовка Cache — Control для сервера и их описание
1	public Директива HTTP протокола Public говорит о том, что ответ сервера можно сохранять в любом кэше.
2	private Директива HTTP протокола private говорит о том, что ответ сервера нужно сохранять в закрытом кэше, который предназначен только для этого пользователя.
3	no — cache Директива HTTP протокола no — cache говорит о том, что кэшированный ответ не должен отправляться клиенту без его предварительной проверки.
4	no — store Директива HTTP протокола no — store говорит о том, что ответ сервера нельзя сохранять в кэше.
5	no — transform Директива HTTP протокола no — transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки.
6	must — revalidate Директива HTTP протокола must — revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка.
7	proxy — revalidate Директива HTTP протокола proxy — revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов.
8	max — age = seconds Директива HTTP протокола max — age говорит о том, сколько живет кэш на сервере.
9	Директива поля заголовка Cache — Control ответа сервера: s — maxage = seconds Директива ответа сервера Public говорит о том, что и директива max-age, но для CDN-серверов

И клиентские, и серверные HTTP приложения должны уметь сравнивать данные из кэша, чтобы не гонять по сети лишний трафик и при этом конечный пользователь на свои запросы получал актуальную информацию. С этой целью в HTTP протокол было введено специальное поле Last-Modified и условные метода запроса с условными полям заголовка. В поле Last-Modified указывается дата и время создания кэшированной версии, значение этого поля может сравнивается со значением даты времени того момента, когда произошло последнее обновление оригинального ресурса и если значения совпадают, то данные клиенту поступают из кэша.

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

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

Безопасность HTTP протокола

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

Но у HTTP протокола есть расширение HTTPS, обратите внимание HTTPS – это не протокол, а расширение HTTP протокола, которое использует TCP порт 433. Это расширение является связкой двух протоколов: HTTP и SSL или HTTP и TLS (TLS и SSL, суть одно и то же).

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