Узнаём основы работы Интернета за 15 минут в картинках для самостоятельной настройки доменов

Друзья, рад приветствовать вас. Надеюсь, НГ прошёл успешно и без потерь?

Наверняка у вас есть (или был) свой сайт. И, вспоминая первый опыт, вы ужасаетесь от того, сколько всего пришлось сделать: купить домен, купить хостинг, привязать хостинг к домену, разобраться с ФТП, найти данные для подключения к MySQL, установить и настроить свой первый сайт… В одном посте, конечно же, всего не опишешь. Одно перечисление потянет на полноценную статью.

Здесь же я хочу попытаться рассказать об основах, каким образом происходит взаимодействие пользователя на одной стороне (от простейшего — ввод доменного имени сайта в адресную строку), и сервера с содержимым сайта — на другой.

Вам известно, что всё в интернете определяет конкретный адрес — IP-адрес. Одно устройство (это может быть что угодно: компьютер, смартфон, мультиварка — не суть) пытается связаться с другим (пусть это будет сервер). Для этого оно формирует пакет данных, в котором обязательно указывает IP-адреса́ — свой и устройства, к которому происходит запрос. Это нужно для того, чтобы удалённое устройство знало, кому нужно «ответить».

Сейчас в наибольшей степени используется четвёртая версия протокола — IPv4. В ней уникальный адрес может быть представлен как 4-ёх байтное число, что в теории ограничивает максимальное количество адресов до 4 294 967 296. Почему в теории? Просто существуют группы специальных адресов с иным предназначением. Шестая версия — IPv6 — в которой IP-адрес представляется 16-байтным значением (2¹²⁸ — это на 5 порядков больше, чем устройств на 100 миллиардах планет со 100 миллиардами жителей по 100 млрд гаджетов у каждого).

Но вернёмся к нашим реалиям. Когда Интернет только задумывался, никто и представить не мог, что 4 миллиардов может быть недостаточно.

В версии протокола HTTP/1.0 от 1996 года предписывалось каждому узлу сети (сайту, например) иметь уникальный IP-адрес. Но красивых адресов (вроде 4.4.4.4 или 8.8.8.8) было не так много. Кроме того, адреса выделялись организациям пулами (группами), и уже юзерам, которые пользовались услугами данных контор, приходилось выбирать что-то из указанного диапазона (но чаще всё-таки выдавался случайный адрес из свободных). Тут-то и пригодилась система DNS, благодаря которой можно использовать символьные адреса.

Смысл ДНС кроется в том, что существует иерархия серверов, благодаря которой можно узнать, на каком IP-адресе следует искать тот или иной сайт. Основой служит группа корневых серверов, которые имеют фиксированные адреса. «Обратившись» к этим адресам, можно получить IP-адреса серверов, отвечающих за домены верхнего уровня (ru, su, com, net и пр.), который могут сообщить либо IP-адрес запрашиваемого ресурса, либо адрес другого сервера, который знает дополнительную информацию.

Конечно, на корневые сервера создаётся колоссальная нагрузка. Но программы кешируют (временно сохраняют) получаемую информацию, поэтому первый запрос к Яндекс породит 3 подзапроса (на корневой сервер, на сервер, ответственный за зону .ru и на сервер Яндекса). Последующие запросы будут осуществляться сразу на сервер Яндекса. Запросы других сайтов в зоне .ru тоже могут не порождать 3 подзапроса, ведь «корень» уже сообщил IP-адрес ответственного за зону .ru сервера.

После того, как определён IP-адрес требуемого сервера, программы должны сделать следующее:

1. Попытаться соединиться с указанным сервером по 80 порту (для HTTP) или 443 (для HTTPS, защищённое соединение). Данные порты обслуживаются специальной программой (веб-сервером).
2. Отправить HTTP-заголовки, которые укажут веб-серверу, чего же от него требуется.

Программы, работающие в фоновом режиме, в терминологии ОС Unix называются «Демонами». Их аналог в MS Windows — «Службы». Смысл таких программ — «точечное» взаимодействие после наступления какого-либо события. Например, демон веб-сервера Apache — httpd — «слушает» порт 80 для обработки HTTP-соединений. Как только на данный порт пришёл запрос, программа сразу включается в работу, выполняет необходимые действия, после чего освобождает задействованные ресурсы и снова переходит в фоновой режим работы.

О первой версии HTTP уже написано чуть выше. Но ведь бывает, что целая куча сайтов имеет один IP-адрес. Это происходит благодаря следующей версии протокола — HTTP/1.1, которая увидела свет в середине 1999 года и оказалась настолько успешной, что используется до сих пор. Для указания сайта, который запрашивается, используется директива Host в заголовке.

Возможно, с этими бесконечными соединениями у вас возникло ощущение непонимания, как всё работает. На самом деле, всё довольно просто. Сначала программе требуется отправить запрос на удалённый сервер, изъявив желание подключиться по определённому порту. Нотация записи следующая: IP:Port. Здесь, IP — адрес удалённого сервера (может быть домен, в этом случае адрес будет определён благодаря системе DNS), Port — числовое значение порта — 1 до до 65535. Произвольное значение не гарантирует, что сервер согласится принимать подключения. Часть портов уже предопределено: 21 — FTP, 80 — HTTP, 443 — HTTPS и т. п. Иногда административные интерфейсы (панели управления) выносят на порты, отличные от стандратных, например на 81 для HTTP или 444 для HTTPS. В этом случае адресная строка браузера имеет вид: http://site.ru:81 или https://site.ru:444, т. е. указание порта является обязательным.

Главное общение между устройствами осуществляется посредством заголовков. Инициатор соединение (обычно это пользователь) запрашивает какое-то содержимое, а удалённый сервер его возвращает, снабдив соответствующими заголовками. Допустим, пользователь обращается и запрашивает главную страницу ПС Яндекс:

GET / HTTP/1.1
Host: www.yandex.ru
Connection: close

Первая строка содержит метод запроса, путь и версию протокола, вторая — хост, третья указывает (обычно keep-alive или close), следует ли сразу после ответа закрывать соединение. Ответ может выглядеть так:

HTTP/1.1 200 Ok
Server: nginx
Content-Type: text/html; charset=UTF-8
Connection: close

Первая строка сообщает версию протокола, ответ и его расшифровку. Код 200 показывает, что всё в порядке. Другой распространённый код — 404 — страница не найдена. Вторая строка — используемый веб-сервер. Не следует путать эту программу с физическим сервером (компьютером), на дисках которого хранится содержимое сайтов. Третья строка — тип возвращаемого содержимого и кодировка. Тип text/html указавает, что пользователю отсылается обычная страница. Типов существует достаточно много: image/jpeg — картинка в формате .jpg, text/plain — обычный текст, text/xml — .xml-документ (например, rss сайта) и т. п.

Для успешной работы устройствам необходимо общаться, согласно протокола. Можно подключиться на 21 порт и передать HTTP заголовки, но на большинстве серверов этот порт обслуживает FTP-демон, принцип работы которого отличается. Соответственно, устройства друг-друга не поймут и подключение будет разорвано.

Таким образом, общее взаимодействие при просмотре сайтов осуществляется в несколько этапов. Сначала пользователь вводит адрес сайта (название домена) в адресную строку браузера.

Потом осуществляется поиск IP-адреса сервера, который обслуживает заданный ресурс.

После этого, производится попытка подключиться к указанному серверу по определённому порту (чаще всего — 80 или 443).

И, затем, с помощью HTTP-заголовков уточняются запрашиваемый домен (директива Host), путь и прочее.

Остался нераскрытым один аспект — NS сервера (обычно имеют вид ns1.domain.ru и ns2.domain.ru), которые нужно прописывать в управлении доменом. Именно благодаря этим записям сервер, ответственный за зону, может указать IP-адрес сервера, на котором располагается сайт. Вся необходимая информация содержится в зоне (ресурсные DNS записи, или данные DNS). Имеются несколько типов записей, главная из которых — A — содержит IP-адрес сервера, который обслуживает сайт.

Для чего хостеры просят изменить NS-сервера домена? Это делается для того, чтобы пользователям не приходилось объяснять, где и как нужно внести изменения, чтобы сайт стал доступен, начала работать его почта и т. п. NS-сервера поддерживаются силами хостера, все записи туда вносятся автоматически (при регистрации вас всегда просят указать свой домен или зарегистрировать новый).

Но ничего не мешает использовать NS-сервера регистратора. Просто некоторые вещи нужно будет настроить самостоятельно, из интерфейса управления зоной. Самое главное — добавить ресурсную запись A для поддомена @:

@ A IP-адрес_сервера

К сожалению, не все хостеры предоставляют возможность полноценного управления зоной. Например, вы можете захотеть подключить к домену сервис Яндекса «почта для домена» и иметь возможность создать до 1000 почтовых ящиков неограниченного размера. Хостеры же включают размеры всех писем в общее дисковое пространство, выделяемое в рамках тарифного плана.

В этом случае, самостоятельное управление зоной на стороне регистратора домена будет отличным решением: вы создаёте A-запись, ссылая её на сервер со своим сайтом, и создаёте MX-запись, которую направляете на соответствующий поддомен Яндекса. В случае переезда к другому хостеру, не нужно будет изменять NS-сервера, заново прописывать MX и ждать несколько часов (а то и дней), пока информация в DNS обновится; вы просто измените A-запись, в которой укажете другой IP-адрес. Всё просто.

Но не всё так прекрасно, как хотелось бы, есть ложка дёгтя — некоторые регистраторы не предоставляют возможность управления зоной, либо делают это на платной основе. В таком случае может помочь замечательный сервис, указанный выше — pdd.yandex.ru. Вы просто нажимаете ссылку Подключить домен, вводите адрес своего домена. Теперь остаётся только изменить NS-сервера в панели регистратора (это позволяется делать у всех) на предоставленные Яндексом. Через некоторое время, когда данные в DNS обновятся, можно будет управлять зоной через удобный визуальный редактор. Для этого во вкладке Мои домены кликаете на подключенный домен → Редактор DNS. Пусть доступны не все возможные типы записей, но для подавляющегося большинства случаев тех основных, что доступны, хватит. Для домена domain.name записи могут выглядеть так:

Остаётся ввести лишь Значение записи — IP-адрес сервера, который обслуживает сайт.

По аналогии с этим, можно легко создавать поддомены и направлять их на совершенно разные сервера. Для этого добавляете A-запись, в качестве Хоста указываете требуемый поддомен, а в Значение записи — IP-адрес.

Помимо этого, есть возможность указать, чтобы абсолютно все поддомены ссылались на один сервер. Сделать это можно, добавив запись типа A и указав в качестве хоста звёздочку — *. Это правило имеет самый низкий приоритет, поэтому не нужно бояться, что из-за этого собьются уже существующие поддомены.

Теперь и вы, друзья, самостоятельно можете легко «рулить» своими доменами, не завися от причуд регистраторов и хостеров. Благодаря работе с зоной можно даже выделять адреса своим друзьям и знакомым на поддоменах своего основного домена — с одной стороны, им не придётся регистрировать домен, чтобы попробовать себя в статусе блоггера, с другой — полноценный сайт на WordPress даст гораздо больше возможностей, чем бесплатный сервис.

Успехов! И с наступающим Рождеством!