Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

170

Часть

III. Web-протоколы

клиент находится вблизи локального DNS-сервера. Близость ХУеЬ-клиента сокра-

щает время ожидания при обработке Web-занросов и снижает объем сетевых ре-

сурсов, требующихся для доставки 1Р-накетов. Решение, какой IP-адрес возвра-

щать, может основываться на различных факторах, в числе которых близость

к клиенту, нагрузка на сеть и нагрузка на ренлики сервера.

Как правило, ответ на DNS-занрос может кэшироваться достаточно продолжи-

тельное время в зависимости от значения ноля TTL. Значения TTL может достигать

дней или даже недель. Однако большие значения TTL не дают возможности

DNS-серверу big.com контролировать, к каким репликам www.big.com осуществля-

ется доступ. Чтобы добиться большей степени контроля, DNS-ответы должны ис-

пользовать меньшие значения TTL, порядка минут. Это гарантирует, что локальный

DNS-сервер не будет кэшировать ответ слишком долго. По истечении времени хра-

нения записи в кэше локальный DNS-сервер не сможет обработать следующий за-

прос от преобразователя, не связываясь с DNS-сервером big.com повторно. Это дает

DNS-серверу возможность отвечать различными IP-адресами для www.big.com. Од-

нако это также требует, чтобы Web-браузер дольше ожидал завершения вызова

gethostbynameQ при истечении времени хранения кэшировагнюй информации на ло-

кальном DNS-сервере. Помимо этого, небольшие значения TTL ведут к более высо-

кой загрузке системы в целом. Инфраструктура DNS не была предназначена для

поддержки выравнивания нагрузки на серверы. Рост Web и уменьшение значений

TTL поднял вопрос об изменении и расширении инфраструктуры DNS. Методы на-

правления клиентских запросов репликам подробнее обсуждаются в главе И (раз-

дел 11.12).

5.4, Протоколы прикладного уровня

Приложения выполняются на компьютерах в сети и взаимодействуют через

протоколы прикладного уровня. Протоколы прикладного уровня определяют син-

таксис и семантику обмена сообщениями между оконечными системами. Синтак-

сис определяет формат сообщений, тогда как семантика диктует, как приложения

должны интерпретировать сообщения и отвечать отправителю. В этом разделе бу-

дут описаны протоколы, лежащие в основе четырех Inteгnet-lIpилoжeний: Telnet,

передача файлов, электронная почта и группы новостей, которые были предшест-

венниками Web. Мы обсудим, как особенности каждого из протоколов прикладно-

го уровня соотносятся с назначением приложений, а также поговорим об их взаи-

модействии с транспортным уровнем.

5,4.1.

Протокол Telnet

Протокол Telnet [PR93J дает возможность пользователю взаимодействовать

с удаленным компьютером. Клиентская программа, выполняющаяся на компьюте-

ре пользователя, взаимодействует по протоколу Telnet с серверной программой,

выполняющейся на удаленном компьютере.

ПРИМЕНЕНИЕ TELNET

На первых порах существования ARPANET главным назначением сети было дать

возможность пользователю в одном месте получить доступ к компьютеру, находяще-

муся в другом месте. Пусть у пользователя есть учетная запись на локальном компью-

тере и учетная запись на удаленном компьютере. Пользователь запускает Telnet-кли-

Глава 5. Протоколы, связанные с HTTP 171

ент на локальной компьютере для соединения с Telnet-сервером на удалегнюм компь-

ютере. Предположим, что пользователь вводит "telnet big.foo.gov". Telnet-клиент

выполняет вызов gethostbynameQ для определения IP-адреса big.foo.gov. Затем кли-

ент создает сокет для взаимодействия с Telnet-сервером. Сервер запрашивает у

пользователя идентификатор для входа в систему

—

имя учетной записи пользовате-

ля на удаленгюй машине — и пароль. В большинстве случаев пользователи Telnet

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

действовали с локальным компьютером. Клиент и сервер Telnet просто передают

данные в прямом и обратном направлении.

ПРОТОКОЛ TELNET

Telnet-клиeIIт выполняет две важные функции: взаимодействие с терминалом

пользователя на локальном компьютере и обмен сообщениями с Telnet-сервером.

По умолчанию Telnet-клиент соединяется с удаленным компьютером по порту 23,

поскольку данный номер ТСР-порта был зарезервирован для Telnet-серверов.

ТСР-соединение существует все время сеанса работы. Клиент и сервер поддержи-

вают ТСР-соединение, даже когда клиент прерывает передачу данных (например,

нажимая ctrl-C или Delete). Для совместимости между различными платформами

протокол Telnet предполагает, что оба компьютера поддерживают виртуальный се-

тевой терминал Network Virtual Terminal (NVT). NVT — это простое символьное

устройство с клавиатурой и принтером ^ данные вводятся пользователем с кла-

виатуры и передаются серверу, данные, полученные от сервера, выводятся на прин-

тер.

NVT-терминалы двух компьютеров обмениваются данными в 7-битпом вари-

анте ASCII, в котором каждый символ посылается в виде октета со старшим битом,

установленным в 0. Управляющая информация, такая как индикация конца стро-

ки,

посылается в виде последовательности из двух октетов.

Каждое управляющее сообщение Telnet начинается со специального октета (8 би-

тов,

установлегтых в 1), чтобы гарантировать, что получатель интерпретирует после-

дующие октеты как команду. В противгюм случае каждый октет интерпретируется как

данные (например, введенный пользователем символ). Отправка управляющих сооб-

щений в том же соединении называется передачей команд управления через то же со-

единение, что и данные (in-band signaling). Для обмена информацией между клиентом

и сервером об их возможностях используются начальные управляющие сообщения.

Например, клиент может указать тип и скорость работы своего терминала, а также то,

как будут передаваться данные: по одному символу или по строкам. После обмена ин-

формацией о возможностях сервер инструктирует клиента отправить имя учетной

записи для входа в систему и пароль. После завершения аутентификации пользова-

тель напрямую взаимодействует с удаленным компьютером. Клиентское приложение

передает введенные пользователем символы серверу, а сервер передает выходные дан-

ные обратно клиенту. Однако клиент и сервер должны просматривать каждый полу-

ченный байт на предмет выявления команд (начинающихся с октета 11111111).

Telnet-отправитель использует поле указателя срочных данных TCP для привлечения

внимания получателя к командам Telnet.

5.4.2. File Transfer Protocol

FTP — протокол передачи файлов [PR85] дает возможность пользователю ко-

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

ет команды серверной программе для координации копирования файлов между

двумя компьютерами в интересах пользователя.

172 Часть III. Web-протоколы

ПРИМЕНЕНИЕ FTP

FTP-клиент связывается с удаленным компьютером и предлагает гюльзователю

ввести идентификатор для входа и пароль. Однако некоторые пользователи могут не

иметь собственных учетных записей на удаленном компьютере. Чтобы предоставить

доступ любым пользователям, многие FTP-серверы имеют специальную «аноним-

ную» учетную запись, которая не требует, чтобы пользователь знал пароль. РТР-сер-

вер координирует доступ к набору файлов в различных каталогах. РТР-сервер обычно

имеет специальный каталог с одним или несколькими подкаталогами, которые Moryi'

быть доступны для РТР-клиентов. Мгюгие РТР-клиенты имеют простой интерфейс

командной строки. Пользователь может входить на РТР-сервер, просматривать ката-

логи, отправлять или получать файлы. Интерфейс может давать возможгюсть отправ-

лять или принимать несколько файлов с помощью одной команды. Последние версии

РТР-клиентов предоставляют графический пользовательский интерфейс. Web-брау-

зер дает возможность пользователям указывать желаемый файл в виде URL (напри-

мер,

ftp://ftp.foo.com/bar/neatfile). Браузер выполняет низкоуровневые задачи но со-

единению с РТР-сервером от лица анонимного пользователя для отправки последова-

тельности РТР-команд и для загрузки запрошенного файла.

ПРОТОКОЛ FTP

РТР использует отдельные ТСР-соединения для передачи команд управления и

данных. По умолчанию РТР-клиент соединяется с портом 21^ на удаленном компь-

ютере. Клиент использует это соединение для отправки команд и получения отве-

тов,

при этом соединение продолжает существовать на протяжении выполнения

нескольких команд. Спецификация РТР включает в себя более 30 различных ко-

манд, которые передаются по управляющему соединению в формате АЗСП NVT.

Команды нечувствительны к регистру и могут иметь аргументы; каждая команда

заканчивается последовательностью из двух символов: возврат каретки (CR) и пе-

ревод строки (LP). Эти команды могут отличаться от команд, вводимых пользова-

телем в РТР-клиенте. Передача одного файла осуществляется одной командой

пользовательского уровня, которая предписывает клиенту отправить последова-

тельность команд РТР-серверу. РТР-сервер отвечает на каждую команду трехзнач-

ным кодом ответа (для РТР-клиента) и необязательным текстовым сообщением

(для пользователя). Первые две цифры предоставляют информацию о типе ответа;

третья цифра не имеет определенного значения. Например, в коде 200 ("команда

успешно выполнена") цифра "2" указывает на успешное завершение команды, а

следующий за пей "О" указывает на то, что ответ имеет отношение к синтаксису.

Управляющее соединение продолжает поддерживаться в процессе обмена ко-

мандами и данными между клиентом и сервером в ходе их диалога. Типичное взаи-

модействие между клиентом и сервером начинается с команды, которая идегггифи-

цирует учетную запись (например, анонимную) на компьютере сервера, вслед за

которой идет команда, отправляющая пользовательский пароль (например, адрес

электронной почты пользователя для анонимной учетной записи РТР). Параметры

этих команд берутся из пользовательского ввода. Сервер использует эту информа-

цию для принятия решения, к каким файлам предоставить доступ дангюму клиен-

ту. Например, для анонимного пользователя доступ может быть ограничен неболь-

шой группой файлов. В начале сеанса РТР-клиент может увидеть корневой ката-

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

^ Это соедипепие используется для передачи команд управления, соединение для переда-

чи данных устанавливается по 20 порту.

—

Прим.

ред.

Глава 5. Протоколы, связанные с HTTP 173

запроса, инициированного пользователем, например, чтение файла, запись файла,

вывод списка файлов в текущем каталоге, переход к другому каталогу, вывод име-

ни текущего каталога и т.д.

Файл передается с использованием отдельного соединения, установленного

компьютером, отправившим данные. Если пользователь хочет получить файл

foo.txt, сервер инициирует создание ТСР-соединепия. Однако сервер не знает, ка-

кой номер порта использовать в качестве порта-адресата для FTP-клиепта. Перед

отправкой команды па загрузку файла foo.txt FTP-клиепт просит свою базовую

операционную систему выделить номер порта (больше 1023). FTP-клиент исполь-

зует управляющее соединение, чтобы проинформировать сервер о выбранном но-

мере порта для соединения, используемого для передачи данных. Сервер создает

соединение для передачи данных, записывает содержимое файла foo.txt и закрыва-

ет соединение. FTP-клиент считывает байты из сокета до получения символа кон-

ца файла (EOF). На практике некоторые организации имеют межсетевые экраны,

которые не позволяют внешним компьютерам инициировать ТСР-соединепия.

Чтобы позволить клиентам за межсетевыми экранами получать данные с FTP-cep-

веров, в FTP имеется команда, которая принуждает сервер играть пассивную роль

в установлении соединения для работы с данными.

Файл обычно передается как поток байтов с закрытием ТСР-соединепия при

достижении конца файла (EOF). Спецификация FTP также описывает блочный ре-

жим, который позволяет отправителю передавать файл как серию блоков данных;

каждый блок начинается с одного или нескольких байтов заголовка. Блочный ре-

жим дает возможность отправителю пересылать несколько файлов через одно и то

же соединение для передачи данных; при этом каждый файл заканчивается на гра-

нице блока. Однако блочный режим не получил широкого распространения. На

практике каждая пересылка данных требует отдельного ТСР-соединепия. В проти-

воположность этому управляющее соединение может существовать в ходе несколь-

ких передач данных. В FTP имеется команда для прерывания передачи исходящих

данных без завершения управляющего соединения. Это дает возможность пользо-

вателю завершить копирование файла без требования к клиенту повторить процесс

соединения с сервером и аутентификации пользователя.

В то время как в Telnet передача да1Н1ых ограничена 7-битными символами

ASCII, FTP позволяет использовать более широкий набор типов данных, включая

двоичные файлы. Однако FTP-сервер не предоставляет информации о типе каждого

из файлов. Вместо этого FTP-клиент должен запросить передачу данных в опреде-

ленной форме. Например, предположим, что пользователь хочет выгрузить файл

picture.gif с локальной машины па удале1П1ый компьютер. Пользователю нужгю за-

просить двоичную передачу данных. Это приведет к выдаче FTP-клиентом команды

FTP-серверу переключиться в двоичный режим. Клиент и сервер не могут указать

режим передачи без помощи от пользователя, поскольку локальный файл напрямую

не ассоциируется с дополнительгшши атрибутами. Расширение .gif в имени файла

не обязательно указывает на тип файла. После копирования файла пользователь мо-

жет запустить отдельную профамму для отображения или модификации содержи-

мого файла, основываясь на знании пользователем типа файла. Например, пользова-

тель может вызвать ghostview для отображения файла PostScript.

174

Часть

III. Web-протоколы

5.4.3.

SMTP — простой протокол передачи

электронной почты

Протокол SMTP (Simple Mail Transfer Protocol) [Pos82J используется для пере-

дачи сообщений электронной почты от локального почтового сервера удаленному

почтовому серверу. Кроме того, SMTP может быть использован для отправки сооб-

щений электронной почты от почтового агента пользователя па локальный почто-

вый сервер.

ПРИМЕНЕНИЕ ЭЛЕКТРОННОЙ ПОЧТЫ

Доставка сообщения электронной почты от одного пользователя другому вовле-

кает несколько компонентов. Пользователь запускает почтовый areirr для отправки

и приема сообщений электронной почты. Агент может также поддерживать множе-

ство других функций, таких как распределение сообщений по папкам, создание, ре-

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

почтовый агент осуществляет взаимодействие с локальным почтовым сервером.

Локальный почтовый сервер обслуживает почтовые ящики пользователей и осуще-

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

предположим, что пользователь с именем Viv имеет собственный компьютер и по-

лучает электронную почту по адресу viv@foo.com; почтовый сервер обслуживает

почтовый ящик viv. Разделение обязанностей между агентом пользователя и поч-

товым сервером весьма важно

—

почтовый агент предоставляет богатые возможно-

сти для одного пользователя, а почтовый сервер обеспечивает надежный сервис

для множества пользователей.

В противоположность передаче файлов отправка и прием сообщений электрон-

ной почты не является интерактивным приложением. При отправке сообщения

электронной почты почтовому агенту не обязательно знать, достигло ли сообщение

1ЮЧТОВОГО сервера или почтового агента получателя, и когда это произошло. Фак-

тически, отправляющий сообщение пользователь может завершить работу почтово-

го агента до того, как почтовый сервер закончит доставку сообщения электронной

почты удаленному почтовому серверу. На практике многие пользователи отправ-

ляют и принимают сообщения электронной почты с помощью своих Web-браузе-

ров.

Это осуществляется двумя основными способами. В нервом случае Web-брау-

зер может действовать как почтовый агент, который взаимодействует с локальным

почтовым сервером и предоставляет интерфейс для чтения и составления сообще-

ний. Во втором случае браузер может использоваться для обращения к Web-сайту,

который дает возможность пользователям читать сообщения (путем получения

HTML-файла) и отправлять сообщения (путем отправки HTML-формы). В этой

ситуации Web-сервер координирует взаимодействие с почтовым сервером. Напри-

мер,

сервер может запускать сценарии для извлечения сообщений электронной

почты, предназначенных пользователю, и для отправки сообщений электронной

почты, созданных пользователем.

Сообщение электрогнюй почты состоит из заголовка и тела сообщения. Тело со-

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

головка начинается с повой строки и состоит из одной строки, закапчивающейся

точкой с запятой (например, Date: Sat Oct 28 2000 11:29:32 GMT). Некоторые из

полей, такие как То (Кому) и Subject (Тема), зависят от пользовательского ввода.

Другие, такие как Date (Дата) и Message-Id (Идентификатор сообщения), зада-

ются агентом пользователя или локальным почтовым сервером, который отправля-

ет сообщение. Заголовок и тело сообщения состоят из текстовых строк в 7-битном

Глава 5. Протоколы, связанные с НТГР 175

формате ASCII. Каждая строка заканчивается последовательностью из двух симво-

лов:

возврата каретки (CR) и перевода строки (LF). Первоначально сообщения

электронной почты могли содержать только текстовые данные. Позднее специфи-

кация Multipurpose Internet Mail Extensions (MIME) [FB96a, FB96bJ предоставила

стандартный способ для преобразования других типов данных в текстовый формат

и включения их в сообщения электронной почты. MIME предусматривает допол-

нительные заголовки, которые указывают на размер и способ кодирования содер-

жимого сообщения.

ПРОТОКОЛ SMTP

SMTP был разработан в 1982 г., чтобы заменить РТР при передаче сообщений

электронной почты от одного почтового сервера другому. В SMTP отправляющий

почтовый сервер устанавливает ТСР-соедипение по порту 25 принимающего поч-

тового сервера. Объединенное с заголовком тело сообщения передается от одного

почтового сервера другому с помощью последовательности команд. При передаче

сообщений электронной почты почтовые серверы не делают различий между заго-

ловком и телом сообщения. Единственно, что делает почтовый сервер с сообщени-

ем,

это заполнение донолйительпых полей заголовка, например. Received (Полу-

чено).

Это дает возможность получателю идентифицировать последовательность

почтовых серверов, участвующих в передаче сообщения. Аналогично FTP, SMTP

ориегггирован на передачу текста и основывается на командах. Отправитель выдает

последовательность команд, по одной за раз, и получает ответы, состоящие из трех-

значного кода ответа и текстовой строки.

Локальный почтовый сервер определяет удаленный почтовый сервер, выполняя

особый вид DNS-запроса. Локальный почтовый сервер выдает запрос на информа-

\хшо о записи MX (Mail Exchanger) для полностью заданного имени домена в правой

части адреса электронной почты (например, users.foo.com в viv@users.foo.com).

DNS-ответ состоит из имен одного или нескольких хостов, действующих в качестве

почтовых серверов для да1пюго полного имени домена. После выбора удаленного

почтового сервера (например, bigmail.foo.com) локальный почтовый сервер выпол-

няет дополнительный DNS-запрос для определения IP-адреса удаленного почтового

сервера. Затем локальный почтовый сервер устанавливает ТСР-соедипение с уда-

ленным почтовым сервером. Проблемы мо1ут возникнуть на каждом из этих этапов.

Во-первых, DNS-занрос может возвратить ошибку. Например, сообщение может

быть направлено домену, который не существует (например, viv@users.foo.com, где

users.foo.com не существует). Это приведет к тому, что локальный почтовый сервер

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

ный почтовый сервер знает IP-адрес удаленного почтового сервера, но не может ус-

тановить TGP-соединение. Это может произойти, если удаленный сервер временгю

отключен, или отказ в сети вызван разрывом соединения двух хостов. В таких ситуа-

циях локальный почтовый сервер сохраняет сообщение и пытается сгюва его пере-

дать через некоторое время. Одновременно отправитель может быть проинформиро-

ван,

что передача сообщения была задержана.

Коммуникационное взаимодействие между двумя серверами начинается с при-

ветственного сообщения от удалегнюго почтового сервера. Затем локальный почто-

вый сервер выдает команды для передачи сообщения электронной почты. Типич-

ный обмен включает отдельные команды для:

• идентификации локального почтового сервера;

• идентификации отправителя сообщения электронной почты;

176

Часть

III.

Web-протоколы

• идентификации каждого получателя сообщения электронной почты;

• отправки данного сообщения электронной почты.

В противоположность FTP, SMTP использует одно ТСР-соединение для обме-

на командами и передачи сообщения электронной почты. Отправитель помечает

конец сообщения последовательностью CRLF с последующей точкой (".") и еще

одной последовательностью CRLF. Однако сообщение электронной почты может

содержать строку, начинающуюся с символа ".", что может ввести в заблуждение

получателя. В связи с этим локальный почтовый сервер добавляет второй сим-

вол "." к таким строкам, и отправляя ".." вместо ".". Лишний символ "." удаляется

получателем перед отображением сообщения пользователю.

Помимо передачи сообщения между почтовыми серверами, доставка сообщения

электронной почты требует двух дополнительных действий, выполняемых агентом

пользователя: передачи сообщения локальному почтовому серверу и получение со-

общения от удаленного почтового сервера. Пользовательский агент отправителя

инициирует передачу сообщения электронной почты локальному гючтовому серве-

ру. Эта передача может также использовать SMTP, хотя возможно применение и

других протоколов. Отправка сообщения электронной почты состоит в передаче дан-

ных от почтового агента почтовому серверу. Напротив, извлечение сообщения из

почтового ящика состоит в получении дагнхых от почтового сервера. При получении

сообщений электрогпюй почты SMTP обычно не используется. Для доступа к почто-

вому ящику в Web может быть использован HTTP. Другие протоколы, такие как

Post Office Protocol (РОРЗ) и Internet Message Access Protocol (IMAP), были специ-

ально разработаны для получения сообщений электронной почты с почтового серве-

ра. Более подробный обзор протоколов, используемых для обмена сообщениями

электронной почты, можно найти в соответствующей литературе [JoxOO].

5ЛЛ. Network News Transfer Protocol

Сетевой протокол передачи новостей (NNTP

—

Network News Transfer Protocol)

[KL86] поддерживает передачу статей электронных групп новостей. Агент пользо-

вателя использует NNTP для коммуникационного взаимодействия с локальным

сервером новостей, который использует NNTP для взаимодействия с центральным

хранилищем статей новостей.

ПРИМЕНЕНИЕ СЕТЕВЫХ НОВОСТЕЙ

Помимо обмена сообщениями между парой пользователей, электронная почта

иногда используется также для распространения сообщений для групп пользовате-

лей в течение определенного периода времени. Например, организация может соз-

дать список рассылки с целью распространения сообщений по определенной теме.

Заинтересованные пользователи могут подписаться па список. Однако списки рас-

сылки не слишком эффективны при наличии больших, меняющихся групп пользо-

вателей. Каждый член списка получает отдельную копию сообщения, которая по-

требляет сетевые ресурсы и требует места для хранения. Кроме того, менеджер

списка рассылки должен обновлять перечень получателей по мере прихода и ухода

пользователей. На практике этот процесс может быть автоматизирован, если поль-

зователи будут отправлять по электронной почте на специальную учетную запись

сообщения для подписки и аннулирования подписки на список рассылки, которые

обрабатываются специальной программой. Почтовый сервер списка рассылки мо-

жет также испытывать затруднения при обращении ко всем получателям, особенно

Глава 5. Протоколы, связанные с HTTP 177

если пользователи забывают аннулировать подписку на список рассылки перед

удалением или изменением своих учетных записей электронной почты.

Затруднения, связанные со списками рассылки, стали толчком для создания

системы групп новостей USENET, разработанной в 1979 г. и стандартизованной

в 1983 г. [Ног83]. Главная идея состоит в хранении сообщений в централизованной

базе данных вместо помещения отдельных копий в почтовые ящики каждого из

подписчиков. База данных состоит из набора групп новостей (например, soc.cultu-

ге.Indian), каждая из которых соответствует унорядочегнюму списку сообщений.

Имена групп новостей состоят из строк, разделенных точками. Схема именования

иерархическая. Например, множество связанных между собой групп новостей на-

чинается с SOC или гее. База данных поддерживает запросы для извлечения статей

из групп новостей, а также индексирование, перекрестные ссылки и контроль «воз-

раста» статей. Системный администратор может задавать стратегии по удалению

устаревших статей после истечения определенного периода времени с целью осво-

бождения пространства на сервере.

Подобно сообщению электронной почты, статья в группе новостей содержит не-

сколько строк заголовка. Например, статья включает следующие строки заголовка:

• адрес электронной почты отправителя статьи,

• тема статьи,

• дата/время создания статьи,

• число строк текста в статье,

• уникальный идентификатор сообщения статьи,

• список групп новостей, являющихся получателями статьи.

Группы новостей могут быть реплицированы на различные серверы в Internet.

Например, компания или университет может иметь свой сервер новостей для под-

держки определенного круга пользователей. Локальный сервер новостей может не

реплицировать все группы новостей, а поддерживать особые группы новостей,

предназначенные для сообщества его пользователей. К примеру, университет мо-

жет исключить группы новостей по ряду тем, но поддерживать дополнительные

группы новостей но различным учебным курсам, по которым ведется обучение.

Пользователи читают и размещают статьи с помощью агента пользователя, ко-

торый координирует взаимодействие с локальным сервером новостей. Агент поль-

зователя предоставляет интерфейс, который отображает краткое содержание ста-

тей,

которое включается в строки заголовка, и поддерживает чтение и публикацию

статей. Большинство Web-браузеров способно связываться с локальным сервером

новостей. В Web группа новостей идентифицируется по URL, который содержит

имя группы (например, news:soc.culture.indian). Помимо отображения текста не-

которые пользовательские агенты могут осуществлять синтаксический анализ и

отображение форматирова1Н1ых данных. Кроме того, пользовательский агент запо-

минает, к какой группе новостей обращается пользователь, а также какие сообще-

ния прочитаны или удалены. Эта информация обычно хранится в локальном фай-

ле,

который может быть прочитан при следующем вызове пользователем агента.

Некоторые Web-сайты предоставляют доступ к статьям групп новостей и разреша-

ют пользователям читать статьи (путем загрузки HTML-файлов), а также публи-

ковать статьи (путем отправки содержимого HTML-форм). В этом случае Web-

браузер связывается непосредственно с Web-сервером, который координирует

взаимодействие с сервером групп новостей.

178

Часть

III. Web-протоколы

ПРОТОКОЛ NNTP

NNTP появился в 1986 г., заменив протокол UNIX-to-UNIX Сору Protocol

(UUCP), использовавшийся для передачи статей rpyrni новостей. NNTP координи-

рует передачу сообщений между локальным сервером новостей и централизованным

хранилищем. NNTP также может использоваться для взаимодействия между аген-

том пользователя и локальным сервером новостей. NNTP-клиент устанавливает

одно ТСР-соединепие с портом 119 NNTP-сервера. Подобно FTP и SMTP, NNTP-

клиент выдает команды серверу, который возвращает трехзначный код ответа и не-

обязательное текстовое сообщение. В зависимости от кода ответа, отклик NNTP мо-

жет содержать дополнительные параметры. Количество и тип этих параметров фик-

сирован для каждого кода ответа, чтобы упростить интерпретацию ответа NNTP-

клиентом. При обработке команд NNTP-сервер отслеживает текущее имя группы

новостей и номер статьи, к которой осуществляет доступ NNTP-клиент.

В NNTP имеется множество команд, которые выполняют различные функции.

Один набор команд предоставляет общую информацию о NNTP-сервере и различ-

ных группах новостей, в том числе:

• перечень команд, воспринимаемых NNTP-сервером,

• список имеющихся групп новостей, включая информацию о первой и послед-

ней статье в каждой группе, а также сведения, разрешена ли публикация ста-

тей в данной группе новостей,

• список групп новостей, созданных после определенной даты/времени,

• список статей, опубликованных в определенной группе новостей после опре-

деленной даты/времени.

Предоставление информации об изменениях, произошедших после определен-

ной даты/времени, дает возможность NNTP-клиенту обновлять свое представле-

ние групп новостей и статей без предъявления к NNTP-серверу требования хра-

нить информацию в интересах каждого клиента. Другие команды используются

для перехода к другой группе новостей (ссылка на которую осуществляется по ее

имени), перехода к другой статье (ссылка па которую осуществляется по идеггги-

фикатору сообщения или по ее номеру в группе новостей), перехода на одну ста-

тью назад в пределах текущей группы новостей и перехода на одну статью вперед

в пределах текущей группы новостей.

Другие команды возвращают всю статью, только ее заголовки или только содер-

жание. Для каждой из этих команд статья идентифицируется по ее идентификато-

ру или по числу, указывающему ее позицию в группе новостей. В NNTP также

имеются команды, связанные с созданием новых статей. Клиент отправляет статью

через существующее ТСР-соединепие, следуя тем же соглашениям, которые дейст-

вуют для SMTP. Конец статьи идентифицируется по одиночной точке "." в строке.

После получения статьи централизованное хранилище создает уникальный иден-

тификатор сообщения и добавляет статью в группу новостей. Другие команды под-

держивают репликацию сообщений между двумя NNTP-серверами. В NNTP также

предусмотрена команда для завершения сеанса клиентом. После получе1Н1я ответа

на команду завершения NNTP-сервер закрывает ТСР-соединепие.

5.4.5. Свойства протоколов прикладного уровня

Для поддержки новых способов коммуникационного взаимодействия через

Internet создаются новые протоколы прикладного уровня. Telnet был создан для

Глава 5. Протоколы, связанные с HTTP 179

поддержки взаимодействия пользователей с удаленными компьютерами, а FTP ре-

шал задачу передачи файлов между различными компьютерами. По мере роста по-

пулярности электронной почты SMTP пришел на смену ранее использующемуся

для передачи сообщений электронной почты протоколу FTP. Аналогичным обра-

зом NNTP возник с целью поддержки групп новостей в качестве альтернативы

спискам рассылки. В результате такой преемственности Telnet, FTP, SMTP и

NNTP имеют черты сходства и различия:

• Команда/ответ. Клиенты и серверы Telnet отправляют команды в двоичном

формате, начинающиеся со специального октета (11111111). В противополож-

ность этому в FTP, SMTP и NNTP команды являются текстовыми и отправ-

ляются клиентом. Команды имеют четко определенный, фиксированный фор-

мат, а сервер отвечает трехзначным кодом ответа и необязательным текстовым

сообщением. Некоторые NNTP-ответы содержат дополнительную информа-

цию в фиксировагнюм формате в зависимости от кода ответа.

• Типы данных. Telnet, FTP, SMTP и NNTP передают текстовые данные

в 7-битном формате ASCII. FTP также поддерживает передачу данных в дво-

ичной форме, когда это указывается клиентом. SMTP и NNTP поддерживают

MIME для преобразования нетекстовых данных в формат ASCII и доставки

информации о тине данных получателю.

• Транспорт. Все четыре протокола основаны на надежном транспортном про-

токоле TCP. Telnet, SMTP и NNTP используют одно TCP-соединение для пе-

редачи команд/ответов и данных, а соединение сохраняется на нротяже1нн1

сеанса. В противоположность этому, FTP использует отдельные соединения

для управления и для данных. Управляющее соединение поддерживается

в процессе обмена командами/ответами; при последовательных передачах

данных обычно используются различные соединения.

• Направление передачи. FTP и NNTP могут передавать данные в обоих на-

правлениях

—

копирование данных или публикация статей клиентом и полу-

чение файлов или статей с сервера. SMTP используется для передачи сообще-

ний электронной почты от клиента серверу. В Telnet и FTP клиентом обычно

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

В SMTP и NNTP клиентом может быть локальный сервер, который обменива-

ется данными (сообщениями электронной почты или статьями групп ново-

стей) с удаленным сервером.

• Сохранение информации о сеансе. Во всех четырех протоколах сервер сохра-

няет информацию о сеансе с клиентом. Например, Telnet-сервер сохраняет

информацию о параметрах терминала NVT. FTP-сервер запоминает текущий

каталог клиента и текущий режим передачи данных (двоичный или тексто-

вый).

SMTP-сервер запоминает информацию об отправителе и получателях

сообщения электронной почты в процессе ожидания команды DATA для пе-

редачи содержимого сообщения. NNTP-сервер сохраняет для клиента теку-

щую группу новостей и номер статьи.

Telnet, FTP, SMTP и NNTP до появления Web представляли собой устоявшие-

ся протоколы прикладного уровня. В связи с этим некоторые ключевые элементы

HTTP тесно связаны с этими более ранними протоколами. Тем не менее, у HTTP

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

щих двух главах.