Полный курс лекций 2009-го года (1130357), страница 73
Текст из файла (страница 73)
Его идея состоит в следующем. Всемашины в сети оснащены таймерами. Таймер работает даже в случае сбоя машины, т.е. он абсолютнонадежен. Каждый таймер - двоичный счетчик достаточно большой разрядности, равной илипревосходящей разрядность последовательных чисел, используемых для нумерации пакетов. Приустановлении соединения значения нескольких младших разрядов этого таймера берутся в качественачального номера последовательности пакетов.
Главное, чтобы последовательности номеров пакетоводного соединения не приводили к переполнению счетчика и его обнулению. Количество разрядов длянумерации TPDU должно быть достаточно большим, чтобы к моменту исчерапания счетчика все пакеты,возникшие вначале, уже исчезли из сети.Проблема возникает, когда машина восстанавливается после сбоя. Транспортный агент не знает вэтот момент, какое число можно использовать для очередного номера.
Чтобы избежать повторногоиспользования порядкового номера, который уже был сгенерирован перед сбоем машины, вводитсяспециальная величина по времени, которая образует область запрещенных номеров (см. рисунок 6-10).Рисунок 6-10. (а) TPDU не могут попасть в запрещенную область; (b) ПроблемаресинхронизацииНеобходимость введения этой области демонстрирует следующий пример.
Предположим дляпростоты, что в момент x начальный номер будет x, и что максимальное время жизни пакета равно 60 сек.Пусть в t = 30 сек. был послан пакет с номером 80, после чего наступил сбой в работе. Пусть в моментt = 60 машина была восстановлена после сбоя, и в момент t = 70 появился пакет с номером 80. Однакостарый пакет с номером 80 все еще существует, так как он будет жить до t = 90. Поэтому для каждогомомента времени вводят область запрещенных номеров. Машина, восстановленная после сбоя, не можетвыбирать номера из этой запретной зоны.
Поэтому после восстановления следует подождать Т сек., покавсе ранее посланные пакеты не перестанут существовать. На практике поступают иначе, чтобы не тратитьвпустую эти Т сек. Строят кривую скорости генерации номеров n = at, тогда после сбоя надо выбиратьномера по формуле: n = at + T.Проблема номеров может возникать по двум причинам. Либо потому, что машина генерируетслишком быстро пакеты и соединения, либо потому, что делает это слишком медленно. Чем большеразрядность счетчика последовательных номеров, тем дальше отодвигается момент попадания в запретнуюобласть.Другая нетривиальная проблема - надежное установление соединения: пакеты ведь могут пропадать.Для ее решения Томлинсон предложил процедуру «троекратного рукопожатия» (three-way handshake),которая проиллюстрирована на рисунке 6-11.
(CR и ACK обозначают соответственно CONNECTIONREQUEST и CONNECTION ACCEPTED.)Рисунок 6-11. Установление соединения с помощью «троекратногорукопожатия»: (а) Нормальная ситуация; (б) Старый дубль CONNECTIONREQUEST возникает «ниоткуда»; (с) Дубли CONNECTION REQUEST и ACKЭта процедура предполагает, что машина 1 шлет запрос на установление соединения под номером x.Машина 2 шлет подтверждение на запрос x, но со своим номером у. Машина 1 подтверждает получениеподтверждения с номером у. На рисунке 6-11 (b) и (c) показано, что будет, если поступит запоздавшийзапрос на соединение и запрос и подтверждение на него.6.2.3.
Разрыв соединенияРазрыв соединения, как уже было сказано, может быть асимметричным или симметричным.Асимметричный разрыв может привести к потере данных (см. рисунок 6-12).Рисунок 6-12. Разрыв соединения с потерей данныхСимметричный разрыв каждая сторона проводит самостоятельно, когда она передала весьимеющийся объем данных. Однако определить этот факт не всегда просто. Здесь есть одна проблема,которая называется проблемой двух армий (см. рисунок 6-13).Суть этой проблемы в следующем. Пусть есть две противоборствующие армии, скажем, А и В. АрмияА представлена двумя группировками, между которыми расположена армия В. Суммарно ресурсы Апревосходят ресурсы В, и, если обе группировки А ударят по В, то А победит.
Дело лишь за тем какдоговорится, чтобы обе группировки ударили одновременно. Имеется сложность – гонец от А долженпройти через территорию, контролируемую В. Пусть группировка №1 шлет гонца с донесением, в которомуказано время атаки. Вопрос, выслав гонца, может ли армия №1 выступать? Конечно, нет! Если гонец недоставил донесение, то атака будет отбита, ресурсы потрачены, и В победит. Выход из создавшегосяположения – дождаться гонца от армии №2 с подтверждением.
Пусть гонец от армии №2 прибыл. Можно линаступать? Опять нельзя! Не получив подтверждения, что гонец доставил подтверждение, армия №2 неможет выступить. Этот процесс ожидания подтверждений можно продолжать сколь угодно долго.Рисунок 6-13. Проблема двух армийВнимательно изучив проблему разрыва соединения, мы придем к выводу, что ни одна армия неначнет атаки до тех пор, пока не получит подтверждения на подтверждение, и так до бесконечности.
Насамом деле, можно доказать, что нет протокола, который безопасно разрешает эту ситуацию. На рисунке6-14 показаны четыре сценария разрыва соединения: нормальный случай с «тройным рукопожатием», спотерей последнего подтверждения, с потерей ответа и с потерей ответа и последующих данных. Обычноэту проблему решают, фиксируя число попыток разрыва. На практике поступаю так: если по соединениюбыла сделана попытка разрыва и не поступало никаких TPDU-пакетов в течении определенного времени,то соединение считается разорванным.Рисунок 6-14. Четыре сценария разрыва соединения: (а) Нормальный случайтрехкратного рукопожатия; (b) Потеря последнего ACK; (c) Потеря ответа; (d)Потеря ответа и последующих DR6.2.4.
Управление потоком и буферизацияТеперь, рассмотрев, как устанавливают соединение, обратимся к тому, как им управляют. Преждевсего, рассмотрим управление потоком. Проблема управления потоком на транспортном уровне в чем-тоаналогична проблеме управления потоком на канальном уровне. Различия в том, что у маршрутизаторачисло каналов невелико, в то время как на транспортном уровне соединений может быть очень много.Канальный протокол сохранял пакеты как на стороне отправителя, так и на стороне получателя дотех пор, пока они не будут подтверждены.
Если у нас есть 64 соединения и поле «время жизни» пакетазанимает 4 разряда, то нам потребуется суммарная емкость буферов на 1024 TPDU-пакетов. Числобуферов можно сократить, если есть информация о надежности сетевого уровня или о наличии буфера уполучателя. На транспортном уровне отправитель сохраняет все пакеты на случай, если какой-то из нихпридется посылать вторично. Если получатель знает об этом, то он может иметь лишь один пул буферовдля всех соединений, и, если пришел пакет и ему нет буфера в пуле, то он сбрасывается, в противномслучае сохраняется и подтверждается.Если сетевой уровень не надежный, то на транспортном уровне отправитель вынужден сохранять всеотправленные пакеты до тех пор, пока они не будут подтверждены.
При надежном сетевом сервисе,наоборот, отправителю нет нужды сохранять отправленные пакеты, если он уверен, что у получателявсегда есть буфер для сохранения полученного TPDU. Если такой уверенности нет, то ему придетсясохранять пакеты.Однако и в первом и во втором случае возникает проблема размера буфера. При фиксированнойдлине буфера естественно организовывать пул буферов одного размера. Однако при переменной длинепакетов проблема становится много сложнее.
Если размер буфера устанавливать по максимальной длинепакета, то мы столкнемся с проблемой фрагментации, т.е. неэффективного использования пространства.Если по минимальной длине, то один пакет придется пересылать как несколько, с дополнительныминакладными расходами. Можно установить схему динамического согласования размера буфера приустановлении соединения.Оптимальное соотношение между буферизацией на стороне отправителя или на стороне получателязависит от типа трафика. Для низкоскоростного, нерегулярного трафика буферизацию лучше делать наобоих концах. В общем случае вопрос о количестве буферов лучше всего решать динамически. Здесь надотолько позаботиться о решении проблемы потери управляющих пакетов.
При этом надо учитывать, чтодинамическое выделение буферов усложнит алгоритм скользящего окна. На рисунке 6-15 и в таблице6-16 показано управление окном в случае динамической буферизации в дейтаграммной сети с 4-битовымипорядковыми номерами.Другую проблему представляет согласование доступного числа буферов и пропускная способностьсетевого уровня. Дело в том, что пропускная способность транспортной среды между двумяопределенными хостами ограниченна.
Это ограничение вытекает из ограниченности числа путей междутранспортными агентами в сети и ограниченностью пропускной способности каждого маршрута. Если потокмежду ними превысит пропускную способность транспортной среды, то возникнет перегрузка. Этупроблему лучше всего решать динамически с помощью управляющих сообщений. Механизм управленияпотоком должен прежде всего учитывать пропускную способность подсети, а уже потом - возможностибуферизации. Располагаться этот механизм будет на стороне отправителя, чтобы предотвращатьнакопление большого числа неподтвержденных сообщений. В 1975 году Белснесом был предложеналгоритм скользящего окна, который следит за соответствием размера окна и пропускной способностиподсети, и, при необходимости, настраивает этот размер. Пропускная способность подсети заопределенный интревал времени может быть оценена по-разному. Например, как число подтвержденныхTPDU за такой интервал.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
