Самоучитель PHP 4 - Котеров Д. В

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

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

Конечно, не обязательно, чтобы все компьютеры, имеющие различные доменные имена, были разными или даже имели уникальные IP-адреса: вполне возможна ситуация, когда на одной и той же машине на одном и том же IP-адресе располагаются сразу несколько доменных имен.

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

Порт

Итак, мы ответили на первый поставленный вопрос — как адресовать отдельные машины в Интернете. Теперь давайте поглядим, как нам быть с программным обеспечением, использующим Сеть для обмена данными.

До сих пор мы расценивали машины, подключенные к Интернету, как некие неделимые сущности. Так оно, в общем-то, и есть (правда, с некоторыми оговорками) с точки зрения протокола IP. Но TCP использует в своей работе несколько другие понятия. А именно, для него отдельной сущностью является процесс — программа, запущенная где-то на компьютере в Интернете. Именно между процессами, а не между машинами, и осуществляется обмен данными в терминах протокола TCP. Мы уже знаем, как идентифицируются отдельные компьютеры в Сети. Осталось рассмотреть, как же TCP определяет тот процесс, которому нужно доставить данные.

Пусть на некоторой системе выполняется программа (назовем ее Клиент), которая хочет через Интернет соединиться с какой-то другой программой (Сервером) на другой машине в Сети. Для этого должен выполняться ряд условий, а именно:

rпрограммы должны "договориться" о том, как они будут друг друга идентифицировать;

rпрограмма Сервер должна находиться в режиме ожидания, что сейчас к ней ктото подключится;

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

Теперь посмотрим, какие действия предпринимает Клиент. Он, как мы условились, знает следующее:

rIP-адрес машины, на которой запущен Сервер;

rномер порта, который использует Сервер.

Как видим, этой информации вполне достаточно, поэтому Клиент посылает драйверу TCP команду на соединение с машиной, расположенной по заданному IP-адресу с указанием нужного номера порта. Поскольку Сервер "на том конце" готов к этому, он откликается, и соединение устанавливается.

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

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

Терминология

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

Сервер

Сервер — любой отдельно взятый компьютер в Интернете, который позволяет другим машинам, грубо говоря, использовать себя в качестве "посредника" при передаче данных. Также все серверы участвуют в вышеописанной "лавине" поиска компьютера по ее IP-адресу, на многих хранится какая-то информация, доступная или нет извне. Сервер — это именно машина ("железо"), а не логическая часть Сети, он может иметь несколько различных IP-адресов (не говоря уже о доменных именах), так что вполне может выглядеть из Интернета как несколько независимых систем.

Только что я сказал, что сервер — это "железо". Пожалуй, это слишком механистический подход. Мы можем придерживаться и другой точки зрения, тоже в некоторой степени правильной. Отличительной чертой сервера является то, что он использует один-единственный стек TCP/IP, т. е. на нем запущено только по одному "экземпляру" драйверов протоколов. Пожалуй, это будет даже правильнее, хотя в настоящее время оба определения почти эквивалентны (просто современный компьютер не настолько мощен, чтобы на нем могли бы функционировать одновременно две операционные системы, а следовательно, и несколько стеков TCP/IP). Посмотрим, как будет с этим обстоять дело в будущем.

У термина "сервер" есть и еще одно, совершенно другое, определение — это программа (в терминологии, TCP — процесс), обрабатывающая запросы клиентов. Например, приложение, обслуживающее пользователей WWW, называется Webсервером. Как правило, из контекста будет ясно, что конкретно имеется в виду. Все же, чтобы не путаться, иногда я такие программы буду называть сетевыми демона-

ми.

Узел

Любой компьютер, подключенный к Интернету, имеет свой уникальный IP-адрес. Нет адреса — нет узла. Узел — совсем не обязательно сервер (типичный пример — клиент, подключенный через модем к провайдеру). Вообще, мы можем дать такое определение: любая сущность, имеющая уникальный IP-адрес в Интернете, называется узлом. С этой (логической) точки зрения Интернет можно рассматривать, как множество узлов, каждый из которых потенциально может связаться с любым другим. Заметьте, что на одной системе может быть расположено сразу несколько узлов, если она имеет несколько IP-адресов. Например, один узел может заниматься только доставкой и рассылкой почты, второй — исключительно обслуживанием WWW, а на третьем работает DNS-сервер.

Помните, мы говорили о том, что TCP использует термин "процесс", и каждый процесс для него однозначно идентифицируется IP-адресом и номером порта. Так вот, этот самый IP-адрес и есть узел.

Порт

Некоторое число, которое идентифицирует программу, желающую принимать данные из Интернета. Таким образом, порт — вторая составляющая адресации TCP. Любая программа, стремящаяся передать данные другой, должна знать номер порта, который закреплен за последней. Например, традиционно Web-серверу выделяется порт с номером 80, поэтому, когда вы набираете какой-нибудь адрес в браузере, запрос идет именно на порт 80 указанного узла.

Сетевой демон

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

же FTP- и Telnet-серверы.

Сам термин "сетевой демон" возник на базе устоявшейся терминологии Unix. В этой системе демоном называют программу, которая постоянно работает на машине в фоновом режиме, обычно с системными привилегиями суперпользо- вателя (то есть, эта программа может делать на машине все, что ей угодно, и не подчиняется правам доступа обычных пользователей). Демон не имеет ни- какой связи с терминалом (экраном и клавиатурой), поэтому не может ни при- нимать данные с клавиатуры, ни выводить их на экран. Вот из-за этой "бес- телесности" его и называют демоном.

Впрочем, к Web-программированию написание сетевых демонов не имеет почти никакого отношения, поскольку это — удел системного программирования. И все же

скажу о них пару слов, т. к. эта область иногда довольно близко примыкает к Webпрограммированию. Написание сетевых демонов — дело непростое и, к тому же, обычно требует полного контроля над "железом" сервера. Фирмы, "продающие" виртуальные хосты в Интернете (хостинг-провайдеры), не позволяют этого делать из соображений безопасности, а также из-за того, что такая программа постоянно работает на компьютере и отнимает процессорное время. Поскольку у многих нет своего собственного узла в Сети (а это стоит обычно около 100—200 долларов в месяц), возможность создавать такие программы доступна далеко не всем, потому мы не будем касаться ее в этой книге.

Провайдер

Провайдер — организация, имеющая несколько модемных входов, к которым могут подключаться пользователи для доступа в Интернет. Все это обычно происходит не бесплатно (для пользователей, разумеется).

Хост

Хост — с точки зрения пользователя как будто то же, что и узел. В общем-то, эти понятия очень часто смешивают. Это обусловлено тем, что любой узел является хостом. Но хост — совсем не обязательно отдельный узел, если это — виртуальный хост. Часто хост имеет собственное уникальное доменное имя. Иногда (обычно просто чтобы не повторяться) я буду называть хосты серверами, что, вообще говоря, совершенно не верно. Фактически, все, что отличает хост от узла — это то, что он может быть виртуальным. Итак, еще раз: любой узел — хост, но не любой хост — узел, и именно так я буду понимать хост в этой книге.

Виртуальный хост

Это — хост, не имеющий уникального IP-адреса в Сети, но, тем не менее, доступный указанием какого-нибудь дополнительного адреса (например, его DNS-имени). В последнее время число виртуальных хостов в Интернете постоянно возрастает, что связано с повсеместным распространением протокола HTTP 1.1. С точки зрения Webбраузера (вернее, с точки зрения пользователя, который этим браузером пользуется) виртуальный хост выглядит так же, как и обычный хост — правда, его нельзя адресовать по IP-адресу. К сожалению, все еще существуют версии браузеров, не поддерживающие протокол HTTP 1.1, которые соответственно не могут быть использованы для обращения к таким ресурсам.

Понятие "виртуальный хост" не ограничивается только службой Web. Многие другие сервисы имеют свои понятия о виртуальных хостах, совершенно не свя-

занные с Web и протоколом HTTP 1.1. Сервер sendmail службы SMTP (Simple Mail Transfer Protocol — Простой протокол передачи почты) также использует понятие "виртуальный хост", но для него это — лишь синоним главного, основ- ного хоста, на котором запущен сервер. Например, если хост syn.com являет- ся синонимом для microsoft.com, то адрес E-mail my@syn.com на самом де- ле означает my@microsoft.com. Примечательно, однако, что виртуальный хост и в этом понимании не имеет уникального IP-адреса.

Хостинг-провайдер (хостер)

Организация, которая может создавать хосты (виртуальные или обычные) в Интернете и продавать их различным клиентам, обычно за определенную плату. Существует множество хостинг-провайдеров, различающихся по цене, уровню обслуживания, поддержке telnet-доступа (то есть доступа в режиме терминала к операционной системе машины) и т. д. Они могут оказывать услуги по регистрации доменного имени в Интернете, а могут и не оказывать. При написании этой книги я рассчитывал, что читатель собирается воспользоваться услугами такого хостинг-провайдера, который предоставляет возможность использования PHP (их сейчас большинство). Если вы еще не выбрали хостинг-провайдера и только начинаете осваивать Webпрограммирование, не беда: во второй части книги подробно рассказано, как можно установить и настроить собственный Web-сервер на любом компьютере с установленной операционной системой Windows. (Это можно сделать даже на той самой машине, на которой будет работать браузер — ведь драйверу протокола TCP совершенно безразлично, где выполняется процесс, к которому будет осуществлено подключение, хоть даже и на том же самом компьютере.) Используя этот сервер, вы сможете немного потренироваться. Кроме того, он незаменим при отладке тех программ, которые вы в будущем планируете разместить на настоящем хосте в Интернете.

Хостинг

Те услуги, которые предоставляют клиентам хостинг-провайдеры.

Сайт

Сайт — это часть логического пространства на хосте, состоящая из одной или нескольких HTML-страниц (иногда представляемых в виде HTML-документов). Хост вполне может содержать сразу несколько сайтов, размещенных, например, в разных его каталогах. Таким образом, сайт — термин весьма условный, обозначающий некоторый логически организованный набор страниц.

HTML-документ

Файл, содержащий данные в формате HTML.

Страница (или HTML-страница)

Адресуемая из Интернета минимальная единица текстовой информации службы World Wide Web, которая может быть затребована у Web-сервера и отображена в браузере. Часто страница представлена отдельным HTML-документом, однако в последнее время число таких страниц постоянно сокращается — чаще они генерируются автоматически "на лету" какой-нибудь программой и тут же отсылаются клиенту. Например, гостевая книга, в который пользователь может оставить текстовое сообщение, — пример страницы, не являющейся HTML-документом в обычном смысле. Язык HTML (Hypertext Markup Language — Язык разметки гипертекста) позволяет вставлять в страницы ссылки на другие страницы. Щелкнув кнопкой мыши на поле ссылки, пользователь может переместиться к тому или иному документу. Впрочем, подразумевается, что читатель более-менее знаком с языком HTML, а потому в этой книге о нем дается минимум сведений — в основном только те, которые касаются форм.

Web-программирование

Этот термин будет представлять для нас особый интерес, потому что является темой книги, которую вы держите в руках, уважаемый читатель. Давайте же наконец проставим все точки над "i".

Только что упоминалось, что страница и HTML-документ — вещи несколько разные, а также то, что существует возможность создания страниц "на лету" при запросе пользователя. Разработка программ, которые занимаются формированием таких страниц, и есть Web-программирование. Все остальное (в том числе, администрирование серверов, разграничение доступа для пользователей и т. д.) не имеет к Webпрограммированию никакого отношения. Фактически, для работы Web-программиста требуется только наличие правильно сконфигурированного и работающего хостинга (возможно, купленного у хостинг-провайдера, в этом случае уж точно среда будет настроена правильно), и это все.

По большому счету эта книга посвящена именно Web-программированию, за исключением второй части и Приложений. Во второй части рассказано о том, как за минимальное время настроить "домашний" хостинг на своей собственной машине, пусть даже и не подключенной к Интернету, т. е. стать "сам себе хостером". Это не так бесполезно, как может показаться, и вскоре вы поймете, почему.

Между прочим, представленная терминология довольно-таки спорная — в раз- ных публикациях используются различные термины. Например, однажды я ви- дел, как хостом называлась любая сущность, имеющая уникальный IP-адрес в Интернете. Лично я с этим не согласен и буду называть эту сущность узлом.

World Wide Web и URL

В наше время одной из самых популярных "служб" Интернета является World Wide Web, Web или WWW (все три термина совершенно равносильны). Действительно, большинство серверов Сети поддерживают WWW и связанный с ним протокол передачи HTTP (Hypertext Transfer Protocol — Протокол передачи гипертекста). Служба привлекательна тем, что позволяет организовывать на хостах сайты — хранилища текстовой и любой другой информации, которая может быть просмотрена пользователем в интерактивном режиме.

Я думаю, каждый хоть раз в жизни набирал какой-нибудь "адрес" в браузере. Он называется URL (Universal Resource Locator — Универсальный идентификатор ресурса) и обозначает в действительности нечто большее, нежели чем просто адрес. Для чего же нужен URL? Почему недостаточен лишь один DNS-адрес?

Ответ довольно-таки очевиден. Действительно, каждый Web-сайт обычно хранит в себе множество документов. Следовательно, нужно иметь механизм, который бы позволял пользователю ссылаться на конкретный документ внутри указанного хоста.

В общем случае URL выглядит примерно так:

http://www.somehost.com:80/path/to/document.html

Давайте рассмотрим чуть подробнее каждую логическую часть этого URL.

Протокол

Часть URL, предваряющая имя хоста и завершающаяся двумя косыми чертами (в нашем примере http://), указывает браузеру, какой высокоуровневый протокол нужно использовать для обмена данными с Web-сервером. Обычно это HTTP, но могут поддерживаться и другие протоколы. Например, протокол HTTPS позволяет передавать информацию в специальном зашифрованном виде, чтобы злоумышленники не могли ее перехватить, — конечно, если Web-сервер способен с ним работать. Нужно заметить, что все подобные протоколы базируются на сервисе, предоставляемом TCP, и по большей части представляют собой лишь набор текстовых команд. В следующей главе мы убедимся в этом утверждении, разбирая, как работает протокол HTTP.

Имя хоста

Следом за протоколом идет имя узла, на котором размещается запрашиваемая страница (в нашем примере — www.somehost.com). Это может быть не только доменное имя хоста, но и его IP-адрес. В последнем случае, как нетрудно заметить, мы сможем обращаться только к узлам (невиртуальным хостам), потому что лишь они однозначно идентифицируются указанием их IP-адреса.

Порт

Сразу за именем хоста через двоеточие может следовать (а может и быть опущен) номер порта. Исторически сложилось, что для протокола HTTP стандартный номер порта — 80 (или 81). Именно это значение используется браузером, если пользователь явно не указал номер порта. Как мы знаем, порт идентифицирует постоянно работающую программу на сервере (или, как ее нередко называют, сетевой демон), в частности, порт 80 связывается с Web-сервером, который и осуществляет обработку HTTP-запросов клиентов и пересылает им нужные документы. Существуют и другие демоны, например, FTP и Telnet, но к ним нельзя подключиться с помощью браузера.

Путь к странице

Наконец, мы дошли до последней части адресной строки — пути к файлу страницы (в нашем примере это /path/to/document.html). Как уже упоминалось, совершенно не обязательно, чтобы эта страница действительно присутствовала, — вполне типична ситуация, когда страницы создаются "на лету" и не представлены отдельными файлами в файловой системе сервера. Например, сайт новостей может использовать виртуальные пути типа /Y/M/N.html для отображения всех новостей за число N ме-

сяца M года Y, так что пользователь, набрав в браузере адрес наподобие http://новострой_сервер/2000/

10/20.html, сможет прочитать новости за 20 октября 2000 года. При этом файла с именем 20.html физически нет, существует только виртуальный путь к нему, а всю работу по генерации страницы берет на себя программное обеспечение сервера (в последней части этой книги я расскажу, как такое программное обеспечение можно написать).

Есть и другой механизм обработки виртуальных путей, когда запрошенные файлы представляют собой статические объекты, но располагаются где-то в другом месте. С точки зрения программного обеспечения путь к документу отсчитывается от некоторого корневого каталога, который указывает администратор сервера. Практически все серверные программы позволяют создавать псевдонимы для физических путей. Например, если мы вводим:

http://www.somehost.com/cgi-bin/something

отсюда не следует, что существует каталог cgi-bin, — это может быть лишь имя псевдонима, ссылающегося на какую-то другую каталог.

Расширение html (от HyperText Markup Language — Язык разметки гипертекста) принято давать документам со страницами Web. HTML представляет собой язык, на котором задается расположение текста, рисунков, гиперссылок и т. д. Кроме html часто встречаются и другие форматы данных: gif, jpg — для изображений, cgi, pl — для сценариев (программ, запускаемых на сервере) и т. д. Вообще говоря, сервер можно настроить таким образом, чтобы он корректно работал с любыми расширениями, например, никто не запрещает нам сконфигурировать его так, чтобы файлы

с расширением htm также рассматривались как HTML-документы (что часто и делается).

Браузеру совершенно все равно, какое расширение у запрошенного объекта — он ориентируется по другому признаку.