- •2. Разработка мультимедийного курса
- •1. Содержание курса «администрирование информационнх систем»
- •1.1. Принципы построения открытых системы и «клиент-серверных» технологий. Модель iso/osi
- •1.1.1 Открытые системы и открытые спецификации
- •1.1.2 Технологии «клиент-сервер»
- •1.1.3 Модель iso/osi, функции протоколов каждого из уровней
- •1.2. Стек tcp/ip и его протоколы
- •1.2.1 Структура стека tcp/ip
- •1.2.2 Краткая характеристика протоколов
- •1.2.3 Надежность протоколов
- •1.2.4 Инкапсуляция
- •1.2.5 Протокол ip и его основные функции
- •1.2.6 Фрагментация
- •1.2.7 Формат заголовка пакета Ipv4
- •1.2.8 Протокол iPv6
- •1.2.9 Протокол icmp
- •1.2.10. Протокол udp
- •1.2.11 Протокол tcp и формат его заголовка
- •1.2.12 Окно передачи в tcp
- •1.3. Адресация в ip сетях
- •1.3.1 Адресация в ip-сетях
- •1.3.2 Типы адресов: физический (mac), сетевой (ip) и символьный (dns)
- •1.3.3 Соглашения о специальных адресах
- •1.3.4 Отображение физических адресов на ip-адреса: протоколы arp и rarp
- •1.4. Принципы работы dns
- •1.4.1 Отображение символьных адресов на ip-адреса: служба dns
- •1.4.2. Основные домены верхнего уровня
- •1.4.3 Система доменных имен bind
- •1.4.4 Автоматизация процесса назначения ip-адресов узлам сети - протокол dhcp
- •1.5. Принципы и основные протоколы маршрутизации в Интернет
- •1.5.1 Основные принципы ip-маршрутизации
- •1.5.2 Разбиения адресного пространства сети на подсети
- •1.5.3 Маскирование
- •1.5.4 Таблицы маршрутизации в ip-сетях
- •1.5.5 Фиксированная маршрутизация
- •1.5.6 Простая маршрутизация
- •1.5.7 Адаптивная маршрутизация
- •1.5.8. Дистанционно-векторный алгоритм маршрутизации (на примере rip)
- •1.5.9 Алгоритм состояния связей (на примере ospf)
- •1.5.10 Комбинирование различных протоколов обмена
- •1.5.11 Протоколы egp и bgp сети Internet
- •1.6. Протоколы прикладного уровня
- •1.6.1 Основные сервисы Интернет и соответствующие протоколы
- •1.6.2 Порты и сокеты
- •1.6.3 Http, ftp и др. Протоколы прикладного уровня
- •1.6.4 Mime, типы и расширения
- •1.6.5 Этапы транзакции http
- •1.6.6 Понятия uri, url
- •1.6.7 Схемы http-сеанса
- •1.6.8 Структура Запроса клиента
- •1.6.9 Структура ответа сервера
- •1.6.10 Cookie
- •1.7. Программирование в Интернет
- •1.7.1 Программирование в Интернет
- •1.7.2 Серверное и клиентское по
- •1.7.3 Программы, выполняющиеся на клиенте (JavaScript, Java-аплеты)
- •1.7.4 Программы, выполняющиеся на сервере
- •1.7.5 Спецификация cgi
- •1.7.6 Perl
- •1.7.7 Isapi
- •1.8. Администрирование в Unix и в Windows. Управление web-сервером.
- •1.8.1 Администрирование в Unix и в Windows
- •1.8.2 Управление web-сервером
- •1.8.3 Построение isp
- •1.8.4 Архитектура сервера Apache
- •1.8.5 Архитектура сервера Internet Information Server
- •1.9. Интернет-экономика. Модели назначения цен. Сетевая коммерция.
- •1.9.1. Экономика информационных сетей.
- •9.2. Интернет-экономика (иэ): основные понятия иэ
- •1.9.3. Составляющие расходов на предоставление услуг Интернет
- •1.9.4. Межсоединения и распределенная экономика: ip-транспорт; структура цены и экономика соглашений о межсоединениях; разделение распределенной стоимости
- •1.9.5. Модель назначения цен. Оценка потребления: тарифы и цены в иэ; методы оценивания стоимости коммуникаций
- •1.9.6. Категории электронного бизнеса
- •1.9.7. Сетевая коммерция: услуги общественного и частного потребления; электронные службы; электронные платежные системы
- •1.9.8. Экономическая эффективность сетей типа Интернет
- •1.10. Перспективы развития глобальных информационных систем
- •2. Разработка мультимедийного курса
1.6.6 Понятия uri, url
Стандарт URI
Документ RFC3986, "Универсальный идентификатор ресурсов (URI): общий синтаксис" - это стандарт интернета. Так называемая серия "Запросы на комментарии" (Request for Comments - RFC) - это известная серия архивных документов, которая является основой процесса разработки стандартов в Проблемной группе проектирования Internet (Internet Engineering Task Force - IETF). Только несколько из тысяч документов RFC, такие как протокол управления передачей (Transmission Control Protocol - TCP) и почтовый формат (RFC821) и протокол (RFC822) интернета получили полный статус стандартов интернета. RFC3986 получил этот статус в январе 2005 г.
Согласно стандарту URI, первый из вышеприведенных примеров - http://www.cisco.com/en/US/partners/index.html является настоящим URI и включает несколько составляющих его частей:
- имя схемы (http);
- имя домена (www.cisco.com);
- путь (/en/US/partners/index.html).
Непротиворечивый процесс IETF управляет схемами. Официальный реестр схем URI Агентства по выделению имен и уникальных параметров протоколов Internet (Internet Assigned Numbers Authority - IANA) включает как общеизвестные схемы, такие как http, https и mailto, так и множество других, менее знакомых широкому кругу пользователей.
URI-путь выглядит как типичный путь доступа к файлу. URI унаследовали левую косую черту (a/b/c) из традиций UNIX, поскольку в конце 1980-х годов, когда они разрабатывались, в интернете преобладала культура UNIX, а не PC. Тогда существовало несколько распространенных представлений для доступа к удаленным файлам. Одно из них - это Ange-ftp, расширение emacs для редактирования удаленных файлов. Оно сводило воедино имена хост-узла и пользователя с путем доступа к файлу, и в результате получалась конструкция такого типа: /jbrown@freddie.ucla.edu:~mblack/. Синтаксис URI, разработанный для интернета, использовал двойную левую косую черту для перекрестного обращения к машинам (это унаследовано из диалекта Apollo Domain UNIX). Помимо этого, он ввел в обращение синтаксис схем для того, чтобы можно было унифицировать соглашения о присвоении имен из любого количества различных протоколов. Вот несколько примеров:
- mailto:mbox@domain
- ftp://host/file
- http://domain/path.
Второй пример во введении, www.yahoo.com/sports, на самом деле не является настоящим URI. Это удобное сокращение для http://www.yahoo.com/sports. Такой формат поддерживается пользовательскими интерфейсами распространенных Web-браузеров. Но если схема XSLT записана следующим образом:
<xsl:includehref="exslt.org/math/min/math.min.template.xsl"/>,
то она не будет работать, как ожидается, если только это выражение не является обращением к файлу в директории exslt.org, находящейся рядом с таблицей стилей XSLT. Атрибут href в XSLT означает URI-ссылку, которая может быть абсолютной или относительной. Если URI-ссылка начинается со схемы и двоеточия, то она является абсолютной, в противном случае - относительной. Относительная URI-ссылка очень похожа на путь доступа к файлу. Например, ../noarch/config.xsd - это относительная URI-ссылка.
URL и URN
URI разработаны таким образом, чтобы выполнять функции и имени, и адреса. После того, как они поступили в IETF для стандартизации, их стали именовать унифицированными указателями информационных ресурсов (Uniform Resource Locators); одновременно началась работа над разработкой унифицированных имен ресурсов (Uniform Resource Names).
Для имен и ресурсов интернет-хостов существуют отдельные стандарты. Синтаксис имен хостов такой же, как и имен доменов (например, zork1.example.edu). Эти имена связаны с адресами типа 192.168.300.21 с помощью протокола системы имен домена (Domain Name System - DNS). Такая непрямая связь позволяет именам оставаться стабильными, когда хосты перемещаются в сети и их нумерация изменяется.
Случайные неработающие ссылки в интернете приводят к тому, что Web-адреса становятся больше похожими на указатели, а не на имена, поэтому в сообществе IETF возникли различные предложения:
- URI: запрос RFC1630, выпущенный в июне 1994 г., был назван "Универсальные идентификаторы ресурсов в WWW: единый синтаксис для выражения имен и адресов объектов в сети, используемый во Всемирной сети Интернет" (Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web). Это был информационный запрос, т.е. он не получил общего одобрения IT-сообщества;
- URL: запрос RFC1738, выпущенный в декабре 1994 г., был назван "Унифицированные указатели информационных ресурсов" (Uniform Resource Locators). Это был предлагаемый стандарт, т.е. он являлся результатом согласований, хотя еще и не был в достаточной степени проверенным и зрелым, чтобы стать стандартом для всего интернета;
- URN: запрос RFC1737, выпущенный в декабре 1994 г., был назван "Функциональные требования для унифицированных имен ресурсов".
В 1997 г. за запросом RFC1737 последовал предлагаемый стандарт RFC2141 - "Синтаксис URN", который описывал спецификацию еще одной схемы - urn, в дополнение к уже существовавшим http:, ftp: и другим.
Окончательный стандарт URI RFC3986 объясняет различие между этими понятиями в секции 1.1.3 - "URI, URL и URN":
URI может далее рассматриваться как указатель, имя или и то, и другое. Термин "унифицированный указатель информационных ресурсов" (URL) относится к подмножеству URI, которые, помимо идентификации ресурса, указывают способ его нахождения путем описания основных механизмов доступа к нему (т.е. его "положение" в сети). Термин "унифицированное имя ресурса" (URN) исторически использовался как для URI в пределах схемы urn, которые должны оставаться уникальными в мировом масштабе и оставаться стабильными, даже если ресурс прекращает существование или становится недоступным, так и для любых других URI со свойствами имени.
Отдельная схема не обязательно должна рассматриваться только как "имя" или "указатель". Конкретные URI из любой схемы могут иметь характеристики как имен, так и указателей, или обоих этих понятий. Часто это зависит от постоянства и тщательности в распределении идентификаторов полномочным органом по присвоению имен, а не от качества схемы. В будущих спецификациях и связанных с ними документах должен использоваться общий термин URI, а не более узкие понятия URL и URN.