И все-таки обычным людям довольно неудобно работать с IP-представлением адреса. Действительно, куда как проще запомнить символьное имя, чем набор чисел. Чтобы облегчить простым пользователям работу с Интернетом, придумали систему DNS (Domain Name System — Система имен доменов).

Итак, при использовании DNS любой компьютер в Сети может иметь не только IP-адрес, но также и символическое имя. Выглядит оно примерно так:
www.somehost.msu.su
То есть, это набор слов (их число произвольно), опять же соединенных точкой. Каж­дое такое сочетание слов называется доменом N-го уровня (например, su — домен первого уровня, msu.su — второго, somehost.msu.su — третьего и т. д.)
Вообще говоря, полное DNS-имя выглядит немного не так: в его конце обязательно стоит точка, например:
www.somehost.msu.su.
Именно такое (вообще-то, и только такое) представление является правильным, но браузеры и другие программы часто позволяют нам опускать завершающую точку. В принятой нами терминологии будем называть эту точку доменом нулевого уровня, или корневым доменом.

Нужно заметить, что одному и тому же IP-адресу вполне может соответствовать сразу несколько доменных имен. Каждое из них ведет в одно и то же место — к единствен­ному IP-адресу. Благодаря протоколу HTTP 1.1 (мы вскоре кратко рассмотрим его особенности) Web-сервер, установленный на машине и откликающийся на какой-либо запрос, способен узнать, какое доменное имя ввел пользователь, и соответствующим образом среагировать, даже если его IP-адресу соответствует несколько доменных имен. В последнее время HTTP 1.1 применяется практически повсеместно — не то, что несколько лет назад, поэтому все больше и больше серверов используют его в качестве основного протокола для доступа к Web.
Интересен также случай, когда одному и тому же DNS-имени сопоставлены несколь­ко разных IP-адресов. В этом случае служба DNS автоматически выбирает тот из ад­ресов, который, по ее мнению, ближе всего расположен к клиенту, или который давно не использовался, или же наименее загружен (впрочем, последняя оценка может быть весьма и весьма субъективна). Эта возможность часто задействуется, когда Web-сервер становится очень большим (точнее, когда число его клиентов начинает пре­вышать некоторый предел) и его приходится обслуживать сразу нескольким компью­терам. Такая схема используется, например, на сайте компании Netscape.
Как же ведется поиск по DNS-адресу? Для начала он преобразуется специальными DNS-серверами, раскиданными по всему миру, в IP-адрес. Давайте посмотрим, как это происходит. Пусть клиентом выдан запрос на определение IP-адреса машины www.host.ru. (еще раз обратите внимание на завершающую точку! — это не конец предложения). Чтобы его обработать, первым делом посылается запрос к так назы­ваемому корневому домену (точнее, к программе — DNS-серверу, запущенному на этом домене), который имеет имя "." (на самом деле его база данных распределена по нескольким компьютерам, но для нас это сейчас несущественно). Запрос содержит команду: вернуть IP-адрес машины (точнее, IP-адрес DNS-сервера), на котором рас­положена информация о домене ru. Как только IP-адрес получен, по нему происходит аналогичное обращение с просьбой — определить адрес, соответствующий домену host внутри домена ru внутри корневого домена ".". В конце у предпоследней машины запрашивается IP-адрес поддомена www в домене.
Важно, что каждый домен "знает" все о своих поддоменах, а те, в свою очередь — о своих, т. е. система имеет некоторую иерархичность. Корневой домен, как мы уже заметили, принято называть доменом нулевого уровня, домен ru. (в нашем приме­ре) — первого, host.ru. — второго уровня, ну и т. д. При изменении доменов неко­торого уровня об этом должны узнать все домены, родительские по отношению к не­му, для чего существуют специальные протоколы синхронизации. Нам сейчас нет нужды вникать, как они действуют — скажу только, что распространяются сведения об изменениях не сразу, а постепенно, спустя некоторое время, задаваемое админист­ратором DNS-сервера, и рассылкой также занимаются DNS-серверы.
Просто? Не совсем. Представьте, какое бы произошло столпотворение на корневом домене ".", если бы все запросы на получение IP-адреса проходили через него. Чтобы этого избежать, практически все машины в Сети кэшируют информацию о DNS-запросах, обращаясь к корневому домену (и доменам первого уровня — ru, com и т. д.) лишь изредка для обновления этого кэша. Например, пусть пользователь, под­ключенный через модем к провайдеру, впервые соединяется с машиной www.host.ru. В этом случае будет передан запрос корневому домену, а затем, по цепочке, под домену host и, наконец, домену www. Если же пользователь вновь обра­тится к www.host.ru., то сервер провайдера сразу же вернет ему нужный IP-адрес, потому что он сохранил его в своем кэше запросов ранее. Подобная технология по­зволяет значительно снизить нагрузку на DNS-серверы в Интернете. В то же время у нее имеются и недостатки, главный из которых — вероятность получения ложных данных, например, в случае, если хост host.ru. только что отключился или сменил свой IP-адрес. Так как кэш обновляется сравнительно редко, мы всегда можем столк­нуться с такой ситуацией.
Конечно, не обязательно, чтобы все компьютеры, имеющие различные доменные имена, были разными или даже имели уникальные IP-адреса: вполне возможна ситуация, когда на одной и той же машине на одном и том же IP-адресе располагаются сразу несколько доменных имен.

• программы должны "договориться" о том, как они будут друг друга идентифици­ровать;
• программа Сервер должна находиться в режиме ожидания, что сейчас к ней кто-то подключится;

Давайте остановимся на первом пункте чуть подробнее. Термин "договориться" тут не совсем уместен (примерно так же милиция "договаривается" с только что задер­жанным бандитом о помещении его в тюрьму). На самом деле программа Сервер, как только она запускается, говорит драйверу TCP, что она собирается использовать для обмена данными с Клиентами некоторый идентификатор, или порт, целое число в диапазоне от 0 до 65 535 (именно такие числа могут храниться в ячейке памяти раз­мером в 2 байта). TCP регистрирует это в своих внутренних таблицах — разумеется, только в том случае, если какая-нибудь другая программа уже не "заняла" нужный нам порт (в последнем случае происходит ошибка). Затем Сервер переходит в режим ожидания поступления запросов, приходящих на этот порт. Это означает, что любой Клиент, который собирается вступить в "диалог" с Сервером, должен знать номер его порта. В противном случае TCP-соединение невозможно: куда передавать данные, если не знаешь, к кому подключиться?
Теперь посмотрим, какие действия предпринимает Клиент. Он, как мы условились, знает следующее:

• IP-адрес машины, на которой запущен Сервер;
• номер порта, который использует Сервер.

Как видим, этой информации вполне достаточно, поэтому Клиент посылает драйверу TCP команду на соединение с машиной, расположенной по заданному IP-адресу с указанием нужного номера порта. Поскольку Сервер "на том конце" готов к этому, он откликается, и соединение устанавливается.
Только что я употребил слово "откликается", подразумевая, что Сервер отправляет какое-то сообщение Клиенту о том, что он готов к обмену данными. Но вспомним, что для TCP существует только два понятия для идентификации процесса: адрес и порт. Так куда же направлять "отклик" Сервера? Очевидно, последний должен каким-то образом узнать, какой порт будет использовать Клиент для приема сообщений от него (ведь мы знаем, что принимать данные можно, только зарезервировав для этого у TCP номер порта). Эту информацию ему как раз и предоставляет драйвер TCP на машине Клиента, который непосредственно перед установкой соединения выбирает незанятый порт из списка свободных на данный момент портов на клиентском ком­пьютере и "присваивает" его процессу Клиент. Затем драйвер информирует о номере порта Сервер в первом же сообщении о желании установить соединение. Собственно, это и составляет смысл такого сообщения.

Как только обмен "приветственными" сообщениями закончен (его еще называют "тройным рукопожатием", потому что в общей сложности посылается 3 таких сооб­щения), между Клиентом и Сервером устанавливается логический канал связи. Про­граммы могут использовать его, как обычный канал Unix (это напоминает случай файла, открытого на чтение и запись одновременно). Иными словами, Клиент может передать данные Серверу, записав их с помощью системной функции в канал, а Сер­вер — принять их, прочитав из канала. Впрочем, мы вернемся к этому процессу бли­же к концу книги, когда будем рассматривать функцию PHP fsockopen().

Терминология
Далее в этой статье я буду часто применять некоторые термины, связанные с "сущностями" в сети Интернет. Чтобы не было разногласий, сразу условимся, что я буду по­нимать под конкретными понятиями. Перечисляю их в том порядке, в котором, на мой взгляд, они идут по логике вещей, чтобы ни одно предыдущее слово не "цепля­лось" за следующее. Это — порядок "от простого к сложному". Собственно, именно по этому принципу построена вся статья, которую вы читаете.