HTTP

Intro

HTTP

  • HyperText Transfer Protocol - HTTP - протокол передачи гипертекста - протокол прикладного уровня передачи данных.

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

  • Гипертекст — текстовые страницы, имеющие внутри себя ссылки на другие текстовые страницы (перекрёстные ссылки).

HTTP History

  • HTTP был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста.

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

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

HTTP History

  • HTTP/1.1 - современная версия протокола, принятая в июне 1999 года.

  • HTTP/2 - вторая версия протокола. Спецификация была опубликована как RFC 7540 в мае 2015.

HTTP

  • HTTP основан на архитектуре клиент-сервер.

  • Клиентское приложение формирует запрос и отправляет его на сервер.

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

HTTP over TCP/IP

HTTP over TCP/IP

HTTP over TCP/IP

  • Протокол HTTP использует протокол TCP как транспорт.

  • TCP (Transmission Control Protocol) - протокол передачи данных через сети интернет. TCP управляет механизмами установки постоянного соединения, передачи данных и завершения соединения.

  • Протокол TCP обеспечивает пересылку TCP/IP пакетов с данными. В данном случае именно этими данными и являются HTTP-сообщения.

HTTP URI

  • HTTP манипулирует ресурсами, которые указываются как URI в запросах клиента.

  • URI - Uniform Resource Identifier (унифицированный идентификатор ресурса) - путь до конкретного ресурса, уникально его идентифицирующий.

  • URI является либо URL, либо URN, либо одновременно обоими.

HTTP URI

  • URL — это URI, который, помимо идентификации ресурса, предоставляет еще и информацию о местонахождении этого ресурса. Как пример - https://rakovets.by/wiki

  • URN — это URI, который только идентифицирует ресурс в определённом пространстве имён. Пример: urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

HTTP Request

HTTP Request

Запрос состоит из 3 частей:

  • Стартовая строка

    • Метод

    • URI

    • Версия

  • Заголовки

    • Строки, содержащие разделенную двоеточием пару параметр-значение

  • Тело сообщения

    • Непосредственно данные, передаваемые запросом

Example

GET /tag/cats/ HTTP/1.1
Host: www.cutestpaw.com
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) Ubuntu Chromium/69.0.3497.81
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,
Referer: http://www.cutestpaw.com/
Accept-Encoding: gzip, deflate
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: ct_cookies_test=194ce5054594115105066f0fd991f1d9;

HTTP Request

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

Request       = Request-Line
                        *(( general-header
                         | request-header
                         | entity-header ) CRLF)
                        CRLF
                        [ message-body ]


Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

HTTP Response

HTTP Response

Ответ также состоит из 3 частей:

  • Стартовая строка

    • Версия

    • Код состояния (Status Code) - 3 цифры

    • Пояснения (Reason Phrase) - описание кода состояния

  • Заголовки

    • Строки, содержащие разделенную двоеточием пару параметр-значение

  • Тело сообщения

    • Непосредственно данные, возвращаемые сервером

Example

HTTP/1.1 200 OK
Server: nginx/1.10.2
Date: Fri, 21 Sep 2018 14:42:10 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
X-Powered-By: PHP/7.0.23
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate

<!DOCTYPE html>
<html xml:lang="en" lang="en" dir="ltr">
<head>
...

HTTP Methods

HTTP Methods

  • Метод HTTP - последовательность символов, указывающая на операцию, которую нужно осуществить с указанным ресурсом.

  • Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы.

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

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

HTTP Methods

  • Каждый сервер обязан поддерживать как минимум методы GET и HEAD.

  • Кроме методов GET и HEAD, часто применяется метод POST.

  • Также распространены и методы PUT, DELETE, PATCH, TRACE, CONNECT и OPTIONS.

GET

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

  • Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа ?: GET /path/resource?param1=value1&param2=value2 HTTP/1.1

GET

  • Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы

HEAD

  • Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело.

  • Запрос HEAD обычно применяется для извлечения метаданных, например:

    • проверка наличия ресурса (валидация URL).

    • узнать, не изменился ли он с момента последнего обращения.

    • если ресурс является файлом, можно узнать его размер и затем определиться со стратегией его загрузки.

POST

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

  • Например, ввод и отправка комментариев посетителями через HTML-форму, после чего они передаются серверу методом POST. Все введенные данные будут включаться в тело запроса.

  • Аналогично с помощью метода POST обычно загружаются файлы на сервер.

POST

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

  • Сообщение ответа сервера на выполнение метода POST не кэшируется.

PUT

  • Метод PUT применяется для загрузки содержимого запроса на указанный в запросе URI.

  • Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов:

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

    • Метод PUT предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

  • Сообщения ответов сервера на метод PUT не кэшируются.

HTTP Methods

  • PATCH - аналогично PUT, но применяется только к фрагменту ресурса.

  • DELETE - удаляет указанный ресурс.

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

  • LINK - устанавливает связь указанного ресурса с другими.

  • UNLINK - убирает связь указанного ресурса с другими.

OPTIONS

  • Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса.

  • В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов.

  • Для того чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — *.

  • Запросы OPTIONS * HTTP/1.1 могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Status code

Status code

  • Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр.

  • Первая цифра указывает на класс состояния.

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

Example

  • 200 OK

  • 201 Created

  • 403 Forbidden

  • 507 Insufficient Storage

Status code 1xx

  • 1xx: Informational (информационные)

  • В этот класс выделены коды, информирующие о процессе передачи.

  • При работе через протокол версии 1.0 сообщения с такими кодами должны игнорироваться.

  • В версии 1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно.

Status code 1xx

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

  • Подобные сообщения прокси-сервера должны отправлять дальше от сервера к клиенту.

Example

  • 100 Continue

  • 101 Switching Protocols

  • 102 Processing

Status code 2xx

  • 2xx: Success (успешно)

  • Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может еще передать заголовки и тело сообщения.

Example

  • 200 OK

  • 201 Created

  • 204 No Content

  • 206 Partial Content

Status code 3xx

  • 3xx: Redirection (перенаправление)

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

  • Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location.

Example

  • 301 Moved Permanently

  • 302 Moved Temporarily

  • 303 See Other

  • 307 Temporary Redirect

Status code 4xx

  • 4xx: Client Error (ошибка клиента)

  • Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Example

  • 400 Bad Request

  • 401 Unauthorized

  • 403 Forbidden

  • 404 Not Found

  • 405 Method Not Allowed

  • 418 I’m a teapot

Status code 5xx

  • 5xx: Server Error (ошибка сервера)

  • Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

Example

  • 500 Internal Server Error

  • 501 Not Implemented

  • 502 Bad Gateway

  • 503 Service Unavailable

  • 504 Gateway Timeout

Headers

Headers

  • Заголовки HTTP - это строки в HTTP-сообщении, содержащие разделенную двоеточием пару параметр-значение.

  • Каждый заголовок пишется с новой строки, иными словами, заголовки разделяются символом переноса строки(CRLF).

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

Headers

Server: Apache/2.2.11 (Win32) PHP/5.3.0
Cache-Control: no-cache
Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
Content-Type: text/html; charset=UTF-8
Content-Language: ru

Headers

Все заголовки разделяются на четыре основных группы:

  • General Headers (Основные заголовки)

    • Являются основными для запросов клиента и ответов сервера. Большая часть из них являются обязательными.

  • Request Headers (Заголовки запроса)

    • Используются только в запросах клиента.

    • Например: Host, Referer, User-Agent

Headers

  • Response Headers (Заголовки ответа)

    • Только для ответов от сервера.

    • Например: Location, Server, Allow

  • Entity Headers (Заголовки сущности)

    • Сопровождают каждую сущность сообщения.

    • Например: Content-Length, Content-Language, Content-Encoding

HTTP for binary

HTTP for binary

  • HTTP является текстовым протоколом.

  • Однако он позволяет передавать и двоичные данные.

  • Вся мультимедия, что мы видим на веб-странице - картинки, видео, аудио - все передается посредством HTTP.

HTTP for binary

  • Для этого можно воспользоваться одним из двух способов:

    • Кодирование информации в текстовый вид.
      Например: base64. Все символы должны быть в диапазоне от 0 до 127.

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

HTTP for binary

  • Принцип получения двоичных данных:

    • В запросе указывается заголовок Accept, которые содержит MIME-тип ресурса, который клиент ожидает получить. Например, Accept: image/png говорит, что ожидается изображение в формате PNG.

    • Сервер же заголовком Content-type указывает тип содержимого ответа. Например, Content-type: image/png укажет на получение картинки PNG.

    • Для обозначения произвольных двоичных данных используется. Например: Content-type: application/octet-stream

Example

GET /image/nyan-cat.jpeg HTTP/1.1
Host: example.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/69.0.3497.81
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Referer: http://www.cutestpaw.com/images/nyan-cat/
Accept-Encoding: gzip, deflate
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: ct_cookies_test=194ce5054594115105066f0fd991f1d9;

Example

HTTP/1.1 200 OK
Server: nginx/1.10.2
Date: Fri, 21 Sep 2018 17:05:34 GMT
Content-Type: image/jpeg
Content-Length: 61087
Last-Modified: Wed, 03 Feb 2016 14:52:34 GMT
Connection: keep-alive
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes

...

Total

Преимущества

  • Простота

    • Протокол прост в реализации, что позволяет с лёгкостью создавать клиентские приложения.

  • Расширяемость

    • Возможности протокола легко расширяются благодаря внедрению своих собственных заголовков, сохраняя совместимость с другими клиентами и серверами.

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

Преимущества

  • Распространенность

    • При выборе протокола HTTP для решения конкретных задач немаловажным фактором является его распространенность.

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

Недостатки

  • Большой размер сообщений.

    • Вследствие того, что протокол является текстовым, то и все передаваемые данные тоже в текстовом формате.

    • Это порождает существенно больший размер по сравнению с двоичными данными.

    • Из-за этого возрастает нагрузка на оборудование при формировании, обработке и передаче сообщений.

    • Для решения этой проблемы протокол уже содержит встроенные средства:

      • кэширование на стороне клиента

      • компрессия передаваемого содержимого.

Недостатки

  • Отсутствие навигации

    • Хотя протокол разрабатывался как средство работы с ресурсами сервера, у него отсутствуют в явном виде средства навигации среди этих ресурсов.

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

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

    • Это вполне нормально и удобно для человека, но затруднительно для автоматической обработки и анализ ресурсов.

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