Протоколы и модели взаимодействия для реализации Web-служб

  Глобальная сеть может охватывать город, множество городов, страны и целые континенты [8]. Базовая технология, применяемая в сетях WAN - это коммутация пакетов (packet switching). В соответствие с этой технологией, сообщения, передаваемые между двумя компьютерами (которые называются хостами (hosts)), разбиваются на модули, называемые пакетами (packets). Пакеты ограничены по размеру, имеют заголовок с полями, содержащими необходимую адресную информацию для направления пакета из источника до пункта назначения, а также сопутствующую информацию, которая требуется для сборки сообщения из составляющих его пакетов в пункте назначения. Составными частями глобальной сети являются коммутаторы пакетов (packet switches) или маршрутизаторы (routers), а также соединяющие их высокоскорос¬тные линии связи (от 45 Мбит/с до нескольких Гбит/сек). Маршрутизаторы - это коммуникационные компьютеры, которые хранят входящие пакеты, анализируют их заголовки, используют таблицы маршрутизации для принятия решения, на какой маршрутизатор послать пакет дальше по его пути к пункту назначения, и помещают пакет в исходящую очередь на выбранную выходную линию. Такой метод называется store and forward (сохранить и передать дальше). К технологиям, используемым для построения глобальных сетей, относятся: протокол X. 25, стандарт ITU (International Telecommunications Union — Международный союз по телекоммуникациям); ISDN (Integrated Services Digital Network - цифровая сеть связи с комплексными услугами) — служба, поддерживаемая многими телефонными компаниями для интеграции голоса и данных в обычных телефонных линиях; ретрансля¬ция кадров (Frame Relay), высокоскоростная служба для глобальных сетей, предлагаемая поставщиками услуг междугородней связи; SMDS (Switched Multimegabit Data Service - высокоскоростная сетевая технология, предлагаемая телефонными компаниями США); ATM (Asynchronous Transfer Mode - асинхрон¬ный режим передачи) - технология коммутации пакетов, использующая небольшие пакеты фиксированного размера (53 байта), называемые ячейками (cells), для обеспечения быстрой передачи голоса, видеоинформации и данных через глобальную сеть [8].

1.5 LAN

Локальная сеть обычно располагается в одном или нескольких близко расположенных зданиях, например учебный корпус или студенческий городок. Существует множество технологий построения локальных сетей, как проводных, так и беспроводных. К наиболее популярным проводным технологиям относятся Ethernet 10 Мбит/сек [13], Ethernet 100 Мбит/сек [14], Token Ring 4 или 16 Мбит/сек [15] и FDDI 100 Мбит/сек [36].

Технология Ethernet была изобретена Меткалфом в начале семидесятых годов прошлого века и стала, пожалуй, наибольшим достижением в развитии локальных сетей [23]. Локальные сети Ethernet имеют шинную топологию (см. рис. 1а). Все компьютеры соединяются с общим коаксиальным кабелем через сетевые адаптеры (network interface card, NIC). Пакеты, передаваемые одним адаптером, могут быть получены остальными адаптерами. Такой принцип называется широковещательной связью. Поскольку пакеты содержат адрес места назначения, то только адаптер места назначения будет копировать пакет в память своего компьютера. Ввиду от­сутствия центрального координатора, решающего, какой компьютер может исполь­зовать разделяемую шину, применяется множественный доступ, называемый CSMA/CD (Carrier Sense Multiple Access with Collision Detection — множественный доступ с контролем несущей и обнаружением конфликтов). Если адаптер желает передать пакет, он "прослушивает" линию на предмет того, не ведется ли по ней передача; это называется контролем несущей (carrier sensing). Если передача ве­дется, адаптер ожидает, а затем снова "прослушивает" линию.

Рисунок 1. (а) Локальная сеть на базе общей шины, (б) Локальная сеть на базе кольца, (в) Локальная сеть на базе двойного кольца.

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

С ростом трафика в сети Ethernet растет вероятность конфликтов, а пропускная способность сети уменьшается, т.к. часть полосы пропускания тратится на разрешение конфликтов и повторные передачи.

Технология Token Ring (маркерное, или эстафетное, кольцо) была изобретена в исследовательских лабораториях компании IBM, и, как показывает само назва­ние, основана на кольцевой топологии (см. рис. 1б). Отправитель помещает фрагменты своего пакета в кольцо. Пакет ходит по кольцу и копируется адаптером, который указан в поле адреса назначения пакета. Пакет продолжает циркулировать по кольцу до своего отправителя, который извлекает этот пакет и сравнивает с отправленным пакетом (для контроля ошибок). Если два или более адаптера намереваются одновременно начать передачу, может возникнуть наложение. Поэтому в локальной сети Token Ring доступ к кольцу управляется марке­ром (token), т.е. специальной последовательностью битов, циркулирующей по кольцу. Маркер последовательно передается от станции к станции; при этом стан­ция, которая желает получить доступ к среде передачи, должна ждать получения маркера и только затем может начать передачу данных. По завершении передачи передававший адаптер отправляет маркер дальше по кольцу. Если адаптеру ничего не нужно передавать, он просто передает маркер следующей станции.

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

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

Существуют два типа ограничений на количество станций, которые можно подсоединить к локальной сети: физические и связанные с производительностью сети. Например, стандарт Ethernet ограничивает длину Ethernet-кабеля до 500 м и требует соблюдения минимального расстояния между станциями, которое составляет 3 м [8]. По соображениям производительности количество станций в локальной сети также ограничивается. Для снижения трафика в локальной сети и улучшения производительности сетевые администраторы разделяют крупные локальные сети на сегменты с некоторым количеством станций в каждом. Сегменты соединяются с помощью специальных устройств, таких как маршрутизаторы и мосты [32]. Станции, которые взаимодействуют друг к другу более часто, должны находиться в одном сегменте, чтобы снизить нагрузку на маршрутизаторы и мосты. В [5] можно найти аналитические выражения для оценки производительности локальных сетей.

Беспроводные локальные сети в качестве среды используют радиочастоту, на которой они обращаются друг к другу. В таких сетях последовательность нулей и единиц, генерируемая станциями, используется для модуляции несущей, которая передается радиопередатчиками. Рассмотрим краткое описание протокола IEEE 802.11, т.е. IEEE-стандарта для беспроводных локальных сетей [16]. В зави­симости от метода модуляции, используемого на физическом уровне протокола IEEE 802.11, данные могут передаваться со скоростью 1 или 2 Мбит/с. О физи­ческом уровне можно отметить следующее: 1) он вырабатывает сигнал несущей, который показывает, ведется ли передача; 2) данные, отправленные одной станци­ей, могут быть приняты всеми станциями в покрываемой области; 3) на качество связи может повлиять "проблема скрытого терминала". Эта проблема возникает в том случае, когда стены или другие структуры препятствуют прохождению радио­сигнала. В таком случае возможна ситуация, когда станция С получает сигналы от станций А и В, но станции А и В не слышат передачи друг друга, поскольку между А и В находится какое-то препятствие.

На рис. 2 показана архитектура сети, использующей протокол IEEE 802.11. Станции связываются внутри своих ячеек или базовых наборов служб (basic service set, BSS) друг с другом и с базовой станцией, называемой местом доступа (access point, АР). Базовая станция позволяет станциям из различных BSS связываться друг с другом.  Станции также могут объединяться в специальные (ad hoc) сети, т.е. в сети, не имеющие мест доступа (см. рис. 3). В свою очередь, места доступа могут соединяться между собой с помощью проводной (рис. 2) или беспроводной локальной сети.

Как и в сети Ethernet, передачи беспроводных станций могут накладываться друг на друга, если они возникают в одно и то же время. В рамках ШЕЕ 802.11 используется протокол CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance - множественный доступ с контролем несущей и исключением конфликтов), который работает следующим образом. Если прослушиваемый канал не занят в течение временного промежутка, равного разделительному межкадровому интервалу (Distributed Inter Frame Space, DIFS), то станция может начинать передачу.

Рисунок 2. Архитектура на базе протокола IEEE 802.11 для беспроводной локальной сети

с местами доступа.

Рисунок 3. Архитектура на базе протокола IEEE 802.11 для специальной беспроводной локальной

сети (без мест доступа).

Получатель корректного кадра посылает отправителю кадр подтверждения через небольшой промежуток времени, называемый коротким межкадровым интервалом (Short Inter Frame Space, SIFS). Протокол IEEE 802.11 требует отправлять подтверждения (АСК) в любых сетях, кроме Ethernet, поскольку в последнем случае отправитель может сам слышать свою передачу.

Если же прослушиваемый канал занят, то отправитель откладывает свою передачу до того момента, когда канал будет свободен в течение времени, равного DIFS. Затем, во избежание наложения передачи с другими станциями, которые отложили свои передачи, выдерживается случайный интервал времени (backoff time). По его истечению станция посылает свой кадр. В отличие от Ethernet, протокол IEEE 802.11 не применяет обнаружение конфликтов, а направлен на их предотвращение. Каждый передаваемый кадр содержит в себе длительность передачи, дабы другие станции не начали свою передачу в это время. Тем не менее, конфликты могут возникать из-за проблемы скрытого терминала. Две станции, скрытые друг от друга, могут вступить в конфликт при передаче одному и тому же адресату приблизительно в один и тот же момент времени. Для решения этой проблемы в протоколе IEEE 802.11 предусмотрен необязательный обмен двумя видами кадров: запрос на передачу (Request To Send, RTS) и готовность к приему (Clear To Send, CTS), который выполняется перед началом передачи собственно данных. Перед тем, как начать передачу кадра данных, отправитель передает получателю короткий кадр RTS, указывающий общую продолжительность передачи, включая время на пересылку подтверждения. Если кадр RTS получен корректно, то в ответ получатель отправляет короткий кадр CTS, означающий, что отправитель может начинать передачу данных. Все остальные станции слышат этот обмен и, во избежание конфликтов, свои передачи не начинают.

1.6. Соединение локальных и глобальных сетей

Локальные сети обычно подключаются к глобальным сетям через выделенные линии со скоростями Т1 (1.544 Мбит/с) или ТЗ (45 Мбит/с). Выбор адекватных параметров линии связи между локальной и глобальной сетями будет обсуждаться в главах 9 и 10, причем с точки зрения моделей производительности системы. На рис. 4 показана топология сети для компании со штабквартирой в Лос-Андже­лесе и филиалами в Чикаго и Нью-Йорке. Эти три местоположения соединены между собой через глобальную сеть с ретрансляцией кадров. В штабквартире находятся локальные сети Ethernet и Token Ring, соединенные с кольцевой волоконно-оптической магистралью FDDI (100 Мбит/с). Магистраль штаб-квартиры подсоединена к глобальной сети Frame Relay через линию Т1. Филиал в Чикаго имеет локальную сеть, состоящую из двух сегментов, соединенных при помощи моста. В одном из этих сегментов находится маршрутизатор, соединяющий ло­кальную сеть с глобальной. Наконец, Нью-Йоркский филиал имеет одну локаль­ную сеть Token Ring 16 Мбит/с, которая через маршрутизатор соединяется с глобальной сетью.

Рисунок 4 .Пример соединения локальных и глобальных сетей.

1.7. Соединение домашнего компьютера с глобальной сетью

В настоящее время существует множество способов подключить домашний компьютер, и даже домашнюю локальную сеть, к глобальной сети. Самый простой и дешевый способ предполагает использование аналогового модема для коммутируемой линии передачи со скоростью от 14.4 до 56 Кбит/с. Более быстрое соединение обеспечивает интерфейс базового уровня ISDN BRI (Basic Rate Interface), требующий использования цифрового модема для коммутируемой линии передачи и обеспечивающий скорость 128 Кбит/с. Если требуется еще большая скорость службы ISDN, тогда следует воспользоваться интерфейсом основного уровня ISDN PRI (Primary Rate Interface), который показывает скорость 1.544 Мбит/с. Та же скорость может быть получена за счет аренды выделенной линии Т1. Скорости порядка линии Т1 можно также получить с помощью высокоскоростной цифровой абонентской линии HDSL (High-bit-rate Digital Subscriber Line), которая обеспечивает большую гибкость. ADSL (Asymmetric Digital Subscriber Line), асимметричная версия HDSL, обеспечивает исходящую скорость 640 Кбит/с и входящую скорость 6 Мбит/с. Подобного рода асимметрия обеспечивает хороший доступ в Web, по­скольку требования по пропускной способности для быстрой загрузки картинок и видеоклипов гораздо выше, чем в отношении отправки запросов на Web-сервер.

Наконец, компании, предоставляющие услуги кабельного телевидения, предлагают кабельные модемы, обеспечивающие высокоскоростной доступ в Internet. Кабель - это среда с разделяемой пропускной способностью, поэтому реальная пропускная способность, "видимая" пользователем, зависит от нагрузки на сеть. Большинство кабельных модемов - асимметричные. Типовые скорости составляют от 1 до 10 Мбит/с по направлению основного трафика (downstream) и 128 Кбит/с в направлении, противоположном основному трафику (upstream). Как показали многочисленные измерения [39], доступ к цифровой абонентской линии (DSL) идет через выделенную местную линию связи, следовательно, при этом время загрузки варьируется в меньших пределах по сравнению с доступом по кабельному модему.

2. Протоколы

Обмен данными между двумя компьютерами или двумя процессами в компьютерной сети управляется набором правил, называемых протоколом (protocol). Пусть А и В - два объекта, которые обмениваются серией сообщений по сети. Объекту А нужно корректно указать адрес объекта В, чтобы сообщения из А прибыли по назначению. Это достигается за счет функций адресации (addressing) и маршру­тизации (routing), реализуемых протоколом. Сообщения, отправленные из А в В, могут потеряться или исказиться из-за шума или отказов в сети. Следовательно, протокол должен выполнять функции обнаружения ошибок (error detection), ис­правления ошибок (error recovery) и управления очередностью (sequence control). Если объект А посылает сообщение с намного большей скоростью, чем способен принять объект В, то в этом случае протокол должен обеспечить механизм управ­ления потоком (flow control). Механизм управления потоками регулирует относи­тельные скорости отправителя и получателя во избежание переполнения буфера и появления сообщений, которые не смогли дойти до своего адресата. Итак, основными функциями протокола являются адресация, маршрутизация, обнаружение и исправление ошибок, управление очередностью и управление потоком.

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

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

Проектирование компьютерного коммуникационного протокола представляет собой достаточно сложную задачу. В этой связи разработчики протоколов используют многоуровневую (layered) архитектуру, представляющую протокол. Международная организация по стандартизации (International Standards Organization, ISO) определила семиуровневую модель, называемую Эталонной моделью взаимодействия открытых систем (Reference Model for Open System Interconnection) . Эта модель предполагает наличие уровней с 1 по 7: физический, канала передачи данных, сетевой, транспортный, сеансовый, представления, прикладной. Каждый объект, находящийся на уровне и, взаимодействует только с удаленными объектами n-го уровня. Объекты n-го уровня используют службы, обеспечиваемые объектами (я-1)-го уровня (см. рис. 5).

Рисунок 5. Многоуровневый подход к проектированию протокола

Как показано на рис. 6, единицы данных, которыми обмениваются n-ные уровни двух объектов, должны быть физически обработаны уровнями от и до 1 компьютера-отправителя, переданы по сети и перемещены с уровня 1 на уровень п на компьютере-получателе. Объекты на уровне п обмениваются между собой протокольными единицами обмена (Protocol Data Unit, PDU). Протокольная единица обмена содержит заголовок n-го уровня и данные n-го уровня. Как видно из рис.6, PDU «-го уровня становится данными для (и-1)-го уровня.

В дальнейших разделах представлено краткое описание двух наиболее важных протоколов Internet: IP и TCP. Этот набор протоколов, известный как TCP/IP, принадлежит к ядру Internet. На рис. 7 показана многоуровневая структура стека протоколов на основе TCP/IP. Здесь легко заметить, что IP представляет собой протокол сетевого уровня, поверх которого находятся два протокола транспортного уровня: протокол на основе соединений TCP и протокол без установки со­единений UDP.

Протокол TCP используют такие протоколы, как HTTP (Web-протокол), протокол передачи файлов FTP (File Transfer Protocol), простой протокол передачи электронной почты SMTP (Simple Mail Transfer Protocol) и Telnet (протокол интерактивного входа в систему). Протокол UDP используют следующие протоколы: сетевая файловая система NFS (Network File System) [8], сервер доменных имен DNS (Domain Name Server), простой протокол сетевого управления SNMP (Simple Network Management Protocol). Следует отметить, что NFS, в свою очередь, использует протокол удаленного вызова процедур RPC (Remote Procedure Call).

Рисунок 6. Инкапсуляция протокольных единиц обмена.

Рисунок 2.7 Многоуровневая архитектура стека протоколов на основе TCP/IP

2.1. Протокол Internet (IP)

Протокол IP определяет форматы пакетов, посылаемых через Internet, механизмы, используемые для передачи пакетов через различные виды сетей, а также маршрутизаторы от источника до места назначения .

Каждый хост, подключенный к Internet, имеет уникальный адрес, называемый IP-адресом. IP-адрес ни что иное как 32-битовое число, обычно представляемое при помощи точечной десятичной нотации, например, 129.2.0.37. Здесь каждое из четырех чисел (каждое из которых может принимать значения от 0 до 255) представляет 8 бит 32-битового адреса. Все 32 бита разделены на две части: префикс и суффикс. Префикс указывает на сеть, а суффикс - на хост внутри сети. Количество бит, отведенных на префикс, определяет количество уникальных сетевых номеров, а количество бит суффикса - количество хостов в сети.

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

Заголовок в протоколе IP имеет длину 20 байт. Из них 4 байта отводится на IP-адрес хоста-отправителя, а 4 байта - на IP-адрес хоста-получателя. Важной функцией IP является маршрутизация (routing) дейтаграмм из источника в пункт назначения. Каждый хост и каждый маршрутизатор в Internet реализует протокол IP. Маршрутизатор поддерживает таблицу маршрутизации "в памяти", которая используется для нахождения следующего маршрутизатора или хоста (если это конечный пункт) с целью передачи дейтаграммы (рис. 8).

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

Рисунок 8 . Протокол IP для хостов и маршрутизаторов.

2.2. Протокол TCP

Протокол TCP обеспечивает основанный на соединении обмен данными между процессами, выполняющимися на хостах сети, для которого характерно высокая надежность, управление потоком и сквозная передача. Протокол TCP гарантирует, что данные будут получены в том же порядке, в котором они были отправлены, и что никакие данные не потеряются. TCP позволяет двум объектам, находящимся на концах соединения, обмениваться информацией одновременно, т.е. в полнодуплексном режиме (см. рис.8). TCP обеспечивает потоковый интерфейс, т.е. принимает от приложения непрерывный поток байтов, который должен отправляться через соединение. Протокольная единица обмена, которой обменивают­ся на уровне протокола TCP, называется сегментом (segment). Заголовок сегмента в TCP имеет длину 20 байт. Протокол TCP посылает сегменты в рамках 1Р-дейтаграмм.

Перед тем, как два хоста начнут обмениваться данными, между ними должно быть установлено соединение. Протокол TCP использует надежный механизм установки соединения, называемый трехсторонним квитированием связи (three-way handshake) . На рис.9 показан обмен сегментами, происходящий при установке соединения, передаче данных и прекращении передачи. Вертикальные пря­мые - это временные оси для хостов А и В. Время возрастает сверху вниз. Диа­гональные линии со стрелками указывают на сегменты, пересылаемые между хостами А и В.

Предположим, что хост А установил соединение с хостом В, обменялся с ним данными, а затем закрыл соединение. Хост А начинает с отправки на хост В сег­мента синхронизации SYN (SYNchronization), который в ответ посылает свой сегмент синхронизации. Такой обмен SYN-сегментами занимает время 1 RTT (round-trip time - время на передачу и подтверждение приема). Хост В считает соединение незавершенным до тех пор, пока от хоста А не придет сегмент подтверждения АСК (ACKnowledgement). В течение интервала времени от посылки хостом В хосту А своего сегмента синхронизации и до получения от А сегмента подтверждения, соединение остается в очереди незавершенных (т.е. неустановлен­ных) соединений. Другими словами, соединение остается в этой очереди в течение 1 RTT. Если хост получил множество запросов на открытие соединений от серверов, расположенных на достаточном удалении, то очередь незавершенных соеди­нений может переполниться, не давая хосту принимать новые соединения. С упомянутой проблемой сталкиваются HTTP-сервера, устанавливающие множество соединений с удаленными клиентами. Данный факт учитывается при совершении так называемых атак типа отказа от обслуживания (Denial of Service, DoS). После того, как хост В получил АСК-сегмент, процесс трехстороннего квитирования (т.е. подтверждения установки соединения) считается завершенным, а соединение - установленным. Теперь можно передавать сегменты данных с обоих направлениях.

Рисунок 9.  Установка и закрытие соединения в протоколе TCP

Закрытие TCP-соединения называется полузакрытием (half-close), поскольку когда хост закрывает соединение, он этим указывает, что больше не будет посылать данные другому хосту, но все еще может принимать данные. Например, на рис. 9 хост А закрывает соединение с хостом В (отправив В сегмент FIN, в от­вет на который В присылает сегмент АСК). Когда хост В желает завершить соединение с А, он отправляет хосту А сегмент FIN, в ответ на который А присыла­ет сегмент АСК. Итак, для установки TCP-соединения потребуется отправить три сегмента, а для закрытия соединения в обоих направлениях - четыре сегмента.

Для контроля ошибок протокол TCP использует АСК-сегменты, таймауты и повторные передачи. Управление потоком в TCP осуществляется с помощью механизма бегущего окна (sliding window). Размер такого окна определяется максимальным количеством байт, которые можно послать до получения подтверждения. Размер окна ограничивается размером буфера получателя и перегруженностью каналов связи с точки зрения отправителя. Когда соединение установлено, получатель объявляет свой максимальный размер окна, W_m. Размер окна отправителя не должен превышать W_m во избежание переполнения буфера получателя. При перегрузке канала связи пакеты теряются на некотором маршрутизаторе, и подтверждение не будет получено до того, как истечет таймаут. Чтобы среагировать на перегруженность канала связи, получатель должен уменьшить размер текущего окна W_c, тем самым снизив скорость передачи.

На рис. 10 показана эволюция бегущего окна. Каждое число (1-13) обозначает сегмент данных в протоколе TCP. Предположим (см. рис. 10), что текущий размер окна W_c равняется восьми сегментам. На рис. 10а все сегменты, вплоть до второго, были отправлены, и от получателя получено подтверждение. Сегменты 3-5 были отправлены, однако подтверждение еще не получено. Итак, отправителю разрешается послать еще пять сегментов в текущем окне (6-10). На рис. 10б показан случай, когда отправлены еще 2 сегмента (6 и 7). Для сегментов 3-7 нет подтверждения. На рис. 10в окно открывается, т.е. движется вправо после того, как получены подтверждения для сегментов 3 и 4.

Функционирование TCP-соединения можно разделить на две фазы: медленный старт (slow start) и избежание перегрузки (congestion avoidance). Поясним эти фазы при помощи рис. 11. Во время медленного старта размер окна W_c принимается равным одному сегменту и увеличивается на единицу после каждого полученного подтверждения. Подтверждения в TCP имеют кумулятивный характер, т.е. АСК подтверждает получение всех сегментов, вплоть до самого последнего. Итак, если размер окна составляет W_c, то отправитель может послать W_c сегмен­тов, получение которых будет подтверждено по истечении времени, выраженного в RTT (при условии, что никакие пакеты не теряются). Т.е. в фазе медленного старта отправитель посылает один сегмент и получает подтверждение через время 1 RTT. Размер окна увеличивается до двух и посылается два сегмента. Через время 1 RTT на эти два сегмента приходит подтверждение, и W_c увеличивается на два, по единице за каждый подтвержденный сегмент (теперь W_c = 4). Теперь отправляется четыре сегмента и через время 1 RTT приходит четыре подтверждения. W_c увеличивается на четыре (теперь W_c = 8). Итак, во время фазы медленного старта W_c удваивается через интервал времени, выраженный в RTT, но не может превысить длину окна получателя W_m. На рис.11 за время первой фазы медлен­ного старта W_c возросло до 16. При этом предполагается, что W_m> 16.

Рисунок 10 Механизм бегущего окна.

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

В любом случае, текущее значение размера окна сохраняется в переменной W_ssthr (slow start threshold window size - пороговое значение окна при медленном старте), а значение W_c уменьшается. В наиболее распространенной версии протокола TCP Reno подобное уменьшение происходит следующим образом. Для примера, показанного на рис. 11, дублирующее подтверждение получено в момент времени 5. Затем половина текущего значения W_c, равная восьми, сохраняется в переменной W_ssthr, и TCP-соединение начинает фазу избежания перегрузки. Еще одно дублирующее сообщение получено в момент времени 20. После этого значение переменной W_ssthr становится равным 7 (14/2).

Рисунок 11. Зависимость размера окна от времени (в RTT).

Если происходит таймаут, W_c устанавливается равным 1 и ТСР-соединение возвращается в фазу медленного старта. На рис. 11 таймаут произошел в момент времени 10, после этого соединение перешло в фазу медленного старта. Когда в этой фазе W_c достигнет значения W_ssthr, то ТСР-соединение перейдет в режим избежания перегрузки. Например, в момент времени 13 (см. рис. 11) W_c достигает текущего значения переменной W_ssthr = 8, и соединение входит в фазу избежания перегрузки.

Давайте рассмотрим работу ТСР-соединения в фазе избежания перегрузки. Здесь размер окна W_c увеличивается на 1/W_C для каждого полученного подтверждения. Другими словами, W_c увеличивается на единицу за каждый RTT.

Пропускная способность ТСР-соединения, Х_TCP, измеряемая в сегментах в секунду, обратно пропорциональна времени RTT, обратно пропорциональна вероятности р того, что пакеты потеряются при пересылке, прямо пропорциональна объявленному получателем размеру окна W_m (в сегментах) и обратно пропорциональна таймауту (ТСР-соединения) Т_о. Выражение для Х_TCP для соединения TCP Reno было получено Пэдхи (Padhye). Эта модель реализована в виде таблицы TCPModel.XLS, которая доступна на сайте издательства.

На рис. 12 показана пропускная способность ТСР-соединения в Кб/с как функция вероятности р того, что пакеты потеряются при пересылке, для четырех значений W_m: 10, 20, 30 и 40 сегментов. Остальные параметры для построения кривой таковы: время ожидания Г_о = 2 с, максимальный размер сегмента 1460 байт, предел пропускной способности соединения отправителя с получателем 12 500 Кбит/с, время на передачу и подтверждение приема RTT = 0.04 с. По рисунку несложно заметить, что с ростом размера окна W_m растет и пропускная спо­собность. Однако преимущества большего размера окна снижаются с ростом вероятности потери пакетов, поскольку после потери пакета потребуется повторно от­правлять дополнительные объемы данных.

Рис.12 . Зависимость пропускной способности ТСР-соединения от вероятности потери пакетов.

Наилучшая пропускная способность ТСР-соединения достигается в том случае, когда текущий размер окна W_c достигает значения максимального размера окна получателя W_m, и при этом перегруженность канала связи отсутствует. В таком случае пропускная способность составит W_m/RTT (сегментов/с) или (W_m / RTT) * MSS (байт/с), где MSS - максимальный размер сегмента. Однако пропускная способность ТСР-соединения не может превысить предельную ширину полосы пропускания сети, соединяющей отправителя и получателя В (байт/с). Итак,

Х_ТСР < min{B, (W_m/RTT)* MSS}                                    (1)

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

Числитель дроби в выражении (2) называется базой сигнала (bandwidth-delay product).

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

В табл. 2.1 показаны база сигнала и оптимальное значение размера окна получателя w*_m (в сегментах) для различных типов сетей, исходя из предположения, что размер сегмента составляет 1 460 байт.  Как показано в таблице, сети с высокой пропускной способностью и малым временем задержки требуют больших размеров окон для обеспечения оптимальной пропускной способности ТСР-соединения (чтобы максимально ис­пользовать пропускную способность сети).

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

2.3. Клиент-серверная парадигма

Клиент-серверные вычисления - это распределенная модель, используемая в Web, при которой выделяются два типа сущностей, реализуемых прикладными приложениями: клиенты (clients) и серверы (servers). Термин "сервер" не следует путать с компьютером, на котором выполняется серверный процесс. Для обозначения такого компьютера и его операционной системы мы будем употреблять термин "машина серверного класса" или ссылаться на него как на компьютер, что будет означать оборудование и операционную систему, используемую для запуска программного обеспечения, которое реализует функции сервера. Клиентский процесс, или просто клиент:

·         запускается на настольном компьютере или пользовательской рабочей станции и поддерживает графический пользовательский интерфейс (GUI) для сбора и отображения данных;

·         производит запросы на специфические службы, выполняемые одним или более серверными процессами, обычно расположенными на удаленных машинах;

·         выполняет часть кода приложения.

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

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

·         никогда не начинает обмен сообщениями с каким-либо клиентом; серверы представляют собой пассивные объекты, которые получают запросы пользователей, выполняют их и отвечают клиентам.

Протокол, по которому общаются клиенты и серверы - это протокол типа "зап­рос-ответ" (request-reply), по которому клиенты отправляют запросы, а серверы отвечают на них (рис. 13). Клиенты и серверы могут работать на базе протокола TCP или модели без установки соединения, например, UDP.

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

                                                                      

Рисунок 13. Запрос-ответ в системе клиент-сервер

Использование множественных потоков или процессов приводит к интересному эффекту со временем отклика, как показано на рис. 15. На рисунке изображены две кривые времени отклика: одна для интенсивности запросов 2.5 запросов/с, а вторая - для 3.6 запросов/с. Предположим, что каждый запрос использует 0.07 с процессорного и 0.2 с дискового времени. Как показано на рисунке, с ростом количества потоков от одного до двух время отклика уменьшается, т.к. уменьшается время, проводимое запросом в ожидании свободного потока. Однако с увеличением количества потоков свыше двух, запрос начинает тратить дополнительное время на получение тех же аппаратных ресурсов (т.е. процессора, памяти и дис­ков), и это дополнительное время превышает экономию времени на ожидание свободного потока. В результате время отклика сети возрастает. Для фиксированного значения интенсивности запросов, при значительном увеличении числа потоков, время ожидания потока становится пренебрежительно малым, а время, затрачиваемое запросом на получение аппаратных ресурсов, - постоянным (ввиду того, что среднее число активных потоков не может увеличиваться с ростом максимального количества активных потоков). Следовательно, время отклика уже больше не за­висит от числа потоков.

                                                                                      

Рисунок 14 . а) Сервер с одним процессом. б) Сервер с несколькими процессами.

                                                                                                            

Рисунок 15.  Зависимость среднего времени отклика (в секундах) клиент-серверной системы от количества потоков на сервере.

Распространенный вопрос при разработке клиент-серверных систем сводится к тому, какую архитектуру следует использовать: двухзвенную или трехзвенную? При двухзвенной архитектуре графический интерфейс пользователя (GUI) и логи­ка приложения запускается на стороне клиента, а SQL-сервер - на стороне серве­ра. При трехзвенной архитектуре графический интерфейс пользователя запускается на стороне клиента, тогда как логика приложения - на стороне сервера приложений, который выступает в качестве клиента для SQL-сервера.

Еще один важный вопрос при выборе архитектуры связан с тем, насколько мощным должен быть клиент? "Толстые" (fat) клиенты реализуют большее количе­ство логики транзакций, нежели "тонкие" (thin), и требуют меньшего взаимодей­ствия с сервером за счет требования от клиента более своих высоких вычислительных возможностей.

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

Серверы должны хранить в своих кэш-структурах копии файлов и записей баз данных. Web-серверы, расположенные близко от группы клиентов, должны хранить наиболее часто запрашиваемые документы, дабы не обращаться за ними к удаленным серверам, сто, таким образом, позволит уменьшить время отклика и требования к пропускной способности. Когда запрашиваемые данные находятся в кэше, говорят, что происходит событие удачного обращения в кэш (cache hit), в противном случае - промах обращения в кэш (cache miss). Для примера рассмотрим файловый сервер, получающий запросы на чтение файловых блоков размером в 8 Кб с интенсивностью 900 запросов/с. Если для 30% подобных запросов будет производиться удачное обращение в кэш клиента (т.е. будет найдено совпадение), то реально сервер будет получать (1 -0.3) * 900 = 630 запросов/с. Если 25% этих запросов будут удовлетворяться из кэша сервера, котрый организован в его основной памяти, то тогда только (1 - 0.25) * 630 = 472.5 запросов/с достигнут дисковой подсистемы сервера. Цена, которую приходится платить за использование кэширования, связана с необходимостью постоянного хранения данных в кэше. Кроме того, потребуется дополнительная обработка для случаев промаха кэша.

2.4. Типы серверов

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

Файловые серверы реализованы на базе сетевых компьютеров с доступом к файловой системе совместного использования (см. рис. 16а). Клиенты делают запросы на просмотр каталогов, получение атрибутов файлов, чтение и запись блоков файлов. Одним из наиболее популярных файловых серверов по праву счи­тается NFS (Network File System — сетевая файловая система). Система NFS обес­печивает обмен данными в разнородных сетях. В качестве транспортного протокола в ней могут использоваться как UDP, так и TCP/IP. Однако в большинстве версий NFS используется только протокол UDP.

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

                                                                         

Рисунок 16. а) Файловый сервер б) SQL сервер в) Сервер приложений

Серверы приложений обеспечивают доступ к удаленным процедурам, вызываемым клиентами с помощью механизма RPC (Remote Procedure Call - удаленный вызов процедуры). Удаленные процедуры обеспечивают логику работы приложе­ния, отправляя SQL-запросы процессору базы данных сервера.

Итак, вместо взаимодействия клиент-сервер по каждому SQL-запросу, такой подход требует всего одного взаимодействия на вызов процедуры (см. рис. 16в).

Как видно из рис. 16а-16в, у SQL-сервера и сервера приложений, по срав­нению с файловым сервером, уменьшается интенсивность запросов к серверу, но возрастает сложность каждого запроса. Выбор оптимального по производительнос­ти решения зависит от конкретных значений соответствующих параметров. Монитор обработки транзакций ТРМ (Transaction Processing Monitor)  применяется для распределения нагрузки между несколькими серверами, выполняющими одну и ту же службу, обеспечивает динамическую репликацию, а также управляет досту­пом к серверам баз данных с целью улучшения производительности. В других системах, таких как сервер транзакций Microsoft (Microsoft's Transaction Server), по­казатели производительности и расширяемости системы еще больше улучшаются с помощью (1) использования пула потоков, отводимых под обслуживание запросов и возвращаемых в пул по окончании обслуживания запроса; (2) установки во вре­мя инициализации пула соединений с базой данных между окружением сервера транзакций и различными базами данных, которые используются приложениями. Этот пул предварительно соединенных сеансов баз данных во время обслуживания запроса уменьшает до нуля время, требуемое на соединение с базой данных.

Серверы программного обеспечения коллективного пользования обеспечивают доступ к неструктурированной и слабоструктурированной информации, подобной текстам, изображениям, почтовым сообщениям, доскам объявлений и технологическим процессам . Серверы объектов поддерживают удаленные вызовы методов, предназначенных для поддержки разработки распределенных объектно-ориентиро­ванных приложений. Связующим звеном между клиентами и удаленными объекта­ми служит брокеры объектных запросов (Object Request Broker, ORB).

Серверы программного обеспечения предоставляют выполняемые файлы сете­вым компьютерам (network computer, NC). У сетевых компьютеров нет жестких дисков, они просто подсоединены к сети и получают выполняемые файлы коммер­ческого программного обеспечения от упомянутого сервера, на котором всегда на­ходится последние версии требуемого программного обеспечения.

Web-серверы обеспечивают доступ к документам, изображениям, звуковым фай­лам, выполняемым файлам, загружаемым приложениям (например, Java-аплетам) через протокол HTTP. Функционирование Web-серверов рассматривается в сле­дующем подразделе.

2.5. HTTP

Документы для Web реализуются на простом "языке разметки", называемом HTML (HyperText Markup Language - язык гипертекстовой разметки) [4]. Язык HTML используется для создания гипертекстовых документов, давая возможность описывать структуру документа с указанием заголовков, выделений, связей с другими документами и т.д. В HTML- документы можно вставлять изображения и другие мультимедиа-объекты. Таким образом, HTML позволяет интегрировать в среде Web видеоклипы, программные приложения, мультимедийные объекты. Большинство HTML-документов состоят из текста и ссылок на встроенные изображения. Связь между ссылкой и именем файла изображения обеспечивают вставку изображения во время просмотра документа.

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

2.6. Сочетание протоколов HTTP и TCP/IP

HTTP  - это протокол уровня приложений, расположенный поверх протокола TCP, и применяемый для взаимодействий между клиентами и серверами в Web. Протокол HTTP определяет простое взаимодействие вида запросответ, которое называется "Web-транзакцией". Каждое HTTP-взаимодействие состоит из запроса, посылаемого от клиента серверу, и следующего за ним ответа от сервера клиенту. HTTP-запрос состоит из нескольких частей: метода, указывающего на действие (GET, HEAD, PUT и POST), унифицированного указателя информационного ре­сурса (Uniform Resource Locator, URL), который идентифицирует имя запрашиваемой информации, а также другой информации, такой как тип требуемого документа, аутентификация и разрешение на оплату.

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

·     Установка соответствия между именем сервера и IP-адресом (например, между именем www.performance_book.com и адресом 199.333.111.0).

·     Установка TCP-соединения с сервером.

·     Передача запроса (URL + метод + другая информация).

·     Получение ответа (HTML-текста, изображения либо другой информации).

·     Закрытие TCP/IP-соединения (как будет показано далее, в случае HTTP 1.1 соединение остается открытым для получения вложенных изображений).

С каждым из указанных этапов связана присущая ему стоимость, которая зави­сит от производительности сервера и сети; это будет показано ниже в этом разделе.

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

Существует и другая сторона медали для такого протокола, связанная со стоимостью производительности. Первая версия протокола, HTTP 1.0, имела несколько недостатков, касающихся производительности системы. Например, для каждого запроса устанавливалось новое соединение. Страница с текстом и большим количеством небольших изображений генерировала множество отдельньк соединений: одно для HTML-страницы и по одному на каждое изображение. Ввиду того, что большинство Web-объектов малы по размеру, то большая часть пакетов, которыми обмениваются клиент и сервер - это ни что иное, как управляющие пакеты TCP, обеспечивающие открытие и закрытие соединений (см. рис. 17а).

Ключевой элемент для понимания работы пары протоколов HTTP и TCP/IP связан с природой обязательных задержек, порождаемых протоколами. Эти задержки можно разложить на задержку соединения и задержку запроса. Первая - это время (измеряемое в RTT), необходимое на установку соединения. Вторая представляет собой время, необходимое на выполнение передачи данных через установленное соединение. Давайте проанализируем задержки, возникающие при выполнении Web-транзакции.

Рисунок 17 а) HTTP- взаимодействие по протоколу HTTP 1.0. б) HTTP- взаимодействие по протоколу HTTP 1.1.

На рис. 17 показан обмен пакетами между клиентом и сервером во время HTTP-взаимодействия через протокол TCP . На рис. 17а) можно видеть обмен пакетами, происходящий в версии протокола HTTP 1.0, а на 176) — в его более поздней версии HTTP 1.1 (в которой поддерживается открытое ТСР-соединение в течение HTTP-запросов). Горизонтальные пунктирные линии со стороны клиента указывают на обязательные задержки сети (в RTT), вызванные совместным функционированием протоколов TCP/IP и HTTP. Пакеты, изображенные светло-серыми линиями, требуются для протокола TCP, но не влияют на задержку, т.к. получатель не обязан ждать их получения для продолжения выполнения своей работы. К обязательным задержкам, возникающим при HTTP-взаимодействии типа запрос-ответ, относятся:

·         Клиент открывает ТСР-соединение, что приводит к обмену сегментами SYN (синхронизации) и АСК (подтверждения) .

·         Клиент посылает HTTP-запрос на сервер, который выполняет его синтаксический разбор, предпринимает требуемые действия и отправляет обратно ответ. В случае поискового запроса сервер должен передать данные с диска
или кэша клиенту через сеть. После этого сервер отвечает за закрытие соединения. Сегменты FIN (сигнализирующие об окончании передачи), которыми должны обменяться сервер и клиент для закрытия соединения, на рис.17 не показаны, поскольку для продолжения своей работы клиент не обязан ждать закрытия соединения.

·         Клиент проводит синтаксический разбор HTML-ответа для поиска URL-адресов встроенных изображений. Затем клиент открывает новое ТСР-соединение, для чего потребуется еще одно трехстороннее квитирование связи.

·         Клиент снова отправляет HTTP-запрос для первого встроенного изображения, и весь процесс повторяется сначала.

Для каждого дополнительного запроса должно быть установлено новое ТСР-соединение, и система снова проходит через процесс установки соединения. Вслед­ствие комбинации протоколов HTTP и TCP/IP клиент должен ждать отображения браузером документа с одним встроенным изображением в течение промежутка времени, равного, по меньшей мере, 4 RTT сети. Каждое дополнительное изобра­жение требует, минимум, еще 2 RTT: одно - на установку TCP-соединения и одно - на получение изображения. Поскольку TCP-соединение проходит через фазу медленного старта, то большинство операций протокола HTTP 1.0 неэффек­тивно используют возможности TCP, в результате чего получается низкая эффек­тивность системы из-за перегрузки каналов связи и большого количества служеб­ных сигналов.

В новой версии протокола HTTP (известной как HTTP 1.1, HTTP с устойчи­вым соединением, или HTTP-NG) решена часть проблем, ограничивающих произ­водительность версии 1.0. HTTP 1.1 оставляет открытым TCP-соединение между двумя последовательными операциями (см. рис. 17б). Этот метод, называемый "устойчивым соединением" ("permanent connection"), использует одно и то же ТСР-соединение для обслуживания множества HTTP-запросов, при этом исключаются расходы на открытие и закрытие других соединений, равно как и минимизируется влияние медленного старта. Итак, через единственное TCP-соединение можно об­служивать множество запросов и ответов. Это свойство позволяет также избежать многих задержек кругового обращения (на передачу и подтверждение приема), улучшить производительность и уменьшить количество пакетов при обмене. Из рис. 17 видно, как новый HTTP-протокол влияет на задержки сети. В случае запроса на HTML-документ и одно встроенное изображение, документ будет по­лучен браузером через время 3 RTT вместо 4 RTT (для протокола HTTP 1.0).

Еще одной особенностью протокола HTTP 1.1., влияющей на производитель­ность, является конвейерная обработка запросов. Конвейерная обработка запро­сов позволяет послать сразу много запросов, не ожидая ответа на первый, второй и т.д. из них. Т.е. клиент отправляет множество запросов через ТСР-соединение до того, как получит ответ на свои предыдущие запросы. Экспериментальные данные показывают, что использование конвейерной обработки в HTTP 1.1 по­зволяет намного улучшить производительность, даже по сравнению с HTTP 1.0 со множеством параллельных TCP-соединений.

3.  Модель взаимодействия равноправных систем

Как вы знаете, в Web в основном используется вычислительная модель типа клиент-сервер. Как мы уже обсуждали, протокол клиент-серверного взаимодействия построен на модели "запрос-ответ", при которой сервер ожидает запросов от клиентов, а затем на них отвечает. В каком-то смысле сервер (или набор серверов одного сайта) представляет собой центральное хранилище ресурсов (файлов или средств по обработке транзакций). Такая центральная роль сервера (или группы равноправных серверов) в модели "клиент-сервер" является препятствием для уве­личения расширяемости и надежности системы. В последнее время стали применять более общий подход, называемый моделью взаимодействия равноправных сис­тем (peer-to-peer model, P2P) . Этот подход применяется для поддержки различных приложений, таких как коллективный доступ к сжатым музыкальным файлам , дисковому пространству , традиционным файлам и даже вычислительным циклам центрального процессора . Подобная тенденция возникла частично и потому, что персональные компьютеры стали значительно быстрее, у них стало больше дискового пространства, возросла скорость соединения с Internet. Модель взаимодействия равноправных систем применяется также и по той причине, что существенная доля ресурсов персональных компьютеров и рабочих станций не используется их владельцами. Например, исследование, проведенное в крупной компании, имеющей около 10 000 файловых систем, показало, что приблизительно 50% общего объема дискового пространства пустует . Другое исследование показало, что до 75% сетевых циклов на рабочей станции представляют собой простои .

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

На рис. 18а показан сервер метаданных, на который отправляются запросы с любой машины, который нужен доступ к ресурсу (например, файлу). Например, машина С посылает запрос на сервер метаданных и получает список сайтов, скажем (I, J, Н), на которых имеется копия запрашиваемого ресурса. Затем С выбирает из этого списка одну машину - например, I, и проводит с ней сеанс связи. Во время сеанса С получает доступ к ресурсу. Итак, сервер метаданных занима­ется регистрацией сайтов и ответом на запросы, связанные с поиском ресурсов. Доступ происходит на основе модели равноправных вычислений. Именно так работает сеть Napster.

Рисунок 18. а) Архитектура Р2Р с централизованным сервером метаданных, б) Архитектура Р2Р без централизованного сервера метаданных.

На рис. 18б показан случай архитектуры Р2Р без централизованного сервера метаданных. Здесь каждая машина содержит информацию о ресурсах, расположенных на соседних машинах. Например, машина С запрашивает своих соседей А, В и D. Машина D не знает местоположение ресурса, но посылает запрос на машины Е и F. Машина F запрашивает машину I, на которой оказывается требуемый ресурс. Ответ передается на машину С через F и D. Затем, как и в случае с рис. 2.18а, С устанавливает сеанс связи с I. В некоторых случаях желаемый ресурс может также передаваться обратно вместе с информацией о его положении, в резуль­тате чего копии этого ресурса будут храниться ближе к точке, в которой они часто запрашиваются.

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

4. Протоколы Web-серверов

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

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

Примерами Web-служб могут быть простые запросы, такие как котировка акций, аутентификация пользователя, разрешение на платеж, а также и более слож­ные задачи, например "Купить авиабилет из Сан-Франциско до Нью-Йорка на 14 мая". Архитектура Web-служб должна обеспечить автоматизацию задач, подобных поиску службы, выполнению, формированию результата, промежуточным операциям. Поиск Web-службы включает автоматические процедуры, выполняющие указанную задачу и показывающие запрашиваемые свойства. Выполнение Web-службы возложено на программу или агента, автоматически запускающего указанную службу в Web. Формирование результата и промежуточные операции - это автоматический выбор и составление адекватной поставленной задаче Web-службы . Для стандартизации требований к Web-службам и технологий их разработки были приложены усилия множеством организаций; особенно это касается вопросов открытия и выполнения Web-служб.

На рис.19 показан многоуровневое представление безопасного стека протоколов и стандартов, который обеспечивает работу Web-служб. Для создания унифицированно­го описания службы и протоколов ее открытия применяются стандартные технологии, такие как TCP/IP, HTTP, XML и SOAP. На верхних слоях (см. рис.19) находятся пока еще не разработанные протоколы взаимодействия и стандарты.

4.1  SOAP

Простой протокол доступа к объектам (Simple Object Access Protocol, SOAP) - это проект документа, разработанный консорциумом World Wide Web Consortium (W3C), который описывает, как использовать язык XML и протокол HTTP для создания механизмов доставки информации и вызова удаленных процедур . SOAP представляет собой упрощенный протокол для обмена информацией в децентрализованном распределенном окружении. Это спецификация, которая указывает стандартный способ передачи данных на языке XML. SOAP состоит из трех частей: конверта, который определяет последовательность работ по описанию содержимого сообщения и по его обработке; набора кодирующих правил для описания экземпляров типов данных, определяемых приложением; и соглашения о представлении вызовов удаленных процедур и откликов. SOAP построен на базе протокола HTTP и языка XML. SOAP определяет последовательность действий, которая позволяет программе запрашивать службу через Internet без необходимости использования обычного языка программирования или инфраструктуры коллективного доступа.

4.2  WSDL

Язык описания Web-служб (Web Servive Description Language, WSDL) - это XML-формат для описания сетевых служб как набора конечных точек, работающих с сообщениями, содержащими или документно-ориентированную, или процедурно-ориентированную информацию. Операции и сообщения описываются абстрактно, а затем для определения конечной точки привязываются к конкретному сетевому протоколу и формату сообщения . Другими словами, WSDL используется для описания того, что делает служба, где она находится и как ее вызывать.

4.3  UDDI

Универсальная услуга описания, обнаружения и интеграции (Universal Description, Discovery and Integration, UDDI) - это спецификация, которая определяет способ опубликования и открытия информации о Web-службах . Спецификация состо­ит из нескольких связанных документов и XML-схемы, определяющих программируемый протокол на основе SOAP для регистрации и открытия Web-служб. UDDI представляет собой проект, направленный на интеграцию Web-служб. Он обеспе­чивает клиентам механизм динамического поиска служб в Internet. Ядром проекта UDDI является UDDI бизнес-регистрация, т.е. XML-файл, используемый для описания бизнес-объекта и его Web-служб . UDDI можно рассматривать как службу DNS для бизнес-приложений.

Литература

[1] J. М. Andrade, М. Т. Carges, Т. J. Dwyer, and S. D. Felts, The Tuxedo System, Addison Wesley, Reading, Massachusetts, 1996.

[2] BBN, "A History of the ARPANET: The First Decade," Tech. Rep., Bolt, Beranek, and Newman, Massachusetts, 1981.

[3] G. Bell and J. Gray, "The Revoluti on Yet to Happen," Beyond Calculation: The Next Fifty Years of Computing, P. J. Denning and R. M. Metcalfe, eds., Copernicus Springer-Verlag, New York, 1997.

[4] T. Berners-Lee, R. Cailliau, H. Nielsen, and A. Pecret, "The World Wide Web," Comm. ACM, vol. 37, no. 8, pp. 76-82, Aug. 1994.

[5] D. Bertsekas and R. Gallager, Data Networks, 2nd ed., Prentice Hall, Upper Saddle River, New Jersey, 1992.

[6] W. J. Bolosky, J. R. Douceur, D. Ely, and M. Theimer, "Feasibility of a Serverless Distributed File System Deployed on an Existing Set of Desktop PCs," Proc. A CM Sigmetrics 2000 Int. Conf. on Measurement and Modeling of Сотр. Syst., June 17-21, 2000, Santa Clara, California, pp. 34-43.

[7] V. Cerf, "When They're Everywhere," Beyond Calculation: The Next Fifty Years of Computing, P. J. Denning and R. M. Metcalfe, eds., Copernicus Springer-Verlag, New York, 1997.

[8] D. E. Comer, Internetworking with TCP/IP Vol. I: Principles, Protocols, and Architecture, 4th ed., Prentice Hall, Upper Saddle River, New Jersey, 2000.

[9] J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, San Francisco, California, 1993.

[10] О. Gusak and Т. Dayar, "A Generalization of a TCP Model: Multiple Source-Destination Case with Arbitrary LAN as the Access Network," Chapter 3 of System Performance Evaluation: Methodologies and Applications, Erol Gelenbe, ed., CRC Press, Boca Raton, Florida, pp. 39-49, 2000.

[11] J. Heidmann, K. Obraczka, and J. Touch, "Modeling the Performance of HTTP Over Several Transport Protocols," IEEE/ACM Trans. Networking, vol. 5, no. 5, pp. 616-630, Oct. 1997.

[12] Enhanced Storage Solution, www.idrive.com

[13] Institute of Electrical and Electronics Engineers, "Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Speci.cations (ANSI)," IEEE, Standard 8802-3: 1996 (ISOIIEC) [ANSI /IEEE Std 802.3, 1996 Edition] .

[14] IEEE, "Supplement to Carrier Sense Multiple Access with Collision Detection (CSMA/CD)," IEEE, Standard 802.3u-1995 .

[15] IEEE, "Token Ring Access Method and Physical Layer Specifcation," IEEE, Standard 8802-5: 1995 (ISOIIEC) [ANSI /IEEE 802.5, 1995 Edition].

[16] IEEE, "IEEE 802.11 Standard for Wireless LAN Medium Access (MAC) and Physical Layer (PHY) Specifcations," 2001.

[17] K. Kant, R. Iyer, and V. Tewari, "On the Potential of Peer-to-peer Computing: Classi.cation and Evaluation," Enterprise Architecture Lab, Intel Corporation, Oregon, 2001.

[18] K. Kant and R. Iyer, "A Performance Model for Peer-to-peer File Sharing Services," Enterprise Architecture Lab, Intel Corporation, Oregon, 2001.

[19] L. Kleinrock, Queueing Systems, Vol. I: Theory, John Wiley and Sons, New York, 1975.

[20] L. Kleinrock, Queueing Systems, Vol. II: Computer Applications, John Wiley and Sons, New York, 1976.

[21] J. F. Kurose and K. W. Ross, Computer Networking: A Top-Down Approach Featuring the Internet, Addison Wesley, Boston, Massachusetts, 2001.

[22] S. Mcllraith, T. Son, and H. Zeng, "Semantic Web Services," IEEE Intelligent Systems, March/April 2001.

[23] R. M. Metcalfe and D. R. Boggs, "Ethernet: Distributed Packet Switching for Local Computer Networks," Comm. ACM, pp. 395-404, 1976.

[24] M. W. Mutka and M. Livny, "The Available Capacity of a Privately Owned Workstation Environment," Performance Evaluation, vol. 12, pp. 269-284, 1991.

[25] Napster, www.napster.com

[26] Н. Nielsen, J. Gettys, A. Bair-Smith, E. Prud'Hommeaux, H. Lie, and С. Lilley, "Network Performance Effects of HTTP/1.1 CSS1, and PNG," Proc. ACM SIGCOMM'97, Cannes, France, Sept. 16-18, 1997.

[27] P. O'Neil and E. O'Neil, Database: Principles, Programming, Performance, 2nd ed., Morgan Kauffman, San Francisco, California, 2000.

[28] R. Orfali, D. Harkey, and J. Edwards, Client/Server Survival Guide, 3rd ed., John Wiley and Sons, New York, 1999.

[29] J. Padhye, V. Firoiu, D. Towsley, and J. F. Kurose, "Modeling TCP Reno Performance: A Simple Model and Its Empirical Validation," IEEE/ACM Tr. Networking, vol. 8, no. 2, pp. 133-145, April 2000.

[30] V. Padmanabhan and J. Mogul, "Improving HTTP Latency," Comput. Networks ISDN Syst., vol. 28, nos. 1,2, Dec. 1995.

[31] M. Parameswaran, A. Susarla, and A. B. Whinston, "P2P Networking: an Information-Sharing Alternative," IEEE Computer, July 2001.

[32] R. Perlman, Interconnections, 2nd. ed., Addison Wesley, Reading, Massachusetts, 1999.

[33] SETI, the Search for Extraterrestrial Intelligence, www.setiathome.ssl. berkeley.edu

[34] M. P. Singh, "Peering at Peer-to-Peer Computing," IEEE Internet Computing, vol. 5, no. 1, pp. 4-5, 2001.

[35] Simple Object Access Protocol (SOAP), www.w3.org/TR/SOAP

[36] W. Stallings, Networking Standards: A Guide to OSI, ISDN, LAN, and MAN Standards, Addison Wesley, Reading, Massachusetts, 1993.

[37] W. R. Stevens, TCP/IP Illustrated, Vol. I, Addison Wesley, Reading, Massachusetts, 1994.

[38] W. R. Stevens, TCP/IP Illustrated, Vol. 3, Addison Wesley, Reading, Massachusetts, 1996.

[39] T. Tu, "Analysis of Broadband Performance," J. Сотр. Resource Management, Computer Measurement Group, pp. 35-39, Spring 2001.

[40] Universal Description, Discovery, and Integration of Business for the Web, www.uddi.org

[41] Web Services Description Language (WSDL), www.w3.org/TR/wsdl [42] World Wide Web Consortium, www.w3.org

[43] N. Yeager and R. McCrath, WebSer ver Technology, Morgan Kaufmann, San Francisco, California, 1996