Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Ответы на вопросы upd / Воп_ сети2012 не кратко upd

.pdf
Скачиваний:
87
Добавлен:
03.06.2014
Размер:
1.58 Mб
Скачать

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

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

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

Максимум раз. Это означает, что процедура либо вообще не была выполнена, либо была выполнена только один раз. Подобное утверждение можно сделать при получении ошибки вместо нормального отклика.

Хотя бы раз. Процедура наверняка была выполнена один раз, но возможно и больше. Для нормальной работы в такой ситуации удаленная процедура должна обладать свойством идемпотентности (от англ. idemponent). Этим свойством обладает процедура, многократное выполнение которой не вызывает кумулятивных изменений. Например, чтение файла идемпонентно, а добавление текста в файл - нет.

Представление данных.

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

Большинство реализаций системы RPC определяют некоторые стандартные виды представления данных, к которым должны быть преобразованы все значения, передаваемые в запросах и откликах.

Например, формат представления данных в RPC фирмы Sun Microsystems

следующий :

 

 

Порядок следования байтов

Старший - последний

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

IEEE

Представление символа

 

ASCII

Сеть.

По своей функциональности система RPC занимает промежуточное место между уровнем приложения и транспортным уровнем. В соответствии с моделью OSI этому положению соответствуют уровни представления и сеанса. Таким образом, RPC теоретически независим от реализации сети, в частности, от сетевых протоколов транспортного уровня.

Программные реализации системы, как правило, поддерживают один или два протокола. Например, система RPC разработки фирмы Sun Microsystems поддерживает передачу сообщений с использованием протоколов TCP и UDP. Выбор того или иного протокола зависит от требований приложения. Выбор протокола UDP оправдан для приложений, обладающих следующими характеристиками :

-вызываемые процедуры идемпотентны;

-размер передаваемых аргументов и возвращаемого результата меньше размера пакета UDP - 8 Кбайт;

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

71

каждым из активных клиентов, это занимает значительную часть его ресурсов. Протокол UDP в этом отношении является менее ресурсоемким.

С другой стороны, TCP обеспечивает эффективную работу приложений со следующими характеристиками :

-приложению требуется надежный протокол передачи;

-вызываемые процедуры неидемпонентны;

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

организует формирование и передачу сообщений. Так, при использовании протокола TCP, для которого передаваемые данные представляют собой поток байтов, необходимо отделить сообщения друг от друга. Для этого, например, применяется протокол маркировки записей, описанный в RFC1057 "RPC: Remote Procedure Call Protocol specification version 2", при котором в начале каждого сообщения помещается 32-разрядное целое число, определяющее размер сообщения в байтах.

По-разному обстоит дело и с семантикой вызова. Например, если RPC выполняется с использованием ненадежного транспортного протокола (UDP), система выполняет повторную передачу сообщения через короткие промежутки времени (тайм-ауты). Если приложение-клиент не получает отклик, то с уверенностью можно сказать, что процедура была выполнена ноль или большее число раз. Если отклик был получен, приложение может сделать вывод, что процедура была выполнена хотя бы однажды. При использовании надежного транспортного протокола (TCP) в случае получения отклика можно сказать, что процедура была выполнена один раз. Если же отклик не получен, определенно сказать, что процедура выполнена не была, нельзя.

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

Принцип работы.

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

72

26. E-mail. SMTP.

Электронной почта.

Электронная почта (e-mail) является одним из широко используемым приложением для большинства сетей. До появления Web половина всех устанавливаемых TCP/IP-соединений предназначена для обмена электронной почтой. В этой лекции рассматриваются принципы передачи почтовых сообщений - простой протокол передачи почты (Simple Mail Transfer Protocol, SMTP), а также некоторые дополнительные расширения.

На свете существует множество почтовых программ, клиентов и серверов. Компоненты электронной почты Интернет.

На рис. 2 приведены настоящие компоненты системы электронной почты, в отличие от концептуальных на рис. 1. Обратите внимание на термины "агент пользователях (user agent, UA) и "агент передачи почты" (message transfer agent,

МТА). Как видим, агент пользователя заменяет почтовую программу, а агент передачи почты заменяет процесс-клиент и процесс-сервер.

Рис. 1 Термин "агент" довольно часто встречается в документации Интернет.

"Агент" - это программа специального назначения, выполняющая действия для пользователя или другой программы. В большинстве случаев почтовая программа называется агентом пользователя (UA). Точно так же агент передачи почты (МТА) представляет собой клиент или сервер, выполняющий задачи по доставке или получению почты на сетевом компьютере.

Вы, как пользователь, взаимодействуете с агентом пользователя. Он, в свою очередь, взаимодействует с файлом-контейнером или агентом передачи сообщений за вас. В то же время, МТА ведет себя как представитель своего компьютера в сети. Агент пользователя защищает вас от необходимости общаться с различными почтовыми хостами, а МТА защищает компьютер от необходимости общаться с различными агентами пользователя или несколькими агентами передачи почты одновременно.

73

Рис. 2 В принципе, пользовательский агент отделен от агента передачи почты.

Конечно, их можно объединить в одной программе, но все равно это будут отдельные модули. Будучи взаимосвязаны, оба агента выполняют совершенно различные функции. Пользователи системы Unix "со стажем " хорошо знакомы с такими программами, как МН, Berkeley Mail, Elm, Mush и Pine.

Система электронной почты представлена агентами передачи почты, МТА. До того как обсудить задачи пользовательского агента, необходимо узнать немного больше о том, что же такое МТА. МТА умеют устанавливать TCPсоединение для связи с другими МТА. Протоколом этого соединения, как правило, является простой протокол передачи почты (SMTP). В следующем разделе вы познакомитесь с основами SMTP. Этот протокол полностью описан в RFC 821, который так и называется "Простой протокол передачи почты"

(Simple Mail Transfer Protocol, Postel, 1982).

Простой протокол передачи почты (SMTP).

Агент передачи почты - основной компонент системы передачи почты Интернет. Как уже говорилось, МТА как бы представляет данный сетевой компьютер для сетевой системы электронной почты. Пользователи редко имеют дело с МТА, поскольку он не вполне "дружелюбен", однако без него не обходится ни одна почтовая система. После того как UA пошлет сообщение в выходную очередь, за дело принимается МТА. Он извлекает сообщение и посылает его другому МТА. Этот процесс продолжается до тех пор, пока сообщение не достигнет компьютера-получателя. Для передачи сообщений по TCP-соединению большинство МТА пользуются протоколом SMTP. Сообщения форматированы по правилам виртуального сетевого терминала (NVT), то есть в NVT ASCII. Как вам известно из десятой главы, NVT подобен виртуальному сетевому протоколу и нужен затем, чтобы скрыть различия в восприятии разными компьютерами разных символов, например переводов каретки, переводов строки, маркеров конца строки, очистки экрана и т. д. Символ в NVT состоит из семи битов набора ASCII и является буквой, цифрой или знаком пунктуации. Семибитный набор ASCII часто называется NVT

ASCII.

74

27. URL.

Единый указатель ресурсов (англ. URL — Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. Поанглийски «URL» целиком произносится как /ɜː(ɹ)l/, по-русски чаще говорят. Ранее назывался Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет.

Структура URL

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

Кодирование URL

Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьѐзным недостатком — в нѐм можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания. Если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французского языка, то нужные нам символы должны быть перекодированы особым образом.

Инициатива PURL

Ещѐ один кардинальный недостаток URL состоит в отсутствии гибкости. Ресурсы во Всемирной паутине и Интернете перемещаются, а ссылки в виде URL остаются, указывая на уже отсутствующие ресурсы. Это особенно болезненно для электронных библиотек, каталогов и энциклопедий. Для решения этой проблемы были предложены постоянные локаторы PURL (англ. Persistent Uniform Resource Locator). В сущности это те же URL, но они указывают не на конкретное место расположения ресурса, а на запись в базе данных PURL, где, в свою очередь, записан уже конкретный URL адрес ресурса. При обращении к PURL сервер находит нужную запись в этой базе данных и перенаправляет запрос уже на конкретное местоположение ресурса. Если адрес ресурса меняется, то нет нужды исправлять все бесчисленные ссылки на него — достаточно лишь изменить запись в БД. В настоящий момент эта идея не стандартизирована и не имеет широкого распространения.

75

28. Web сервер. HTTP.

Web-сервер - программа, которая "слушает" сеть (обычно 80 порт), принимает сообщения и реагирует на них, посылая в ответ домашнюю страницу своей организации. При этом к Web-серверу предъявляются следующие требования :

-он должен : работать быстро, чтобы справляться со множеством запросов, используя минимум аппаратных средств;

-быть многозадачным, т.е. работать одновременно с множеством запросов;

аеще раз быть многозадачным, чтобы человек, управляющий им, мог осуществлять сопровождение выдаваемых сервером данных, не завершая его работы. Для этого необходимо запускать сервер в многозадачной операционной системе (UNIX, Windows NT, OS/2); а иметь средства аутентификации запрашивающих абонентов: некоторые из них могут иметь право на большее число услуг, чем другие;

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

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

-предлагать разные форматы. Говоря техническим языком, пользователю могут понадобиться файлы в формате JPEG, а не GIF, или не то и не другое, а TIFF. Может ему захочется посмотреть текст не в формате PostScript, а в формате vdi;

-работать как proxy-сервер. Proxy-сервер - это сервер, который принимает запросы от клиентов и пересылает их на реальные серверы, а затем передает ответы от этих серверов обратно клиентам. Необходимость этого объясняется двумя причинами:

-proxy-сервер может работать на внешней стороне брандмауэра, предоставляя своим пользователям доступ к Internet;

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

-быть надежным.

Технология клиент-сервер. HTTP протокол.

Hypertext Transfer Protocol (HTTP, протокол пересылки гипертекста)-это язык, которым клиенты и серверы World Wide Web пользуются для общения между собой. Он по сути дела и является основой в Web.

Хотя HTTP в большей мере относится к сфере программирования серверов и клиентов, знание этого протокола важно и для С01-программирования[2]. Кроме того, иногда HTTP фильтрует информацию и передает ее обратно пользователям - это происходит, например, когда в окне браузера отображаются коды ошибок сервера. На следующем рисунке приводится модель взаимодействия клиент-сервер с помощью протокола http.

76

Принципы работы HTTP

Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из трех частей: строки запроса (ответа), раздела заголовка и тела. Клиент инициирует транзакцию следующим образом:

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию - 80). Затем клиент посылает запрос документа, указав HTTPкоманду, называемую методом, адрес документа и номер версии HTTP. Например, в запросе :

GET /index.html HTTP/1.0

используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html. Методы HTTP более подробно рассматриваются ниже.

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

User-Agent: Mozilla/2.02Gold (WinNT; )

Accept: image/glf, image/x-bitmap, image/jpeg, image/pjpeg, */*

Завершается заголовок пустой строкой.

Послав запрос и заголовки, клиент может отправить и дополнительные данные. Эти данные используются главным образом теми CGI-программами, которые применяют метод POST. Клиенты (например, Netscape Navigator) могут использовать их для помещения отредактированной страницы на Web-сервер.

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

1. Первая часть ответа сервера - строка состояния, содержащая три поля: версию HTTP, код состояния и описание. Поле версии содержит номер версии HTTP, которой данный сервер пользуется для передачи ответа.

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

HTTP /1.0 200 OK

говорит о том, что сервер для ответа использует версию HTTP 1.0. Код состояния 200 означает, что запрос клиента был успешным и затребованные данные будут переданы после заголовков.

77

2.После строки состояния сервер передает клиенту информацию заголовка, содержащую данные о самом сервере и затребованном документе. Ниже приведен пример заголовка:

Date: Fri, 21 May 1999 08:10:26 GMT Server: Apache/1.3.6

Last-modified: Mon, 30 Apr 1999 21:43:17 GMT Content-type: text/html

Content-lenght: 3192

Завершает заголовок пустая строка.

3.Если запрос клиента успешен, то посылаются затребованные данные. Это может быть копия файла или результат выполнения CGI-программы. Если запрос клиента удовлетворить нельзя, передаются дополнительные данные в виде понятного для пользователя разъяснения причин, по которым сервер не смог выполнить данный запрос.

В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершенной, если не передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение и клиент может посылать другие запросы. Поскольку во многие документы встроены другие документы - изображения, кадры, апплеты

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

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

"ключиками" (cookies).

Запросы клиента

Запросы клиента разбиваются на три раздела. Первая строка сообщения содержит HTTP-команду, называемую методом, URI, который обозначает запрашиваемый клиентом файл или ресурс, и номер версии HTTP. Следующие строки запроса клиента содержат информацию заголовка. Информация заголовка содержит сведения о клиенте и информационном объекте, который он посылает серверу. Третья часть клиентского запроса представляет собой тело содержимого - собственно данные, посылаемые серверу.

URI (Uniform Resource Identifier, универсальный идентификатор ресурса) - это общий термин для всех допустимых форматов схем адресации, поддерживаемых в World Wide Web. Сейчас общепринятой является схема с использованием универсальных локаторов ресурсов (URL).

Методы

Метод - это HTTP-команда, с которой начинается первая строка запроса клиента. Метод сообщает серверу о цели запроса. Для HTTP определены три основных метода: GET, POST и HEAD. При задании имен методов учитывается регистр, поэтому GET и get различаются.

78

GET - это запрос информации, расположенной на сервере по указанному URL. GET - наиболее распространенный метод поиска с помощью браузеров документов для визуализации. Результат запроса GET может представлять собой, например, файл, доступный для сервера, результат выполнения программы или CGI-сценария, выходную информацию аппаратного устройства и т.д. Метод GET также используется для передачи входной информации в CGIпрограммы посредством тегов форм. Поскольку тело запроса GET пусто, входные данные пересылаются к URL в строке GET запроса. Если в тэге <form> задано значение атрибута method="GET", то пары ключ-значение, представляющие собой введенные данные из формы, присоединяются к URL после вопросительного знака. Пары отделяются друг от друга амперсандом (&):

GET /cgi-bin/birthday.pl?month&october&date=11 НТТР/1.0

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Информация заголовка запроса HEAD должна быть такой же, как в запросе GET. Этот метод используется, когда клиент хочет найти информацию о документе, не получая его. Для метода HEAD существует множество приложений. Например, клиент может затребовать следующую информацию:

время изменения документа (эти данные полезны для запросов, связанных

скэш-памятью);

размер документа (необходим для компоновки страницы, оценки времени передачи, определения необходимости запроса более компактной версии документа);

тип документа (позволяет клиенту изучать документы только определенного типа);

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

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

Метод POST позволяет посылать на сервер данные в запросе клиента. Эти данные направляются в программу обработки данных, к которой сервер имеет доступ (например в CGI-сценарий). Метод POST может использоваться во многих приложениях. Например, его можно применять для передачи входных данных для:

сетевых служб (таких как телеконференции);

программ с интерфейсом в виде командной строки;

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

выполнения операций в базах данных. Ответы сервера

Ответ сервера на запрос клиента состоит из трех частей. Первая строка - это

строка ответа сервера, которая содержит номер версии HTTP, число, обозначающее состояние запроса, и краткое описание состояния. После строки ответа следует информация заголовка и тело содержимого, если таковое имеется.

Взаимодействие Web-сервера с другими программами. Скрипты CGI.

CGI (Common Gateway Interface, общий шлюзовый интерфейс) относится к числу средств, без которых нельзя обойтись как при создании комплексных

79

Web-узлов, так и при управлении ими. CGI обеспечивает возможность писать сценарии, которые позволяют разрабатывать управляемые пользователем интерактивные приложения.

CGI - компонент программного обеспечения Web-сервера, который может взаимодействовать с другими программами, работающими на этом сервере. С помощью CGI Web-сервер может вызвать внешнюю программу и передать в нее пользовательские данные (например, информацию о том, с какой хост-машины пользователь установил соединение, или данные, введенные пользователем в HTML-форму). Эта программа затем обрабатывает полученные данные, и сервер передает результаты ее работы в Web-бpayзep.

CGI обеспечивает средства динамического создания Web-страниц на основе вводимой информации, вводимой пользователями. За счет этого расширяется диапазон возможностей World Wide Web. Пользователь, не будучи ограниченным рамками заранее написанных документов, может использовать CGI-сценарии для создания широкого круга приложений - от обзоров до средств поиска, от программного обеспечения сервисных шлюзов Internet до игр и викторин. CGI обеспечивает возможность организовать подсчет количества пользователей, обратившихся к документу, более того, каждому из них может быть предложено расписаться в электронной книге гостей. Кроме того, CGI позволяет предоставлять пользователям любого рода информацию, регистрировать замечания клиентов и давать на них ответы.

80