Рис. 6.48. Передача половины мегабита из Сан-Диего в Бостон: а — в момент времени t = 0; б — через 500 мкс; в — через 20 мс; г — через 40 мс
Отсюда следует, что для эффективного использования канала размер окна получателя должен быть, по меньшей мере, равен произведению пропускной способности и времени задержки, а лучше превосходить его, так как получатель может сразу и не ответить. Для трансконтинентальной гигабитной линии каждому соединению потребуется, по меньшей мере, по 5 Мбайт.
Третья проблема, связанная с предыдущей, состоит в том, что простые схемы повторной передачи, такие как протокол с возвращением на N блоков, плохо работают в линиях с большим значением произведения пропускной способности на задержку. Рассмотрим трансконтинентальную линию, работающую со скоростью 1 Гбит/с. Время прохождения сигнала в оба конца равно 40 мс. За это время отправитель успевает передать 5 Мбайт. Если обнаруживается ошибка, потребуется 40 мс, чтобы оповестить об этом отправителя. При использовании протокола с возвращением на N блоков отправителю потребуется повторять передачу не только поврежденного пакета, но также и до 5 Мбайт пакетов, переданных после поврежденного. Очевидно, что этот протокол использует ресурсы очень неэффективно. Поэтому необходимы более сложные механизмы, такие как метод выборочного повтора.
Суть четвертой проблемы состоит в том, что гигабитные линии принципиально отличаются от мегабитных — в длинных гигабитных линиях главным ограничивающим фактором является не пропускная способность, а задержка. На рис. 6.49 изображена зависимость времени, требующегося для передачи файла размером 1 Мбит по линии длиной в 4000 км, от скорости передачи. На скоростях до 1 Мбит/с время передачи
в основном зависит от скорости передачи данных. При скорости 1 Гбит/с задержка в 40 мс значительно превосходит 1 мс (время, требующееся для передачи битов по оптоволоконному кабелю). Дальнейшее увеличение скорости вообще не оказывает на время передачи файла почти никакого действия.
Рис. 6.49. Время передачи и подтверждения файла размером 1 Мбит по линии длиной 4000 км
Изображенная на рис. 6.49 зависимость демонстрирует ограничения сетевых протоколов. Она показывает, что протоколы с ожиданием подтверждений, такие как удаленный вызов процедур (RPC, Remote Procedure Call), имеют врожденное ограничение на производительность. Это ограничение связано со скоростью света. Никакие технологические прорывы в области оптики здесь не помогут (хотя могли бы помочь новые законы физики). Если в периоды времени, пока хост ждет ответа, гигабитная линия будет простаивать, она будет ничем не лучше простой мегабитной линии, а только дороже.
Пятая проблема заключается в том, что скорости передачи данных увеличиваются значительно быстрее, чем скорости обработки данных. (Обращение к разработчикам компьютеров: идите и побейте разработчиков средств связи! Мы рассчитываем на вас.) В 70-е годы объединенная сеть ARPANET работала на скорости 56 Кбит/с и состояла из компьютеров с производительностью около 1 MIPS (1 млн инструкций в секунду). Сравните эти цифры с цифрами для современных компьютеров, имеющих производительность 1000 MIPS и обменивающихся пакетами по гигабитной линии. Число инструкций на один байт уменьшилось более, чем в десять раз. Точные цифры зависят от времени и конкретной ситуации, но в итоге можно сказать следующее: у протокола осталось меньше времени на обработку пакетов, поэтому протоколы должны стать проще.
Перейдем теперь к рассмотрению методов решения всего этого набора проблем. Главный принцип, который каждый разработчик высокоскоростных сетей должен выучить наизусть, звучит так:
Проектируя, стремись увеличить скорость, а не оптимизировать пропускную способность.
При разработке старых протоколов обычно ставилась задача минимизировать количество битов, переданных в линию, часто за счет использования полей малого размера и упаковывания нескольких полей вместе в один байт или слово. В настоящее время экономить пропускную способность смысла нет: ее более чем достаточно. Проблема заключается в обработке протоколами пакетов, поэтому при разработке новых протоколов минимизировать нужно именно время обработки. Разработчики IPv6, к счастью, хорошо понимают это.
Конечно, заманчивы попытки ускорить работу сетей, создав быстрые сетевые интерфейсы на аппаратном уровне. Сложность такого подхода состоит в том, что если только протокол не является чрезвычайно простым, аппаратный интерфейс представляет собой дополнительную плату с отдельным процессором и своей программой. Чтобы сетевой сопроцессор не был столь же дорогим, как и центральный процессор, он часто представляет собой более медленную микросхему. В результате такого подхода быстрый центральный процессор ждет, пока медленный сопроцессор выполнит свою работу. Было бы неверным полагать, что у центрального процессора на время ожидания обязательно найдется другая работа. Более того, для общения двух процессоров общего назначения потребуются тщательно продуманные протоколы, обеспечивающие их корректную синхронизацию. Как правило, наилучший метод заключается в создании простых протоколов, чтобы всю работу мог выполнять центральный процессор.
Крайне важен в гигабитных сетях формат пакета. В заголовке должно быть как можно меньше полей — это позволит снизить время его обработки. Сами поля должны быть достаточно большими, чтобы нести в себе как можно больше полезной (служебной) информации. Кроме того, они не должны пересекать границы слов, тогда их будет проще обработать. В данном контексте под «достаточно большим» подразумевается такой размер, который исключает возникновение проблем зацикливания порядковых номеров при нахождении в сети старых пакетов, учитывает отсутствие у получателя возможности объявить реально доступный размер окна из-за слишком малого служебного поля размера окна и т. д.
Максимальный размер поля данных должен быть достаточно большим, чтобы снизить накладные расходы, возникающие за счет программного обеспечения, и обеспечить возможность эффективной работы сети. Размер пакета 1500 байт слишком мал для гигабитных сетей, поэтому гигабитная сеть Ethernet позволяет передавать сверхдлинные кадры размером до 9 Кбайт, а IPv6 поддерживает джамбограммы размером более 64 Кбайт.
Рассмотрим теперь вопрос обратной связи в высокоскоростных протоколах. Из-за относительно длинного цикла задержки желателен отказ от обратной связи: на оповещение отправителя уходит слишком много времени. Один пример обратной связи — управление скоростью передачи с помощью протокола скользящего окна. Чтобы избежать долгих задержек, связанных с передачей получателем информации о состоянии окна отправителю, лучше использовать протокол, основанный на скорости. В таком протоколе отправитель может посылать не быстрее, чем с некоторой скоростью, с которой получатель заранее согласился.
Второй пример обратной связи — алгоритм медленного старта, разработанный Джекобсоном. Этот алгоритм проводит многочисленные пробы, пытаясь определить пропускную способность сети. В высокоскоростных сетях на проведение пяти-шести проб для определения ответной реакции сети тратится огромное количество сетевых ресурсов. Более эффективная схема состоит в резервировании ресурсов отправителем, получателем и сетью в момент установки соединения. Кроме того, заблаговременное резервирование ресурсов позволяет несколько снизить эффект неравномерности доставки (джиттер). Короче говоря, повышение скоростей передачи в сетях неумолимо заставляет разработчиков выбирать ориентированную на соединение (или близкую к этому) схему работы сети.
Еще одно полезное свойство протокола — возможность посылать нормальное количество данных вместе с запросом соединения. При этом можно сэкономить время одного запроса и ответа.
6.7. Сети, устойчивые к задержкам
Последний раздел мы посвятим новому виду транспорта, который, возможно, когда-нибудь станет важной частью Интернета. TCP и большинство других транспортных протоколов исходят из предположения о том, что между отправителем и получателем постоянно существует рабочий путь; в противном случае протокол дает сбой, и пакеты не доставляются. В некоторых сетях сквозной путь часто отсутствует. В качестве примера можно привести космическую сеть, в которой спутники LEO (Low-Earth Orbit, низкая околоземная орбита) попеременно находятся в зоне и вне зоны досягаемости наземных станций. Каждый конкретный спутник может установить связь с данной наземной станцией только в определенное время, а два спутника никогда не могут установить связь друг с другом даже через наземную станцию, так как один из них всегда находится вне зоны досягаемости этой станции. Другие примеры касаются подводных лодок, автобусов, мобильных телефонов и других устройств, оснащенных компьютерами, для которых связь является непостоянной из-за перемещений или экстремальных условий.
