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 – ставь новый заголовок, учи сервер и клиент обрабатывать его и всё… Кто не знает как его обрабатывать – просто проигнорируют, что даёт полную совместимость с предыдущим вариантом.
Как убедить Гермеса посылать бандероли через HTTP.
К 1.1ой версии протокола было замечено, что размеры файлов, передаваемые через HTTP становились всё больше и больше. Этот факт дал пищу для ума W3C. Размышления на данную тему привели организацию к концепции диапазонов. То есть клиент должен уметь работать с объектами не только как с некими монолитами, но как с набором байт. Точнее, с диапазоном байт.
Для того, чтобы запросить диапазон байт, клиент посылает заголовок Range, с некоторыми параметрами. В параметрах, к примеру, можно указать с какого по какой байт хочет выкачать клиент файл. Чаще всего используется запрос на скачивание с определённого бита. Оно и понятно: если произошёл разрыв соединения, то нам известно сколько у нас уже есть байт файла… Нам нужно остальное.
В итоге мы имеем разрыво-устойчивый протокол. Чего ещё желать обычному пользователю? Хотя, необычный пользователь может ещё пожелать распределённости… И будет прав! Но, увы, HTTP не может предоставить подобную возможность.
Файл без метки – байты на ветер.
ETag даёт нам способ проверки актуальности документа без обращения ко времени. При использовании ETag мы не “засекаем” качество объекта, а помечаем напрямую. ETag – Entity Tag – просто метка объекта. Строка, возможно, с индикатором “слабости”. “Сильная” метка принадлежит двум объектам, если они эквивалентны. Тоже самое и со слабыми, в том смысле, что, раз они обе “слабы”, то что их сравнивать. Обязательное условие для метки – уникальность. Она должна быть уникальной среди всех экземпляров всех объектов. По ETag’у можно довольно просто проверить актуальность документа в кеше (некоторые сервера, к примеру, отсылают вместе с 304 ответом ещё и метку файла, к которому обращались).
Значение метки используется при получении объекта по разным ссылкам. Ведь при нынешней организации веб-ресурсов свободно могут встречаться url типа “http://example.com/2009/10/me.jpg” и “http://example.com/category/photo/me.jpg”.
HTTP в этих ваших интернетах
«I hear there’s rumors on the, uh, Internets…»
Джордж Буш-младший
HTTP – один из самых (если не сказать, самый) востребованный протокол Internet’а. Для многих пользователей (проверено на маме) Интернет, веб, сеть, сайты – слова-синонимы. Поэтому, для поддержания конкуренции было бы неплохо реализовать данный протокол в рассово-чистом интернете FidoNet.
Fido-fido-fido-net больше тебя нет.
Fido-fido-fido-net высше тебя нет.
Фольклор Фидо, не позднее 1997 г.
Одним из самых известных (скандально) инициаторов создания версии протокола для фидо является Сергей Соколов aka Mithgol – сисоп узла 2:5063/88. С этой идеей он обратился к зам. преда (в ходе интернет-конференции Яндекса 5 марта 2007 года), на что Медведев, видимо, по незнанию, ответил: “задача создания гипертекстового фидонета как минимум актуальна”. После этого были выделены ресурсы на развитие Гипертекстового Векторного Фидонета ТТИ ЮФУ.
Что ж, думаю, что в для общего развития студентам Таганрогского Технического Института будет полезно построить свой “интернет” с блекджеком и… В реальной жизни, к сожалению, Fido не способен составить конкуренцию моснтруозному и привычному Интернету.
Что день грядущий нам готовит?
В 1999-ом, когда разрабатывался HTTP/1.1, не было огромных ресурсов подобных facebook, google, youtube. Поэтому не было и проблемы, которая стоит довольно остро в наше время. В HTTP нет поддержки распределённости. Протокол разрабатывался для решения задач, решение которых не должно занимать много времени (обработка запроса, вёрстка).
Для решения этой проблемы в 1998-ом году консорциумом WWW был предложен протокол HTTP-NG (Next Generation) – объектно-ориентированный протокол передачи гипертекста. Эта идея была высоко оценена специалистами по распределённым вычислениям, однако данный протокол до сих пор не запущен. Возможно, и не будет никогда использоваться: высоко-нагруженные веб-проекты уже давно научились перераспределять потоки данных и нагрузку между сотнями серверов.
Кстати, так же было в своё время и с поддержкой сессий… Просто ввели дополнительный “костыль” – cookies. Почти всегда проще доделать, чем переделывать всё с нуля.
Протокол HTTP и вообще Web давно стали синонимами Internet’а. Именно они являются передним краем развития IT. Сей факт лишь ещё раз доказывает нам древнее утверждение “кто владеет информацией – тот владеет миром”. А гипертекст – есть ничто иное, как “связанная” информация.
“Живи долго и процветай!”