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