Полный курс лекций 2009-го года (1130357), страница 76
Текст из файла (страница 76)
В нашидни каналы достаточно надежные, так что актуальной остается вторая причина.На рисунке 6-26 дана иллюстрация перегрузок. Перегрузки возникают по двум причинам: нехваткабуфера на стороне получателя – недостаточная емкость получателя (а); перегрузка внутри сети –недостаточная емкость сети (b).Рисунок 6-26. Причины перегрузокВ Internet эти ситуации различаются как внутренняя емкость сети и емкость получателя.
Поэтомукаждый отправитель поддерживает два окна - обычное окно отправителя и окно перегрузки. Каждоепоказывает количество байтов, которое отправитель может послать. Фактически отправляемое количествобайтов - минимум из этих двух величин.Сначала окно перегрузки полагают равным размеру максимального сегмента для данногосоединения. Если сегмент успешно (без time_out) был передан, то окно перегрузки увеличивается вдвое.Это увеличение будет происходить до тех пор, пока либо не наступит time_out и произойдет возврат кпредыдущему значению, либо размер окна перегрузки не достигнет размера окна получателя. Этоталгоритм называется slow start - медленный старт.Другой параметр управления перегрузками в Internet – порог (threshold).
Алгоритм медленногостарта при возникновении перегрузки устанавливает этот параметр равным половине длины окнаперегрузки, а окно перегрузки - равным размеру максимального сегмента. Окно перегрузки растетэкспоненциально до тех пор, пока не сравняется с порогом, после чего оно растет линейно, пока недостигнет размера окна получателя. На этом рост прекращается до первой перегрузки.
Работа этогоалгоритма показана на рисунке 6-27.Рисунок 6-27. Алгоритм управления перегрузками в internet6.3.7. Управление таймером в TCPПротокол ТСР использует несколько таймеров для управления передачей. Наиболее важный из них таймер повторной передачи. Этот таймер устанавливают, когда отправляют сегмент. (Напомним, что такмы называем TPDU-пакет.) Если подтверждение пришло до исчерпания этого таймера, то егоостанавливают и сбрасывают. Если таймер исчерпан, то сегмент посылают повторно.Здесь основная проблема - как удачно выбрать величину time_out: временной интервал, поистечении которого сегмент надо передать повторно. Как мы знаем, эта проблема встречается и на другихуровнях.
Однако на транспортном уровне она имеет особенность, которая заключается в следующем. Наканальном уровне дисперсия величины задержки подтверждения имеет ярко выраженный максимум (см.рисунок 6-28 (a)). Другими словами, ее разброс невелик. Величину time_out на этом уровнеустанавливают чуть больше ожидаемой величины прихода подтверждения. На транспортном уровнефункция распределения величины задержки подтверждения имеет более пологую форму, чем наканальном уровне (см. рисунок 6-28 (b)).
Поэтому предсказать величину времени, которая нужна дляпередачи данных от источника до получателя и передачи подтверждения от получателя до источника,очень трудно. Заведомо эта величина не должна быть постоянной в силу гладкости функциираспределения.В основе используемого в протоколе ТСР алгоритма, предложенного Якобсоном в 1988 году, лежитспециальная переменная RTT для получения оптимального значения величины time_out (Round Trip Time),значение которой постоянно модифицируется. В этой переменной хранится наименьшее времяподтверждения.
При каждой передаче сегмента замеряется величина задержки подтверждения М. Если приочередной передаче подтверждение поступило прежде, чем наступил time_out, значение переменной RTTнемного уменьшают, в противном случае - увеличивают по формуле:RTT = l RTT + (1- l )M, где l = 0,87.Однако, даже зная величину RTT, определить величину ожидания оказалось непросто. Якобсонпредложил вычислять величину D - отклонения между ожидаемой величиной задержки и измеренной поформуле:D = l D + (1-l ) |RTT - M|.Кроме этого, Якобсон показал как, зная D, вычислить величину time_out по формуле:time_out = RTT + 4*D.Позднее Филл Карн (Phill Karn) модифицировал эту формулу для случая повторно передаваемыхсегментов. Действительно, когда поступает подтверждение для сегмента, то не ясно, то ли этоподтверждение для первой передачи, толи для последней.
Филла интересовал вопрос вычислениявеличины RTT для передачи данных по протоколам TCP/IP по КВ-радиоканалу. В результате экспериментовон показал, что для повторно передаваемых сегментов эффективно просто удваивать величину ожиданиядо тех пор, пока подтверждение не поступит с первого раза.Другой важный таймер в протоколе ТСР - таймер настойчивости. Он позволяет бороться соследующего типа тупиками. Когда получатель посылает сообщение с нулевым размером окна, отправительостанавливает передачу и ждет сообщения об изменении размера окна. Наконец, получатель послал такоесообщение, но оно было потеряно. Все ждут. Чтобы избежать такой ситуации, используют таймернастойчивости.
Если он исчерпан, то отправитель шлет сообщение получателю, напоминая ему о проблемеразмера буфера.Еще один важный таймер - таймер функционирования. Если по какой-либо причине по соединениюдолго не посылали сообщений, то надо проверить, функционирует ли оно. Когда этот таймер исчерпан, тосоответствующая сторона шлет другой стороне запрос: «Жива ли ты?» Если ответа не поступает, тосоединение считается разорванным.Рисунок 6-28. Дисперсия величины задержки подтверждения: (а) На канальномуровне; (b) На транспортном уровне (TCP)6.3.8. Протокол UDPInternet поддерживает также транспортный протокол без соединений - UDP.
Протокол UDP (UserDatagram Protocol) предназначен для обмена дейтаграммами между процессами компьютеров, входящих вединую сеть с коммутацией пакетов. В качестве протокола нижнего уровня UDP-протокол использует IP.Протокол UDP предоставляет прикладным программам возможность отправлять сообщения другимприложениям, используя минимальное количество параметров протокола. Этот протокол не обеспечиваетдостоверность доставки пакетов, защиты от дублирования данных или от сбоев в передаче. Заисключением параметров приложения - номеров портов отправителя и получателя пакета, UDPпрактически ничего не добавляет к IP-дейтаграмме.Рисунок 6-29.
Заголовок UDPПротокол UDP намного проще, чем TCP, и полезен в ситуациях, когда мощные механизмыобеспечения надежности протокола TCP не требуются или будут только помехой для решенияопределенного рода задач, например, аутентификации пользователей. Структура UDP-заголовка показанана рисунке 6-29.§Source Port (16 бит). Порт отправителя. Это поле может содержать номер порта, с которого былотправлен пакет, когда это имеет значение (например, когда отправитель ожидает ответа). Если это полене используется, оно заполняется нулями.§Destination Port (16 бит). Порт назначения - это порт компьютера, на который пакет будет доставлен.§Length (16 бит). Поле длины.
Длина (в байтах) этой дейтаграммы, включая заголовок и данные.(Минимальное значение этого поля равно 8).§Checksum (16 бит). Поле контрольной суммы. Контрольная сумма UDP-пакета представляет собойпобитное дополнение 16-битной суммы 16-битных слов (аналогично TCP). В вычислении участвуют:данные пакета, заголовок UDP-пакета, псевдозаголовок (информация от IP-протокола), полявыравнивания по 16-битной границе (нулевые).Преимущество протокола UDP состоит в том, что он требует минимум установок и параметров длясоединения двух процессов между собой.
Этот протокол используется при работе Серверов Доменов (NameServers), протокола TFTP (Trivial File Transfer), при работе с SNMP-протоколом и построении системаутентификации. Идентификатор UDP в IP-заголовке - число 17. Более подробное описание протокола UDPможно найти в RFC-768.6.3.9. TCP и UDP в беспроводных коммуникацияхТеоретически ТСР не должен зависеть от того, над какой средой он работает – оптической илибеспроводной. Однако на практике дело обстоит иначе. ТСР-протокол тщательно оптимизировали приразных предположениях, которые не выполняются в беспроводной среде.
Так, например, предполагалось,что сетевая среда достаточно надежна и рост числа time_out – это результат перегрузки, а не потерипакетов.В беспроводной среде потеря пакета - дело частое. Поэтому применение протокола ТСР «в лоб» спротоколом Якобсона медленного старта лишь усугубит положение. Так, например, если потерисоставляют 20%, то при пропускной способности канала в 100 пакетов в секунду фактически будем иметьлишь 80 пакетов. Согласно алгоритму медленного старта, при увеличении числа time_out надо понизитьскорость, скажем до 50 пакетов в секунду, что приведет к фактической скорости 40 пакетов.Поэтому, если увеличилось число отказов в обычном канале, надо сбросить скорость, а если эточисло возросло в беспроводной среде, надо не понижать скорость, а слать пакеты повторно.
Так что беззнаний о среде принять решение трудно.Основным источником проблем является то, что в беспроводной среде соединения частонеоднородные. На рисунке 6-30 показан пример. Была предложена модификация ТСР – разбить такоесоединение на два так, чтобы каждое стало однородным. Есть и другие решения, связанные смодификацией не самого ТСР, а канального уровня для базовых станций.Рисунок 6-30. Разбиение TCP-соединения на два6.4. Вопросы производительностиПроизводительность вычислительных сетей и машин один из основных показателей ихэффективности.
Сегодня настройка производительности сетей и систем больше искусство, чем наука.Многое из того, что здесь будет сказано – результат практики. Мы уже много внимания уделили вопросампроизводительности при рассмотрении, например, сетевого уровня. Однако вопросы производительностисети в целом, как системы, относятся к транспортному уровню и будут рассмотрены здесь.
В последующихпяти разделах мы рассмотрим пять основных аспектов производительности сетей:1.Проблемы производительности2.Измерение производительности3.Влияние организации сетей на производительность4.Быстрая обработка TPDU5.Протоколы для высокопроизводительных сетей6.4.1.
Проблемы производительности в сетяхОдна из таких причин – перегрузки из-за несбалансированности ресурсов и нагрузки. Если намаршрутизаторы наваливается больше нагрузки, чем они могут переработать, возникает перегрузка.Перегрузки были достаточно подробно рассмотрены ранее.Производительность может падать из-за структурной несбалансированности ресурсов. Например,если персональную машину подключить к гигабитному каналу, то она будет захлебываться от наплывапакетов из-за несбалансированности скорости процессора и скорости канала.Перегрузка может быть вызвана синхронно, как реакция на некоторые действия в сети. Это такназываемые синхронные перегрузки. Например, если сегмент TPDU содержит неверный параметр (номерпорта или процесса), то в ответ пойдет сообщение об ошибке.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
