Протокол передачи гипертекстовых данных. Протокол 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

Метод 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-таге:

// метод GET с кодировкой по умолчанию // enctype явно задает кодировку // метод POST с кодировкой по умолчанию (urlencoded, как и предыдущая форма)

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

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

В этом случае при отправке данных на сервер ничего не кодируется. А сервер, со своей стороны, посмотрев на "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
.

В эпоху повсеместного использования интернета, особую распространенность получили вирусы, которые устанавливаются в браузер. На нашем ресурсе можно найти несколько статей о таких вредоносных программах, но особо в их ряду выделяется Time to Read. Данный вирус может проникнуть на компьютер невнимательного пользователя и сильно испортить удовольствие от работы с браузером. Пользователь будет видеть рекламу, его начнет постоянно переносить на сайт Time to Read, и возникнут многие другие проблемы, впрочем, обо всем по порядку.

Как и большинство троянских вирусов, Time to Read выполняет простую задачу – показать пользователю максимальное количество рекламы, чтобы создатели программы получили деньги за ее трансляцию, клики по ней и переводы на сайты-партеры. Чаще всего услугами продвижения своих сайтов при помощи вирусов пользуются мошеннические ресурсы или страницы, которые заражены чем-то более серьезным, чем рекламный троян.

Вирус Time to Read после попадания на компьютер проявляет себя следующими «симптомами»:

  • На сайтах постоянно всплывает дополнительная реклама, в том числе и pop-up баннеры, которые полностью загораживают контент до клика по ним;
  • Настройки безопасности компьютера подвергаются изменениям, что опасно для компьютера, который имеет постоянное подключение к интернету;
  • Стартовая страница всех браузеров автоматически меняется на сайт Time to Read, который стремится позиционировать себя в качестве поиска и новостного ресурса;
  • Автоматическая переадресация на сторонние ресурсы. Важно: с неизвестного сайта, на который пользователь может быть переадресован вирусом Time to Read, велик риск загрузки на компьютер других вирусов.

Если вы заметили на компьютере обозначенные выше симптомы, значит, ваш компьютер заражен вирусом Time to Read. Необходимо его срочно удалить, чтобы избежать более серьезных проблем, к которым он может привести.

Чтобы убрать вирус Time to Read с компьютера, потребуется предварительно загрузить и установить две программы: AdwCleaner и CCleaner. Данные приложения помогут в автоматическом режиме справиться с вирусом, и пользователю останется выполнить лишь самые простые задачи в «ручном» режиме.

Процесс удаления вируса Time to Read с компьютера проходит следующим образом:

  1. Первым делом необходимо удалить с компьютера все временные файлы, чтобы вирусная программа не могла восстановиться после удаления. Для этого перейдите в соответствующие разделы:
На Windows 7: {Системный диск}:\Users\Имя пользователя\AppData\Local\Temp На Windows 10: {Системный диск}:\Users\Администратор\AppData\Local\Temp

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


Обратите внимание, что выполнять сброс КЭШа распознавателя необходимо с профиля администратора.


Как установить и правильно настроить CCleaner:


На этом удаление вируса Time to Read с компьютера можно считать завершенным. Рекомендуем до начала работы с браузером перезагрузить компьютер.

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

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

Соблюдая простые правила, описанные выше, можно существенно снизить риск заражения компьютера вирусом Time to Read, который способен доставить массу хлопот.

Протокол HTTP или HyperText Transfer Protocol это главный прокол (всемирной паутины). Основная задача протокола, обеспечить передачу гипертекста в сети. В протоколе точно описывается формат сообщений, для обмена клиентов и серверов.

Описан протокол HTTP в RFC 2616(HTTP1.1).

Основа протокола обеспечить взаимодействие клиента и сервера по средством одного ASCII-запроса, и следующего на него ответа в стандарте RFC 822 MIME.

На практике протокол HTTP работает на основе порт 80, но можно настроить и по-другому. И хоть TCP/IP не является обязательным, он остается предпочтительным, так как берет на себя разбиение и сборку сообщений на себя и не «напрягает» ни браузер, ни сервер.

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

URL

Основой веб-общения клиент-сервер является запрос. Запрос отправляется при помощи URL– единого указателя ресурсов Интернет. Напомню, что такое URL адрес.

Понятная и простая структура URL состоит из следующих элементов:

  • Протокол;
  • Хост;
  • Порт;
  • Каталок ресурса;
  • Метки (Запрос).

Примечание: Протокол http это протокол для простых, не защищенных соединений. Защищенные соединения работают по протоколу https. Он более безопасен для обмена данными.

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

Один из параметров URL, определяет название хоста, с которым мы хотим общаться. Но этого мало. Нужно определить действие, которое нужно совершить. Сделать это можно при помощи метода определенного протоколом HTTP.

Методы HTTP

  • Метод/Описание
  • HEAD/Прочитать заголовок веб-страницы
  • GET/Прочитать веб-страницу
  • POST/Добавить к веб-странице
  • PUT/Сохранить веб-страницу
  • TRACE/Отослать назад запрос
  • DELETE/Удалить веб-страницу
  • OPTIONS/Отобразить параметры
  • CONNECT/Зарезервировано для будущего использования

Разберем методы HTTP подробнее

Метод GET. запрашивает страницу (файл, объект), закодированную по стандарту MIME. Это самый употребляемый метод. Структура метода:
GET имя_файла HTTP/1.1

Метод HEAD. Этот метод запрашивает заголовок сообщения. При этом страница не загружается. Этот метод позволяет узнать время последнего обновления страницы, что нужно для управления КЭШем страниц. Этот метод позволяет проверить работоспособность запрашиваемого URL.

Метод PUT. Этот метод может поместить страницу на сервер. Тело запроса PUT включает размещаемую страницу, которая закодирована по MIME. Это метод требует идентификации клиента.

Метод POST. Этот метод добавляет содержимое к уже имеющейся странице. Используется, как пример, для добавления записи на форум.

Метод DELETE. Этот метод уничтожает страницу. Метод удаления требует подтверждения прав пользователя на удаление.

Метод TRACE. Этот метод отладки. Он указывает серверу отослать запрос назад и позволяет узнать, искажается или нет, запрос клиента, вернувшись от сервера.

Метод CONNECT – метод резерва, не используется.

Метод OPTIONS позволяет запросить свойства сервера и свойства любого файла.

В общении клиента и сервера «запрос-ответ», сервер обязательно генерирует ответ. Это может быть веб-страница или строку состояния с кодом состояния. Код состояния вам хорошо известен. Один из кодов известный код 404 –Страница не найдена.

Группы кодов состояния

1хх: Готовность сервера, Код 100 – сервер готов обрабатывать запросы клиента;

2хх: Успех.

  • Код 200 – запрос обработан успешно;
  • Код 204 – Содержимого нет.

3хх: Перенаправление.

  • Код 301 – Запрашиваемая страница перенесена;
  • Код 304 – Страница в КЭШе еще актуальна.

4хх: Ошибка клиента.

Стандартный протокол для передачи данных по Всемирной паутине -- это HTTP (HyperText Transfer Protocol -- протокол передачи гипертекста). Он описывает сообщения, которыми могут обмениваться клиенты и серверы. Каждое взаимодействие состоит из одного ASCII-запроса, на который следует один ответ, напоминающий ответ стандарта RFC 822 MIME. Все клиенты и все серверы должны следовать этому протоколу. Он определен в RFC 2616.

Соединения

Обычный способ взаимодействия браузера с сервером заключается в установке ТСР-соединения с портом 80 сервера, хотя формально эта процедура не является обязательной. Ценность использования TCP -- в том, что ни браузерам, ни серверам не приходится беспокоиться о потерянных, дублированных, слишком длинных сообщения и подтверждениях. Все это обеспечивается протоколом TCP.

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

Это соображение привело к созданию протокола HTTP 1.1, который поддерживал устойчивые соединения. Это означало, что появилась возможность установки TCP-соединения, отправки запроса, получения ответа, а затем передачи и приема дополнительных запросов и ответов. Таким образом, снизились накладные расходы, возникавшие при постоянных установках и разрывах соединения. Стало возможным также конвейеризировать запросы, то есть отправлять запрос 2 еще до прибытия ответа на запрос 1.

Несмотря на то что HTTP был разработан специально для использования в веб - технологиях, он был намеренно сделан более универсальным, чем это было необходимо, так как рассчитывался на будущее применение в объектно-ориентированных приложениях. По этой причине в дополнение к обычным запросам веб-страниц были разработаны специальные операции, называемые методами. Они обязаны своим существованием технологии SOAP. Каждый запрос состоит из одной или нескольких строк ASCII, причем первое слово является именем вызываемого метода. Встроенные методы перечислены в таблице на рис.6. Помимо этих общих методов, у различных объектов могут быть также свои специфические методы. Имена методов чувствительны к регистру символов, то есть метод GET существует, a get -- нет.

Рисунок 6 - Встроенные методы HTTP-запросов

Метод GET запрашивает у сервера страницу (под которой в общем случае подразумевается объект, но на практике это обычно просто файл), закодированную согласно стандарту MIME. Большую часть запросов к серверу составляют именно запросы GET.

Метод HEAD просто запрашивает заголовок сообщения, без самой страницы. С помощью этого метода можно узнать время последнего изменения страницы для сбора индексной информации или просто для проверки работоспособности данного URL.

Метод PUT является противоположностью метода GET: он не читает, а записывает страницу. Этот метод позволяет создать набор веб-страниц на удаленном сервере. Тело запроса содержит страницу. Она может быть кодирована с помощью MIME. В этом случае строки, следующие за командой PUT, могут включать различные заголовки, например, Content-Type или заголовки аутентификации, подтверждающие права абонента на запрашиваемую операцию.

Метод POST несколько напоминает метод PUT. Он также содержит URL, но вместо замены имеющихся данных новые данные «добавляются» (в неком общем смысле) к уже существующим. Это может быть публикация сообщения в конференции или добавление файла к электронной доске объявлений BBS. На практике ни PUT, ни POST широко не применяются.

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

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

Метод CONNECT в настоящее время не используется. Он зарезервирован для будущего применения.

Метод OPTIONS позволяет клиенту узнать у сервера о его свойствах или о свойствах какого-либо конкретного файла.

В ответ на каждый запрос от сервера поступает ответ, содержащий строку состояния, а также, возможно, дополнительную информацию (например, веб-страницу или ее часть). Строка состояния может содержать трехразрядный код состояния, сообщающий об успешном выполнении запроса или о причинах неудачи. Первый разряд предназначен для разделения всех ответов на пять основных групп, как показано в таблице на рис.7. Коды, начинающиеся с 1 Aхх), на практике используются редко. Коды, начинающиеся с 2, означают, что запрос был обработан успешно и данные (если их запрашивали) отосланы. Коды Зхх сообщают клиенту о том, что нужно попытать счастья в другом месте -- используя либо другой URL, либо свой собственный кэш.

Рисунок 7 - Группы кодов состояния, содержащиеся в ответах сервера

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

Пример использования HTTP

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

Рисунок 8 - последовательность команд HTTP-протокола

Эта последовательность команд устанавливает telnet-соединение (то есть ТСР- соединение) с портом 80 веб-сервера IETF, расположенного по адресу www.ietf.org.

Результат сеанса связи записывается в файл log, который затем можно просмотреть. Далее следует команда GET. Указывается имя запрашиваемого файла и протокол передачи. Следом идет обязательная строка с заголовком Host. Пустая строка, которая находится за ней, также обязательна. Она сигнализирует серверу о том, что заголовки запросов закончились. Командой close (это команда программы telnet) соединение разрывается.

Файл журнала соединения, log, может быть просмотрен с помощью любого текстового редактора. Он должен начинаться примерно так, как показано в листинг на рис.8, если только на сайте IETF за это время не произошли какие-нибудь изменения.

Рисунок 9 - Начало вывода файла «www.ietf.org/rfc.html»

Первые три строки в этом листинге созданы программой telnet, а не удаленным сайтом. А вот строка, начинающаяся с HTTP/1.1, -- это уже ответ IETF, говорящий о том, что сервер желает общаться с вами при помощи протокола НТТР/1.1. Далее следует ряд заголовков и, наконец, само содержимое запрашиваемого файла. Заголовок ETag, который является уникальным идентификатором страницы, связанным с кэшированием, и X-Pad -- нестандартного заголовка, помогающего бороться с ошибками браузеров.



Есть вопросы?

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: