HTML/URL-адрес
Синтаксис
<протокол>://<логин>:<пароль>@<хост>:<порт>/<путь-к-файлу>?<параметры>#<якорь>
Описание
URL-адрес (от англ. «Uniform Resource Locator» ‒ «Универсальный Указатель Ресурсов»; от англ. «Uniform Resource Locator» ‒ «Унифицированный Указатель Ресурсов») это указатель расположения ресурса.
URL-адреса могут быть абсолютными и относительными.
Условия использования
Все «&
» символы, используемые во всех URL-адресах в (X)HTML документе должны быть заменены на соответствующие символьные ссылки («&
»).
Спецификация
RFC | Название |
---|---|
1630 | Universal Resource Identifiers in WWW |
1738 | Uniform Resource Locators (URL) |
3508 | H. 323 Uniform Resource Locator (URL) Scheme Registration |
URL-составляющие
- <протокол>
- Протокол обмена данными.
http://example.su
Примечание: Название протокола может не указываться; в этом случае будет иметь место «URL-адрес относительно протокола» (будет применён протокол используемый при передачи данных текущей страницы).
//example.su
- <логин>
- Указывается логин пользователя. Указывать логин в URL-адресе не безопасно!
http://login:[email protected]
- <пароль>
- Указывается пароль пользователя. Указывать пароль в URL-адресе не безопасно!
http://login:[email protected]
- <хост>
- Указывается доменное имя или IP-адрес хоста.
http://example.su.
,http://example.su
илиhttp://5.101.153.60
- <порт>
- Указывается порт хоста.
http://example.su:80
или - <путь-к-файлу>
- Указывается путь к файлу (ресурсу).
http://example.su/
,http://example.su/path/
илиhttp://example.su/path/index.html
- <параметры>
- Параметры передаваемые (GET методом) на сервер обрабатывающему файлу. В качестве разделителей параметров указывается знак «&» АМПЕРСАНД [U+0026].
http://example.su?text=tag%20a
илиhttp://example.su?val1=true&val3=true
- <якорь> (имя указателя)
name
» или глобального параметра «id
».)http://example.su/path/index.html#anchor
Пример: Обновление URL-адреса вашего сервиса в веб-карте.—Portal for ArcGIS (10.3 и 10.3.1)
На главнуюИспользованиеАдминистрирование
Наверх
В этом примере обновляется URL-адрес сервиса, на который ссылается веб-карта. Это удобно, если URL сервиса изменился, и вы не хотите, чтобы пользователи удаляли и повторного добавляли сервис во всех веб-картах. Существует множество причин, по которым URL сервиса может измениться. Например, сервис может быть перемещен на новый сервер, может измениться название сервиса, или сервис может оказаться перемещенным в другую папку на сервере или может измениться префикс домена сервера.
При запуске скрипта вам потребуется указать следующую информацию:
- URL-адрес для доступа к Portal for ArcGIS. Это может быть URL-адрес ArcGIS Web Adaptor, например, https://webadaptor.domain.com/arcgis, или URL-адрес компьютера с порталом, например, https://portal.domain.com:7443/arcgis. В URL-адресе необходимо указать полное доменное имя компьютера.
- Имя пользователя и пароль для учетной записи, которая имеет права администратора портала.
- Тип элементов, который будет обновлен. Укажите «Веб-карта», чтобы обновить все веб-карты портала.
- URL-адрес сервиса, на который ссылаются веб-карты, например, http://webadaptor.domain.com/arcgis/rest/services/folderA/ServiceAreas/MapServer.
- Новый URL-адрес сервиса, который будет использоваться в веб-картах, например, http://webadaptor.domain.com/arcgis/rest/services/folderB/ServiceAreas/MapServer.
В следующем примере URL-адрес картографического сервиса http://webadaptor.domain.com/arcgis/rest/services/folderA/ServiceAreas/MapServer заменяется на URL-адрес http://webadaptor.
python updateWebmapServices.py https://webadaptor.domain.com/arcgis admin pass.word "type: Web Map" http://webadaptor.domain.com/arcgis/rest/services/folderA/ServiceAreas/MapServer http://webadaptor.domain.com/arcgis/rest/services/folderB/ServiceAreas/MapServer
#!/usr/bin/env python # Requires Python 2.7+ # Sample Usage: # python updateWebmapServices.py <sourcePortal> <sourceAdmin> <sourcePassword> # <query> <oldUrl> <newUrl> import urllib import json import argparse def generateToken(username, password, portalUrl): '''Retrieves a token to be used with API requests.''' parameters = urllib.urlencode({'username' : username, 'password' : password, 'client' : 'referrer', 'referrer': portalUrl, 'expiration': 60, 'f' : 'json'}) response = urllib.urlopen(portalUrl + '/sharing/rest/generateToken?', parameters).read() try: jsonResponse = json.loads(response) if 'token' in jsonResponse: return jsonResponse['token'] elif 'error' in jsonResponse: print jsonResponse['error']['message'] for detail in jsonResponse['error']['details']: print detail except ValueError, e: print 'An unspecified error occurred.' print e def searchPortal(portalUrl, query=None, totalResults=None, sortField='numviews', sortOrder='desc', token=None): ''' Search the portal using the specified query and search parameters. Optionally provide a token to return results visible to that user. ''' # Default results are returned by highest # number of views in descending order. allResults = [] if not totalResults or totalResults > 100: numResults = 100 else: numResults = totalResults results = __search__(portalUrl, query, numResults, sortField, sortOrder, 0, token) if not 'error' in results. keys(): if not totalResults: totalResults = results['total'] # Return all of the results. allResults.extend(results['results']) while (results['nextStart'] > 0 and results['nextStart'] < totalResults): # Do some math to ensure it only # returns the total results requested. numResults = min(totalResults - results['nextStart'] + 1, 100) results = __search__(portalUrl=portalUrl, query=query, numResults=numResults, sortField=sortField, sortOrder=sortOrder, token=token, start=results['nextStart']) allResults.extend(results['results']) return allResults else: print results['error']['message'] return results def __search__(portalUrl, query=None, numResults=100, sortField='numviews', sortOrder='desc', start=0, token=None): '''Retrieve a single page of search results. ''' params = { 'q': query, 'num': numResults, 'sortField': sortField, 'sortOrder': sortOrder, 'f': 'json', 'start': start } if token: # Adding a token provides an authenticated search. params['token'] = token request = portal + '/sharing/rest/search?' + urllib.urlencode(params) results = json.loads(urllib.urlopen(request).read()) return results def updateWebmapService(webmapId, oldUrl, newUrl, token, portalUrl): '''Replaces the URL for a specified map service in a web map.''' try: params = urllib.urlencode({'token' : token, 'f' : 'json'}) print 'Getting Info for: ' + webmapId # Get the item data. reqUrl = (portalUrl + '/sharing/content/items/' + webmapId + '/data?' + params) itemDataReq = urllib.urlopen(reqUrl).read() itemString = str(itemDataReq) # Find the service URL to be replaced. if itemString.find(oldUrl) > -1: newString = itemString.replace(oldUrl, newUrl) # Get the item's info for the addItem parameters itemInfoReq = urllib.urlopen(portalUrl + '/sharing/content/items/' + webmapId + '?' + params) itemInfo = json.loads(itemInfoReq.read(), object_hook=__decodeDict__) print 'Updating ' + itemInfo['title'] # Post back the changes overwriting the old map if(itemInfo['ownerFolder'] is not None): modRequest = urllib.urlopen(portalUrl + '/sharing/content/users/' + itemInfo['owner'] + '/' + itemInfo['ownerFolder'] + '/items/' + webmapId + '/update?' + params , urllib. urlencode( {'text' : newString} )) else: modRequest = urllib.urlopen(portalUrl + '/sharing/content/users/' + itemInfo['owner'] + '/items/' + webmapId + '/update?' + params , urllib.urlencode( {'text' : newString} )) # Evaluate the results to make sure it happened modResponse = json.loads(modRequest.read()) if modResponse.has_key('error'): raise AGOPostError(webmapId, modResponse['error']['message']) else: print 'Successfully updated the urls' else: print 'Didn\'t find any services with ' + oldUrl except ValueError as e: print 'Error - no web map specified' except AGOPostError as e: print e. webmap print 'Error updating web map ' + e.webmap + ': ' + e.msg # Helper functions for decoding the unicode values in the webmap json. def __decodeDict__(dct): newdict = {} for k, v in dct.iteritems(): k = __safeValue__(k) v = __safeValue__(v) newdict[k] = v return newdict def __safeValue__(inVal): outVal = inVal if isinstance(inVal, unicode): outVal = inVal.encode('utf-8') elif isinstance(inVal, list): outVal = __decode_list__(inVal) return outVal def __decode_list__(lst): newList = [] for i in lst: i = __safeValue__(i) newList.append(i) return newList class AGOPostError(Exception): def __init__(self, webmap, msg): print 'ok' self.webmap = webmap self.msg = msg # Run the script. if __name__ == '__main__': parser = argparse.ArgumentParser() parser.add_argument('portal', help=('url of the Portal (e.g. ' 'https://portal. domain.com:7443/arcgis)')) parser.add_argument('username', help='username') parser.add_argument('password', help='password') parser.add_argument('query', help='search string to find content') parser.add_argument('oldUrl', help='the URL to replace') parser.add_argument('newUrl', help='the new URL') # Read the command line arguments. args = parser.parse_args() portal = args.portal username = args.username password = args.password query = args.query oldUrl = args.oldUrl newUrl = args.newUrl # Get a token for the source Portal for ArcGIS. token = generateToken(username=username, password=password, portalUrl=portal) # Get a list of the content matching the query. content = searchPortal(portalUrl=portal, query=query, token=token) for item in content: if item['type'] == 'Web Map': updateWebmapService(item['id'], oldUrl, newUrl, token=token, portalUrl=portal) print 'Update complete. '
Отзыв по этому разделу?
Реальная разница между URL-адресом и URI
URL-адреса и URI-это одна из самых больших путаниц, и путаница возникает из-за того, что оба являются идентификаторами ресурсов, но URL-адрес является типом URI .
Все URL-адреса являются URI, но не все URI являются URL-адресами.
URI или URL — одна из известных битв ботаников.
Настоящая разница между URI и URL-адресом заключается в том, что URI может быть просто именем (например, google.com) или именем в сочетании с протоколом, позволяющим туда добраться (например, https://)— , в то время как URL всегда представляет собой имя в сочетании с протоколом (https://google.com) .
URI подобен адресу сам по себе или адрес с направлениями, в то время как URL всегда адрес с направлениями .
Другими словами, URI — это идентификаторы, а URL — это идентификаторы , которые также сообщают вам, как к ним добраться!
URL URI и URN
Что следует использовать?
Структуры URL
Пройдем тест
Путаница с RFC
Резюме
Это основы, но ниже вы можете получить более подробную техническую информацию о различиях между URI и URL, а также URN.
Примеры
Типы и подтипы URI
Вот еще примеры URI, URN и URL, которые показывают взаимосвязь. Помните, что URI может быть URN или URL, потому что оба являются подтипами URI.
Имена и адреса технически не являются URI в этом примере, но он иллюстрирует разницу между вещью и тем, как найти эту вещь.
URI, URL и URN
Унифицированный идентификатор ресурса (URI) — это строка символов, однозначно идентифицирующая имя или ресурс в Интернете. URI идентифицирует ресурс по имени, расположению или по обоим параметрам . URI имеют две специализации, известные как унифицированный указатель ресурса (URL) и унифицированное имя ресурса (URN).
Унифицированный указатель ресурса (URL) — это тип URI, который указывает не только ресурс, , но и способ доступа к нему в Интернете — например, http://, ftp:// или mailto:// .
Унифицированное имя ресурса (URN) — это тип URI , в котором используется конкретная схема именования urn: — например, urn:isbn:0-486-27557-4 или urn:isbn:0-395-36341-1.
Таким образом, URI или URN похожи на ваше имя, а URL — это особый подтип URI, который подобен вашему имени в сочетании с вашим адресом.
Все URL-адреса являются URI, но не все URI являются URL-адресами.
Выше мы узнали, что URI включают в себя как URN, так и URL-адреса, но давайте рассмотрим это более подробно.
A UR I — это идентификатор определенного ресурса. Примеры: Книги, Документы
A UR L — это специальный тип идентификатора , который также сообщает вам, как получить к нему доступ . Примеры: HTTP, FTP, MAILTO
Если протокол (https, ftp и т. д.) либо присутствует, либо подразумевается для домена, вы должны называть его URL-адресом , даже если это также URI.
Итак, что мне использовать?
URI и URL — один из самых вечных споров компьютерщиков. Если вы когда-нибудь услышите, как кто-то поправляет кого-то — в том или ином направлении — вы часто услышите сразу после этого обнажение мечей Катана.
Так что правильно?
Когда большинство людей упоминают домен, подразумевается протокол HTTP, что делает его URL-адресом.
Ответ таков: это зависит от того, что обсуждается. Если вы говорите о обычном домене веб-сайта, таком как google.com, лучше использовать URL вместо URI, потому что URL более конкретен.
Обычно лучше быть как можно более конкретным, поэтому URL-адрес лучше, чем URI, даже если оба они технически верны.
Если вы разговариваете с кем-то, например, из Сан-Франциско, и они спрашивают вас, где вы живете, вы не станете говорить им, что живете в Сан-Франциско или в Калифорнии. Вы ответили бы своим соседям, потому что это уровень детализации, о котором они просили.
Технически google.com — это URI, так же как технически вы живете в Калифорнии, но google.com — это еще и URL, и вы также живете в Сан-Франциско.
Другими словами, в 99% повседневных случаев вы должны использовать URL вместо URI, потому что оба варианта технически верны, но URL более конкретен!
Структуры URL-адресов
URL-адреса также имеют свою особую структуру. В этой структуре у вас есть следующие компоненты:
Схема — протокол, который вы используете для взаимодействия.
Власть, которая является целью, к которой вы обращаетесь. Это разбивается на информацию о пользователе, хосте и порте.
Путь, который является ресурсом, который вы запрашиваете на хосте.
Запрос — параметры, используемые в веб-приложении.
Фрагмент, на который нужно перейти на данной странице.
Схемы могут включать: HTTP, HTTPS, FTP, MAILTO, IRC, FILE и т. д. HTTP и HTTPS обычно используются для доступа к интернет-ресурсам, но они также могут указывать на локальные ресурсы (в сети или на компьютере).
Схема ФАЙЛ обращается к файлу, расположенному на локальном компьютере, и ищет файл по указанному пути. Хост также может включать обозначение порта, которое переопределяет порт по умолчанию для указанного протокола. Например:
https://google. com
…перейдет на хост google.com через порт 443, потому что 443 является портом по умолчанию для HTTP. Но если вы укажете порт следующим образом:
https://google.com:9023
… клиент попытается подключиться к порту 9023, используя вместо этого протокол HTTPS.
Наконец, URL-адреса также имеют параметры запроса и идентификаторы фрагментов.
Параметры запроса указывают на то, что аргумент передается веб-приложению, например функция поиска веб-страницы, например:
https://google.com/search?s=bing
Это приведет к поиску слова «bing» в функции, называемой поиском в Google.
Фрагменты позволяют перейти к определенной части страницы по URL-адресу, например:
https://google.com/results.html#worse
Это приведет к переходу к гиперссылке на странице с пометкой «хуже» на странице с именем results.html.
Проверка некоторых примеров
Хорошо, давайте рассмотрим несколько примеров и посмотрим, сможете ли вы ответить на вопросы.
Это URI, URL или URN?
www.google.com
Ответ: Это неполный URL, потому что у него нет протокола (хотя вы можете возразить, что это может подразумеваться). Что касается структуры, если бы это был URL-адрес, это была бы только часть хоста , поскольку в ней отсутствует схема и путь .
Это URI, URL или URN?
userstats.html
Ответ: Похоже, что это ресурс внутри URL-адреса, но, поскольку он не выглядит уникальным ресурсом и не предваряется префиксом urn:, это не формальный URN. Так что это не URN, URL или URI.
Путаница с RFC
Более глубокое объяснение (давайте перейдем к техническим аспектам)
Позвольте мне предупредить вас: это один из самых распространенных NerdFights в истории технологий, и это говорит о многом.
Неконтролируемое обучение — безопасность, технологии и искусственный интеллект за 10 минут…
Получайте еженедельные сводки о том, что происходит в сфере безопасности и технологий — и почему это важно .
Одним из препятствий на пути к сути вещей является то, что соответствующие RFC чрезвычайно запутаны, запутаны и даже противоречивы. Например, RFC 39.86 говорит, что URI может быть именем, локатором или и тем, и другим…
Мой акцент.
URI может быть дополнительно классифицирован как локатор, имя или и то, и другое . Термин «унифицированный указатель ресурса» (URL) относится к подмножеству идентификаторов URI, которые, помимо идентификации ресурса, предоставляют средства определения местоположения ресурса путем описания его основного механизма доступа (например, его сетевого «местоположения»).
RFC 3986, раздел 1.1.3
RFC 3986, раздел 1.1.3
Но чуть ниже тот же RFC говорит…
Мой акцент.
Сам URI обеспечивает только идентификацию; доступ к ресурсу не гарантируется и не подразумевается наличием URI .
RFC 3986, раздел 1.2.2
RFC 3986, раздел 1.2.2
И затем, если вы еще не совсем запутались, там также написано…
Мой акцент.
Каждый URI начинается с имени схемы , как определено в Разделе 3.1, которое относится к спецификации для присвоения идентификаторов в рамках этой схемы.
RFC 3986, раздел 1.1.1
RFC 3986, раздел 1.1.1
Далее приведены примеры:
Обратите внимание, что все их примеры имеют схемы.
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:[электронная почта защищена]
новости:comp.infosystems.www.servers.unix
тел:+1-816-555-1212
telnet://192.0.2.16:80/
урна:оазис:имена:спецификация:docbook:dtd:xml:4.1.2
Подождите… что?
Эти три противоречия и есть источник всего этого многолетнего спора.
В том же RFC только что сказано, что URI может быть именем, локатором или и тем, и другим — но URI только обеспечивает идентификацию, а способ доступа не гарантируется и не подразумевается — да, и также каждый URI начинается с имени схемы (которое во многих случаях говорит вам, как именно получить доступ к ресурсу).
Неудивительно, что все в замешательстве!
Причина, по которой интернет спорит об этом уже более десяти лет, заключается в том, что RFC написан плохо.
Спасение практических правил от всего этого
Быть первым в результатах поиска по этой теме означает, что у меня много разговоров.
Итак, учитывая тот факт, что RFC вносит путаницу, а не устраняет ее, что — если вообще что-нибудь — мы можем из них использовать?
В духе языка, предназначенного для общения, а не для педантизма, вот мои собственные практические интерпретации RFC , которые, я надеюсь, синхронизируют людей и приведут к меньшему количеству драк на мечах.
Все бабочки летают, но не все, что летает, является бабочкой.
Унифицированный идентификатор ресурса (URI) предоставляет простые и расширяемые средства идентификации ресурса (прямо из RFC 3986). Это просто идентификатор; не переусердствуйте.
Для большинства дебатов по этому вопросу URI является надмножеством, поэтому вопрос только в том, является ли данный URI формально URL-адресом или нет . Все URL-адреса являются URI, но не все URI являются URL-адресами. В общем, если вы видите http(s)://, это URL.
URI технически требуют схемы (см. выше), но RFC также говорит, что они могут быть именем, локатором или и тем, и другим, так что YOLO! Мой совет всем, кто говорит, что для URI нужна или не нужна схема, — показать им эту статью, потому что это единственное, что я знаю о том, что подчеркивает противоречия в RFC.
Фрагменты, такие как file.htm , на самом деле не являются URN , потому что URN должны использовать специальную запись с urn: в начале.
Малоизвестный раздел RFC 3986 на самом деле прямо говорит о религиозной части аргумента, и, кажется, говорит, что мы должны говорить URI вместо URL .
RFC 3986 от 2005 года, поэтому, по-видимому, они говорят, что URI является предпочтительным термином после этого пункта.
Будущие спецификации и сопутствующая документация должны использовать общий термин «URI», а не более ограничительные термины «URL» и «URN». Я», но, на мой взгляд, это еще большая поддержка тех, кто говорит: «Хватит искать ответы в RFC 15-летней давности».
Это похоже на еще один широко читаемый текст в этом смысле.
Противоречивого контента так много, что некоторые выводы частично подтверждаются.
Резюме
Какой беспорядок. Вот TL;DR…
RFC устарели, плохо написаны, и их не стоит обсуждать, пока они не будут обновлены.
URI — это идентификатор.
URL-адрес — это идентификатор, который сообщает вам, как к нему добраться.
Используйте термин, который лучше всего понятен получателю .
Я бы приветствовал новую версию RFC, которая упрощает и проясняет различие с современными примерами.
Эти RFC были написаны очень давно , и они написаны с академической слабостью, поскольку не оптимизированы для чтения.
Лучшее, что я могу вам сказать об этих дебатах, это не переоценивать их. Я ни разу за 20 лет не видел ситуации, когда путаница между URI и URL действительно имела значение.
Ирония в том, что RFC должны устранять путаницу, а не добавлять ее.
Таким образом, несмотря на некоторую прямую поддержку того, что RFC предпочитает «URI», а «URL» кажется наиболее точным для полных адресов со схемами http(s) (поскольку он наиболее специфичен), я решил поставить принцип ясности коммуникации выше, чем педантичный нюанс.
Мне потребовалось много времени, чтобы добраться до этого момента.
В результате я лично использую «URL» в большинстве случаев , потому что это менее вероятно, чтобы вызвать путаницу , но если я слышу, что кто-то использует «URI», я часто сразу же переключаюсь на его использование.
Примечания
20 февраля 2022 г. — Добавлены дополнительные разделы и более подробные объяснения различий в URL-адресах, URI и URN.
16 января 2022 г. — Обновлено для краткости, удобочитаемости и ясности.
3 мая 2019 г. — Я сделал крупное обновление статьи, в том числе исправил некоторые ошибки, которые были у меня в предыдущих версиях. А именно, у меня такие фрагменты, как file.html, отображались как URN, что неправильно. Эта версия статьи является лучшей версией, особенно потому, что она полностью исследует конфликтующие формулировки в RFC и то, как мало мы должны обращать внимание на такой старый документ. Тем не менее, я определенно читал и следил за обновлениями.
RFC 3986 Ссылка
Статья Википедии по ссылке URI
Примеры Masscan: от установки до повседневного использования 5
Значение веб-адреса. Что такое URL (унифицированный указатель ресурсов)?
Веб-адрес или URL — это конкретное местоположение веб-сайта в Интернете.
Другими словами, URL-адрес (унифицированный указатель ресурсов) — это текстовая строка, указывающая расположение веб-страниц, изображений или видео в Интернете.
Например, https://www.codesweetly.com
— это веб-адрес CodeSweetly.
Веб-адрес состоит из восьми частей:
- Схема
- Поддомен
- Имя домена
- Домен верхнего уровня
- Порт
- Путь к файлу
- Параметр
- Привязка
Давайте обсудим каждую часть веб-адреса.
Схема указывает протокол (набор правил), который браузеры должны использовать для доступа к ресурсам веб-сайта. Некоторые из популярных схем — HTTPS, TCP, Mailto и FTP.
Субдомен
Субдомен является подмножеством определенного веб-сайта. Он позволяет разделить ваш сайт на один или несколько разделов.
Хотя большинство людей используют www
в качестве основного раздела своего веб-сайта, использование www
в URL-адресах не является обязательным, поскольку это не служит технической цели.
Другими словами, вы можете использовать www
в качестве вторичного домена, используя блог
, или новости
, или подобные в качестве основного домена.
Кроме того, вы можете создать свой домен без использования www
.
Независимо от вашего выбора между www
и не www
URL, лучше выбрать один и придерживаться его. Таким образом, ваш веб-адрес будет соответствовать вашим пользователям и поисковым системам.
После того, как вы выбрали URL-адрес www
или не- www
, не забудьте перенаправить другой тип.
Так, например, если вы решили использовать URL-адреса www
, настройте сервер для перенаправления всех запросов, отличных от www
, на их эквивалент www
.
Перенаправление необходимо, поскольку вы не можете предсказать URL-адрес, который будут использовать ваши пользователи.
Доменное имя
Доменное имя — это имя веб-сайта. Это неотъемлемая часть веб-сайта, которая помогает пользователям запомнить веб-сайт.
Другими словами, доменное имя — это то, что следует после @
в адресе электронной почты. Или то, что следует за www.
в веб-адресе.
Так, например, codesweetly
— это доменное имя в [email protected]
и https://www.codesweetly.com
.
Имейте в виду, что доменное имя — это удобная для человека версия IP-адреса.
Например, 172.217.169.36
— это IP-адрес www.google.com
.
Другими словами, предположим, что вы ввели в браузере www.google.com
. В этом случае компьютер преобразует URL-адрес в IP-адрес 172.217.169.36
через систему доменных имен (DNS).
Но зачем преобразовывать доменные имена в IP-адреса?
Имейте в виду, что людям гораздо легче запоминать имена, чем числа. Однако компьютеры лучше всего работают с цифрами.
Таким образом, преобразование доменных имен в IP-адреса и наоборот позволяет свободно общаться между людьми и компьютерами.
Другими словами, система доменных имен помогает компьютерам быстро находить определенный ресурс (например, веб-сайт), который люди хотят получить. В то же время позволяя людям с легкостью использовать компьютеры.
Итак, как именно работает система доменных имен?
Предположим, вы вводите доменное имя в браузере. DNS будет искать на своих серверах доменных имен IP-адрес, соответствующий запрашиваемому имени веб-сайта.
Если будет найден соответствующий IP-адрес, DNS:
- Преобразует доменное имя в соответствующий IP-адрес.
- Отправьте браузеру полезную информацию об IP-адресе.
Имейте в виду, что данные, которые получит ваш веб-браузер, включают:
- IP-адрес доменного имени и
- текущие серверы имен хоста веб-сайта, которые содержат IP-адрес хоста.
Эти данные помогут вашему браузеру найти и получить ваш запрос с сервера, на котором размещен запрошенный вами ресурс.
Таким образом, DNS можно рассматривать как важный транслятор, который преобразует удобный для человека адрес (например, www.codesweetly.com
) в эквивалентный компьютерный адрес (например, 104.21.1.249
).
Итак, в чем же разница между доменным именем, системой доменных имен и DNS-сервером? Давай выясним.
Доменное имя, система доменных имен и DNS-сервер
Доменное имя — это имя веб-сайта.
A Система доменных имен (DNS) — это то, как доменные имена преобразуются в эквивалентные им IP-адреса.
И DNS-сервер — это компьютер, используемый для хранения и сопоставления доменных имен с соответствующими им IP-адресами.
- Доменные имена иногда называют именами хостов или веб-сайтов.
- Вы можете приобрести доменные имена у таких регистраторов, как InMotion, Namecheap или Shopify.
Домен верхнего уровня
Домен верхнего уровня (ДВУ) помогает отнести веб-сайт к определенной категории в Интернете.
Например, в https://www.army.mil
домен верхнего уровня mil
классифицирует армейский веб-сайт как военный домен.
Аналогичным образом, в https://www.harvard.edu
домен верхнего уровня edu
классифицирует веб-сайт Гарварда как образовательный ресурс.
Порт — это технический шлюз на сервере веб-сайта, с которого браузеры могут получить доступ к ресурсам сайта.
Так, например, в https://www.codesweetly.com:80
, порт 80
.
Другими словами, порт 80 — это шлюз, предназначенный для обслуживания ресурсов CodeSweetly.
Имейте в виду, что вы можете не указывать номер порта в URL-адресе, если сервер веб-сайта использует стандартный HTTP-порт для предоставления доступа к ресурсам сайта.
Например, предположим, что сервер сайта использует порт 80 для HTTP (или порт 443 для HTTPS). В этом случае вам не нужно указывать номер порта при вводе URL-адреса.
Однако, если сервер сайта использует какой-либо нестандартный порт для предоставления своего ресурса, в этом случае необходимо указать номер порта.
Документ общих портов Массачусетского технологического института содержит список стандартных коммуникационных портов, определенных IANA.
Путь к файлу URL — это путь (маршрут) к ресурсу веб-сайта на веб-сервере.
Параметр (строка запроса) позволяет отправлять определенные данные на сервер. Когда веб-сервер получает строку запроса, он может использовать значение строки для выполнения других действий перед отправкой запрошенного ресурса в ваш браузер.
Анкер — это ссылка на определенную часть того же файла, на который ссылается URL-адрес.
Якорь похож на закладку, используемую для указания браузерам отображать содержимое файла, расположенного в отмеченном месте.
- Часть после хеш-символа привязки (#) иногда называют идентификатором фрагмента.
- Идентификатор фрагмента никогда не отправляется на сервер.
Предположим, веб-сайт — это книга. В этом случае вы можете описать анатомию его URL-адреса следующим образом:
Якорь = Закладка в определенной части книги. Например, закладка заголовка страницы.
Закладка заголовка Библии – Изображение Эйвери Эванс
Параметр = Информация для хранителя книги. Например, вы можете использовать параметр, чтобы сообщить хранителю язык книги.
Путь к файлу = Конкретная страница, которая вам нужна из книги, например, Страница 625.
Порт = Номер двери магазина, где можно получить доступ к книге, например, дверь 70.
Домен верхнего уровня = Жанр, к которому относится книга, например, Образовательный.
Доменное имя = Название книги, например, Библия.
Субдомен = Конкретный раздел книги, к которому вы хотите получить доступ, например, Ветхий Завет.