Мы начнем изучение вопросов контроля перегрузки с трех ситуаций возникновения перегрузок в сети в порядке возрастания сложности. Для каждой ситуации мы выявим причину и укажем ее негативные последствия (невозможность полного использования ресурсов, ухудшение качества обслуживания). Сейчас мы не станем уделять внимание способам возможного реагирования на перегрузки или избежания их появления; нас будет интересовать, что происходит в сети при увеличении частоты
В предыдущих разделах мы рассмотрели общие принципы надежной передачи данных при существовании вероятности потерь пакетов, а также применение этих принципов в протоколе TCP. Как было показано, потери пакетов чаще всего обусловлены переполнением буферов маршрутизаторов при перегрузках в сети. Повторная передача пакетов является признаком перегрузки, однако не устраняет ее причину, которая заключается в том, что передающие стороны посылают слишком большое число
Несмотря tfa то что эта тема может показаться не столь увлекательной, как тема надежной передачи данных или контроля потока, она является весьма важной, поскольку процедура установления соединения способна в значительной степени увеличить время ожидания (например, при навигации в web). Итак, мы изучаем вопрос установления TCP-соединения. Пусть процесс, выполняющийся на одном хосте (клиент), желает инициировать соединение с процессом, выполняющимся на другом
Как говорилось ранее, на обоих хостах, между которыми установлено ТСР-соеди-нение, имеются приемные буферы. Протокол TCP помещает в приемные буферы байты, принятые без искажений и в правильном порядке. Приложение, связанное с TCP-соединением, считывает данные из приемного буфера в произвольные моменты времени, не зависящие от поступления новых данных. К примеру, приложение может быть занято выполнением трудоемких операций и обращаться к буферу со
Напоследок мы зададимся вопросом, к каким протоколам относится TCP: к GBN-или к SR-протоколам? Как мы знаем, в TCP используется общее квитирование, и для неискаженных сегментов, полученных с нарушением порядка следования, не формируются отдельные квитанции. Таким образом, передающей стороне TCP необходимо хранить лишь наименьший порядковый номер отправленного неподтвержденного байта SendBase и порядковый номер следующего передаваемого байта NextSeqNum (см. рис. 3.18 и
Одним из недостатков механизма повторной передачи с интервалами ожидания является то, что интервалы ожидания часто оказываются относительно долгими. При потере пакета передающая сторона вынуждена ждать истечения интервала ожидания для того, чтобы осуществить повторную передачу, тем самым увеличивая общую задержку. Здесь на помощь приходит механизм дублирования подтверждений, позволяющий передающей стороне обнаруживать потери пакетов до истечения интервала ожидания. Дублирующее подтверждение — это
Здесь мы рассмотрим несколько модификаций предыдущей модели, присутствующих в большинстве реализаций протокола TCP. Первая модификация заключается в изменении длительности интервала ожидания по его истечении. Мы знаем, что по истечении интервала ожидания TCP осуществляет повторную передачу неподтвержденного сегмента с наименьшим порядковым номером. При этом оказывается, что вместо расчета нового интервала ожидания с использованием значений EstimatedRTT и DevRTT (см. «Время оборота и
Итак, мы упрощенно олисали механизм, с помощью которого TCP осуществляет надежную передачу данных. Тем не менее оказывается, что даже такая простая модель не лишена некоторых нюансов. Сейчас мы рассмотрим несколько ситуаций и соответствующих режимов работы протокола TCP. Первую ситуацию иллюстрирует рис. 3.30, где хост А посылает один сегмент хосту В. Предположим, что сегмент имеет порядковый номер 92 и содержит 8
Протокол сетевого уровня IP предоставляет транспортному уровню службу ненадежной передачи данных. IP не дает гарантий относительно доставки дейтаграмм, сохранения порядка их следования и корректности информации. При перегрузке маршрутизаторов дейтаграммы могут быть потеряны, порядок их получения может отличаться от порядка отправки, и, кроме того, допускаются искажения битов (изменения значений с 0 на 1 и наоборот). Поскольку дейтаграммы являются средством передачи сегментов
Как определить величину временного интервала ожидания на основе значений EstimatedRTT и DevRTT? Очевидно, что интервал ожидания должен быть не меньше EstimatedRTT, поскольку в противном случае это приведет к лишним повторным передачам. Вместе с тем интервал ожидания не должен значительно превосходить значение EstimatedRTT: чем больше времени требуется на обнаружение факта потери пакета, тем большие задержки при передаче данных испытывает приложение. Таким
Все статьи из рубрики "Транспортный уровень" размещены на сайте Компьютерные сети и многоуровневая архитектура интернета (conlex.kz) в ознакомительных целях.
Уточнения, корректировки и обсуждения статей доступны под текстом статей, в комментариях.
Ответственность, за все изменения, внесённые в систему по советам данных статей, Вы берёте на себя.
Копирование данных статей, без указания ссылки на сайт первоисточника Компьютерные сети и многоуровневая архитектура интернета (conlex.kz), строго запрещено.