Протокол HTTP — Документация по Веб-программированию 0.0.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP/1.1 200 Ok

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

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

Таблица 1. Методы протокола HTTP

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

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

Примечание

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

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

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

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

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

Рис. 1. Структура кода состояния HTTP

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

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

Таблица 2. Коды состояния протокола HTTP

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

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

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

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

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

Заголовки HTTP

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

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

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

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

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

200 OK

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

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

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

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

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

Таблица 3. Заголовки HTTP

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

Листинг 1. Заголовки HTTP

http://www.example.org/

GET http://www.example.org/ HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive

HTTP/1.0 302 Moved Temporarily
Date: Thu, 03 Mar 2011 06:48:28 GMT
Location: http://www.iana.org/domains/example/
Server: BigIP
Content-Length: 0
X-Cache: MISS from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive
----------------------------------------------------------
http://www.iana.org/domains/example/

GET http://www.iana.org/domains/example/ HTTP/1.1
Host: www.iana.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive

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

....

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

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

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

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

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

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

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

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

Протокол Передачи ГИПЕРтекста HTTP для Чайников ты должен знать

HTTP расшифровывается, как Hypertext Transfer Protocol — протокол передачи гипертекста.  Этот протокол являются основой системы world wide web, именно его мы используем, когда просматриваем странички в браузере.

Web придумал Тим Бернерс-Ли, когда работал в ЦЕРН в 1989 году. Кроме протокола HTTP, веб включал язык разметки HTML, Web-сервер и Web-браузер. Веб-браузер ЦЕРН работал в текстовом виде. Вскоре после этого, появились графические веб браузеры, которыми оказалось очень легко пользоваться. Именно благодаря графическим браузерам и вебу интернет стал очень популярен. Сейчас Тим Бернерс-Ли является директором консорциума W3C, которая издает стандарты для World Wide Web.  

Гипертекст и HTML

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

Например, тег ˂h2˃ говорит, что дальше идет заголовок Протокол HTTP и закрывающийся тег ˂h2˃ заголовок закончился. Тег ˂u1˃ означает список, а ˂li˃ элемент списка. 

Вот как этот гипертекстовый HTML документ показывает браузер. 

Заголовок Протокол HTTP. Обычный текст, который был указан без разметки “Тим Бернер-Ли в ЦЕРН предложил концепцию Web в 1989 году”. И список. 

URL — уникальное положение ресурса

Большую роль в работе web и http играет URL (Uniform Resource Locator) — уникальное положение  ресурса, по-русски его часто называют ссылка. Это уникальный адрес веб-страницы в интернете. 

Рассмотрим, как устроены ссылки. Например, https://www.zvondozvon.ru/tehnologii/protokoli. Сначала идет название протокола, в нашем случае https. Затем :// и доменное имя сервера www.zvondozvon.ru на котором размещена страница, либо здесь может находиться IP-адрес сервера. После этого через слеш указывается имя конкретной страницы, которую мы хотим загрузить /tehnologii/protokoli.

 URL рассчитаны не только на работу с http и html, но и например с другими протоколами, можно указать защищенный протокол https или протокол ftp. Также не обязательно использовать гипертекст, на веб-серверах могут размещаться обычные текстовые страницы. 

Место протокола HTTP в стеке протоколов TCP/IP 

Протокол http находятся на прикладном уровне в стеке протоколов TCP/IP. 

Он использует протокол транспортного уровня TCP, веб-сервер работает на 80 порту для клиента номер порта генерируются автоматически операционной системой. HTTP работает в режиме запрос-ответ. Клиент пересылают серверу запрос на передачу веб-страницы и сервер в ответ эту веб-страницу пересылает. 

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

Версии протокола HTTP

Есть несколько версий протокола HTTP. Первая, экспериментальная версия HTTP 0.9 была разработана в ЦЕРН в 1991 году. Первая официальная версия HTTP 1.0 была принята в качестве стандарта в 1996 году и почти сразу же после этого в 1997 году была принята расширенная версия протокола HTTP 1.1. Именно эта версия используется до сих пор. В 2015 году появилась новая версия протокола HTTP 2 сейчас эта версия только вводится в эксплуатацию она поддерживается еще не всеми браузерами и не всеми веб-серверами.

Структура пакета HTTP

Пакет HTTP состоит из 3 частей. Первая часть это запрос, либо со стороны клиента, либо от статус ответа со стороны сервера. Например, запрос GET означает, что клиент просит передать ему web-страницу, которая находится на сервере вот по такому пути GET/tehnologii/protokoli в ответ сервер пересылает статус выполнения операции код и символьное сообщение, например 200 OK. Это означает, что страница нашлась на сервере и сервер передает ее в теле сообщения.

Затем могут идти и заголовки, которых может быть несколько. В версии HTTP 1.0 заголовки были не обязательны, но в версии HTTP 1.1 в запросе обязательно использовать заголовок Host:www.zvondozvon.ru, где указываются доменное имя сервера, у которого вы хотите запросить веб-страницу. Это сделано из-за того, что на одном и том же IP-адресе, может работать несколько веб-сайтов и в web серверу необходимо знать с какого сайта вы хотите загрузить страницу. 

Также могут быть другие заголовки, например тип передаваемого сообщения в примере Content-Type: text/html; charset=UTF-8, размер передаваемого сообщения Content-Length: 5161 байт. 

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

Методы HTML

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

• Самые популярные методы это GET запрос на передачу веб-страницы, именно этот запрос используются чаще всего. 
• POST передача данных на веб-сервер для обработки. Метод post используется например, когда вы пишите комментарии к роликам youtube, остальные методы, кроме get и post используются значительно реже. 
• Метод HEAD запрашивает заголовок страницы, то же самое, что и GET только без тела сообщения, хотя HTTP разрабатывался для передачи веб-страниц, создатели HTTP предусмотрели возможность его использования для работы с ресурсами других типов. 
• Метод PUT помещение ресурса на веб-сервер. 
• Метод DELETE удаление страницы или ресурса с веб-сервера для выполнения этих методов необходимо иметь соответствующие права доступа. 
• Метод TRACE позволяет отслеживать, что происходит со страницей, кто вносит в нее какие изменения. 
• Метод OPTIONS позволяет узнать, какие именно методы поддерживаются для конкретного ресурса на веб-сервере.
• Метод CONNECT позволяет подключиться к веб-серверу через прокси. 

Статусы HTTP

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

• Статусы, которые начинаются на единицу (1ХХ), используются для передачи информационных сообщений.
• Статусы, которые начинаются на двойку (2ХХ), говорят о том, что запрос выполнен успешно, например наиболее популярный статус (200 OK), означает что страница найдена и она передается клиенту.
• Статусы, которые начинаются на тройку (3ХХ), говорят о перенаправлении, например статус 301 — постоянное перенаправление, говорит о том что страница была перемещена на другой адрес и все последующие запросы должны передаваться на этот новый адрес. Статус 307 тоже говорит о перенаправлении, но временном, сейчас доступ к странице можно получить по другому адресу, но через некоторое время необходимо снова обращаться к исходному адресу.
• Статусы, которые начинаются с четверки (4ХХ), говоря о том, что произошла какая-то ошибка на стороне клиента. Чаще всего встречается ошибка 404 — страница, которую запросил клиент не найдена на сервере. Также возможна ошибка 403 доступ к ресурсу, который запросил клиент запрещен и другие ошибки. 
• Статусы начинающиеся на пять (5ХХ) говорят об ошибке на стороне сервера, например 500 — внутренняя ошибка сервера. 

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

Рассмотрим примеры запроса и ответа HTTP. 

Подключение по TCP к серверу www.zvondozvon.ru, порт 80. 

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

GET /tehnologii/protokoli HTTP 1.1

Host: www.zvondozvon.ru 

HTTP работают в текстовом режиме, нам необходимо подключиться к веб-серверу, например www.zvondozvon.ru к порту 80 по протоколу TCP. Дальше мы пишем запрос, используем метод GET хотим получить ресурс /tehnologii/protokoli и указываем версию протокола по которой мы хотим работать HTTP 1.1. Так как мы используем версию 1.1 нам необходимо указать заголовок host, доменное имя сервера с которым мы работаем www.zvondozvon.ru, этого вполне достаточно для того чтобы веб-сервер нам ответил. 

HTTP/1.1 200 OK

Server: nginx

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

Content-Length: 5161

 

˂html lang=”ru-RU”˃

˂head˃

…

˂/html˃

Ответ веб-сервера начинается со статуса 200 ok, обработка запроса произошла успешно, также вначале указываются версия протокола, которая используется HTTP 1.1. Затем идут несколько заголовков реализации веб-сервера nginx, тип передаваемой страницы текста html кодировка utf-8, длина страницы 5161 байт, также здесь могут идти другие заголовки, которые вам передал сервер. 

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

Продолжение про протокол HTTP читайте в статье постоянное соединение и кэширование протокола HTTP.

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

Протокол передачи гипертекста — HTTP — Компьютерные сети

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

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

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

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

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

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

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

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

протокол передачи гипертекста — с английского на русский

См. также в других словарях:

• Протокол передачи гипертекста — базирующийся на TCP/IP протокол передачи гипертекста, обеспечивающий доступ к документам на веб узлах. Основная задача протокола состоит в установлении связи с веб сервером и обеспечении доставки HTML страниц веб браузеру клиента. Протокол HTTP:… …   Финансовый словарь

• ПРОТОКОЛ ПЕРЕДАЧИ ГИПЕРТЕКСТА — Базирующийся на TCP/IP протокол передачи гипертекста, обеспечивающий доступ к документам на веб узлах. Основная задача протокола состоит в установлении связи с веб сервером и обеспечении доставки HTML страниц веб браузеру клиента Словарь бизнес… …   Словарь бизнес-терминов

• протокол передачи гипертекста — Протокол передачи файлов, подобный FTP, но со встроенным идентификатором типа передаваемой информации (MIME формат). Главным образом используется в WWW [http://www.webxpert.ru/slovar.html]. [http://www.morepc.ru/dict/] Тематики информационные… …   Справочник технического переводчика

• Протокол передачи гипертекста — HTTP Название: Hypertext Transfer Protocol Уровень (по модели OSI): Прикладной Семейство: TCP/IP Создан в: 1990 г. Порт/ID: 80/TCP Назначение протокола: Доступ к гипертексту, ныне стал универсальным Спецификация: RFC 1945 …   Википедия

• защищенный протокол передачи гипертекста — (МСЭ Т Х.1141). [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN secure hypertext transfer protocolHTTPS …   Справочник технического переводчика

• транспортный протокол передачи гипертекста — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN hypertext transport protocolHTTP …   Справочник технического переводчика

• Протокол передачи данных — Проверить информацию. Необходимо проверить точность фактов и достоверность сведений, изложенных в этой статье. На странице обсуждения должны быть пояснения …   Википедия

• защищенный протокол для передачи гипертекста — S HTTP Безопасный способ передачи информации по WWW. [http://www.rfcmd.ru/glossword/1.8/index.php?a=index&d=4228] Тематики защита информации Синонимы S HTTP EN secure hypertext transfer protocolS HTTP …   Справочник технического переводчика

• Протокол управления передачей / Межсетевой протокол — набор протоколов, разработанный для Интернета и ставший его основой. Передача информации по протоколу TCP/IP состоит из четырех этапов: 1 протокол ТСР: разбиение информации на нумерованные пакеты; 2 протокол IP: передача пакетов получателю; 3… …   Финансовый словарь

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

• простой протокол обнаружения служб — Сеансовый протокол (L5) для объявления узлами сети об обслуживании тех или иных задач. Например, сервер печати может объявить: «я, такой то, предоставляю услуги сетевой печати по прото­колу LPR». Формат пересылаемых данных… …   Справочник технического переводчика

Протокол передачи гипертекста — с русского на все языки

См. также в других словарях:

• Протокол передачи гипертекста — базирующийся на TCP/IP протокол передачи гипертекста, обеспечивающий доступ к документам на веб узлах. Основная задача протокола состоит в установлении связи с веб сервером и обеспечении доставки HTML страниц веб браузеру клиента. Протокол HTTP:… …   Финансовый словарь

• ПРОТОКОЛ ПЕРЕДАЧИ ГИПЕРТЕКСТА — Базирующийся на TCP/IP протокол передачи гипертекста, обеспечивающий доступ к документам на веб узлах. Основная задача протокола состоит в установлении связи с веб сервером и обеспечении доставки HTML страниц веб браузеру клиента Словарь бизнес… …   Словарь бизнес-терминов

• протокол передачи гипертекста — Протокол передачи файлов, подобный FTP, но со встроенным идентификатором типа передаваемой информации (MIME формат). Главным образом используется в WWW [http://www.webxpert.ru/slovar.html]. [http://www.morepc.ru/dict/] Тематики информационные… …   Справочник технического переводчика

• Протокол передачи гипертекста — HTTP Название: Hypertext Transfer Protocol Уровень (по модели OSI): Прикладной Семейство: TCP/IP Создан в: 1990 г. Порт/ID: 80/TCP Назначение протокола: Доступ к гипертексту, ныне стал универсальным Спецификация: RFC 1945 …   Википедия

• защищенный протокол передачи гипертекста — (МСЭ Т Х.1141). [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN secure hypertext transfer protocolHTTPS …   Справочник технического переводчика

• транспортный протокол передачи гипертекста — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN hypertext transport protocolHTTP …   Справочник технического переводчика

• Протокол передачи данных — Проверить информацию. Необходимо проверить точность фактов и достоверность сведений, изложенных в этой статье. На странице обсуждения должны быть пояснения …   Википедия

• защищенный протокол для передачи гипертекста — S HTTP Безопасный способ передачи информации по WWW. [http://www.rfcmd.ru/glossword/1.8/index.php?a=index&d=4228] Тематики защита информации Синонимы S HTTP EN secure hypertext transfer protocolS HTTP …   Справочник технического переводчика

• Протокол управления передачей / Межсетевой протокол — набор протоколов, разработанный для Интернета и ставший его основой. Передача информации по протоколу TCP/IP состоит из четырех этапов: 1 протокол ТСР: разбиение информации на нумерованные пакеты; 2 протокол IP: передача пакетов получателю; 3… …   Финансовый словарь

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

• простой протокол обнаружения служб — Сеансовый протокол (L5) для объявления узлами сети об обслуживании тех или иных задач. Например, сервер печати может объявить: «я, такой то, предоставляю услуги сетевой печати по прото­колу LPR». Формат пересылаемых данных… …   Справочник технического переводчика

Список сетевых протоколов — Википедия

Материал из Википедии — свободной энциклопедии

Здесь представлен неполный список сетевых протоколов, отсортированных по ближайшим им уровням модели Open Systems Interconnection (OSI). Однако, многие из данных протоколов изначально основаны на стеке протоколов TCP/IP и прочих моделях, поэтому они не могут быть однозначно соотнесены с уровнями модели OSI.

• Ethernet
• GFP ITU-T G.7041 Обобщённая процедура разбиения на фреймы
• OTN ITU-T G.709 Оптическая передача данных по сети, также называемая «Оптической оболочкой канала» (Optical Channel Wrapper) или «Цифровой технологией обертывания» (Digital Wrapper Technology)

• ATM Asynchronous Transfer Mode
• Frame relay, упрощенная версия X.25
• MPLS Multi-protocol label switching
• X.25
• ARP Протокол разрешения адреса
• RARP Протокол разрешения обратного адреса

• MTP Message Transfer Part
• NSP Network Service Part

• CLNP Сетевой протокол без установки соединения
• EGP протокол внешнего шлюза (устарел)
• EIGRP Enhanced Interior Gateway Routing Protocol
• ICMP Internet Control Message Protocol
• IGMP Internet Group Management Protocol
• IGRP Interior Gateway Routing Protocol
• IPv4 Internet Protocol version 4
• IPv6 Internet Protocol version 6
• IPsec Internet Protocol Security
• IPX Internetwork Packet Exchange
• SCCP Signalling Connection Control Part
• AppleTalk DDP

Протоколы уровня 3 (управление на сетевом уровне)[править | править код]

• IS-IS Intermediate System-to-Intermediate System
• OSPF Open Shortest Path First
• BGP Border Gateway Protocol
• RIP Routing Information Protocol
• IRDP: Реализация RFC 1256
• Gateway Discovery Protocol (GDP) — протокол, разработанный Cisco, схожий с IRDP

• HIP Протокол идентификации хоста

• AH Аутентификационный заголовок по IP или IPSec
• ESP Encapsulating Security Payload over IP or IPSec
• GRE Generic Routing Encapsulation для туннелирования
• IL Первоначально разработан как транспортный уровень для 9P
• SCTP Stream Control Transmission Protocol
• Sinec h2 для удаленного контроля
• SPX Sequenced Packet Exchange
• TCP Transmission Control Protocol
• UDP User Datagram Protocol

• 9P — протокол распределённой файловой системы, разработанный как часть Plan 9
• NCP NetWare Core Protocol
• NFS — сетевая файловая система
• SMB Server Message Block
• SOCKS «SOCKet Secure»
• L2TP — Layer 2 Tunneling Protocol

Протоколы уровня 6 (уровень представления)[править | править код]

• PPTP — Point-to-Point Tunneling Protocol

• ADC — peer-to-peer-протокол обмена файлами
• AFP, Apple Filing Protocol
• BACnet, Building Automation and Control Network protocol
• BitTorrent — peer-to-peer-протокол обмена файлами
• BOOTP, Bootstrap Protocol
• DIAMETER — протокол аутентификации, авторизации и работы с аккаунтами
• DICOM содержит определение сетевого протокола
• DICT — словарный протокол
• DNS — система доменных имён
• DHCP, Dynamic Host Configuration Protocol
• ED2K — peer-to-peer-протокол обмена файлами
• FTP — протокол передачи файлов
• Finger — протокол, возвращающий информацию о пользователях на удалённом компьютере
• Gnutella — peer-to-peer-протокол скачивания файлов
• Gopher — иерархический протокол на основе гиперссылок
• HTTP, Hypertext Transfer Protocol
• IMAP, Internet Message Access Protocol
• IRC — протокол для чата
• ISUP, ISDN User Part
• XMPP — протокол мгновенного обмена сообщениями
• LDAP Lightweight Directory Access Protocol
• MIME, Multipurpose Internet Mail Extensions
• MSNP, Microsoft Notification Protocol (используется в Windows Live Messenger)
• MAP, Mobile Application Part
• NetBIOS — протокол общего пользования файлами и разрешения имен — основа обмена файлами в Windows.
• NNTP — сетевой протокол передачи новостей
• NTP — сетевой протокол времени
• NTCIP, National Transportation Communications for Intelligent Transportation System Protocol
• POP3 — почтовый протокол версии 3
• RADIUS — протокол аутентификации, авторизации и работы с аккаунтами
• Rlogin — протокол удаленного входа в UNIX
• rsync — протокол передачи файлов для резервного копирования, копирования и зеркалирования
• RTP, Real-time Transport Protocol
• RTSP, Real-time Transport Streaming Protocol
• SSH, Secure Shell
• SISNAPI, Siebel Internet Session Network API
• SIP, Session Initiation Protocol, сигнальный протокол
• SMTP, Simple Mail Transfer Protocol
• SNMP, Simple Network Management Protocol
• SOAP, Simple Object Access Protocol
• STUN, Session Traversal Utilities for NAT
• TUP, Telephone User Part
• Telnet — протокол удаленного доступа к терминалу
• TCAP, Transaction Capabilities Application Part
• TFTP, Trivial File Transfer Protocol, простой протокол передачи файлов
• WebDAV, Web Distributed Authoring and Versioning
• DSM CC Digital Storage Media Command and Control

ASN.1