… Быть Богом (история протокола HTTP) [RC1]

Сейчас никого не удивишь просмотром фильмов через интернет. Все новинки появляются там http://useunix.ru/wp-admin/post.php?action=trash&post=1562&_wpnonce=e92b0a1c40почти в одно время с их премьерами. Телевизор отошёл на второй план — и мы получаем новости в сети. Некоторые нашли здесь работу. Кто-то покупает одежду в online-магазинах. И почти каждый владелец компьютера общается по сети со своими друзьями.

В интернете есть всё. Есть своя реальность, свой мир.

Как и реальный мир, этот был не сразу. Как и в реальном, всё получалось не с первого раза… Трудно быть Богом!

In a galaxy far, far away…

«Когда мы были ламеры и шкеты,
И музыка была — сплошное ретро,
А игры занимали пол-дискеты
И памяти четыре миллиметра.»

Никита Гургуц, «Баллада о правильных играх»

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

В таком научном центре (CERN) в далёком 1980-ом и работал «консультантом по программному обеспечению» (anykey’щик по-сути) Тим Беренс Ли. Будучи человеком склонным к творчеству и эксперименту (в своё время был пойман в Оксфорде за хакерской атакой), он не мог мириться со сложившейся ситуацией (неупорядоченная и вообще никак не связанная куча документов). Тогда Тим Беренс Ли предпринял попытку упорядочить данные. Он придумал концепцию системы обмена документами «Enquire».

Enquire описывает части, из которых состоит система, а также их взаимодействие.

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

Так TimBL описывал Enquire (Вольный пересказ)

Потом Тим Беренс Ли работал 3 года системным архитектором в телекоммуникационной компании. Очевидно, впечатление он о себе оставил в CERN’е хорошее — его снова пригласили, точнее дали гранд на исследование распределённых систем для сбора научных данных.

Вначале было слово… Потом — протокол для его передачи.

HTTP/0.9

Итак, в 1984-ом Тим Бернерс-Ли возвращается в CERN и продолжает свою работу над Enquire. В 1989-ом его работа выливается в рацпредложение.

Многие, обсуждая будущее CERN и непосредственно LHC (да-да, тот самый Большой Адронный Коллайдер), задаются вопросом:

— Это всё хорошо, но как мы будем следить за таким большим проектом?

Рацпредложение Тима Беренса Ли 1989 года дает ответ на такие вопросы. Во-первых, здесь предлагается решение проблемы доступа к информации в CERN. Во-вторых, оно вносит идею связанных информационных систем и сравнивает их с менее гибкими способами поиска информации.

Предложение TimBL по вводу распределённой гипертекстовой системы (Вольный пересказ)

Между делом замечу, что гипертекст — это просто текст со ссылками. Примером может быть книжка с указателем или фразами типа «за более подробным доказательством данного факта обратитесь к книге…».

Основной проблемой, с которой предстояло справиться новой системе, была потеря информации в CERN. Для её решения каждый модуль системы должен был иметь дополнительную информацию, отвечающую на вопросы:

• Где этот модуль используется?
• Кто написал этот код? Где он работает?
• Какие существуют документы об этой концепции?
• Какие лаборатории включены в этот проект?
• Какие системы зависят от этого устройства?
• Какие документы относятся к нему?

Мало того, что вся информация должна «складироваться» и записываться в «амбарной книге», она должна быть удобной, т.е. предоставлять удобный способ доступа к ней. К примеру, удобно рисовать объекты в виде кружков/овалов, а их взаимосвязи — стрелочками/линиями. Теперь применим ту же логику — и вот у нас документы со связями(ссылками)… То есть, тот самый гипертекст.

В 1980 году я написал программу для отслеживания программ, с которыми я работал в системе управления PS. Она позволяла хранить фрагменты информации, а также собирать все воедино. Поиск осуществлялся одним проходом через ссылки с одного листа на другой, как в старой компьютерной игре «Adventure». Это похоже на HyperCard, созданное недавно для Apple Macintosh. Разница в том, что это можно использовать на многопользовательской системе, что позволит многим людям получить доступ к одним и тем же данным.

Всё то же рацпредложение

Так же к системе предъявлялся некоторый список разумных условий:

• Удалённый доступ. Требование вполне естественное: CERN организация немаленькая…
• Неоднородность. Т.е. поддержка машин различных архитектур: в CERN были и VAX’ы, и макинтошы, и юниксы…
• Децентрализованность. Информационные системы появляются отдельно друг от друга, а затем сливаются. Новая система должна позволить существующим системам быть связаны друг с другом без какого-либо централизованного контроля и координации.
• «Частные» ссылки. Нужно предоставить возможность добавлять ссылки на частные и государственные документы.
• «Плюшки».  Хранимые данные должны нормально отображаться в ASCII консоли 24×80. «Плюшки» типа изображений подождут.
• Анализ данных. Так же хотелось реализовать некоторую обработку собранных данных.
• «Живые» ссылки. Ссылка достаточно статична, документ же может быть перемещён.
• Какая-нибудь реализация отслеживания авторских прав и защиты данных.

Стоит отметить, что как раз в то время формировался стандарт гипертекста, так что работа Тима Беренса Ли была кстати.

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

Итак, большая часть из задуманного была реализована:

• Создаётся TCP/IP соединение на указанный пользователем IP/доменное имя, указанный порт (если порт не указан — берём 80ый).
• Запрос отсылается клиентом на сервер в виде ASCII строки, заканчивающейся байтами 0D, 0A (возврат каретки, перевод строки). Хотя, сервер может и не требовать возврат каретки… Сам запрос состоит из слова GET <пробел> и адреса запрашиваемого документа (в адресе нет пробелов). Дальнейшие слова в запросе игнорируются.
• Ответ на запрос — ASCII сообщение в гипертекстовом языке разметки (HTML). Возвращаемый текст может содержать переводы как ODOA, так и просто переводы строк. Так же рекомендуется форматировать под вывод на 80ти колонный интерфейс. Сообщение заканчивается закрытием соединения сервером. Сообщение об ошибке должно передаваться пользователю в понятном виде.
• Отключение происходит либо при нарушении соединения, либо после полной передачи сообщения сервером.

Все соединения независимы, сервер не хранит информацию о них.

Очевидно, что протоколу было куда «расти» (вспомнить хотя бы «плюшки»). Очевидно это было и Тиму Беренсу Ли. Возможно, именно по этой причине протокол носил не номер 1, который присваивался обычно релизам, а 0.9 (beta), как бы говоря, что это пробная версия и следуют улучшения…

HTTP/1.0. Быстрее! Проще! Нагляднее!

Однако, нового протокола долго не было. Аж до 1996-ого года. В мае состоялся выход RFC-1945 — документа, описывающего нововведения. Также была внесена некоторая ясность в терминологический аппарат: введены термины Uniform Resource Identifier (URI), URL (location) и URN (name).

По сравнению с 0.9-ым протоколом появились важные изменения:

• Введена поддержка кеширования, что снизило траффик и нагрузку на сервер.
• Появилась поддержка MIME, следовательно, теперь передать через HTTP можно всё.
• Для совместимости с предыдущим форматом и сервера, и клиенты должны уметь работать с обеими версиями протокола.
• Появилась возможность сжатия.
• Теперь, помимо строки запроса, можно было добавить заголовки: строка запроса, с новой строки заголовки, разделённые переносами строк. А в конце — двойной перенос строки.
• Ответ так же отправлялся теперь с заголовками.
• Появились новые методы запроса: POST и HEAD.

Итак, что же могла версия 1.0 по сравнению с 0.9?

Ну, во-первых, в ней мы ушли от дикого в наше время консольного интерфейса. А это позволяла уже программная база: появился графический Windows 95,  для Unix-подобных систем уже давно существовала X Window System (для Linux так же была GNU-версия). Думаю, те, кому хоть раз приходилось заниматься веб-серфингом с помощью браузера Lynx, должны понять, насколько проще и приятнее стало пользоваться вебом.

Помимо этого, при указании сервером значения «application/octet-stream» в соответствующем поле заголовка сервер мог передавать не только в текстовом формате, но и в бинарном. Последнее новшество позволило передавать по HTTP ещё и картинки.

Одними улучшениями интерфейса Тим Беренс Ли не ограничился. Протокол HTTP является текстовым, что многократно увеличивает объём передаваемой информации. Чтобы уменьшить объем траффика, были введены следующие новшества:

• Возможность сжатия данных (например, gzip’ом)
• Поле запроса If-Modified-Since позволяло запросить документ у сервера (GET’ом) только в том случае, если документ был изменён со времени, указанного пользователем.

Ещё одним недостатком версии 0.9 был его GET. Точнее, сам GET не проблема — со своей задачей передачи запроса на документ серверу он отлично справлялся. Но задачи бывают разные, и GET, к примеру, не сможет передать серверу десяток килобайт данных (есть ограничение на длину строки запроса). Опять же передавать пароль в строке запроса — моветон . Именно для разрешения этих проблем был введён метод POST. Этот метод имел уже помимо заголовков, ещё и «тело» с данными, которые нужно было пересылать серверу. Теперь размер передаваемых данных ограничивался уже более внушительным числом (собственно столько,  сколько указано в настройках сервера).

Также был добавлен служебный запрос HEAD. По своей сути он очень поход на GET, однако сервер отвечает на него только заголовками (тело ответа не отсылает). Таким запросом, к примеру, удобно проверять актуальность документа (If modify).

Ещё один важный момент, который не был реализован в 0.9-ом протоколе, однако заявлялся для исполнения работниками CERN, — защита данных. Реализация появилась в 1.0-ой версии через заголовки: у сервера был запрос «WWW-Authenticate», на что клиент отвечал заголовком «Authorization», передавая пару аккаунт-пароль (разделённые символом «:»), зашифрованные в base64.

Теперь протокол уже выглядит солиднее. По сравнению с 0.9 было добавлено огромное число расширений. Однако, Тим Беренс Ли понимал, что за один день провести переход с 0.9 на 1.0 не удастся, поэтому всё ПО 1.0 должно было поддерживать и предыдущую версию протокола. К сожалению,  нынешним протоколо-стоителям этого понимания не хватает (вспоминается свистопляска AOL во время смены протокола ICQ).

Что ж, по такому протоколу приятно работать… Чего ещё желать? Но прогресс не стоит на месте. Мир меняется, появляются всё новые и новые потребности. Вот уже и 1.0 версия протокола не может их удовлетворить…

7-ой день сотворения. HTTP/1.1

Одна из основных задач была удовлетворить многократно возросший интерес людей к хостингу. Все хотели себе сайт. Да непременно с доменом уровня 2-ого и в корне! Но для этого нужно было отдельно поднимать http сервер, следовательно, держать дополнительного специалиста. В принципе, можно взять одного специалиста на несколько сайтов, держать всё на одной машине с 4-мя сетевыми интерфейсами, можно использовать нестандартные порты… Очевидно, что это неудобно. Но другого решения не было: по протоколу одной паре IP:Порт соответствовал только 1 сайт (dedicated IP hosting).

Протокол версии 1.1 решал эту проблему следующим образом: был введён обязательный заголовок host, в котором клиент писал, на какой сайт (домен) он идёт по этому адресу. То есть, теперь можно было привязать к одному IP на один порт сколько угодно сайтов (доменов), главное, чтобы клиент говорил нам, куда он идёт (shared IP hosting). Этот хостинг более подходит для размещения большого количества небольших проектов.

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

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

Спецификация по HTTP/1.1 была выпущена в 1999-ом году и по сей день остаётся актуальной.

Протокол HTTP перестал быть просто протоколом передачи гипертекста. Он стал универсальным транспортом информации. Функции докачки и фрагментированного скачивания сделали ненужными когда-то многочисленные FTP сервера. Сейчас в качестве средства передачи данных с HTTP может поспорить только Torrent. Все уже привыкли к видео-ресурсам по HTTP, ведутся трансляции матчей в прямом эфире. На сайте, посвящённом музыке, можно прослушать песню перед тем, как её скачать (опять же по HTTP), или даже не скачивать, а слушать по HTTP, к примеру, радио.

Веб-приложения достигли такого уровня, что ими заменяют программы на компьютере (Google Docs заменят OpenOffice в Ubuntu Netbook).

И, похоже, нет предела Web’у, ведь если что-то новое захочется ввести в HTTP — ставь новый заголовок, учи сервер и клиент обрабатывать его и всё… Кто не знает как его обрабатывать — просто проигнорируют, что даёт полную совместимость с предыдущим вариантом.

Что день грядущий нам готовит?

В 1999-ом, когда разрабатывался HTTP/1.1, не было огромных ресурсов подобных facebook, google, youtube. Поэтому не было и проблемы, которая стоит довольно остро в наше время. В HTTP нет поддержки распределённости. Протокол разрабатывался для решения задач, решение которых не должно занимать много времени (обработка запроса, вёрстка).

Для решения этой проблемы в 1998-ом году консорциумом WWW был предложен протокол HTTP-NG (Next Generation) — объектно-ориентированный протокол передачи гипертекста. Эта идея была высоко оценена специалистами по распределённым вычислениям, однако данный протокол до сих пор не запущен. Возможно, и не будет никогда использоваться: высоко-нагруженные веб-проекты уже давно научились перераспределять потоки данных и нагрузку между сотнями серверов.

Кстати, так же было в своё время и с поддержкой сессий… Просто ввели дополнительный «костыль» — cookies. Почти всегда проще доделать, чем переделывать всё с нуля.

Протокол HTTP и вообще Web давно стали синонимами Internet’а. Именно  они являются передним краем развития IT. Сей факт лишь ещё раз доказывает нам древнее утверждение «кто владеет информацией — тот владеет миром». А гипертекст — есть ничто иное, как «связанная» информация.

«Живи долго и процветай!»