База знаний по HTTP и WWW

Спасибо, что Вы с нами и с BИKИ. 

Все о HTTP

Все о WWW

Что есть HTTP

HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов в формате HTML, в настоящий момент используется для передачи произвольных данных). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

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

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

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

HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

 

 

Программное обеспечение

Всё программное обеспечение для работы с протоколом HTTP разделяется на три большие категории:

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

Для отличия конечных серверов от прокси в официальной документации используется термин «исходный сервер» (англ. origin server). Один и тот же программный продукт может одновременно выполнять функции клиента, сервера или посредника в зависимости от поставленных задач. В спецификациях протокола HTTP подробно описывается поведение для каждой из этих ролей.

Клиенты

Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Для просмотра сохранённого содержимого сайтов на компьютере без соединения с Интернетом были придуманы офлайн-браузеры. При нестабильном соединении для загрузки больших файлов используются менеджеры закачек. Они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. Виртуальные атласы, такие как Google Планета Земля и NASA World Wind, тоже используют HTTP.

Нередко протокол HTTP используется программами для скачивания обновлений.

Целый комплекс программ-роботов используется в поисковых системах Интернета. Среди них веб-пауки (краулеры), которые производят проход по гиперссылкам, составляют базу данных ресурсов серверов и сохраняют их содержимое для дальнейшего анализа.

Исходные серверы

Основные реализации: Apache, Internet Information Services (IIS), nginx, Google Web Server, lighttpd.

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

Основные реализации: Squid, UserGate, Multiproxy, Naviscope, nginx.

История развития

HTTP/0.9
HTTP был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация протокола привела к упорядочению правил взаимодействия между клиентами и серверами HTTP, а также чёткому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.
HTTP/1.0
В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0.
HTTP/1.1
Текущая версия протокола, принята в июне 1999 года[2]. Новым в этой версии был режим «постоянного соединения»: TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможной более простую организацию виртуального хостинга.
HTTP/2 
11 февраля 2015 года опубликованы финальные версии черновика следующей версии протокола. В отличие от предыдущих версий, протокол HTTP/2 является бинарным. Среди ключевых особенностей мультиплексирование запросов, расстановка приоритетов для запросов, сжатия заголовков, загрузка нескольких элементов параллельно, посредством одного TCP соединения, поддержка проактивных push-уведомлений со стороны сервера.

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

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

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

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.

Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.

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

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

GET URI — для версии протокола 0.9.
Метод URI HTTP/Версия — для остальных версий.

Здесь:

  • Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.
  • URI определяет путь к запрашиваемому документу.
  • Версия (англ. Version) — пара разделённых точкой цифр. Например: 1.0

Чтобы запросить страницу данной статьи, клиент должен передать строку (задан всего один заголовок):

GET /wiki/HTTP HTTP/1.0
Host: ru.wikipedia.org

Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение, где:

  • Версия — пара разделённых точкой цифр как в запросе.
  • Код состояния (англ. Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента.
  • Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:

HTTP/1.0 200 OK

Методы

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

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

Кроме методов GET и HEAD, часто применяется метод POST.

OPTIONS

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

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

Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Результат выполнения этого метода не кэшируется.

GET

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

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[4]

Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно.

HEAD

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.

POST

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

В отличие от метода GET, метод POST не считается идемпотентным[4], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться очередная копия этого комментария).

При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

PUT

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурс, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

PATCH

Аналогично PUT, но применяется только к фрагменту ресурса.

DELETE

Удаляет указанный ресурс.

TRACE

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

CONNECT

Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищённого SSL-соединения через нешифрованный прокси.

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

Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трёх цифр[5]. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

201 Webpage Created
403 Access allowed only for registered users
507 Insufficient Storage

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

В настоящее время выделено пять классов кодов состояния.

1xx Informational («Информационный»)

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

2xx Success («Успех»)

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

3xx Redirection («Перенаправление»)

Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

4xx Client Error («Ошибка клиента»)

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

5xx Server Error («Ошибка сервера»)

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

Заголовки

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

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

Server: Apache/2.2.11 (Win32) PHP/5.3.0
Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
Content-Type: text/plain; charset=windows-1251
Content-Language: ru

В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до первого двоеточия, называется именем (англ. name), а что после неё — значением (англ. value).

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

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

Именно в таком порядке рекомендуется посылать заголовки получателю.

Все необходимые для функционирования HTTP заголовки описаны в основных RFC. Если не хватает существующих, то можно вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией Microsoft для расширения WebDAV.

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

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

message-body = entity-body
| <entity-body закодировано согласно
Transfer-Encoding>

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

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

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

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

Примеры диалогов HTTP

Обычный GET-запрос

Запрос клиента:

GET /wiki/страница HTTP/1.1
Host: ru.wikipedia.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close
(пустая строка)  

Ответ сервера:

HTTP/1.1 200 OK
Date: Wed, 11 Feb 2009 11:20:59 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
(пустая строка)
(далее следует запрошенная страница в HTML)

Аналогично выглядит ответ 203. Что существенно, непосредственно запрашиваемые данные отделены от HTTP-заголовков с помощью CRLF CRLF (двух переводов строки).

Перенаправления

Предположим, что у вымышленной компании Example Corp. есть основной сайт по адресу http://example.com и домен-псевдоним example.org. Клиент посылает запрос страницы «О компании» на вторичный домен (часть заголовков опущена):

GET /about.html HTTP/1.1
Host: example.org
User-Agent: MyLonelyBrowser/5.0

Так как домен example.org не является основным и компания не собирается в будущем его использовать в других целях, их сервер вернёт код для постоянного перенаправления, указав в заголовке Location целевой URL:

HTTP/1.x 301 Moved Permanently
Location: http://example.com/about.html#contacts
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.4
Content-Type: text/html; charset=windows-1251
Content-Length: 110
(пустая строка)
<html><body><a href="http://example.com/about.html#contacts">Click here</a></body></html>

В заголовке Location можно указывать фрагменты как в данном примере. Браузер не указал фрагмент в запросе, так как его интересует весь документ. Но он автоматически прокрутит страницу до фрагмента «contacts», как только загрузит её. В тело ответа также был помещён короткий HTML-документ со ссылкой, с помощью которой посетитель попадёт на целевую страницу, если браузер не перейдёт на неё автоматически. Заголовок Content-Type содержит характеристики именно этого HTML-пояснения, а не документа, который находится по целевому URI.

Допустим, эта же компания Example Corp. имеет несколько региональных представительств по всему миру. И для каждого представительства у них есть сайт с соответствующим ccTLD. Запрос главной страницы основного сайта example.com может выглядеть так:

GET / HTTP/1.1
Host: example.com
User-Agent: MyLonelyBrowser/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7

Сервер принял во внимание заголовок Accept-Language и сформировал ответ с временным перенаправлением на российский сервер example.ru, указав его адрес в заголовке Location:

HTTP/1.x 302 Found
Location: http://example.ru/
Cache-Control: private
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.6
Content-Type: text/html; charset=windows-1251
Content-Length: 82
(пустая строка)
<html><body><a href="http://example.ru">Example Corp.</a></body></html>

Обратите внимание на заголовок Cache-Control. Значение «private» сообщает остальным серверам (в первую очередь прокси) что ответ может кэшироваться только на стороне клиента. В противном случае не исключено, что следующие посетители из других стран будут переходить всё время не в своё представительство.

Для перенаправления также используются коды ответа 303 (See Other) и 307 (Temporary Redirect).

Докачка и фрагментарное скачивание

Допустим, вымышленная организация предлагает скачать с сайта видео прошедшей конференции по адресу http://example.org/conf-2009.avi объёмом примерно 160 МБ. Рассмотрим, как происходит докачивание этого файла в случае сбоя и как менеджер закачек организовал бы многопоточную загрузку нескольких фрагментов.

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

GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://example.org/

Заголовок Referer указывает, что файл был запрошен с главной страницы сайта. Менеджеры закачек обычно тоже его указывают, чтобы эмулировать переход со страницы сайта. Без него сервер может ответить 403 (Access Forbidden), если не допускаются запросы с других сайтов. В нашем случае сервер вернул успешный ответ:

HTTP/1.1 200 OK
Date: Thu, 19 Feb 2009 12:27:04 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Content-Type: video/x-msvideo
Content-Length: 160993792
Accept-Ranges: bytes
Connection: close
(пустая строка)
(двоичное содержимое всего файла)

Заголовок Accept-Ranges информирует клиента о том, что он может запрашивать у сервера фрагменты, указывая их смещения от начала файла в байтах. Если этот заголовок отсутствует, то клиент может предупредить пользователя, что докачать файл, скорее всего, не удастся. Исходя из значения заголовка Content-Length, менеджер закачек поделит весь объём на равные фрагменты и запросит их по отдельности, организовав несколько потоков. Если сервер не укажет размер, то клиенту параллельное скачивание реализовать не удастся, но при этом он сможет докачивать файл, пока сервер не ответит 416 (Requested Range Not Satisfiable).

Допустим, на 84-м мегабайте соединение с Интернетом прервалось и процесс загрузки приостановился. Когда соединение с Интернетом было восстановлено, менеджер закачек автоматически послал новый запрос на сервер, но с указанием выдать содержимое с 84-го мегабайта:

GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Range: bytes=88080384-
Referer: http://example.org/

Сервер не обязан помнить, какие и от кого запросы были до этого, и поэтому клиент снова вставил заголовок Referer, как будто это его самый первый запрос. Указанное значение заголовка Range говорит серверу — «выдай содержимое от 88080384-го байта до самого конца». В связи с этим сервер вернёт ответ:

HTTP/1.1 206 Partial Content
Date: Thu, 19 Feb 2009 12:27:08 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Accept-Ranges: bytes
Content-Range: bytes 88080384-160993791/160993792
Content-Length: 72913408
Connection: close
Content-Type: video/x-msvideo
(пустая строка)
(двоичное содержимое от 84-го мегабайта)

Заголовок Accept-Ranges здесь уже не обязателен, так как клиент уже знает об этой возможности сервера. О том, что передаётся фрагмент, клиент узнаёт по коду 206 (Partial Content). В заголовке Content-Range содержится информация о данном фрагменте: номера начального и конечного байта, а после слэша — суммарный объём всего файла в байтах. Обратите внимание на заголовок Content-Length — в нём указывается размер тела сообщения, то есть передаваемого фрагмента. Если сервер вернёт несколько фрагментов, то Content-Length будет содержать их суммарный объём.

Теперь вернёмся к менеджеру закачек. Зная суммарный объём файла «conf-2009.avi», программа поделила его на 10 равных секций. Начальную менеджер загрузит при самом первом запросе, прервав соединение как только дойдёт до начала второго. Остальные он запросит отдельно. Например, 4-я секция будет запрошена со следующими заголовками (часть заголовков опущена — см. полный пример выше):

GET /conf-2009.avi HTTP/1.0
Range: bytes=64397516-80496894

Ответ сервера в этом случае будет следующим (часть заголовков опущена — см. полный пример выше):

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 64397516-80496894/160993792
Content-Length: 16099379
(пустая строка)
(двоичное содержимое 4-й части)

Если подобный запрос отправить серверу, который не поддерживает фрагменты, то он вернёт стандартный ответ 200 (OK) как было показано в самом начале, но без заголовка Accept-Ranges.

См. также частичные GET, байтовые диапазоны, ответ 206, ответ 416.

Основные механизмы протокола

Частичные GET

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

Для получения фрагмента клиент посылает серверу запрос с заголовком Range, указывая в нём необходимые байтовые диапазоны. Если сервер не понимает частичные запросы (игнорирует заголовок Range), то он вернёт всё содержимое со статусом 200, как и при обычном GET. В случае успешного выполнения сервер возвращает вместо кода 200 ответ со статусом 206 (Partial Content), включая в ответ заголовок Content-Range. Сами фрагменты могут быть переданы двумя способами:

  • В ответе помещается заголовок Content-Range с указанием байтовых диапазонов. В соответствии с ними фрагменты последовательно помещаются в основное тело. При этом Content-Length должен соответствовать суммарному объёму всего тела.
  • Сервер указывает медиатип multipart/byteranges для основного содержимого и передаёт фрагменты, указывая соответствующий Content-Range для каждого элемента (см. также Множественное содержимое).

Условные GET

Метод GET изменяется на «условный GET», если сообщение запроса включает в себя поле заголовка «If-Modified-Since». В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты, указанной в заголовке «If-Modified-Since». Алгоритм определения этого включает в себя следующие случаи:

  • Если код статуса ответа на запрос будет отличаться от «200 OK», или дата, указанная в поле заголовка «If-Modified-Since» некорректна, ответ будет идентичен ответу на обычный запрос GET.
  • Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET.
  • Если ресурс не изменялся после указанной даты, сервер вернет код статуса «304 Not Modified».

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

Согласование содержимого

Согласование содержимого (англ. Content Negotiation) — механизм автоматического определения необходимого ресурса при наличии нескольких разнотипных версий документа. Субъектами согласования могут быть не только ресурсы сервера, но и возвращаемые страницы с сообщениями об ошибках (403, 404 и т. п.).

Различают два основных типа согласований:

  • Управляемое сервером (англ. Server-Driven).
  • Управляемое клиентом (англ. Agent-Driven).

Одновременно могут быть использованы оба типа или каждый из них по отдельности.

В основной спецификации по протоколу (RFC 2616) также выделяется так называемое прозрачное согласование (англ. Transparent Negotiation) как предпочтительный вариант комбинирования обоих типов. Последний механизм не следует путать с независимой технологией Transparent Content Negotiation (TCN, «Прозрачное согласование содержимого», см. RFC 2295), которая не является частью протокола HTTP, но может использоваться с ним. У обоих существенное различие в принципе работы и самом значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN прозрачность означает доступность полного списка вариантов ресурса для всех участников процесса доставки данных.

Управляемое сервером

При наличии нескольких версий ресурса сервер может анализировать заголовки запроса клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном анализируются заголовки Accept, Accept-Charset, Accept-Encoding, Accept-Languages и User-Agent. Серверу желательно включать в ответ заголовок Vary с указанием параметров, по которым различается содержимое по запрашиваемому URI.

Географическое положение клиента можно определить по удалённому IP-адресу. Это возможно за счёт того что IP-адреса, как и доменные имена, регистрируются на конкретного человека или организацию. При регистрации указывается регион, в котором будет использоваться желаемое адресное пространство. Эти данные общедоступны, и в Интернете можно найти соответствующие свободно распространяемые базы данных и готовые программные модули для работы с ними (следует ориентироваться на ключевые слова «Geo IP»).

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

Управляемое сервером согласование имеет несколько недостатков:

  • Сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, но не может знать точно, что именно нужно в данный момент (например, версия на русском языке или английском).
  • Заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами — мало. Из-за этого оборудование испытывает избыточную нагрузку.
  • Общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на идентичные запросы от разных пользователей.
  • Передача заголовков Accept также может раскрывать некоторые сведения о его предпочтениях, таких как используемые языки, браузер, кодировка.

Управляемое клиентом

В данном случае тип содержимого определяется только на стороне клиента. Для этого сервер возвращает в ответе с кодом состояния 300 (Multiple Choices) или 406 (Not Acceptable) список вариантов, среди которых пользователь выбирает подходящий. Управляемое клиентом согласование хорошо, когда содержимое различается по самым частым параметрам (например, по языку и кодировке) и используется публичный кэш.

Основной недостаток — лишняя нагрузка, так как приходится делать дополнительный запрос, чтобы получить нужное содержимое.

Прозрачное согласование

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

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

Множественное содержимое

Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но в виде иерархии с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиатипы multipart/*. Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиатипом). Если получателю не известно как работать с типом, то он обрабатывает его так же, как multipart/mixed.

Параметр boundary означает разделитель между различными типами передаваемых сообщений. Например передаваемый из формы параметр DestAddress передает значение адреса e-mail, а следующий за ним элемент AttachedFile1 отправляет двоичное содержимое изображения формата .jpg

Со стороны сервера сообщения со множественным содержимым могут посылаться в ответ на частичные GET при запросе нескольких фрагментов ресурса. В этом случае используется медиатип multipart/byteranges.

Со стороны клиента при отправке HTML-формы чаще всего пользуются методом POST. Типичный пример: страницы отправки электронных писем со вложенными файлами. При отправке такого письма браузер формирует сообщение типа multipart/form-data, интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес получателя, сам текст и вложенные файлы:

POST /send-message.html HTTP/1.1
Host: mail.example.com
Referer: http://mail.example.com/send-message.html
User-Agent: BrowserForDummies/4.67b
Content-Type: multipart/form-data; boundary="Asrf456BGe4h"
Content-Length: (суммарный объём, включая дочерние заголовки)
Connection: keep-alive
Keep-Alive: 300
(пустая строка)
(отсутствующая преамбула)
--Asrf456BGe4h
Content-Disposition: form-data; name="DestAddress"
(пустая строка)
brutal-vasya@example.com
--Asrf456BGe4h
Content-Disposition: form-data; name="MessageTitle"
(пустая строка)
Я негодую
--Asrf456BGe4h
Content-Disposition: form-data; name="MessageText"
(пустая строка)
Привет, Василий! Твой ручной лев, которого ты оставил
у меня на прошлой неделе, разодрал весь мой диван.
Пожалуйста, забери его скорее!
Во вложении две фотки с последствиями.
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержимое первой фотографии)
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержимое второй фотографии)
--Asrf456BGe4h--
(отсутствующий эпилог)

В примере в заголовках Content-Disposition параметр name соответствует атрибуту name в HTML-тегах <INPUT> и <TEXTAREA>. Параметр filename равен исходному имени файла на компьютере пользователя. Более подробная информация о формировании HTML-форм и вложении файлов в RFC 1867.

Особенности протокола

Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.

При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов — в простейшем случае картинки в разных форматах).

Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.

Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это коммерциализировало Интернет, появились компании, основным полем деятельности которых стало предоставление доступа в Интернет (провайдеры) и создание сайтов.

См. также

 
В Викисловаре есть статья «HTTP»
  • Список кодов состояния HTTP
  • Заголовки HTTP (список):
    • Referer
    • User-Agent
  • Cookie
  • Дайджест-аутентификация
  • HTTP/2

Примечания

  1. Объём HTTP-трафика впервые превысил P2P // Компьюлента, 22 июня 2007 (Официальный документ от Ellacoya Networks).
  2. Впервые спецификация HTTP/1.1 была опубликована в январе 1997 RFC 2068; в современной версии RFC 2616 исправлены опечатки, местами улучшены терминология и оформление. Также разъяснено допустимое поведение клиента (браузера), сервера и прокси-серверов в некоторых сомнительных ситуациях. То есть версия 1.1 появилась всё-таки в 1997 году.
  3. HTTP/2 Draft
  4. 1 2 HTTP/1.1: Method Definitions (англ.). Архивировано из первоисточника 24 июня 2012.
  5. См. первое предложение раздела «6.1.1 Status Code and Reason Phrase» в RFC 2068. На стр. 40 есть также объявление в формате расширенной БНФ-формы (Augmented BNF (англ.)) «extension-code = 3DIGIT» для кодов расширений.

Ссылки

  • Логотип Викисклада HTTP: тематические медиафайлы на Викискладе
  • RFC 1945 — HTTP/1.0 (Май 1996), включает версию 0.9
  • RFC 2616 — HTTP/1.1 (Июнь 1999); см. также в виде PostScript и PDF;
  • httpbis-http2-17 — HTTP/2 (11 февраля 2015) Окончательная спецификация
  • «Разъяснение http/2» Даниэль Штенберг (PDF) (рус.)
  • Найденные опечатки в спецификации HTTP/1.1
  • Перевод спецификации HTTP/1.1
  • Первоначальный HTTP 0.9 Тима Бернерса-Ли (написан и издан в 1991 году)
  • Ранняя версия исходного черновика версии 1.0 1992 года Тима Бернерса-Ли
  • Пример последовательности HTTP-обмена между браузером и сервером
  • Функционирование HTTP-сервера

 

 

Что есть WWW

Всеми́рная паути́на (англ. World Wide Web) — распределённая система, предоставляющая доступ к связанным между собой документам, расположенным на различных компьютерах, подключённых к Интернету. Для обозначения Всемирной паутины также используют слово веб (англ. web «паутина») и аббревиатуру WWW.

Всемирную паутину образуют сотни миллионов веб-серверов. Большинство ресурсов Всемирной паутины основаны на технологии гипертекста. Гипертекстовые документы, размещаемые во Всемирной паутине, называются веб-страницами. Несколько веб-страниц, объединённых общей темой, дизайном, а также связанных между собой ссылками и обычно находящихся на одном и том же веб-сервере, называются веб-сайтом. Для загрузки и просмотра веб-страниц используются специальные программы — браузеры (англ. browser).

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

 

 

Структура и принципы Всемирной паутины

 
Всемирная паутина вокруг Википедии

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

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

Для создания, хранения и отображения гипертекста во Всемирной паутине традиционно используется язык HTML (англ. HyperText Markup Language «язык разметки гипертекста»). Работа по созданию (разметке) гипертекстовых документов называется вёрсткой, она делается веб-мастером либо отдельным специалистом по разметке — верстальщиком. После HTML-разметки получившийся документ сохраняется в файл, и такие HTML-файлы являются основным типом ресурсов Всемирной паутины. После того, как HTML-файл становится доступен веб-серверу, его начинают называть «веб-страницей». Набор веб-страниц образует веб-сайт.

Гипертекст веб-страниц содержит гиперссылки. Гиперссылки помогают пользователям Всемирной паутины легко перемещаться между ресурсами (файлами) вне зависимости от того, находятся ресурсы на локальном компьютере или на удалённом сервере. Для определения местонахождения ресурсов во Всемирной паутине используются единообразные локаторы ресурсов URL (англ. Uniform Resource Locator). Например, полный URL главной страницы русского раздела Википедии выглядит так: http://ru.wikipedia.org/wiki/Заглавная_страница. Подобные URL-локаторы сочетают в себе технологию идентификации URI (англ. Uniform Resource Identifier «единообразный идентификатор ресурса») и систему доменных имён DNS (англ. Domain Name System). Доменное имя (в данном случае ru.wikipedia.org) в составе URL обозначает компьютер (точнее — один из его сетевых интерфейсов), который исполняет код нужного веб-сервера. URL текущей страницы обычно можно увидеть в адресной строке браузера, хотя многие современные браузеры предпочитают по умолчанию показывать лишь доменное имя текущего сайта.

Технологии Всемирной паутины

Для улучшения визуального восприятия веба стала широко применяться технология CSS, которая позволяет задавать единые стили оформления для множества веб-страниц. Ещё одно нововведение, на которое стоит обратить внимание, — система обозначения ресурсов URN (англ. Uniform Resource Name).

Популярная концепция развития Всемирной паутины — создание семантической паутины. Семантическая паутина — это надстройка над существующей Всемирной паутиной, которая призвана сделать размещённую в сети информацию более понятной для компьютеров. Семантическая паутина — это концепция сети, в которой каждый ресурс на человеческом языке был бы снабжён описанием, понятным компьютеру. Семантическая паутина открывает доступ к чётко структурированной информации для любых приложений, независимо от платформы и независимо от языков программирования. Программы смогут сами находить нужные ресурсы, обрабатывать информацию, классифицировать данные, выявлять логические связи, делать выводы и даже принимать решения на основе этих выводов. При широком распространении и грамотном внедрении семантическая паутина может вызвать революцию в Интернете. Для создания понятного компьютеру описания ресурса, в семантической паутине используется формат RDF (англ. Resource Description Framework), который основан на синтаксисе XML и использует идентификаторы URI для обозначения ресурсов. Новинки в этой области — это RDFS (англ. RDF Schema) и SPARQL (англ. Protocol And RDF Query Language) (произносится как «спа́ркл»), новый язык запросов для быстрого доступа к данным RDF.

История Всемирной паутины

 
Так выглядит самый первый веб-сервер, разработанный Тимом Бернерсом-Ли

Изобретателями всемирной паутины считаются Тим Бернерс-Ли и, в меньшей степени, Роберт Кайо. Тим Бернерс-Ли является автором технологий HTTP, URI/URL и HTML. В 1980 году он работал в Европейском совете по ядерным исследованиям (фр. conseil européen pour la recherche nucléaire, CERN) консультантом по программному обеспечению. Именно там, в Женеве (Швейцария), он для собственных нужд написал программу «Энквайр» (англ. Enquire, можно вольно перевести как «Дознаватель»), которая использовала случайные ассоциации для хранения данных и заложила концептуальную основу для Всемирной паутины.

 
Развитие информационных технологий

В 1989 году, работая в CERN над внутренней сетью организации, Тим Бернерс-Ли предложил глобальный гипертекстовый проект, теперь известный как «Всемирная паутина». Проект подразумевал публикацию гипертекстовых документов, связанных между собой гиперссылками, что облегчило бы поиск и консолидацию информации для учёных CERN. Для осуществления проекта Тимом Бернерсом-Ли (совместно с его помощниками) были изобретены идентификаторы URI, протокол HTTP и язык HTML. Это технологии, без которых уже нельзя себе представить современный Интернет. В период с 1991 по 1993 год Бернерс-Ли усовершенствовал технические спецификации этих стандартов и опубликовал их. Но, всё же, официально годом рождения Всемирной паутины нужно считать 1989 год.

В рамках проекта Бернерс-Ли написал первый в мире веб-сервер, называвшийся «httpd», и первый в мире гипертекстовый веб-браузер, называвшийся «WorldWideWeb». Этот браузер был одновременно и WYSIWYG-редактором (сокр. от англ. what you see is what you get — что видишь, то и получишь), его разработка была начата в октябре 1990 года, а закончена в декабре того же года. Программа работала в среде NeXTStep и начала распространяться по Интернету летом 1991 года.

Майк Сендал (Mike Sendall) покупает в это время компьютер «NeXT cube» для того, чтобы понять, в чём состоят особенности его архитектуры, и отдает его затем Тиму [Бернерс-Ли]. Благодаря совершенству программной системы «NeXT cube» Тим написал прототип, иллюстрирующий основные положения проекта, за несколько месяцев. Это был впечатляющий результат: прототип предлагал пользователям, кроме прочего, такие развитые возможности, как WYSIWYG browsing/authoring!… В течение одной из сессий совместных обсуждений проекта в кафетерии ЦЕРНа мы с Тимом попытались подобрать «цепляющее» название (catching name) для создаваемой системы. Единственное, на чём я настаивал, это чтобы название не было в очередной раз извлечено все из той же греческой мифологии. Тим предложил «world wide web». Все в этом названии мне сразу очень понравилось, только трудно произносится по-французски.

— Robert Cailliau, 2 ноября 1995[1]

Первый в мире веб-сайт был размещён Бернерсом-Ли 6 августа 1991 года на первом веб-сервере доступном по адресу http://info.cern.ch/, (здесь архивная копия). Ресурс определял понятие «Всемирной паутины», содержал инструкции по установке веб-сервера, использования браузера и т. п. Этот сайт также являлся первым в мире интернет-каталогом, потому что позже Тим Бернерс-Ли разместил и поддерживал там список ссылок на другие сайты.

 
Первая фотография во Всемирной паутине — группа Les Horribles Cernettes

На первой фотографии, появившейся во Всемирной паутине, была изображена пародийная филк-группа Les Horribles Cernettes[2]. Тим Бернес-Ли попросил у лидера группы отсканированные фотографии после музыкального фестиваля «CERN hardronic festival».

И всё же теоретические основы веба были заложены гораздо раньше Бернерса-Ли. Ещё в 1945 году Ванна́вер Буш разработал концепцию Memex — вспомогательных механических средств «расширения человеческой памяти». Memex — это устройство, в котором человек хранит все свои книги и записи (а в идеале — и все свои знания, поддающиеся формальному описанию) и которое выдаёт нужную информацию с достаточной скоростью и гибкостью. Оно является расширением и дополнением памяти человека. Бушем было также предсказано всеобъемлющее индексирование текстов и мультимедийных ресурсов с возможностью быстрого поиска необходимой информации. Следующим значительным шагом на пути ко Всемирной паутине было создание гипертекста (термин введён Тедом Нельсоном в 1965 году).

С 1994 года основную работу по развитию Всемирной паутины взял на себя консорциум Всемирной паутины (англ. world wide web consortium, три буквы «W» и «C», W3C), основанный и до сих пор возглавляемый Тимом Бернерсом-Ли. Данный консорциум — организация, разрабатывающая и внедряющая технологические стандарты для Интернета и Всемирной паутины. Миссия W3C: «Полностью раскрыть потенциал Всемирной паутины путём создания протоколов и принципов, гарантирующих долгосрочное развитие Сети». Две другие важнейшие задачи консорциума — обеспечить полную «интернационализа́цию Сети́» и сделать Сеть доступной для людей с ограниченными возможностями.

W3C разрабатывает для Интернета единые принципы и стандарты (называемые «рекомендациями», англ. W3C recommendations), которые затем внедряются производителями программ и оборудования. Таким образом достигается совместимость между программными продуктами и аппаратурой различных компаний, что делает Всемирную сеть более совершенной, универсальной и удобной. Все рекомендации консорциума Всемирной паутины открыты, то есть не защищены патентами и могут внедряться любым человеком без всяких финансовых отчислений консорциуму.

Перспективы развития Всемирной паутины

В настоящее время наметились два направления в развитии Всемирной паутины: семантическая паутина и социальная паутина.

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

В рамках второго направления наработки, являющиеся частью семантической паутины, активно используются в качестве инструментов (RSS и другие форматы веб-каналы, OPML, микроформаты XHTML). Частично семантизированные участки дерева категорий «Википедии» помогают пользователям осознанно перемещаться в информационном пространстве, однако, очень мягкие требования к подкатегориям не дают основания надеяться на расширение таких участков. В связи с этим интерес могут представлять попытки составления атласов Знания.

Существует также популярное понятие Web 2.0, обобщающее сразу несколько направлений развития Всемирной паутины.

Способы активного отображения информации во Всемирной паутине

Представленная в сети информация может быть доступна:

  • только для чтения («пассивно»);
  • для чтения и добавления/изменения («активно»).

К способам активного отображения информации во Всемирной паутине относятся:

  • гостевые книги (англ. guestbook);
  • форумы (англ. forum);
  • чаты (англ. chat);
  • блоги (англ. blog);
  • wiki-проекты;
  • социальные сети (англ. social networking service);
  • системы управления контентом (англ. content management system, англ. CMS).

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

Отчасти информация с сайтов может также быть доступна через речь. В Индии уже началось[3] тестирование системы, делающей текстовое содержимое страниц доступным даже для людей, не умеющих читать и писать.

«World wide web» иногда иронично называют «Wild wild web» («дикий, дикий web») — по аналогии с названием одноименного фильма «Wild wild west» (Дикий, дикий Запад, 1999, США)[4].

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

Для киберпреступников Всемирная паутина стала ключевым способом распространения вредоносного программного обеспечения. Кроме того, под понятие сетевой преступности подпадают кража личных данных, мошенничество, шпионаж и незаконный сбор сведений о тех или иных субъектах или объектах[5]. Веб-уязвимости, по некоторым данным, в настоящее время превосходят по количеству любые традиционные проявления проблем компьютерной безопасности; по оценкам Google, примерно одна из десяти страниц во Всемирной паутине может содержать вредоносный код[6][7][8]. По данным компании Sophos, британского производителя антивирусных решений, большинство кибератак в веб-пространстве совершается со стороны легитимных ресурсов, размещённых по преимуществу в США, Китае и России[9]. Наиболее распространённым видом подобных нападений, по сведениям от той же компании, является SQL-инъекция — злонамеренный ввод прямых запросов к базе данных в текстовые поля на страницах ресурса, что при недостаточном уровне защищённости может привести к раскрытию содержимого БД[10]. Другой распространённой угрозой, использующей возможности HTML и уникальных идентификаторов ресурсов, для сайтов Всемирной паутины является межсайтовое выполнение сценариев (XSS), которое стало возможным с введением технологии JavaScript и набрало обороты в связи с развитием Web 2.0 и Ajax — новые стандарты веб-дизайна поощряли использование интерактивных сценариев[11][12][13]. По оценкам 2008 года, до 70 % всех веб-сайтов в мире были уязвимы для XSS-атак против их пользователей[14].

Предлагаемые решения соответствующих проблем существенно варьируются вплоть до полного противоречия друг другу. Крупные поставщики защитных решений вроде McAfee разрабатывают продукты для оценки информационных систем на предмет их соответствия определённым требованиям, другие игроки рынка (например, Finjan) рекомендуют проводить активное исследование программного кода и вообще всего содержимого в режиме реального времени, вне зависимости от источника данных[5][15]. Есть также мнения, согласно которым предприятия должны воспринимать безопасность как удачную возможность для развития бизнеса, а не как источник расходов; для этого на смену сотням компаний, обеспечивающих защиту информации сегодня, должна прийти немногочисленная группа организаций, которая приводила бы в исполнение инфраструктурную политику постоянного и повсеместного управления цифровыми правами[16][17].

Конфиденциальность

Каждый раз, когда пользовательский компьютер запрашивает у сервера веб-страницу, сервер определяет и, как правило, протоколирует IP-адрес, с которого поступил запрос. Аналогичным образом большинство обозревателей Интернета записывают сведения о посещённых страницах, которые затем можно просмотреть в журнале браузера, а также кэшируют загруженное содержимое для возможного повторного использования. Если при взаимодействии с сервером не используется зашифрованное HTTPS-соединение, запросы и ответы на них передаются через Интернет открытым текстом и могут быть считаны, записаны и просмотрены на промежуточных узлах сети.

Когда веб-страница запрашивает, а пользователь предоставляет определённый объём личных сведений, таких, к примеру, как имя и фамилия либо реальный или электронный адрес, поток данных может быть деанонимизирован и ассоциирован с конкретным человеком. Если веб-сайт использует файлы cookie, поддерживает аутентификацию пользователя или другие технологии отслеживания активности посетителей, то между предыдущими и последующими визитами также может быть установлена взаимосвязь. Таким образом, работающая во Всемирной паутине организация имеет возможность создавать и пополнять профиль конкретного клиента, пользующегося её сайтом (или сайтами). Такой профиль может включать, к примеру, информацию о предпочитаемом отдыхе и развлечениях, потребительских интересах, роде занятий и других демографических показателях. Такие профили представляют существенный интерес для маркетологов, сотрудников рекламных агентств и других специалистов подобного рода. В зависимости от условий обслуживания конкретных сервисов и местных законов такие профили могут продаваться или передаваться третьим сторонам без ведома пользователя.

Раскрытию сведений способствуют также социальные сети, предлагающие участникам самостоятельно изложить определённый объём личных данных о себе. Неосторожное обращение с возможностями таких ресурсов может приводить к попаданию в открытый доступ сведений, которые пользователь предпочел бы скрыть; помимо прочего, такая информация может становиться предметом внимания хулиганов или, более того, киберпреступников. Современные социальные сети предоставляют своим участникам довольно широкий спектр настроек конфиденциальности профиля, однако эти настройки могут быть излишне сложны — в особенности для неопытных пользователей[18].

Распространение


В период с 2005 по 2010 год количество веб-пользователей удвоилось и достигло отметки двух миллиардов[19]. Согласно ранним исследованиям 1998 и 1999 годов, большинство существующих веб-сайтов не индексировались корректно поисковыми системами, а сама веб-сеть оказалась крупнее, чем ожидалось[20][21]. По данным на 2001 год было создано уже более 550 миллионов веб-документов, большинство из которых однако находились в пределах невидимой сети[22]. По данным на 2002 год было создано более 2 миллиардов веб-страниц[23], 56,4 % всего интернет-содержимого было на английском языке, после него шёл немецкий (7.7 %), французский (5.6 %) и японский (4.9 %). Согласно исследованиям, проводимым в конце января 2005 года на 75 разных языках было определено более 11,5 миллиардов веб-страниц, которые были индексированы в открытой сети[24]. А по данным на март 2009 года, количество страниц увеличилось до 25.21 миллиардов[25]. 25 июля 2008 года инженеры программного обеспечения Google Джессе Альперт и Ниссан Хайай объявили, что поисковик Google Search засёк более миллиарда уникальных URL-ссылок[26].

  • В 2011 году в Санкт-Петербурге планировали установить памятник Всемирной паутине. Композиция должна была представлять собой уличную скамейку в виде аббревиатуры WWW с бесплатным доступом в Сеть[27].

См. также

  • Семантическая паутина
  • Глобальная вычислительная сеть
  • Всемирная цифровая библиотека

Примечания

  1. Статья «Web как "следующий шаг" (NextStep) революции персональных компьютеров».
  2. LHC: The first band on the web
  3. IBM разработала голосовой интернет
  4. Ховард М., Лебланк Д. Защищённый код\Пер. с англ. — 2-е изд., испр. — М.: Издательско-торговый дом «Русская редакция», 2005, с. 3 (УДК 004.45, ББК 32Ю973Ю26-018.2, Х68, ISBN 5-7502-0238-0)
  5. 1 2 Ben-Itzhak, Yuval. Infosecurity 2008 – New defence strategy in battle against e-crime, ComputerWeekly, Reed Business Information (18 April 2008). Проверено 20 апреля 2008.
  6. Christey, Steve and Martin, Robert A. Vulnerability Type Distributions in CVE (version 1.1). MITRE Corporation (22 May 2007). Проверено 7 июня 2008. Архивировано из первоисточника 15 апреля 2013.
  7. (April 2008) «Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)» (PDF) (Symantec Corp.) XIII: 1–2. Проверено 11 May 2008.
  8. Google searches web's dark side, BBC News (11 May 2007). Проверено 26 апреля 2008.
  9. Security Threat Report (PDF). Sophos (Q1 2008). Проверено 24 апреля 2008. Архивировано из первоисточника 15 апреля 2013.
  10. Security threat report (PDF). Sophos (July 2008). Проверено 24 августа 2008. Архивировано из первоисточника 15 апреля 2013.
  11. Fogie, Seth, Jeremiah Grossman, Robert Hansen, and Anton Rager. Cross Site Scripting Attacks: XSS Exploits and Defense. — Syngress, Elsevier Science & Technology, 2007. — P. 68–69, 127. — ISBN 1-59749-154-3.
  12. O'Reilly, Tim. What Is Web 2.0 4–5. O'Reilly Media (30 September 2005). Проверено 4 июня 2008. Архивировано из первоисточника 15 апреля 2013.
  13. Ritchie, Paul (March 2007). «The security risks of AJAX/web 2.0 applications» (PDF). Infosecurity (Elsevier). Проверено 6 June 2008.
  14. Berinato, Scott. Software Vulnerability Disclosure: The Chilling Effect, CSO, CXO Media (1 January 2007), стр. 7. Архивировано из первоисточника 18 апреля 2008. Проверено 7 июня 2008.
  15. Prince, Brian. McAfee Governance, Risk and Compliance Business Unit, eWEEK, Ziff Davis Enterprise Holdings (9 April 2008). Проверено 25 апреля 2008.
  16. Preston, Rob. Down To Business: It's Past Time To Elevate The Infosec Conversation, InformationWeek, United Business Media (12 April 2008). Проверено 25 апреля 2008.
  17. Claburn, Thomas. RSA's Coviello Predicts Security Consolidation, InformationWeek, United Business Media (6 February 2007). Проверено 25 апреля 2008.
  18. boyd, danah; Hargittai, Eszter (July 2010). «Facebook privacy settings: Who cares?». First Monday (University of Illinois at Chicago) 15 (8).
  19. Lynn, Jonathan. Internet users to exceed 2 billion ..., Reuters (19 October 2010). Проверено 9 февраля 2011.
  20. S. Lawrence, C.L. Giles, "Searching the World Wide Web, " Science, 280(5360), 98-100, 1998.
  21. S. Lawrence, C.L. Giles, "Accessibility of Information on the Web, " Nature, 400, 107—109, 1999.
  22. The 'Deep' Web: Surfacing Hidden Value. Brightplanet.com. Проверено 27 июля 2009. Архивировано из первоисточника 4 апреля 2008.
  23. Distribution of languages on the Internet. Netz-tipp.de. Проверено 27 июля 2009. Архивировано из первоисточника 24 мая 2013.
  24. Alessio Signorini. Indexable Web Size. Cs.uiowa.edu. Проверено 27 июля 2009. Архивировано из первоисточника 24 мая 2013.
  25. The size of the World Wide Web. Worldwidewebsize.com. Проверено 27 июля 2009. Архивировано из первоисточника 24 мая 2013.
  26. Alpert, Jesse; Hajaj, Nissan. We knew the web was big.... The Official Google Blog (25 июля 2008). Архивировано из первоисточника 24 мая 2013.
  27. Памятник Интернету установят в Санкт-Петербурге

Литература

  • Филдинг, Р.; Геттис, Дж.; Могул, Дж.; Фристик, Г.; Мазинтер, Л.; Лич, П.; Бернерс-Ли, Т. (Июнь 1999). «Hypertext Transfer Protocol — http://1.1» (Information Sciences Institute).
  • Бернерс-Ли, Тим; Брэй, Тим; Конноли, Дэн; Коттон, Пол; Филдинг, Рой; Джекл, Марио; Лилли, Крис; Мендельсон, Ной; Оркард, Дэвид; Уолш, Норман; Уиллиамс, Стюарт (Декабрь 15, 2004). «Architecture of the World Wide Web, Volume One» (W3C).
  • Поло, Лучано. World Wide Web Technology Architecture: A Conceptual Analysis. New Devices (2003). Проверено Июль 31 2005. Архивировано из первоисточника 24 августа 2011.

Ссылки

  • Официальный сайт Консорциума Всемирной паутины (World Wide Web Consortium (W3C))  (англ.)
  • Tim Berners-Lee, Mark Fischetti. Плетя паутину: истоки и будущее Всемирной паутины = Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web. — New York: HarperCollins Publishers (англ.). — 256 p. — ISBN 0-06-251587-X, ISBN 978-0-06-251587-2.  (англ.)
  • Историческое предложение Тима Бернерса-Ли для CERN
  • Первый в мире веб-сайт (архив)
  • Эволюция Веба (интерактивное представление)
  • The BBC Standards and Guidelines for Mobile Accessibility
Другие организации, занимающиеся развитием Всемирной паутины и Интернета в целом
  • The Internet Engineering Task Force, IETF
  • Internet Society, ISOC
  • International Organization for Standardization, ISO
  • Web Standards Group, WSG
  • The Web Standards Project
  • Unicode Organization
  • The Semantic Web Community Portal

 

И, наконец, что есть СНИППЕТ, дорогие товарищи.