Наш чат в Telegram для обмена идеями, проектами, мыслями, людьми в сфере ИТ г.Ростова-на-Дону: @it_rostov

HTTP - HyperText Transfer Protocol

Все данные в рамках Web-технологии передаются по протоколу HTTP (HyperText Transfer Protocol). Исключение составляет обмен с использованием программирования на Java или обмен из Plugin-преложений. Учитывая реальный объем трафика, который передается в рамках Web-обмена по HTTP, мы будем рассматривать только этот протокол. При этом мы рассмотрим такие вопрсы, как:


Общая структура сообщений

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

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

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

Ниже приведен HTTP-запрос:

GET / HTTP/1.0
Accept: image/jpeg
[пустая строка]

и отклик:

HTTP/1.0 200 OK
Date: Fri, 24 Jul 1998 21:30:51 GMT
Server: Apache/1.2.5
Content-type: text/html
Content-length: 21345
[пустая строка]
контекст страницы

Текст "пустая строка" - это просто обозначение наличия пустой строки, которая отделяет заголовок HTTP-сообщения от его тела.

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


Методы доступа

Самой главной директивой HTTP-запроса является метод доступа. Он указывается первым словом в первой строке запроса. В нашем примере это GET. Различают четыре основных метода доступа:

  • GET
  • HEAD
  • POST
  • PUT

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

Метод GET

Метод GET используется клиентом при запросе к серверу по умолчанию. При этом методе клиент сообщает адрес ресурса(URL), который он хочет получить, версию протокола HTTP, MIME-типы документов, которые он поддерживает, версию и название клиентского программного обеспечения. Все эти параметры указываются в заголовке HTTP-запроса. Тело в запросе не передается.

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

Метод HEAD

Метод HEAD используется для минимизации обменов при работе по протоколу HTTP. Он аналогичен методу GET за исключением того, что в отклике не передается тела сообщения. Данный метод используется для проверки времени последней модификации ресурса, для проверки срока годности кэшированных ресурсов, при использовании программ сканирования ресурсов World Wide Web. Одним словом, метод HEAD предназначен для минимизации объема передаваемой по сети информации в рамках HTTP-обмена.

Метод POST

Метод POST - это альтернатива методу GET. При обмене данными по методу POST в запросе клиента присутствует тело HTTP-сообщения. Это тело может формироваться из данных, которые вводятся в HTML-форме, или из присоединенного внешнего файла. В отклике как правило присутствует и заголовок и тело HTTP-сообщения. Для инициирования обмена по методу POST в атрибуте method контейнера form следует указать значение "post".

Метод PUT

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

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


Оптимизация обмена

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

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

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

Для оптимизации числа открытых TCP-соединений в HTTP-протоколе версий 1.0 и 1.1 предусмотрен режим keep-alive. В этом режиме соединение инициализируется только один раз и по нему последовательно можно реализовать несколько HTTP-обменов.

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


Кодировка GET и POST-запросов

Существуют два вида кодирования HTTP-запроса. Основной - urlencoded, он же - стандартное кодирование URL. Пробел представляется как %20, русские буквы и большинство спецсимволов кодируются, английские буквы и дефис оставляются как есть.

Способ, которым следует кодировать данные формы при submit'е, задается в ее HTML-таге:

<form method="get"> // метод GET с кодировкой по умолчанию
<form method="post" enctype="application/x-www-form-urlencoded"> // enctype явно задает кодировку
<form method="post"> // метод POST с кодировкой по умолчанию (urlencoded, как и предыдущая форма)

Если форма отправляеться обычным образом, то браузер сам кодирует (urlencode) название и значение каждого поля данных (input и т.п.) и отсылает форму на сервер в закодированном виде.

Второй способ кодирования - это отсутствие кодирования. Например, кодировать не нужно для пересылки файлов. Он указывается в форме (только для POST) так:

<form method="post" enctype="multipart/form-data">

В этом случае при отправке данных на сервер ничего не кодируется. А сервер, со своей стороны, посмотрев на "Content-Type: multipart/form-data", поймет, что пришло.


Кодировка данных

Если Вы используете только UTF-8 - этот раздел вам не нужен.

Все идущие на сервер параметры GET/POST, кроме случая multipart/form-data, кодируются в UTF-8. Не в кодировке страницы, а именно в UTF-8. Поэтому, например, в PHP их нужно при необходимости перекодировать функцией iconv.

$name = iconv('UTF8','CP1251',$_GET['name']);

Ответ с сервера браузер воспринимает именно в той кодировке, которая указана в заголовке ответа Content-Type. Т.е, опять же, в PHP, чтобы браузер воспринял ответ в windows-1251 и нормально отобразил данные на странице в windows-1251, нужно послать заголовок с кодировкой в php-коде, например так:

header('Content-Type: text/plain; charset=windows-1251');

Или же, такой заголовок должен добавить сервер. Например, в apache автоматически добавляется кодировка опцией:

# в конфиге апача
AddDefaultCharset windows-1251

.