Протокол передачи гипертекста http: Простым языком об HTTP / Хабр

Простым языком об HTTP / Хабр

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

HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

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

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

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

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

Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.

Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.

Предположим, что он ввёл в адресной строке следующее:

http://alizar.habrahabr.ru/

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

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

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

После того, как вы подключитесь к серверу, нужно отправить HTTP-запрос. Это, кстати, очень легко — HTTP-запросы могут состоять всего из двух строчек.

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

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

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

GET / HTTP/1.1

Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

OPTIONS * HTTP/1.1

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:

echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80

Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:

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

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.

После стартовой строки следуют заголовки, а также тело ответа. Например:

HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sat, 08 Mar 2014 22:53:46 GMT
Content-Type: application/octet-stream
Content-Length: 7
Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT
Connection: keep-alive
Accept-Ranges: bytes

Wisdom

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка

Content-Length

(в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

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

Смотрите сами:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 08 Mar 2014 22:29:53 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Keep-Alive: timeout=25
Location: http://habrahabr.ru/users/alizar/

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h2>302 Found</h2></center>
<hr><center>nginx</center>
</body>
</html>

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

То есть:

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.

А что с безопасностью?

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

SSL

или

TLS

.

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

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

SPDY

(произносится как английское слово

speedy

, не является аббревиатурой) является модификацией протокола HTTP, цель которой — уменьшить задержки при загрузке веб-страниц, а также обеспечить дополнительную безопасность.

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

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

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

Впрочем, если вы знаете английский и хотите углубиться в изучение не только самого HTTP, но и используемых для передачи пакетов TCP/IP, то рекомендую прочитать вот эту статью.

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

Удачи и плодотворного обучения!

Обзор протокола HTTP — HTTP

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

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

Хотя HTTP был разработан  ещё в начале 1990-х годов, за счёт своей расширяемости в дальнейшем он все время совершенствовался.  HTTP является протоколом прикладного уровня, который чаще всего использует возможности другого протокола — TCP (или TLS — защищённый TCP) — для пересылки своих сообщений, однако любой другой надёжный транспортный протокол теоретически может быть использован для доставки таких сообщений. Благодаря своей расширяемости, он используется не только для получения клиентом гипертекстовых документов, изображений и видео, но и для передачи содержимого серверам, например, с помощью HTML-форм. HTTP также может быть использован для получения только частей документа с целью обновления веб-страницы по запросу (например посредством AJAX запроса).

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

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

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

Клиент: участник обмена

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

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

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

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

Веб-сервер

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

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

Прокси

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

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

HTTP — прост

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

HTTP — расширяемый

Введённые в HTTP/1.0 HTTP-заголовки сделали этот протокол лёгким для расширения и экспериментирования. Новая функциональность может быть даже введена простым соглашением между клиентом и сервером о семантике нового заголовка.

HTTP не имеет состояния, но имеет сессию

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

HTTP и соединения

Соединение управляется на транспортном уровне, и потому принципиально выходит за границы HTTP. Хотя HTTP не требует, чтобы базовый транспортного протокол был основан на соединениях,  требуя только надёжность, или отсутствие потерянных сообщений (т.е. как минимум представление ошибки). Среди двух наиболее распространённых транспортных протоколов Интернета, TCP надёжен, а UDP — нет. HTTP впоследствии полагается на стандарт TCP, являющийся основанным на соединениях, несмотря на то, что соединение не всегда требуется.

HTTP/1.0 открывал TCP-соединение для каждого обмена запросом/ответом, имея два важных недостатка: открытие соединения требует нескольких обменов сообщениями, и потому медленно, хотя становится более эффективным при отправке нескольких сообщений, или при регулярной отправке сообщений: тёплые соединения более эффективны, чем холодные.

Для смягчения этих недостатков, HTTP/1.1 предоставил конвейерную обработку (которую оказалось трудно реализовать) и устойчивые соединения: лежащее в основе TCP соединение можно частично контролировать через заголовок  Connection. HTTP/2 сделал следующий шаг, добавив мультиплексирование сообщений через простое соединение, помогающее держать соединение тёплым и более эффективным.

Проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google экспериментирует с QUIC, которая основана на  UDP, для предоставления более надёжного и эффективного транспортного протокола.

Естественная расширяемость HTTP со временем позволила большее управление и функциональность Сети. Кеш и методы аутентификации были ранними функциями в истории HTTP. Способность ослабить первоначальные ограничения, напротив, была добавлена в 2010-е.

Ниже перечислены общие функции, управляемые с HTTP.

• Кеш
  Сервер может инструктировать прокси и клиенты: что и как долго кешировать. Клиент может инструктировать прокси промежуточных кешей игнорировать хранимые документы.
• Ослабление ограничений источника
  Для предотвращения шпионских и других, нарушающих приватность, вторжений, веб-браузер обеспечивает строгое разделение между веб-сайтами. Только страницы из того же источника могут получить доступ к информации на веб-странице. Хотя такие ограничение нагружают сервер, заголовки HTTP могут ослабить строгое разделение на стороне сервера, позволяя документу стать частью информации с различных доменов (по причинам безопасности).
• Аутентификация
  Некоторые страницы доступны только специальным пользователям. Базовая аутентификация может предоставляться через HTTP, либо через использование заголовка WWW-Authenticate (en-US) и подобных ему, либо с помощью настройки спецсессии, используя куки.
• Прокси и туннелирование
  Серверы и/или клиенты часто располагаются в интернете, и скрывают свои истинные IP-адреса от других. HTTP запросы идут через прокси для пересечения этого сетевого барьера. Не все прокси — HTTP прокси. SOCKS-протокол, например, оперирует на более низком уровне. Другие, как, например, ftp, могут быть обработаны этими прокси.
• Сессии
  Использование HTTP кук позволяет связать запрос с состоянием на сервере. Это создаёт сессию,  хотя ядро HTTP — протокол без состояния.  Это полезно не только для корзин в интернет-магазинах, но также для любых сайтов, позволяющих пользователю настроить выход.

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

1. Открытие TCP соединения: TCP-соединение будет использоваться для отправки запроса или запросов, и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее, или открыть несколько TCP-соединений к серверу.
2. Отправка HTTP-сообщения: HTTP-сообщения (до HTTP/2) — человеко-читаемо. Начиная с HTTP/2, простые сообщения инкапсулируются во фреймы, делая невозможным их чтения напрямую, но принципиально остаются такими же.

   GET / HTTP/1.1
   Host: developer.mozilla.org
   Accept-Language: fr

3. Читает ответ от сервера:

   HTTP/1.1 200 OK
   Date: Sat, 09 Oct 2010 14:28:02 GMT
   Server: Apache
   Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
   ETag: "51142bc1-7449-479b075b2891b"
   Accept-Ranges: bytes
   Content-Length: 29769
   Content-Type: text/html
   
   <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

4. Закрывает или переиспользует соединение для дальнейших запросов.

Если активирован HTTP-конвейер, несколько запросов могут быть отправлены без ожидания получения первого ответа целиком. HTTP-конвейер тяжело внедряется в существующие сети, где старые куски ПО сосуществуют с современными версиями.  HTTP-конвейер был заменён в HTTP/2 на более надёжные мультиплексные запросы во фрейме.

HTTP/1.1 и более ранние HTTP сообщения человеко-читаемы. В версии HTTP/2 эти сообщения встроены в новую бинарную структуру, фрейм, позволяющий оптимизации, такие как компрессия заголовков и мультиплексирование. Даже если часть оригинального HTTP сообщения отправлена в этой версии HTTP, семантика каждого сообщения не изменяется и клиент воссоздаёт (виртуально) оригинальный HTTP-запрос. Это также полезно для понимания HTTP/2 сообщений в формате HTTP/1.1.

Существует два типа HTTP сообщений, запросы и ответы, каждый в своём формате.

Запросы

Примеры HTTP запросов:

Запросы содержат следующие элементы:

• HTTP-метод, обычно глагол подобно GET, POST или существительное, как OPTIONS или HEAD, определяющее операцию, которую клиент хочет выполнить. Обычно, клиент хочет получить ресурс (используя GET) или передать значения HTML-формы (используя POST), хотя другие операция могут быть необходимы в других случаях.
• Путь к ресурсу: URL ресурсы лишены элементов, которые очевидны из контекста, например без protocol (http://), domain (здесь developer.mozilla.org), или TCP port (здесь 80).
• Версию HTTP-протокола.
• Заголовки  (опционально), предоставляющие дополнительную информацию для сервера.
• Или тело, для некоторых методов, таких как POST, которое содержит отправленный ресурс.

Ответы

Примеры ответов:

Ответы содержат следующие элементы:

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

HTTP — лёгкий в использовании расширяемый протокол. Структура клиент-сервера, вместе со способностью к простому добавлению заголовков, позволяет HTTP продвигаться вместе с расширяющимися возможностями Сети.

Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP сообщения во фреймы для улучшения производительности, базовая структура сообщений осталась с HTTP/1.0. Сессионный поток остаётся простым, позволяя исследовать и отлаживать с простым монитором HTTP-сообщений.

HTTP | MDN

Протокол передачи гипертекста (Hypertext Transfer Protocol — HTTP) — это прикладной протокол для передачи гипертекстовых документов, таких как HTML. Он создан для связи между веб-браузерами и веб-серверами, хотя в принципе HTTP может использоваться и для других целей. Протокол следует классической клиент-серверной модели, когда клиент открывает соединение для создания запроса, а затем ждёт ответа. HTTP — это протокол без сохранения состояния, то есть сервер не сохраняет никаких данных (состояние) между двумя парами «запрос-ответ». Несмотря на то, что HTTP основан на TCP/IP, он также может использовать любой другой протокол транспортного уровня с гарантированной доставкой.

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

Обзор HTTP

Основные свойства клиент-серверного протокола: что можно сделать и для чего он предназначен.

HTTP-кеширование (HTTP Cache)

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

HTTP-куки (HTTP cookies)

Как работают куки, можно почитать в RFC 6265. При обслуживании HTTP-запроса сервер может отправить в ответе HTTP-заголовок Set-Cookie. После этого значение куки посылается клиентом с каждым запросом к этому серверу. Делается это в форме заголовка запроса Cookie. Дополнительно можно указать истечение срока куки, а так же ограничения для специфического домена или пути.

Контроль доступа (совместное использование ресурсов между разными источниками, HTTP access control (CORS))

Межсайтовые HTTP-запросы (кросс-сайтовые) — это HTTP-запросы к ресурсам, находящимся в домене, отличающемся от того, с которого производится запрос. Например, HTML-страница, загружаемая с домена А (http://domaina.example), запрашивает изображение с домена Б (http://domainb.foo), используя тег img (http://domainb.foo/image.jpg). Это происходит постоянно в мире веба: страницы загружают различные ресурсы в кросс-сайтовой манере, включая стили (CSS), изображения, скрипты и другие ресурсы. CORS позволяет разработчикам сайтов контролировать межсайтовые запросы.

Эволюция HTTP

Краткое описание изменений, произошедших в HTTP, начиная с самых ранних версий, заканчивая новой HTTP/2 и далее.

Принципы веб-безопасности Mozilla

Сборник советов для помощи в разработке защищённых веб-приложений.

HTTP-сообщения (HTTP Messages)

Описывает тип и структуру разных видов сообщений HTTP/1.x и HTTP/2.

Обычный сеанс HTTP

Показывает и описывает течение обычного сеанса HTTP.

Управление подключениями в HTTP/1.x

Описывает три модели управления подключениями, доступными в HTTP/1.x, их сильные и слабые стороны.

Контроль предварительной загрузки DNS (Controlling DNS prefetching)

Firefox, как и большинство других браузеров, выполняет предварительную загрузку DNS (DNS prefetching). Это действие, когда браузеры превентивно выполняют разрешение доменных имён (получают имена доменов) для ссылок, по которым пользователь может перейти, а также для ссылок на ресурсы, такие как картинки, CSS,  JavaScript. Эта предварительная загрузка выполняется в фоновом режиме, так что вполне вероятно, что к моменту обращения к объектам в документе DNS уже получен. Это уменьшает задержки, когда, например, пользователь кликает на ссылку.

Справочники

Глубже изучите HTTP с помощью справочников и документации.

HTTP-заголовки (HTTP Headers)

Заголовки HTTP-сообщения используются для точного описания загружаемого ресурса или поведения сервера или клиента. Пользовательские заголовки можно добавить, используя X- префикс; другие перечислены в  IANA registry, содержание которого в свою очередь определено в RFC 4229. IANA так же поддерживает регистр предложенных новых HTTP-заголовков.

Методы HTTP-запроса

Различные операции, которые выполняются с HTTP:
 

Коды ответа (HTTP response codes)

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

Директивы CSP

Поля заголовка ответа Content-Security-Policy (en-US) позволяют администраторам веб-сайтов контролировать ресурсы, которые браузер пользователя может загрузить на данную веб-страницу. За некоторым исключением, эти политики связаны с указанием сервера-источника и адресов доступа (обращения) скриптов.

Инструменты и ресурсы

Полезные инструменты и ресурсы для понимания и отладки HTTP.

Инструменты разработчика Firefox

Сетевой монитор

Mozilla Observatory

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

RedBot

Инструмент для проверки кеширования заголовков.

Принципы работы современных веб-браузеров

Комплексная статья по внутренностям браузеров и потоку запросов через протокол HTTP. Это нужно понимать всем веб-разработчикам.

Лекция 4. Протокол HTTP | Веб-программирование

Презентация

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) — символьно-ориентированный клиент-серверный протокол прикладного уровня без сохранения состояния, используемый сервисом World Wide Web.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier – уникальный идентификатор ресурса) в запросе клиента. Основными ресурсами являются хранящиеся на сервере файлы, но ими могут быть и другие логические (напр. каталог на сервере) или абстрактные объекты (напр. ISBN). Протокол HTTP позволяет указать способ представления (кодирования) одного и того же ресурса по различным параметрам: mime-типу, языку и т. д. Благодаря этой возможности клиент и веб-сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

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

Структура протокола определяет, что каждое HTTP-сообщение состоит из трёх частей (рис. 1), которые передаются в следующем порядке:

1. Стартовая строка (англ. Starting line) — определяет тип сообщения;
2. Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
3. Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Рис. 1. Структура протокола HTTP
(дамп пакета, полученный сниффером Wireshark)

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

Cтартовая строка является обязательным элементом, так как указывает на тип запроса/ответа, заголовки и тело сообщения могут отсутствовать.

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

Метод URI HTTP/Версия протокола

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

GET /web-programming/index.html HTTP/1.1

Стартовая строка ответа сервера имеет следующий формат:

HTTP/Версия КодСостояния [Пояснение]

Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:

HTTP/1.1 200 Ok

Методы протокола

Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами (Табл. 1). Названия метода чувствительны к регистру.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Наиболее востребованными являются методы GET и POST — на человеко-ориентированных ресурсах, POST — роботами поисковых машин и оффлайн-браузерами.

Прокси-сервер

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

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

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

Каждый код представляется целым трехзначным числом. Первая цифра указывает на класс состояния, последующие — порядковый номер состояния (рис 1.). За кодом ответа обычно следует краткое описание на английском языке.

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

Применяемые в настоящее время классы кодов состояния и некоторые примеры ответов сервера приведены в табл. 2.

100 Continue (Продолжать)
101 Switching Protocols (Переключение протоколов)
102 Processing (Идёт обработка)

200 OK (Успешно).
201 Created (Создано)
202 Accepted (Принято)
204 No Content (Нет содержимого)
206 Partial Content (Частичное содержимое)

300 Multiple Choices (Множественный выбор)
301 Moved Permanently (Перемещено навсегда)
304 Not Modified (Не изменялось)

401 Unauthorized (Неавторизован)
402 Payment Required (Требуется оплата)
403 Forbidden (Запрещено)
404 Not Found (Не найдено)
405 Method Not Allowed (Метод не поддерживается)
406 Not Acceptable (Не приемлемо)
407 Proxy Authentication Required (Требуется аутентификация прокси)

500 Internal Server Error (Внутренняя ошибка сервера)
502 Bad Gateway (Плохой шлюз)
503 Service Unavailable (Сервис недоступен)
504 Gateway Timeout (Шлюз не отвечает)

Заголовки HTTP

Заголовок HTTP (HTTP Header) — это строка в HTTP-сообщении, содержащая разделённую двоеточием пару вида «параметр-значение». Формат заголовка соответствует общему формату заголовков текстовых сетевых сообщений ARPA (RFC 822). Как правило, браузер и веб-сервер включают в сообщения более чем по одному заголовку. Заголовки должны отправляться раньше тела сообщения и отделяться от него хотя бы одной пустой строкой (CRLF).

Название параметра должно состоять минимум из одного печатного символа (ASCII-коды от 33 до 126). После названия сразу должен следовать символ двоеточия. Значение может содержать любые символы ASCII, кроме перевода строки (CR, код 10) и возврата каретки (LF, код 13).

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

Пример заголовков ответа сервера:

Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 51
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive
200 OK

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

1. General Headers (Основные заголовки) — должны включаться в любое сообщение клиента и сервера.
2. Request Headers (Заголовки запроса) — используются только в запросах клиента.
3. Response Headers (Заголовки ответа) — присутствуют только в ответах сервера.
4. Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения.

Сущности (entity, в переводах также встречается название «объект») — это полезная информация, передаваемая в запросе или ответе. Сущность состоит из метаинформации (заголовки) и непосредственно содержания (тело сообщения).

В отдельный класс заголовки сущности выделены, чтобы не путать их с заголовками запроса или заголовками ответа при передаче множественного содержимого (multipart/*). Заголовки запроса и ответа, как и основные заголовки, описывают всё сообщение в целом и размещаются только в начальном блоке заголовков, в то время как заголовки сущности характеризуют содержимое каждой части в отдельности, располагаясь непосредственно перед её телом.

В таблице 3 приведено краткое описание некоторых HTTP-заголовков.

В листинге 1 приведен фрагмент дампа заголовков при подключении к серверу http://example.org

http://www.example.org/
GET http://www.example.org/ HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
HTTP/1.0 302 Moved Temporarily
Date: Thu, 03 Mar 2011 06:48:28 GMT
Location: http://www.iana.org/domains/example/
Server: BigIP
Content-Length: 0
X-Cache: MISS from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive
----------------------------------------------------------
http://www.iana.org/domains/example/
GET http://www.iana.org/domains/example/ HTTP/1.1
Host: www.iana.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
HTTP/1.0 200 OK
Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 9858
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive
....

Несколько полезных примеров php-скриптов, обрабатывающих HTTP-заголовки, приведены в статье «Использование файла .htaccess» (редирект, отправка кода ошибки, установка last-modified и т.п.).

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

Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи сущности, связанной с запросом или ответом. Тело сообщения (message-body) отличается от тела сущности (entity-body) только в том случае, когда при передаче применяется кодирование, указанное в заголовке Transfer-Encoding. В остальных случаях тело сообщения идентично телу сущности.

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

Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) может быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body).

Все ответы содержат тело сообщения, возможно нулевой длины, кроме ответов на запрос методом HEAD и ответов с кодами статуса 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified).

Контрольные вопросы

1. В каком случае клиент получит от сервера ответ с кодом 418?

CC-BY-SA Анатольев А.Г., 22.08.2012

Протокол передачи гипертекста — HTTP

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

Каждая web-страница, или документ, состоит из объектов. Объект представляет собой обычный файл в формате HTML, изображение в формате JPEG или GIF, Java-апплет, аудиоклип и т. п., то есть единицу, обладающую собственным универсальным указателем ресурса (Uniform Resource Locator, URL). Как правило, web-страницы состоят из базового HTML-файла и объектов, на которые он ссылается. Так, если web-страница включает базовый HTML-файл и пять изображений, то она состоит из шести объектов. Ссылки на объекты, относящиеся к web-странице, представляют собой URL-адреса, включенные в базовый HTML-файл. URL состоит из двух частей: имени хоста сервера, на котором находится объект, и пути к объекту. Так, например, для URL _www.someSchool.edu/someDepartment/picture.gif именем хоста является фрагмент _www.someSchool.edu, а путем к объекту — фрагмент someDepartment/picture.gif.

Браузером называется агент пользователя web; он отображает web-страницы, а также выполняет множество дополнительных служебных функций. Кроме того, браузеры представляют клиентскую сторону протокола HTTP. Таким образом, термины «браузер» и «клиент» в контексте web будут употребляться как эквивалентные. В число наиболее популярных браузеров входят Netscape Navigator и Microsoft Internet Explorer.

Web-сервер содержит объекты, каждый из которых идентифицируется своим URL-адресом. Кроме того, web-серверы представляют серверную сторону протокола HTTP. К наиболее популярными web-серверам следует отнести Apache и Microsoft Internet Information Server.

Протокол HTTP определяет, каким образом клиенты (например, браузеры) запрашивают web-страницы, а серверы осуществляют передачу этих страниц. Более подробный разговор о взаимодействии клиента и сервера мы проведем позднее, однако основную идею можно понять из рис. 2.4. Когда пользователь запрашивает web-страницу (например, совершает щелчок на гиперссылке), браузер посылает серверу HTTP-запрос объектов, составляющих web-страницу. Сервер получает запрос и высылает ответные сообщения, содержащие требуемые объекты. В 1997 году практически все web-браузеры и web-серверы стали поддерживать протокол HTTP версии 1.0, описанный в документе RFC 1945. В 1998 году начался переход к версии 1.1, которая была описана в документе RFC 2616. Версия 1.1 имеет обратную совместимость с версией 1.0, то есть любой сервер или браузер, использующий версию 1.1, может в полной мере взаимодействовать с браузером или сервером, поддерживающим версию 1.0.

Как HTTP 1.0, так и HTTP 1.1 используют TCP в качестве протокола транспортного уровня. HTTP-клиент сначала устанавливает ТСР-соединение с сервером, а после создания соединения клиент и сервер начинают взаимодействовать с протоколом TCP через интерфейс сокетов. Как было сказано ранее, сокеты представляют собой «двери» между процессами и протоколом транспортного уровня.

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

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

HTTPS — защищенный протокол передачи гипертекста

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

HTTPS (HyperText Transfer Protocol Secure) — это не отдельный протокол, а расширение обычного HTTP, работающего через шифрованные транспортные механизмы SSL или TLS. HTTPS обеспечивает защиту от атак, основанных на прослушивании сетевого соединения, то есть от снифферских атак и атак типа man-in-the-middle.

В отличие от HTTP, который по умолчанию использует TCP-порт 80, для HTTPS используется по умолчанию TCP-порт 443. Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен открыть 443 порт, получить и установить в систему SSL-сертификат для этого веб-сервера, а также настроить веб-сервер для обработки соединений по HTTPS.

Что такое SSL-сертификат?

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

Также, для нормальной работы HTTPS, SSL-сертификат должен быть подписан организацией, которой доверяют все. В случае SSL-сертификатов такими организациями являются центры сертификации. И если сертификат подписан надёжным центром сертификации, то считается, что он содержит правильную и соответствующую действительности информацию.

Сертификат состоит из 2 частей (2 ключей) — public и private. Public-часть сертификата используется для зашифрования трафика от клиента к серверу в защищённом соединении, private-часть — для расшифрования полученного от клиента зашифрованного трафика на сервере. В HTTPS для шифрования используются ключи длиной 40, 56, 128 или 256 бит. Реально надёжными являются ключи от 128 бит.

Получение SSL-сертификата и его стоимость

Стоимость сертификатов сильно разнится в зависимости от центра сертификации и от «навороченности» сертификата, наиболее дорогими являются EV-сертификаты (Extended Validation Certificates) — их стоимость может составлять более 1000 евро в год, а процесс их получения требует предоставления достаточно объёмного пакета документов.

Если не нужен EV-сертификат, то стоит обратить внимание на Let’s Encrypt — этот сервис позволяет автоматизировать получение и обновление сертификатов, причём это бесплатно. 

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

Что такое протокол HTTP и как он работает

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

Что же привело к столь широкому распространению этого формата передачи данных?

История HTTP

HyperText Transfer Protocol был создан в CERN в 1991 году Тимом Бернерсоном-Ли, во времена, когда призрак Интернета бродил по земному шарику. Как и многие великие изобретения, он создавался не ради каких-то абстрактных целей, а ради удобства автора и решал конкретную проблему: давал доступ к гигантскому количеству информационных ресурсов лаборатории. Документацию и экспериментальные данные необходимо было не только хранить, но обеспечивать к ним доступ для сотен специалистов и институтов по всему миру. HTTP был придуман с целью упростить доступ к информации и оказался настолько удобен, что в 1993 году была опубликована спецификация HTTP/0.9, доступная каждому. В ней описывался базовый синтаксис протокола, давались определения базовым понятиям и подготавливалась почва для дальнейшего расширения протокола. Также были опубликованы исходные коды браузера (программы для просмотра гипертекста, передаваемого через HTTP) под названием, вы не поверите, WorldWideWeb:

Так мировая сеть сделала свой первый шаг.

Первоначально HTTP использовался исключительно для передачи гипертекста (текста с перекрёстными ссылками) между компьютерами, но позже оказалось, что он прекрасно подходит и для того, чтобы посылать на ПК пользователя бинарные данные — например, изображения или музыку.

В мае 1996 года, всего через три года после первого релиза, была выпущена спецификация HTTP/1.0 (RFC1945), которая расширяла исходную версию протокола, закрепляла коды ответа и вводила новый тип данных для передачи — application/octet-stream, что фактически «легализовало» передачу нетекстовых данных.

В июне 1999 года была опубликована версия протокола 1.1, которая фактически оставалась неизменной на протяжении 16 лет! Более того, она послужила основой для многих других протоколов, в частности WebSocket и WebDav.

И, наконец, 11 февраля 2015 года вышла черновая версия протокола HTTP/2. В отличие от предыдущих двух релизов, он не является переработанным HTTP/0.9, имеет не текстовый, а бинарный формат представления данных, требует обязательного шифрования и имеет множество более мелких отличий от своих предков: сжатие заголовков, использование одного TCP соединения для серии запросов, а также даёт возможность послать серверу дополнительные данные в теле ответа, превентивно отдавая ресурсы в браузер. Более подробно эта версия протокола будет рассмотрена в одной из следующих статей.

Как работает HTTP/1.1

В основе протокола HTTP лежит концепция клиент-серверной архитектуры: клиент, чаще всего браузер, делает запрос на сервер. Существует множество видов запросов, самые распространённые — это GET и POST: первый означает, что клиент хочет получить данные, а второй — что клиент хочет послать данные на сервер. Таким образом, общение между клиентом и сервером сводится к обмену сообщениями, причём всегда по принципу «клиент послал запрос — сервер прислал ответ».

Разберём модельную ситуацию: Петя зовет Колю погулять. Он открывает страничку ВК (или другой социальной сети) и пишет приглашение, после чего нажимает кнопку «Отправить». Что же происходит при этом? Браузер берёт текст приглашения Пети, упаковывает его какой-нибудь промежуточный формат (например, json) и посылает на сервер в виде POST сообщения. Если всё прошло удачно, то сервер ВК в ответ присылает сообщение с кодом 201 («CREATED» — «создано»).

Теперь мысленно обратимся к Коле, который открыл страничку своей любимой социальной сети. При этом браузер послал на сервер GET запрос. Сервер, на который Петя уже послал своё приглашение, видит, что Коля проверяет свои входящие, и отвечает на запрос сообщением, содержащим код 200 (буквально означает «OK»).

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

Внутреннее устройство протокола

Чем же на самом деле обмениваются клиент и сервер между собой?

Как было замечено выше, протокол HTTP до версии 2.0 (и мы будем рассматривать версию 1.1 как самую распространенную до сих пор) имеет текстовую природу. Фактически клиент посылает на сервер специальным образом составленное «письмо»:

——————————————————

GET /im HTTP/1.1

Host: vk.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

Accept: text/html

Connection: close

——————————————————

Давайте разберём его построчно.

Первая строка содержит в себе название метода (GET), URI — универсальный идентификатор ресурса (/im в данном случае), и версию используемого протокола — HTTP/1.1.

После этой обязательной строки, с которой начинается любое HTTP-сообщение, идут несколько пар значений, разделённых двоеточиями. Они называются заголовками (HTTP-headers). Эти значения могут быть самыми разными, но наиболее распространенными являются Host (содержит имя сайта, наличие такого заголовка позволяет хостить несколько сайтов на одном IP адресе) и User-Agent, который по задумке должен обозначать вид используемого браузера, а на практике сложным образом описывает список поддерживаемых браузером технологий. Поле Accept определяет формат данных в ответе, который нужен клиенту, а «Connection: close» означает, что клиент хочет закрыть TCP соединение сразу после получения ответа от сервера.

Если запрос сформирован правильно, и сервер функционирует нормально, и сеть в порядке (как много этих «если»…), то в ответ на HTTP пакет от клиента придёт ответ, который выглядит примерно вот так:

——————————————————

HTTP/1.1 200 OK

Date: Wed, 27 Aug 2017 09:50:20 GMT

Server: Apache

X-Powered-By: PHP/5.2.4-2ubuntu5wm1

Content-Language: ru

Content-Type: text/html; charset=utf-8

Content-Length: 18

Connection: close

Го гулять

——————————————————

Здесь мы наблюдаем отсутствие названия метода в первой строке, и ряд новых заголовков, из которых я рекомендую обратить внимание на поле «Content-Length: 18». Это число обозначает длину данных в байтах, которые передаются после пустой строки в конце пакета (так как в заголовке Content-Type указана кодировка utf-8, то каждая буква кириллицы в сообщении занимает два байта). Таким образом мы рассмотрели простой пример работы протокола HTTP.

HTTP позволяет миллиардам людей получать доступ новостям, письмам друзей, спорам о самолёте на конвейерной ленте, смешным фотографиям котиков и данным о недавно открытом в БАКе гамма-резонансе (есть что-то трогательное в том, что HTTP по-прежнему приносит пользу на своей малой родине, ЦЕРНе). Мало какие изобретения обладают столь мощным влиянием на человечество в том объёме, как этот простенький протокол передачи структурированного текста. И, разумеется, такой протокол не мог остаться без расширений, и самым популярным из них стал HTTPS — о нем и поговорим в следующей статье.

HTTP | MDN

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

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

Обзор HTTP

Основные возможности протокола клиент-сервер: что он может делать и его предполагаемое использование.

HTTP-кэш

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

HTTP-файлы cookie

Как работают файлы cookie, определено RFC 6265. При обслуживании HTTP-запроса сервер может отправить HTTP-заголовок Set-Cookie с ответом.Затем клиент возвращает значение cookie с каждым запросом к тому же серверу в форме заголовка запроса Cookie . Срок действия файла cookie также может быть установлен на определенную дату или ограничен определенным доменом и путем.

Совместное использование ресурсов между источниками (CORS)

Межсайтовые HTTP-запросы — это HTTP-запросы ресурсов из другого домена , отличного от домена ресурса, выполняющего запрос. Например, HTML-страница из домена A ( http: // domaina.example / ) делает запрос изображения в Домене B ( http://domainb.foo/image.jpg ) через элемент img . Сегодня веб-страницы очень часто загружают межсайтовые ресурсы, включая таблицы стилей CSS, изображения, сценарии и другие ресурсы. CORS позволяет веб-разработчикам контролировать реакцию своего сайта на межсайтовые запросы.

Развитие HTTP

Краткое описание изменений между ранними версиями HTTP, современными HTTP / 2, возникающими HTTP / 3 и последующими.

Руководство по веб-безопасности Mozilla

Сборник советов, которые помогут оперативным группам создавать безопасные веб-приложения.

HTTP-сообщения

Описывает тип и структуру различных типов сообщений HTTP / 1.x и HTTP / 2.

Типичный сеанс HTTP

Показывает и объясняет ход обычного сеанса HTTP.

Управление подключением в HTTP / 1.x

Описывает три модели управления подключением, доступные в HTTP / 1.x, их сильные и слабые стороны.

Просмотрите подробную справочную документацию HTTP.

Заголовки HTTP

Заголовки сообщений HTTP

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

Методы HTTP-запроса

Различные операции, которые можно выполнять с помощью HTTP: GET , POST , а также менее распространенные запросы, такие как OPTIONS , DELETE или TRACE .

Коды ответа HTTP-статуса

Коды ответа

HTTP указывают, был ли успешно выполнен конкретный запрос HTTP. Ответы сгруппированы по пяти классам: информационные ответы, успешные ответы, перенаправления, ошибки клиента и ошибки серверов.

Директивы CSP

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

Полезные инструменты и ресурсы для понимания и отладки HTTP.

Инструменты разработчика Firefox

Сетевой монитор

Обсерватория Мозилла

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

RedBot

Инструменты для проверки заголовков, связанных с кешем

Как работают браузеры

Очень подробная статья о внутреннем устройстве браузера и потоке запросов по протоколу HTTP.ОБЯЗАТЕЛЬНО ПРОЧИТАЙТЕ любой веб-разработчик.

Протокол передачи гипертекста — HTTP / 1.1

Протокол передачи гипертекста — HTTP / 1.1

Этот документ был заменен. В 2014 году RFC2616 был заменен несколькими RFC (7230-7237). См. Документы IETF для получения дополнительной информации.

Сетевая рабочая группа Р. Филдинг
Запрос комментариев: 2616 UC Irvine
Устаревшие: 2068 J.Gettys
Категория: Стандарты Отслеживание Compaq / W3C
                                                              J. Mogul
                                                                Compaq
                                                            Г. Фрыстык
                                                               W3C / MIT
                                                           Л. Масинтер
                                                                 Ксерокс
                                                              П.Выщелачивание
                                                             Microsoft
                                                        Т. Бернерс-Ли
                                                               W3C / MIT
                                                             Июнь 1999 г.
 

Статус этого меморандума

Этот документ определяет протокол отслеживания стандартов Интернета для
Интернет-сообщество и просит обсуждения и предложения по
улучшения.См. Текущую редакцию «Интернет
Официальные стандарты протокола »(STD 1) для государства стандартизации
и статус этого протокола. Распространение этой памятки не ограничено.

Уведомление об авторских правах

Авторское право (C) The Internet Society (1999). Все права защищены.

Абстрактный

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

HTTP используется глобальной информацией во всемирной паутине.
Инициатива с 1990 года.Эта спецификация определяет протокол
называется «HTTP / 1.1» и является обновлением RFC 2068 [33].

HTTP — Обзор протокола передачи гипертекста

HTTP — Обзор протокола передачи гипертекста

Новости | HTTP
Деятельность | Технические характеристики | Программного обеспечения
| Переговоры | Списки рассылки | IETF | HTTP-расширения |
WebMux | HTTP-NG | Веб-характеристика | Справочная информация

Теперь, когда и расширения HTTP, и HTTP / 1.1 — стабильные спецификации (на тот момент RFC2616), W3C
закрыл HTTP-действие.

Попытка пересмотреть HTTP / 1.1 началась в 2006 году, что привело к созданию IETF httpbis.
Рабочая группа. Работа завершена публикацией RFC 723X (см. Ниже)

Рядом находится

Связанные протоколы

См. Также временную шкалу HTTP для более старых событий

Рабочая группа HTTP

Связанные протоколы

Структура расширения HTTP

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

Протокол мультиплексирования (MUX)

Проект предложения по внедрению поддержки асинхронного обмена сообщениями на
уровень ниже HTTP

Обработка
идентификаторы фрагментов в перенаправленных URL

Интернет-черновик с предложением по проблеме, которую оставляет HTTP
неопределенные.

HTTP-NG — Протокол передачи гипертекста — Далее
Поколение

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

Фон

W3C предлагает сервер Jigsaw, написанный на Java и
клиентский API libwww — оба выпущены с полной
набор функций HTTP / 1.1, включая кеширование и постоянные соединения.
См. Вклады W3C с открытым исходным кодом для
подробнее.

Предварительная производительность HTTP / 1.1
Оценка Джима Геттиса

Производительность HTTP / 1.1
документ подробно объясняет эксперименты и недавно был
отправлено для публикации. Эта работа показывает, как можно получить столько же
коэффициент 10 в количестве пакетов и в 2 раза в скорости за счет использования
Конвейерная обработка HTTP / 1.1. Первые результаты были представлены на встрече IETF в Сан-Хосе,
Декабрь 1996 г., и более полные результаты на заседании Консультативного комитета W3C.
в Англии в январе.

Обзор новых функций HTTP / 1.1 и
изменения по сравнению с HTTP / 1.0 Джимом Геттисом

Эта презентация дает хороший обзор новых функций. Это будет
обновляется время от времени по мере представления. Презентация также
доступно для Microsoft
PowerPoint

PEP — механизм расширения для HTTP
Авторы: Хенрик Фристик Нильсен и Рохит Кхаре

Эта презентация была представлена ​​на встрече IETF в
Монреаль, июнь 1996 года.

Есть несколько списков рассылки, которые вы можете использовать.Поскольку некоторые из
у них очень большой объем, тогда, пожалуйста, сначала проверьте архивы, чтобы узнать,
тема, которую вы хотите поднять, на самом деле уже обсуждалась. Как мы
попытаться добиться как можно большего прогресса в HTTP, очень важно, чтобы мы
может оставаться сосредоточенным — даже на открытых списках рассылки!

[email protected] (Архивировано в W3C (см. Также
с 1994 по
Архив 2002 г.).

Официальный список рассылки рабочей группы IETF HTTP.

w3c-http @ w3.org (Архив)

Это список рассылки W3C, посвященный продвижению HTTP / 1.1.
реализации, чтобы получить достаточный опыт среди членов W3C для
поддержать спецификацию и упростить

разработка программного обеспечения и приложений HTTP / 1.1. Список только
доступен для членов W3C.

[email protected] (Архив)

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

[email protected] (информация)

Этот список больше не поддерживается и больше не активен.
Не отправляйте письма на этот адрес!

См. Также информацию о HTTP-NG

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

Рабочие группы, связанные с HTTP

Это рабочие группы IETF
работает над проблемами, напрямую связанными с HTTP:

Пол Хоффман в Интернет-почте
Консорциум ведет отличный список рабочих групп IETF, напрямую связанных
в интернет-почту.В следующем списке представлены рабочие группы более удаленных
природа относительно HTTP.

Вы также можете проверить полный список работающих IETF
группы.

Встречи IETF

Также посетите страницу собрания IETF для
самая свежая информация. Мы сохраняем небольшой список заметок из предыдущей HTTP wg.
встреч на различных встречах IETF:

Лос-Анджелес , Калифорния, США, март-апрель 1998 г.

Где, как добраться,
повестка дня и т. д.

Вашингтон, округ Колумбия, США, декабрь 1997 г.

HTTP-WG
заметки с встречи и полный он-лайн
Поступления

Мюнхен, Германия, 11-15 августа 1997 г.

HTTP-WG
заметки с собрания и полное
on-line Proceedings

Мемфис, Теннесси, 7-11 апреля 1997 г.

HTTP-WG
заметки с встречи и полный он-лайн
Труды

Сан-Хосе, Калифорния, 9-13 декабря 1996 г.

HTTP-WG
заметки с собрания и полное
он-лайн слушания.

Монреаль, Квебек КАНАДА, 24-28 июня 1996 г.

HTTP-WG примечания от
встреча

Другие организации, связанные с IETF

Неупорядоченный список организаций, связанных с IETF:

• Интернет-инженерия
  Руководящая группа (IESG), состоящая из директоров IETF Area
  вместе с председателем IETF.
• The Internet Research Task Force
  (IRTF) состоит из целого ряда целенаправленных долгосрочных небольших исследований.
  Группы.Эти группы работают над темами, связанными с интернет-протоколами,
  приложения, архитектура и технологии.
• Совет по архитектуре Интернета
  (IAB) — это орган Internet Society, отвечающий за общие
  архитектурные соображения в Интернете.
• Internet Society (ISOC) — это
  неправительственная Международная организация глобального сотрудничества и
  координация Интернета и его технологий межсетевого взаимодействия и
  Приложения.
• Интернет-присвоенные номера
  Полномочия (IANA) являются центральным координатором по назначению
  уникальные значения параметров для интернет-протоколов

Авторские права © 1996-2003 гг.
W3C ^® (MIT, ERCIM,
Кейо), все права защищены. Ответственность W3C, товарный знак, использование документов
и программное обеспечение
применяются правила лицензирования. Ваше взаимодействие с этим сайтом соответствует
с нашей общественностью и
Конфиденциальность участников
заявления.

Что такое HTTP? Протокол передачи данных через Интернет

Протокол передачи гипертекста (HTTP) — это метод кодирования и передачи информации между клиентом (например, веб-браузером) и веб-сервером.HTTP — это основной протокол для передачи информации через Интернет.

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

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

HTTP — это протокол прикладного уровня, работающий на основе протокола сетевого уровня, такого как протокол управления передачей (TCP).

Ресурсы

HTTP, такие как веб-серверы, идентифицируются в Интернете с помощью уникальных идентификаторов, известных как унифицированные указатели ресурсов , (URL-адреса).

Как может помочь NGINX Plus?

NGINX Plus и NGINX — лучшие в своем классе решения для балансировки нагрузки, используемые веб-сайтами с высокой посещаемостью, такими как Dropbox, Netflix и Zynga.Более 400 миллионов веб-сайтов по всему миру полагаются на NGINX Plus и NGINX Open Source для быстрой, надежной и безопасной доставки своего контента.

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

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

Что такое протокол передачи гипертекста (HTTP)?

Что означает протокол передачи гипертекста (HTTP)?

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

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

Techopedia объясняет протокол передачи гипертекста (HTTP)

Будучи протоколом без сохранения состояния, HTTP по своей сути не сохраняет пользовательские настройки, поэтому такие элементы, как файлы cookie, используются, чтобы помочь веб-сайтам и серверам «запомнить», что сделал пользователь.

Использование доступных для пользователя инструментов означает, что пользователи могут удалить файлы cookie и другие инструменты и начать заново как анонимные пользователи или сохранить эти маркеры, чтобы они могли снова обойти все это «знакомство» с сайтом хостинг-сервера.

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

Ранний HTTP

Давайте поговорим о некоторых важных частях HTTP-заголовка. Заголовки HTTP-запроса и ответа определяют рабочие параметры HTTP-транзакций.

Структура запроса обычно содержит URL-адрес с методом и определяет протокол.

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

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

Универсализация этого в контексте синтаксиса гипертекста имеет смысл и является частью подхода таких групп, как World Wide Web Consortium или W3C, к созданию Интернета в том виде, в каком он существует сегодня.

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

Со временем появился новый протокол HTTPS, который шифрует содержимое HTTP-сообщений с помощью протоколов Transport Layer Security и Secure Dockets Layer или TLS / SSL.

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

Поскольку протокол HTTPS шифрует фактический синтаксис HTTP, он эффективен для защиты от такого рода действий.

Отслеживание и интерактивность

По мере усложнения Интернета развивается и HTTP. Способы взаимодействия веб-пользователей и сайтов претерпели довольно значительные изменения за последние пару десятилетий.

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

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

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

Протокол передачи гипертекста (HTTP) — Глоссарий

Протокол передачи гипертекста (HTTP) — Глоссарий | CSRC

Вы просматриваете эту страницу в неавторизованном окне фрейма.

Это потенциальная проблема безопасности, вас перенаправляют на https://csrc.nist.gov.

Использование официальных сайтов.gov

Веб-сайт .gov принадлежит официальной правительственной организации США.

Безопасные веб-сайты .gov используют HTTPS

Блокировка () или https: // означает, что вы безопасно подключились к.gov веб-сайт. Делитесь конфиденциальной информацией только на официальных безопасных веб-сайтах.

Поиск

Сортировать по

Соответствие (наилучшее соответствие) Срок (A-Z) Срок (Z-A)

Пункты на странице
100200500Все

Исправьте следующее:

Поиск
Перезагрузить

Глоссарий

А
|
B
|
C
|
D
|
E
|
F
|
г
|
ЧАС
|
я
|
J
|
K
|
L
|
M
|
N
|
О
|
п
|
Q
|
р
|
S
|
Т
|
U
|
V
|
W
|
Икс
|
Y
|
Z

Протокол передачи гипертекста (HTTP)

Аббревиатуры и синонимы:

http

показать источники
скрыть источники

HTTP

показать источники
скрыть источники

определение:

Как работает HTTP: объяснение протокола передачи гипертекста

Протокол передачи гипертекста предоставляет стандарт сетевого протокола, который веб-браузеры и серверы используют для связи.Вы видите HTTP при посещении веб-сайта, потому что протокол отображается в URL-адресе (например, http://www.lifewire.com).

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

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

История HTTP

Тим Бернерс-Ли создал первоначальный стандарт HTTP в начале 1990-х годов в рамках своей работы по определению оригинальной Всемирной паутины. В 1990-х годах были развернуты три основные версии:

• HTTP 0.9 : Поддержка базовых гипертекстовых документов.
• HTTP 1.0 : Расширения для поддержки полнофункциональных веб-сайтов.
• HTTP 1.1 : Разработано для устранения ограничений производительности HTTP 1.0, указанных в Internet RFC 2068.

Последняя версия, HTTP 2.0, стала утвержденным стандартом в 2015 году. Она поддерживает обратную совместимость с HTTP 1.1, но предлагает дополнительные улучшения производительности.

В то время как стандартный HTTP не шифрует трафик, отправляемый по сети, стандарт HTTPS добавляет шифрование к HTTP с помощью Secure Sockets Layer или, позже, Transport Layer Security.

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

HTTP — это протокол прикладного уровня, построенный на основе TCP, который использует модель связи клиент-сервер.HTTP-клиенты и серверы общаются посредством сообщений запроса и ответа. Три основных типа сообщений HTTP — это GET, POST и HEAD.

• HTTP GET : сообщения, отправленные на сервер, содержат только URL-адрес. В конец URL-адреса можно добавить ноль или несколько дополнительных параметров данных. Сервер обрабатывает необязательную часть данных URL-адреса, если она есть, и возвращает результат (веб-страницу или элемент веб-страницы) в браузер.
• HTTP POST : Сообщения помещают любые необязательные параметры данных в тело сообщения запроса, а не добавляют их в конец URL-адреса.
• HTTP HEAD : запросы работают так же, как запросы GET. Вместо ответа с полным содержимым URL-адреса сервер отправляет обратно только информацию заголовка (содержащуюся в разделе HTML).

Браузер инициирует связь с HTTP-сервером, инициируя TCP-соединение с сервером. Сеансы просмотра веб-страниц по умолчанию используют порт сервера 80, хотя иногда вместо него используются другие порты, такие как 8080.

После того, как сеанс установлен, вы инициируете отправку и получение HTTP-сообщений, посещая веб-страницу.

HTTP — это то, что называется системой без сохранения состояния . Это означает, что, в отличие от других протоколов передачи файлов, таких как FTP, HTTP-соединение разрывается после завершения запроса. Итак, после того, как ваш веб-браузер отправит запрос, а сервер ответит страницей, соединение закрывается.

Устранение неполадок HTTP

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

• Ошибка пользователя.
• Неисправность веб-браузера или веб-сервера.
• Ошибки при создании веб-страниц.
• Временные сбои в сети.

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

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

Спасибо, что сообщили нам!

Расскажите, почему!

Другой

Недостаточно подробностей

Сложно понять

.