Полный курс лекций 2009-го года (1130357), страница 78
Текст из файла (страница 78)
Поэтому лучше избегать их.§Правило 7: Избегайте наступления time_out.Таймеры неизбежны в сетях. Однако использовать их надо очень аккуратно и минимизировать ихисчерпание (time_out), поскольку это влечет выполнение специальных действий. Поэтому установкатаймера требует тщательных измерений, а изменение начального значения надо делать осторожно ипостепенно.Рисунок 6-33.
Четыре контекстных переключателя при обработке пакета спомощью сетевого менеджера пространства пользователя6.4.4. Быстрая обработка TPDUВывод из вышесказанного один – основным препятствием для быстрой работы сети являетсяпрограммное обеспечение стека протоколов. Здесь мы рассмотрим некоторые способы ускорения работыэтого программного обеспечения.Затраты на обработку TPDU делятся на затраты на обработку каждого TPDU и затраты на обработкукаждого байта. Оба вида затрат могут и должны быть сокращены. Для ускорения обработки собственноTPDU можно использовать следующую идею. Основную долю TPDU-сегментов обрабатывают в режимеEstablished (см.
рисунок 6-23). Поэтому важно максимально ускорить обработку TPDU в этом режиме. Дляэтого надо уметь быстро различать этот нормальный случай от остальных специальных, например, разрывасоединения.Рассмотрим пример. Для простоты будем предполагать, что транспортный агент расположен в ядреоперационной системы (см. рисунок 6-34), хотя те же идеи применимы и для других случаев, например,когда транспортный агент является частью прикладного процесса или библиотечной функцией. На сторонеотправителя прикладной процесс через программное прерывание передает TPDU транспортному агенту вядре. Агент с помощью проверок определяет, во-первых, какой случай имеет место: нормальный –отправка TPDU или специальный – разрыв соединения, во-вторых, что оправляется регулярное TPDU, а неспециальное, и в-третьих, что окно получателя имеет достаточный размер.
Если все условия выполнены,то может быть запущен ускоренный процесс отправки.Рисунок 6-34. Быстрая обработка TDPUВ нормальной ситуации заголовки последовательных TPDU сегментов почти одинаковы. Чтобывоспользоваться преимуществом этого факта, транспортный агент сохраняет прототип заголовка у себяпри запуске процедуры быстрой обработки. Обычно это делается максимально быстро на регистровомбуфере.
Те поля TPDU, которые меняются, переписываются в буфере. Затем указатель на TPDU иуказатель на тело данных передаются сетевому агенту на сетевой уровень. Там может быть применена таже схема, после чего сетевой агент передаст пакет на канальный уровень.Рассмотрим, как эта идея работает в случае TCP/IP. На рисунке 6-35 (а) показан заголовок TPDU.Светлым тоном выделены поля, которые меняют свои значения от сегмента TPDU к сегменту TPDU.
Пятьслов прототипа TPDU копируются в буфер, вычисляется контрольная сумма, увеличивается порядковыйномер. IP-процедура, в свою очередь, копирует пять слов прототипа (см. рисунок 6-35 (b)) своегозаголовка, заполняя соответствующими данными поля «Identification» и «Checksum».Рисунок 6-35. (а) TCP-заголовок; (b) IP-заголовокТеперь рассмотрим, что происходит на стороне получателя (правая часть рисунка 6-34). Преждевсего, транспортный агент на стороне получателя должен найти запись о соединении для поступившегосегмента TPDU. Для TCP-протокола эта запись может храниться в хеш-таблице.
Ключом к этой таблицеможет служить информация о портах отправителя и получателя и их IP-адресах. Другой подход к поискузаписи о соединении предложил Кларк – использовать последнюю использованную. Как показалапрактика, эта эвристика работает хорошо.После этого выполняются проверки, чтобы убедиться, что мы имеем дело с нормальным случаем, т.е.нет попытки разрыва соединения, нет URGENT-флага, и т.п. Если мы в состоянии Established, данныекопируются приложению, при этом вычисляется контрольная сумма.
Если она правильная, токорректируется запись о соединении, формируется подтверждение о получении и посылаетсяотправителю.Описанная здесь в общих чертах схема носит название предвидения заголовка. Она используется вомногих реализациях.Две другие области ускорения – управление буферизацией и таймерами.
Основная идея ускоренияпри управлении буферизацией – избегать излишнего копирования. Управление таймерами состоит в том,что, хотя таймер устанавливается для каждого TPDU, срабатывает он лишь для немногих TPDU. Общаясхема, оптимизирующая работу с таймерами, заключается в следующем. Записи о таймерах связываются всписок. В очередном элементе списка указывают, сколько тактов от срабатывания предыдущего таймерадолжно пройти, чтобы сработал текущий. Поэтому, если есть три таймера, которые должны сработать вмоменты 3, 10 и 12, то список будет выглядеть, как 3, 7, 2 соответственно. При такой организациидостаточно корректировать при каждом такте не все таймеры, а только первую запись в списке.Другой прием, оптимизирующий работу с таймерами, называется колесо времени.
Он используетмассив (см. рисунок 6-36), длина которого пропорциональна максимальной длине временного интервала,который может возникнуть при работе. Каждый элемент в этом массиве соответствует одному такту часов.Рисунок 6-36. Колесо времени6.4.5. Протоколы для гигабитных сетейВ начале 90-х стали появляться гигабитные сети, т.е. коммуникационное оборудование, способноеработать на таких скоростях. Первой естественной реакцией специалистов было использовать на этомоборудовании те же протоколы, что и для обычных сетей.
Однако сразу возникло довольно многонеожиданных проблем. Здесь мы рассмотрим некоторые из них и направления для развития новыхпротоколов.Первая проблема – длина поля для последовательной нумерации. Например, 16- или 32-разрядныеполя для Ethernet 10 Мбит будут исчерпаны даже при нумерации каждого байта чуть менее чем за сутки.Здесь неявно предполагалось, что так долго пакет существовать в сети не может. При скорости 1 Гбит/сек.32-разрядный счетчик будет исчерпан за 32 сек.
Среднее время жизни пакета в Internet около 120 сек.Можно, конечно, нумеровать не каждый байт, как в протоколе TCP, а лишь пакеты, но это не намногооблегчит положение. Причина этой проблемы в том, что предположение о времени жизни пакета, верноеранее, теперь, при 1 Гбит/сек., не верно.Вторая проблема возникает из-за того, что скорость передачи растет быстрее производительностипроцессоров. В начале 70-х годов скорость передачи была порядка 56 Кбит/сек., быстродействиепроцессоров - 1 MIPS, размер пакета - 1 Кб. Это означает, что пакеты поступали со скоростью 56 пакетов всекунду, на обработку одного пакета отводилось 18 мсек.
или 18 000 команд процессора. Если оставлять50% производительности под приложение, то получим 9000 команд на обработку одного пакета, чтовесьма неплохо.В наши дни, при скоростях передачи 1 Гбит/сек., производительности процессора 100 MIPS, размерепакета 4 Кб, пакеты следуют со скоростью 30 000 в секунду, т.е. на обработку одного пакета остается неболее 15 мсек., если мы половину производительности хотим оставить для приложения. За 15 мсек.процессор со скоростью 100 MIPS успеет сделать 1500 команд.
При этом надо учитывать, чтофункционально команда RISC-процессора беднее команды CISC-процессора. Вывод: на работу сетевогопрограммного обеспечения остается все меньше времени, следовательно, протоколы должныстановиться проще! (Не забывайте каналы становятся надежнее.)Третья проблема состоит в том, что гигабитный канал принципиально отличается от мегабитного.Гигабитный канал более чувствителен к величине задержки, чем к скорости передачи. На рисунке 6-37показана зависимость времени передачи от скорости передачи для файла в 1 Мб на расстояние 4000 км.Там хорошо видно, что, начиная с гигабитных скоростей, увеличение пропускной способности не даетсущественного прироста в скорости передачи.
Поэтому протоколы старт-стопного типа, например, RPC,существенно будут ограничены в производительности на таких каналах. То же самое можно сказать опротоколах с откатами (они применяются, например, на канальном уровне, если часть пакетов впоследовательности была утеряна).
Откат увеличивает задержку в канале и увеличивает объем повторнопередаваемой информации.Рисунок 6-37. Зависимость времени передачи от скорости передачи для файла в1 Мб на расстояние 4000 кмЧетвертая проблема, о которой стоит упомянуть, - скорее проблема, вызванная новымиприложениями, чем проблема собственно протоколов. Это проблема приложений, для которых важно несреднее значение задержки, а минимальное отклонение от среднего, т.е. максимально равномерный потокданных. Примером таких приложений являются многие мультимедиа-приложения.Теперь рассмотрим, что означают гигабитные скорости для организации протоколов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
