tanenbaum_seti_all.pages (525408), страница 168
Текст из файла (страница 168)
Поскольку каждая часть соединения представляет собой полноценное ТСР-соединение, базовая станция сама подтверждает получение каждого сегмента обычным способом. Только теперь получение подтверждения отправителем означает не то, что сегмент успешно добрался до получателя, а только то, что его получила базовая станция. Другое решение, разработанное Балакришнаном (Ва1а1сг1зйпап и др., 1995), не нарушает семантики протокола ТСР, В его основе лежат небольшие изменения Транспортные протоколы Интернета: ТСР 631 в программе сетевого уровня, работающей на базовой станции.
Одно из изменений состоит в добавлении специального следящего агента, просматривающего и кэширующего сегменты, направляемые мобильному хосту, и подтверждений, посылаемых им в ответ. Если следящий агент замечает, что в ответ на ТСР-сегмент, пересылаемый им мобильному хосту, не поступает подтверждения, он просто передает этот сегмент еще раз, не информируя об этом отправителя. У следящего агента есть свой таймер для отслеживания подтверждений, устанавливаемый на относительно небольшой интервач времени. Он также повторно передает сегменты, когда получает от мобильнога хоста дубликаты подтверждений, означающие, что хосту чего-то не хватает для счастья.
Дубликаты подтверждений уничтожаются на месте, чтобы отправитель на другом конце кабельной сети не принял их за сигнал о перегрузке. Недостаток такой прозрачности состоит в том, что при частых потерях сегментов на беспроводном участке у отправителя может истечь интервал ожидания, и он может запустить механизм борьбы с перегрузкой, В предыдущем варианте составного ТСР-соединения, напротив, алгоритм борьбы с перегрузкой никогда бы не запустился, если только в сети действительно не образовался бы затор. Метод Балакришиана также решает проблему потерянных сегментов, отправляемых мобильным хостом.
Если базовая станция замечает разрыв в порядковых номерах получаемых сегментов, она просит повторить недостающие байты. Благодаря этим двум исправлениям участок беспроводной связи стал более надежным в обоих направлениях, причем для зтога не потребовалось изменять семантику протокола ТСР и даже информировать о возникающих проблемах отправителя.
Хотя протокол ()1)Р и це страдает от тех же самых проблем, что и протокол ТСР, беспроводная связь также представляет для него некоторые трудности. Основная сложность состоит в том, что программы, использующие протокол ()1)Р, ожидают от него высокой надежности. Они знают, что гарантии не предоставляются, но, тем не менее, надеются, что протокол (П)Р почти совершенен. В условиях беспроводной связи до совершенства будет очень далеко. Программы, способные справляться с потерей (ЛЭР-сообщений (но довольно значимой ценой), попадая из окружения, в котором сообщения теоретически могут теряться, но теряются очень релка, в окружение, в котором они теряются постоянно, могут очень сильно потерять в производительности. Беспроводная связь затрагивает также аспекты, отличные от произволительности.
Например, как мобильному хосту найти локальный принтер, чтобы не связываться со своим домашним принтером? В чем-то близкой является проблема получения веб-страницы для локальной соты, даже если ее имя неизвестно. Кроме того, веб-дизайнеры обычно рассчитывают на большую пропускную способность сети. Они размещают на каждой странице гигантский логотип, для передачи которого по беспроводному каналу потребуется 10 с при каждом обращении к этой странице, что чрезвычайно раздражает пользователей, Беспроводные сети распространяются все шире, поэтому проблемы работы в них протокола ТСР становятся все более острыми.
Дополнительную информацию, касающуюся данных вопросов, можно найти в (Вагакас и др., 2000; Сйаш и Тйх1ц 1999; Нцзгап, 2001; Ху1ошепоз и др., 2001). 632 Глава 6. Транспортный уровень Транзакционный ТСР Мы уже рассматривали в этой главе, как осуществляется удаленный вызов процедуры в клиент-серверных системах. Если запрос и ответ достаточно малы, чтобы поместиться в один пакет, а операция идемпотсптна, то можно смело использовать 1Л)Р. Однако если эти условия не выполняются, применение протокола 1Л)Р оказывается менее привлекательным.
Например, если ответ может быть довольно объемным, то нужен механизм для последовательного выстраивания частей сообщения и повторной передачи потерянных пакетов. Получается, что речь идет о том, что приложению следует заново изобрести ТСР. Это, понятное дело, не очень привлекательная перспектива.
Однако и ТСР сам по себе в данном случае не кажется слишком привлекательным, Проблема заключается, прежде всего, в эфФективности. На рис. 6.33, а показана обычная последовательность пакетов, необходимая лля удаленного вызова процедуры. В лучшем случае потребуется обменяться девятью пакетами. Вот они: 1. Клиент посылает пакет Я'Ж для установки соединения. 2. Сервер посылает пакет (СК для подтверждения приема 5У)у'.
3, Клиент выполняет <тройное рукопожатие». 4. Клиент посылает, собственно, свой запрос. 5. Клиент посылает пакет Е11У, сигнализирующий об окончании передачи. 6. Сервер подтверждает запрос и Г1йг. 7. Сервер посылает овеет клиенту. 8. Сервер посылает пакет Е1И, сообщающий о том, что он также закончил передачу. 9. Клиент подтверждает Г1)у' сервера.
И это в лучшем случае! Если же обстоятельства складываются не очень удачно, то запрос и Н)у' клиента подтверждаются раздельно. Раздельно могут подтверждаться и ответ и г1Х сервера. Само собой, возникает вопрос: нельзя ли объединить эффективность выполнения КРС с помогдью 1Л)Р (всего два сообщения) с налсжностью, которую гарантирует ТСР7 Ответ: отчасти. Можно попытаться применить экспериментальный вариант протокола ТСР, называемый транзакционным ТСР (Т/ТСР, Тгапзасйопа1 ТСР).
Протокол Т/ТСР описан в КГС 1379 и 16И. Центральная идея протокола состоит в том, чтобы немного изменить стандартную последовательность действий, выполняемых прн установке соединения, и предоставить возможность передачи данных непосредственно во время установки соединения. Работа Т/ТСР показана на рис. 6.33, б.
В нервом пакете клиента содержится бит 5УУ, собственно запрос и г11у'. В сущности, клиент говорит: «и хочу установить соединение, вот данные для передачи, и на этом я считаю свою миссию вьшолнсннойм Получив запрос, сервер ищет или вычисляет содержимое ответа и выбирает способ ответа. Если ответ укладывается в один пакет, он будет послан так, как показано на рис. 6.33, б, то есть сервер как бы говорит: «Подтверждаю получение Вопросы производительности 633 ос, и на этом я считаю свою миссию вьшолнепшего г1)у', вот мой ответ на запрос, и а вашего й».
Клиент полтверждаст с р гт1тт ервера, и да атом работа протокола заканчиванои». роцесс потребовалось всего три сообщения. ется. . Обратите внимание: на весь про Клиент Сервер Клиент Сервер Время Время б в Рис. 6.33. Удаленны вызов пр ц й зов процедуры с помощью сбычногоТСР (в); удаленный Р б! вызов процедуры с помощью т/ТС (, О с ответ не укладывается в одтш пакет, р р , се ве может и не устапавднако если ответ кетов, сколько пужливать бит г11т' в первом ж п б г11т' .
же пакете. Он посылает столько па ТСР , ч о к оме Т,гТСР известны и другие вариации на тему Стоит отметить, что кроме,гТ тролем потока О ним из таких протоколов является пр р отокол пе едачи с контрол дним ! . С е и его свойсгв можно выделить (ВСТР, Бггеапт Сопгго! Тгапзш)зз!оп Ргогосо ). Среди олько ежимов доставки (например, неупосохранение границ сообщении, несколько р а ию бли ование адресатовл сслек ), тиврядоченная), множественную адресацию (ду л р Л х, 2001). Тем не менее, когда кто-то про т ' ные подтверждения (Вгетуагг и Мегх, 20 ). г х лет, обычно ек асио аботает в течение долгих лет, о ь ет улучшения того, что и гак прекр р 1 х лет, о ь в х диаметрально противоп .
о возникают споры между сторонниками д ух , что понк~ иональности» и «Нс трогать то, что и- принципов: «Все для расширения функц о ' ка еще пе сломалось». Вопросы производительности н ю оль в компьютерных сетях. Когда Вопросы производительности играют важную роль вится ены вместе, нх взаимодействие станов сотни или тысячи компьютеров соединены вм неп сдсказуемым последствиям, асто очень сложным и может привести к непр д оизводительности, причины которои дов сложность приводит к низкой прои д п осы, святрудно определить. В следующих ра д р з елах мы ассмотрим многие вопро 634 Глава 6.
Транспортный уровень ванные с производительностью сетей, определим круг сушествующих проблем и обсудим методы их разрешения. К сожалению, понимание производительности сетей — зто скорее искусство, чем наука. Теоретическая база, допускаюшая хоть какое-то практическое применение, крайне скулна. Лучшее, что мы можем сделать, — это представить несколько практических методов, полученных в результате долгих экспериментов, а также привести несколько реально действующих примеров. Мы намеренно отложили эту дискуссию до того момента, когда будет изучен транспортный уровень в сетях ТСР, чтобы иметь возможность иллюстрировать некоторые места примерами из ТСР. Вопросы производительности возникают не только на транспортном уровне.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
