URL (Uniform Resource Locator)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:35, 29 октября 2016.

URL (англ. Uniform Resource Locator - Единый указатель ресурса) — единообразный локатор (определитель местонахождения) ресурса. Ранее назывался Universal Resource Locator — универсальный указатель ресурса. URL служит стандартизированным способом записи адреса ресурса в сети Интернет.

История

URL был изобретён Тимом Бернерсом-Ли в 1990 году в стенах Европейского совета по ядерным исследованиям в Женеве, Швейцария[1]. Через два годы были готовы протоколы HTTP и HTML , благодаря которым появился интернет.

URL

Главной целью разработчиков URL было обеспечение возможности существования документов, ссылавшихся друг на друга в условиях многообразия форматов, доступ к которым осуществлялся по протоколам вроде Gopher или FTP . Необходим был надежный способ ссылаться на файл, так, чтобы в ссылке был закодирован протокол, хост в интернете и местонахождение на этом хосте. Этим способом стал URL, впервые официально задокументированный в RFC в 1994 году.

Структура

Общая схема или структура URL-адреса выглядит следующим образом[2]:

<схема>://<логин>:<пароль>@<хост>:<порт>/<URL‐путь>?<параметры>
  • Схема – это тот протокол передачи данных, по которому, мы хотим обратиться к ресурсу.
  • Логин и пароль — имя пользователя и пароль, используемые для доступа к ресурсу. Далеко не всегда эти параметры будут использоваться. Например, для доступа к какой-либо веб-странице, по протоколу http – как правило, эти данные не указывают.
  • @ — разделитель между хостом и парой логин-пароль. В случае, если логин-пароль не указывается, то разделитель можно точно также не указывать.
  • Хост> – доменное имя или IP-адрес (ссылки) того ресурса, к которому нужно обратиться.
  • Порт – уникальный номер, который выделяется тому приложению, которое будет обрабатывать ваш запрос. При работе по протоколу http, чаще всего задается автоматически и равен 80 или 8080.
  • URL — путь – здесь мы указываем уточняющую информацию о местонахождении ресурса. Зависит от используемого протокола. В случае с протоколом HTTP задается путь с указанием каталогов и подкаталогов, где лежит ресурс.
  • Параметры — строка запроса с передаваемыми на сервер методом GET параметрами.
  • Разделитель параметров — знак &.
Пример: ?параметр_1=значение_1&параметр_2=значение_2&параметр3=значение_3
  • якорь – уникальная строка, набор букв И(ИЛИ) цифр, которая ссылается на определенную уникальную область (раздел) того веб-документа, который вы собираетесь открыть.

Т.е. переходя по url адресу с якорем можно сделать так, чтобы документ открылся не с самого начала, а с конкретного места или раздела.

Протоколы URL

Первая часть URL — это протокол, по которому нужно производить соединение. Самый распространенный протокол это http. Это простой протокол для передачи документов, который Тим Бернерс-Ли разработал специально для сети. Это был не единственный вариант. Некоторые считали, что нужно использовать Gopher[3]. Gopher был разработан специально для отправки структурированных данных, по аналогии со структурой файлового дерева. Например, при запросе на /Cars можно получить такой ответ:

1Chevy Camaro             /Archives/cars/cc     gopher.cars.com     70
iThe Camero is a classic  fake                  (NULL)              0
iAmerican Muscle car      fake                  (NULL)              0
1Ferrari 451              /Factbook/ferrari/451  gopher.ferrari.net 70 

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

Первым популярным протоколом был FTP. Его создали в 1971 году для получения списков и скачивания файлов на удаленных машинах. Gopher был логическим продолжением этой идеи, так как он предлагал похожий листинг, но также включал механизмы получения мета-информации о записях. Это означает, что его можно было использовать и для других задач, вроде ленты новостей или простой базы данных. Однако, ему не хватало свободы и простоты, которые характеризуют HTTP и HTML.

Главное меню протокола Gopher

HTTP — это очень простой протокол, особенно по сравнению с альтернативами вроде FTP или даже HTTP/2, популярность которого сегодня растет. Во-первых, HTTP полностью текстовый, в нем не используются бинарные элементы (которые могли бы значительно улучшить производительность). Тим Бернерс-Ли правильно решил, что текстовый формат позволит поколениям программистов легче разрабатывать и отлаживать приложения, использующие HTTP.Формально, длина URL не ограничена, но браузеры имеют ограничения по длине URL. Не рекомендуется использовать URL длиной более 2048 символов, так как Microsoft Internet Explorer имеет именно такое ограничение.

HTTP также не делает никаких допущений по поводу содержания. Несмотря на то, что он был разработан специально для передачи HTML, он позволяет указать тип содержания (с помощью MIME Content-Type, который был новым изобретением в свое время). Сам протокол довольно прост.

Запрос:

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

Возможный ответ:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Content-Type: text/html; charset=UTF-8
 Content-Encoding: 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>

В основе сети лежит IP, протокол интернета. IP отвечает за передачу маленького пакета данных (около 1500 байтов) от одного компьютера другому. Поверх этого — TCP, который отвечает за передачу более крупных блоков данных вроде целых документов или файлов. TCP осуществляет гарантированную доставку с помощью множества IP-пакетов. Поверх этого живет протокол вроде HTTP или FTP, который указывает, какой формат данных использовать для пересылки с помощью TCP (или UDP или другого протокола) чтобы передать осмысленные и понятные данные. Можно сделать свой протокол, если захочется, собирая байты из сообщений TCP как угодно. Единственное требование заключается в том, чтобы получатель говорил на том же языке. Поэтому принято стандартизировать эти протоколы.

Кодирование URL

Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьёзным недостатком — в нём можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания. Если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французского языка, то нужные нам символы должны быть перекодированы особым образом.
Кодирование URL и просто двоичных данных в последовательность букв, цифр и некоторых специальных знаков латинского алфавита в интернете было связано с ограничением физических устройств на передачу только алфавитно-цифровых символов. В URL такое кодирование обычно применяется для передачи символов в формате Unicode (как правило UTF-8) в последовательность из двух байт, записанных в шестнадцатиричном представлении[4]. Каждый байт предваряется знаком %. При таком кодировании слово "корова" будет иметь вид:

Таблица кодов UTF заглавных букв кириллицы
%D0%BA%D0%BE%D1%80%D0%BE%D0%B2%D0%B0. 

То есть русской букве к будет соответствовать последовательность %D0%BA и.т.д. Такое кодирование является общепринятым для путей к файлам или папкам, входящим в URL. Подмножество символов, которые разрешены в URL немного шире чем алфавитно-цифровые символы, так, в URL можно использовать дефис и подчеркивание, но нельзя, например, использовать одинарные или двойные кавычки. Некоторые символы используют для разделения параметров в URL, и их кодирование в этом случае будет неправомочным. В зависимости от отношения к кодированию специальных символов в javascript различают функции encodeURI и decodeURI, которые могут работать с полным URL, и, функции encodeURIComponent / decodeURIComponent, применяемые для параметров, входящих в URL. Вообще говоря, кодирование параметров может быть достаточно произвольным. Здесь разработчик может использовать любую схему кодировки, если состав ее символов будет коректно передаваться через сеть. Так, вместо строки кириллицы в utf-8 можно применить строку в кодировке Windows 1251. В этом случае строка будет выглядеть как:

%EA%EE%F0%EE%E2%E0.
Таблица кодов UTF строчных букв кириллицы

То есть, символу к будет соответствовать последовательность из двух букв со знаком процента перед ними - %EA. Допустимы также другие способы кодирования, например, escape/unescape функцию javascript. Строка в этом случае будет выглядеть как :

%u043A%u043E%u0440%u043E%u0432%u0430.

Порты протоколов URL

Историю Gopher и HTTP можно проследить по их номерам портов. Gopher — это 70, HTTP 80. Порт для HTTP был установлен (скорее всего Джоном Постелом из IANA) по запросу Тима Бернерса-Ли между 1990 и 1992 годами. Концепция регистрации «номеров портов» появилась еще до интернета. В оригинальном протоколе NCP, на котором работала сеть ARPANET, удаленные адреса были идентифицированы с помощью 40 битов. Первые 32 указывали на удаленный хост, это похоже на то, как IP работает сегодня. Последние 8 бит назывались также AEN (“Another Eight-bit Number” или «Еще одно восьмибитное число»), и использовались для схожих с портом целей: разделить сообщения, имеющие разные предназначения. Другими словами, адрес указывал на машину, куда нужно доставить сообщение, а AEN (или номер порта) указывал на приложение, которому нужно доставить сообщение. Они быстро запросили, чтобы пользователи регистрировали эти «номера сокетов» для ограничения потенциальных коллизий. Когда номера портов расширили до 16 бит в TCP/IP, процесс регистрации продолжился. Не смотря на то, что у протоколов есть порт по умолчанию, имеет смысл позволять вручную указывать порт для упрощения локальной разработки и для работы с несколькими сервисами на одной машине. Такая же логика лежала в основе добавления www. в адреса сайтов. В то время было сложно представить, чтобы кто-то получал доступ к корню своего домена чтобы всего лишь захостить «экспериментальный» веб-сайт. Но если давать пользователям имя хоста для конкретной машины (dx3.cern.ch), то начнутся проблемы когда появится необходимость заменить машину. Если использовать общий поддомен (www.cern.ch), то можно свободно менять место, куда указывает этот адрес.

Авторизация

В URL также можно включить логин и пароль. Браузер кодирует эти данные в формат Base64 и посылает в виде заголовка. Base64 используется только для того, чтобы можно было передавать запрещенные в заголовках символы. Он никак не скрывает логин и пароль. Это было проблемой, особенно до распространения SSL. Любой человек, который следит за вашим соединением, мог с легкостью увидеть пароль. Предлагали много альтернатив, в том числе Kerberos, который был и остается популярным протоколом безопасности. Как и с другими примерами нашей истории, простую базовую авторизацию было проще всего реализовать разработчикам браузеров (Mosaic). Так базовая авторизация стала первым и единственным решением до тех пор, пока разработчики не получили инструменты для создания собственных систем аутентификации.

Стандарт IRI

Поскольку такому сложному кодированию подвергаются буквы всех алфавитов, кроме базовой латиницы, то URL со словами подавляющего большинства языков может стать нечитаемым для человека. Это всё входит в противоречие с принципом интернационализма, провозглашаемого всеми ведущими организациями Интернета, включая W3C и ISOC. Эту проблему призван решить стандарт IRI (англ. Internationalized Resource Identifier) — международных идентификаторов ресурсов, в которых можно было бы без проблем использовать символы Юникода, и которые поэтому не ущемляли бы права других языков. Хотя заранее сложно сказать, смогут ли когда‐либо идентификаторы IRI заменить столь широко используемые URL (и URI в целом).

PURL

У современного URL есть огромное количество недостатков, среди них[5]:

  • Малая гибкость;
  • Проблемы с шифрованием;
  • Указание пути на несуществующие ресурсы;
  • Навязывание ресурсам иерархической структуры (об этом говорил сам создатель URL);
  • Плохая работа с гипертекстовой структурой.

По этим и другим причинам была предложена совершенно новая интерпретация URL под названием PURL. В рамках данного стандарта будет использоваться несколько иной подход. Все будет основано на существовании базы данных PURL, в которой и будут храниться все имена и пути к ресурсам. Система будет регулярно проверять эти ресурсы и, при необходимости, удалять или обновлять ссылки на них. Таким образом удастся решить три из пяти вышеперечисленных проблем. Что касается остальных, специалисты пока что находятся на стадии разработки их решений.

Примечания

  1. URL [Электронный ресурс] : Материал из Википедии — свободной энциклопедии - Режим доступа: https://ru.wikipedia.org/wiki/URL
  2. Материал из электронного ресурса — Что такое url адрес - Режим доступа: http://webgyry.info/chto-takoe-url-adress
  3. Материал из электронного ресурса — История URL'а: домен, протокол и порт - Режим доступа: https://habrahabr.ru/post/305484/
  4. Материал из электронного ресурса — URL кодирование и декодирование строк - Режим доступа: https://www.design-sites.ru/utility/url-encoding.php
  5. Материал из электронного ресурса — Перспективы URL - Режим доступа: http://geek-nose.com/url-adres-stranicy-sajta-chto-eto-takoe-i-gde-ego-vzyat/#kak-uznat-url