Что такое URL адрес | ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)
Что такое URL
URL – это обозначение индивидуального адреса веб-сайта или другого ресурса, который записывают и формируют по особой форме. Сама аббревиатура URL обозначает «Universal Resource Locator», что можно перевести как «Универсальный Указатель Местоположения». Рекомендуем интересную статью про URL адреса – a-round.com.ua/seo-url-sajta-chpu.
Говоря простым языком – чтобы найти нужный дом нам потребуется знать город, улицу и его номер (иными словами – адрес), то в случае с веб-сайтом нам достаточно знать его URL, который представляет собой аналогичный адрес, только в интернете – он может состоять из букв латиницы, цифр и некоторых других символов.
Из чего состоит URL адрес
Рассмотрим для примера URL http://www.site.ru/category/page. Данный веб адрес URL состоит из таких компонентов:
Протокол
«http://» – это указание на используемый протокол, который будет маршрутизировать данные через интернет-соединение. Некоторые браузеры не отображают протокол в адресной строке, но это не значит, что его нет. Сейчас часто можно встретить протокол «https», где буква «s» в названии обозначает передачу информации по защищённому протоколу.
Доменное имя
Адрес www.site.ru состоит из таких компонентов:
«ru» – домен первого (верхнего) уровня
«site» – домен второго уровня, который предпочитают регистрировать большинство владельцев веб-сайтов
«www» – домен третьего уровня; корректно настроенный сайт также должен работать без ввода «www».
Каталог
В элементе адреса – /category/page, приведен путь к определённой странице на самом домене. Иногда URL адрес написан только в такой сокращенной форме, и тогда он называется относительным адресом URL. Термин «относительный» означает, что даже если вы перемещаете веб-сайт на другой домен, указанная вами ссылка будет по-прежнему работать внутри сайта.
Иногда URL адреса веб-сайтов, построенных на некоторых системах управления контентом, труднопонятны для человека, потому что они не являются конкретным путем к определенной странице, а представляют собой техническую команду. Такие адреса неудобны пользователям, поэтому с помощью специальных команд их заменяют на так называемые «человекопонятные URL» или «SEO URL».
История
URL адрес был изобретён в далёком 1990 году и использовался для указания на расположение определенных файлов в сети интернет. Затем его создатели пришли к выводу, что такой адрес можно применять и для доступа пользователей на веб-сайты в еще только зарождавшемся на тот момент интернете.
Правильно подобранный адрес для сайта значит очень многое. Краткое и емкое имя позволяет клиентам и посетителям легко запомнить это обозначение, что позволит зайти на требуемый сайт, просто введя его адрес по памяти. Также большое значение URL имеет и для продвижения веб-сайта в поисковых системах. Так, например, Яндекс и Google рекомендуют делать адреса понятными и информативными, что позволит улучшить пользовательский опыт, а пользователи, вероятнее всего, будут чаще переходить по таким ссылкам.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
andreyex.ru
Простым языком об HTTP / Habr
Вашему вниманию предлагается описание основных аспектов протокола HTTP — сетевого протокола, с начала 90-х и по сей день позволяющего вашему браузеру загружать веб-страницы. Данная статья написана для тех, кто только начинает работать с компьютерными сетями и заниматься разработкой сетевых приложений, и кому пока что сложно самостоятельно читать официальные спецификации.HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).
Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.
Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское приложение может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом.
Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.
Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».
API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.
Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.
Как отправить HTTP-запрос?
Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.
http://alizar.habrahabr.ru/
Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.
Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:
telnet alizar.habrahabr.ru 80
Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.
После того, как вы подключитесь к серверу, нужно отправить HTTP-запрос. Это, кстати, очень легко — HTTP-запросы могут состоять всего из двух строчек.
Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.
Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:
Метод URI HTTP/Версия
Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):
GET / HTTP/1.1
Метод (в англоязычной тематической литературе используется слово method
URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:
OPTIONS * HTTP/1.1
Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).
Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:
GET / HTTP/1.1Host: alizar.habrahabr.ru
При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.
Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.
Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:
echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80
Как прочитать ответ?
Стартовая строка ответа имеет следующую структуру:
HTTP/Версия Код состояния Пояснение
Версия протокола здесь задаётся так же, как в запросе.
Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.
Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.
После стартовой строки следуют заголовки, а также тело ответа. Например:
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sat, 08 Mar 2014 22:53:46 GMT
Content-Type: application/octet-stream
Content-Length: 7
Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT
Connection: keep-alive
Accept-Ranges: bytes
Wisdom
Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).
Смотрите сами:
HTTP/1.1 302 Moved Temporarily Server: nginx Date: Sat, 08 Mar 2014 22:29:53 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive Keep-Alive: timeout=25 Location: http://habrahabr.ru/users/alizar/ <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h2>302 Found</h2></center> <hr><center>nginx</center> </body> </html>
В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.
То есть:
GET /users/alizar/ HTTP/1.1Host: habrahabr.ru
В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.
Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.
А что с безопасностью?
Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.
Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.
На данный момент HTTPS поддерживается всеми популярными веб-браузерами.
А есть дополнительные возможности?
Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.
Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.
Что-то ещё, кстати, используют?
На данный момент существуют и другие протоколы, предназначенные для передачи веб-содержимого. В частности, протокол SPDY (произносится как английское слово speedy, не является аббревиатурой) является модификацией протокола HTTP, цель которой — уменьшить задержки при загрузке веб-страниц, а также обеспечить дополнительную безопасность.
Увеличение скорости обеспечивается посредством сжатия, приоритизации и мультиплексирования дополнительных ресурсов, необходимых для веб-страницы, чтобы все данные можно было передать в рамках одного соединения.
Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.
Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.
На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.
И что, всё?
В общем-то, да. Можно было бы описать конкретные методы и заголовки, но фактически эти знания нужны скорее в том случае, если вы пишете что-то конкретное (например, веб-сервер или какое-то клиентское программное обеспечение, которое связывается с серверами через HTTP), и для базового понимания принципа работы протокола не требуются. К тому же, всё это вы можете очень легко найти через Google — эта информация есть и в спецификациях, и в Википедии, и много где ещё.
Впрочем, если вы знаете английский и хотите углубиться в изучение не только самого HTTP, но и используемых для передачи пакетов TCP/IP, то рекомендую прочитать вот эту статью.
Ну и, конечно, не забывайте, что любая технология становится намного проще и понятнее тогда, когда вы фактически начинаете ей пользоваться.
Удачи и плодотворного обучения!
habr.com
домен, протокол и порт / Habr
11 января 1982 года двадцать два специалиста по информатике встретились, чтобы обсудить «компьютерную почту» (ныне известную как «электронная почта»). Среди участников был будущий основатель Sun Microsystems, парень, который сделал Zork, чувак, создавший NTP, и еще один, который убедил правительство платить за Unix. Перед ними стояла задача решить проблему: в ARPANET было 455 хостов, и ситуация выходила из под контроля.
Проблема возникла из-за того, что ARPANET переходил с оригинального протокола NCP на протокол TCP/IP, на котором сейчас существует Интернет. После такого перехода быстро должно было появиться множество объединенных сетей (inter…net), которым требуется иерархическая система доменов, чтобы ARPANET мог резолвить свои домены, а другие сети — свои.
В то время были другие сети: “COMSAT”, “CHAOSNET”, “UCLNET” и “INTELPOSTNET”. Их обслуживали группы университетов и компаний в США, которые хотели обмениваться информацией и которые могли позволить себе арендовать 56 тысяч соединений у телефонной компании и купить PDP-11 для маршрутизации.
В изначальной архитектуре ARPANET главный Центр Сетевой Информации (Network Information Center, NIC) отвечал за специальный файл, в котором содержится список всех хостов сети. Он назывался HOSTS.TXT, аналогично файлу /etc/hosts в современных Linux или macOS. Любое изменение в сети требовало от NIC подключаться к каждому узлу сети по FTP (протокол, созданный в 1971 году), что сильно повышало нагрузку на инфраструктуру.
Хранение всех хостов Интернета в одном файле, конечно, не могло считаться масштабируемым методом. Но приоритетным вопросом была электронная почта. Она была главной задачей адресации. В итоге, они решили создать иерархическую систему, в которой можно было бы запросить у удаленной системы информацию о домене или наборе доменов. Другими словами: «Решение заключалось в том, чтобы расширить существующий почтовый идентификатор вида ‘user@host’ до ‘[email protected]’, где ‘domain’ может быть иерархией доменов». Так родился домен.
Важно отметить, что такие архитектурные решения были приняты без каких-либо предположений о том, как домены будут использоваться в будущем. Они были обусловлены лишь простотой реализации: это требовало минимальных изменений в существующих системах. Одним из предложений было формировать почтовый адрес как <user>.<host>@<domain>. Если бы в почтовых именах тех дней уже не было бы точек, то сегодня вы, возможно, писали бы мне на zack.eager@io
Считается, что главная функция операционной системы — это определить несколько разных имен для одного и того же объекта, так чтобы система была постоянно занята слежением за всеми взаимоотношениями между разными именами. Сетевые протоколы, похоже, ведут себя так же.— Дэвид Д. Кларк, 1982
Еще одно отклоненное предложение заключалось в том, чтобы отделить домен восклицательным знаком. Например, для подключения к хосту ISIA в сети ARPANET нужно было бы написать !ARPA!ISIA. Можно было бы использовать шаблоны: !ARPA!* — все хосты сети ARPANET.
Такой метод адресации не то чтобы безумно отличался от стандарта, наоборот, это была попытка поддержки стандарта. Система разделения с помощью восклицательного знака использовалась в инструменте для передачи данных UUCP, созданном в 1976 году. Если вы читаете эту статью в macOS или Linux, то uucp скорее всего все еще установлен и доступен в терминале.
ARPANET появилась в 1969 году и быстро превратилась в мощный инструмент обмена информацией… среди нескольких университетов и правительственных организаций, которые имели к ней доступ. Интернет в знакомом нам виде стал доступен широкой публике в 1991 году, спустя двадцать один год. Но это не значит, что пользователи компьютеров не обменивались информацией.
В эпоху до интернета использовался способ прямого подключения одной машины к другой через телефонную сеть. Например, если вы хотели послать мне файл, то ваш модем позвонил бы моему модему, и файл был бы передан. Чтобы сделать из этого некое подобие сети, был придуман UUCP.
В этой системе у каждого компьютера был файл со списком хостов, о которых ему известно, их телефонные номера и логин и пароль для хоста. Далее требовалось смастерить маршрут от текущей машины к целевой через набор других хостов:
sw-hosts!digital-lobby!zack
Такой адрес использовался не только для передачи файлов или прямого подключения к компьютеру, но и как адрес электронной почты. В эпоху до почтовых серверов вам не удалось бы послать мне письмо, если мой компьютер был отключен.
В то время, как ARPANET был доступен только топовым университетам, UUCP позволил появиться «подпольному» интернету для простых людей. Он был основой и для Usenet и для системы BBS.
Система DNS, которую мы до сих пор используем, была предложена в 1983 году. Если сделать DNS-запрос с помощью утилиты dig, например, то ответ будет примерно таким:
;; ANSWER SECTION:
google.com. 299 IN A 172.217.4.206
Это значит, что google.com доступен по адресу 172.217.4.206. Как вы наверняка знаете, A означает, что это запись адреса, которая связывает домен с IPv4-адресом. Число 299 — это время жизни (time to live, TTL), сколько еще секунд эта запись считается валидной пока не понадобится делать новый запрос. Но что такое IN?
IN это «Internet». Наряду с другими деталями, это поле пришло из прошлого, в котором было несколько конкурирующих сетей, и им нужно было общаться друг с другом. Другие потенциальные значения для этого поля это CH для CHAOSNET, HS для Hesiod (название сервиса системы Athena). CHAOSNET давно закрылся, но сильно модифицированная версия Athena все еще используется студентами MIT. Список всех классов DNS доступен на сайте IANA, но не удивительно, что обычно используется только один из потенциальных вариантов.
Вероятность того, что будут созданы какие-то другие TLD крайне низка.— Джон Постел,
1994
Когда было решено, что доменные имена должны располагаться иерархически, осталось определить корень иерархии. Такой корень обозначается точкой .. Заканчивать все доменные имена точкой — семантически верно, и такие адреса будут работать в браузере: google.com.
Первым TLD был .arpa. Пользователи могли использовать свои старые имена хостов ARPANET в период перехода. Например, если моя машина была в прошлом зарегистрирована как hfnet, то мой новый адрес был бы hfnet.arpa. Это было временным решением для периода смены системы. Серверным администраторам нужно было принять важное решение: какой из пяти TLD им выбрать? “.com”, “.gov”, “.org”, “.edu” или “.mil”?
Когда говорят, что DNS обладает иерархией, имеют ввиду, что есть набор корневых DNS-серверов, которые отвечают, например, за преобразование .com в адреса DNS-серверов зоны .com, которые в свою очередь вернут ответ на вопрос «как добраться до google.com». Корневая зона DNS состоит из тринадцати кластеров DNS-серверов. Кластеров только 13, потому что больше не помещается в один пакет UDP. Исторически сложилось, что DNS работает через UDP, поэтому ответ на запрос не может быть длиннее 512 байт.
Скрытый текст
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . "
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC
; under anonymous FTP as
; file /domain/named.cache
; on server FTP.INTERNIC.NET
; -OR- RS.INTERNIC.NET
;
; last update: March 23, 2016
; related version of root zone: 2016032301
;
; formerly NS.INTERNIC.NET
;
. 3600000 NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30
;
; FORMERLY NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:84::b
;
; FORMERLY C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c
;
; FORMERLY TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13
D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d
;
; FORMERLY NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f
;
; FORMERLY NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; FORMERLY AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53
;
; FORMERLY NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53
;
; OPERATED BY VERISIGN, INC.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30
;
; OPERATED BY RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1
;
; OPERATED BY ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::42
;
; OPERATED BY WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35
; End of fileКорневые DNS-сервера находятся в сейфах, внутри закрытых клеток. На сейфе стоят часы, чтобы проверять, не взломали ли видеонаблюдение. Учитывая, как медленно работает реализация DNSSEC, взлом одного из этих серверов позволит взломщику перенаправить весь трафик части пользователей интернета. Это сценарий крутейшего фильма, который еще ни разу не сняли.
Не удивительно, что DNS-сервера топовых TLD очень редко меняются. 98% запросов в корневые DNS-сервера — это запросы по ошибке, обычно из-за того, что клиенты не кэшируют свои результаты как надо. Это стало такой проблемой, что несколько операторов корневых серверов добавили специальные серверы только для того, чтобы отвечать «уходи!» всем людям, которые делают обратные запросы DNS по своим локальным IP-адресам.
Сервера TLD администрируются разными компаниями и правительствами по всему миру (Verisign отвечает за .com). Когда вы покупаете домен в зоне .com, примерно 18 центов уходит в ICANN, и 7 долларов 85 центов уходят в Verisign.
Редко бывает, что забавное название, которое разработчики придумали для своего проекта, становится окончательным, публичным именем продукта. Можно назвать базу данных компаний Delaware (потому что в этом штате зарегистрированы все компании), но можно не сомневаться: когда дело дойдет до продакшена, она будет называться CompanyMetadataDatastore. Но изредка, когда все звезды сходятся и начальник в отпуске, одно название пробирается сквозь щель.
Punycode — это система для кодировки юникода в имена доменов. Проблема, которую она решает, проста: как записать 比薩.com, когда все системы интернета построены вокруг алфавита ASCII, в котором самый экзотический символ — это тильда?
Нельзя просто переключить доменные имена на unicode. Исходные документы, которые отвечают за домены, обязывают кодировать их в ASCII. Каждое устройство в интернете за последние сорок лет, включая маршрутизаторы Cisco и Juniper, которые использовались для доставки этой страницы, работают с учетом этого условия.
Сам веб никогда не ограничивался ASCII. Изначально стандартом должен был ISO 8859-1, который включал в себя все символы из ASCII, плюс набор специальных символов вроде ¼ и буквы с диакритическими знаками вроде ä. Но этот стандарт включал только латинские символы.
Это ограничение HTML’а было окончательно исключено в 2007, и в том же году Юникод стал самым популярным стандартом кодирования символов в вебе. Но домены все еще работали через ASCII.
Как вы могли догадаться, Punycode не был первой попыткой решить эту проблему. Вы скорее всего слышали про UTF-8, популярный способ кодирования Юникода в байты (число 8 в названии «UTF-8» означает 8 бит в одном байте). В 2000 несколько членов Инженерного совета Интернета (Internet Engineering Task Force) придумали UTF-5. Идея заключалась в кодировании Юникода пятибитными наборами. Далее каждые пять бит связывались с разрешенным символом (A-V и 0-9) в доменных именах. Например, если бы у меня был сайт про изучение японского языка, то адрес 日本語.com превратился бы в загадочный M5E5M72COA9E.com.
У такого метода есть несколько недостатков. Во-первых, символы A-V и 0-9 используются в закодированном выводе. То есть, если нужно использовать один из этих символов в самом названии домена, то их пришлось бы кодировать как и другие символы. Получаются очень длинные имена, и это серьезная проблема: каждый сегмент домена ограничен 63 символами. Домен на Бирманском языке был бы ограничен 16 символами. Но у всей этой затеи есть интересные последствия, например, Юникод таким образом можно передавать через код Морзе или телеграммой.
Отдельным вопросом было то, как клиенты будут понимать, что домен был закодирован именно таким способом, и можно показывать пользователю реальное имя вместо M5E5M72COA9E.com в адресной строке. Было несколько предложений, например, задействовать неиспользованный бит в ответе DNS. Но это был «последний неиспользованный бит в заголовке», и люди, отвечающие за DNS «очень не хотели отдавать его».
Еще одна идея заключалась в том, чтобы добавлять ra-- в начало каждого доменного имени, которое использует этот способ кодирования. В то время (середина апреля 2000) не было ни одного домена, который начинался бы с ra--. Я знаю интернет, поэтому уверен: кто-то сразу купил домен с ra— всем назло сразу после публикации того предложения.
Окончательное решение было принято в 2003 — использовать формат Punycode. Он включал в себя дельта-кодирование, которое помогало значительно укоротить закодированные доменные имена. Дельта-кодирование — это особенно хорошая идея в случае с доменами, потому что скорее всего все символы доменного имени находятся примерно в одной области таблицы Юникода. Например, два символа из Фарси будут ближе друг к другу, чем символ из Фарси и символ из Хинди. Чтобы понять, как это работает, давайте взглянем на пример с такой бессмысленной фразой:
يذؽ
В незакодированном виде это три символа[1610, 1584, 1597] (на основе их положения в Юникоде). Чтобы закодировать их, давайте сначала отсортируем их (запомнив исходный порядок): [1584, 1597, 1610]. Теперь можно сохранить наименьшее значение (1584), и расстояние (дельту) до следующего символа (13), и до следующего (23), так что передавать и хранить нужно меньше информации.
Далее Punycode эффективно (очень эффективно!) кодирует эти целые числа в символы, разрешенные в доменных именах, и добавляет xn— в начало строки чтобы сообщить клиентам о кодировании имени. Можно заметить, что все символы Юникода собраны в конце домена. Они хранят не только значения символов, но и их положение в имени. Например, адрес 熱狗sales.com превратится в xn--sales-r65lm0e.com. Когда вы вводите символы Юникода в адресную строку браузера, они всегда кодируются таким способом.
Эта трансформация могла бы быть прозрачной, но тогда может возникнуть серьезная проблема безопасности. Есть символы Юникода, которые выводятся на экран идентично существующим символам ASCII. Например, вы скорее всего не заметите разницу между кириллической буквой “а” и латинской “a”). Если я зарегистрирую кириллический аmazon.com (xn--mazon-3ve.com), то вы можете не понять, что находитесь на другом сайте. По этой причине сайт .ws, выглядит в вашем браузере скучно: xn--vi8hiv.ws.
Первая часть URL — это протокол, по которому нужно производить соединение. Самый распространенный протокол это http. Это простой протокол для передачи документов, который Тим Бернерс-Ли разработал специально для веба. Это был не единственный вариант. Некоторые считали, что нужно использовать Gopher. 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.
HTTP — это очень простой протокол, особенно по сравнению с альтернативами вроде FTP или даже HTTP/2, популярность которого сегодня растет. Во-первых, HTTP полностью текстовый, в нем не используются магические бинарные элементы (которые могли бы значительно улучшить производительность). Тим Бернерс-Ли правильно решил, что текстовый формат позволит поколениям программистов легче разрабатывать и отлаживать приложения, использующие HTTP.
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/IP посылает кучу байтов другому компьютеру, а протокол уровня HTTP объясняет, чем являются эти байты и что они означают.
Можно сделать свой протокол, если захочется, собирая байты из сообщений TCP как угодно. Единственное требование заключается в том, чтобы получатель говорил на том же языке. Поэтому принято стандартизировать эти протоколы.
Конечно, существуют менее важные протоколы. Например, есть протокол цитаты дня Quote of The Day (порт 17), и случайного символа Random Characters (порт 19). Они могут показаться забавными сегодня, но они помогают понять важность универсального протокола для передачи документов, которым был HTTP.
Историю 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 двойной слэш (//) стоит между протоколом и второй частью:
http://eager.io
Этот двойной слэш был унаследован от компьютерной системы Apollo, которая была одной из первых сетевых рабочих станций. У команды Apollo появилась такая же проблема, что у Тима Бернерса-Ли: им нужен был способ отделять путь от машины, в которой находится этот путь. Они решили придумать специальный формат для пути:
//computername/file/path/as/usual
И сэр Тим скопировал эту схему. На самом деле, теперь он жалеет об этом решении. Он хотел бы, чтобы домен (в нашем примере example.com) был бы первой частью пути:
http:com/example/foo/bar/bazМы рассказали о компонентах URL, которые нужны для подключения к конкретному приложению на удаленной машине где-то в интернете. В продолжении этой статьи мы поговорим про компоненты URL, которые обрабатываются удаленным приложением, чтобы вернуть ответ. Это путь, фрагменты, запросы и авторизация.
Хотелось бы включить все это в один пост, но размер уже начинает пугать читателей. Но вторая часть будет стоить потраченного времени. Мы обсудим альтернативные формы URL, которые обдумывал Тим Бернерс-Ли, историю форм и как придумали синтаксис параметров GET-запроса, и как 15 лет спорят о способе создания неизменяемых URL.
habr.com
Что такое URL и где его взять?
это ссылка на что-либо!! ! Единый указатель ресурсов (англ. URL — Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. По‐английски «URL» целиком произносится как /ɜː(ɹ)l/, по‐русски чаще говорят [у-эр-э́л] или [урла́] (сленг) . Ранее назывался Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет. URL был изобретён Тимом Бернерсом-Ли в 1990 году в стенах Европейского совета по ядерным исследованиям (фр. Conseil Européen pour la Recherche Nucléaire, CERN) в Женеве, Швейцария. URL стал фундаментальной инновацией в Интернете. Изначально URL предназначался для обозначения мест расположения ресурсов (чаще всего файлов) во Всемирной паутине. Сейчас URL применяется для обозначения адресов почти всех ресурсов Интернета. Стандарт URL закреплён в документе RFC 1738, прежняя версия была определена в RFC 1630. Сейчас URL позиционируется как часть более общей системы идентификации ресурсов URI, сам термин URL постепенно уступает место более широкому термину URI. Cтандарт URL регулируется организацией IETF и её подразделениями. Изначально локатор URL был разработан как система для максимально естественного указания на местонахождения ресурсов в сети. Локатор должен был быть легко расширяемым и использовать лишь ограниченный набор ASCII‐символов (к примеру, пробел никогда не применяется в URL). В связи с этим, возникла следующая традиционная форма записи URL: <схема>://<логин>:<пароль>@<хост>:<порт>/<url‐путь> В этой записи: схема схема обращения к ресурсу, в большинстве случаев имеется в виду сетевой протокол логин имя пользователя, используемое для доступа к ресурсу пароль пароль, ассоциированный с указанным именем пользователя хост полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста в форме четырёх десятичных чисел, разделённых точками. Числа находятся в интервале от 0 до 255. порт порт хоста для подключения URL‐путь уточняющая информация о месте нахождения ресурса (зависит от протокола) Общепринятые схемы (протоколы) URL включают: ftp — Протокол передачи файлов FTP http — Протокол передачи гипертекста HTTP https — Специальная реализация протокола HTTP, использующая шифрование (как правило, SSL или TLS) gopher — Протокол Gopher mailto — Адрес электронной почты news — Новости Usenet nntp — Новости Usenet через протокол NNTP irc — Протокол IRC prospero — Служба каталогов Prospero Directory Service telnet — Ссылка на интерактивную сессию Telnet wais — База данных системы WAIS xmpp — Протокол XMPP (часть Jabber) file — Имя локального файла data — Непосредственные данные (Data: URL) Экзотические схемы URL: afs — Глобальное имя файла в файловой системе Andrew File System cid — Идентификатор содержимого для частей MIME mid — Идентификатор сообщений для электронной почты mailserver — Доступ к данным с почтовых серверов nfs — Имя файла в сетевой файловой системе NFS tn3270 — Эмуляция интерактивной сессии Telnet 3270 z39.50 — Доступ к службам ANSI Z39.50 skype — Протокол Skype smsto — Открытие редактора SMS в некоторых мобильных телефонах Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьёзным недостатком — в нём можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания. Если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французcкого языка, то нужные нам символы должны быть перекодированы особым образом.
Url адресс это (например) : <a rel=»nofollow» href=»http://www.mail.ru» target=»_blank»>www.mail.ru</a>, <a rel=»nofollow» href=»/» title=»2668:##:http://www.google.ru» target=»_blank» >[ссылка заблокирована по решению администрации проекта]</a> и т. д
ЮРЛ — это в адресной строке ссылка, она нахродится наверху в браузере, на ней отображен домен (название сайта) и томуподобное, его обычно копируют и вставляют куда необходимо
<img src=»//otvet.imgsmail.ru/download/237695886_5ba83473b826a1920acb52b0f674e72c_800.png» alt=»» data-lsrc=»//otvet.imgsmail.ru/download/237695886_5ba83473b826a1920acb52b0f674e72c_120x120.png» data-big=»1″>
это ссылка на что-либо!! ! Единый указатель ресурсов (англ. URL — Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. По‐английски «URL» целиком произносится как /ɜː(ɹ)l/, по‐русски чаще говорят [у-эр-э́л] или [урла́] (сленг) . Ранее назывался Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет. URL был изобретён Тимом Бернерсом-Ли в 1990 году в стенах Европейского совета по ядерным исследованиям (фр. Conseil Européen pour la Recherche Nucléaire, CERN) в Женеве, Швейцария. URL стал фундаментальной инновацией в Интернете. Изначально URL предназначался для обозначения мест расположения ресурсов (чаще всего файлов) во Всемирной паутине. Сейчас URL применяется для обозначения адресов почти всех ресурсов Интернета. Стандарт URL закреплён в документе RFC 1738, прежняя версия была определена в RFC 1630. Сейчас URL позиционируется как часть более общей системы идентификации ресурсов URI, сам термин URL постепенно уступает место более широкому термину URI. Cтандарт URL регулируется организацией IETF и её подразделениями. Изначально локатор URL был разработан как система для максимально естественного указания на местонахождения ресурсов в сети. Локатор должен был быть легко расширяемым и использовать лишь ограниченный набор ASCII‐символов (к примеру, пробел никогда не применяется в URL). В связи с этим, возникла следующая традиционная форма записи URL: <схема>://<логин>:<пароль>@<хост>:<порт>/ В этой записи: схема схема обращения к ресурсу, в большинстве случаев имеется в виду сетевой протокол логин имя пользователя, используемое для доступа к ресурсу пароль пароль, ассоциированный с указанным именем пользователя хост полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста в форме четырёх десятичных чисел, разделённых точками. Числа находятся в интервале от 0 до 255. порт порт хоста для подключения URL‐путь уточняющая информация о месте нахождения ресурса (зависит от протокола) Общепринятые схемы (протоколы) URL включают: ftp — Протокол передачи файлов FTP http — Протокол передачи гипертекста HTTP https — Специальная реализация протокола HTTP, использующая шифрование (как правило, SSL или TLS) gopher — Протокол Gopher mailto — Адрес электронной почты news — Новости Usenet nntp — Новости Usenet через протокол NNTP irc — Протокол IRC prospero — Служба каталогов Prospero Directory Service telnet — Ссылка на интерактивную сессию Telnet wais — База данных системы WAIS xmpp — Протокол XMPP (часть Jabber) file — Имя локального файла data — Непосредственные данные (Data: URL) Экзотические схемы URL: afs — Глобальное имя файла в файловой системе Andrew File System cid — Идентификатор содержимого для частей MIME mid — Идентификатор сообщений для электронной почты mailserver — Доступ к данным с почтовых серверов nfs — Имя файла в сетевой файловой системе NFS tn3270 — Эмуляция интерактивной сессии Telnet 3270 z39.50 — Доступ к службам ANSI Z39.50 skype — Протокол Skype smsto — Открытие редактора SMS в некоторых мобильных телефонах Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьёзным недостатком — в нём можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания. Если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французcкого языка, то нужные нам символы должны быть перекодированы особым образом. Источник: спинной мозг
touch.otvet.mail.ru
URL, интернет-серверы, порты и HTTP
URL адрес
URL адресКогда вы пользуетесь Веб или отправляете электронное письмо, используются имена доменов. Например, в URL адресе (Uniform Resource Locator, URL) «sd-company.su» содержится имя домена sd-company.su. То же можно сказать об этом адресе электронной почты: [email protected]. Этот Email защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script Каждый раз, когда используют доменное имя, в переводе удобного для восприятия людьми имени домена в понятный машинам IP адрес принимают участие DNS серверы. Чтобы вы смогли получить подробные сведения о системе имен доменов, рекомендуем прочесть соответствующую специализированную статью.
К именам доменов верхнего уровня (их еще называют именами доменов первого уровня) относятся RU, SU, COM, ORG, NET, EDU и GOV. В каждом домене верхнего уровня имеется большой список доменов второго уровня. Например, в домене первого уровня COM имеются домены:
Каждое имя в домене верхнего уровня RU должно быть уникальным. Слово, располагающееся в крайней левой позиции, например, www, является именем узла. Оно указывает на имя определенной машины (с определенным IP адресом) в домене. Любой домен может теоретически содержать миллионы имен узлов, при условии, что все они в этом домене уникальны.
DNS серверы принимают запросы от программ и от других серверов имен, касающиеся преобразования доменных имен в IP адреса. При поступлении запроса DNS сервер может выполнить с ним одно из четырех действий:
- Он может в ответ на этот запрос отправить IP адрес, если соответствующий IP адрес запрошенного домена уже известен.
- Он может также связаться с другим DNS сервером и попытаться там найти IP адрес, соответствующий указанному в запросе имени. Он может выполнять эти действия многократно.
- Он может также ответить следующим образом: «Я не знаю IP адреса запрошенного домена, но вот IP адрес DNS сервера, где имеется больше информации».
- Кроме того, он может в ответ на запрос отправить сообщение об ошибке, если указанное в запросе доменное имя неправильное или не существует.
Интернет серверы и клиенты
Интернета действует благодаря интернет серверам. Все подключенные к Интернету машины являются либо серверами, либо клиентами. Серверами называются машины, предоставляющие запущенные на них сервисы другим машинам сети. Машины, предназначенные для пользования указанными выше сервисами серверов, называются клиентами. Есть WEB серверы, почтовые серверы, FTP серверы и тому подобное, предназначенные для удовлетворения потребностей пользователей Интернета в любой точке земного шара.
Когда вы подключаетесь к серверу www.howstuffworks.com, чтобы открыть WEB страницу, то являетесь пользователем, сидящим за клиентской машиной. Вы подключаетесь к WEB серверу HowStuffWorks. Сервер находит запрошенную страницу и отправляет ее вам. Клиенты, связывающиеся с сервером, делают это с определенной целью, поэтому адресуют свои запросы специализированным программам, запущенным на сервере. Например, если пользователь запускает на своей машине WEB браузер, последний будет обмениваться информацией с WEB сервером серверной машины, а не с почтовым сервером.
Серверу присваивается статический IP адрес, который не меняют очень часто. Домашнему компьютеру, который получает доступ в Интернет с использованием модема и коммутируемого соединения, напротив, при каждом соединении с Интернетом, как правило, присваивается поставщиком услуги новый IP адрес. Этот адрес для данной сессии является уникальным и неизменным, однако в следующей сессии может быть совсем другим. Благодаря такому подходу, поставщику услуг Интернета требуется только по одному IP адресу для каждого подключенного в данный момент к Интернету модема, а не для каждого зарегистрированного абонента.
Порты и HTTP
Доступ к сервисам любого сервера осуществляется через пронумерованные порты — по одному для каждого имеющегося на сервере сервиса. Например, если на сервере работает WEB сервер и FTP сервер, обычно доступ к WEB серверу осуществляется через порт 80, а к FTP серверу — через порт 21. Клиенты подключаются к выбранному сервису, используя определенный IP адрес, и через порт с определенным номером.
Когда клиент подключился к требуемому сервису через соответствующий порт, он обменивается с этим сервисом информацией, используя определенный протокол. Протоколы часто представляют собой текстовую информацию, просто описывающую правила обмена данными между клиентом и сервером. Каждый WEB сервер Интернета поддерживает протокол передачи гипертекста (hypertext transfer protocol, HTTP). Подробную информацию о интернет серверах, портах и протоколах можно почерпнуть из статьи о WEB серверах.
Интернет работает благодаря наличию сетей, маршрутизаторов, пунктов доступа к сети, поставщиков услуг Интернета, серверов доменных имен и мощных серверов. Просто поражаешься, когда представишь, что вся эта информация передается в любую точку земного шара за миллисекунды! Перечисленные составляющие Интернета в условиях современной жизни играют очень важную роль — без них не было бы и самого Интернета. А без Интернета жизнь многих из нас была бы совсем другой.
sd-company.su