Четверг , 28 Март 2024
ДомойПубликацииУзнаём основы работы Интернета за 15 минут в картинках для самостоятельной настройки доменов

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

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

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

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

Основы работы Сети

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

Запрос-ответ в архитектуре клиент-сервер

Сейчас в наибольшей степени используется четвёртая версия протокола — IPv4. В ней уникальный адрес может быть представлен как 4-ёх байтное число, что в теории ограничивает максимальное количество адресов до 4 294 967 296. Почему в теории? Просто существуют группы специальных адресов с иным предназначением. Шестая версия — IPv6 — в которой IP-адрес представляется 16-байтным значением (2128 — это на 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 даст гораздо больше возможностей, чем бесплатный сервис.

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

Рейтинг: 0

Автор публикации

2 070
не в сети 11 месяцев

x64 (aka andi)

Комментарии: 2893Публикации: 405Регистрация: 02-04-2009
Так себеНеплохоХорошоЗамечательноСупер! (3 голосов, в среднем: 5,00 из 5)
Загрузка...

8 комментариев

  1. Надежда Давыдова

    Я мало что поняла из этого серьезного труда. Для меня все эти DNS и A-записи просто темный лес. Когда меняла ip своего сайта (причем несколько раз), очень нервничала, выставляя эти все показатели. Но вроде получилось. Зато потом вечно с сотого раза попадаю на свой FTP. Просто загадка какая-то. Думаю, это просто из-за того, что все кажется безумно сложным, начинаешь нервничать и путать эту циферию.

    Рейтинг: 0
    • В том и беда, что всё наслаивается друг на друга и кажется жутким до ужаса.
      На деле же, после смены хостинга пользователю нужно (на стороне регистратора) либо сменить NS-сервера, либо A-запись.

      Рейтинг: 0
      • Надежда Давыдова

        Я из-за этих сложностей все время оттягиваю переезд, достал этот Таймвеб! И другие хостинги все хвалят каждый на свой манер, не знаю, как бы не поменять шило на мыло. У меня частенько сайт бывает недоступен, из-за этого даже вылетела статья хорошая из индекса Яши, потеря трафика, понижение позиций…

        Рейтинг: 0
        • Про Таймвеб наслышан, и плохого в основном.
          Исключительно качественного виртуального хостинга, мне думается, не существует в природе. Но если развиться до своего сервера, или хотя бы VPS, уже можно делать много хорошестей разной степени крутости.
          Тут как ведь бывает, может повезти, и соседи на сервере будут «нулевики», практически не создающие нагрузки. А значит, и сайт летать всегда будет. Но может быть и совсем даже наоборот, когда десяток аккаунтов активно потребляют ресурсы.

          Рейтинг: 0
  2. Хорошо, что теперь есть эта статья, в которой понятно и подробно расписаны принципы DNS и настройки. Когда я впервые полез в DNS, такой статьи найти не мог, многое делал методом тыка

    Рейтинг: 0
  3. Спасибо за статью — заинтересовало использование NS Яндекса. «Бум думать».

    Рейтинг: 0

Оставить комментарий

Политика конфиденциальности

Наш сайт использует файлы cookies, чтобы улучшить работу и повысить эффективность сайта. Продолжая работу с сайтом, вы соглашаетесь с использованием нами cookies и политикой конфиденциальности.

Принять