tanenbaum_seti_all.pages (525408), страница 173
Текст из файла (страница 173)
Рассмотрим, к примеру, линях) длиной 4000 км, работающую со скоростью 1 Гбит/с. Время прохождения сиги ьча в оба конца равно 40 мс. За это время отправитель успевает передать 5 Мбайт. Если обнаруживается ошибка, потребуется 40 мс, чтобы оповестить об этом отправителя. При использовании протокола с возвратом на и отнрави гелю потребуется повторять передачу не только поврежденного пакета, но также и до 5 Мбайт пакетов, переданных после поврежденного. Очевидно, что этот протокол использует ресурсы очень неэффективно. Суть четвертой проблемы состоит в том, что гигабитныс линии принципиально отличаются от мегабитных — в длинных гигабитных линиях главным ограничивающим фактором является не пропускная способность, а задержка. На рис.
6.40 изображена зависимость времени, требующегося для передачи файла размером 1 Мбит по линии длиной в 4000 км, от скорости передачи. На скоростях до 1 Мбит/с время передачи, в основном, зависит от скорости передачи данных. При скорости 1 Гбит/с задержка в 40 мс значительно превосходит 1 мс (время, требующееся для передави битов по оптоволоконному кабелю). Дальнейшее увеличение скорости вообще не оказывает почти никакого действия на время передачи файла. Изображенная на рнс. 6.40 зависимость демонстрирует ограничения сетевых протоколов. Она показывает, что протоколы с ожиданием подтверждений, такие как удаленный вызов процедуры (КРС, Кстоге Ргоссг)цгс Са1!), имеют врожденное ограничение на производительность. Это ограничение связано со скоростью света.
Никакие технологические прорывы в области оптики здесь не помогут (хотя могли бы помочь новые законы физики). Пятая проблема, которую стоит упомянуть, связана нс с протоколами или технологиями, а с появлением новых гигабитных мультимелийных приложений, для которых постоянство времени передачи пакета так же важно, как и само среднее значение задержки. Низкая, но постоянная скорость доставки часто прсдпочтительнее высокой, но непостоянной. 650 Глава 6.
Транспортный уровень 1ООО с 1ОО с с чбг 10 о и 1с й 100мс ф 10мс 1 мс тбз 10к 1Ов 1Ов 10г 1Ов 10в 10га 10п тбм Скорость передачи (бит/с) Рис. б.40. Время передачи и подтверждения файла размером 1 Мбит по линии длиной 4000 км Перейдем теперь к рассмотрснию методов решения всего этого набора проблем. Сначала будет сделано несколько общих замечаний, затем мы рассмотрим механизмы протоколов, формат пакетов и программное обеспечение протоколов. Главный принцип, который каждый разработчик гигабитных сетей должен выучить наизусть, звучит так: Проектируя, стремись увеличить скорость, и не оптииизировить пропускную способность, При разработке старых протоколов обычно ставилась задача минимизировать количество битов, переданных в линию, часто за счет использования полей малого размера и упаковывания нескольких полей вместе в один байт или слово. В настоящее время экономить пропускную способность смысла нет: ее более чем достаточно.
Проблема заключается в обработке протоколами пакетов, поэтому при разработке новых протоколов минимизировать нужно именно время обработки. Разработчики 1рчб, к счастью, хорошо понимают это. Конечно, заманчивы попытки ускорить работу сетей, создав быстрые сетевыс интерфейсы на аппаратном уровне.
Сложность такого подхода состоит в том, что если только протокол не является чрезвычайно простым, аппаратный интерфейс представляет собой дополнительную плату с отдельным процессором и своей прогРаммой. Чтобы сетевой сопроцессор пе был столь же дорогим, он, как и центральный процессор, часто представляет собой более медленную микросхему. В результате такого подхода быстрый центральный процессор ждет, пока медленный сопроцессор выполнит свою работу. Было бы неверным полагать, что у центрального процессора на время ожидания обязательно найдется другая работа, Более того, для обцгения двух процессоров общего назначения потребуются тщательно продуманные протоколы, обеспечивающие их корректную синхронизацию.
Как правило, наилучший метод заключается в создании простых протоколов, чтобы всю работу мог выполнять центральный процессор. Вопросы производительности 651 Рассмотрим теперь вопрос обратной связи в высокоскоростных протоколах. Из-за относительно длинного цикла задержки желателен отказ от обратной связи: на оповеШение отправителя уходит слишком много времени, Один пример обратной связи — управление скоростью передачи с помощью протокола скользящего окна. Чтобы избежать долгих задержек, связанных с передачей получателем информации о состоянии окна отправителю, лучше использовать протокол, основанный на скорости.
В таком протоколе отправитель может посылать не быстрее, чем с некоторой скоростью, с которой получатель заранее согласился, Второй пример обратной связи — алгоритм затяжного пуска, разработанный Джекобсоном. Этот алгоритм проводит многочисленные пробы, пытаясь определить пропускную способность сети. В высокоскоростных сетях па проведение пяти-шести проб для определения отвстной реакции сети тратится огромное количество сетевых ресурсов. Более эффективная схема состоит в резервировании ресурсов отправителем, получателем и сетью в момснт установки соединения.
Кроме того, заблаговременное рсзервирование ресурсов позволяет несколько снизить эффект неравномерности доставки (джиттер). Короче говоря, повышение скоростей передачи в сетях неумолимо заставляет разработчиков выбирать ориентированную на соединение (нли близкую к этому) схему работы сети.
Крайне важен в гигабитных сетях формат пакета. В заголовке должно быть как можно мецыпе полей — это позволит снизить врсмя его обработки. Сами поля должны быть достаточно большими, чтобы нести в себе как можно больше полезной (служебной) информации. Кроме того, они не должны пересекать границы слов, тогда их будет проще обработать. В данном контексте под «достаточно большим» подразумевается такой размер, который исключает возникновение проблем зацикливания порядковых номеров при нахождении в сети старых пакетов, учитывает отсутствие у получателя возможности объявить реально доступный размер окна из-за слишком малого служебного поля размера окна, и т.
д. Кроме того, контрольные суммы заголовка и данных следует считать раздельно. Причин здесь две. Во-первых, чтобы предоставить возможность считать контрольную сумму только заголовка, без данных, что значительно быстрее. Во-вторых, чтобы иметь возможность убедиться в правильности заголовка, прежде чем начать копировать данные в пространство пользователя. Контрольную сумму данных лучше проверять во время копирования данных в пространство пользователя, но если заголовок неверен, то может оказаться, что будет производиться копирование не того процесса. Во избежание ненужного копирования необходимо считать контрольные суммы отдельно. Максимальный размер поля данных должен быть достаточно большим, чтобы обеспечить возможность эффективной работы сети дажс при наличии больших задержек.
Кроме того, чем больше размер поля данных, тем мсньшую долю в обшем потоке данных составляют заголовки. Вше одно полезное свойство протокола — возможность посылать нормальное количество данных вместе с запросом соединения. При этом можно сэкономить время одного запроса и ответа. Наконец, следует сказать несколько слов о программном обеспечении протокола. Следует сконцентрировать внимание на успешном варианте работы. Мно- 652 Глава 6.
Транспортный уровень гие старые протоколы были рассчитаны на работу в условиях плохих линий связи и особое внимание уделяли обработке ошибок (например, при потере пакета). Чтобы сделать протокол быстрее, разработчик должен, в первую очередь, постараться минимизировать время обработки в нормальном случае. Минимизация времени обработки в случае ошибок на линии должна быть на втором местс. Второй аспект, касающийся программного обеспечения, состоит в минимизации времени копирования. Как уже было сказано раисе, копирование данных часто Оказывастся Основным истОчником накладных расходов. В идеале, аппаратура должна отображать каждый приходящий пакет в память в виде нспрсрывного блока данных.
Затем программа должна скопировать этот пакет в буфер пользователя за одну операцию блочного копирования. В зависимости от принципа работы каша может быть желателен отказ от циклической организации копирования. Другими словами, чтобы скопировать 1024 слова, возможно, самым быстрым способом будет использование 1024 инструкций МОЧС подряд (или 1024 пар инструкций чтения и записи). Процедура копирования является столь критичной, что ее следует очень аккуратно писать вручную на ассемблере, если только нет возможности заставить компилятор произвести самый оптимальный код. Резюме Транспортный уровень — это ключ к пониманию многоуровневых протоколов. Он предоставляет различныс услуги, наиболее важной из которых является сквозной, надежный, ориентированный на соединение поток байтов от отправителя к получателю.
Доступ к нему предоставлястся при помощи сервисных примитивов, позволяющих устанавливать, использовать и разрывать соелинения. Транспортные протоколы должны обладать способностью управлять соединением в ненадежных сетях. Установка соединения осложняется возможностью существования дубликатов пакетов, которые могут появляться в самый неподходящий момент. Для борьбы с этими дубликатами при установке соединения применяется алгоритм «тройного рукопожатия». Разрыв соединения проще установки и, тем не менее, далеко нс тривиален из-за наличия проблемы двух армий.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
