Протокол http что это
Протокол HTTP: обзор для чайников
Каждый раз, когда вы посещаете страницу в интернете, ваш компьютер использует протокол передачи гипертекста (HTTP) для загрузки этой страницы. HTTP — это набор правил для передачи файлов: текста, изображений, звука, видео и других мультимедиа. HTTP работает поверх набора протоколов TCP/IP, которые составляют основу интернета.
Составляющие HTTP
В HTTP-протоколе есть две разные роли: сервер и клиент. Запрос всегда инициирует клиент, а сервер на него отвечает. Клиентом может быть как браузер, так и, к примеру, поисковый робот, который просматривает страницы в интернете и индексирует их согласно релевантности ключевого запроса. HTTP основан на тексте — сообщения между клиентом и сервером по сути представляют собой фрагменты текста, хотя в теле сообщения могут быть другие элементы: видео, фото, аудио и т.д.
Каждый отдельный запрос отправляется на сервер, который обрабатывает его и предоставляет ответ. Между клиентом и сервером существует множество объектов, которые называются прокси-серверами. Они обеспечивают различные уровни функциональности, безопасности и конфиденциальности в зависимости от ваших потребностей или политики компании.
Схематичное изображение работы HTTP-протокола
Итак, мы выяснили, что HTTP содержит три основных элемента:
Рассмотрим подробнее, что это такое и как они работают.
Клиент
Клиент — это любой инструмент, который действует от имени пользователя. В основном эту роль выполняет веб-браузер, но помимо браузера это быть программы, используемые инженерами или веб-разработчиками для отладки своих приложений. Клиент всегда инициирует запрос, это никогда не делает сервер.
Веб-сервер
На другой стороне канала связи находится сервер, который обслуживает документ по запросу клиента. Хотя для пользователя сервер выглядит как одна виртуальная машина, на самом деле это может быть набор серверов, разделяющих нагрузку. С другой стороны, несколько серверов могут быть расположены на одной и той же машине. При HTTP/1.1 и заголовке Host они могут даже использовать один и тот же IP-адрес.
Прокси
Прокси-серверы — это серверы, компьютеры или другие машины уровня приложений, которые находятся между клиентским устройством и непосредственно сервером. Они ретранслируют HTTP-запросы и ответы. Обычно для каждого взаимодействия клиент-сервер используется один или несколько прокси.
Веб-разработчики могут использовать прокси для следующих целей:
Как работает HTTP-протокол
Шаг первый: направляем URL в браузер.
Когда мы хотим посмотреть веб-страницу, мы можем использовать разные типы девайсов: ноутбук, стационарный компьютер или телефон. Главное, чтобы на устройстве было приложение браузера. Пользователь либо вводит унифицированный указатель ресурса (URL) в поисковую строку браузера, либо переходит по ссылке с уже открытой страницы:
URL-адрес начинается с HTTP. Это сигнал браузеру, что ему необходимо использовать HTTP-протокол для получения документа по этому адресу.
Шаг второй: браузер ищет нужный IP-адрес.
Обычно IP-адреса содержат удобные и читабельные для человека названия доменов, например «highload.today» или «wikipedia.org». Браузер использует преобразователь DNS для сопоставления домена с IP-адресом.
Шаг третий: браузер посылает HTTP-запрос.
Как только браузер определяет IP-адрес компьютера, на котором размещен запрошенный URL, он отправляет HTTP-запрос.
HTTP-запрос может состоять всего из двух строк текста:
Кроме GET в HTTP-протоколе существует еще два вида запросов. Разберем их отличия:
Шаг четвертый: сервер отправляет HTTP-ответ.
Как только хост-компьютер получает HTTP-запрос, он отправляет клиенту ответ с содержанием и метаданными.
HTTP-ответ начинается аналогично запросу:
Ответ начинается с указания версии HTTP-протокола — 1.1. Следующее число — это код статуса HTTP, в примере это число 200. Этот код значит, что запрашиваемый документ был успешно извлечен.
Следующая часть ответа HTTP — это заголовки. Они предоставляют браузеру дополнительные сведения и помогают ему отображать контент. Эти два заголовка являются общими для большинства запросов:
Content-length показывает длину документа в байтах, что помогает браузеру узнать, сколько времени потребуется для загрузки файла.
Кроме кода 200, в случае если загрузка страницы прошла успешно, есть еще несколько статусов:
Шаг пятый: отображается нужная веб-страница. После выполнения всех шагов, браузер получает всю необходимую информацию, для отображения запрошенного документа.
Основные характеристики HTTP-протокола
Есть три основные особенности, которые делают HTTP простым, но мощным протоколом.
HTTP-протокол — простой, но многофункциональный
HTTP — это основа всего интернета. Он быстрый, легкий и многофункциональный. Подводя итоги, рассмотрим преимущества и особенности HTTP-протокола.
Для закрепления материала можно посмотреть эти два образовательные видео:
Глава 1. Введение в протоколы HTTP и HTTPS
Протокол HTTP предназначен для передачи содержимого в Интернете. HTTP — это простой протокол, который использует для передачи содержимого надежные службы протокола TCP. Благодаря этому HTTP считается очень надежным протоколом для обмена содержимым. Также HTTP является одним из самых часто используемых протоколов приложений. Все операции в Интернете используют протокол HTTP.
HTTPS — это безопасная версия протокола HTTP, которая реализует протокол HTTP с использованием протокола TLS для защиты базового TCP-подключения. За исключением дополнительной конфигурации, необходимой для настройки TLS, использование протокола HTTPS по сути не отличается от протокола HTTP.
Общие требования для протокола HTTP
Для правильной работы пакета NetX Web HTTP требуется установить NetX Duo 5.10 или более поздней версии. Кроме того, должен быть создан экземпляр IP, для которого включено использование протокола TCP. Для поддержки HTTPS также необходимо установить NetX Secure TLS 5.11 или более поздней версии (см. следующий раздел). Этот процесс показан в демонстрационном файле в разделе «Пример небольшой системы» главы 2.
Для HTTP-клиента из пакета NetX Web HTTP больше нет дополнительных требований.
Но HTTP-сервер из пакета NetX Web HTTP определяет еще несколько дополнительных требований. Во-первых, ему требуется полный доступ к известному TCP-порту 80 для обработки всех запросов HTTP-клиента (приложение может указать любой другой допустимый порт TCP). HTTP-сервер также разработан для работы с внедренной файловой системой FileX. Если система FileX недоступна, пользователь может перенести используемые разделы FileX в собственную среду. Этот процесс рассматривается в последующих разделах этого руководства.
Требования для протокола HTTPS
Для правильной работы протокола HTTPS на основе пакета NetX Web HTTP требуется, чтобы были установлены NetX Duo 5.10 или более поздней версии и NetX Secure TLS 5.11 или более поздней версии. Кроме того, должен быть создан экземпляр IP, для которого включено использование протокола TCP для работы с протоколом TLS. Сеанс TLS необходимо будет инициализировать с помощью соответствующих криптографических процедур и сертификата доверенного ЦС. Кроме того, потребуется выделить пространство для сертификатов, которые будут предоставляться удаленными узлами сервера во время подтверждения TLS. Этот процесс показан в демонстрационном файле в разделе «Пример небольшой системы HTTPS» главы 2.
Для HTTPS-клиента из пакета NetX Web HTTP больше нет дополнительных требований.
Но HTTPS-сервер из пакета NetX Web HTTP определяет еще несколько дополнительных требований. Во-первых, ему требуется полный доступ к известному TCP-порту 443 для обработки всех HTTPS-запросов клиента (как и в случае протокола HTTP без шифрования, приложение может изменить этот порт). Во-вторых, потребуется инициализировать сеанс TLS с помощью соответствующих криптографических процедур и сертификата удостоверения сервера (или общего ключа). HTTPS-сервер также разработан для работы с внедренной файловой системой FileX. Если система FileX недоступна, пользователь может перенести используемые разделы FileX в собственную среду. Использование FileX рассматривается в последующих разделах этого руководства.
Дополнительные сведения о параметрах конфигурации TLS см. в документации по NetX Secure.
Если не указано иное, все функции HTTP, описанные в этом документе, также относятся к протоколу HTTPS.
Ограничения протоколов HTTP и HTTPS
NetX Web HTTP реализует стандарт HTTP 1.1. Но существует ряд ограничений, которые приведены ниже:
URL-адрес HTTP (имена ресурсов)
Протокол HTTP разработан для передачи содержимого через Интернет. Запрашиваемое содержимое определяется URL-адресом. Это основной компонент каждого HTTP-запроса. URL-адреса всегда начинаются с символа «/» и обычно обозначают определенные файлы на HTTP-сервере. Ниже приведены типичные расширения файлов, используемые с протоколом HTTP:
Запросы HTTP-клиента
Эти команды ASCII обычно генерируются веб-браузерами и службами клиента NetX Web HTTP для выполнения операций HTTP на HTTP-сервере.
Ответы HTTP-сервера
Например, в ответ на успешно выполненный запрос PUT клиента для файла test.htm будет возвращено сообщение «HTTP/1.1 200 OK».
Взаимодействие по протоколу HTTP
HTTP-запрос GET
HTTP-запрос PUT
Проверка подлинности HTTP
Проверка подлинности HTTP является необязательной, то есть требуется не для всех веб-запросов. Существуют две разновидности проверки подлинности: обычная и на основе дайджеста. Обычная проверка подлинности по имени и паролю работает точно так же, как во многих других протоколах. При обычной проверке подлинности HTTP имя и пароли объединяются в одну строку и кодируются в формате Base64. Основным недостатком обычной проверки подлинности является то, что имя и пароль передаются в запросе в открытом виде. Это позволяет достаточно легко похищать такие имена и пароли. Дайджест-проверка подлинности устраняет эту проблему, так как при ней имя и пароль не передаются вместе с запросом. Вместо этого применяется специальный механизм вычисления 128-разрядного дайджеста по имени пользователя, паролю и некоторым другим параметрам. Сервер NetX Web HTTP поддерживает стандартный алгоритм дайджестов MD5.
Когда нужна проверка подлинности? HTTP-сервер самостоятельно решает, требуется ли проверка подлинности для запрошенного ресурса. Если проверка подлинности нужна, но в запросе от клиента нет необходимых данных проверки подлинности, то клиенту возвращается ответ «HTTP/1.1 401 Unauthorized» с указанием требуемого типа проверки подлинности. Ожидается, что клиент в этом случае сформирует новый запрос с правильными данными проверки подлинности.
При использовании протокола HTTPS HTTPS-сервер по-прежнему может использовать проверку подлинности HTTP. В этом случае для шифрования всего трафика HTTP используется протокол TLS, поэтому использование обычной проверки подлинности HTTP не обуславливает угрозу безопасности. Дайджест-проверка подлинности также допускается, но не обеспечивает значительного повышения безопасности по сравнению с обычной проверкой подлинности на основе протокола TLS.
Обратный вызов проверки подлинности HTTP
Как уже упоминалось, проверка подлинности HTTP является необязательной, то есть используется не при любой передаче данных через Интернет. Кроме того, проверка подлинности обычно зависит от конкретного ресурса. Один и тот же сервер может требовать проверку подлинности для доступа к некоторым ресурсам и не требовать для доступа к другим. Пакет HTTP-сервера Неткс позволяет приложению указать (с помощью вызова nx_web_http_server_create ) подпрограммы обратного вызова проверки подлинности, которая вызывается в начале обработки каждого HTTP-запроса клиента.
Эта подпрограмма обратного вызова предоставляет серверу NetX Web HTTP строковые значения имени пользователя, пароля и области, которые связаны с конкретным ресурсом, и возвращает необходимый тип проверки подлинности. Если для ресурса не требуется проверка подлинности, обратный вызов проверки подлинности должен возвращать значение NX_WEB_HTTP_DONT_AUTHENTICATE. Если для указанного ресурса требуется обычная проверка подлинности, эта подпрограмма должна возвращать NX_WEB_HTTP_BASIC_AUTHENTICATE. Наконец, если требуется дайджест-проверка подлинности MD5, подпрограмма обратного вызова должна возвращать NX_WEB_HTTP_DIGEST_AUTHENTICATE. Если ни для одного из ресурсов, предоставляемого HTTP-сервером, не требуется проверка подлинности, обратный вызов можно не указывать, передав в вызов для создания HTTP-сервера пустой указатель.
Формат подпрограммы обратного вызова проверки подлинности для приложения достаточно прост и определен ниже.
Входные параметры определяются следующим образом.
Возвращаемое значение подпрограммы проверки подлинности указывает, требуется ли проверка подлинности. Указатели на имя, пароль и область определения приложения не используются, если подпрограмма обратного вызова проверки подлинности возвращает значение NX_WEB_HTTP_DONT_AUTHENTICATE. В противном случае разработчик HTTP-сервера должен убедиться, что значения NX_WEB_HTTP_MAX_USERNAME и NX_WEB_HTTP_MAX_PASSWORD, определенные в файле nx_web_http_server.h, достаточно велики для размещения имени пользователя и пароля, указанных в обратном вызове проверки подлинности. По умолчанию оба значения равны 20 символам.
Обратный вызов для недопустимых значений имени пользователя или пароля HTTP
Чтобы зарегистрировать обратный вызов на HTTP-сервере, используется приведенная ниже служба, которая определена на сервере NetX Web HTTP.
Определены следующие типы запроса:
Обратный вызов для добавления заголовка даты GMT в HTTP
Этот необязательный обратный вызов на сервере NetX Web HTTP позволяет добавлять в ответные сообщения заголовок со значением даты. Он вызывается, когда HTTP-сервер отвечает на запрос PUT или GET.
Чтобы зарегистрировать обратный вызов для добавления даты GMT на HTTP-сервере, определена приведенная ниже служба.
Тип данных NX_WEB_HTTP_SERVER_DATE определяется следующим образом:
Обратный вызов для получения сведений из кэша HTTP
HTTP-сервер поддерживает обратный вызов для запроса ограничений по возрасту и датам для определенного ресурса в приложении HTTP. Эти сведения позволяют определить, будет ли HTTP-сервер отправлять всю страницу клиенту по запросу GET. Если в запросе клиента нет строки «if modified since» (если изменено позднее) или это значение не совпадает с датой «last modified» (последнее изменение), полученной в обратном вызове запроса сведений из кэша, то клиенту отправляется вся страница.
Чтобы зарегистрировать обратный вызов на HTTP-сервере, определена приведенная ниже служба.
Поддержка поблочного кодирования HTTP
Если определить общую длину сообщения HTTP перед отправкой невозможно, то можно использовать функцию поблочного кодирования для отправки сообщений в виде серий блоков без поля заголовка Content-Length. Эта функция поддерживается во всех сообщениях HTTP-запросов и HTTP-ответов. Эта функция поддерживается на стороне получателя, а заголовок блока автоматически обрабатывается внутренней логикой. На стороне отправителя клиентом и сервером должны вызываться интерфейсы API nx_web_http_client_request_chunked_set и nx_web_http_server_response_chunked_set соответственно.
Дополнительные сведения об использовании этих служб можно найти в главе 3 «Описание служб HTTP».
Поддержка многокомпонентных сообщений HTTP
Протокол MIME изначально предназначался для взаимодействия с протоколом SMTP, но теперь он используется и с протоколом HTTP. Протокол MIME позволяет включать в одно сообщение смешанные типы данных (например, image/jpg и text/plain). Сервер NetX Web HTTP включает в себя службы для определения типа содержимого в полученных от клиента сообщениях HTTP, содержащих данные MIME. Чтобы включить поддержку многокомпонентных сообщений HTTP и использовать эти службы, необходимо определить параметр конфигурации NX_WEB_HTTP_MULTIPART_ENABLE.
Дополнительные сведения об использовании этих служб можно найти в главе 3 «Описание служб HTTP».
Поддержка многопоточности HTTP
Службы клиента NetX Web HTTP можно вызывать из нескольких потоков одновременно. Но запросы на чтение или запись для конкретного экземпляра HTTP-клиента должны выполняться последовательно из одного потока.
При использовании протокола HTTPS службы клиента NetX Web HTTP могут вызываться из нескольких потоков, но ввиду повышенной сложности базовых функций TLS каждый поток должен использовать отдельный, независимый экземпляр HTTP-клиента (структуру управления NX_WEB_HTTP_CLIENT).
Соответствие протокола HTTP положениям документов RFC
NetX Web HTTP соответствует требованиям документов RFC 1945 «Hypertext Transfer Protocol/1.0» (Протокол передачи гипертекста, версия 1.0), RFC 2616 «Hypertext Transfer Protocol/1.1» (Протокол передачи гипертекста, версия 1.1), RFC 2581 «TCP Congestion Control» (Контроль перегрузки TCP), RFC 1122 «Requirements for Internet Hosts» (Требования к Интернет-узлам) и других связанных с ними документов RFC.
Реализация протокола HTTPS в NetX Web HTTP соответствует требованиям документа RFC 2818 «HTTP over TLS» (Передача данных HTTP по протоколу TLS).
Обзор протокола HTTP
HTTP — это протокол, позволяющий получать различные ресурсы, например HTML-документы. Протокол HTTP лежит в основе обмена данными в Интернете. HTTP является протоколом клиент-серверного взаимодействия, что означает инициирование запросов к серверу самим получателем, обычно веб-браузером (web-browser). Полученный итоговый документ будет (может) состоять из различных поддокументов, являющихся частью итогового документа: например, из отдельно полученного текста, описания структуры документа, изображений, видео-файлов, скриптов и многого другого.
Клиенты и серверы взаимодействуют, обмениваясь одиночными сообщениями (а не потоком данных). Сообщения, отправленные клиентом, обычно веб-браузером, называются запросами, а сообщения, отправленные сервером, называются ответами.
Составляющие систем, основанных на HTTP
HTTP — это клиент-серверный протокол, то есть запросы отправляются какой-то одной стороной — участником обмена (user-agent) (либо прокси вместо него). Чаще всего в качестве участника выступает веб-браузер, но им может быть кто угодно, например, робот, путешествующий по Сети для пополнения и обновления данных индексации веб-страниц для поисковых систем.
Каждый запрос (англ. request) отправляется серверу, который обрабатывает его и возвращает ответ (англ. response). Между этими запросами и ответами как правило существуют многочисленные посредники, называемые прокси, которые выполняют различные операции и работают как шлюзы или кэш, например.
Обычно между браузером и сервером гораздо больше различных устройств-посредников, которые играют какую-либо роль в обработке запроса: маршрутизаторы, модемы и так далее. Благодаря тому, что Сеть построена на основе системы уровней (слоёв) взаимодействия, эти посредники «спрятаны» на сетевом и транспортном уровнях. В этой системе уровней HTTP занимает самый верхний уровень, который называется «прикладным» (или «уровнем приложений»). Знания об уровнях сети, таких как представительский, сеансовый, транспортный, сетевой, канальный и физический, имеют важное значение для понимания работы сети и диагностики возможных проблем, но не требуются для описания и понимания HTTP.
Клиент: участник обмена
Участник обмена (user agent) — это любой инструмент или устройство, действующие от лица пользователя. Эту задачу преимущественно выполняет веб-браузер; в некоторых случаях участниками выступают программы, которые используются инженерами и веб-разработчиками для отладки своих приложений.
Браузер всегда является той сущностью, которая создаёт запрос. Сервер обычно этого не делает, хотя за многие годы существования сети были придуманы способы, которые могут позволить выполнить запросы со стороны сервера.
Веб-страница является гипертекстовым документом. Это означает, что некоторые части отображаемого текста являются ссылками, которые могут быть активированы (обычно нажатием кнопки мыши) с целью получения и соответственно отображения новой веб-страницы (переход по ссылке). Это позволяет пользователю «перемещаться» по страницам сети (Internet). Браузер преобразует эти гиперссылки в HTTP-запросы и в дальнейшем полученные HTTP-ответы отображает в понятном для пользователя виде.
Веб-сервер
На другой стороне коммуникационного канала расположен сервер, который обслуживает (англ. serve) пользователя, предоставляя ему документы по запросу. С точки зрения конечного пользователя, сервер всегда является некой одной виртуальной машиной, полностью или частично генерирующей документ, хотя фактически он может быть группой серверов, между которыми балансируется нагрузка, то есть перераспределяются запросы различных пользователей, либо сложным программным обеспечением, опрашивающим другие компьютеры (такие как кеширующие серверы, серверы баз данных, серверы приложений электронной коммерции и другие).
Прокси
Между веб-браузером и сервером находятся большое количество сетевых узлов, передающих HTTP сообщения. Из-за слоистой структуры большинство из них оперируют также на транспортном сетевом или физическом уровнях, становясь прозрачным на HTTP слое и потенциально снижая производительность. Эти операции на уровне приложений называются прокси. Они могут быть прозрачными или нет, (изменяющие запросы не пройдут через них), и способны исполнять множество функций:
Основные аспекты HTTP
Даже с большей сложностью, введённой в HTTP/2 путём инкапсуляции HTTP-сообщений в фреймы, HTTP, как правило, прост и удобен для восприятия человеком. HTTP-сообщения могут читаться и пониматься людьми, обеспечивая более лёгкое тестирование разработчиков и уменьшенную сложность для новых пользователей.
Введённые в HTTP/1.0 HTTP-заголовки сделали этот протокол лёгким для расширения и экспериментирования. Новая функциональность может быть даже введена простым соглашением между клиентом и сервером о семантике нового заголовка.
HTTP не имеет состояния, но имеет сессию
HTTP не имеет состояния: не существует связи между двумя запросами, которые последовательно выполняются по одному соединению. Из этого немедленно следует возможность проблем для пользователя, пытающегося взаимодействовать с определённой страницей последовательно, например, при использовании корзины в электронном магазине. Но хотя ядро HTTP не имеет состояния, куки позволяют использовать сессии с сохранением состояния. Используя расширяемость заголовков, куки добавляются к рабочему потоку, позволяя сессии на каждом HTTP-запросе делиться некоторым контекстом или состоянием.
HTTP и соединения
Соединение управляется на транспортном уровне, и потому принципиально выходит за границы HTTP. Хотя HTTP не требует, чтобы базовый транспортного протокол был основан на соединениях, требуя только надёжность, или отсутствие потерянных сообщений (т.е. как минимум представление ошибки). Среди двух наиболее распространённых транспортных протоколов Интернета, TCP надёжен, а UDP — нет. HTTP впоследствии полагается на стандарт TCP, являющийся основанным на соединениях, несмотря на то, что соединение не всегда требуется.
HTTP/1.0 открывал TCP-соединение для каждого обмена запросом/ответом, имея два важных недостатка: открытие соединения требует нескольких обменов сообщениями, и потому медленно, хотя становится более эффективным при отправке нескольких сообщений, или при регулярной отправке сообщений: тёплые соединения более эффективны, чем холодные.
Проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google экспериментирует с QUIC (которая основана на UDP) для предоставления более надёжного и эффективного транспортного протокола.
Чем можно управлять через HTTP
Естественная расширяемость HTTP со временем позволила большее управление и функциональность Сети. Кеш и методы аутентификации были ранними функциями в истории HTTP. Способность ослабить первоначальные ограничения, напротив, была добавлена в 2010-е.
Ниже перечислены общие функции, управляемые с HTTP.
HTTP поток
Когда клиент хочет взаимодействовать с сервером, являющимся конечным сервером или промежуточным прокси, он выполняет следующие шаги:
Если активирован HTTP-конвейер, несколько запросов могут быть отправлены без ожидания получения первого ответа целиком. HTTP-конвейер тяжело внедряется в существующие сети, где старые куски ПО сосуществуют с современными версиями. HTTP-конвейер был заменён в HTTP/2 на более надёжные мультиплексные запросы во фрейме.
HTTP сообщения
HTTP/1.1 и более ранние HTTP сообщения человекочитаемые. В версии HTTP/2 эти сообщения встроены в новую бинарную структуру, фрейм, позволяющий оптимизации, такие как компрессия заголовков и мультиплексирование. Даже если часть оригинального HTTP сообщения отправлена в этой версии HTTP, семантика каждого сообщения не изменяется и клиент воссоздаёт (виртуально) оригинальный HTTP-запрос. Это также полезно для понимания HTTP/2 сообщений в формате HTTP/1.1.
Существует два типа HTTP сообщений, запросы и ответы, каждый в своём формате.
Запросы
Примеры HTTP запросов:
Запросы содержат следующие элементы:
Ответы
Ответы содержат следующие элементы:
Вывод
HTTP — лёгкий в использовании расширяемый протокол. Структура клиент-сервера, вместе со способностью к простому добавлению заголовков, позволяет HTTP продвигаться вместе с расширяющимися возможностями Сети.
Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP сообщения во фреймы для улучшения производительности, базовая структура сообщений осталась с HTTP/1.0. Сессионный поток остаётся простым, позволяя исследовать и отлаживать с простым монитором HTTP-сообщений.