Cправочник web-дизайнера / Internet

Система адресации в Internet

Система адресации в Internet IP-адрес - это 4-байтовая последовательность (32 разряда). Принято каждый байт этой последовательности записывать в виде десятичного числа. Например, приведенный здесь адрес является адресом сервера кафедры ПМИ ДонГТУ: 177. . .16.

Каждая точка доступа к сетевому интерфейсу имеет свой IP-адрес, который состоит из двух частей:

- адрес сети;

- адрес хоста,

где хост-ЭВМ - это компьютер, подключенный к сети Internet. Но в последнее время понятие "хост" трактуется более расширенно. Это может быть и:

- принтер с сетевой картой;

- Х-терминал;

- любое устройство со своим сетевым интерфейсом.

Существует пять классов IP-адресов. Эти классы отличаются друг от друга количеством битов, отведенных на адрес сети и адрес хоста в сети.

Классы IP-адресов 0 7 8 15 16 23 24 31 Класс A 0 номер сети номер хоста Класс В 10 номер сети номер хоста Класс С 110 номер сети номер хоста Класс D 1110 групповой адрес Класс Е 11110 Резерв Опираясь на эту структуру, можно подсчитать характерестики каждого класса в терминах числа сетей и числа машин в каждой сети.

Характеристики классов IP-адресов Класс Диапазон значений 1-го байта Количество сетей Количество узлов A 1-126 126 16777214 B 128-191 16382 65534 C 192-223 2097150 254 D 224-239 - 228 E 240-247 - 227 Адреса класса А предназначены для использования в больших сетях общего пользования. Адреса класса В предназначены для использования в сетях среднего размера (сети больших компаний, НИИ, ВУЗы и т.д.). Адреса класса В предназначены для использования в сетях с небольшим числом компьютеров (сети небольщих фирм, кафедр). Адреса класса D используются для обращения к группам компьютеров, а адреса класса Е - зарезервированы.

Среди всех IP-адресов имеется несколько отведеннх под специальные нужды.

Выделенные IP-адреса IP-адрес Значение все нули данный узел сети номер сети|все нули данная IP-сеть все нули|номер узла узел в данной (локальной) сети все единицы все узлы в данной локальной IP-сети номер сети|все единицы все узлы указанной IP-сети 127.0.0.1 "Петля" Особое внимание в приведенной выше таблице имеет последняя строка. Адрес 127.0.0.1 предназначен для тестирования программ и взаимодействия процессов в рамках родного компьютера. В большинстве случаев в файлах настройки этот адрес обязательно должен быть указан, иначе система при запуске может зависнуть. Наличие "петли" чрезвычайно удобно с точки зрения использования сетевых приложений в локальном режиме для их тестирования и при разработке интегрированных систем.

Некоторые зарезервированные адреса используются для широковещательных сообщений. Например, номер сети (строка2) используется для посылки сообщений этой сети. Адреса, содержащие все единицы, используются для широковещательных посылок (для запроса адресов, например). Реальные адреса выделяются организациям, представляющим IP-услуги, из выделенных для них узлов IP-адресов.

Доменная адресация Числовая адресация удобна для машинной обработки таблиц маршрутов, но совершенно неприемлима для использования ее человеком. Запомнить наборы цифр гораздо труднее, чем мнемонические осмысленные имена. Для облегчения взаимодействия в Сети в начале стали использовать таблицы соответствия числовых адресов именам машин. Эти таблицы сохранились до сих пор и используются многими прикладными программами. Это файлы с исенем hosts. Так, например, в UNIX этот файл расположен в директории /етс и имеет следующий вид:

Пример таблицы имен хостов (файл/етс/hosts) IP-адреса Имя машины Синоним 127.0.0.1 localhost localhost 144.206.160.32 Polyn polyn 144.206.160.40 Apollo www Последний столбец этой таблицы является необязательным. Пользователь при обращении к машине может использовать как IP-адрес, так и ее имя или синоним.

Пример адекватных обращений:

telnet 144.206.160.40 Apollo telnet Apollo telnet www Такой способ присвоения символьных имен был хорош до тех пор, пока Internet была маленькой. По мере роста сети стало трудно держать большие списки имен на каждом компьютере. Чтобы решить эту проблему была разработана структура имен DNS Domain Name System (Доменная система имен).

Система доменных адресов строится по иерархическому принципу. Однако иерархия эта не строгая. Фактичеки нет единого корня всех доменов Internet. В 80-е годы были определены первые домены верхнего уровня: gov, mil, edu, com, net. Позднее, когда сеть перешагнула национальные границы США, появились национальные домены типа: uk, jp, au, ch т т.д. Для СССР также был введен домен su. После 1991 года многие республики получили свои собственные домены: ru, ua, la, li и т.п. Однако Internet - это не СССР, и просто так выкинуть домен su из сервера имен нельзя, так как на основе доменных имен строятся адреса электронной почты и доступ ко многим информационным ресурсам Internet. Поэтому проще оказалояь ввести новый домен и добавить его к существующему, чем заменить его. Поэтому в Москве есть организации с доменным именем, оканчивающими на su и на ru.

Тематические домены в Internet Домены высшего уровня Использование com Коммерческие организации edu Учебные заведения (университеты и институты) gov Невоенные правительственные организации mil Военные учреждения net Вычислительные сети int Международные организации org Другие Географические домены в Internet Домен | Страна (Упорядочены по домену) Домен | Страна (Упорядочены по стране) aq Антарктида au Австралия at Австрия at Австрия au Австралия aq Антарктида be Бельгия by Беларусь bg Болгария be Бельгия br Бразилия bg Болгария by Беларусь br Бразилия ca Канада uk Великобритания ch Швейцария hu Венгрия cl Чили ve Венесуэла cy Кипр de Германия cz Чешская Республика nl Голландия de Германия hk Гонконг dk Дания gl Гренландия ee Эстония gr Греция es Испания dk Дания fi Финляндия il Израиль fr Франция in Индия gl Гренландия ir Ирландия gr Греция is Исландия hk Гонконг es Испания hu Венгрия it Италия il Израиль ca Канада in Индия cy Кипр ir Ирландия kr Корея is Исландия kw Кувейт it Италия lv Латвия jp Япония lu Люксембург kr Корея my Малайзия kw Кувейт mx Мексика lu Люксембург mo Морокко lv Латвия nz Новая Зеландия mo Морокко no Норвегия mx Мексика pl Польша my Малайзия pt Португалия nl Голландия pr Пуэрто-Рико no Норвегия su Россия nz Новая Зеландия ru Россия pl Польша us США pr Пуэрто-Рико sg Сингапур pt Португалия sk Словацкая Республика ru Россия si Словения sa Южная Африка th Таиланд se Швеция tw Тайвань sg Сингапур tu Тунис si Словения tr Турция sk Словацкая Республика ua Украина su Россия fi Финляндия th Таиланд fr Франция tr Турция cz Чешская Республика tu Тунис cl Чили tw Тайвань ch Швейцария ua Украина se Швеция uk Великобритания ee Эстония us США sa Южная Африка ve Венесуэла jp Япония Основные рубрики телеконференций Название рубрики Тематика comp Содержит все темы, связанные с компьютерами. Представляет большой интерес начинающему пользователю misc Собраны все темы, которые не входят ни в одну из других групп news Содержит информацию телеконференции USENET sci Содержит обсуждение исследований из различных областей науки. Уровень обсуждений очень высок soc Собраны разнообразные материалы на социальные темы talk Множество дискуссий на самые различные темы Альтернативные рубрики телеконференций Название рубрики Тематика alt Нет никаких ограничений на выбор тем bionet Биологические темы на профессиональном уровне biz Все о новых продуктах на компьютерном рынке gnu Телеконференции Free Software Foundation (FSF), елью которых является предложения на рынке свободных от каких либо авторских прав компьютерных программ, входящих в проект GNU (General Not UNIX) Вслед за доменами верхнего уровня следуют домены, определяющие либо районы, либо организации. Далее идут следующие уровни иерархии, которые могут быть закреплены либо за небольшими организаци ями, либо за подразделениями больших организаций.

Система серверов доменных имен (BIND) Наиболее популярной программой поддержки DNS является named, которая реализует Berkely Internet Name Domain (BIND). BIND это сервер доменных имен, реализованный в университете г. Беркли, который широко применяется в Internet. Он обеспечивает поиск доменных имен и IP-адресов для любого узла Сети.

Собственно система доменной адресации состоит из трех компонент:

- системы имен или базы данных имен; - сервера имен; - resolver. Рассмотрим общий принцип работы сервера имен. Любой сервер имен имеет зону своей ответственности. Для того, чтобы получить адреса или имена машин, которые не входят в зону его ответственности, сервер обращается к другим серверам имен. В принципе, в поиске адреса или имени запрос может пропутешествовать до корня системы доменов, а затем снова опуститься до локального сервера имен. При поиске имени resolver формирует запрос и посылает его своему серверу имен, который пытается найти имя в своей базе данных. Если это ему удается, то ответ возвращается resolver'у, в противном случае он запрашивает сервер, стоящий выше него в иерархии доменов. Этот сервер обычно называется корневым. Корневой сервер находит, в чей домен попадает указанное в запросе имя, и указывает адрес этого сервера серверу, с которого поступил запрос. Сервер, найденный корневым сервером, называется удаленным сервером. Локальный сервер устанавливает взаимодействие с удаленным сервером и получает от послед него необходимую информацию.

Кроме алгоритма взаимодействия самих серверов представляет интерес и алгоритм формирования запроса программой, запрашиваемой адрес. Обычно рассматриваются три случая:

- однословное имя; - имя с точкой на конце; - составное имя. А. Однословное имя Рассмотрим к примеру следующий адрес: /usr/paul>telnet polyn. В этом случае происходит обращение к файлу синонимов (aliases), который указывается в переменной окружения, например, HOSTALIASES или каким либо другим способом.

Б. Имя с точкой на конце Если в качестве имени указано имя с точкой на конце, то его и используют для поска адреса и никакой дополнительной информации к нему не добавляется.

В. Составное имя Если указано составное имя, то сначала его проверяют в местном домене. Если адрес не найден, то к имени добавляется имя местного домена. Если снова адрес не найден, то добавляется имя вышестоящего домена. Если имя вышестоящего домена состоит из одного слова, то его не добавляют к указанному в запросе адресу. Например, пусть адрес запроса имеет вид: /usr/paul/telnet apollo.polyn и при этом на машине указано имя текущего домена polyn.kiae.su. Тогда будут проверены следующие имена:

- apollo.polyn; - apollo.polyn.polyn.kiae.su; - apollo.polyn.kiae.su. Последнее имя будет найдено в базе данных локального сервера и будет возвращен IP-адрес этой машины.

Различают четыре вида серверов: - primary master сервер; - secondary master сервер; - caching сервер; - remote (удаленный) сервер. Primary master сервер - это сервер, который поддерживает свою базу доменных имен и обслуживает свой домен. Secondary master сервер - это сервер, который обслуживает свой домен, но данные об адресах части своих машин получает по сети с другого сервера. Сaching сервер - это сервер, который не имеет своего домена. Он получает данные либо с одного из master серверов, либо из буфера. Удаленный сервер - это обычный master сервер, который установлен на удаленной машине. Программы обращаются к нему по сети. Обычно адрес сервера указывается в файле /etc/resolv.coft.

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

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

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

3. При работе на рабочих станциях или ПК, которые не являются шлюзами и не используются для публичного сервиса, имеет смысл использовать удаленные сервера, что облегчает проблемы с администрированием сервера имен.

Универсальный идентификатор ресурсов - URI Из всех спецификаций WWW только спецификация URI доведена до состояния RFC (т.е. стандарта). За этим стандартом закреплен номер 1630 (в 1994 году и отражает состояние информационных ресурсов Internet). URI определяет способ записи (кодирования) адресов различных информационных ресурсов при обращении к ним из страниц WWW. Однако в последнее время данная спецификация стала встраиваться и в почтовые сообщения.

Необходимость в URI была понятна с самого начала, так как предполагалось объединение в единую информационную среду средств, использующие различные способы идентификации информационных ресурсов. Первоначально это был FTP-архивы системы ЦЕРН. Но сразу была разработана спецификация, которая включала в себя обращение к FTP, Gopher, WAIS, Usenet, E-Mail, Prospero, telnet^ Whois, X.500 и, конечно, HTTP (WWW). Эта спецификация позволяет расширить список адресуемых ресурсов за счет появления новых схем.

Метод применения URI - гипертекстовые ссылки, которые записываются в дескрипторах <A HREF=URI> и <LINK HREF=URI>. Встраиваемые графические объекты также могут записываться по спецификации URI в дескрипторах <IMG SRC=URI> и <FIG SRC=URI>. Реализация URI для WWW называется URL. Точнее URL - это реализация схемы URI, отображенная на алгоритм доступа к ресурсам по сетевым протоколам. Существует еще и URN, которое отображает URI в пространство имен на сети. Появление URN связано с желанием адаптировать части почтового сообщения MIME.

Принципы построения адреса WWW В основу URI были заключены следующие принципы:

- Расширяемость - новые адресные схемы должны легко вписываться в существуюший синтаксис URI.

- Полнота - по возможности любая из существующих схем должна описываться средствами URI. - Читаемость - адрес дожен быть легко читаем человеком, что вообще характерны для технологии WWW. Документы вместе со ссылками могут разрабатываться в обычном текстовом редакторе.

Расширяемость была достигнута за счет выбора определенного порядка интерпритации адресов, который базируется на понятие "адресная схема". Идентификатор схемы стоит перед остатком адреса, отделен от него двоеточием и определяет порядок интерпретации остатка.

Полнота и читаемость порождали противоречие, связанное с тем, что в некоторых схемах используется двоичная информация. Эта проблема была решена за счет формы представления такой информации. Символы, которые несут служебную функцию, и двоичные данные отображаются в URI в шестнадцатиричном коде и предворяются символом "%".

Схемы адресации ресурсов в Internet В FRC-1630 рассмотрено 8 (9?) схем адресации ресурсов Internet и указаны две, синтаксис которых находится в обсуждении.

Схема HTTP. Это основная схема WWW. В ней указывается ее идентификатор, адрес машины, TCP-порт, путь в директории сервера, поисковый критерий и метка. Примеры:

http://polyn.net.kiae.su/polyn/manifest.html - наиболее распространенный;

http://144.206.130.40/risk/risk.html - используется IP-адрес;

http://144.206.130.40:8080/altai/index.html - если сервер запущен на другой, отличный от 80 порта TCP.

http://polyn.net.kiae.su/altai/volume4.html#first - если происходит ссылка на точку внутри файла HTML. Для этого вслед за именем документа должна быть указана метка внутри документа. Символ "#" отделяет имя документа от имени метки.

http://polyn.net.kiae.su/isindex.html?keyword1+keyword2 - первоначально предполагалось, что в качестве параметров будут передаваться ключевые слова, но по мере развития механизма CGI-скриптов в качестве параметров стала передаваться и другая информация. В этом примере предполагается, что документ "isindex.html" - документ с возможностью поиска по ключевым словам. При этом в зависимостм от поисковой машины (программы, реализующей поиск) знак "+" будет интерпретироваться либо как "AND", либо как "OR". Вообще говоря, знак "+" заменяет знак пробела и относится к классу неотображаемых символов. Если его необходимо передать в строке параметров, то следует передавать в 16-ом виде его ASCII код, например,

http://polyn.net.kiae.su/isindex.html?keyword1%20keyword2 - здесь параметр имеет два слова, которые разделены знаком пробела.

http://polyn.net.kiae.su/isindex.html?field1=value1+field2=value2 при использовании HTML-форм параметры передаются как поименованные поля. Значения "field1" и "field2" - это имена полей, а символы "value1" и "value2" - их значения. При этом приведенном выше при мере URI может соответствовать следуюшая HTML-форма:

<FORM ACTION=http://polyn.net.kiae.su/cgi-bin/test> Введите значения полей: <BR> Поле "field1": <INPUT NAME="field1" VALUE="value1"> <BR> Поле "field2": <INPUT NAME="field2" VALUE="value2"> <BR> <HR> </FORM>

Схема FTP. Данная схема позволяет адресовать файловые архивы FTP из программ клиентов WWW. При этом программа должна поддерживать протокол FTP. В данной схеме возможно указание не только имени схемы, адреса FTP-архива, но и идентификатор пользователя и даже его пароля. Наиболее часто данная схема используется для доступа к публичным архивам FTP:

http://polyn.net.kiae.su/pub/0index.txt

В данном случае записана ссылка на архив "0index.txt" с идентификатором "anonymous" или "ftp" (анонимный доступ). Если есть необходимость указать идентификатор пользователя и его пароль, то можно это сделать перед адресом машины: ftp://nobody:password@polyn.net.kiae.su/user/local/pib

В данном случае эти параметры отделены от адреса машины сиволом "@", а друг от друга двоеточием. Но следует учитывать, что употребление идентификатора пользователя и его пароля не рекомендовано, так как данные передаются не зашифрованными и могут быть перехвачены. Реальная защита в WWW осуществляется другими средствами и построена на других принципах.

Схема Gopher. Данная схема используется для ссылки на ресурсы распределенной информационной системы Gopher. Схема состоит из идентификатора и пути, в котором указывается адрес Gopher-сервера, тип ресурса и команда Gopher:

gopher://gopher.kiae.su:70:/7/optimization

В данном примере осуществляется доступ к gopher-серверу gopher.kiae.su через порт 70 для поиска (тип 7) слова "optimization".

Схема MAILTO. Данная схема предназначена для отправки почты по стандарту RFC-822 (стандарт почтового сообщения). Общий вид схемы имеет вид: mailto://paul@quest.polyn.kiae.su

Схема NEWS. Данная схема служит для просмотра сообщений системы Usenet. При использовании этой схемы используется следующая нотация: news:comp.infosystem.gopher. В данном случае можно получить статьи из группы "comp.infosystem.gopher" в режиме уведомления можно получить и текст статьи, тогда в этом случае указывается ее номер: news:0186@comp.infosystem.gopher. В данном примере заказана 186 статья из группы.

ПРИМЕЧАНИЕ Из примеров видно, что в этой схеме не ставятся символы"//".

Схема NNTP. Это еще одна схема получения доступа к ресурсам Usenet. В данной схеме обращение к группе comp.infosystem.gopher для получения статьи с номером 186 будет выглядеть так: nntp://comp.infosystem.gopher/186. Следует обратить внимание на то, что адрес сервера Usenet не указан. Программа-клиент должна быть предварительно сконфигурирована на работу с одним из серверов Usenet. Сама служба Usenet является распределенным информационным ресурсом, а группа comp.infosystem.gopher на сервере в домене kiae.su или где-либо еще в мире содержит одни и те же сообщения.

Схема TELNET. По этой схеме осуществляется доступ к ресурсу удаленного терминала. Обычно клиент вызывает дополнительную программу для работы по протоколу telnet. При использовании этой схемы необходимо указывать идентификатор пользователя, допускается использование пароля. Реально доступ осуществляется к публичным ресурсам и поэтому идентификатор и пароль являются общедоступными. Их можно узнать в базах данных Hytelnet.

telnet://quest:password@apollo.polyn.kiae.su

Схема WAIS. WAIS - распределенная информационная поисковая система. Она работает в 2-х режимах: поиска и просмотра. При поиске используется форма со знаком "?", отделяющим адресную часть от ключевых слов:

wais://wais.think.com/wais?guide

В данном случае обращаются к базе данных wais на сервере wais.think.com с запросом на поиск документов со словом guide. Сервер должен вернуть клиенту список документов. После получения этого списка можно использовать вторую форму схемы WAIS - запрос на просмотр документа:

wais://wais.think.com/wais/wtype/039=/option/optimization.txt. Здесь 039 - это идентификатор документа.

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

Схема FILE. WWW-технология используется как в сетевых, так и в локальных режимах. Для локального режима используют схему FILE.

file:///c\/text/html/index.htm

В данном примере приведено обращение к локальному документу на ПС с MS DOS или MS WINDOWS. Следует заметить, что данная схема не может быть применена к CGI-скриптам. Очень часто, однако, пользователи пытаются применить file к скрипту, что является ошибкой. Любой скрипт может быть запущен только сервером HTTP, то-есть ему надо передавать параметры и данные. Клиент запускает только программы просмотра на основе MIME-типов из заголовков сообщений сервера или по расширению файла.

Существуют и другие схемы, которые находятся в стадии обсуждения.

Протокол обмена гипертекстовой информации ( HyperText Transport Protocol, HTTP 1.0) Этот протокол прикладного уровня, разработанный для обмена гипертекстовой информацией в сети Internet. Данный протокол используется в WWW с 1990 года.

HTTP позволяет реализовать в рамках обмена данными набор методов доступа, базирующих на спецификации УНИВЕРСАЛЬНОГО ИДЕНТИФИКАТОРА РЕСУРСОВ (Universal Resourse Identifier - URI), применяемого в форме универсального имени ресурсов (Universal Resourse Name URN) или универсального локатора ресурсов (Universal Resourse Locator - URL). Сообщения по сети при использовании протокола HTTP передаются в формате, схожем с форматом почтового сообщения Internet (RCF-822) или с форматом сообщений MIME (Multiperposal Internet Mail Exchange). HTTP используется для взаимодействия программ-клиентов с программами-шлюзами, разрешающими доступ к ресурсам электронной почты (SMTP), списками новостей (NNTP), файловыми архивами (FTP), системам Gopher, WAIS и др. Протокол разработан для доступа к этим ресурсам посредством промежуточных программ-серверов (proxy), которые позволяют передавать информацию различным информационным службам без потерь.

Протокол реализует принцип "запрос/ответ". Запрашивающая программа-клиент иницирует взаимодействие с отвечающей программой-сервером, и посылает запрос, включающий в себя метод доступа, адрес URL, версию протокола, похожее по форме на MIME-сообщение с модификаторами типа передаваемой информации, информацию клиента и, возможно, тело сообщения клиента. Сервер отвечает строкой состояния, включающий версию протокола и код возврата, за которым следует сообщение в форме, похожей на MIME. Данное сообщение содержит информацию сервера, метаинформацию и тело сообщения. Понятно, что в принципе одна и та же программа может выступать и в роли клиента и в роли сервера (что и происходит при сипользовании PROXY-серверов).

Форма запроса клиента Программа-клиент посылает после установления соединения запрос серверу. Этот запрос может быть в двух формах: в форме полного зап роса и в форме простого запроса. Простой запрос содержит метод доступа и запрос ресурса, например:

GET http://polyn.net.kiae.su/ В этой слово GET обозначает метод доступа GET, а http://polyn.net. kiae.su/ - это запрос ресурса. Клиенты, которые способны поддерживать версию протокола выше 0.9, должны пользоваться полной формой запроса. В этом случае в запросе указывается строка запроса, несколько заголовков (заголовок запроса или общий заголовок. и, возможно, тело обозначения ресурса. Общий вид запроса в форме БНФ(Бекуса-Наура форма) имеет вид:

<Полный запрос> := <строка запроса> (<Общий заголовок> I <Заголовок запроса> I <заголовок обозначения ресурса>) <символ новой строки> [<тело ресурса>]. Здесь [...] необязательный элемент.

Строка запроса - это практически простой запрос ресурса. Отличие состоит в том, что в строке запроса можно указывать различные методы доступа и за запросом ресурса следует указывать версию протокола. Например, для вызова внещней программы можно использовать следующую строку запроса:

POST http://polyn.net.kiae.su/cgi-bin/test HTTP/1.0

В данном случае используется метод POST и протокол версии 1.0

В обоих формах запроса важное место занимает форма запроса ресурса, которая кодируется в соответствии спецификации URI. Применительно к WWW эта спецификация получила название URL. При обращении к серверу можно использовать как полную форму URL, так и упрощенную.

Полная форма содержит тип протокола доступа, адрес сервера и адрес ресурса на сервере. Однако такой адрес реально нужен для работы через промежуточный сервер, так как тот может пересылать запросы. При обращении к первичному серверу клиент может опускать порт 80, протокол и адрес, устанавливая взаимодействие с сервером по адресу, указанному в URL (в исходном документе), передавая только путь от корня сервера.

Методы доступа В настоящее время в практике WWW реально используются только три доступа: GET, POST и HEAD.

GET - метод, позволяющий получать данные, заданные в форме URI в запросе ресурса. Если ссылаются на программу, то возвращается результат выполнения этой программы, но не текст программы. Дополнительные данные, которые надо передавать для обработки, кодируются в запрос ресурса. Имеется разновидность метода GET - условный GET. При использовании этого метода сервер ответит на запрос, только если будут выполнены условия передачи. Это позволит разгрузить сеть, избавив ее от передачи ненужной информации. Условие указывается в поле "if_Modified_Since" заголовка ресурса. При использовании метода GET в поле тела ресурса возвращается собственно затребованная информация.

HEAD - то же, что и GET, но не возвращается тело ресурса. Используется для получения информации о ресурсах. Условного HEAD не существует. Данный метод используется для тестирования гипертекстовых ссылок.

POST - это метод разработан для передачи большого объема информации на сервер. Им используются для анкетирования существующих ресурсов, посылки почтовых сообщений, работы с формами интерфейсов к внешним базам данных и внешним исполняемым программам. В отличие от GET и HEAD в POST передается тело ресурса, которое является информацией из поля форм или других источников ввода.

В первых версиях протокола были определены и другие методы доступа, но они не нашли должного применения. Изменение числа методов доступа отражает практику использования HTTP. В версии 1993 г. насчитывалось 13 различных методов доступа. К выше перечисленным можно отнести следующие:

CHECKOUT - защита от несанкционированного доступа;

PUT - замена содержания информационного ресурса;

DELETE - удаление ресурса;

LINK - создание гипертекстовой ссылки;

NULINK - удаление гипертекстовой ссылки;

SPACEJUMP- переход по координатам;

SEARCH - поиск.

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

Однако, во-первых, как показал опыт, практически не использовались методы доступа, связанные с изменением информации. Это объясняется прежде всего соображениями безопасности. Ни один администратор не позволит неизвестно кому менять информацию на его сервере. Во-вторых, методы SPACEJUMP и SEARCH были с успехом заменены CGI-скриптами. Из этого не следует, что их возрождение невозможно. Например, в языке HTML вернулись ссылки, общие для всего документа, но пока их реализация в протоколе отложена. В-третьих, не нашли практической реалиации методы установления/удаления ссылок LINK и UNLINK. Но необходимость в них растет, и связано она с реорганизацией сети. Многие информационные ресурсы меняют свои адреса, что вносит запутанность в структуру сети. То-есть, вопрос о новых методах доступа все еще не открыт, и поэтому, видимо, спецификация HTTP еще не вышла на уровень RFC и остается в виде Internet Dreft.

Ответ сервера Ответ сервера может быть, как и запрос, упрощенным или полным. При упрощенном ответе сервер возвращается только тело ресурса, например, текст HTML-документа. При полном ответе клиенту возвращается строка состояния (Status-Line), общий заголовок, заголовок ответа, заголовок ресурса и тело ресурса. В нотации Бэкуса полный ответ представляется в следующем виде:

<Полный ответ> := <Строка состояния> ( <Общий заголовок> I <Заголовок ответа> I <Заголовок ресурса> ) <символ новой строки> [<тело ресурса>]

Строка состояния состоит из версии протокола, кода возврата и краткого описания этого кода. Например, она может выглядеть так:

"HTTP/1.0 200 Success"

Коды возврата делятся на несколько классов:

1ХХ - информационные сообщения;

2ХХ - сообщения успешной передачи;

3ХХ - сообщения переадресации;

4ХХ - ошибки клиента;

5ХХ - ошибки сервера.

Заголовок ответа сервера может состоять из адреса URI для запрашиваемого ресурса, и/или наименования программы сервера, и/или кода идентификации для работы в защищенном режиме. Состав полей заголовка ресурса является общим и для запроса клиента и для ответа сервера. Он состоит из:

- разрешения на метод доступа;

- типа кодировки тела ресурса (содержания ресурса);

- длины тела ресурса;

- типа ресурса;

- времени действия данной копии ресурса;

- времени последнего изменения ресурса;

- расширения заголовка.

Рассмотрим более подробно поля заголовка, обращая внимание на реальное применение каждого из них и возможность проявления ошибок при обработке этих полей разными программами (серверами и клиентами).

Если в заголовке ответа сервера указано предложение Location, то это значит, что требуемый ресурс находится по другому адресу и его надо запросить заново. Такая процедура называется перенаправлением. Перенапрвление в заголовке будет выглядеть так:

Location: http://apollo.polyn.kiae.su./risk/riskform.html

Имя и версия сервера указывается в поле Server. При использовании сервера ЦЕРН (Швейцария) данное поле будет выглядеть так:

Server: CERN/3.0 libwww/2.17

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

WWW-Authenticate: Basic realm="WallyWorld"

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

Allow: GET,HEAD

Поле Content-Encoding определяет тип кодирования передаваемого ресурса:

Content-Encoding: x-gzip

В данном случае указывается, что ресурс является заархивированным файлом в формате zip. Обычно ресурсы хранятся в виде, указанном в данном поле, и при их получении клиент должен обеспечить их преобразование в приемлемый для отображении вид. Это своего рода предобработка данных, которая базируется обычно на MIME типах. В машинах, где недостаточно памяти на видеоадаптерах, используют предобработку для преобразования изображений в приемлимый для отображения вид. Так на ЭВМ с 512 Кб памяти на видеоадаптере используют предобработку для преобразования 256 цветов в 16.

Другим полем, которое проявляет себя при работе в сети, порождая ошибки отображения ранними версиями броузеров или ранними версиями программ серверов, является поле Content-Length. Это поле указывает размер в байтах передаваемого ресурса. Это поле указывается как клиентом при работе по методу POST, так и сервером при ответе на запросы клиентов. В старых версиях программ серверов порождается ошибка, вызванная тем, что происходит вставка сервером некоторой информации в текст ресурса. Например, сервер NCSA (1.3) позволяет вставлять в текст HTML-документов фрагменты текста из других файлов при помощи выражения типа:

<!--#includes virtual="include/commonheader.html"-->

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

Поле Content-Type определяет тип информации, передаваемой сервером. Наиболее часто используются типы text/plain - простой текст и text/html - документ в формате HTML.

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

Поле Date определяет время отправки сообщения. Информация из этого поля сохраняется в файле статистики сервера и может быть использована для анализа доступа к ресурсам сервером из сети.

Поле Expires определяет время годности ресурса для использования. Если время использования вышло, то ресурс не должен передаваться, а точнее, его не следует передавать и принимать.

Поле if_Modified_Sience уже упоминалось. Оно используется для того, чтобы не передавать имеющие у клиента копии ресурса, если не были произведены его изменения. Реально известно только одно значение данного поля: no-cashe, которое запрещает запоминать в буфере данные для последующего использования.

Поле Preferer используется для того, чтобы указать, из какого ресурса была осуществлена ссылка на ресурс. Данное поле - мечта любого администратора базы данных сети. При помощи информации из этого поля можно определить, в каких WWW-страницах прописан конкретный сервер. От этого зависит количество обращений к серверу, "качество" пользователей, время отклика на информацию, размешенной на сервере.

Контрольные вопросы Характеристика классов IP-адресов.

Суть доменной адресации.

Принципы работы сервера имен.

Виды серверов в Internet.

URI и его место применения.

Приведите примеры схем адресации ресурсов в Internet: HTTP, FTP, News и FILE.

Перечислить методы доступа, используемые в WWW.