Что такое http

Цели перехода на http/2

Новый протокол разработан для существенного улучшения работы веб-сайтов. Переход на http/2 имеет смысл, потому что он обладает рядом преимуществ:

• Добавлены новые методы согласования протокола. Как клиент, так и сервер имеют возможность пользоваться первой, второй версией HTTP и совершенно другими протоколами.
• Поддержка совместимости с большим количеством функций HTTP 1.1. К примеру, совместимость по виду URI, изобилию заголовков, набору методов доступа (POST, GET и т.д.), статусным кодам.
• Ускорение загрузки документов. Обеспечивается за счет сжатия HTTP-заголовков, конвейеризации запросов, применении push-технологий на сервере, устранении блокировки начала строки в протоколах 1.0 и 1.1, а также мультиплексировании нескольких запросов лишь в одном соединении.
• Сохранение совместимости с площадками, где внедрен HTTP. Это полные и мобильные версии браузеров, многие интерфейсы и сервера, в числе которых прокси-сервера.

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

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

Один из основных плюсов второй версии HTTP. В предыдущей версии для одного запроса была необходима установка отдельного TCP-соединения. И чем больше было запросов, тем медленней работал браузер. Благодаря мультиплексированию браузер отправляет сразу несколько запросов через одно TCP-соединение.

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

Приоритезация

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

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

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

Приоритезация в протоколе не обязательна, но рекомендована, потому что мультиплексирование не способно полноценно работать без приоритетов. Чревато это медленной загрузкой, даже хуже, чем в http 1.1 версии. Ресурсы вторичного приоритета, занимая полосу, негативно скажутся на производительности.

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

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

Поддержка поблочного кодирования HTTP

Если определить общую длину сообщения HTTP перед отправкой невозможно, то можно использовать функцию поблочного кодирования для отправки сообщений в виде серий блоков без поля заголовка Content-Length. Эта функция поддерживается во всех сообщениях HTTP-запросов и HTTP-ответов. Эта функция поддерживается на стороне получателя, а заголовок блока автоматически обрабатывается внутренней логикой. На стороне отправителя клиентом и сервером должны вызываться интерфейсы API nx_web_http_client_request_chunked_set и nx_web_http_server_response_chunked_set соответственно.

Дополнительные сведения об использовании этих служб можно найти в главе 3 «Описание служб HTTP».

Составляющие систем, основанных на HTTP

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

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

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

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

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

Сервер не обязательно расположен на одной машине, и наоборот — несколько серверов могут быть расположены (поститься) на одной и той же машине. В соответствии с версией HTTP/1.1 и имея заголовок, они даже могут делить тот же самый IP-адрес.

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

• caching (кеш может быть публичным или приватными, как кеш браузера)
• фильтрация (как сканирование антивируса, родительский контроль, …)
• выравнивание нагрузки (позволить нескольким серверам обслуживать разные запросы)
• аутентификация (контролировать доступом к разным ресурсам)
• протоколирование (разрешение на хранение истории операций)

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

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

Как он работает

HTTP-запрос состоит из трех элементов:

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

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

Метод + URL + HTTP/Версия

Метод (иногда его называют HTTP-глаголом) – описывает, какое именно действие нужно совершить со страницей. Можно придумать самые разные, но стандартных методов девять: GET, HEAD, POST, PUT, DELETE,CONNECT, OPTIONS, TRACE, PATCH. Их функциональность раскрывается в названии, они позволяют получить данные (GET), отправить данные на сервер (POST), удалить (DELETE) или заменить часть (PATCH).

URL (Uniform Resource Locator) – единообразный идентификатор ресурса, идентифицирует ресурс и определяет его точное местоположение. Именно с помощью URL записаны ссылки в интернете.

В отличие от него URN не ведет к конкретному адресу, а просто определяет ресурс во множестве терминов. Потенциально это удобно, чтобы не перегружать интернет устаревшими или пропавшими ссылками.

Версия показывает, какую версию протокола нужно использовать в ответе сервера.

HTTP-ответ строится примерно по тому же принципу, что и запрос:

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

Версия совпадает с версией в запросе.

Код состояния показывает статус запроса. Это трехзначное число, благодаря которому можно узнать, получен ли запрос, обработан ли он, какие ошибки есть. Например, одна из самых известных ошибок – 404 – сообщает о том, что сервер не нашел ресурс по адресу. Возможно, в запросе опечатка, ошибка или он не соответствует протоколу.

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

Курс

Этичный хакер

Начните с программирования на Python и JavaScript, изучите Linux и Windows и освойте тестирование на проникновение. Скидка 5% по промокоду BLOG.

Узнать больше

SPDY — 2009

Google пошёл дальше и стал экспериментировать с альтернативными протоколами, поставив цель сделать веб быстрее и улучшить уровень безопасности за счёт уменьшения времени задержек веб-страниц. В 2009 году они представили протокол SPDY.

Казалось, что если мы будем продолжать увеличивать пропускную способность сети, увеличится её производительность. Однако выяснилось, что с определенного момента рост пропускной способности перестаёт влиять на производительность. С другой стороны, если оперировать величиной задержки, то есть уменьшать время отклика, прирост производительности будет постоянным. В этом и заключалась основная идея SPDY.

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

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

В 2015 в Google решили, что не должно быть двух конкурирующих стандартов, и объединили SPDY с HTTP, дав начало HTTP/2.

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. (Последние три метки из
вышеперечисленных — не зарегистрированные метки; все, кроме
последней — примеры меток, которые могли бы быть зарегистрированы
в будущем.)

Обеспечение безопасности

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

Аутентификация клиентов

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

Передача конфиденциальной информации

Подобно любому общему протоколу передачи данных, HTTP не может регулировать содержимое передаваемых данных, не существует методов определения степени конфиденциальности конкретного фрагмента данных в пределах контекста запроса. Следовательно, приложения должны предоставлять как можно больше контроля провайдеру информации.
Четыре поля заголовка представляют интерес с точки зрения сохранения конфиденциальности: Server, Via, Referer и From.
Раскрытие версии программного обеспечения сервера может привести к большей уязвимости машины сервера к атакам на программы с известными слабостями. Разработчики должны сделать поле заголовка Server конфигурируемой опцией

Прокси, которые служат в качестве сетевого firewall, должны предпринимать специальные предосторожности в отношении передачи информации заголовков, идентифицирующей ЭВМ, за пределы firewall.

Персональная информация

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

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

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант — это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

• 202 Accepted: запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
• 204 No Content: в теле ответа нет сообщения.
• 205 Reset Content: указание серверу о сбросе представления документа.
• 206 Partial Content: ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

3xx: Перенаправление

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

• 301 Moved Permanently: ресурс теперь можно найти по другому URL адресу.
• 303 See Other: ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
• 304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности — Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

• 400 Bad Request: вопрос был сформирован неверно.
• 401 Unauthorized: для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
• 403 Forbidden: сервер не открыл доступ к ресурсу.
• 405 Method Not Allowed: неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
• 409 Conflict: сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

• 501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.
• 503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Аутентификация

HTTP действительно поддерживает рудиментарную форму аутентификации, называемой Основной Проверкой Подлинности (Basic Authentication), точно также как и более надежную форму — Краткую Проверку Подлинности (Digest Authentication).

В Основной Проверке Подлинности сервер сразу же отвергает запрос клиента с WWW-Authenticate и кодом состояния 401 — Unauthorized. Увидев этот заголовок, браузер отображает диалоговое окно входа с запросом имени пользователя и пароля. Эта информация отправляется в фотмате BASE64 в заголовке запроса на аутентификацию. Теперь сервер может проверить запрос и разрешить доступ, если учетные данные верны. Некоторые серверы могут даже отправить заголовок Autentification-Info, содержащий дополнительные детали об аутентификации.

Следствием Основной Проверки Подлинности является Проверка Подлинности Прокси. Вместо веб-сервера, задача аутентификации состоит в запрашивании промежуточного прокси-сервера. Прокси-сервер отправляет заголовок Proxy-Authenticate с кодом статуса 407-Unauthorized. В свою очередь, клиенту предлагается посылать мандаты с помощью заголовка запроса Proxy-Authorization.

Краткая Проверка Подлинности похожа на Основную ПП техникой, схожей с WWW-Authenticate и заголовками авторизации, но Краткая ПП использует более надежные хэш-функции для шифрования имени пользователя и пароля (обычно- MD5 или KD дайджест-функций). Хотя Краткая ПП должна быть более безопасной, чем Основная ПП, веб-сайты обычно используют Основную ПП из-за её простоты. Для смягчения проблем безопасности Основные ПП используются в сочетании с SSL (Secure Sockets Layer).

Протокол Secure HTTP

Протокол HTTPS обеспечивает безопасное соединение в Интернете. Самый простой способ узнать, используете ли Вы его: проверить адресную строку браузера. Защищенный компонент HTTPs включает в себя вставленный слой шифрования / дешифрования между HTTP и TCP- Secure Sockets Layer (SSL) или улучшенный протокол Transport Layer Security (TLS).

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

Существующие клиенты / серверы не должны изменить способ обработки сообщения, так что большая часть тяжелой работы проходит в слое SSL. Таким образом, вы можете разрабатывать веб-приложения, используя Основные ПП и автоматически пользоваться преимуществами SSL за счет перехода на протокол https://. Однако, чтобы веб-приложение работало на протоколе HTTPS, необходимо иметь рабочий цифровой сертификат, развернутый на сервере.

Сертификаты

Также как человеку нужен паспорт для удостоверения личности, серверу нужен цифровой сертификат для идентификации. Сертификаты (или “certs”) выдаются Центром Сертификации (CA) и поручаются за Вашу личность в Интернете. CA хранят в себе PKI. Наиболее распространенная форма сертификатов- стандарт X.509 v3, который содержит такую информацию:

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

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

Как только сертификат сверен, вступает в силу полная и безопасная передача SSL.

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

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

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

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

Встречается в статьях

Инструкции:

1. Как настроить связку Apache + HTTP/2 на Linux CentOS 7
2. Как установить и настроить связку Asterisk + FreePBX на CentOS 8
3. Настройка веб-сервера на CentOS 7 со всем необходимым для правильной работы
4. Настройка веб-сервера на CentOS 8 со всем необходимым для правильной работы
5. Настройка безопасности Linux с помощью Fail2ban
6. Инструкция по установке и использованию GLPI на Linux CentOS
7. Установка и настройка веб-сервера IIS + PHP + MySQL
8. Настройка почтового сервера iRedMail на Ubuntu
9. Как настроить почту для корпоративной среды на CentOS 8
10. Как настроить почту для корпоративной среды на Ubuntu Server
11. Настройка веб-сервера на Ubuntu со всем необходимым для правильной работы
12. Как настроить NGINX с поддержкой HTTP/2
13. Трансляция видео с веб-сервера с помощью NGINX + rtmp
14. Как настроить почту на базе Postfix для корпоративной среды
15. Установка и настройка системы мониторинга Prometheus на Linux
16. Как установить и настроить прокси-сервер Squid на CentOS
17. Как установить и настроить прокси-сервер Squid на Ubuntu Server
18. Установка веб-сервера Apache на FreeBSD
19. Установка и настройка почтового сервера Zimbra на Linux
20. Как установить и использовать сервер хранения секретов Hashicorp Vault

Мини-инструкции:

1. Как настраивать перенаправления в сервере NGINX
2. Как настроить Apache для работы по HTTPS (SSL)
3. Как настроить HTTP/2 на Windows Server 2016 и выше
4. Инструкция по установке и настройке phplist
5. Как установить и настроить сервер Haproxy на Linux CentOS 7
6. Установка и настройка прокси-сервера 3proxy на Linux CentOS 7
7. Настройка проксирования почты с NGINX для IMAP, POP3 и SMTP
8. Настройка сервера мониторинга Zabbix на Linux CentOS
9. Настройка сервера мониторинга Zabbix на Ubuntu
10. Установка и настройка своего локального репозитория CentOS
11. Установка и настройка LDAP сервера FreeIPA на Linux CentOS
12. Установка и настройка CRM Битрикс24 от 1С на Linux CentOS
13. Включение кеширования ответа от backend в Nginx
14. Как пройти SSL-проверку при настройке https в NGINX
15. Инструкция по установке и настройке phplist на Linux Ubuntu
16. Установка и настройка модуля PageSpeed для NGINX и Apache
17. Установка и использование почтового клиента WebMail Lite на Linux CentOS
18. Настройка сервера мониторинга Zabbix 5 на Linux CentOS 8
19. Организация сервиса календаря и адресной книги на базе Baikal
20. Публикация баз 1С как веб-приложение в Apache на операционной системе Windows
21. Программный межсетевой экрана (маршрутизатор) pfSense — установка и настройка
22. Как настроить балансировку http-запросов в веб-сервере NGINX
23. Как настроить прозрачную аутентификацию в NGINX через LDAP
24. Как установить и настроить веб-сервер на базе NGINX + uWSGI для поддержки приложений на Python
25. Кластер серверов Hashicorp Vault с доступом через систему обнаружения Consul
26. Как установить и настроить Consul-агента и зарегистрировать на кластере сервис
27. Установка второго сервера FreeIPA с настройкой репликации

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

Чтобы понять, как браузер общается с сервером, нужно думать как браузер, нужно стать браузером.

Попробуем обратиться к веб-странице http://http.maxkuznetsov.ru так, как это делают браузеры под капотом. Для этого отправим запрос из терминала/командной строки с помощью утилиты netcat. Чаще всего она установлена по умолчанию: в Mac OS X — это «nc», в других ОС может быть «ncat» или «netcat». (Или воспользуйтесь онлайн-сервисом https://reqbin.com/u4178vu3, в котором слева и справа выберите табы Raw для отображения «голых» запросов и ответов. Но из терминала получится нагляднее.)

Дальше ничего не произойдёт, терминал подвиснет — это нормально. Команда netcat подключилась к серверу по адресу http.maxkuznetsov.ru к 80-му порту, и сервер ждёт от нас текст запроса.

Введём в терминале такие строки запроса.

После Host нужно ввести две пустые строки: одна строка отступа, вторая содержит тело запроса, но в данном примере оно пустое. Такие правила протокола HTTP. Получив вторую пустую строку, веб-сервер поймёт, что запрос завершён, обработает его и пришлёт ответ, включающий интересующую нас веб-страницу с html.

После этого браузер разбирает ответ, убирает техническую информацию и отображает html-страницу в кодировке UTF-8  — так ему сказал сервер в заголовке Content-Type. Если в HTML включены CSS, Javascript, картинки, то браузер запросит их отдельными запросами ровно таким же образом. Если он их уже запрашивал раньше, то возьмёт из локального кэша. Поэтому первый раз страницы грузятся визуально дольше.

Разберём структуру запроса и ответа более детально.

HTTP/1.0 — 1996

В отличие от HTTP/0.9, спроектированного только для HTML-ответов, HTTP/1.0 справляется и с другими форматами: изображения, видео, текст и другие типы контента. В него добавлены новые методы (такие, как POST и HEAD). Изменился формат запросов/ответов. К запросам и ответам добавились HTTP-заголовки. Добавлены коды состояний, чтобы различать разные ответы сервера. Введена поддержка кодировок. Добавлены составные типы данных (multi-part types), авторизация, кэширование, различные кодировки контента и ещё многое другое.

Вот так выглядели простые запрос и ответ по протоколу HTTP/1.0:

Помимо запроса клиент посылал персональную информацию, требуемый тип ответа и т.д. В HTTP/0.9 клиент не послал бы такую информацию, поскольку заголовков попросту не существовало.

Пример ответа на подобный запрос:

В начале ответа стоит HTTP/1.0 (HTTP и номер версии), затем код состояния — 200, затем — описание кода состояния.

В новой версии заголовки запросов и ответов были закодированы в ASCII (HTTP/0.9 весь был закодирован в ASCII), а вот тело ответа могло быть любого контентного типа — изображением, видео, HTML, обычным текстом и т. п. Теперь сервер мог послать любой тип контента клиенту, поэтому словосочетание «Hyper Text» в аббревиатуре HTTP стало искажением. HMTP, или Hypermedia Transfer Protocol, пожалуй, стало бы более уместным названием, но все к тому времени уже привыкли к HTTP.

Один из главных недостатков HTTP/1.0 — то, что вы не можете послать несколько запросов во время одного соединения. Если клиенту надо что-либо получить от сервера, ему нужно открыть новое TCP-соединение, и, как только запрос будет выполнен, это соединение закроется. Для каждого следующего запроса нужно создавать новое соединение.

Почему это плохо? Давайте предположим, что вы открываете страницу, содержащую 10 изображений, 5 файлов стилей и 5 JavaScript файлов. В общей сложности при запросе к этой странице вам нужно получить 20 ресурсов — а это значит, что серверу придётся создать 20 отдельных соединений. Такое число соединений значительно сказывается на производительности, поскольку каждое новое TCP-соединение требует «тройного рукопожатия», за которым следует медленный старт.

Тройное рукопожатие

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

• SYN — Клиент генерирует случайное число, например, x, и отправляет его на сервер.
• SYN ACK — Сервер подтверждает этот запрос, посылая обратно пакет ACK, состоящий из случайного числа, выбранного сервером (допустим, y), и числа x + 1, где x — число, пришедшее от клиента.
• ACK — клиент увеличивает число y, полученное от сервера и посылает y + 1 на сервер.

Примечание переводчика: SYN — синхронизация номеров последовательности, (англ. Synchronize sequence numbers). ACK — поле «Номер подтверждения» задействовано (англ. Acknowledgement field is significant).

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

Тем не менее, некоторые реализации HTTP/1.0 старались преодолеть эту проблему, добавив новый заголовок Connection: keep-alive, который говорил бы серверу «Эй, дружище, не закрывай это соединение, оно нам ещё пригодится». Однако эта возможность не была широко распространена, поэтому проблема оставалась актуальна.

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