Что такое dns uri url
Появилось таки некоторое количество времени, и я решил написать сий пост, идея которого возникла уже давно.
Связан он будет будет с такой, казалось бы, простой вещью, как URI, детальному рассмотрению которой в рунете уделяется как-то мало внимания.
"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:
Перед тем как начать хотел бы обозначить, что есть пост на схожую тему, в котором все обозначено проще и немного понятнее. Целью же этого поста, я ставлю более глубокое изучение вопроса и сбор информации об URI в одном месте, дабы «не потерять». Ну, почти в одном месте, статья будет разделена на две части
А для удобства бахнем оглавление, которое работает не без особенностей URI, которую мы рассмотрим попозжа, в этой статье.
Ознакомление
Расшифровка аббревиатур
URL - Uniform Resource Locator (унифицированный определитель местонахождения ресурса)
URN - Unifrorm Resource Name (унифицированное имя ресурса)
URI - Uniform Resource Identifier (унифицированный идентификатор ресурса)
Внимание! Далее в мелочах кроется истина, и пока ничего не понятно, - какая-то каша, но, едем дальше.
Wildcards
Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:
1. URI
Унифицированный Идентификатор Ресурса, в простонародье — URI
Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно RFC3986, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого тырнета.
Резюмируя п.1.1 можно сформулировать определение:
Многие из вас замечали, что на разных ресурсах ссылки называют то URL, то URI и, вероятно, становилось интересно — какой же из вариантов правильный?
Дело в том, что URL увидел свет и был документирован в 1990 году, в то время как URI был документирован лишь в 1994 году. И вплоть до 2002 года, до выхода RFC3305, уместными были оба варианта именования, что, порой вносило путаницу.
В п.2 RFC3305 сообщается об устаревании такого термина как URL, применимо к ссылкам, и что отныне верным будет именование URI, с того момента, во всех документах W3C использует термин URI. Исходя из этого, применяя термин URL к соответствующим ссылкам, вы не делаете смысловой ошибки, но делаете ее с точки зрения правильного именования.
Так же примечателен тот момент, что вплоть до выхода RFC2396, в 1997 году, URI расшифровывался как Universal Resource Identifier, что можно увидеть в RFC1630
- либо scheme+authority+path ,
- либо sheme+path ,
- либо только path .
1.1. Синтаксис
URI составлен из ограниченного набора символов, состоящих из цифр, букв и нескольких графических символов, все эти символы вписываются в кодировку US-ASCII (ASCII). Зарезервированное подмножество символов может использоваться, чтобы разграничить компоненты синтаксиса в URI, в то время как остающиеся символы: не зарезервированный набор и включая те зарезервированные символы, которые не действуют как разделители в данной компоненте URI, определяют данные идентификации каждого компонента.
Зарезервированные символы
-
gen-delims, они же «главные разделители», т.е. символы, разделяющие URI на крупные компоненты.
Для данного случая, согласно ABNF :
ALPHA — любая буква верхнего и нижнего регистров кодировки ASCII (в regExp [A-Za-z])
DIGIT — любая цифра (в regExp 1)
HEXDIG — шестнадцатиричная цифра (в regExp [0-9A-F])
Процентное кодирование
Т.о., %20, например, означает пробел.
1.2. Компоненты URI
-
Scheme (схема)
Каждый URI начинается с имени схемы, которое относится к спецификации для присвоения идентификаторов в этой схеме. Также, синтаксис URI — объединенная и расширяемая система именования, причем, спецификация каждой схемы может далее ограничить синтаксис и семантику идентификаторов, использующих эту схему.
Название схемы обязательно начинается с буквы и далее может быть продолжено любым количеством разрешенных символов.
Разрешенные символы для схемы:
Выводы
Подводя итог можно сказать, что если мы говорим про сеть Интернет, то чаще всего используем термин URL, так как находим определенный ресурс в сети именно по его адресу на каком-то сервере. Также часто можно встретить аббревиатуру URI, подразумевающую именно URL. Хотя по факту это не совсем так, потому что URL является часть URI. В то же время в контексте веба URN практически не используется.
Пост из серии «Ликбез». Всегда хотел это понять, но значимость его была настолько мала, что всегда находился повод этого не делать.
А вы задавались вопросом: URL — что это?
Всегда с таким сталкиваюсь, но до сих пор не желал понять в чем различие между терминами URI, URL, URN.
По началу, данная статья была результатом перевода "в лоб", в результате чего по ней разгорелись довольно нешуточные комментарии.
Позже, я решил переосмыслить чужие доводы и отчасти переписал первоисточник, стараясь внести ясность в повествование.
Вы когда-нибудь обращали внимание на адресную строку в Вашем браузере?
Что это? URI, URL или URN?
Многие из нас не делают различий между URI, URL, URN, а кое-кто даже и не слышал терминов URI и URN, все просто пользуются термином URL.
Давайте вместе попытаемся разобраться в этом.
В чем различия
URL: Исторически возник самым первым из понятий и закрепился как синоним термина веб-адрес. URL определяет местонахождение ресурса в сети и способ его (ресурса) извлечения.
Это позволяет нам полностью узнать: как, кому и где можно достать требуемый ресурс, вводя понятия схемы, данных авторизации и местонахождения.
URI: Это лишь обобщенное понятие (множество) идентификации ресурса, включающее в нашем случае как URL, так и URN, как по отдельности, так и совместно. Т.е. мы можем считать, что: URI = URL или URI = URN или URI = URL + URN
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Давайте вспомним, в одном из прошлых уроков мы узнали, что на сервере могут храниться различные ресурсы. Это могут быть статичные файлы в файловой системе, также это может быть динамически создаваемый контент, который потом отдается клиенту. Сейчас важно понять, что на сервере в сети Интернет хранятся разнородные данные, и каждый элемент этих данных можно назвать отдельным ресурсом, будь то изображение PNG, либо данные курсов валют.
Итак, давайте начнем с первого термина URI и дадим ему такое определение:
URI (Uniform Resource Identifier) – это строка символов, которая используется для идентификации какого-либо ресурса по его адресу или по его имени, либо по тому и тому вместе.
Чтобы стало понятнее проведем аналогию с реальным миром на примере какого-нибудь человека. У человека есть имя, например Боб. Также у человека есть адрес проживания, например, пр. Победы 152. Предположим, нам нужно найти человека. Мы можем это сделать, начав поиск только по имени, или только по адресу, или по имени и адресу вместе.
Возвращаясь обратно к терминологии, вместо человека выступает какой-нибудь ресурс на сервере, и при помощи URI мы можем идентифицировать ресурс на сервере по его адресу или по его названию, либо по тому и тому вместе.
Следующий термин – это URL. Дадим такое определение:
URL (Uniform Resource Locator) – это строка символов, которая используется для идентификации какого-либо ресурса, но только по его адресу, по его местоположению.
В примере с человеком это выглядит примерно так. К слову сказать, в вебе, в сети Интернет именно URL чаще всего используется для обнаружения ресурсов на сервере. Наверняка вы не раз встречали эту аббревиатуру.
И последний термин – это URN. Дадим такое определение:
URN (Uniform Resource Name) – это строка символов, которая используется для идентификации какого-либо ресурса, но только по его имени.
В нашем примере это выглядит так. Мы знаем этого человека, знаем, что его зовут Боб. Но мы не знаем, где он живет. Нам придется искать его только по имени.
Важно запомнить такой момент. Все эти три термина находятся в такой условной зависимости (или иерархии), как на картинке ниже. Потому что URI может использовать и адрес, и имя при идентификации ресурса. В то время как URL и URN только адрес и только имя соответственно.
Каждый URL является URI. Каждый URN является URI. Но не каждый URI, к примеру, является URL (он может быть URN).
Теперь давайте более подробно разберем каждое из этих понятий.
URL чаще всего используется в Интернете для поиска ресурсов на сервере. URL буквально точно показывает нам, как определить ресурс, именно по его адресу. Если ввести подобный URL в строке поиска браузера, то будет осуществлен поиск соответствующего ресурса. И хотя URL на картинке ниже немного отличаются друг от друга своей структурой, есть определенный формат, как должен быть построен любой URL.
Любой URL состоит из нескольких компонентов. Протокол и хост являются обязательными, все остальные - нет.
Любой URL состоит из нескольких компонентов. Протокол и хост являются обязательными, все остальные - нет.
URN служит для обозначения уникального имени ресурса, неважно, где этот ресурс располагается в данный момент времени или вообще. Такая природа URN (независимость от адреса) позволяет ресурсам перемещаться с одного места на другое. URN позволяет получить доступ к ресурсу по различным сетевым протоколам, обращаясь к одному и тому же имени.
. URN позволяет получить доступ к ресурсу по различным сетевым протоколам, обращаясь к одному и тому же имени
На текущий день URN все еще считается экспериментальным и не так сильно распространен, как URL, так как для полной поддержки URN требуется поддерживающая его развитая сетевая инфраструктура.
CNAME для Heroku или Github
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.
2. URL
URL используются, чтобы определить местоположение ресурсов, обеспечивая абстрактную идентификацию расположения ресурса. Определив местоположение ресурса, система может выполнить множество операций на ресурсе, которые могут быть характеризованы такими словами как 'доступ', 'обновление', 'замена', 'поиск атрибутов'. В целом только метод доступа должен быть определен для любой схемы URL.
Т. о.: URL призван решить широкий ряд задач, начиная с получения и заканчивая изменением данных на ресурсе, а обязательным параметром для получения доступа — является метод, т. е. любой полноценный (абсолютный) URL можно свести к виду:
2.1. Структура
В целом, URL имеет схожую структуру, для всех схем, хотя для каждой отдельно взятой схемы, структура может отличаться от общего шаблона.
Графически ее можно выразить в следующем виде:
-
Относительная ссылка использует иерархический синтаксис, чтобы выразить ссылку URI относительно пространства имен другого иерархического URI.
- «urn:» — обязательная, регистронезависимая часть URN
- NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:
Относительные ссылки так же делятся на несколько подвидов:
-
Ссылка сетевого пути
Имеет вид:
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
3. URN
Унифицированные имена ресурсов (URN) предназначены, чтобы служить постоянными, независимыми от расположения, идентификаторами ресурсов и разработаны для упрощения отображения других пространств имен (которые совместно используют свойства URN) в URN-пространство. Таким образом, синтаксис URN обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.
Т. е., в отличие от URL, который ссылается на како-то место, где хранится документ, URN ссылается на сам документ, и при перемещении документа в другое место ссылка не изменится.
В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая — DDDS , которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.
3.1. Структура
Запрещенные символы должны быть процентно-кодированы. Если указанный символ встретится в явном виде, его позиция будет считаться концом URN:
Самоидентифицирующийся URN
Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.
Например, URN из magnet-ссылки с одного торрент-трекера:
magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d.
С теорией все, во второй части рассмотрим, что можно и что нужно делать с URI, если мы их обрабатываем, а именно — нормализация, разбор и т.д.
В предыдущих двух статьях мы рассмотрели основы взаимодействия по протоколу SIP.
Далее я предлагаю разобраться с такой важной составляющей SIP, как SIP URI. Мы сталкивались с ними раньше, когда говорили о полях From, To и других, однако не уделяли им должного внимания.
В рамках этой короткой статьи мы рассмотрим, какие бывают URI и из чего они состоят. В следующей статье остановимся на URI и URL в протоколе SIP.
Викепедия говорит следующее: URI (англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. На английский манер произносится как [ю-ар-ай], по-русски чаще говорят [ури]. URI — это последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.
При этом URI может указывать как местоположение ресурса (URL), так и его имя (URN). А может содержать и то и другое. То есть URL и URN — это частные случаи URI.
Выглядит довольно запутанно, поэтому приведу пример:
Интересный факт: Тим Бернерс-Ли, основоположник URL в последствии сожалел, что разделил точкой доменные имена в рамках URL. URL мог бы выглядеть вот так:
URN не используется в рамках SIP, однако без него рассказ был бы неполным.
URN (Uniform Resource Name) является уникальным именем объекта. URN включает в себя название пространства имен и идентификатора в этом пространстве. Типичный пример URN — это ISDN-Имя книги. URN состоит из NID (namespace identifier или идентификатор пространства имен) и NSS (namespace-specific string или уникального для данного пространства имен имени). Схематично это выглядит следующим образом:
Чтобы стало совсем понятно, приведу следующий пример. Допустим, мы хотим описать некого Ивана.
URN в данном случае будет выглядеть следующим образом: паспорт РФ: Иванов Иван Иванович, паспорт серия 1234 номер 123456. Где «паспорт РФ» — это название идентификатора пространства имен, а «Иванов Иван Иванович, паспорт серия 1234 номер 123456» — это уникальное имя в этом пространстве.
С помощью этого URN мы одназначно идентифицируем Ивана, но не сможем определить его местоположение. Здесь нам поможет URL. Выглядеть это может примерно так: машина: город N/улица M/квартира L. Где «машина» — это метод получения доступа, а «город N. » — путь.
Подведем итог. URN отвечает идентифицирует ресурс по имени и отвечает на вопрос «Что?». URL — указывает путь и метод доступа к ресурсу и отвечает на вопросы «Где?» и «Как?». При этом URN и URL — это частные случаи URI.
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Базовые штуки
Давайте взглянем на маппинг между именем и адресом:
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:
Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA's DNS Parameters.
Оставшаяся часть ответа описывает сам ответ:
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес ( 192.168.1.1 ), на какой порт стучался dig ( 53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig 'у, если бы информация не был закэширована:
Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Другие типы
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
Подведем итоги
URI - это абстракция концепции идентификации,
а URL и URN - это конкретные реализации - полного адреса ресурса и уникального контекстного имени соответственно.
Да простят меня собеседники, но, чтобы не вводить в заблуждение читателей, мной была удалена часть спорных комментариев.
Читайте также: