Компьютерные сети

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

Читать далее »

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

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

Несмотря tfa то что эта тема может показаться не столь увлекательной, как тема надежной передачи данных или контроля потока, она является весьма важной, поскольку процедура установления соединения способна в значительной степени увеличить время ожидания (например, при навигации в web). Итак, мы изучаем вопрос установления TCP-соединения. Пусть процесс, выполняющийся на одном хосте (клиент), желает инициировать соединение с процессом, выполняющимся на другом хосте (с сервером). Сначала клиентское приложение уведомляет TCP-клиент о том, что необходимо установить TCP-соединение с сервером. ТСР-клиент инициирует TCP-соединение следующим образом.
Читать далее »

Как говорилось ранее, на обоих хостах, между которыми установлено ТСР-соеди-нение, имеются приемные буферы. Протокол TCP помещает в приемные буферы байты, принятые без искажений и в правильном порядке. Приложение, связанное с TCP-соединением, считывает данные из приемного буфера в произвольные моменты времени, не зависящие от поступления новых данных. К примеру, приложение может быть занято выполнением трудоемких операций и обращаться к буферу со значительными задержками. Если частота поступления данных в буфер превышает частоту их считывания приложением, то через некоторый интервал времени возникает угроза переполнения буфера.
Читать далее »

Напоследок мы зададимся вопросом, к каким протоколам относится TCP: к GBN-или к SR-протоколам? Как мы знаем, в TCP используется общее квитирование, и для неискаженных сегментов, полученных с нарушением порядка следования, не формируются отдельные квитанции. Таким образом, передающей стороне TCP необходимо хранить лишь наименьший порядковый номер отправленного неподтвержденного байта SendBase и порядковый номер следующего передаваемого байта NextSeqNum (см. рис. 3.18 и приведенный в начале этого подраздела фрагмент программы на псевдоязыке). Это создает видимость сходства TCP с GBN-протокола-ми; тем не менее между ними существуют важные различия. Первое различие заключается в том, что в реализациях TCP, как правило, предусмотрена буферизация пакетов, полученных с нарушением порядка следования. Далее, представим себе, что происходит, когда передающая сторона посылает последовательность сегментов 1, 2, N и все сегменты успешно принимаются приемной стороной в правильном порядке. Пусть квитанция для одного из сегментов с номером n < Утеряется, но оставшиеся N- 1 квитанций достигают передающей стороны до истечения интервала ожидания. В этом случае GBN-протокол осуществил бы повторную передачу не только пакета п, но и всех последующих пакетов (п + 1, я + 2,N). TCP, напротив, в худшем случае передает единственный сегмент п; более того, если квитанция для сегмента n + 1 принимается передающей стороной до истечения интервала ожидания, повторная передача сегмента п вообще не производится.
Читать далее »

Одним из недостатков механизма повторной передачи с интервалами ожидания является то, что интервалы ожидания часто оказываются относительно долгими. При потере пакета передающая сторона вынуждена ждать истечения интервала ожидания для того, чтобы осуществить повторную передачу, тем самым увеличивая общую задержку. Здесь на помощь приходит механизм дублирования подтверждений, позволяющий передающей стороне обнаруживать потери пакетов до истечения интервала ожидания. Дублирующее подтверждение — это копия положительной квитанции предыдущего сегмента, отправляемая в ответ на получение следующего сегмента, если порядковый номер последнего превышает ожидаемый. Чтобы понять реакцию передающей стороны на появление дублирующих подтверждений, сначала необходимо выяснить причину, побуждающую к использованию такого механизма. В табл. 3.3 приведены основные правила генерации квитанций принимающей стороной TCP. При получении сегмента, порядковый номер которого превышает ожидаемый, протокол регистрирует наличие недостающего сегмента. Появление недостающих сегментов может быть обусловлено потерей сегментов или нарушением порядка их следования при передаче по сети. Поскольку в TCP не поддерживается отрицательное квитирование, принимающая сторона не может явно указать на необходимость повторной передачи недостающих данных. Вместо этого она повторно отсылает подтверждение для последнего успешно принятого байта (обратите внимание на то, что таблица иллюстрирует ситуацию, когда принимающая сторона не игнорирует сегменты, нарушающие очередность).
Читать далее »

Здесь мы рассмотрим несколько модификаций предыдущей модели, присутствующих в большинстве реализаций протокола TCP. Первая модификация заключается в изменении длительности интервала ожидания по его истечении. Мы знаем, что по истечении интервала ожидания TCP осуществляет повторную передачу неподтвержденного сегмента с наименьшим порядковым номером. При этом оказывается, что вместо расчета нового интервала ожидания с использованием значений EstimatedRTT и DevRTT (см. «Время оборота и интервал ожидания» данного раздела) TCP удваивает текущее значение интервала ожидания. Пусть, например, при первом переполнении таймера было установлено время ожидания 0,75 с. Первая повторная передача сегмента будет происходить с таймером, установленным на 1,5 с. Если интервал ожидания вновь истечет, таймер будет установлен на 3 с, и т. д. Таким образом, увеличение интервала ожидания происходит экспоненциально при каждой новой повторной передаче. Однако, если запуск таймера происходит при наступлении одного из двух других событий (получения данных от верхнего уровня или квитанции), длительность интервала ожидания рассчитывается обычным способом — при помощи величин EstimatedRTT и DevRTT.
Читать далее »

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

□ Сложность сообщений. Как мы видели, алгоритм, основанный на состоянии линий, требует от каждого узла знания стоимости каждой линии сети. Для этого необходимо отправить 0(пЕ) сообщений, где п представляет собой количество узлов сети, а Е — число линий. Кроме того, каждый раз, когда стоимость линии изменяется, об этом следует известить все узлы. Дистанционно-векторный алгоритм требует обмена сообщениями только между напрямую соединенными узлами на каждой итерации. Как было показано, время, необходимое для схождения алгоритма, может зависеть от многих факторов. Когда изменяется стоимость линии, дистанционно-векторный алгоритм распространяет результаты только в том случае, если это изменение приводит к изменению пути с наименьшей стоимостью для одного из узлов, присоединенного к этой линии.
□ Скорость схождения. Как мы видели, количество вычислений в нашей реализации алгоритма, основанного на состоянии линий, растет пропорционально квадрату узлов сети, требуя передачи 0(пЕ) сообщений. Дистанционно-векторный алгоритм может сходиться медленно (в зависимости от относительной стоимости путей, как было показано в примере на рис. 4.10), и во время схождения могут образовываться маршрутные петли. Кроме того, дистанционно-векторный алгоритм страдает от «приступов» счета до бесконечности.
□ Живучесть. Что может случиться, если маршрутизатор выйдет из строя, «сойдет с ума» или объявит забастовку? В алгоритме маршрутизации, основанном на состоянии линий, маршрутизатор может передать всем остальным маршрутизаторам неверные сведения о стоимости одной из присоединенных к нему линий. Узел может также повредить или потерять один из широковещательных пакетов LS-алгоритма, который он получил. Но узел рассчитывает только собственную таблицу продвижения данных. Остальные узлы сами вычисляют свои таблицы. Это означает, что в алгоритме, основанном на состоянии линий, расчеты маршрутов выполняются в значительной степени раздельно, что предоставляет определенную степень живучести. В случае дистанционно-векторного алгоритма узел может передать другим узлам неверно сосчитанные им значения минимальной стоимости путей. (Такие ситуации встречаются на практике. В 1997 году неисправный маршрутизатор, принадлежащий небольшой компании, занимающейся предоставлением доступа в Интернет, снабжал маршрутизаторы национальной магистрали ошибочной информацией о маршрутах. Это привело к тому, что другие маршрутизаторы завалили трафиком неисправный маршрутизатор, в результате большие фрагменты Интернета в течение нескольких часов были отрезаны.) Обратите внимание, что в дистанционно-векторном алгоритме на каждой итерации результаты вычислений узла непосредственно передаются соседнему узлу, а затем на следующей итерации они попадают к соседу соседа и т. д. Таким образом, в дистанционно-векторном алгоритме некорректно вычисленные данные могут распространиться по всей сети.
Читать далее »

Итак, мы упрощенно олисали механизм, с помощью которого TCP осуществляет надежную передачу данных. Тем не менее оказывается, что даже такая простая модель не лишена некоторых нюансов. Сейчас мы рассмотрим несколько ситуаций и соответствующих режимов работы протокола TCP. Первую ситуацию иллюстрирует рис. 3.30, где хост А посылает один сегмент хосту В. Предположим, что сегмент имеет порядковый номер 92 и содержит 8 байт данных. После передачи этого сегмента хост А ожидает от хоста В сегмент с номером подтверждения 100. Положим, что сегмент, посланный хостом А, успешно получен, а сегмент хоста В оказывается потерянным. В этом случае происходит истечение интервала ожидания, и хост А отправляет свой сегмент повторно. Хост В получает этот сегмент и по его порядковому номеру выясняет, что такой сегмент им уже принят. Это приводит к удалению повторно переданного сегмента.
Читать далее »