Что означают коды ответа сервера о состоянии страниц сайта

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

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

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

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

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

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

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

Замеряем пульс российского диджитал-консалтинга

Какие консалтинговые услуги востребованы на российском рынке, и как они меняют бизнес-процессы? Представляете компанию-заказчика диджитал-услуг?

Примите участие в исследовании Convergent, Ruward и Cossa!

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

5 последних уроков рубрики «Разное»

• Перевод сайта на https

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

• Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

  Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

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

• Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Резюме¶

Протокол HTTP это:

• однонаправленный (запрос/ответ)
• текстовый протокол
• не хранит состояния
• работает на сетевом уровне только через TCP
• может передавать любые данные
• используется не только в браузерах
• обслуживает львиную долю Интернет трафика

Достоинства

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

Недостатки

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

• Отсутствие навигации. У протокола отсутствую средства навигации среди
  ресурсов сервера. Клиент не может, как в FTP запросить список доступных
  файлов. Протокол предполагает, что пользователю уже известен URI
  интересующего его ресурса.

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

  Карта сайта может использоваться как пользователем, так и
  роботами-пауками поисковых систем, уменьшая для них глубину
  просмотра—минимально необходимое количество переходов с главной страницы.
  Аналогичную функцию выполняют и файлы sitemap, но только для
  приложений. Данная проблема полностью решена в протоколе более высокго
  уровня WebDAV с помощью добавленного метода PROPFIND, который
  позволяет получить не только дерево каталогов, но и список параметров
  каждого ресурса.

• Отсутствие поддержки распределённости. Изначально протокол HTTP
  разрабатывался для решения типичных бытовых задач, где само по себе время
  обработки запроса должно занимать незначительное время или вовсе не
  приниматься в расчёт. Однако со временем стало очевидно, что при
  промышленном использовании с применением распределённых вычислений при
  высоких нагрузках на сервер протокол HTTP оказывается непригоден. В
  связи с этим с 1998 году был предложен альтернативный протокол HTTP-NG (англ. HTTP Next
  Generation), но этот протокол до сих пор находится на стадии разработки.

Различие между HTTP и HTTPS

Большинство людей не знают о различиях между http:// и https://, поскольку оба они почти визуально схожи. Знание различий между ними имеет первостепенное значение для поддержания безопасного и эффективного сайта, способного защитить информацию и данные. Браузеры были разработаны таким образом, что строка URL-адреса будет выделять буквы S в HTTPS другим цветом, чтобы пользователи могли их заметить.

Вот некоторые очевидные различия между ними:

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

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

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

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

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

Резюме технических различий между HTTP и HTTPS:

• HTTP небезопасен, в то время как HTTPS является безопасным протоколом.
• HTTP использует TCP порт 80, в то время как HTTPS использует TCP порт 4433.
• HTTP работает на прикладном уровне, в то время как HTTPS работает на транспортном уровне безопасности (TLS).
• Для HTTP не требуется сертификат SSL, но HTTPS требует, чтобы сертификат SSL был подписан и внедрен центром сертификации (ЦС).
• HTTP не обязательно требует подтверждения домена, в то время как HTTPS в обязательном порядке требует подтверждения домена и определенных сертификатов, которые требуют юридического оформления.
• Во время зашифровки данных непосредственно перед их передачей для протокола HTTPS шифрование данных в HTTP не выполняется.
• HTTPS является расширением протокола HTTP. В этом случае он работает совместно с другим протоколом, а именно Secure Sockets Layer (SSL) для безопасной передачи данных.
• Как HTTP, так и HTTPS не обращаются к данным, которые будут передаваться по назначению. И наоборот, SSL не имеет никакого отношения к тому, как будут выглядеть данные.

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

HTTP-заголовки

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

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

Заголовки запросов

К числу наиболее важных HTTP-заголовков, которые можно включать в запросы, но нельзя включать в ответы, относятся:

Заголовок Accept

Это список MIME-типов, принимаемых клиентом, в формате тип/подтип. Элементы списка должны разделяться запятыми:

Accept: text/html, image/gif, */*

Элемент */* указывает, что все типы будут приняты и обработаны клиентом. Если тип запрошенного файла не может быть обработан клиентом, возвращается ошибка HTTP 406 «Not acceptable» (недопустимо).

Заголовок From

Указывает адрес электронной почты в Интернете учетной записи пользователя, под которой работает клиент, направивший запрос:

From: alexerohinzzz@gmail.com

Заголовок Referer

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

Referer: http://www.professorweb.ru

Заголовок User-Agent

Представляет собой строку, идентифицирующую приложение-клиент (обычно браузер) и платформу, на которой оно выполняется. Общий формат имеет вид: программа/версия библиотека/версий, но это не неизменный формат:

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) 
   Chrome/24.0.1312.56 Safari/537.17

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

Заголовки ответов

В ответы могут включаться следующие заголовки:

Заголовок Content-Type

Используется для указания типа данных, отправляемых получателю или, в случае метода HEAD, тип данных, который был бы отправлен в ответ на запрос GET:

Content-Type: text/html

Заголовок Expires

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

Expires: Fri, 19 Aug 2012 16:00:00 GMT

Заголовок Location

Определяет точное расположение другого ресурса, к которому может быть перенаправлен клиент. Если это значение представляет собой полный URL, сервер возвращает клиенту «redirect» для непосредственного извлечения указанного объекта:

Location: http://www.samplesite.com

Если ссылка на другой файл относится к серверу, должен указываться частичный URL.

Заголовок Server

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

Server: Microsoft-IIS/7.0

Общие заголовки

Несколько заголовков могут включаться как в запрос, так и в ответ, например:

Заголовок Date

Используется для установки даты и времени создания сообщения:

Date: Tue, 16 Aug 2012 18:12:31 GMT

Заголовок Connection

В НТТР/1.0 мы могли использовать в запросе заголовок Connection, указывая, что хотим сохранить соединение после отправки ответа. Теперь такое поведение принято по умолчанию, и в HTTP/1.1 можно использовать заголовок Connection, чтобы указать, что постоянное соединение не нужно:

Connection: close

Talks and Presentations

Preliminary HTTP/1.1 Performance
Evaluation by Jim Gettys

The HTTP/1.1 performance
paper explains the experiments in detail, and was recently
submitted for publication. This work shows how you can gain as much as
a factor of 10 in number of packets and 2 in times of speed by using
HTTP/1.1 pipelining. Earliest results were presented at the IETF meeting in San Jose,
December 1996, and more complete results at the W3C Advisory Committee Meeting
in England in January.

Overview of new HTTP/1.1 functionality and
changes from HTTP/1.0 by Jim Gettys

This presentation gives a good overview of new features. It will be
updated occasionally as it is presented. The presentation is also
available for Microsoft
PowerPoint

PEP — An Extension Mechanism for HTTP
by Henrik Frystyk Nielsen and Rohit Khare

This presentation was given at the IETF meeting in
Montreal, June 1996.

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

Ниже приведен пример диалога между HTTP-клиентом и HTTP-сервером, работающим на www.example.com, порт 80.

Запрос клиента

ПОЛУЧАТЬ  HTTP1.1Хозяин www.example.com

За клиентским запросом (состоящим в данном случае из строки запроса и только одного поля заголовка) следует пустая строка, так что запрос заканчивается двойной новой строкой, каждая в форме возврат каретки за которым следует перевод строки. В поле «Хост» различаются различные DNS имена, разделяющие один айпи адрес, позволяя на основе имени виртуальный хостинг. Хотя в HTTP / 1.0 это необязательно, в HTTP / 1.1 это обязательно. («/» Означает /index.html, если он есть.)

Ответ сервера

HTTP1.1 200 OkДата Пн, 23 мая 2005 г., 22:38:34 GMTТип содержимого текст / html; charset = UTF-8Content-Length 155Последнее изменение Ср, 8 января 2003 г., 23:11:55 GMTСервер Apache / 1.3.3.7 (Unix) (Red-Hat / Linux)ETag "3f80f-1b6-3e1cb03b"Принять-диапазоны байтыСвязь Закрыть<html>  <голова>    <заглавие>Пример страницы</заглавие>  </голова>  <тело>    <п>Привет, мир, это очень простой HTML-документ.</п>  </тело></html>

В ETag Поле заголовка (тег объекта) используется для определения того, идентична ли кэшированная версия запрошенного ресурса текущей версии ресурса на сервере. Тип содержимого определяет Тип интернет-СМИ данных, передаваемых HTTP-сообщением, а Content-Length указывает его длину в байтах. HTTP / 1.1 веб сервер публикует свою способность отвечать на запросы для определенных диапазонов байтов документа, устанавливая поле Accept-Ranges: байты. Это полезно, если клиенту нужны только определенные порции ресурса, отправленного сервером, который называется байтовое обслуживание. Когда Подключение: закрыть отправлено, это означает, что веб сервер закроет TCP соединение сразу после передачи этого ответа.

Большинство строк заголовка необязательны. Когда Content-Length отсутствует длина определяется другими способами. При кодировании с фрагментированной передачей для обозначения конца содержимого используется размер фрагмента 0. Личность кодирование без Content-Length читает содержимое, пока сокет не будет закрыт.

А Content-Encoding подобно gzip может использоваться для сжатия передаваемых данных.

Интернет-протокол (IP)

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

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

Под ним находится канальный уровень – часть протокола, так сказать, «голая металлическая». С другой стороны, убедительный аргумент в пользу полного пересмотра можно увидеть по той скорости, с которой создателям IPFS (межпланетной файловой системы) удалось закрыть финансирование ICO, которое в течение одного месяца составило 250 миллионов долларов США.

Мы можем проследить начало протокола IP еще в 1974 году, к статье, опубликованной Институтом инженеров по электротехнике и электронике и автором которой являются Винт Серф и Боб Кан. Он детализировал пакеты, отправляемые по сети, маршрутизируя их по IP-адресам и численно определяемым адресам узлов в сети / сетях. Протокол определял формат этих пакетов или датаграмм – его заголовки и полезную нагрузку.

После определения RFC 760 от 1980 года IETF согласился с определением, широко используемым по сей день, в своем запросе комментариев 791 . Это четвертая версия протокола, но можно сказать, что это первая производственная версия.

Интернет-протокол (Источник изображения: RFC791 )

Он использует 32-битные адреса, что устанавливает ограничение на количество адресов около 4 миллиардов. Это ограничение объясняет загадку того, почему некоммерческие интернет-пользователи получают «динамические IP-адреса» от своих интернет-провайдеров, а статический IP-адрес считается «добавленной стоимостью» и часто требует дополнительной оплаты.

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

Интернет-протокол версии 6 или IPv6 стал способом устранения этих ограничений, в том числе постепенного принятия по сравнению с предыдущей версией. Он был подготовлен в качестве проекта стандарта для IETF в 1998 году и был повышен до стандарта Интернета в 2017 году.

Хотя адресное пространство IPv4 было ограничено длиной 32-разрядного адреса, стандарту IPv6 было присвоено 128 битов, или 3,4 * 10 ^ 38 возможных адресов. Этого должно быть достаточно, чтобы продержаться у нас довольно долго.

По данным Google и IPv6 среди пользователей, внедрение IPv6 составляет чуть более 25% по состоянию на март 2019 года.

Принятие IPv6

IP является рудиментарным уровнем интернет-стека, определяющим самые основные вещи, без гарантий доставки, целостности данных или упорядочения передаваемых пакетов. Само по себе это ненадежно. Формат заголовка IPv4 предусматривает контрольную сумму заголовка, которую узлы передачи используют для проверки целостности заголовка. Это отличает его от версии IPv6, которая основывается на канальном уровне, что делает его более быстрым.

Заголовок датаграммы в Интернете (Источник изображения: RFC791 )

Резюме

Есть люди, которые думают, что из-за того, что стандарт HTTP/2 еще не принят, может быть слишком рано настаивать на использовании HTTP/3 (версия три). Это верный момент, но, как мы уже упоминали, этот протокол уже видел широкомасштабные тесты и реализации. Google начал тестировать его уже в 2015 году , а Facebook – в 2017 году .

С тех пор к стандартизации присоединились другие игроки, такие как Akamai и Mozilla. На последнем хакатоне IETF в ноябре 2018 года список участников проявил интерес к QUIC такими компаниями, как Facebook, Apple, Google, Mozilla, NetApp и LiteSpeed ​​Tech. Были некоторые многообещающие тесты , и похоже, что LiteSpeed ​​может быть первым крупным поставщиком серверов с работающим сервером HTTP/3 . Cloudflare также в настоящее время работает в бета-версии QUIC .

Вскоре после этого QUIC был переименован в HTTP/3 в интернет-проектеIETF . Срок его действия истекает в конце июня 2019 года, и мы можем ожидать RFC или окончательный стандарт где-то в июле.

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

Когда HTTP/3 будет доступен. Как только RFC будет завершен (лето 2019 года) и Nginx официально поддержит QUIC.

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

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

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: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Примечания

1. Google придумала, как заставить сайты перейти на HTTPS
2. Kazakhstan government is now intercepting all HTTPS traffic
3. Why do 20 per cent of the world’s biggest websites ignore HTTPS
4. Число сайтов в рунете, работающих по протоколу HTTPS, увеличилось в четыре раза
5. Антивирусы и сетевые устройства, призванные усилить безопасность, только вредят HTTPS
6. Веб-браузеры также виноваты в ситуации с Lenovo Superfish
7. Атака посредника, атака «человек посередине», MITM-атака (англ. Man in the middle) — термин в криптографии, обозначающий ситуацию, когда криптоаналитик (атакующий) способен читать и видоизменять по своей воле сообщения, которыми обмениваются корреспонденты, причём ни один из последних не может догадаться о его присутствии в канале
8. SPDY — протокол прикладного уровня для передачи веб-контента. Разработан корпорацией