20414

Информационные системы. Определение распределенной системы

Шпаргалка

Информатика, кибернетика и программирование

Мультипроцессорные системы шинной архитектуры состоят из некоторого количества процессоров подсоединенных к общей шине а через нее к модулям памяти. Память стала несогласованной и программирование системы осложнилось. Для построения мультипроцессорной системы с более чем 256 процессорами для соединения процессоров с памятью необходимы другие методы.

Русский

2013-07-25

1.18 MB

3 чел.

0 Мультипроцессоры

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

Поскольку используется единая память, когда процессор А записывает слово в память, а процессор В микросекундой позже считывает слово из памяти, процессор В получает информацию, записанную в память процессором А. Память, обладающая таким поведением, называется согласованной (coherent). Проблема такой схемы состоит в том, что в случае уже 4 или 5 процессоров шина оказывается стабильно перегруженной и производительность резко падает. Решение состоит в размещении между процессором и шиной высокоскоростной кэш-памяти (cache memory), как показано на рис. 1.5. В кэше сохраняются данные, обращение к которым происходит наиболее часто. Все запросы к памяти происходят через кэш. Если запрошенные данные находятся в кэш-памяти, то на запрос процессора реагирует она и обращения к шине не выполняются. Если размер кэш-памяти достаточно велик, вероятность успеха, называемая также коэффициентом кэш-попаданий (hit rate), велика и шинный трафик в расчете на один процессор резко уменьшается, позволяя включить в систему значительно больше процессоров. Общепринятыми являются размеры кэша от 512 Кбайт до 1 Мбайт, коэффициент кэш-попаданий при этом обычно составляет 90 % и более.

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

Проблема мультипроцессорных систем шинной архитектуры состоит в их ограниченной масштабируемости, даже в случае использования кэша. Для построения мультипроцессорной системы с более чем 256 процессорами для соединения процессоров с памятью необходимы другие методы. Один из вариантов — разделить общую память на модули и связать их с процессорами через коммутирующую решетку (crossbar switch), как показано на рис. 1.6, а. Как видно из рисунка, с ее помощью каждый процессор может быть связан с любым модулем памяти. Каждое пересечение представляет собой маленький электронный узловой коммутатор (crosspoint switch), который может открываться и закрываться аппаратно. Когда процессор желает получить доступ к конкретному модулю памяти, соединяющие их узловые коммутаторы мгновенно открываются, организуя запрошенный доступ. Достоинство узловых коммутаторов в том, что к памяти могут одновременно обращаться несколько процессоров, хотя если два процессора одновременно хотят получить доступ к одному и тому же участку памяти, то одному из них придется подождать.

Недостатком коммутирующей решетки является то, что при наличии n процессоров и n модулей памяти нам потребуется n2 узловых коммутаторов. Для больших значений n это число может превысить наши возможности. Обнаружив это, человечество стало искать и нашло альтернативные коммутирующие сети, требующие меньшего количества коммутаторов. Один из примеров таких сетей — омегасеть (omega network), представленная на рис. 1.6, б. Эта сеть содержит четыре коммутатора 2x2, то есть каждый из них имеет по два входа и два выхода. Каждый коммутатор может соединять любой вход с любым выходом. Если внимательно изучить возможные положения коммутаторов, становится ясно, что любой процессор может получить доступ к любому блоку памяти. Недостаток коммутирующих сетей состоит в том, что сигнал, идущий от процессора к памяти или обратно, вынужден проходить через несколько коммутаторов. Поэтому, чтобы снизить задержки между процессором и памятью, коммутаторы должны иметь очень высокое быстродействие, а дешево это не дается.

Люди пытаются уменьшить затраты на коммутацию путем перехода к иерархическим системам. В этом случае с каждым процессором ассоциируется некоторая область памяти. Каждый процессор может быстро получить доступ к своей области памяти. Доступ к другой области памяти происходит значительно медленнее. Эта идея была реализована в машине с неунифицированным доступом к памяти (NonUniform Memory Access, NUMA). Хотя машины NUMA имеют лучшее среднее время доступа к памяти, чем машины на базе омегасетей, у них есть свои проблемы, связанные с тем, что размещение программ и данных необходимо производить так, чтобы большая часть обращений шла к локальной памяти.

1.1. Определение распределенной системы

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

Однако в середине восьмидесятых под воздействием двух технологических новинок ситуация начала меняться. Первой из этих новинок была разработка мощных микропроцессоров. Изначально они были 8-битными, затем стали дос тупны 16-, 32- и 64-битные процессоры. Многие из них обладали вычислительной мощностью мэйнфреймов (то есть больших компьютеров), но лишь частью их цены.

Скорость роста, наблюдавшаяся в компьютерных технологиях в последние полвека, действительно потрясает. Ей нет прецедентов в других отраслях. От машин, стоивших 100 миллионов долларов и выполнявших одну команду в секунду, мы пришли к машинам, стоящим 1000 долларов и выполняющим 10 миллионов команд в секунду. Разница в соотношении цена/производительность достигла порядка 1012. Если бы автомобили за этот период совершенствовались такими же темпами, «роллс-ройс» сейчас стоил бы один доллар и проходил миллиард миль на одном галлоне бензина (к сожалению, к нему потребовалось бы 200-страничноеруководство по открыванию дверей).

Второй из новинок было изобретение высокоскоростных компьютерных сетей. Локальные сети (Local - Area Networks, LAN) соединяют сотни компьютеров, находящихся в здании, таким образом, что машины в состоянии обмениваться небольшими порциями информации за несколько микросекунд. Большие массивы данных передаются с машины на машину со скоростью от 10 до 1000 Мбит/с. Глобальные сети (Wide - Area Networks , WAN) позволяют миллионам машин во всем мире обмениваться информацией со скоростями, варьирующимися от 64 кбит/с (килобит в секунду) до гигабит в секунду.

В результате развития этих технологий сегодня не просто возможно, но и дос таточно легко можно собрать компьютерную систему, состоящую из множества компьютеров, соединенных высокоскоростной сетью. Она обычно называется компьютерной сетью, или распределенной системой (distributed system), в отличие от предшествовавших ей централизованных (centralized systems), или одно процессорных (single - processor systems), систем, состоявших из одного компьютера, его периферии и, возможно, нескольких удаленных терминалов.

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

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

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

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

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

Для того чтобы поддержать представление различных компьютеров и сетей в виде единой системы, организация распределенных систем часто включает в себя дополнительный уровень программного обеспечения, находящийся между верхним уровнем, на котором находятся пользователи и приложения, и нижним уровнем, состоящим из операционных систем, как показано на рис. 1.1. Соответственно, такая распределенная система обычно называется системой промежуточного уровня (middleware).

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

В качестве последнего примера рассмотрим World Wide Web. Web предоставляет простую, целостную и единообразную модель распределенных документов. Чтобы увидеть документ, пользователю достаточно активизировать ссылку. После этого документ появляется на экране. В теории (но определенно не в текущей практике) нет необходимости знать, с какого сервера доставляется документ, достаточно лишь информации о том, где он расположен. Публикация документа очень проста: вы должны только задать ему уникальное имя в форме унифицированного указателя ресурса (Uniform Resource Locator, URL), которое ссылается на локальный файл с содержимым документа. Если бы Всемирная паутина представлялась своим пользователям гигантской централизованной системой документооборота, она также могла бы считаться распределенной системой. К сожалению, этот момент еще не наступил. Так, пользователи сознают, что документы находятся в различных местах и распределены по различным серверам.

1.2. Задачи распределенных систем

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

1.2.1. Соединение пользователей с ресурсами

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

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

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

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

1.2.2. Прозрачность

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

Прозрачность в распределенных системах

Концепция прозрачности, как видно из табл. 1.1, применима к различным аспектам распределенных систем.

Таблица 1.1. Различные формы прозрачности в распределенных системах

Прозрачность

Описание

Доступ

Скрывается разница в представлении данных и доступе к ресурсам

Местоположение

Скрывается местоположение ресурса

Перенос

Скрывается факт перемещения ресурса в другое место

Смена местоположения

Скрывается факт перемещения ресурса в процессе обработки в другое место

Репликация

Скрывается факт репликации ресурса

Параллельный доступ

Скрывается факт возможного совместного использования ресурса несколькими конкурирующими пользователями

Отказ

Скрывается отказ и восстановление ресурса

Сохранность

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

Прозрачность доступа (access transparency) призвана скрыть разницу в представлении данных и в способах доступа пользователя к ресурсам. Так, при пересылке целого числа с рабочей станции на базе процессора Intel на Sun SPARC необходимо принять во внимание, что процессоры Intel оперируют с числами формата «младший — последним» (то есть первым передается старший байт), а процессор SPARC использует формат «старший — последним» (то есть первым передается младший байт). Также в данных могут присутствовать и другие несоответствия. Например, распределенная система может содержать компьютеры с различными операционными системами, каждая из которых имеет собственные ограничения на способ представления имен файлов. Разница в ограничениях на способ представления имен файлов, так же как и собственно работа с ними, должны быть скрыты от пользователей и приложений.

Важная группа типов прозрачности связана с местоположением ресурсов. Прозрачность местоположения (location transparency) призвана скрыть от пользователя, где именно физически расположен в системе нужный ему ресурс. Важную роль в реализации прозрачности местоположения играет именование. Так, прозрачность местоположения может быть достигнута путем присвоения ресурсам только логических имен, то есть таких имен, в которых не содержится закодированных сведений о местоположении ресурса. Примером такого имени может быть URL: http://~wiv.prenhall.com/index.html, в котором не содержится никакой информации о реальном местоположении главного web-сервера издательства Prentice Hall. URL также не дает никакой информации о том, находился ли файл index.html в указанном месте постоянно или оказался там недавно. О распределенных системах, в которых смена местоположения ресурсов не влияет на доступ к ним, говорят как об обеспечивающих прозрачность переноса (mig-ration transparency). Более серьезна ситуация, когда местоположение ресурсов может измениться в процессе их использования, причем пользователь или приложение ничего не заметят. В этом случае говорят, что система поддерживает прозрачность смены местоположения (relocation transparency). Примером могут служить мобильные пользователи, работающие с беспроводным переносным компьютером и не отключающиеся (даже временно) от сети при перемещении с места на место.

Как мы увидим, репликация имеет важное значение в распределенных системах. Так, ресурсы могут быть реплицированы для их лучшей доступности или повышения их производительности путем помещения копии неподалеку от того места, из которого к ней осуществляется доступ. Прозрачность репликации (replication transparency) позволяет скрыть тот факт, что существует несколько копий ресурса. Для скрытия факта репликации от пользователей необходимо, чтобы все реплики имели одно и то же имя. Соответственно, система, которая поддерживает прозрачность репликации, должна поддерживать и прозрачность местоположения, поскольку иначе невозможно будет обращаться к репликам без указания их истинного местоположения.

Мы часто упоминаем, что главная цель распределенных систем — обеспечить совместное использование ресурсов. Во многих случаях совместное использование ресурсов достигается посредством кооперации, например в случае коммуникаций. Однако существует множество примеров настоящего совместного использования ресурсов. Например, два независимых пользователя могут сохранять свои файлы на одном файловом сервере или работать с одной и той же таблицей в совместно используемой базе данных. Следует отметить, что в таких случаях ни один из пользователей не имеет никакого понятия о том, что тот же ресурс задействован другим пользователем. Это явление называется прозрачностью параллельного доступа (concurrency transparency). Отметим, что подобный параллельный доступ к совместно используемому ресурсу сохраняет этот ресурс в непротиворечивом состоянии. Непротиворечивость может быть обеспечена механизмом блокировок, когда пользователи, каждый по очереди, получают исключительные права на запрашиваемый ресурс. Более изощренный вариант — использование транзакций, однако, механизм транзакций в распределенных системах труднореализуем.

Популярное альтернативное определение распределенных систем, принадлежащее Лесли Лампорт (Leslie Lamport), выглядит так: «Вы понимаете, что у вас есть эта штука, поскольку при поломке компьютера вам никогда не предлагают приостановить работу». Это определение указывает еще на одну важную сторону распределенных систем: прозрачность отказов. Прозрачность отказов (failure transparency) означает, что пользователя никогда не уведомляют о том, что ресурс (о котором он мог никогда и не слышать) не в состоянии правильно работать и что система далее восстановилась после этого повреждения. Маскировка сбоев — это одна из сложнейших проблем в распределенных системах и столь же необходимая их часть. Основная трудность состоит в маскировке проблем, возникающих в связи с невозможностью отличить неработоспособные ресурсы от ресурсов с очень медленным доступом. Так, контактируя с перегруженным web-сервером, браузер выжидает положенное время, а затем сообщает о недоступности страницы. При этом пользователь не должен думать, что сервер и правда не работает.

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

Степень прозрачности

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

Точно так же в глобальной распределенной системе, которая соединяет процесс в Сан-Франциско с процессом в Амстердаме, вам не удастся скрыть тот факт, что мать-природа не позволяет пересылать сообщения от одного процесса к другому быстрее чем за примерно 35 мс. Практика показывает, что при использовании компьютерных сетей на это реально требуется несколько сотен миллисекунд. Скорость передачи сигнала ограничивается не столько скоростью света, сколько скоростью работы промежуточных переключателей.

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

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

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

1.2.3. Открытость

Другая важная характеристика распределенных систем — это открытость. Открытая распределенная система (open distributed system) — это система, предлагающая службы, вызов которых требует стандартные синтаксис и семантику. Например, в компьютерных сетях формат, содержимое и смысл посылаемых и принимаемых сообщений подчиняются типовым правилам. Эти правила формализованы в протоколах. В распределенных системах службы обычно определяются через интерфейсы (interfaces), которые часто описываются при помощи языка определения интерфейсов (Interface Definition Language , IDL). Описание интерфейса на IDL почти исключительно касается синтаксиса служб. Другими словами, оно точно отражает имена доступных функций, типы параметров, возвращаемых значений, исключительные ситуации, которые могут быть возбуждены службой и т. п. Наиболее сложно точно описать то, что делает эта служба, то есть семантику интерфейсов. На практике подобные спецификации задаются неформально, посредством естественного языка.

Будучи правильно описанным, определение интерфейса допускает возможность совместной работы произвольного процесса, нуждающегося в таком интерфейсе, с другим произвольным процессом, предоставляющим этот интерфейс. Определение интерфейса также позволяет двум независимым группам создать абсолютно разные реализации этого интерфейса для двух различных распределенных систем, которые будут работать абсолютно одинаково. Правильное определение самодостаточно и нейтрально. «Самодостаточно» означает, что в нем имеется все необходимое для реализации интерфейса. Однако многие определения интерфейсов сделаны самодостаточными не до конца, поскольку разработчикам необходимо включать в них специфические детали реализации. Важно отметить, что спецификация не определяет внешний вид реализации, она должна быть нейтральной. Самодостаточность и нейтральность необходимы для обеспечения переносимости и способности к взаимодействию. Способность к взаимодействию (interoperability) характеризует, насколько две реализации систем или компонентов от разных производителей в состоянии совместно работать, полагаясь только на то, что службы каждой из них соответствуют общему стандарту. Переносимость (portability) характеризует то, насколько приложение, разработанное для распределенной системы А, может без изменений выполняться в распределенной системе В, реализуя те же, что и в А интерфейсы.

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

Отделение правил от механизмов

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

Необходимость изменений в распределенных системах часто связана с тем, что компонент не оптимальным образом соответствует нуждам конкретного пользователя или приложения. Так, например, рассмотрим кэширование в World Wide Web. Браузеры обычно позволяют пользователям адаптировать правила кэширования под их нужды путем определения размера кэша, а также того, должен ли кэшируемый документ проверяться на соответствие постоянно или только один раз за сеанс. Однако пользователь не может воздействовать на другие параметры кэширования, такие как длительность сохранения документа в кэше или очередность удаления документов из кэша при его переполнении. Также невозможно создавать правила кэширования на основе содержимого документа. Так, например, пользователь может пожелать кэшировать железнодорожные расписания, которые редко изменяются, но никогда — информацию о пробках на улицах города.

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

1.2.4. Масштабируемость

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

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

Проблемы масштабируемости

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

Таблица 1.2. Примеры ограничений масштабируемости

Концепция

Пример

Централизованные службы

Один сервер на всех пользователей

Централизованные данные

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

Централизованные алгоритмы

Организация маршрутизации на основе полной информации

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

Централизация данных так же вредна, как и централизация служб. Как выбудете отслеживать телефонные номера и адреса 50 миллионов человек? Предположим, что каждая запись укладывается в 50 символов. Необходимой емкостью обладает один 2,5-гигабайтный диск. Но и в этом случае наличие единой базы данных несомненно вызовет перегрузку входящих и исходящих линий связи. Так, представим себе, как работал бы Интернет, если бы служба доменных имен (DNS) была бы реализована в виде одной таблицы. DNS обрабатывает информацию с миллионов компьютеров во всем мире и предоставляет службу, необходимую для определения местоположения web -серверов. Если бы каждый запрос на интерпретацию URL передавался бы на этот единственный DNS -сервер, воспользоваться Web не смог бы никто (кстати, предполагается, что эти проблемы придется решать снова).

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

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

  •  ни одна из машин не обладает полной информацией о состоянии системы;
  •  машины принимают решения на основе локальной информации;
  •  сбой на одной машине не вызывает нарушения алгоритма;
  •  не требуется предположения о существовании единого времени.

Первые три свойства поясняют то, о чем мы только что говорили. Последнее, вероятно, менее очевидно, но не менее важно. Любой алгоритм, начинающийся со слов: «Ровно в 12:00:00 все машины должны определить размер своих входных очередей», работать не будет, поскольку невозможно синхронизировать все часы на свете. Алгоритмы должны принимать во внимание отсутствие полной синхронизации таймеров. Чем больше система, тем большим будет и рассогласование. В одной локальной сети путем определенных усилий можно добиться, чтобы рассинхронизация всех часов не превышала нескольких миллисекунд, но сделать это в масштабе страны или множества стран? Вы, должно быть, шутите.

У географической масштабируемости имеются свои сложности. Одна из основных причин сложности масштабирования существующих распределенных систем, разработанных для локальных сетей, состоит в том, что в их основе лежит принцип синхронной связи (synchronous communication). В этом виде связи запрашивающий службу агент, которого принято называть клиентом (client), блокируется до получения ответа. Этот подход обычно успешно работает в локальных сетях, когда связь между двумя машинами продолжается максимум сотни микросекунд. Однако в глобальных системах мы должны принять во внимание тот факт, что связь между процессами может продолжаться сотни миллисекунд, то есть на три порядка дольше. Построение интерактивных приложений с использованием синхронной связи в глобальных системах требует большой осторожности (и немалого терпения).

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

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

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

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

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

Технологии масштабирования

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

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

Однако многие приложения не в состоянии эффективно использовать асинхронную связь. Например, когда в интерактивном приложении пользователь посылает запрос, он обычно не в состоянии делать ничего более умного, чем просто ждать ответа. В этих случаях наилучшим решением будет сократить необходимый объем взаимодействия, например, переместив часть вычислений, обычно выполняемых на сервере, на клиента, процесс которого запрашивает службу. Стандартный случай применения этого подхода — доступ к базам данных с использованием форм. Обычно заполнение формы сопровождается посылкой отдельного сообщения на каждое поле и ожиданием подтверждения приема от сервера, как показано на рис. 1.2, а. Сервер, например, может перед приемом введенного значения проверить его на синтаксические ошибки. Более успешное решение состоит в том, чтобы перенести код для заполнения формы и, возможно, проверки введенных данных на клиента, чтобы он мог послать серверу целиком заполненную форму (рис. 1.2, б). Такой подход — перенос кода на клиента — в настоящее время широко поддерживается в Web посредством Java -апплетов.

Следующая важная технология масштабирования — распределение (distribution). Распределение предполагает разбиение компонентов на мелкие части и последующее разнесение этих частей по системе. Хорошим примером распределения является система доменных имен Интернета (DNS). Пространство DNS имен организовано иерархически, в виде дерева доменов (domains), которые разбиты на неперекрывающиеся зоны (zones), как показано на рис. 1.3. Имена каждой зоны обрабатываются одним сервером имен. Не углубляясь чересчур в детали, можно считать, что каждое доменное имя является именем хоста в Интернете и ассоциируется с сетевым адресом этого хоста. В основном интерпретация имени означает получение сетевого адреса соответствующего хоста. Рассмотрим, к примеру, имя nl . vu . cs . flits . Для интерпретации этого имени оно сначала передается на сервер зоны Z 1 (рис. 1.3), который возвращает адрес сервера зоны Z 2, который, вероятно, сможет обработать остаток имени, vu . cs . flits . Сервер зоны Z 2 вернет адрес сервера зоны Z 3 , который способен обработать последнюю часть имени и вернуть адрес соответствующего хоста.

Эти примеры демонстрируют, как служба именования, предоставляемая DNS, распределена по нескольким машинам и как это позволяет избежать обработки всех запросов на интерпретацию имен одним сервером.

В качестве другого примера рассмотрим World Wide Web . Для большинства пользователей Web представляется гигантской информационной системой документооборота, в которой каждый документ имеет свое уникальное имя — URL .

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

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

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

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

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

2 Концепции аппаратных решений

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

За прошедшие годы было предложено множество различных схем классификации компьютерных систем с несколькими процессорами, но ни одна из них не стала действительно популярной и широко распространенной. Нас интересуют исключительно системы, построенные из набора независимых компьютеров. На рис. 1.4 мы подразделяем все компьютеры на две группы. Системы, в которых компьютеры используют память совместно, обычно называются мультипроцессорами (multiprocessors), а работающие каждый со своей памятью — мультикомпьютерами (multicomputers). Основная разница между ними состоит в том, что мультипроцессоры имеют единое адресное пространство, совместно используемое всеми процессорами. Если один из процессоров записывает, например, значение 44 по адресу 1000, любой другой процессор, который после этого прочтет значение, лежащее по адресу 1000, получит 44. Все машины задействуют одну и ту же память

.

В отличие от таких машин в мультикомпьютерах каждая машина использует свою собственную память. После того как один процессор запишет значение 44 по адресу 1000, другой процессор, прочитав значение, лежащее по адресу 1000, получит то значение, которое хранилось там раньше. Запись по этому адресу значения 44 другим процессором никак не скажется на содержимом его памяти. Типичный пример мультикомпьютера — несколько персональных компьютеров, объединенных в сеть.

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

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

Мы проведем также разделение распределенных компьютерных систем на гомогенные (homogeneous) и гетерогенные (heterogeneous). Это разделение применяется исключительно к мультикомпьютерным системам. Для гомогенных мультикомпьютерных систем характерна одна соединяющая компьютеры сеть, использующая единую технологию. Одинаковы также и все процессоры, которые в основном имеют доступ к одинаковым объемам собственной памяти. Гомогенные мультикомпьютерные системы нередко используются в качестве параллельных (работающих с одной задачей), в точности как мультипроцессорные.

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

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

3 Гомогенные мультикомпьютерные системы

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

Сначала мы рассмотрим гомогенные мультикомпьютерные системы. В этих системах, известных под названием системных сетей (System Area Networks, SAN), узлы монтируются в большой стойке и соединяются единой, обычно высокоскоростной сетью. Как и в предыдущем случае, нам придется выбирать между системами на основе шинной архитектуры и системами на основе коммутации.

В мультикомпьютерных системах с шинной архитектурой процессоры соединяются при помощи разделяемой сети множественного доступа, например FastEthernet. Скорость передачи данных в сети обычно равна 100 Мбит/с. Как и в случае мультипроцессоров с шинной архитектурой, мультикомпьютерные системы с шинной архитектурой имеют ограниченную масштабируемость. В зависимости от того, сколько узлов в действительности нуждаются в обмене данными, обычно не следует ожидать высокой производительности при превышении системой предела в 25—100 узлов.

В коммутируемых мультикомпьютерных системах сообщения, передаваемые от процессора к процессору, маршрутизируются в соединительной сети в отличие от принятых в шинной архитектуре широковещательных рассылок. Было предложено и построено множество различных топологий. Две популярные топологии — квадратные решетки и гиперкубы — представлены на рис. 1.7. Решетки просты для понимания и удобны для разработки на их основе печатных плат. Они прекрасно подходят для решения двухмерных задач, например задач теории графов или компьютерного зрения (глаза робота, анализ фотографий).

Гиперкуб (hypercube) представляет собой куб размерности n. Гиперкуб, показанный на рис. 1.7, б, четырехмерен. Его можно представить в виде двух обычных кубов, с 8 вершинами и 12 ребрами каждый. Каждая вершина — это процессор. Каждое ребро — это связь между двумя процессорами. Соответствующие вершины обоих кубов соединены между собой. Для расширения гиперкуба в пятое измерение мы должны добавить к этой фигуре еще один комплект из двух связанных кубов, соединив соответствующие вершины двух половинок фигуры. Таким же образом можно создать шестимерный куб, семимерный и т. д.

Коммутируемые мультикомпьютерные системы могут быть очень разнообразны. На одном конце спектра лежат процессоры с массовым параллелизмом (Massively Parallel Processors, МРР), гигантские суперкомпьютеры стоимостью во много миллионов долларов, содержащие тысячи процессоров. Нередко они собираются из тех же процессоров, которые используются в рабочих станциях или персональных компьютерах. От других мультикомпьютерных систем их отличает наличие патентованных высокоскоростных соединительных сетей. Эти сети проектируются в расчете на малое время задержки и высокую пропускную способность. Кроме того, предпринимаются специальные меры для защиты системы от сбоев. При наличии тысяч процессоров каждую неделю как минимум несколько будут выходить из строя. Нельзя допустить, чтобы поломка одного из них приводила к выводу из строя всей машины.

На другом конце спектра мы обнаруживаем популярный тип коммутируемых микрокомпьютеров, известных как кластеры рабочих станций (Clusters Of Workstations, COW), основу которых составляют стандартные персональные компьютеры или рабочие станции, соединенные посредством коммерческих коммуникационных компонентов, таких как карты Myrinet. Соединительные сети — вот то, что отличает COW от МРР. Кроме того, обычно не предпринимается никаких особых мер для повышения скорости ввода-вывода или защиты от сбоев в системе. Подобный подход делает COW проще и дешевле.

4 Гетерогенные мультикомпьютерные системы

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

Соединяющая их сеть также может быть сильно неоднородной. Так, например, авторы этой книги помогали разрабатывать самодельную распределенную компьютерную систему, названную DAS, состоящую из четырех кластеров мультикомпьютерных систем, соединенных высокопроизводительными ATM коммутируемыми каналами. Фотографии этой системы и ссылки на исследования, проводимые на ней, можно найти по адресу http://www.cs.vu.nllballdas.html. Кластеры также были связаны между собой через стандартные Интернет-соединения. Каждый кластер содержал одинаковые процессоры (Pentium III) и соединяющую их сеть (Myrinet), но различался по числу процессоров (64128).

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

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

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

6 Концепции программных решений

Аппаратура важна для распределенных систем, однако от программного обеспечения значительно сильнее зависит, как такая система будет выглядеть на самом деле. Распределенные системы очень похожи на традиционные операционные системы. Прежде всего, они работают как менеджеры ресурсов (resource managers) существующего аппаратного обеспечения, которые помогают множеству пользователей и приложений совместно использовать такие ресурсы, как процессоры, память, периферийные устройства, сеть и данные всех видов. Во-вторых, что, вероятно, более важно, распределенная система скрывает сложность и гетерогенную природу аппаратного обеспечения, на базе которого она построена, предоставляя виртуальную машину для выполнения приложений.

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

Это деление на сильно и слабо связанные системы связано с классификацией аппаратного обеспечения, приведенной в предыдущем разделе. Сильно связанные операционные системы обычно называются распределенными операционными системами (Distributed Operating System, DOS) и используются для управления мультипроцессорными и гомогенными мультикомпьютерными системами. Как и у традиционных однопроцессорных операционных систем, основная цель распределенной операционной системы состоит в сокрытии тонкостей управления аппаратным обеспечением, которое одновременно используется множеством процессов.

Слабо связанные сетевые операционные системы (Network Operating Systems, NOS) используются для управления гетерогенными мультикомпьютерными системами. Хотя управление аппаратным обеспечением и является основной задачей сетевых операционных систем, они отличаются от традиционных. Это отличие вытекает из того факта, что локальные службы должны быть доступными для удаленных клиентов. В следующих пунктах мы рассмотрим в первом приближении те и другие.

Чтобы действительно составить распределенную систему, служб сетевой операционной системы недостаточно. Необходимо добавить к ним дополнительные компоненты, чтобы организовать лучшую поддержку прозрачности распределения. Этими дополнительными компонентами будут средства, известные как системы промежуточного уровня (middleware), которые и лежат в основе современных распределенных систем. Средства промежуточного уровня также обсуждаются в этой главе. В табл. 1.3 представлены основные данные по распределенным и сетевым операционным системам, а также средствам промежуточного уровня.

Таблица 1.3. Краткое описание распределенных и сетевых операционных систем, а также сре дств пр омежуточного уровня

Система

Описание

Основное назначение

Распределенные операционные системы

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

Сокрытие и управление аппаратным обеспечением

Сетевые операционные системы

Слабо связанные операционные системы для гетерогенных мультикомпьютерных систем (локальных или глобальных сетей)

Предоставление локальных служб удаленным клиентам

Средства промежуточного уровня

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

Обеспечение прозрачности распределения

7 5 Распределенные операционные системы

Существует два типа распределенных операционных систем. Мультипроцессорная операционная система (multiprocessor operating system) управляет ресурсами мультипроцессора. Мулътикомпъютерная операционная система (multicomputeroperating system) разрабатывается для гомогенных мультикомпьютеров. Функциональность распределенных операционных систем в основном не отличается от функциональности традиционных операционных систем, предназначенных для компьютеров с одним процессором за исключением того, что она поддерживает функционирование нескольких процессоров. Поэтому давайте кратко обсудим операционные системы, предназначенные для обыкновенных компьютеров с одним процессором.

Операционные системы для однопроцессорных компьютеров

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

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

Следовательно, операционная система должна полностью контролировать использование и распределение аппаратных ресурсов. Поэтому большинство процессоров поддерживают как минимум два режима работы. В режиме ядра (kernelmode) выполняются все разрешенные инструкции, а в ходе выполнения доступна вся имеющаяся память и любые регистры. Напротив, в пользовательском режиме (user mode) доступ к регистрам и памяти ограничен. Так, приложению не будет позволено работать с памятью за пределами набора адресов, установленного для него операционной системой, или обращаться напрямую к регистрам устройств. На время выполнения кода операционной системы процессор переключается в режим ядра. Однако единственный способ перейти из пользовательского режима в режим ядра — это сделать системный вызов, реализуемый через операционную систему. Поскольку системные вызовы — это лишь базовые службы, предоставляемые операционной системой, и поскольку ограничение доступа к памяти и регистрам нередко реализуется аппаратно, операционная система в состоянии полностью их контролировать.

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

Более удобен вариант с организацией операционной системы в виде двух частей. Одна часть содержит набор модулей для управления аппаратным обеспечением, которые прекрасно могут выполняться в пользовательском режиме. Например, управление памятью состоит в основном из отслеживания, какие блоки памяти выделены под процессы, а какие свободны. Единственный момент, когда мы нуждаемся в работе в режиме ядра, — это установка регистров блока управления памятью.

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

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

У микроядер имеется два существенных недостатка. Во-первых, они работают иначе, чем существующие операционные системы, а попытки поменять сложившееся «статус-кво» всегда встречают активное сопротивление («если эта операционная система подходила для моего деда — она подойдет и для меня»). Во-вторых, микроядро требует дополнительного обмена, что слегка снижает производительность. Однако, зная как быстры современные процессоры, снижение производительности в 20 % вряд ли можно считать фатальным.

Мультипроцессорные операционные системы

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

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

Многопроцессорные операционные системы нацелены на поддержание высокой производительности конфигураций с несколькими процессорами. Основная их задача — обеспечить прозрачность числа процессоров для приложения. Сделать это достаточно легко, поскольку сообщение между различными приложениями или их частями требует тех же примитивов, что и в многозадачных однопроцессорных операционных системах. Идея состоит в том, что все сообщение происходит путем работы с данными в специальной совместно используемой области данных, и все что нам нужно — это защитить данные от одновременного доступа к ним. Защита осуществляется посредством примитивов синхронизации.

Мультикомпьютерные операционные системы

Мультикомпьютерные операционные системы обладают гораздо более разнообразной структурой и значительно сложнее, чем мультипроцессорные. Эта разница проистекает из того факта, что структуры данных, необходимые для управления системными ресурсами, не должны больше отвечать условию легкости совместного использования, поскольку их не нужно помещать в физически общую память. Единственно возможным видом связи является передача сообщений (messagepassing). Мультикомпьютерные операционные системы в основном организованы так, как показано на рис. 1.9.

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

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

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

8 Сетевые операционные системы

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

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

rlogin machine

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

Сетевые операционные системы также имеют в своем составе команду удаленного копирования для копирования файлов с одной машины на другую. Например:

rср machine1: file1 machine2: file 2

Эта команда приведет к копированию файла file1 с машины machine1 на machine2 и присвоению ему там имени file2. При этом перемещение файлов задается в явном виде, и пользователю необходимо точно знать, где находятся файлы и как выполняются команды.

Такая форма связи хотя и лучше чем ничего, но все же крайне примитивна. Это подвигло проектировщиков систем на поиски более удобных вариантов связи и совместного использования информации. Один из подходов предполагает создание глобальной общей файловой системы, доступной со всех рабочих станций. Файловая система поддерживается одной или несколькими машинами, которые называются файловыми серверами (file servers). Файловые серверы принимают запросы от программ пользователей, запускаемых на других машинах (не на серверах), которые называются клиентами (clients), на чтение и запись файлов. Каждый пришедший запрос проверяется и выполняется, а результат пересылается назад, как показано на рис. 1.14.

Файловые серверы обычно поддерживают иерархические файловые системы, каждая с корневым каталогом, содержащим вложенные каталоги и файлы. Рабочие станции могут импортировать или монтировать эти файловые системы, увеличивая свою локальную файловую систему за счет файловой системы сервера. Так, например, на рис. 1.15 показаны два файловых сервера. На одном из них имеется каталог под названием games, а на другом — каталог под названием work (имена каталогов на рисунке выделены жирным шрифтом). Каждый из этих каталогов содержит некоторые файлы. На обоих клиентах смонтированы файловые системы обоих серверов, но в разных местах файловых систем клиентов. Клиент 1 смонтировал их в свой корневой каталог и имеет к ним доступ по путям /games и /work соответственно. Клиент 2, подобно Клиенту 1, смонтировал каталог work в свой корневой каталог, но решил, что игры (games) должны быть его частным делом. Поэтому он создал каталог, который назвал /private, и смонтировал каталог games туда. Соответственно, он получит доступ к файлу рас woman через путь /private/games/pacwoman, а не /games/pacwoman .

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

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

«Нехватка» прозрачности в сетевых операционных системах имеет некоторые очевидные обратные стороны. Например, с ними часто сложно работать, поскольку пользователь вынужден явно подсоединяться к удаленным машинам или копировать файлы с одной машины на другую. Это также проблемы с управлением. Поскольку все машины под управлением сетевой операционной системы независимы, часто и управлять ими можно исключительно независимо. В результате пользователь может получить удаленное соединение с машиной X, только имея на ней регистрацию. Таким образом, если пользователь хочет использовать один пароль на «все случаи жизни», то для смены пароля он вынужден будет явно сменить его на каждой машине. Рассуждая далее, мы видим, что в основном все права доступа относятся к конкретной машине. Нет простого метода сменить права доступа, поскольку всюду они свои. Такой децентрализованный подход к безопасности нередко затрудняет защиту сетевой операционной системы от атак злоумышленников.

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

9 Программное обеспечение промежуточного уровня

Ни распределенные, ни сетевые операционные системы не соответствуют нашему определению распределенных систем, данному в разделе 1.1. Распределенные операционные системы не предназначены для управления набором независимых компьютеров, а сетевые операционные системы не дают представления одной согласованной системы. На ум приходит вопрос: а возможно ли вообще разработать распределенную систему, которая объединяла бы в себе преимущества двух «миров» — масштабируемость и открытость сетевых операционных систем и прозрачность и относительную простоту в использовании распределенных операционных систем? Решение было найдено в виде дополнительного уровня программного обеспечения, который в сетевых операционных системах позволяет более или менее скрыть от пользователя разнородность набора аппаратных платформ и повысить прозрачность распределения. Многие современные распределенные системы построены в расчете на этот дополнительный уровень, который получил название программного обеспечения промежуточного уровня. В этом пункте мы кратко рассмотрим, как устроено программное обеспечение промежуточного уровня, чтобы понять его особенности.

Позиционирование программного обеспечения промежуточного уровня

Многие распределенные приложения допускают непосредственное использование программного интерфейса, предлагаемого сетевыми операционными системами. Так, связь часто реализуется через операции с сокетами, которые позволяют процессам на разных машинах обмениваться сообщениями. Кроме того, приложения часто пользуются интерфейсами локальных файловых систем. Как мы понимаем, проблема такого подхода состоит в том, что наличие распределения слишком очевидно. Решение заключается в том, чтобы поместить между приложением и сетевой операционной системой промежуточный уровень программной поддержки, обеспечивающий дополнительное абстрагирование. Потому этот уровень и называется промежуточным. Он находится посредине между приложением и сетевой операционной системой, как показано на рис. 1.16.

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

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

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

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

Модели промежуточного уровня

Чтобы сделать разработку и интеграцию распределенных приложений как можно более простой, основная часть программного обеспечения промежуточного уровня базируется на некоторой модели, или парадигме, определяющей распределение и связь. Относительно простой моделью является представление всех наблюдаемых объектов в виде файлов. Этот подход был изначально введен в UNIX и строго соблюдался в Plan 9. В Plan 9 все ресурсы, включая устройства ввода-вывода, такие как клавиатура, мышь, диск, сетевые интерфейсы и т. д., рассматривались как файлы. Важно, что удаленные и локальные файлы ничем не отличались. Приложение открывало файлы, читало и записывало в них байты и закрывало их. Поскольку файлы могли совместно использоваться несколькими процессами, связь сокращалась до простого обращения к одному и тому же файлу.

Подобный же подход, но менее строгий, чем в Plan 9, применяется в программном обеспечении промежуточного уровня, построенном по принципу распределенной файловой системы (distributed file system). Во многих случаях это программное обеспечение всего на один шаг ушло от сетевых операционных систем в том смысле, что прозрачность распределения поддерживается только для стандартных файлов (то есть файлов, предназначенных только для хранения данных). Процессы, например, часто должны запускаться исключительно на определенных машинах. Программное обеспечение промежуточного уровня, основанное на модели распределенной файловой системы, оказалось достаточно легко масштабируемым, что способствовало его популярности.

Другая важная ранняя модель программного обеспечения промежуточного уровня основана на удаленных вызовах процедур (Remote Procedure Calls, RFC). В этой модели акцент делается на сокрытии сетевого обмена за счет того, что процессу разрешается вызывать процедуры, реализация которых находится на удаленной машине. При вызове такой процедуры параметры прозрачно передаются на удаленную машину, где, собственно, и выполняется процедура, после чего результат выполнения возвращается в точку вызова процедуры. За исключением, вероятно, некоторой потери производительности, все это выглядит как локальное исполнение вызванной процедуры: вызывающий процесс не уведомляется об имевшем место факте сетевого обмена. Мы вернемся к вызовам удаленных процедур в следующей главе.

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

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

Как модели могут упростить использование сетевых систем, вероятно, наилучшим образом видно на примере World Wide Web. Успех среды Web в основном определяется тем, что она построена на базе потрясающе простой, но высокоэффективной модели распределенных документов (distributed documents). В модели, принятой в Web, информация организована в виде документов, каждый из которых размещен на машине, расположение которой абсолютно прозрачно. Документы содержат ссылки, связывающие текущий документ с другими. Если следовать по ссылке, то документ, с которым связана эта ссылка, будет извлечен из места его хранения и выведен на экран пользователя. Концепция документа не ограничивается исключительно текстовой информацией. Например, в Web поддерживаются аудио и видеодокументы, а также различные виды документов на основе интерактивной графики.

Службы промежуточного уровня

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

Важная служба, общая для всех систем промежуточного уровня, — это именование (naming). Службы именования сравнимы с телефонными книгами или справочниками типа «Желтых страниц». Они позволяют совместно использовать и искать сущности (как в каталогах). Хотя присвоение имен на первый взгляд кажется простым делом, при масштабировании возникают серьезные трудности. Проблема состоит в том, что для эффективного поиска имени в большой системе местоположение разыскиваемой сущности должно считаться фиксированным.Такое допущение, в частности, принято в среде World Wide Web, в которой любой документ поименован посредством URL. URL содержит имя сервера, на котором находится документ с данным URL адресом. Таким образом, если документ переносится на другой сервер, его URL перестает работать.

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

Если хранение данных играет важную роль для оболочки, то обычно предоставляются и средства для распределенных транзакций (distributed transactions). Важным свойством транзакций является возможность множества операций чтения и записи в ходе одной атомарной операции. Под атомарностью мы понимаем тот факт, что транзакция может быть либо успешной (когда все операции записи завершаются успешно), либо неудачной, что оставляет все задействованные данные не измененными. Распределенные транзакции работают с данными, которые, возможно, разбросаны по нескольким машинам.

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

Ну и, наконец, практически все системы промежуточного уровня, используемые не только для экспериментов, предоставляют средства обеспечения защиты(security). По сравнению с сетевыми операционными системами проблема защиты в системах промежуточного уровня состоит в том, что они распределены. Промежуточный уровень в принципе не может «надеяться» на то, что базовые локальные операционные системы будут адекватно обеспечивать защиту всей сети. Соответственно, защита отчасти ложится на программное обеспечение промежуточного уровня. В сочетании с требованием расширяемости защита превращается в одни из наиболее трудно реализуемых в распределенных системах служб.

Промежуточный уровень и открытость

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

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

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

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

Сравнение систем

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

Таблица 1.5. Сравнение распределенных операционных систем, сетевых операционных систем и распределенных систем промежуточного уровня

 
Характеристика


Распределенная операционная
система

Сетевая операционная система

Распределенная система промежуточ-ного уровня

 

мульти- процессорная

мульти-компьютерная

 

 

Степень прозрачности

Очень высокая

Высокая

Низкая

Высокая

Идентичность операционной системы на всех узлах

Поддерживается

Поддерживается

Не поддерживается

Поддерживается

Число копий ОС

1

N

N

N

Коммуникации на основе

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

Сообщений

Файлов

В зависимости от модели

Управление ресурсами

Глобальное централизован ное

Глобальное распределенное

Отдельно на узле

Отдельно на узле

Масштабируемость

Отсутствует

Умеренная

Да

Различная

Что касается прозрачности, ясно, что распределенные операционные системы работают лучше, чем сетевые. В мультипроцессорных системах нам нужно скрывать только общее число процессоров, а это относительно несложно. Сложнее скрыть физическое распределение памяти, поэтому не просто создать мультикомпьютерную операционную систему с полностью прозрачным распределением. Распределенные системы часто повышают прозрачность путем использования специальных моделей распределения и связи. Так, например, распределенные файловые системы обычно хорошо скрывают местоположение файлов и доступ к ним Однако они несколько теряют в общности, и пользователи, решившие выразить все, что можно, в рамках конкретной модели, могут получить взамен проб темы с некоторыми приложениями.

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

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

И, наконец, сетевые операционные системы и распределенные системы промежуточного уровня выигрывают с точки зрения открытости В основном узлы поддерживают стандартный коммуникационный протокол типа TCP/IP, что делает несложной организацию их совместной работы. Однако здесь могут встретиться трудности с переносом приложений под разные платформы. Распределенные операционные системы в основном рассчитаны не на открытость, а на максимальную производительность, в результате на дороге к открытым системам у них стоит множество запатентованных решений.

10 Модель клиент-сервер

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

1.5.1. Клиенты и серверы

В базовой модели клиент-сервер все процессы в распределенных системах делятся на две возможно перекрывающиеся группы. Процессы, реализующие некоторую службу, например службу файловой системы или базы данных, называются серверами (servers). Процессы, запрашивающие службы у серверов путем посылки запроса и последующего ожидания ответа от сервера, называются клиентами(clients). Взаимодействие клиента и сервера, известное также под названием режим работы запрос-ответ (request-reply behavior), иллюстрирует рис. 1.18.

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

Использование не требующего соединения протокола дает существенный выигрыш в эффективности. До тех пор пока сообщения не начнут пропадать или повреждаться, можно вполне успешно применять протокол типа запрос-ответ. К сожалению, создать протокол, устойчивый к случайным сбоям связи, — нетривиальная задача. Все, что мы можем сделать, — это дать клиенту возможность повторно послать запрос, на который не был получен ответ. Проблема, однако, состоит в том, что клиент не может определить, действительно ли первоначальное сообщение с запросом было потеряно или ошибка произошла при передаче ответа. Если потерялся ответ, повторная посылка запроса может привести к повторному выполнению операции. Если операция представляла собой что-то вроде «снять 10 000 долларов с моего банковского счета», понятно, что было бы гораздо лучше, если бы вместо повторного выполнения операции вас просто уведомили о произошедшей ошибке. С другой стороны, если операция была «сообщите мне, сколько денег у меня осталось», запрос прекрасно можно было бы послать повторно. Нетрудно заметить, что у этой проблемы нет единого решения.

В качестве альтернативы во многих системах клиент-сервер используется надежный протокол с установкой соединения. Хотя это решение в связи с его относительно низкой производительностью не слишком хорошо подходит для локальных сетей, оно великолепно работает в глобальных системах, для которых ненадежность является «врожденным» свойством соединений. Так, практически все прикладные протоколы Интернета основаны на надежных соединениях по протоколу TCP/IP. В этих случаях всякий раз, когда клиент запрашивает службу, до посылки запроса серверу он должен установить с ним соединение. Сервер обычно использует для посылки ответного сообщения то же самое соединение, после чего оно разрывается. Проблема состоит в том, что установка и разрыв соединения в смысле затрачиваемого времени и ресурсов относительно дороги, особенно если сообщения с запросом и ответом невелики. Мы обсудим альтернативные решения, в которых управление соединением объединяется с передачей данных, в следующей главе.

11. Разделение приложений по уровням

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

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

  •  уровень пользовательского интерфейса;
  •  уровень обработки;
  •  уровень данных.

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

Уровень пользовательского интерфейса

Уровень пользовательского интерфейса обычно реализуется на клиентах. Этот уровень содержит программы, посредством которых пользователь может взаимодействовать с приложением. Сложность программ, входящих в пользовательский интерфейс, весьма различна.

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

В наше время даже в среде мэйнфреймов наблюдаются более совершенные пользовательские интерфейсы. Обычно на клиентских машинах имеется как минимум графический дисплей, на котором можно задействовать всплывающие или выпадающие меню и множество управляющих элементов, доступных для мыши или клавиатуры. Типичные примеры таких интерфейсов — надстройка XWindows, используемая во многих UNIX-системах, и более ранние интерфейсы, разработанные для персональных компьютеров, работающих под управлением MS-DOS и Apple Macintosh .

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

Уровень обработки

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

В качестве первого примера рассмотрим поисковую машину в Интернете. Если отбросить все анимированные баннеры, картинки и прочие оконные украшательства, пользовательский интерфейс поисковой машины очень прост: пользователь вводит строку, состоящую из ключевых слов, и получает список заголовков web-страниц. Результат формируется из гигантской базы просмотренных и проиндексированных web страниц. Ядром поисковой машины является программа, трансформирующая введенную пользователем строку в один или несколько запросов к базе данных. Затем она помещает результаты запроса в список и преобразует этот список в набор HTML-страниц. В рамках модели клиент-сервер часть, которая отвечает за выборку информации, обычно находится на уровне обработки. Эта структура показана на рис. 1.19.

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

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

Уровень данных

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

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

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

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

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

12 Варианты архитектуры клиент-сервер

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

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

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

Многозвенные архитектуры

Один из подходов к организации клиентов и серверов — это распределение программ, находящихся на уровне приложений, описанном в предыдущем пункте, по различным машинам, как показано на рис. 1.20. В качестве первого шага мы рассмотрим разделение на два типа машин: на клиенты и на серверы, что приведет нас к физически двухзвенной архитектуре (physically two-tiered architecture).

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

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

Во многих системах клиент-сервер популярна организация, представленная на рис. 1.20, г и д. Эти типы организации применяются в том случае, когда клиентская машина — персональный компьютер или рабочая станция — соединена сетью с распределенной файловой системой или базой данных. Большая часть приложения работает на клиентской машине, а все операции с файлами или базой данных передаются на сервер. Рисунок 1.20, д отражает ситуацию, когда часть данных содержится на локальном диске клиента. Так, например, при работе в Интернете клиент может постепенно создать на локальном диске огромный кэш наиболее часто посещаемых web-страниц.

Рассматривая только клиенты и серверы, мы упускаем тот момент, что серверу иногда может понадобиться работать в качестве клиента. Такая ситуация, отраженная на рис. 1.21, приводит нас к физически трехзвенной архитектуре (physically three-tiered architecture).

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

Современные варианты архитектуры

Многозвенные архитектуры клиент-сервер являются прямым продолжением разделения приложений на уровни пользовательского интерфейса, компонентов обработки и данных. Различные звенья взаимодействуют в соответствии с логической организацией приложения. Во множестве бизнес-приложений распределения обработка эквивалентна организации многозвенной архитектуры приложений клиент-сервер. Мы будем называть такой тип распределения вертикальным распределением (vertical distribution). Характеристической особенностью вертикального распределения является то, что оно достигается размещением логически различных компонентов на разных машинах. Это понятие связано с концепцией вертикального разбиения (vertical fragmentation), используемой в распределенных реляционных базах данных, где под этим термином понимается разбиение по столбцам таблиц для их хранения на различных машинах.

Однако вертикальное распределение — это лишь один из возможных способов организации приложений клиент-сервер, причем во многих случаях наименее интересный. В современных архитектурах распределение на клиенты и серверы происходит способом, известным как горизонтальное распределение (horizontal distribution). При таком типе распределения клиент или сервер может содержать физически разделенные части логически однородного модуля, причем работа с каждой из частей может происходить независимо. Это делается для выравнивания загрузки.

В качестве распространенного примера горизонтального распределения рассмотрим web-сервер, реплицированный на несколько машин локальной сети, как показано на рис. 1.22. На каждом из серверов содержится один и тот же набор web-страниц, и всякий раз, когда одна из web-страниц обновляется, ее копии незамедлительно рассылаются на все серверы. Сервер, которому будет передан приходящий запрос, выбирается по правилу «карусели» (round-robin). Эта форма горизонтального распределения весьма успешно используется для выравнивания нагрузки на серверы популярных web-сайтов.

Таким же образом, хотя и менее очевидно, могут быть распределены и клиенты. Для несложного приложения, предназначенного для коллективной работы, мы можем не иметь сервера вообще. В этом случае мы обычно говорим об одноранговом распределении (peer-to-peer distribution). Подобное происходит, например, если пользователь хочет связаться с другим пользователем. Оба они должны запустить одно и то же приложение, чтобы начать сеанс. Третий клиент может общаться с одним из них или обоими, для чего ему нужно запустить то же самое приложение.

22 PHP

PHP (англ. PHP: Hypertext Preprocessor — «PHP: препроцессор гипертекста», англ. Personal Home Page Tools[3] (устар.) — «Инструменты для создания персональных веб-страниц») — скриптовый язык[4] программирования общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов.[5]

Язык и его интерпретатор разрабатываются группой энтузиастов в рамках проекта с открытым кодом.[6] Проект распространяется под собственной лицензией, несовместимой с GNU GPL.

Область применения

В области программирования для Сети PHP — один из популярных скриптовых языков (наряду с JSP, Perl и языками, используемыми в ASP.NET) благодаря своей простоте, скорости выполнения, богатой функциональности, кроссплатформенности и распространению исходных кодов на основе лицензии PHP.

Популярность в области построения веб-сайтов определяется наличием большого набора встроенных средств для разработки веб-приложений[7]. Основные из них:

  •  автоматическое извлечение POST и GET-параметров, а также переменных окружения веб-сервера в предопределённые массивы;
  •  взаимодействие с большим количеством различных систем управления базами данных (MySQL, MySQLi, SQLite, PostgreSQL, Oracle (OCI8), Oracle, Microsoft SQL Server, Sybase, ODBC, mSQL, IBM DB2, Cloudscape и Apache Derby, Informix, Ovrimos SQL, Lotus Notes, DB++, DBM, dBase, DBX, FrontBase, FilePro, Ingres II, SESAM, Firebird / InterBase, Paradox File Access, MaxDB, Интерфейс PDO);
  •  автоматизированная отправка HTTP-заголовков;
  •  работа с HTTP-авторизацией;
  •  работа с cookies и сессиями;
  •  работа с локальными и удалёнными файлами, сокетами.
  •  обработка файлов, загружаемых на сервер;
  •  работа с XForms;

В настоящее время PHP используется сотнями тысяч разработчиков. Согласно рейтингу корпорации TIOBE, базирующемся на данных поисковых систем, в апреле 2011 года PHP находился на 5 месте среди языков программирования.[5] К крупнейшим сайтам, использующим PHP, относятся Facebook, ВКонтакте, Wikipedia и др.

Входит в LAMP — распространённый набор программного обеспечения для создания веб-сайтов (Linux, Apache, MySQL, PHP).

Создание GUI-приложений

Хотя PHP и не слишком распространён в данном качестве, его можно использовать и для создания GUI-приложений.

Для создания кроссплатформенных приложений служат пакеты PHP-GTK и PHP-Qt, представляющие собой обёртки для соответствующих популярных библиотек виджетов.

Для тех, кого интересует программирование с использованием Windows API существует две альтернативы. Во-первых это open source пакет WinBinder. Его ядро представляет собой написанное на C расширение php — php_winbinder.dll. В состав WinBinder включён также визуальный редактор форм, (см. скриншот) написанный с использованием самого WinBinder. Но, по сути, WinBinder является простой обёрткой к WinAPI и программирование с его использованием — достаточно низкоуровневое.

Второй альтернативой является интегрированная среда Devel Studio, ориентированная, прежде всего, на начинающих программистов.

Различные части DevelStudio распространяются под различными лицензиями. Интерфейс к графическим и системным возможностям Windows представляет собой ряд модулей расширения PHP, и является проприетарным ПО, распространяемым в виде скомпилированных DLL на условиях freeware. (Авторы планируют также выпуск платной Pro версии DevelStudio, в которой набор таких, базовых, библиотек будет шире).

Поверх этих расширений существует написанная на PHP открытая библиотека компонентов, которая, вместе с IDE, также написанном на PHP, распространяется на условиях GPL. Вместе они образует среду визуального программирования с Delphi-подобной архитектурой. Программист может расширять DevelStudio собственными, написанными на PHP компонентами, которые, возможно, будут использовать функционал написанных им, или кем то другим, дополнительных бинарных расширений PHP. DevelStudio включает средства упаковки и установки таких пакетов.

Для работы DevelStudio приложений необходим также soulEngine.exe — мини-сервер, запускающий веб-приложения (использует php5ts.dll версии 5.2). Он также написан на PHP, и лицензируется на условиях BSDL.

Для программирования под Windows можно также использовать Phalanger — реализацию PHP для платформы .NET. Результатом компиляции PHP кода в Phalanger может быть любое .NET-приложение, будь то серверное ASP.NET или десктопное Windows Forms /Windows Presentation Foundation(WPF)

Синтаксис

Синтаксис PHP подобен синтаксису языка Си. Некоторые элементы, такие как ассоциативные массивы и цикл foreach, заимствованы из Perl.

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

Простейшая программа Hello world на PHP выглядит следующим образом:

<?php

 echo 'Hello, world!'; 

?>

PHP исполняет код, находящийся внутри ограничителей, таких как <?php ?>. Всё, что находится вне ограничителей, выводится без изменений. В основном это используется для вставки PHP-кода в HTML-документ, например, так:

<html>

 <head>

 <title>Тестируем PHP</title>

 </head>

 <body>

 <?php echo 'Hello, world!'; ?>

 </body>

</html>

Помимо ограничителей <?php ?>, допускается использование дополнительных вариантов, таких как <? ?> и <script language="php"> </script>. Кроме того, до версии 6.0 допускается использование ограничителей языка программирования ASP <% %> (конструкции <? ?> и <% %> могут быть выключены в конфигурационном файле php.ini).

Имена переменных начинаются с символа $, тип переменной объявлять не нужно. Имена переменных, функций и классов чувствительны к регистру. Константы также чувствительны к регистру. Переменные обрабатываются в строках, заключённых в апострофы или двойные кавычки, и heredoc-строках (строках, созданных при помощи оператора <<<).

PHP рассматривает переход на новую строку как пробел, так же как HTML и другие языки со свободным форматом. Инструкции разделяются с помощью точки с запятой (;), за исключением некоторых случаев, после объявления конструкции if/else и циклов.

PHP поддерживает три типа комментариев: в стиле языка Си (ограниченные /* */), C++ (начинающиеся с // и идущие до конца строки) и оболочки UNIX# до конца строки).

Типы данных

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

К скалярным типам данных относятся:

  •  целый тип (integer),
  •  вещественный тип данных (float, double),
  •  логический тип (boolean),
  •  строковый тип (string),
  •  и специальный тип NULL.

К нескалярным типам относятся:

  •  «ресурс» (resource),
  •  массив (array),
  •  объект (object),
  •  анонимная функция (closure) или псевдотип callback.

Диапазон целых чисел (integer) в PHP зависит от платформы (обычно, это диапазон 32-битных знаковых целых чисел, то есть, от −2 147 483 648 до 2 147 483 647). Числа можно задавать в десятичной, восьмеричной и шестнадцатеричной системах счисления. Диапазон вещественных чисел (double), также, зависит от платформы (для 32-битной архитектуры диапазон позволяет оперировать числами от ±1.7×10−308 до ±1.7×10+308).

PHP предоставляет разработчикам логический тип (boolean), способный принимать только два значения TRUE («истина») и FALSE («ложь»). При преобразовании в логический тип число 0, пустую строку, ноль в строке «0», NULL и пустой массив считаются равными FALSE. Все остальные значения автоматически преобразуются в TRUE.

Специальный тип NULL предназначен для переменных без определённого значения. Единственным значением данного типа является константа NULL. Тип NULL принимают неинициализированные переменные, переменные инициализированные константой NULL, а также переменные, удалённые при помощи конструкции unset().

Ссылки на внешние ресурсы имеют тип «ресурс» (resource). Переменные данного типа, как правило, представляют собой дескриптор, позволяющий управлять внешними объектами, такими как файлы, динамические изображения, результирующие таблицы базы данных и т. п.

Массивы (array) поддерживают числовые и строковые ключи и являются гетерогенными. Массивы могут содержать значения любых типов, включая другие массивы. Порядок элементов и их ключей сохраняется. Не совсем корректно называть php-массивы массивами, на самом деле это, скорее всего, упорядоченный хеш. Возможно неожиданное поведение при использование цикла for со счетчиком вместо foreach. Так, например, сортируя массив с численными индексами функциями из стандартной библиотеки, сортируются и ключи тоже.

Указатель на функцию в PHP может быть представлен замыканием или типом callback. Замыкание доступно с версии 5.3 и в коде выглядит как простое определение функции, в которую явно можно утянуть значения из контекста, например:

 function($args..$argsN) use($ctxVar,$ctxVar1) { definition ; }

callback тип может быть представлен:

  •  строкой (интерпретируется как название функции);
  •  массивом где нулевой и первый элемент строки (интерпретируется как название статичной функции в классе);
  •  массивом где нулевой элемент объект, а первый строка (интерпретируется как метод у объекта).

Для проверки является ли значение вызываемым следует использовать is_callable($var)

Обращение к переменным и функциям

Обращение к переменным осуществляется с помощью символа $, за которым следует имя переменной. Данная конструкция может быть применена также для создания динамических переменных и функций.[12] Например:

$a = 'I am a';        // Запись значения в переменную $a

echo $a;              // Вывод переменной $а

 

$b = 'a';

echo $$b;             // Вывод переменной $а (дополнительный $ перед переменной $b)

 

echo ${'a'};      // Вывод переменной $a

 

function_name();      // Вызов функции function_name

$c = 'function_name';

$c();                 // Вызов функции function_name,

 

$d = 'Class_name';

$obj = new Class_name; // Создание объекта класса Class_name

$obj = new $d();      // Создание объекта класса Class_name

 

$obj->b;     // Обращение к полю b объекта

$obj->c();   // Вызов метода c() объекта

 

$obj->$b;    // Обращение к полю a объекта, так как $b = 'a'

$obj->$c();  // Вызов метода function_name() объекта, так как $c = 'function_name'

В PHP echo и print не являются функциями[13] (хотя print имеет возвращаемое значение), а являются синтаксическими единицами. При их использовании можно опустить скобки.

Объектно-ориентированное программирование

PHP поддерживает широкие объектно-ориентированные возможности, полная поддержка которых была введена в пятой версии языка.

Класс в PHP объявляется с помощью ключевого слова class. Методы и поля класса могут быть общедоступными (public, по умолчанию), защищёнными (protected) и скрытыми (private). PHP поддерживает все три основных механизма ООП — инкапсуляцию, полиморфизм и наследование (родительский класс указывается с помощью ключевого слова extends после имени класса). Поддерживаются интерфейсы (ставятся в соответствие с помощью implements). Разрешается объявление финальных, абстрактных методов и классов. Множественное наследование классов не поддерживается, однако класс может реализовывать несколько интерфейсов. Для обращения к методам родительского класса используется ключевое слово parent.

Классы в PHP имеют ряд специальных методов (англ. Magic methods), начинающихся с двух символов подчёркивания. Особо стоит отметить конструктор (__construct(), в версиях до 5.0 конструктором служил метод, одноимённый с классом) и деструктор (__destruct()), а также методы чтения (__get()) и записи (__set()), свёртывания (__sleep()) и развёртывания (__wake()), клонирования (__clone()) и др. Эти методы являются достаточно гибким инструментом: переопределяя их, можно добиться существенного изменения поведения объекта.

Экземпляры класса создаются с помощью ключевого слова new, обращение к полям и методам объекта производится с использованием оператора ->. Для доступа к членам класса из его методов используется переменная $this.

class C1 extends C2 implements I1, I2

{

 private $a;

 protected $b;

 

 function __construct($a, $b)

 {

   parent::__construct($a, $b);

   $this->a = $a;

   $this->b = $b;

 }

 

 public function plus()

 {

   return $this->a + $this->b;

 }

/* ...............  */

}

 

$d = new C1(1, 2);

echo $d->plus(); // 3

Начиная с пятой версии PHP, объекты передаются по ссылке:

class a

{

 public $color = 'red';

}

 

$a = new a();

echo $a -> color; // red

$b = $a;

$b -> color = 'blue';

echo $a -> color; // blue

«Paamayim Nekudotayim» или просто «двойное двоеточие». Используя эту лексему, программист может обращаться к константам, статическим или перегруженным свойствам или методам класса. При обращении к этим элементам извне класса, программист должен использовать имя этого класса. «Paamayim Nekudotayim» на первый взгляд может показаться странным словосочетанием для обозначения двойного двоеточия. Однако, во время создания Zend Engine версии 0.5 (который входил в PHP3), Andi и Zeev выбрали[14] именно это обозначение. «Paamayim Nekudotayim» действительно значит «двойное двоеточие» на иврите. Это обозначение не менялось ни разу в течение всего времени разработки PHP.[15]

<?php

class MyClass {

 const CONST_VALUE = 'Значение константы';

}

// Использование :: вне объявления класса

echo MyClass::CONST_VALUE;

?>

Интегрированные среды разработки для PHP

Название

Лицензия

Сайт

JetBrains PhpStorm

Trial

http://www.jetbrains.com/phpstorm/

PHP Development Tools

Eclipse Public License

http://www.eclipse.org/pdt/

Zend Studio

Shareware

http://www.zend.com/products/zend_studio/

Aptana Studio

GNU GPL

http://www.aptana.org

phpDesigner

Shareware

http://www.mpsoftware.eu/

PHP Expert Editor

Shareware[31]

http://www.phpexperteditor.com/

NetBeans IDE

CDDL

http://www.netbeans.org/

RadPHP XE

Trial

http://www.embarcadero.com/products/radphp/

NuSphere

Trial

http://www.nusphere.com/

KDevelop[32]

GNU GPL

http://www.kdevelop.org/

Критика

Несогласованный синтаксис функций и неортогональность

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

Другая причина отсутствия ортогональности в PHP заключается в особенностях появления этого языка на свет. В отличие от подавляющего большинства остальных языков программирования, PHP не был изначально задуман как полноценный язык программирования, а постепенно вырос из шаблонизатора для Perl. Это привело как к появлению в первоначальном варианте языка некоторых спорных решений (от которых планируется избавиться в 6-й версии), так и к отсутствию контроля со стороны создателя языка, который бы следил за стройностью его архитектуры.

Отсутствие обратной совместимости между версиями языка

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

В новых версиях линейки 5.3.x большое количество функций было признано устаревшими, их поддержка не планируется в новых версиях языка[34], что вызывает несовместимость со скриптами, которые используют устаревшие функции. Также для версии 5.3 на данный момент отсутствует программное обеспечение Zend Optimizer. Однако разработчики планировали выпустить его в 2010 году [35]

Надо отметить, что противоречие между обратной совместимостью и процессом развития — одна из ключевых проблем в разработке программного и аппаратного обеспечения. При работе над скриптовыми языками время от времени происходит резкая смена его архитектуры (а порой и парадигмы), обычно сопровождающаяся сменной первой цифры в номере версии. Так, в настоящее время идёт постепенный переход на новую ветвь языка Python — 3.x, в стадии тестирования находится Perl 6, являющийся, по сути, новым perl-подобным языком. При этом принято выпускать переходные версии, в которых постепенно вводятся новые конструкции, а использование устаревших вызывает вывод предупреждений. К таким переходным версиям относится и PHP 5.3.

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

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

Разработчики сообщают что проблема будет решена в PHP 6[11].

Отсутствие многопоточности

В языке не предусмотрена возможность создания многопоточных приложений. Есть различные обходные решения с использованием curl[36] и сокетов.[37][38][39] Для POSIX-совместимых систем можно использовать функции с префиксом pcntl_. Справедливости ради, следует отметить, что PHP распространён главным образом в области Web-разработки, где зачастую проблему многопоточности берет на себя веб-сервер.

24

MySQL (/mɑɪ ɛs kjuː ɛl/, «май-эс-кью-эль», жарг. мускул) [1] — свободная система управления базами данных (СУБД). MySQL является собственностью компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License или под собственной коммерческой лицензией. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

MySQL является решением для малых и средних приложений. Входит в состав серверов WAMP, LAMP и в портативные сборки серверов Денвер, XAMPP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

26 февраля 2008 года Sun Microsystems приобрела MySQL AB за 1 миллиард долларов.[2]

27 января 2010 года Oracle Corporation приобрела Sun Microsystems и включила MySQL в свою линейку СУБД.[3]

Сообществом разработчиков MySQL созданы различные ответвления кода, такие как Drizzle (англ.), OurDelta, Percona Server (англ.), и MariaDB (англ.). Все эти ответвления уже существовали на момент поглощения компаний Sun и MySQL AB корпорацией Oracle.

О происхождении MySQL

MySQL возникла как попытка применить mSQL к собственным разработкам компании: таблицам, для которых использовались ISAM — подпрограммы низкого уровня. В результате был выработан новый SQL-интерфейс, но API-интерфейс остался в наследство от mSQL. Откуда происходит название «MySQL» — доподлинно не известно. Разработчики дают два варианта: либо потому, что практически все наработки компании начинались с префикса My, либо в честь девочки по имени My, дочери Майкла Монти Видениуса, одного из разработчиков системы [4][5].

Логотип MySQL в виде дельфина носит имя «Sakila». Он был выбран из большого списка предложенных пользователями «имён дельфина». Имя «Sakila» было отправлено Open Source-разработчиком Ambrose Twebaze.

Лицензирование

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

Платформы

MySQL портирована на большое количество платформ: AIX, BSDi, FreeBSD, HP-UX, Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista и Windows 7. Существует также порт MySQL к OpenVMS. Важно отметить, что на официальном сайте СУБД для свободной загрузки предоставляются не только исходные коды, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули СУБД MySQL.

Языки программирования

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

Технические характеристики

Максимальные размеры таблиц

MySQL 3.22: до 4 Гб

MySQL 3.23+: До 8 миллионов терабайт. (2 ^ 63)

Размер таблицы ограничен её типом. В общем случае тип MyISAM ограничен предельным размером файла в файловой системе операционной системы. Например в NTFS этот размер теоретически может быть до 32 эксабайт. В случае InnoDB одна таблица может храниться в нескольких файлах, представляющих единое табличное пространство. Размер последнего может достигать 64 терабайт.

Локализация

Начиная с версии 4.1 в СУБД MySQL внедрена новая система кодировок и сортировок. При использовании кодировки Windows-1251, перед выполнением SQL-инструкций необходимо настроить кодировку соединения при помощи операторов:

 SET character_set_client='cp1251';

 SET character_set_results='cp1251';

 SET character_set_connection='cp1251';

Эти три оператора эквивалентны вызову одного оператора:

 SET NAMES 'cp1251'

Переменная character_set_client устанавливает кодировку данных отправляемых от клиента, переменная character_set_results устанавливает кодировку данных отправляемых клиенту, переменная character_set_connection устанавливает кодировку, в которую преобразуется информация пришедшая от клиента, перед выполнением запроса на сервере.

При использовании Юникода UTF-8 этот оператор выглядит следующим образом:

 SET NAMES 'utf8'

Кодировка ISO 8859-5 не поддерживается.

23 HTTP

HTTP (сокр. от англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука[1].

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

Преимущества

Простота

Протокол настолько прост в реализации, что позволяет с лёгкостью создавать клиентские приложения.

Расширяемость

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

Распространённость

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

Недостатки и проблемы

Большой размер сообщений

Использование текстового формата в протоколе порождает соответствующий недостаток: большой размер сообщений по сравнению с передачей двоичных данных. Из-за этого возрастает нагрузка на оборудование при формировании, обработке и передаче сообщений. Для решения данной проблемы в протокол встроены средства для обеспечения кэширования на стороне клиента, а также средства компрессии передаваемого контента. Нормативными документами по протоколу предусмотрено наличие прокси-серверов, которые позволяют получить клиенту документ с наиболее близкого к нему сервера. Также в протокол было внедрено diff-кодирование, чтобы клиенту передавался не весь документ, а только его изменённая часть.

Отсутствие «навигации»

Хотя протокол разрабатывался как средство работы с ресурсами сервера, у него отсутствуют в явном виде средства навигации среди этих ресурсов. Например, клиент не может явным образом запросить список доступных файлов, как в протоколе FTP. Предполагалось, что конечный пользователь уже знает URI необходимого ему документа, закачав который, он будет производить навигацию благодаря гиперссылкам. Это вполне нормально и удобно для человека, но затруднительно, когда стоят задачи автоматической обработки и анализа всех ресурсов сервера без участия человека. Решение этой проблемы лежит полностью на плечах разработчиков приложений, использующих данный протокол.

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

Полностью эта проблема решена в расширяющем HTTP протоколе WebDAV с помощью добавленного метода PROPFIND. Данный метод позволяет не только получить дерево каталогов, но и список параметров каждого ресурса.

Нет поддержки распределённости

Протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вообще не приниматься в расчёт. Но в промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается беспомощен. В 1998 году W3C предложил альтернативный протокол HTTP-NG (англ. HTTP Next Generation) для полной замены устаревшего с акцентированием внимания именно на этой области[2]. Идею его необходимости поддержали крупные специалисты по распределённым вычислениям, но данный протокол до сих пор находится на стадии разработки.

Программное обеспечение

Всё программное обеспечение для работы с протоколом HTTP разделяется на три большие категории:

  •  Серверы как основные поставщики услуг хранения и обработки информации (обработка запросов).
  •  Клиенты — конечные потребители услуг сервера (отправка запроса).
  •  Прокси для выполнения транспортных служб.

Для отличия конечных серверов от прокси в официальной документации используется термин origin server (рус. исходный сервер). Разумеется, один и тот же программный продукт может одновременно выполнять функции клиента, сервера или посредника в зависимости от поставленных задач. В спецификациях протокола HTTP подробно описывается поведение для каждой из этих ролей.

Клиенты

Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Популярные браузеры (в алфавитном порядке): Epiphany, Google Chrome, Internet Explorer, Konqueror, Mozilla Firefox, Opera, Safari.

Для просмотра сохраненного содержимого сайтов на компьютере без соединения с Интернетом были придуманы оффлайн-браузеры. Среди известных HTTrack и Offline Explorer.

При нестабильном соединении для загрузки больших файлов используются менеджеры закачек. Они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. В ОС Windows популярны программы Download Master, FlashGet, Free Download Manager, GetRight, ReGet. В Linux — графический менеджер закачек KGet и d4x (Downloader For X). Многие пользователи Linux предпочитают использование Wget — программы для загрузки файлов, которая сама по себе не является менеджером закачек.

Виртуальные атласы, такие как Google Планета Земля и NASA World Wind, тоже используют HTTP.

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

Целый комплекс программ-роботов используется в поисковых системах Интернета. Среди них веб-пауки (краулеры), которые производят проход по гиперссылкам, составляют базу данных ресурсов серверов и сохраняют их содержимое для дальнейшего анализа.

История развития

HTTP/0.9

HTTP /0,9 был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация протокола привела к упорядочению правил взаимодействия между клиентами и серверами HTTP, а также чёткому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.

В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0.

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

HTTP/1.2

Первоначально 1995 работая проектов документа PEP - механизм выдвижения для HTTP (предложил протокол выдвижения протокола, сокращенный PEP) подготовил Консорциум world wide web и представлено к Internet engineering task force. PEP первоначально был предназначен стать различая характеристикой HTTP/1.2.[4] В более поздно Проекты PEP работая, однако, справка к HTTP/1.2 извлеклась. Экспериментально RFC 2774, Рамки выдвижения HTTP, больше subsumed PEP. Оно было опубликовано в феврале 2000.

Структура протокола

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

  1.  Стартовая строка (англ. Starting line) — определяет тип сообщения;
  2.  Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
  3.  Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.

Стартовая строка

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

GET URI — для версии протокола 0.9.

Метод URI HTTP/Версия — для остальных версий.

Здесь:

  •  Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.
  •  URI определяет путь к запрашиваемому документу.
  •  Версия (англ. Version) — пара разделённых точкой арабских цифр. Например: 1.0.

Чтобы запросить страницу данной статьи, клиент должен передать строку:

GET /wiki/HTTP HTTP/1.0

Стартовая строка ответа сервера имеет следующий формат:

HTTP/Версия КодСостояния Пояснение

Здесь:

  •  Версия — пара разделённых точкой арабских цифр как в запросе.
  •  КодСостояния (англ. Status Code) — три арабские цифры. По коду статуса определяется дальнейшее содержимое сообщения и поведение клиента.
  •  Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:

HTTP/1.0 200 OK

Методы

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

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Кроме методов GET и HEAD, часто применяется метод POST.

OPTIONS

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

Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определён. Сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера.

Для того чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

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

GET

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

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[3] — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.

Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно.

HEAD

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.

POST

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

В отличие от метода GET, метод POST не считается идемпотентным[3], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).

При результатах выполнения 200 (Ok) и 204 (No Content) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

PUT

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

PATCH

Аналогично PUT, но применяется только к фрагменту ресурса.

DELETE

Удаляет указанный ресурс.

TRACE

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

LINK

Устанавливает связь указанного ресурса с другими.

UNLINK

Убирает связь указанного ресурса с другими.

CONNECT

Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенному SSL соединению через не шифрованный прокси.

Коды состояния

Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр[4]. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

201 Webpage Created

403 Access allowed only for registered users

507 Insufficient Storage

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

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

1xx Informational (русск. Информационный)

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

2xx Success (русск. Успешно)

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

3xx Redirection (русск. Перенаправление)

Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

4xx Client Error (русск. Ошибка клиента)

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Для запоминания значений кодов с 400 по 417 существуют приёмы иллюстративной мнемотехники[5]

5xx Server Error (русск. Ошибка сервера)

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

Заголовки

Заголовки HTTP (англ. HTTP Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

Примеры заголовков:

Server: Apache/2.2.11 (Win32) PHP/5.3.0

Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT

Content-Type: text/plain; charset=windows-1251

Content-Language: ru

В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до первого двоеточия, называется именем (англ. name), а что после неё — значением (англ. value).

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

  1.  General Headers (русск. Основные заголовки) — должны включаться в любое сообщение клиента и сервера.
  2.  Request Headers (русск. Заголовки запроса) — используются только в запросах клиента.
  3.  Response Headers (русск. Заголовки ответа) — только для ответов от сервера.
  4.  Entity Headers (русск. Заголовки сущности) — сопровождают каждую сущность сообщения.

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

Все необходимые для функционирования HTTP заголовки описаны в основных RFC, ссылки на которые есть в конце этой статьи. При этом если вам не будет хватать существующих, то можете смело вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией Microsoft для расширения WebDAV.

Тело сообщения

Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения (message-body) отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.

        message-body = entity-body

                     | <entity-body закодированно согласно

                        Transfer-Encoding>

Поле Transfer-Encoding ДОЛЖНО использоваться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding - это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.

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

Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) МОЖЕТ быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body) .

Включается или не включается тело сообщения (message-body) в сообщение ответа зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD НЕ ДОЛЖНЫ включать тело сообщения (message-body), даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) НЕ ДОЛЖНЫ содержать тела сообщения (message-body). Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.

Примеры диалогов HTTP

Обычный GET-запрос

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

GET /wiki/страница HTTP/1.1

Host: ru.wikipedia.org

User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

Accept: text/html

Connection: close

(пустая строка)

Ответ сервера:

HTTP/1.0 200 OK

Date: Wed, 11 Feb 2009 11:20:59 GMT

Server: Apache

X-Powered-By: PHP/5.2.4-2ubuntu5wm1

Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT

Content-Language: ru

Content-Type: text/html; charset=utf-8

Content-Length: 1234

Connection: close

(далее следует запрошенная страница в HTML)

Аналогично выглядит ответ 203. Что существенно, непосредственно запрашиваемые данные отделены от HTTP-заголовков с помощью CRLF CRLF (двух переводов строки).

Перенаправления

Предположим, что у вымышленной компании Example Corp. есть основной сайт по адресу http://example.com и домен-псевдоним example.org. Клиент посылает запрос страницы «О компании» на вторичный домен (часть заголовков опущена):

GET /about.html HTTP/1.1

Host: example.org

User-Agent: MyLonelyBrowser/5.0

Так как домен example.org не является основным и компания не собирается в будущем его использовать в других целях, их сервер вернёт код для постоянного перенаправления, указав в заголовке Location целевой URI:

HTTP/1.x 301 Moved Permanently

Location: http://example.com/about.html#contacts

Date: Thu, 19 Feb 2009 11:08:01 GMT

Server: Apache/2.2.4

Content-Type: text/html; charset=windows-1251

Content-Length: 110

(пустая строка)

<html><body><a href="http://example.com/about.html#contacts">Click here</a></body></html>

В заголовке Location можно указывать фрагменты как в данном примере. Браузер не указал фрагмент в запросе, так как его интересует весь документ. Но он автоматически прокрутит страницу до фрагмента «contacts», как только загрузит её. В тело ответа также был помещён коротенький HTML-документ с ссылкой, с помощью которой посетитель попадёт на целевую страницу, если браузер не перейдёт на неё автоматически. Заголовок Content-Type содержит характеристики именно этого HTML-пояснения, а не документа, который находится по целевому URL.

Допустим, эта же компания Example Corp. имеет несколько региональных представительств по всему миру. И для каждого представительства у них есть сайт с соответствующим ccTLD. Запрос главной страницы основного сайта example.com может выглядеть так:

GET / HTTP/1.1

Host: example.com

User-Agent: MyLonelyBrowser/5.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: ru,en-us;q=0.7,en;q=0.3

Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7

Сервер принял во внимание заголовок Accept-Language и сформировал ответ с временным перенаправлением на российский сервер test.ru, указав его адрес в заголовке Location:

HTTP/1.x 302 Found

Location: http://test.ru/

Cache-Control: private

Date: Thu, 19 Feb 2009 11:08:01 GMT

Server: Apache/2.2.6

Content-Type: text/html; charset=windows-1251

Content-Length: 82

(пустая строка)

<html><body><a href="http://test.ru">Example Corp. Россия</a></body></html>

Обратите внимание на заголовок Cache-Control. Значение «private» сообщает остальным серверам (в первую очередь прокси) что ответ может кэшироваться на стороне клиента. В противном случае не исключено, что следующие посетители из других стран будут переходить всё время не в своё представительство.

Для перенаправления также используются коды ответа 303 (See Other) и 307 (Temporary Redirect).

Докачка и фрагментарное скачивание

Допустим, вымышленная организация предлагает скачать с сайта видео прошедшей конференции по адресу http://example.org/conf-2009.avi объёмом примерно 160 МБ. Рассмотрим, как происходит докачивание этого файла в случае сбоя и как менеджер закачек организовал бы многопоточную загрузку нескольких фрагментов.

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

GET /conf-2009.avi HTTP/1.0

Host: example.org

Accept: */*

User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)

Referer: http://example.org/

Заголовок Referer указывает, что файл был запрошен с главной страницы сайта. Менеджеры закачек обычно тоже его указывают, чтобы эмулировать переход со страницы сайта. Без него сервер может ответить 403 (Access Forbidden), если не допускаются запросы с других сайтов. В нашем случае сервер вернул успешный ответ:

HTTP/1.1 200 OK

Date: Thu, 19 Feb 2009 12:27:04 GMT

Server: Apache/2.2.3

Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT

ETag: "56d-9989200-1132c580"

Content-Type: video/x-msvideo

Content-Length: 160993792

Accept-Ranges: bytes

Connection: close

(пустая строка)

(двоичное содержимое всего файла)

Заголовок Accept-Ranges информирует клиента о том, что он может запрашивать у сервера фрагменты, указывая их смещения от начала файла в байтах. Если этот заголовок отсутствует, то клиент может предупредить пользователя, что докачать файл, скорее всего, не удастся. Исходя из значения заголовка Content-Length, менеджер закачек поделит весь объём на равные фрагменты и запросит их по отдельности, организовав несколько потоков. Если сервер не укажет размер, то клиенту параллельное скачивание реализовать не удастся, но при этом он сможет докачивать файл, пока сервер не ответит 416 (Requested Range Not Satisfiable).

Допустим, на 84-ом мегабайте соединение с Интернетом прервалось и процесс загрузки приостановился. Когда соединение с Интернетом было восстановлено, менеджер закачек автоматически послал новый запрос на сервер, но с указанием выдать содержимое с 84-ого мегабайта:

GET /conf-2009.avi HTTP/1.0

Host: example.org

Accept: */*

User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)

Range: bytes=88080384-

Referer: http://example.org/

Сервер не обязан помнить, какие и от кого запросы были до этого, и поэтому клиент снова вставил заголовок Referer, как будто это его самый первый запрос. Указанное значение заголовка Range говорит серверу — «выдай содержимое от 88080384-ого байта до самого конца». В связи с этим сервер вернёт ответ:

HTTP/1.1 206 Partial Content

Date: Thu, 19 Feb 2009 12:27:08 GMT

Server: Apache/2.2.3

Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT

ETag: "56d-9989200-1132c580"

Accept-Ranges: bytes

Content-Range: bytes 88080384-160993791/160993792

Content-Length: 72913408

Connection: close

Content-Type: video/x-msvideo

(пустая строка)

(двоичное содержимое от 84-ого мегабайта)

Заголовок Accept-Ranges здесь уже не обязателен, так как клиент уже знает об этой возможности сервера. О том, что передаётся фрагмент, клиент узнаёт по коду 206 (Partial Content). В заголовке Content-Range содержится информация о данном фрагменте: номера начального и конечного байта, а после слэша — суммарный объём всего файла в байтах. Обратите внимание на заголовок Content-Length — в нём указывается размер тела сообщения, то есть передаваемого фрагмента. Если сервер вернёт несколько фрагментов, то Content-Length будет содержать их суммарный объём.

Теперь вернёмся к менеджеру закачек. Зная суммарный объём файла «conf-2009.avi», программа поделила его на 10 равных секций. Начальную менеджер загрузит при самом первом запросе, прервав соединение как только дойдёт до начала второго. Остальные он запросит отдельно. Например, 4-я секция будет запрошена со следующими заголовками (часть заголовков опущена — см. полный пример выше):

GET /conf-2009.avi HTTP/1.0

Range: bytes=64397516-80496894

Ответ сервера в этом случае будет следующим (часть заголовков опущена — см. полный пример выше):

HTTP/1.1 206 Partial Content

Accept-Ranges: bytes

Content-Range: bytes 64397516-80496894/160993792

Content-Length: 16099379

(пустая строка)

(двоичное содержимое 4-ой части)

Если подобный запрос отправить серверу, который не поддерживает фрагменты, то он вернёт стандартный ответ 200 (OK) как было показано в самом начале, но без заголовка Accept-Ranges.

См. также частичные GET, байтовые диапазоны, ответ 206, ответ 416.

Основные механизмы протокола

Частичные GET

HTTP позволяет запросить не сразу всё содержимое ресурса, а только указанный фрагмент. Такие запросы называются частичные GET, возможность их выполнения необязательна (но желательна) для серверов. Частичные GET в основном используются для докачки файлов и быстрого параллельного скачивания в нескольких потоках. Некоторые программы скачивают заголовок архива, выводят пользователю внутреннюю структуру, а потом уже запрашивают фрагменты с указанными элементами архива.

Для получения фрагмента клиент посылает серверу запрос с заголовком Range, указывая в нём необходимые байтовые диапазоны. Если сервер не понимает частичные запросы (игнорирует заголовок Range), то он вернёт всё содержимое со статусом 200, как и при обычном GET. В случае успешного выполнения сервер возвращает вместо кода 200 ответ со статусом 206 (Partial Content), включая в ответ заголовок Content-Range. Сами фрагменты могут быть переданы двумя способами:

  •  В ответе помещается заголовок Content-Range с указанием байтовых диапазонов. В соответствии с ними фрагменты последовательно помещаются в основное тело. При этом Content-Length должен соответствовать суммарному объёму всего тела.
  •  Сервер указывает медиа тип multipart/byteranges для основного содержимого и передаёт фрагменты указывая соответствующий Content-Range для каждого элемента (см. также Множественное содержимое).

См. также пример диалога докачки и фрагментарного скачивания.

Условные GET

Метод GET изменяется на "условный GET", если сообщение запроса включает в себя поле заголовка "If-Modified-Since". В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты, указанной в заголовке "If-Modified-Since". Алгоритм определения этого включает в себя следующие случаи:

  •  Если код статуса ответа на запрос будет отличаться от "200 OK", или дата, указанная в поле заголовка "If-Modified-Since" некорректна, ответ будет идентичен ответу на обычный запрос GET.
  •  Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET.
  •  Если ресурс не изменялся после указанной даты, сервер вернет код статуса "304 Not Modified".

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

Согласование содержимого

Согласование содержимого (англ. Content Negotiation) — механизм автоматического определения необходимого ресурса при наличии нескольких разнотипных версий документа. Субъектами согласования могут быть не только ресурсы сервера, но и возвращаемые страницы с сообщениями об ошибках (403, 404 и т. п.).

Различают два основных типа согласований:

  •  Управляемое сервером (англ. Server-Driven).
  •  Управляемое клиентом (англ. Agent-Driven).

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

В основной спецификации по протоколу (RFC 2616) также выделяется так называемое прозрачное согласование (англ. Transparent Negotiation) как предпочтительный вариант комбинирования обоих типов. Последний механизм не следует путать с независимой технологией Transparent Content Negotiation (TCN, русск. Прозрачное согласование содержимого, см. RFC 2295), которая не является частью протокола HTTP, но может использоваться с ним. У обоих существенное различие в принципе работы и самом значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN прозрачность означает доступность полного списка вариантов ресурса для всех участников процесса доставки данных.

Управляемое сервером

При наличии нескольких версий ресурса сервер может анализировать заголовки запроса клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном анализируются заголовки Accept, Accept-Charset, Accept-Encoding, Accept-Languages и User-Agent. Серверу желательно включать в ответ заголовок Vary с указанием параметров, по которым различается содержимое по запрашиваемому URI.

Географическое положение клиента можно определить по удалённому IP-адресу. Это возможно за счёт того что IP-адреса, как и доменные имена, регистрируются на конкретного человека или организацию. При регистрации указывается регион, в котором будет использоваться желаемое адресное пространство. Эти данные общедоступны, и в Интернете можно найти соответствующие свободно распространяемые базы данных и готовые программные модули для работы с ними (следует ориентироваться на ключевые слова «Geo IP»). Следует помнить что такой метод способен определить местоположение максимум с точностью до города (отсюда определяется и страна). При этом информация актуальна только на момент регистрации адресного пространства. То есть, например, если московский провайдер зарегистрирует диапазон адресов с указанием Москвы и начнёт предоставлять доступ клиентам из ближайшего Подмосковья, то его абоненты могут на некоторых сайтах наблюдать что они из Москвы, а не из, к примеру, Красногорска или Дзержинского.

Управляемое сервером согласование имеет несколько недостатков:

  •  Сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, но не может знать точно, что именно нужно в данный момент (например, версия на русском языке или английском).
  •  Заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами — мало. Из-за этого оборудование испытывает избыточную нагрузку.
  •  Общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на идентичные запросы от разных пользователей.
  •  Передача заголовков Accept также может раскрывать некоторые сведения о его предпочтениях, таких как используемые языки, браузер, кодировка.

Управляемое клиентом

В данном случае тип содержимого определяется только на стороне клиента. Для этого сервер возвращает с кодом состояния 300 (Multiple Choices) или 406 (Not Acceptable) список вариантов, среди которых пользователь выбирает подходящий. Управляемое клиентом согласование хорошо, когда содержимое различается по самым частым параметрам (например, по языку и кодировке) и используется публичный кэш. Основной недостаток — лишняя нагрузка, так как приходится делать дополнительный запрос, чтобы получить нужное содержимое.

Прозрачное согласование

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

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

Множественное содержимое

Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но в виде иерархии с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиатипы multipart/*. Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиа типом). Если получателю не известно как работать с типом, то он обрабатывает его так же, как multipart/mixed. Параметр boundary означает разделитель между различными типами передаваемых сообщений.Например передаваемый из формы параметр DestAddress передает значение e-mail адреса , а последущий за ним элемент AttachedFile1 отправляет двоичное содержимое изображения формата .jpg Со стороны сервера сообщения со множественным содержимым могут посылаться в ответ на частичные GET при запросе нескольких фрагментов ресурса. В этом случае используется медиа тип multipart/byteranges.

Со стороны клиента при отправке HTML-формы чаще всего пользуются методом POST. Типичный пример: страницы отправки электронных писем со вложенными файлами. При отправке такого письма браузер формирует сообщение типа multipart/form-data, интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес получателя, сам текст и вложенные файлы:

POST /send-message.html HTTP/1.1

Host: mail.example.com

Referer: http://mail.example.com/send-message.html

User-Agent: BrowserForDummies/4.67b

Content-Type: multipart/form-data; boundary="Asrf456BGe4h"

Content-Length: (суммарный объём включая дочерние заголовки)

Connection: keep-alive

Keep-Alive: 300

(пустая строка)

(отсутствующая преамбула)

--Asrf456BGe4h

Content-Disposition: form-data; name="DestAddress"

(пустая строка)

brutal-vasya@example.com

--Asrf456BGe4h

Content-Disposition: form-data; name="MessageTitle"

(пустая строка)

Я негодую

--Asrf456BGe4h

Content-Disposition: form-data; name="MessageText"

(пустая строка)

Привет, Василий! Твой ручной лев, которого ты оставил

у меня на прошлой неделе, разодрал весь мой диван.

Пожалуйста забери его скорее!

Во вложении две фотки с последствиями.

--Asrf456BGe4h

Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg"

Content-Type: image/jpeg

(пустая строка)

(двоичное содержимое первой фотографии)

--Asrf456BGe4h

Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg"

Content-Type: image/jpeg

(пустая строка)

(двоичное содержимое второй фотографии)

--Asrf456BGe4h--

(отсутствующий эпилог)

В примере в заголовках Content-Disposition параметр name соответствует атрибуту name в HTML-тегах <INPUT> и <TEXTAREA>. Параметр filename равен исходному имени файла на компьютере пользователя. Более подробная информация о формировании HTML-форм и вложении файлов в RFC 1867.

Особенности протокола

Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.

При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт в заголовке строчку «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов — в простейшем случае картинки в разных форматах).

Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.

Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это превратило Internet из «академической игрушки» в «коммерческий сервис»: появились компании, основным полем деятельности которых стало предоставление доступа в Internet (компании-провайдеры) и создание сайтов.


 

А также другие работы, которые могут Вас заинтересовать

82310. Развитие Казахской ССР в предвоенные годы 31.54 KB
  В 1922 году со всех руководящих постов были смещены бывшие члены партии Алаш.Голощекииа занявшего пост первого секретаря Казкрайкома партии в 1925 году.Ежова назначенного заведующим организационноинструкторским отделом Казкрайкома партии. Из посланцев партии в Казахстан были репрессированы Л.
82311. События в Новом Узени. Забастовки шахтеров Караганды 29.73 KB
  Забастовки шахтеров Караганды В июне 1989 г. Забастовки шахтеров Кузбасса в России и Донбасса в Украине в июле 1989 г. Назарбаев встретился с бастующими согласился с требованиями шахтеров и пообещал принять меры. 9 июня 1989 года началась забастовка шахтеров Карагандинского бассейна.
82312. Начало Великой Отечественной войны. Перестройка экономики и жизни республики на военный лад 29.16 KB
  Перестройка экономики и жизни республики на военный лад 22 июня 1941 года гитлеровская Германия вероломно без объявления войны напала на СССР. На первом этапе войны в КазССР были сформированы обучены и отправлены на фронт 14 стрелковых и кавалерийских дивизий 6 бригад. Высокими темпами в тылу шла подготовка командных кадров: 27 военных учебных заведений в основном переведенных из временно оккупированных врагом районов за годы войны подготовили 16 тыс.
82313. Распад СССР. Создание СНГ 29.12 KB
  Создание СНГ Весь 1990 год и особенно 1991 год в числе главных проблем стоящих перед СССР стояла проблема подписания нового Союзного договора.Горбачева был проведен общесоюзный референдум по вопросу о том быть или не быть СССР и каким ему быть. Большинство населения СССР проголосовало за сохранение СССР.
82314. Казахстан – надежный арсенал фронта в годы войны 34.75 KB
  В годы войны в увеличилась роль Казахстана в добыче медной руды производстве черной меди была организована добыча марганцевых и никелевых руд. Тем не менее в годы войны увеличились посевные площади и количество урожая было поставлено государству большое количество мяса и молока. С первых же дней войны экономика Казахстана была перестроена на военный лад.
82315. Конституция РК (структура содержание) 31.29 KB
  Действующая Конституция Республики Казахстан была принята 30 августа 1995 года на всенародном референдуме. Этот день является государственным праздником – Днём Конституции Республики Казахстан. Определены основные направления реформирования базовых отраслей законодательства: в области конституционного законодательства: разделение полномочий ветвей власти; в области гражданского права: развитие частного права восстановление в полном объеме права собственности защита участников торговоденежных отношений от вмешательства государства; в...
82316. Герои- казахстанцы ВОВ. 1941-1945 годов 30.83 KB
  Семенченко ставший первым казахстанцем – Героем Советского Союза Р.Бородино ворвался в штаб немецкой части и уничтожил пять немецких офицеров за что ему посмертно было присвоено звание Героя Советского Союза. В боях за Днепр самым юным Героем Советского Союза из казахов стал 18летний Жанибек Елеусов. Так многими орденами и медалями были отмечены боевые заслуги бесстрашной летчицы Рахимы Ералиной механика самолета трижды Героя Советского Союза И.
82317. Послание Президента народу Казахстану Казахстан 2030. Успехи и достижения Казахстана на современном этапе 29.38 KB
  Успехи и достижения Казахстана на современном этапе. Послание Президента страны народу Казахстана. Далее в своей работе Назарбаев отмечает 3 основные возможности внешнего характера для Казахстана: 1 географическое положение на перекрестке дорог в евроазиатском регионе; 2 поддержка со стороны иностранных государств и донорских организаций; 3 процесс глобализации и научнотехнического прогресса. Миссия Казахстана.
82318. Наука, культура и образование Казахстана в годы войны 1941-1945 годах 31.71 KB
  В годы войны в республике были созданы следующие научные учреждения: в 1942 г. Столь стремительное развитие Казахстанской науки прежде всего связано с тем что в период войны на территории нашей республики находились многие видные учёные того времени. В годы войны крайне тяжёлое положение сложилось у школ и учреждений высшего образования.