Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 22
Текст из файла (страница 22)
Выбор того, какой из них использовать, завр1сит отсвойств лежащего ниже сетевого уровня. Никогда ни один из них не должен перегружаться.Время от времени предлагаются дополнительные транспортные протоколы.Так, например, для поддержки передачи данных в реальном времени был определен транспортный протокол реального времени {Real-time Transport Protocol,RTP). RTP — это кадровый протокол, который определяет формат пакета для2.1.
Уровни протоколов89данных реального времени, ничего не говоря о механизмах гарантированной доставки этих данных. Кроме того, в нем определен протокол для мониторингаи управления передачей RTP-пакетов [406].TCP в архитектуре клиент-серверВзаимодействие клиент-сервер в распределенных системах часто осуществляетсяпутем использования транспортного протокола базовой сети. С ростом популярности Интернета нередко можно наблюдать построение приложений клиент-сервер и систем на базе TCP. Преимущества протокола TCP по сравнению с UDPсостоят в том, что он надежно работает в любой сети. Очеврщная оборотная сторона — протокол TCP создает значительную дополнительную нагрузку на сеть,особегпю в тех случаях, когда базовая сеть высоконадежна, например, в локальных сетях.Когда на карту поставлены производительность и надежность, альтернативойвсегда является протокол UDP в сочетании с дополнительными процедурамиконтроля ошибок и потоков, оптимизированными для конкретного приложения.Оборотная сторона этого подхода состоит в том, что приходится проделыватьмассу дополнительной работы, а также в том, что полученное решение будет частным, снижающим открытость системы.Протокол TCP во многих случаях непривлекателен из-за невозможности приспособить его для поддержки синхронного поведения запрос-ответ, используемогово многих взаимодействиях клиент-сервер.
На рис. 2.4, а показано применениепротокола TCP для поддержки взаимодействия клиент-сервер в нормальных условиях (когда сообщения не пропадают). Сначала клиент инициирует установление соединения, которое происходит по трехэтапному протоколу установления связи (первые три сообщения на рисунке). Этот протокол необходим длядостижения договоренности о порядке нумерации пакетов, пересылаемых черезсоединение (детали можно найти в [446]). Когда соединение установлено, клиент посылает свой запрос (сообщение 4), сопровождаемый пакетом, требующимот сервера разорвать соединение (сообщение 5).Сервер отвечает немедленным подтверждением приема запроса от клиента,которое скомпоновано с подтверждеиР1ем разрыва соединения (сообщение 6).Затем сервер выполняет требуемую работу и посылает клиенту ответ (сообщение 7), также сопровождаемый требованием разорвать соединение (сообщение 8).Клиент должен только послать подтверждение разрыва связи на сервер (сообщение 9).Ясно, что большая часть дополнительной нагрузки на сеть связана с управлением соединением.
При использовании TCP для управления взаимодействиемклиент-сервер гораздо дешевле будет скомбинировать установление соединенияс немедленной посылкой запроса, а посылку ответа — с разрывом соедиР1ения.Получившийся протокол носит название TCP для транзакций {TCP for Transactions), сокращаемое до Т/ТСР. То, как функционирует этот протокол в нормальных условиях, можно увидеть на рис. 2.4, б.В нормальной обстановке происходит следующее: клиент посылает одно сообщение (сообщение 1), содержащее три порции информации: запрос на уста-90Глава 2. Связьновленрге соединения, собственно запрос к серверу и запрос, сообщающий серверу, что после этого он может немедленно разорвать соединение.СерверКлиент1СерверSYNSYN.aanpoc.FINSYN.ACK(FIN).OTBeT,FlN.SYN,ACK(SYN)••ACK(SYN)^запросACK(FIN)"FINВремяiВремя1Рис.
2 . 4 . Нормальное функционирование протокола TCP (а).Функционирование протокола TCP для транзакций (б)Сервер отвечает только после того, как обработает запрос. Он может послатьданные, для передачи которых и создавалось соединение, и немедленно потребовать его разрыва, что иллюстрирует сообще1П1е 2. После этого клиенту остаетсятолько подтвердить разрыв соединения (сообщение 3).Протокол Т/ТСР, созданный как расширение TCP, автоматически преобразуется в нормальный протокол TCP, если другая сторона не поддерживает эторасширение. Дополнительную информацию по TCP/IP можно найти в [437].2 .
1 . 3 . Протоколы верхнего уровняПоверх транспортного уровня OSI указывает на наличие трех дополнительныхуровней. На практике используется только прикладной уровень. На самом деле вкомплекте протоколов Интернета все, что находится выше транспортного уровня, собирается в одну «кучу». В этом пункте мы увидим, почему с точки зрениясистем промежуточного уровня нас не устраивает ни подход OSI, ни подход Интернета.Сеансовые протоколы и протоколы представленияСеансовый уровень представляет собой фактически расширенную версию транспортного уровня. Он обеспечивает управление диалогом, отслеживая и запоминая, какая сторона говорит в настоящий момент, и предоставляет средства сип-2.1. Уровни протоколов91хронизации.
Последние требуются для создания пользователями контрольныхточек при длинных сеансах передачи данных, а также уведомления их о сбое в ходе такого сеанса. При этом необходимо сделать откат только до последней контрольной точки и не нужно проходить весь путь сначала. На практике сеансовыйуровень нужен немногим приложениям и поддерживается редко. Он даже не входит в комплект протоколов Интернета.В отличие от предыдущих уровней, на которых мы заботились о точной и эффективной пересылке битов от отправителя к получателю, уровень представлениязанимается смыслом этих битов.
Большинство сообщений содержат не случайные последовательности битов, а структурированную информацию типа фамилий, адресов, денежных сумм и т. п. На уровне представления можно определитьзаписи, содержащие подобного рода поля, и потребовать у отправителя уведомлять получателя, что сообщение содержит отдельные записи соответствующегоформата. Это упрощает взаимодействие между машинами с различным внутренним представлением данных.Прикладные протоколыПрикладной уровень модели OSI изначально должен был содержать набор стандартных сетевых приложений, например для работы с электронной почтой, передачи файлов и эмуляции терминала. В настоящее время он стал местом собраниявсех приложений и протоколов, которые не удалось пристроить ни на один из более низких уровней.
В свете эталонной модели OSI все распределенные системыявляются просто приложениями.Чего в этой модели нет — так это четкого разграничения приложений, специальных протоколов приложений и протоколов общего назначения. Так, например, популярный в Интернете протокол передачи файлов {File Transfer Protocol,FTP) [203, 361] определяет передачу файлов между клиентской машиной и сервером. Этот протокол не следует путать с программой ftp, которая представляетсобой законченное приложение для передачи файлов и совпадает (но не полностью) с реализацией протокола FTP для Интернета.Другим примером сугубо специального прикладного протокола [142] можетслужить протокол передачи гипертекста (Hypertext Transfer Protocol, HTTP), разработанный для удаленного управления и загрузки web-страниц. Протокол реализован в таких приложениях, как web-браузеры и web-серверы.
Однако сейчасэтот протокол используется и в системах, связь которых с Web не предполагается. Так, например, в RMI в языке Java протокол HTTP используется для обращения к удаленному объекту, защищенному брандмауэром [441].Кроме того, существует множество протоколов общего назначения, используемых в различных приложениях. Они попали в прикладные протоколы, потому что их нельзя было отнести к транспортным. Во многих случаях они могутсчитаться протоколами промежуточного уровня, которые мы сейчас рассмотрим.Протоколы промежуточного уровняк промежуточному уровню относятся приложения, логически помещаемые наприкладной уровень, но содержащие множество протоколов общего назначения.92Глава 2.
Связьчто дает им право на их собственный уровень, независимый от других, более специализированных приложений. Можно отделить высокоуровневые протоколывзаимодействия от протоколов для предоставления различных служб промежуточного уровня.Существует множество протоколов, которые поддерживают разнообразныеслужбы промежуточного уровня. Так, например, в главе 8 мы обсуждаем разнообразные методы аутентификации, то есть методы удостоверения личности.Протоколы аутентификации не привязаны к какому-либо конкретному приложению. Вместо этого они встраиваются в системы промежуточного уровня направах общедоступной службы.
Протоколы авторизации, согласно которым подтвердившие свой статус пользователи и процессы получают доступ только к темресурсам, на которые они имеют право, также имеют тенденцию к переходу нанезависимый от приложений уровень.В качестве другого примера рассмотрим множество протоколов распределенного подтверждения (commit) из главы 7.
Протоколы подтверждения делаюттак, чтобы в группе процессов либо все процессы прошли через определеннуюоперацр1ю, либо операция не была применена ни к одному из них. Это явление,известное также как атомарность, широко используется при транзакциях. Какмы увидим, не только транзакции, но и другие приложения, особенно рассчитанные на устойчивость к сбоям, также могут нуждаться в протоколах распределенного подтверждения.В качестве последнего примера рассмотрим протоколы распределенной блокировки, при помощи которых может быть предотвращен одновременный доступ к ресурсам нескольких процессов, распределенных по множеству машин.Мы рассмотрим некоторые из этих протоколов в главе 5. Это еще один примерпротоколов, которые могут быть реализованы в виде общедоступной службыпромежуточного уровня, который в то же время не зависит от какого-либо конкретного приложения.Коммуникационные протоколы промежуточного уровня поддерживают высокоуровневые коммуникационные службы.