В основе Всемирной паутины (World Wide Web) лежит фундаментальная концепция — унифицированная система адресации ресурсов․ Без надежного механизма идентификации и локализации документов, изображений, скриптов и других сущностей, гипертекстовые архивы превратились бы в хаотичный набор несвязанных файлов․ Статья подробно рассматривает архитектуру системы адресов (URL/URI), ее компоненты, принципы работы, историческую эволюцию и современные вызовы․

Терминологическая база: URI, URL, URN

Часто эти термины используют как синонимы, однако в технической спецификации (RFC 3986) существует строгая иерархия:

• URI (Uniform Resource Identifier) — Унифицированный идентификатор ресурса․ Это надмножество, обобщающее понятие «имя» и «адрес» ресурса․ Любая строка, идентифицирующая ресурс, является URI․
• URL (Uniform Resource Locator) — Унифицированный указатель ресурса․ Подкласс URI, который не просто идентифицирует ресурс, но и предоставляет средства его локализации (протокол, хост, путь)․ Именно URL мы видим в адресной строке браузера․
• URN (Uniform Resource Name), Унифицированное имя ресурса․ Подкласс URI, обеспечивающий постоянное уникальное имя ресурса без привязки к его текущему местоположению (например, urn:isbn:0451450523 для книги)․

Ключевой принцип: Любой URL является URI, но не любой URI является URL․

Анатомия URL: Синтаксис по RFC 3986

Стандартный URL состоит из нескольких компонентов, разделенных специальными разделителями․ Общая схема:

схема:[//авторизация]путь[?запрос][#фрагмент]

Схема (Scheme)

Определяет протокол или механизм доступа к ресурсу․ Завершается двоеточием (:)․

• Стандартные: http, https, ftp, mailto, file, data․
• Пользовательские: tg (Telegram), spotify, myapp (Deep Linking)․

Имена схем нечувствительны к регистру, но рекомендуется нижний регистр․

Авторизация (Authority) — опционально

Предваряется двойным слешем (//)․ Содержит информацию о доступе к хосту․

[userinfo@]host[:port]

• Userinfo: Имя пользователя и пароль (устарело, небезопасно: user:pass@)․
• Host (Хост): Доменное имя (example․com) или IP-адрес (IPv4: 192․0․2․1, IPv6: [2001:db8::1] — в квадратных скобках)․
• Port (Порт): Номер TCP/UDP порта․ Если опущен, используется стандартный для схемы (80 для HTTP, 443 для HTTPS)․

Путь (Path)

Идентифицирует конкретный ресурс в иерархии на сервере․ Состоит из сегментов, разделенных слешем (/)․

• Абсолютный путь начинается с /․
• Может имитировать файловую систему (/images/logo․png) или быть виртуальным (REST API: /api/v1/users/42)․
• Чувствителен к регистру (в отличие от доменного имени)․

Строка запроса (Query) — опционально

Начинается с вопросительного знака (?)․ Передает неиерархические данные серверу (параметры поиска, фильтры, токены)․

Формат: пары ключ=значение, разделенные амперсандом (&) или точкой с запятой (;)․

?q=search+terms&lang=ru&page=1

Фрагмент (Fragment) — опционально

Важно: Фрагмент никогда не отправляется на сервер при HTTP-запросе․ Обрабатывается исключительно клиентом (браузером)․

Кодирование (Percent-Encoding)

URL может содержать только ограниченный набор ASCII-символов (буквы, цифры, - ․ _ ~ и зарезервированные символы-разделители)․ Все остальные символы (кириллица, пробелы, спецсимволы) должны быть закодированы в формате %XX, где XX — шестнадцатеричный код байта в кодировке UTF-8․

IRIs (Internationalized Resource Identifiers)

Современный стандарт (RFC 3987) позволяет использовать Unicode-символы напрямую в строке адреса (например, https://пример․рф/страница)․ Браузеры отображают их в читаемом виде, но перед отправкой запроса автоматически преобразуют в ASCII-совместимый формат (Punycode для доменов: xn--e1afmkfd․xn--p1ai и Percent-encoding для пути)․

Относительные и абсолютные URL

• Относительный к корню (Root-relative): Начинается с / (/path/file․html)․ Зависеть только от хоста․
• Относительный к протоколу (Protocol-relative): //site․com/path (устаревший паттерн, браузер сам подставит http или https)․

Алгоритм разрешения (Resolution): Клиент (браузер) преобразует относительный URL в абсолютный, используя Base URL (обычно URL текущего документа или тег <base href="․․․">)․

Историческая эволюция и ключевые RFC

1. RFC 1738 (1994) — Первая спецификация URL (Berners-Lee, Masinter, McCahill)․ Определила базовые схемы: http, ftp, gopher, mailto, news, telnet, file, wais, prospero․
2. RFC 1808 (1995) — Относительные URL․
3. RFC 2732 (1999) — Поддержка IPv6 в хостах (квадратные скобки)․
4. RFC 3986 (2005) — Текущий основной стандарт (STD 66)․ Уточнение синтаксиса, нормализация, сравнение URI, ABNF-грамматика․
5. RFC 3987 (2005) — IRI (Internationalized Resource Identifiers)․
6. WHATWG URL Living Standard — Современная спецификация, реализуемая браузерами․ Более детально описывает парсинг, сериализацию, Origin, URL API (класс URL в JS) и обработку ошибок, чем строгий RFC 3986․

Безопасность и уязвимости системы адресации

Сложность парсинга URL является источником множества уязвимостей:

URL Parsing Confusion (Несоответствие парсеров)

Разные компоненты инфраструктуры (WAF, Reverse Proxy, Backend-сервер, Браузер) могут по-разному интерпретировать один и тот же URL․

• Path Traversal: /static/․․/admin — нормализация пути до или после проверки прав доступа․
• Host Header Injection / SSRF: Манипуляции с авторизацией: http://evil․com@good․com (userinfo), http://good․com:80@evil․com (порт как часть userinfo)․

IDN Homograph Attacks (Атаки гомографов)

Использование визуально похожих символов из разных алфавитов в доменных именах (Punycode)․ Пример: аррӏе․com (кириллица) vs apple․com (латиница)․ Современные браузеры показывают Punycode (xn--80ak6aa92e․com), если скрипты смешаны или не соответствуют языку пользователя․

Open Redirects

Параметры вроде ?next=/dashboard или ?url=https://evil․com, которые невалидируются сервером, позволяют фишингу под легитимным доменом․

Современные тренды и будущее адресации

Content Addressing (IPFS, IPNS)

Переход от Location-based addressing (где лежит файл) к Content-based addressing (хеш содержимого)․

• CID (Content Identifier): bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi (IPFS v1, base32)․
• Гарантирует неизменность и дедупликацию․ Используется в Web3, распределенных файловых системах․

DIDs (Decentralized Identifiers)

W3C стандарт для самосуверенных идентификаторов (did:example:123456789abcdefghi)․ Не зависят от централизованных реестров (DNS/ICANN), разрешаются через DID Documents (часто хранятся на блокчейнах или в IPFS)․

Web Share Target / Protocol Handlers

Регистрация веб-приложений как обработчиков схем (mailto, web+com․example) или целей шаринга (Web Share Target API), превращая PWA в полноценные системные обработчики URL․

URL Canonicalization и SEO

Для поисковых систем критична канонизация: выбор одного «правильного» URL для дублирующего контента (www vs non-www, trailing slash, параметры сортировки, HTTPS)․ Используются rel="canonical", 301 редиректы, файл sitemap․xml․

Программная работа с URL (Best Practices)

Никогда не парсьте URL регулярными выражениями․ Используйте стандартные библиотеки платформы:

• JavaScript/TypeScript: new URL(input, base), URLSearchParams (WHATWG API)․
• Python: urllib․parse, yarl, pydantic․HttpUrl․
• Go: net/url․
• Java/Kotlin: java․net․URI, java․net․URL, OkHttp HttpUrl․
• Rust: url crate․

Пример на JS (WHATWG API):

const base = 'https://example․com/path/';
const relative = '․․/resource?key=value#section';

const absolute = new URL(relative, base);
console․log(absolute․href); // https://example․com/resource?key=value#section
console․log(absolute․origin); // https://example․com
console․log(absolute․pathname); // /resource
console․log(absolute․searchParams․get('key')); // "value"
// Безопасное построение URL с параметрами
const apiUrl = new URL('https://api․example․com/v1/search');
apiUrl․searchParams․set('q', 'поисковый запрос с пробелами');
apiUrl․searchParams․append('tags', 'tag1');
apiUrl․searchParams․append('tags', 'tag2');
fetch(apiUrl); // Автоматически закодирует всё корректно

Система адресов гипертекстовых архивов (URL/URI) — это не просто строки в адресной строке, а универсальный язык навигации в цифровом пространстве․ От строгой иерархии RFC 3986 до живого стандарта WHATWG, от DNS-кодировки Punycode до криптографических CID в IPFS — архитектура адресации постоянно эволюционирует, балансируя между читаемостью для человека, эффективностью для машины и безопасностью для экосистемы․

Глубокое понимание структуры URL, правил кодирования, алгоритмов разрешения относительных путей и векторов атак на парсеры является обязательным навыком для веб-разработчиков, инженеров по безопасности, SEO-специалистов и архитекторов распределенных систем․