русс | укр

Языки программирования

ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование

Все о программировании


Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации

Параметры квитирования


Дата добавления: 2013-12-23; просмотров: 5907; Нарушение авторских прав


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

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

Существуют два подхода к организации процесса обмена положительными и отрицательными квитанциями: с простоями и с организацией "окна".

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

Рис. 2.5. Реализация квитирования с простоями приемника

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



Метод обмена квитанциями с простоями имеет один параметр - величину тайм-аута ожидания квитанции. При отправке очередного пакета взводится таймер ожидания квитанции и, если установленный тайм-аут истек, а квитанция не пришла, то пакет или квитанции считаются утерянными и организуется вторичная передача неподтвержденного пакета (рис. 2.6).

Рис. 2.6. Влияние тайм-аута на работу протокола

Величина тайм-аута - это основной параметр настройки протоколов, работающих в соответствии с алгоритмом простоев источника. Слишком маленькие значения тайм-аута могут вызвать нежелательное снижение пропускной способности. Это может произойти в большой составной сети, в которой работают перегруженные маршрутизаторы, медленно обрабатывающие потоки пакетов. Если задержки передачи пакетов превзойдут значение тайм-аута, то исходный узел будет повторно передавать пакеты, которые на самом деле не были потеряны, а просто слишком медленно шли до узла назначения.

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

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

Рассмотрим пример, иллюстрирующий возможное снижение пропускной способности сети NovellNetWare из-за слишком большого значения тайм-аута времени ожидания квитанций.

Клиент и сервер NetWare по умолчанию используют алгоритм квитирования с простоями при организации передачи файлов. Если на сервере и клиенте работает стек IPX/SPX, то протокол прикладного уровня NCP, отвечающий за файловый сервис, не использует для транспортировки своих сообщений протокол SPX, работающий с установлением соединения, а обращается непосредственно к протоколу IPX. Это делается для ускорения работы файлового сервиса, так как использование каждого дополнительного уровня в стеке протоколов снижает общую производительность стека.

Протокол IPX - это протокол дейтаграммного типа, который повторную передачу искаженных и утерянных пакетов не выполняет. В результате при утере или искажении данных в локальной сети, где на нижнем уровне также работают протоколы диаграммного типа (Ethernet, TokenRing и т.п.), повторная передача пакетов организуется только протоколом NCP, который работает по алгоритму квитирования с простоем источника. По умолчанию протокол NCP использует тайм-аут в 0.5 секунды, после истечения которого выполняется повторная передача пакета, на который не пришла квитанция.

Рассмотрим на примере, насколько может снизиться пропускная способность сети NetWare при значении тайм-аута в 0.5 секунды и уровне потерянных и искаженных пакетов всего в 3%.

На рисунке 2.7 показаны временные диаграммы передачи файла между сервером и клиентом в двух случаях - при идеально работающей сети, когда пакеты не искажаются и не теряются, и в сети с 3% уровнем утерянных и искаженных пакетов.

Пусть в обоих случаях между клиентом и сервером передается файл размером в 240 000 байт. Файл передается с помощью протокола IPX со служебным заголовком в 30 байт и протокола Ethernet с размером служебного заголовка в 26 байт (с учетом преамбулы). Размер служебного заголовка самого протокола NCP составляет 20 байт.

Пусть файл передается частями по 1000 байт. Всего для передачи файла потребуется 240 пакетов.

Размер кадра Ethernet, переносящего 1000 байт передаваемого файла, составит 1000+20+30+26 = 1076 байт или 8608 бит.

Размер квитанции NCP, которая подтверждает получение пакета, равен 10 байтам, что дает размер кадра Ethernet, переносящего квитанцию в 86 байт (вместе с преамбулой) или 688 бит.

Предположим, что время обработки одного пакета на клиентской стороне составляет 650 мкс, а на сервере - 50 мкс.

В этих условиях время одного цикла передачи очередной части файла в идеальной сети составит 860.8 + 68.8 +650 + 50 = 1629.6 мкс.

Общее время передачи файла в 240 000 байт составит при этом 240х1629.6 = 0.391 секунды, а эффективная пропускная способность сети - 240000/0.391 = 613810 байт/с или 4.92 Мб/c.

При потере (независимо от причины) 3% кадров Ethernet повторная передача кадра начинается только после истечения тайм-аута в 0.5 сек. Всего таких случаев за время передачи файла будет 240х0.03 = 7. Следовательно, время передачи файла возрастет на 7х0.5 = 3.5 сек, а общее время передачи файла составит 0.391 + 3.5 = 3.891 сек. Пропускная способность сети при этом становится равной 240000/3.891 = 61680 байт/c или 0.49 Мб/c.

Таким образом, при наличии в сети NetWare всего 3% потерянных или искаженных пакетов пропускная способность этой сети снижается в 10 раз.

Рис. 2.7. Влияние потерь пакетов на производительность сети

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

Рис. 2.8. Квитирование с передачей "неподтвержденных" пакетов

Количество пакетов, которые разрешается передавать таким образом, называется размером окна. Рисунок 2.9 иллюстрирует данный метод для размера окна в 8 пакетов.

Рис. 2.9. Обмен квитанциями в режиме окна

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

Алгоритм скользящего окна имеет два настраиваемых параметра - размер окна и время тайм-аута ожидания прихода квитанции. Оба параметра влияют на пропускную способность сети. В сетях с редкими искажениями и потерями пакетов целесообразно устанавливать большие значения окна и тайм-аута, в ненадежных сетях нужно работать с меньшими значениями, как окна, так и тайм-аута.

Многие протоколы используют механизм скользящего окна для повышения своей пропускной способности. К ним относятся такие популярные протоколы как LAP-B, LAP-D и LAP-M семейства HDLC, используемые в территориальных сетях, протокол V.42, работающий в современных модемах, протоколы SPX , TCP и многие протоколы прикладного уровня.

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

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

Особенностью протокола TCP является также адаптивное изменение величины окна. В подавляющем большинстве других протоколов размер окна устанавливается администратором и самим протоколом в процессе его работы не изменяется. Варьируя величину окна, можно повлиять на загрузку сети. Чем больше окно, тем большую порцию неподтвержденных данных можно послать в сеть. Если сеть не справляется с нагрузкой, то возникают очереди в промежуточных узлах-маршрутизаторах и в конечных узлах-компьютерах.

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

После приема квитанции с нулевым значением окна протокол-отправитель время от времени делает контрольные попытки продолжить обмен данными. Если протокол-приемник уже готов принимать информацию, то в ответ на контрольный запрос он посылает квитанцию с указанием ненулевого размера окна.

Другим проявлением перегрузки сети является переполнение буферов в маршрутизаторах. В таких случаях они могут централизовано изменить размер окна, посылая управляющие сообщения некоторым конечным узлам, что позволяет им дифференцированно управлять интенсивностью потока данных в разных частях сети.

2.1.7. Сравнение сетевых технологий по производительности: Ethernet, TokenRing, FDDI, 100VG-AnyLAN, FastEthernet, ATM

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

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

  • Перспективность протокола. Желательно иметь уверенность, что выбранный вами протокол не постигнет судьба протокола ARCnet (или близкого к нему стандарта 802.4), который при неплохих технических показателях сошел на нет из-за отсутствия поддержки со стороны большинства производителей коммуникационного оборудования. Перспективность протокола трудно прогнозировать, поэтому можно ориентироваться на фактор, рассматриваемый следующим.
  • Количество компаний, поддерживающий данный протокол. Для примера сравним два новых высокоскоростных протокола - FastEthernet и 100VG-AnyLAN. Если первый поддерживают практически все производители оборудования для локальных сетей (более 100 известных компаний), то протокол 100VG-AnyLAN поддерживают только 30 производителей. Поэтому риск при переходе на протокол 100VG-AnyLAN более велик, чем при переходе на протокол FastEthernet.
  • Отказоустойчивость протокола. Далеко не во все протоколы встроены процедуры тестирования корректности работы сети и автоматического восстановления работоспособности после отказов. Контроль доставки пакетов адресату и повторная передача искаженных и утраченных пакетов - это один из уровней отказоустойчивости, которым может обладать протокол. К сожалению, большая часть протоколов канального уровня локальных сетей не выполняет эти функции, а контролем работоспособности кабельной системы и аппаратуры, и автоматическим восстановлением работоспособности сети после отказов может похвастаться только протокол FDDI.
  • Стоимость оборудования, реализующего данный протокол. Этот фактор - один из главных, обеспечивших преобладание протокола Ethernet в локальных сетях и сдерживающих распространение технологии АТМ. Стоимость - немаловажный козырь в руках сторонников технологии FastEthernet, унаследовавшей от 10 Мб Ethernet'а простоту алгоритмов и, соответственно, минимальную стоимость среди всех протоколов локальных сетей.
  • Поддержка трафика реального времени. В связи с необходимостью передачи по одной и той же сети традиционного компьютерного трафика, слабо чувствительного к задержкам, и мультимедийного трафика - голоса, видеоданных и т.п., плохо переносящего задержки пакетов даже в несколько миллисекунд, от протокола может потребоваться способность приоритизации чувствительного к задержкам трафика, который представляет собой трафик реального времени. В этом отношении протоколы Ethernet и FastEthernet уступают своим конкурентам, так как они не различают классы трафика. Протоколы FDDI и 100VG-AnyLAN различают трафик двух классов - обычный и высокоприоритетный и передают приоритетные кадры в первую очередь. Наиболее совершенным в отношении поддержки разных типов трафика является протокол АТМ, который сегодня различает 5 типов трафика - от компьютерного с неизвестной пропускной способностью до голосового трафика с постоянной средней битовой скоростью.

Если же вернуться к проблеме выбора протокола канального уровня по критерию максимизации пропускной способности сети, то наиболее влияющими параметрами протокола в этом отношении будут следующие:

  • номинальная пропускная способность протокола (битовая скорость передачи кадра);
  • максимально допустимый размер поля данных кадра;
  • номинальное время доступа к среде передачи данных.

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

Однако это далеко не всегда верно. Результирующая пропускная способность сети складывается под влиянием многих параметров и часто наиболее значимым является размер поля данных кадра или же время доступа к среде. Для подтверждения этого явления приведем результаты экспериментального сравнения пропускной способности сети при использовании в ней протоколов Ethernet, TokenRing и FDDI, отличающихся как номинальной пропускной способностью, так и максимальным размером поля данных и номинальным времени доступа к среде.

Экспериментальная сеть состояла всего из двух узлов - клиентского компьютера и сервера, поэтому фактор ожидания доступа к среде из-за ее загрузки здесь не исследовался.

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

Исследовалось влияние на время реакции: номинальной пропускной способности, максимально допустимого размера поля данных кадра, номинального времени доступа к среде передачи данных.



<== предыдущая лекция | следующая лекция ==>
Время жизни пакета | Фактор номинального времени доступа к среде


Карта сайта Карта сайта укр


Уроки php mysql Программирование

Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские

Аппаратное и программное обеспечение Графика и компьютерная сфера Интегрированная геоинформационная система Интернет Компьютер Комплектующие компьютера Лекции Методы и средства измерений неэлектрических величин Обслуживание компьютерных и периферийных устройств Операционные системы Параллельное программирование Проектирование электронных средств Периферийные устройства Полезные ресурсы для программистов Программы для программистов Статьи для программистов Cтруктура и организация данных


 


Не нашли то, что искали? Google вам в помощь!

 
 

© life-prog.ru При использовании материалов прямая ссылка на сайт обязательна.

Генерация страницы за: 0.004 сек.