Http: протокол, который каждый разработчик должен знать (часть 2)

В чем различия между http и https?

Теперь перейдем к основному вопросу: в чем заключается главная разница между http и https? По ранее описанным особенностям протоколов можно понять, какие между ними отличия. Но если посмотреть более пристально, то можно понять, что есть и другие отличительные черты.

1. Каждый из протоколов функционирует при помощи специальных портов. Но для работы http используется порт 80, а для https – 443.
2. С учетом того, как работает https, мы ранее сделали вывод, что применяемое шифрование данных надежно защищает их от злоумышленников. Для их расшифровки используются специальные ключи, хранящиеся на сервере. Для http это не характерно.
3. Защищенное соединение гарантирует полную сохранность данных. Даже если в них будут внесены незначительные коррективы, система моментально их зафиксирует.
4. Протокол безопасности предоставляет аутентификацию. То есть, пользователь может быть уверен в том, что попадет именно на тот ресурс, который ищет. Такой подход помогает предотвратить любые посторонние вмешательства.

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

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

Нужно ли переходить на HTTPS?

Если ваш сайт содержит информацию, которая быть надежно защищена, то переходить на безопасный протокол нужно обязательно. В противном случае в любой момент важные данные могут быть украдены и использованы в мошеннических целях. Но будьте готовы к тому, что за переход на https вам придется вносить дополнительную плату, если выберете платный SSL-сертификат. А также оплачивать услуги программиста фрилансера от 1000 до 3000 рублей.

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

Таким образом, http и https – это понятия во многом схожие, но между ними есть принципиальная разница. Зная, в чем она заключается, каждый сайтовладелец сможет выбрать для себя оптимальный вариант.

3.12 Еденицы измерения диапазонов (Range Units).

HTTP/1.1 позволяет клиенту запрашивать только часть объекта.
HTTP/1.1 использует еденицы измерения диапазонов в полях заголовка
Range () и Content-Range (). Объект может
быть разбит на части соответственно различным структурным модулям.

         range-unit       = bytes-unit | other-range-unit

         bytes-unit       = "bytes"
         other-range-unit = token

Единственая еденица измерения диапазонов, определенная в HTTP/1.1
— это «bytes». Реализации HTTP/1.1 могут игнорировать диапазоны,
определенные с использованием других едениц измерения. HTTP/1.1
был разработан, чтобы допускать реализации приложений, которые не
зависят от знания диапазонов.

Copyright    1998
Alex Simonoff
(http://www.omsk.com/Leshik/),
All Rights Reserved.

Что такое HTTP и HTTPS?

HTTP – протокол гипертекстовой разметки, используемый по стандарту для передачи любого рода данных в интернете. Аббревиатура расшифровывается как «hypertext transfer protocol». Суть проста: пользователь отправляет запрос на сервер расположения сайта, протокол форматирует данные определённым образом в процессе, а потом доставляет результат, браузер всё это преобразует в нужный вид. В общем, HTTP – это набор правил передачи информации между браузером клиента и сервером сайта.

HTTPS – тот же протокол, но со встроенным шифровальщиком: добавочная буква «S» в аббревиатуре означает «Secure», то есть «безопасный». Он задействуется для доменов, к которым подключён SSL-сертификат (Secure Sockets Layer). В общем, это – защищённая вариация стандартного протокола для конфиденциальной передачи данных, расшифровка которых потребует приватного ключа, хранящегося только на сервере. Шифрование происходит в обе стороны – на приём и передачу, поэтому в промежутке доставки они всегда находятся в зашифрованном виде.

Стандарты (протокола) обмена информацией

Это тоже название определённых правил, по которым передают сведения между участниками Сети в том или ином случае. Передаваемая кодированная информация становится понятной для всех абонентов благодаря применению таких правил. Обычно к ним относят следующие явления:

• приёмы реализации по контролю;
• структура, по которой удалось построить базы данных и т. д.

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

Какой протокол является базовым в Интернете — будет рассмотрено далее.

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

Интеграция в сложные сетевые процессы обмена информацией становится недоступной.

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

Обслуживание соединения со стороны сервера

В основном сервер прослушивает входящие сообщения и обрабатывает их по мере поступления запросов. Операции сервера включают в себя:

• создание сокета для начала прослушивания 80-го (или другого) порта,
• получение запроса и анализ сообщения,
• обработку ответа,
• установку заголовка ответа,
• отправку ответа клиенту,

прерывание соединение, если возникло сообщение: Connection: close.

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

Структура пакета HTTP

Пакет HTTP состоит из 3 частей. Первая часть это запрос, либо со стороны клиента, либо от статус ответа со стороны сервера. Например, запрос GET означает, что клиент просит передать ему web-страницу, которая находится на сервере вот по такому пути GET/tehnologii/protokoli в ответ сервер пересылает статус выполнения операции код и символьное сообщение, например 200 OK. Это означает, что страница нашлась на сервере и сервер передает ее в теле сообщения.

Затем могут идти и заголовки, которых может быть несколько. В версии HTTP 1.0 заголовки были не обязательны, но в версии HTTP 1.1 в запросе обязательно использовать заголовок Host:www.zvondozvon.ru, где указываются доменное имя сервера, у которого вы хотите запросить веб-страницу. Это сделано из-за того, что на одном и том же IP-адресе, может работать несколько веб-сайтов и в web серверу необходимо знать с какого сайта вы хотите загрузить страницу. 

Также могут быть другие заголовки, например тип передаваемого сообщения в примере Content-Type: text/html; charset=utf-8, размер передаваемого сообщения Content-Length: 5161 байт. 

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

Методы

Метод — это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

Приведенные ниже методы определены, но практически не используются:

Метод GET

GET — это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком ‘/’, а затем, после символа ‘&’ — именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом ‘&’. Например:

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

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

Метод HEAD

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Этот метод используется, когда клиент хочет получить информацию о документе, не получая его. Например, клиента может интересовать:

• время изменения документа;
• размер документа;
• тип документа;
• тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Разработка протокола HTTP

HTTP — аббревиатура, расшифровав которую получаем HyperText Transfer Prоtocоl — «протокол передачи гипертекста». Обычно гипертекст представляется набором текстов, содержащих узлы перехода между ними, которые позволяют избирать читаемые сведения или последовательность чтения.

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

Разработчиком протокола HTTP был британский учёный и сотрудник ЦЕРН Тим Бернерс-Ли — идеолог создания «всемирной паутины» (на фото слева). Работа над созданием протокола длилась около двух лет и уже в марте 1991 года было начато использование протокола, как механизма для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста.

Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 года. Спецификация протокола привела к упорядочению правил взаимодействия между клиентами и серверами HTTP, а также чёткому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.

В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, послуживший основой для реализации большинства компонентов более поздней версии HTTP/1.0. И, наконец, в июне 1999 года была принята версия протокола HTTP/1.1, использующаяся и сегодня.

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

Несколько HTTP соединений

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

Например, первое соединение для загрузки стилевого файла, следующие соединение для загрузки javascript и другие соединения для передачи различных картинок. Каждое такое соединение может быть постоянным и использоваться для загрузки нескольких ресурсов, а также внутри таких соединений можно использовать HTTP pipelining. Почти все современные браузеры используют несколько HTTP соединений как правило от 4 до 8.

Особенности HTTP

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

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

• аутентификации пользователя;
• хранения персональных предпочтений и настроек пользователя;
• отслеживания состояния сессии доступа пользователя;
• ведения статистики о пользователях.

Такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.

Ещё одной особенностью протокола HTTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Тогда как при доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно.

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

Для этого же в HTML были введены формы.

Все эти особенности протокола HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это позволило сделать Интернет коммерческой площадкой: появилось множество компаний, основным полем деятельности которых стало предоставление доступа в Интернет (провайдеры) и создание сайтов.

3.10 Метки языков (Language Tags).

Метка языка идентифицирует естественный язык: разговорный,
письменный, или другой используемый людьми для обмена информацмей
с другими людьми. Машинные языки являются исключением. HTTP
использует метки языка внутри полей Accept-Language и
Content-Language.

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

           language-tag  = primary-tag *( "-" subtag )

           primary-tag   = 1*8ALPHA
           subtag        = 1*8ALPHA

Внутри метки не допустим пробел и все метки не чувствительны к
регистру. Пространство имен меток языка управляется IANA. Например
метки содержат:

          en, en-US, en-cockney, i-cherokee, x-pig-latin

Любая двухсимвольная первичная метка является меткой аббревеатуры
языка ISO 639, а любая двухсимвольная подчиненная метка является
меткой кода страны ISO 3166. (Последние три метки из
вышеперечисленных — не зарегистрированные метки; все, кроме
последней — примеры меток, которые могли бы быть зарегистрированы
в будущем.)

Как работает запрос Conditional GET

При первом обращении к ресурсу, браузер посылает обычный запрос GET и сохраняет результат в кэш. Conditional GET можно использовать только если в http ответе установлен заголовок Last-modified, в котором указана дата последнего изменения ресурса.

В следующий раз, когда браузер будет обращаться к серверу за тем же самым ресурсом, он уже будет использовать запрос Conditional GET, в этом запросе используется дополнительный заголовок if-Modified-Since, в этом заголовки указывается дата изменения ресурсов, это дата как раз берется из значения заголовка last-modified, который передал нам сервер.

Ответ на запрос GET с условием

Сервер может передать два варианта ответа на Conditional GET запрос. Если ресурс не поменялся, то сервер передает короткое сообщение со статусом 304 Not Modified. Это сообщение, также может включать дополнительные заголовки по управлению кэша. Сам ресурс при этом не передается, так как актуальная копия есть в кэше браузера. Если же ресурс поменялся, то измененная версия ресурса передается полностью, при этом используется статус http ответа 200 OK.

ETag в запросах Get с условием

В протоколе версия HTTP 1.1 появилась другая возможность проверить изменился ресурс или нет. Для этого используется entity tag или сокращенно ETag, это код который генерируется на основе содержимого ресурса? как правило это хэш-код или что-нибудь подобное.

Web-сервер при отправке ресурса, добавляет этот код в заголовок ETag, если ресурс изменился, то значение ETag также поменяются. ETag удобно применять, если web-сервер может передавать различные варианты одной и той же страниц.

Например, на разных языках, в этом случае дату изменений использовать нельзя, так как страницы на разных языках могут быть изменены в одно и тоже время, а ETag вполне подходит. Если мы хотим использовать ETag в conditional GET то вместо заголовка if-Modified-Since мы должны указывать If-None-Match. Вот пример:  If-None-Match: 57454284-3d8f

Заголовок Cache—Control

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

Cache-Control: private, max-age=10. В этом примере используется два элемента private и max-age = 10 разделенное запятой.

Что можно использовать в заголовке Cache-Control

• значение no-store, говорит о том, что ресурс нельзя сохранять в кэш;
• no-cache, говорит о том, что и ресурсы сохранять в кэш можно, но для его использования необходимо выполнить запрос conditional GET, и загружать ресурс из кэша только в том случае если он не изменился на сервере;
• public, говорит о том, что информация может быть доступна всем и ее можно кэшировать, это значение удобно использовать совместно с http аутентификацией, так как по умолчанию при аутентификации кэширование не используется;
• private сообщает о том, что страница может быть сохранена только в частном кэша браузера, но не в разделяемых кэшах;
• max-age устанавливает время хранения ресурсов кэша в секундах, используется для замены заголовка expires.

HyperText Transfer Protocol

Интернет протокол HTTP – HyperText Transfer Protocol является протоколом передачи гипертекста. Он предназначен для передачи различной информации между клиентом и сервером и является символьно-ориентированным клиент-серверным протоколом.

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

Всего было четыре версии протокола. Самый первый вариант интернет протокола HTTP 0.9 был выпущен в 1991 году и впервые издан в январе 1992 года. Он привел к урегулированию норм и правил взаимосвязи между клиентами и серверами HTTP, а соответственно к точному разграничению функций между этими элементами. Были запротоколированы основные синтаксические и семантические принципы и положения.

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

Постоянное соединение в HTTP

Альтернативный подход, который называется постоянное соединение, заключается в том что можно один раз установить соединение tcp и затем использовать его для загрузки различных ресурсов не только HTML страницы, но и стилевых файлов, javascript, картинок и всех связанных ресурсов. TCP соединения разрываются после того, как все ресурсы были загружены.

По-английски постоянное соединение называется HTTP persistent connection или HTTP keep-alive. Использование постоянного соединения позволяет повысить скорость загрузки web-страниц.

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

Что значит незащищенный протокол HTTP?

Основная цель технологии Protect – защитить весь процесс вашего серфинга в интернете. Защитная технология от Яндекса сканирует посещаемый вами сайт и если на нем обнаруживаются фатальные проблемы (например, вирусные скрипты) – блокирует к нему доступ. Конечно же, Протект объяснит вам суть выявленной опасности. Помимо этого, такая защита контролирует следующие аспекты:

1. Проверка безопасности активных на компьютере и телефоне Wi-Fi сетей;
2. Защита ваших логин-паролей, мобильного банкинга и платежей в Сети;
3. Проверка загружаемых файлов из Сети;
4. Блокировка рекламы со спамом и шокирующим контентом.

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

Защищенный протокол HTTPS имеет ряд преимуществ перед HTTP

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

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

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

Сообщение HTTP содержит три части, которые пересылаются в следующем порядке:

1. Starting line – стартовая строка. Устанавливает тип передаваемого сообщения;
2. Headers – заголовки. Дают характеристику телу сообщения, параметры его передачи и иные данные;
3. Message Body – тело сообщения. Передает непосредственно информацию сообщения. Необходимо в обязательном порядке отделить тело сообщение от заголовков пустой строкой.

В этих трёх частях стартовая строка обязательно должна присутствовать. Заголовки и тело сообщения являются необязательными элементами. Это связано с тем, что собственно стартовая строка указывает на вид запроса – ответа. Исключением является интернет протокол HTTP версии 0.9. В ней сообщение запроса включает всего лишь стартовую строку, а сообщения ответа содержит только его тело.

Symbols

Постскриптум.

Думаю, что о передаче запросов на сервер не стоит рассказывать подробно. Это уже дело чисто РНР техники :-). Достаточно внимательно прочитать раздел о функциях работы с сокетами, или о функциях модуля CURL в официальной документации РНР.

Из выше сказанного, надеюсь теперь понятно, почему вопрос: «Как мне сформировать POST запрос, используя функцию header?»  бессмысленен. Функция header(string) добавляет запись только в заголовок запроса, но никак не в тело запроса.

Есть еще один тип запросов  Content-Type: multipart/mixed, надеюсь после прочтения данной статьи Вы легко разберетесь с данным типом сами. Подробно изучить его можно

О запросах других типов можно прочитать в официальной спецификации протокола HTTP 1.0 здесь.

Разница между HTTP и HTTPS

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

Данные, передаваемые по HTTP, меньше по объёму, поэтому их передача в обе стороны занимает чуть меньше времени. Но, если сайт нормально оптимизирован, то разница в скорости не будет бросаться в глаза. Да и многие пользователи понимают: лучше подождать пару секунд, не переживая, доберутся ли их деньги, реквизиты и пароли до сервера назначения в безопасности. Кроме того, поисковые системы, в частности, Google и Yandex считают HTTPS одним из признаков качественного сайта.

Пример запроса HTTP

Рассмотрим примеры запроса и ответа HTTP. 

HTTP работают в текстовом режиме, нам необходимо подключиться к веб-серверу, например www.zvondozvon.ru к порту 80 по протоколу TCP. Дальше мы пишем запрос, используем метод GET хотим получить ресурс /tehnologii/protokoli и указываем версию протокола по которой мы хотим работать HTTP 1.1. Так как мы используем версию 1.1 нам необходимо указать заголовок host, доменное имя сервера с которым мы работаем www.zvondozvon.ru, этого вполне достаточно для того чтобы веб-сервер нам ответил. 

Ответ веб-сервера начинается со статуса 200 ok, обработка запроса произошла успешно, также вначале указываются версия протокола, которая используется HTTP 1.1. Затем идут несколько заголовков реализации веб-сервера nginx, тип передаваемой страницы текста html кодировка utf-8, длина страницы 5161 байт, также здесь могут идти другие заголовки, которые вам передал сервер. 

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

Продолжение про протокол HTTP читайте в статье постоянное соединение и кэширование протокола HTTP.

URL — уникальное положение ресурса

Большую роль в работе web и http играет URL (Uniform Resource Locator) — уникальное положение  ресурса, по-русски его часто называют ссылка. Это уникальный адрес веб-страницы в интернете. 

Рассмотрим, как устроены ссылки. Например, https://www.zvondozvon.ru/tehnologii/protokoli. Сначала идет название протокола, в нашем случае https. Затем :// и доменное имя сервера www.zvondozvon.ru на котором размещена страница, либо здесь может находиться IP-адрес сервера. После этого через слеш указывается имя конкретной страницы, которую мы хотим загрузить /tehnologii/protokoli.

URL рассчитаны не только на работу с http и html, но и например с другими протоколами, можно указать защищенный протокол https или протокол ftp. Также не обязательно использовать гипертекст, на веб-серверах могут размещаться обычные текстовые страницы. 

Пример сеанса FTP

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

Ответ FTP сервера, также как и ответы серверов многих прикладных протоколов состоят из двух частей, первая 220 статус, а вторая поясняющее сообщение Welcome to the FTP Server. Статус ответа 220, коды которой начинаются с 2, говорят об успешном выполнении команды, поясняющее сообщение содержит приветствие “Добро пожаловать на FTP сервер”. 

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

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

Устанавливаем бинарный режим передачи файлов с помощью команды TYPE 1. Сервер отвечает, что тип передачи данных успешно установлен в 1. 200 Type set to 1. 

Мы хотим загрузить сервера в файл, показан путь /pud/tex/latex/llncs2e.zip, но перед тем как загрузить, мы хотим узнать его размер, для этого выдаем команду SIZE /pud/tex/latex/llncs2e.zip. Сервер в ответ выдает размер файла в байтах 213 230229. 

Переходим в пассивный режим с помощью команды PASV. 

В ответ сервер говорит, что он перешел в пассивный режим 227 Entering Passive Mod (213, 71, 6, 142, 35, 141) и передает нам 6 чисел, которые нужно использовать для установки соединения для передачи данных. Первые 4 числа это IP-адрес, вторые два числа используются, чтобы узнать порт на который нужно установить соединение. Первое число 35 нужно умножить на 256 и прибавить второе число 141, так мы узнаем порт. 

Для того, чтобы загрузить нужный нам файл используем команду RETR /pud/tex/latex/llncs2e.zip. После того, как мы выдали эту команду сервер ждет, что мы установим соединение с IP-адресом и портом, которые он нам указал. 

После того, как соединение для передачи данных установлено, сервер сообщает нам об этом в управляющем соединении. 150 Opening BINARY mode data connection for /pud/tex/latex/llncs2e.zip (230229 bytes). Также сервер говорит, что передача данных ведется в бинарном режиме. 

После того, как передача файла закончена, сервер сообщает нам об этом 226 Transfer complete. Клиент выдает команду QUIT чтобы разорвать соединение. Сервер сообщает нам некоторую статистику, сколько было передано байт и файлов. 221 You have transferred 239229 bytes in 1 file. И говорит до свидания 221 Goodbye. На этом сеанс работы по протоколу FTP завершен. 

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

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

Протокол HTTP/2 существенно ускоряет открытие сайтов за счет следующих особенностей:

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

приоритеты потоков: клиент может задавать серверу приоритеты — какого типа ресурсы для него более важны, чем другие;

сжатие заголовка: размер заголовка HTTP может быть сокращен;

push-отправка данных со стороны сервера: сервер может отправлять клиенту данные, которые тот еще не запрашивал, например, на основании данных о том, какую следующую страницу открывают пользователи.

Конкурс Дикси для digital-агентств

Разработайте классную идею в одной из 18 номинаций онлайн-конкурса – и получите возможность реализовать ее с Дикси, выиграть отличные призы от Коссы/Руварда – и получить заслуженное признание рынка.

Идеи и концепции агентств принимаются на конкурс до 7 декабря,
поторопитесь!

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

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

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP версия
• Код статуса
• Сообщение статуса, понятное для человека

Обычный статус выглядит примерно так:

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

response-header = Accept-Ranges
                | Age
                | ETag
                | Location
                | Proxy-Authenticate
                | Retry-After
                | Server
                | Vary
                | WWW-Authenticate

• Age время в секундах, когда сообщение было создано на сервере.
• ETag MD5 сущности для проверки изменений и модификаций ответа.
• Location используется для перенаправления и содержит новый URL адрес.
• Server определяет сервер, где было сформирован ответ.

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