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

Соединения

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

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

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

Методы

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

Таблица 1. Встроенные методы HTTP-запросов

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

GET filename HTTP/1.1,

где filename указывает на запрашиваемый ресурс (файл), а 1.1 — на используемую версию протокола.

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

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

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

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

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

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

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

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

Таблица 2. Группы кодов состояния, содержащиеся в ответах сервера

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

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

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

 Таблица  3. Некоторые заголовки сообщений протокола HTTP

Заголовок User-Agent позволяет клиенту информировать сервер о версии своего браузера, операционной системы или предоставлять другую информацию о себе. В листинге выше мы видели, что сервер каким-то волшебным образом получал эти данные и мог при необходимости использовать их в PHP-скрипте. Как раз с помощью заголовка User-Agent клиент и сообщил серверу о себе.

Четыре заголовка, начинающиеся с Accept, сообщают серверу о типах информации, которые он готов принять (если их набор ограничен). Первый приведенный в таблице заголовок определяет типы MIME, которые будут корректно приняты клиентом (например, text/html). Заголовок Accept-Charset сообщает о том, какой набор символов клиент хотел бы видеть (например, ISO-8859 или Unicode-1-1). В заголовке Accept-Encoding речь идет о приемлемых методах сжатия (например, gzip). Наконец, Accept-Language сообщает, на каком языке клиент готов читать документы (например, на испанском). Если сервер имеет возможность выбирать из нескольких страниц, он подберет наиболее подходящий для клиента вариант в соответствии с полученной информацией. Если запрос удовлетворить невозможно, возвращается код ошибки, и запрос считается неудавшимся.

Заголовок Host описывает сервер. Его значение берется из URL. Этот заголовок обязателен. Почему? Потому что некоторые IP-адреса могут обслуживать несколько имен DNS одновременно, и серверу необходимо каким-то образом различать, кому передавать запрос.

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

Несмотря на то, что cookie описываются в RFC 2109, а не в RFC 2616, для их описания существуют два заголовка. В частности, заголовок Cookie применяется клиентом при возвращении на сервер cookie-файла, который ранее был послан какой-либо машиной из домена сервера.

Заголовок Date может применяться как в запросах, так и в ответах. Он содержит время и дату отправки сообщения.

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

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

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

Заголовок Last-modified содержит дату и время внесения последних изменений в отправляемую страницу. Он играет важную роль при кэшировании страницы.

Заголовок Location вставляется сервером для информирования клиента о том, что стоит попробовать осуществить свой запрос повторно по другому URL. Такая ситуация может возникать при «переезде» страницы или тогда, когда несколько URL ссылаются на одну и ту же страницу (возможно, на «зеркало» страницы, расположенное на другом сервере). Этот трюк нередко применяется теми компаниями, главная веб-страница которых прописана в домене .com, однако клиенты перенаправляются с нее на национальные или региональные страницы, имеющие свои IP-адреса или написанные на более приемлемом для клиента языке.

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

Set-cookie — это второй заголовок, относящийся к cookie-маркерам. Если этот заголовок установлен сервером, предполагается, что, увидев его, клиент сохранит у себя cookie и вернет его вместе со следующим запросом на сервер.

al-tm.ru

Что такое протокол 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 — о нем и поговорим в следующей статье.

www.iguides.ru

Протокол передачи гипертекста — Hypertext Transfer Protocol

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

Разработка HTTP был инициирован Тим Бернерс-Ли в CERN в 1989. Разработка стандартов HTTP координировалась Engineering Task Force Интернет (IETF) и консорциума World Wide Web (W3C), что привело к публикации серии запросов на Комментарии (РЛК). Первое определение HTTP / 1.1, версия HTTP в общем пользовании, произошло в RFC  2068 в 1997 году, хотя это было сделано устаревшим RFC  2616 в 1999 году , а затем снова в RFC  7230 семейства РЛК в 2014 году.

Более поздняя версия, преемник HTTP / 2 , был стандартизирован в 2015 году (и HTTP / 3 является его предложенный преемник ( Internet Draft ), который основан на HTTP / 2), и в настоящее время поддерживается основными веб — серверами и программами TLS с использованием ALPN расширение , где TLS 1.2 или более поздней версии требуется.

Технический обзор

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

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

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

HTTP является прикладного уровня протокол , разработанный в рамках пакета Интернет — протокола . Ее определение предполагает , лежащий в основе и надежного транспортного уровня протокола, и протокол управления передачей (TCP) обычно используется. Однако, HTTP может быть адаптирован для использования ненадежных протоколов , таких как User Datagram Protocol (UDP), например , в HTTPU и Simple Service Discovery Protocol (SSDP).

HTTP ресурсы определены и находятся в сети с помощью унифицированного указателя ресурсов (URL), используя унифицированные идентификаторы ресурсов схем (URI) в HTTP и HTTPS . URIs и гиперссылок в HTML — документы являются взаимосвязанными гипертекстовых документов.

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

история

Термин гипертекст был придуман Тедом Нельсоном в 1965 году в Xanadu проекте , который в своей очереди был вдохновлен Ванневар Буш «s 1930 — х лет видение информационного поиска микрофильмов основы и управления„ Memex “система , описанная в его 1945 эссе» Как мы можем думать , ». Тим Бернерс-Ли и его команда CERN приписывают изобретение оригинального HTTP, наряду с HTML и связанных с ними технологий для веб — сервера и текстовый веб — браузер. Бернерс-Ли предложил первый проект «WorldWideWeb» в 1989 году, теперь известный как World Wide Web . Первая версия протокола имела только один способ, а именно GET, который бы запросить страницу с сервера. Ответ от сервера всегда был HTML — страницы.

Первый документированный версия HTTP был HTTP v0.9 (1991). Дэйв Раггетт возглавлял рабочую группу HTTP (HTTP WG) в 1995 году и хотел расширить протокол с расширенными операциями, расширенного переговоров, богаче мета-информации, связанных с протоколом безопасности , который стал более эффективным путем добавления дополнительных методов и полей заголовка . RFC  1945 официально представлен и признал HTTP V1.0 в 1996 году.

HTTP РГ планирует опубликовать новые стандарты в декабре 1995 года , а поддержка до стандарта HTTP / 1.1 на основе затем развивается RFC  2068 ( так называемый HTTP-NG) быстро принят основными разработчиками браузеров в начале 1996 года В марте того же года , предварительно стандарт HTTP / 1.1 был поддержан в арене , Netscape 2.0 , Netscape Navigator Gold 2,01, Mosaic 2.7 , Lynx 2.5 , а в Internet Explorer 2.0 . Конечный пользователь принятие новых браузеров было быстрым. В марте 1996 года , один веб — хостинге компания сообщила , что более 40% браузеры в использовании в Интернете были HTTP 1.1 совместимых. В том же веб — хостинг компания сообщила , что в июне 1996 года, 65% всех браузеров доступ к своим серверам были HTTP / 1.1 совместимый. HTTP / 1.1 стандарт , как это определено в RFC  2068 был официально выпущен в январе 1997 года Улучшения и обновления к HTTP / 1.1 стандарта были выпущены в соответствии с RFC  2616 в июне 1999 года.

В 2007 году Рабочая группа HTTPbis была сформирована, в частности, пересмотреть и уточнить HTTP / 1.1 спецификации. В июне 2014 года Рабочая группа выпустила обновленные шесть частей спецификации obsoleting RFC  2616 :

• RFC  7230 , HTTP / 1.1: Сообщение Синтаксис и маршрутизация
• RFC  7231 , HTTP / 1.1: Семантика и содержание
• RFC  7232 , HTTP / 1.1: Условные запросы
• RFC  7233 , HTTP / 1.1 Диапазон запросов
• RFC  7234 , HTTP / 1.1: Кэширование
• RFC  7235 , HTTP / 1.1: Аутентификация

HTTP / 2 был опубликован в RFC  7540 в мае 2015 года.

HTTP сессии

HTTP сессия представляет собой последовательность операций запрос-ответ сети. Клиент HTTP инициирует запрос путем создания протокола управления передачей соединения (TCP) к определенному порту на сервере (обычно порт 80, иногда порт 8080, см список TCP и UDP номера порта ). HTTP — сервер прослушивает этот порт ждет сообщения с запросом клиента. Получив запрос, сервер отправляет обратно строку состояния, такие как «HTTP / 1.1 200 OK», и сообщение о своей собственной. Тела этого сообщения , как правило , запрошенный ресурс, хотя сообщение об ошибке или другая информация также может быть возвращена.

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

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

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

царства аутентификации

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

методы запроса

HTTP определяет методы (иногда называемые как глаголы , но нигде в описании не упоминается глагол , ни OPTIONS или голова глагола) , чтобы указать желаемое действие , которое будет выполняться на идентифицированный ресурсе. Что этот ресурс представляет собой, будь то ранее существовавшие данные или данные , которые генерируются динамически, зависит от реализации сервера. Часто ресурс соответствует файлу или выходу исполняемого файла , размещенного на сервере. HTTP / 1.0 спецификации определили GET, POST и HEAD , методы и HTTP / 1.1 спецификация добавили пять новых методов: OPTIONS, PUT, DELETE, TRACE и CONNECT. Будучи указанные в этих документах, их семантика хорошо известны и могут быть зависело. Любой клиент может использовать любой метод , и сервер может быть выполнен с возможностью поддерживать любую комбинацию методов. Если метод неизвестен промежуточный, он будет рассматриваться как небезопасный и не-идемпотентный метод. Там нет ограничения на количество методов , которые могут быть определены , и это позволяет для будущих методов , которые будут указаны без нарушения существующей инфраструктуры. Например, WebDAV определил 7 новых методов и RFC  5789 указан PATCH метод.

ПОЛУЧИТЬ

Метод GET запрашивает представление указанного ресурса. Запросы , использующие GET должен только извлекать данные и не должны иметь никакого другого эффекта. (Это также относится и к некоторым другим методам HTTP) . В W3C опубликовала принципы наведения на этом различии, говоря, « Веб — приложение дизайн должен быть проинформирован вышеизложенными принципами, но и соответствующими ограничениями.» См безопасные методы ниже.

ГОЛОВА

Метод ГОЛОВКИ запрашивает ответ, идентичного способом запроса GET, но без тела ответа. Это полезно для извлечения мета-данные, записанные в заголовках ответа, без необходимости транспортировать весь контент.

СООБЩЕНИЕ

Метод POST запросов , что сервер принимает объект , включенный в запрос , как новое подчинение веб — ресурса , идентифицированного URI. Данные публикуемые может быть, например, аннотация для имеющихся ресурсов; сообщение на доске объявлений, телеконференции, список рассылки или нить комментария; блок данных , который является результатом представления веб — формы в процессе обработки данных; или элемент для добавления в базу данных.

ПОЛОЖИЛ

Метод PUT просит включенный объект будет храниться в прилагаемом URI . Если URI относится к уже существующему ресурсу, он изменяется; если URI не указывает на существующий ресурс, то сервер может создать ресурс с этим URI.

УДАЛЯТЬ

УДАЛИТЬ метод удаляет указанный ресурс.

TRACE

Метод TRACE эхо принятый запрос таким образом, что клиент может видеть то, что (если таковые имеются) изменения или дополнения были сделаны промежуточных серверов.

ОПЦИИ

Метод OPTIONS возвращает методы HTTP , что сервер поддерживает для указанного URL . Это может быть использовано для проверки работоспособности веб — сервера путем запроса «*» вместо конкретного ресурса.

CONNECT

Метод CONNECT преобразует соединение запроса в прозрачный TCP / IP туннель , как правило , для облегчения SSL -encrypted связи (HTTPS) через незашифрованный HTTP прокси . См метод HTTP CONNECT .

PATCH

Метод применяется ЗАПЛАТА частичных модификаций к ресурсу.

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

Безопасные методы

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

Напротив, такие методы, как POST, PUT, DELETE и PATCH предназначены для действий , которые могут вызвать побочные эффекты , либо на сервере, либо внешних побочных эффектов , таких как финансовые операции или передачи по электронной почте . Такие способы , как правило , таким образом , не используется в соответствии веб — роботов или веб — сканеров; некоторые , которые не соответствуют , как правило, делают запросы безотносительно к контексту или последствий.

Несмотря на предписанную безопасности GET запросов, на практике их обработка сервера технически не ограничивается каким — либо образом. Таким образом, неосторожное или умышленное программирование может привести к нетривиальным изменениям на сервере. Это не рекомендуется, так как это может вызвать проблемы для веб — кэширования , поисковых систем и других автоматизированных агентов, которые могут сделать непреднамеренные изменения на сервере. Например, веб — сайт может позволить удаление ресурса через URL , такие как http://example.com/article/1234/delete , который, если произвольно извлеченный, даже с использованием GET , просто удалить статью.

Одним из примеров этого происходит на практике было во время недолгого Google Web Accelerator бета , который опережающей выборки произвольных URL — адресов на странице пользователь просматривает, в результате чего записи будут автоматически изменены или удалены в массовом порядке . Бета была приостановлена только недели после своего первого релиза, после широкой критики.

Идемпотентные методы и веб-приложения

Методы PUT и DELETE определяются так, чтобы быть идемпотентна , а это означает , что несколько одинаковых запросов должны иметь один и тот же эффект, что и один запрос ( обратите внимание , что идемпотентность относится к состоянию системы после того , как запрос завершен, так что в то время как действие сервер принимает (например , удаление записи) или код ответа он возвращает может отличаться от последующих запросов, состояние системы будет таким же , каждый раз ). Методы GET, HEAD, OPTIONS и следовые, прописывают в безопасности, а также должны быть идемпотентна как HTTP является протоколом без .

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

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

Безопасность

Метод трассировки может быть использован как часть класса атак , известных как трассировка межсайтовой ; по этой причине, советы общей безопасности для того , чтобы быть отключен в конфигурации сервера. Microsoft IIS поддерживает собственный метод «дорожкой», которая ведет себя подобным образом , и который также рекомендуется отключить.

Таблица результатов

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

В HTTP / 1.0 и так как , в первой строке ответа HTTP называется строкой состояния и включает в себя числовой код состояния (например, « 404 ») и текстовая причина фразу (например, „Not Found“). Образом агент пользователя обрабатывает ответ в первую очередь зависит от кода, а во- вторых на других полях заголовка ответа . Пользовательские коды состояния могут быть использованы, если агент пользователя встречает код он не признает, он может использовать первую цифру кода , чтобы определить общий класс ответа.

Стандартная причина фраза только рекомендация, и может быть заменена на «местные эквиваленты» на разработчик веб усмотрения «s. Если код состояния указывают на проблему, агент пользователя может отобразить причину фразы пользователю предоставить дополнительную информацию о характере проблемы. Стандарт также позволяет агенту пользователя , чтобы попытаться интерпретировать причину фразу , хотя это может быть неразумно , поскольку стандарт явно указует , что коды состояния машиночитаемые и причина фраза являются читаемым человеком. Код состояния HTTP в основном разделен на пять групп для лучшего объяснения запроса и ответов между клиентом и сервером , как называется:

• информационный 1XX
• успешный 2XX
• Перенаправление 3XX
• Ошибка клиента 4XX
• Ошибка сервера 5XX

Постоянные соединения

В HTTP / 0.9 и 1.0, соединение закрывается после одной пары запрос / ответ. В HTTP / 1.1 удерживающий-живе-механизм был введен, где соединение может быть повторно использовано для более чем одного запроса. Такие постоянные соединения снижают запрос задержку ощутимо, так как клиенту не нужно повторно согласовывать соединение TCP — 3-Way-квитирования после того, как первый запрос был отправлен. Другой положительный побочный эффект заключается в том , что, в целом, связь становится быстрее со временем из — за данных TCP медленного старта -mechanism.

Версия 1.1 протокола также пропускная способность улучшения оптимизации для HTTP / 1.0. Так , например, HTTP / 1.1 введено кодирование поблочного , чтобы на содержание постоянных соединений, подлежащих потоковой передаче , а не в буфер. HTTP конвейерные дополнительно уменьшает время задержки, что позволяет клиентам отправлять несколько запросов перед ожиданием каждого ответа. Еще одно дополнения к протоколу было байты Порции , когда сервер передает только часть ресурса явно запрошенный клиентом.

состояние HTTP сессии

HTTP является протоколом без . Без гражданства протокол не требует серверов HTTP , чтобы сохранить информацию или статус каждого пользователя на протяжении нескольких запросов. Тем не менее, некоторые веб — приложения реализовать состояния или на стороне сервера сеансов с использованием, например HTTP печеньем или скрытых переменных внутри веб — форм .

Зашифрованные соединения

Самый популярный способ установления зашифрованного соединения HTTP является HTTPS. Существуют также два других метода для установления шифрованного соединения HTTP: Secure Hypertext Transfer Protocol , и с помощью / 1.1 заголовка Upgrade HTTP , чтобы указать обновление до TLS. Поддержка браузера для этих двух, однако, почти не существует.

формат сообщения

Клиент и сервер общаются, посылая простые текстовые ( ASCII ) сообщения. Клиент посылает запросы на сервер , а сервер посылает ответы .

сообщение запроса

Сообщение запроса состоит из следующих действий:

Строка запроса и другие поля заголовка должны каждый конец с <CR> <LF> (то есть, возврат каретки характер с последующим фидерной линии символа). Пустая строка не должна состоять только <CR> <LF> и никаких других пробельных символов . В / 1.1 протокола HTTP, все поля заголовка кроме хоста не являются обязательными.

Запрос строка , содержащая только имя пути принимаются серверами для обеспечения совместимости с HTTP — клиентами до HTTP / 1.0 спецификации в RFC  1945 .

Ответное сообщение

Ответное сообщение состоит из следующих действий:

Строка состояния и другие поля заголовка все должны заканчиваться <CR> <LF>. Пустая строка не должна состоять только <CR> <LF> и никаких других пробельных символов . Это строгое требование <CR> <LF> ослабляется несколько в теле сообщения для последовательного использования других системных переносов , таких как <CR> или <LF> в одиночку.

Пример сеанса

Ниже приведен пример разговора между клиентом HTTP и сервером HTTP работает на www.example.com , порт 80. Как уже упоминалось в предыдущих разделах, все данные передаются в текстовом ( ASCII ) кодирования, с использованием двух- байт CR LF ( «\ г \ п») линия заканчивается в конце каждой строки.

запрос клиента

GET /index.html HTTP/1.1
Host: www.example.com

Запрос клиента (состоящий в данном случае строки запроса и только одно поле заголовка) следует пустая строка, так что запрос завершается с двойной новой строки, каждая в виде возврата каретки с последующим переводом строки . Поле «Host» различает различные DNS — имена , разделяющие один IP — адрес , что позволяет на основе имен виртуального хостинга . В то время как дополнительный в HTTP / 1.0, он является обязательным в HTTP / 1.1.

ответ сервера

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

ETag Поле заголовка (метка объекта) используется для определения того, если в кэше версия запрашиваемого ресурса идентична текущей версии ресурса на сервере. Content-Type определяет тип интернет — медиа данных , передаваемых в сообщении HTTP, в то время как Content-Length указывает длину в байтах. HTTP / 1.1 веб — сервер публикует свою способность реагировать на запросы определенных диапазонов байтов документа путем установки поля Accept-Ranges: байт . Это полезно, если клиент должен иметь только определенные части ресурса , отправленного сервером, который называется байт служит . Когда соединения: близко посылаются, то это означает , что веб — сервер закрывает TCP сразу соединение после передачи этого ответа.

Большинство строк заголовка не является обязательным. Когда Content-Length отсутствует длина определяется другими способами. Блочное кодирование передачи использует размер порции 0 , чтобы отметить конец содержимого. Идентичность кодирование без Content-Length считывает содержимое до тех пор , пока сокет закрыт.

Content-Encoding , как Gzip может быть использован для сжатия передаваемых данных.

Подобные протоколы

Протокол Gopher был содержание протокола доставки , который был вытеснен HTTP в начале 1990 — х годов. SPDY протокол является альтернативой HTTP разработан в Google , он будет заменен новым протоколом HTTP, HTTP / 2 .

Смотрите также

Заметки

Рекомендации

внешняя ссылка

Викискладе есть медиафайлы по теме HTTP .

ru.qwertyu.wiki

ответы на тест 9_016 | EduDocs.net: образовательные документы

edudocs.net

Тест на тему Компьютерные сети (с ответами)

Тест на тему «Компьютерные сети»

Вопрос 1. (Сложность — A) Глобальная сеть — это …
        Ответ 1. система, связанных между собой компьютеров
        Ответ 2. система, связанных между собой локальных сетей
        Ответ 3. система, связанных между собой локальных телекоммуникационных сетей
        *Ответ 4. система, связанных между собой локальных сетей и компьютеров отдельных пользователей

Вопрос 2. (Сложность — A) Чтобы соединить два компьютера по телефонным линиям связи необходимо иметь:
        Ответ 1. модем
       * Ответ 2. два модема
        Ответ 3. телефон, модем и специальное программное обеспечение
        Ответ 4. по модему на каждом компьютере и специальное программное обеспечение

Вопрос 3. (Сложность — A) E-mail — это:
        Ответ 1. поисковая программа
        Ответ 2. название почтового сервера
        Ответ 3. почтовая программа
        *Ответ 4. обмен письмами в компьютерных сетях(электронная почта)

Вопрос 4. (Сложность — A) Протокол HTTP служит для:
        *Ответ 1. передачи гипертекста
        Ответ 2. передачи файлов
        Ответ 3. управления передачи сообщениями
        Ответ 4. запуска программы с удаленного компьютера

Вопрос 5. (Сложность — A) Какие компоненты вычислительной сети необходимы для организации одноранговой локальной сети?
        *Ответ 1. модем, компьютер-сервер
        Ответ 2. сетевая плата, сетевое программное обеспечение
        Ответ 3. компьютер-сервер, рабочие станции,
        Ответ 4. линии связи, сетевая плата, сетевое программное обеспечение

Вопрос 6. (Сложность — A) Для просмотра WEB-страниц предназначены:
        Ответ 1. поисковые серверы
        *Ответ 2. браузеры
        Ответ 3. телеконференции
        Ответ 4. провайдеры

Вопрос 7. (Сложность — A) Какая из приведенных схем соединения компьютеров представляет собой замкнутую цепочку?
        Ответ 1. Шина
        *Ответ 2. Кольцо
        Ответ 3. Звезда
        Ответ 4. Нет правильного ответа

Вопрос 8. (Сложность — A) Какой кабель обеспечивает скоростью передачи данных до 10 Мбит/с?
        *Ответ 1. коаксиальный
        Ответ 2. витая пара
        Ответ 3. оптоволокно
        Ответ 4. нет правильного ответа

Вопрос 9. (Сложность — A) Для передачи файлов по сети используется протокол…
        Ответ 1. POP3
        Ответ 2. HTTP
        Ответ 3. CMPT
        *Ответ 4. FTP

Вопрос 10. (Сложность — A) Выберите корректный адрес электронной почты:
        Ответ 1. ivanpetrov@mail
        Ответ 2. ivan_petrov.mail.ru
        Ответ 3. ivan petrov.mail.ru
        *Ответ 4. [email protected]

Вопрос 11. (Сложность — A) Скорость передачи данных равна 6000Мбит/мин. Это составляет … Мбит/с
        Ответ 1. 10
        *Ответ 2. 100
        Ответ 3. 3600
        Ответ 4. 36000

Вопрос 12. (Сложность — A) Задан адрес электронной почты в сети Интернет: [email protected]. Каково имя почтового сервера?
        Ответ 1. [email protected]
        Ответ 2. fortuna
        *Ответ 3. list.ru
        Ответ 4. list

Вопрос 13. (Сложность — A) Компьютер, подключенный к сети Internet, обязательно имеет
        Ответ 1. URL-адрес;
        *Ответ 2. IP-адрес
        Ответ 3. WEB-страницу;
        Ответ 4. доменное имя;

Вопрос 14. (Сложность — A) Выберите корректный IP-адрес компьютера в сети
        *Ответ 1. 108.214.198.112
        Ответ 2. 18.274.198.0
        Ответ 3. 1278.214.198
        Ответ 4. 10,0,0,1225
Вопрос 15. (Сложность — A) Топология компьютерной сети, в которой все компьютеры сети присоединены к центральному узлу называется
        Ответ 1. Шина
        Ответ 2. Кольцо
        *Ответ 3. Звезда
        Ответ 4. Нет правильного ответа
Вопрос 16. (Сложность — B) Определите номер компьютера в сети по IP 215.128.255.106
        Ответ 1. 215.128.255.106
        Ответ 2. 128.255.106
        Ответ 3. 255.106
        *Ответ 4. 106
Вопрос 19. (Сложность — A) Протокол – это …
        Ответ 1. способность компьютера посылать файлы через каналы передачи информации
        Ответ 2. устройство для работы локальной сети
        *Ответ 3. стандарт передачи данных через компьютерную сеть
        Ответ 4. стандарт отправки сообщений через электронную почту

infourok.ru