Слайд 2
HTTP
HyperText Transfer Protocol — «протокол передачи гипертекста» —
протокол прикладного уровня передачи данных (изначально — в виде
гипертекстовых документов в формате HTML, в настоящий момент используется для передачи произвольных данных). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом
Слайд 4
HTTP
Основным объектом манипуляции в HTTP является ресурс, на
который указывает URI (Uniform Resource Identifier) в запросе клиента.
Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (В частности для этого используется HTTP-заголовок.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым
Слайд 5
URI.
URI - отвечает на вопрос: “Где и как
найти что - то?”
Пример:
http://example.com/just/some/long/path/path
Слайд 6
HTTP. История
HTTP/0.9
HTTP был предложен в марте 1991 года
Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для
доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация протокола привела к упорядочению правил взаимодействия между клиентами и серверами HTTP, а также четкому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.
HTTP/1.0
В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0.
HTTP/1.1
Текущая версия протокола, принята в июне 1999 года. Новым в этой версии был режим «постоянного соединения»: TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможной более простую организацию виртуального хостинга.
HTTP/2
11 февраля 2015 года опубликованы финальные версии черновика следующей версии протокола. В отличие от предыдущих версий, протокол HTTP/2 является бинарным. Среди ключевых особенностей мультиплексирование запросов, расстановка приоритетов для запросов, сжатия заголовков, загрузка нескольких элементов параллельно, посредством одного TCP соединения, поддержка проактивных push-уведомлений со стороны сервера.
Слайд 7
RFC.
Документы, содержащие технические спецификации и стандарты, широко применяемые
во всемирной сети интернет.
Существует более 5000 документов.
Слайд 8
HTTP. Структура
Каждое HTTP-сообщение состоит из трёх частей, которые
передаются в указанном порядке:
Стартовая строка (англ. Starting line) —
определяет тип сообщения;
Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.
Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.
Слайд 9
HTTP. Структура. Стартовая строка запроса
Метод URI HTTP/Версия
Слайд 10
HTTP. Структура. Стартовая строка запроса
Метод (англ. Method) —
название запроса, одно слово заглавными буквами
URI определяет путь к
запрашиваемому документу
Версия (англ. Version) — пара разделенных точкой цифр. Например: 1.0
Слайд 11
HTTP. Структура. Стартовая строка ответа
HTTP/Версия Код-Состояния Пояснение
Версия —
пара разделенных точкой цифр как в запросе.
Код состояния (англ.
Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента.
Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.
Слайд 13
HTTP. Методы
Последовательность из любых символов, кроме управляющих и
разделителей, указывающая на основную операцию над ресурсом. Метод представляет
собой короткое английское слово, записаное заглавными буквами. Название метода чувствительно к регистру
Слайд 14
HTTP. Методы
Каждый сервер обязан поддерживать как минимум методы
GET и HEAD. Если сервер не распознал указанный клиентом
метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.
Кроме методов GET и HEAD, часто применяется метод POST.
Слайд 15
HTTP. Методы
OPTIONS
GET
HEAD
POST
PUT
PATCH
DELETE
TRACE
CONNECT
Слайд 16
HTTP. Методы
OPTIONS
Используется для определения возможностей веб-сервера или параметров
соединения для конкретного ресурса. В ответ серверу следует включить
заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.
Результат выполнения этого метода не кэшируется
Слайд 17
HTTP. Методы
GET
Используется для запроса содержимого указанного ресурса. С
помощью метода GET можно также начать какой-либо процесс. В
этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.
Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:
GET /path/resource?param1=value1¶m2=value2 HTTP/1.1
Согласно стандарту HTTP, запросы типа GET считаются идемпотентными
Слайд 18
HTTP. Методы
HEAD
Аналогичен методу GET, за исключением того, что
в ответе сервера отсутствует тело. Запрос HEAD обычно применяется
для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая
Слайд 19
HTTP. Методы
POST
Применяется для передачи пользовательских данных заданному ресурсу.
Например, в блогах посетители обычно могут вводить свои комментарии
к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться очередная копия этого комментария).
При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.
Сообщение ответа сервера на выполнение метода POST не кэшируется
Слайд 20
HTTP. Методы
PUT
Применяется для загрузки содержимого запроса на указанный
в запросе URI. Если по заданному URI не существует
ресурс, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).
Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются
Слайд 21
HTTP. Методы
PATCH
Аналогично PUT, но применяется только к фрагменту
ресурса
Слайд 22
HTTP. Методы
DELETE
Удаляет указанный ресурс
Слайд 23
HTTP. Методы
TRACE
Возвращает полученный запрос так, что клиент может
увидеть, какую информацию промежуточные серверы добавляют или изменяют в
запросе
Слайд 24
HTTP. Методы
CONNECT
Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно
чтобы содействовать установлению защищённого SSL-соединения через нешифрованный прокси
Слайд 25
HTTP. Коды состояния
1xx Informational («Информационный»)
В этот класс выделены
коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с
такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
2xx Success («Успех»)
Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
3xx Redirection («Перенаправление»)
Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.
4xx Client Error («Ошибка клиента»)
Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
5xx Server Error («Ошибка сервера»)
Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
Слайд 26
HTTP. Коды состояния
1xx: Informational (информационные)
100 Continue («продолжай»)
101 Switching
Protocols («переключение протоколов»)
102 Processing («идёт обработка»)
Слайд 27
HTTP. Коды состояния
2xx: Success (успешно)
200 OK («хорошо»)
201 Created
(«создано»)
202 Accepted («принято»)
203 Non-Authoritative Information («информация не авторитетна»)
204 No
Content («нет содержимого»)
205 Reset Content («сбросить содержимое»)
206 Partial Content («частичное содержимое»)
207 Multi-Status («многостатусный»)
Слайд 28
HTTP. Коды состояния
3xx: Redirection (перенаправление)
300 Multiple Choices («множество
выборов»)
301 Moved Permanently («перемещено навсегда»)
302 Moved Temporarily («перемещено временно»)
302
Found («найдено»)
303 See Other (смотреть другое)
304 Not Modified (не изменялось)
305 Use Proxy («использовать прокси»)
306 — зарезервировано (код использовался только в ранних спецификациях)
307 Temporary Redirect («временное перенаправление»)
Слайд 29
HTTP. Коды состояния
4xx: Client Error (ошибка клиента)
400 Bad
Request («плохой, неверный запрос»)
401 Unauthorized («не авторизован»)
402 Payment Required
(«необходима оплата»)
403 Forbidden («запрещено»)
404 Not Found («не найдено»)
405 Method Not Allowed («метод не поддерживается»)
406 Not Acceptable («неприемлемо»)
407 Proxy Authentication Required («необходима аутентификация прокси»)
408 Request Timeout («истекло время ожидания»)
409 Conflict («конфликт»)
410 Gone («удалён»)
411 Length Required («необходима длина»)
412 Precondition Failed («условие ложно»)
Слайд 30
HTTP. Коды состояния
4xx: Client Error (ошибка клиента)
413 Request
Entity Too Large («размер запроса слишком велик»)
414 Request-URI Too
Large («запрашиваемый URI слишком длинный»)
415 Unsupported Media Type («неподдерживаемый тип данных»)
416 Requested Range Not Satisfiable («запрашиваемый диапазон не достижим»)
417 Expectation Failed («ожидаемое неприемлемо»)
422 Unprocessable Entity («необрабатываемый экземпляр»)
423 Locked («заблокировано»)
424 Failed Dependency («невыполненная зависимость»)
425 Unordered Collection («неупорядоченный набор»)
426 Upgrade Required («необходимо обновление»)
428 Precondition Required («необходимо предусловие»)
429 Too Many Requests («слишком много запросов»)
431 Request Header Fields Too Large («поля заголовка запроса слишком большие»)
434 Requested host unavailable. («Запрашиваемый адрес недоступен»)
444 Закрывает соединение без передачи заголовка ответа. Нестандартный код
449 Retry With («повторить с»)
451 Unavailable For Legal Reasons («недоступно по юридическим причинам»)
Слайд 31
HTTP. Коды состояния
5xx: Server Error (ошибка сервера)
500 Internal
Server Error («внутренняя ошибка сервера»)
501 Not Implemented («не реализовано»)
502
Bad Gateway («плохой, ошибочный шлюз»)
503 Service Unavailable («сервис недоступен»)
504 Gateway Timeout («шлюз не отвечает»)
505 HTTP Version Not Supported («версия HTTP не поддерживается»)
506 Variant Also Negotiates («вариант тоже проводит согласование»)
507 Insufficient Storage («переполнение хранилища»)
508 Loop Detected («обнаружена петля»)
509 Bandwidth Limit Exceeded («исчерпана пропускная ширина канала»)
510 Not Extended («не расширено»)
511 Network Authentication Required («требуется сетевая аутентификация»)
Слайд 32
HTTP. Заголовки
HTTP Headers — это строки в HTTP-сообщении,
содержащие разделенную двоеточием пару параметр-значение. Формат заголовков соответствует общему
формату заголовков текстовых сетевых сообщений ARPA (RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой
Слайд 34
HTTP. Заголовки
Все заголовки разделяются на четыре основных группы:
General
Headers («Основные заголовки») — могут включаться в любое сообщение
клиента и сервера.
Request Headers («Заголовки запроса») — используются только в запросах клиента.
Response Headers («Заголовки ответа») — только для ответов от сервера.
Entity Headers («Заголовки сущности») — сопровождают каждую сущность сообщения
Слайд 36
HTTP vs HTTPs
HyperText Transfer Protocol Secure — расширение
протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTPS,
«упаковываются» в криптографический протокол SSL или TLS.
В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443
Слайд 37
HTTP vs HTTPs
HTTPS не является отдельным протоколом. Это
обычный HTTP, работающий через шифрованные транспортные механизмы SSL и
TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства и сертификат сервера проверен и ему доверяют
Слайд 38
HTTP vs HTTPs
По умолчанию HTTPS URL использует 443
TCP-порт (для незащищённого HTTP — 80). Чтобы подготовить веб-сервер
для обработки https-соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера. Сертификат состоит из 2 частей (2 ключей) — public и private. Public-часть сертификата используется для зашифровывания трафика от клиента к серверу в защищённом соединении, private-часть — для расшифровывания полученного от клиента зашифрованного трафика на сервере. После того как пара ключей приватный/публичный сгенерированы, на основе публичного ключа формируется запрос на сертификат в Центр сертификации, в ответ на который ЦС высылает подписанный сертификат. ЦС при подписании проверяет клиента, что позволяет ему гарантировать, что держатель сертификата является тем, за кого себя выдаёт (обычно это платная услуга)
Слайд 39
HTTP vs HTTPs
Традиционно на одном IP-адресе может работать
только один HTTPS сайт. Для работы нескольких HTTPS-сайтов с
различными сертификатами применяется расширение TLS под названием Server Name Indication (SNI)