Tcp проверка ошибок

30.12.2019GATE CS, Компьютерные сети

Контроль ошибок

TCP — достоверный протокол транспортного уровня. Это означает, что прикладная программа доставляет поток данных к TCP, к прикладной программе на другом конце в порядке, без ошибок и без потери любой части или дублирования.

TCP обеспечивает достоверность, используя контроль ошибок. Контроль ошибок включает в себя механизмы обнаружения:

• искаженных сегментов;
• потери сегментов, нарушения порядка следования сегментов;
• дублирования сегментов.

Контроль ошибок также включает механизм для коррекции ошибок, после того как они обнаружены.

Обнаружение и коррекция ошибок

Обнаружение ошибок в TCP достигается с помощью использования трех простых инструментов: контрольной суммы, подтверждения и контроля по времени (time-out). Каждый сегмент включает в себя поле контрольной суммы, которое используется для проверки искаженности сегмента. Если сегмент искажен, он удаляется пунктом назначения TCP. TCP применяет метод подтверждения для получения сведений о том, что сегмент достиг пункта назначения неискаженным. Отрицательное подтверждение не используется в TCP. Если сегмент не подтвержден, прежде чем окончится контрольное время, это считается признаком искажения или потери и сегмент будет передан повторно.

Искаженный сегмент

Рис. 10.10 показывает прибытие искаженного сегмента на пункт назначения.

В этом примере источник посылает сегменты с 1 до 3, каждый по 200 байт. Последовательность номеров начинается с 1201 в сегменте 1.

TCP приемника принимает сегменты 1 и 2 , используя контрольную сумму, находит, что они свободны от ошибок. Он подтверждает принятие сегментов 1 и 2, используя номер 1 601, который означает, что получены нормально и неискаженно байты 1201 до 1600 и ожидается получения байта 1601. Однако он нашел, что сегмент 3 искажен, и удаляет сегмент 3. Заметим, что, хотя он получил байты 1601 до 1800 в сегменте 3, пункт назначения не считает его полученным, потому что этот сегмент искажен. После того как сработает счетчик времени для сегмента 3, источник TCP передаст повторно сегмент 3. После получения сегмента 3 пункт назначения посылает подтверждение для байта 1801, которое указывает, что он получил байты от 1201 до 1800 неповрежденными и в пределах заданного времени.

Потеря сегмента

Рис. 10.11. показывает случай потери сегмента. Ситуация точно та же, как и при искаженном сегменте. Другими словами, от точки источника и до пункта назначения действия при потере сегмента те же, что и при его искажении. Разница в том, что искаженный сегмент удаляется конечным пунктом назначения; потерянный сегмент удаляется любым промежуточным узлом и не достигает конечного пункта.

Дублированный сегмент

Дублированный сегмент, например, может быть создан источником TCP, когда до окончания контрольного времени не прибыло подтверждение. Обработка дублированного сегмента — простой процесс для пункта назначения TCP. Пункт назначения TCP ждет продолжения потока байт. Когда прибывает пакет, который содержит тот же порядковый номер, что и другой полученный сегмент, пункт назначения удаляет пакет.

Сегмент с нарушением порядка

TCP использует услуги IP, протокола сетевого уровня, не обеспечивающего достоверности, не ориентированного на соединение. TCP-сегмент инкапсулируется в IP-дейтаграмму. Каждая дейтаграмма — независимая единица. Маршрутизаторы могут послать каждую дейтаграмму по любому маршруту, найденному ими по ситуации. Одна дейтаграмма может следовать маршрутом с короткой задержкой; другая может следовать маршрутом с длительной задержкой. Если дейтаграмма прибывает с нарушением порядка, сегменты TCP, которые инкапсулированы в дейтаграмме, с высокой степенью вероятности будут в беспорядке.

Обработка сегментов с нарушением порядка пунктом назначения очень проста: он не подтверждает сегмент с нарушением порядка, пока не примет все сегменты, которые предшествуют ему. Конечно, если подтверждение задержано, в TCP-источнике может закончиться контрольное время и сегмент может быть выслан повторно. Дубликат затем будет удален пунктом назначения.

Потеря подтверждения

Рис. 10.12. показывает потерю подтверждения, которое посылается пунктом назначения. Потеря подтверждения может быть даже не замечена источником TCP. TCP использует систему накопленного подтверждения. Каждое подтверждение относится ко всей предыдущей информации, до последнего переданного байта.

Например, если пункт назначения посылает подтверждение (ACK) сегмента с номером подтверждения 1801, это предполагает, что байты с 1201 до 1800 приняты. Если конечный пункт предварительно посылал подтверждение для байта 1601 и оно потеряно, то эта потеря подтверждения не учитывается.

TCP — надежный протокол транспортного уровня. Это означает, что после того, как программа прикладного уровня доставит поток данных в TCP, она должна полагаться на TCP, чтобы доставить весь поток данных в приложение на другом конце, и это в порядке, без ошибок и без потери какой-либо части или повторяется.

TCP использует контроль ошибок для обеспечения надежности. Контроль ошибок включает в себя следующие механизмы: обнаружение и повторная передача поврежденных сегментов, повторная передача потерянных сегментов, сохранение сегментов, прибывающих не по порядку, до истечения срока действия отсутствующих пакетов, а также обнаружение и отбрасывание сегментов дублированных пакетов. TCP использует три простых инструмента для контроля ошибок: контрольную сумму, подтверждение и тайм-аут.

Контрольная сумма

Каждое сообщение содержит поле контрольной суммы, чтобы проверить, не поврежден ли сегмент сообщения. Если обнаруживается, что сегмент сообщения поврежден из-за неверной контрольной суммы, он будет отброшен TCP конечной точки и считается потерянным. TCP требует, чтобы каждый сегмент использовал 16-битную контрольную сумму.

подтверждать

         TCP использует подтверждения для подтверждения получения сегмента. Сегмент управления не несет данных, но он должен потреблять порядковый номер, и его также необходимо подтверждать, в то время как сегмент ACK не требует подтверждения [сегмент ACK не использует порядковые номера и не требует подтверждения] .

Раньше TCP использовал только один тип подтверждения: накопленное подтверждение. В настоящее время некоторые реализации TCP также используют подтверждение выбора.

Подтверждение накопления (ACK)

       Первоначальная конструкция TCP заключается в накоплении и подтверждении полученных сегментов сообщения. Получатель объявляет порядковый номер следующего байта, который он ожидает получить, и игнорирует все сегменты, которые прибывают не по порядку и сохраняются. Иногда это называется подтверждением положительного накопления или ACK. Слово «утвердительный» означает, что для отброшенных, потерянных или повторяющихся сегментов не предоставляется никакой обратной связи. 32-битное поле ACK в заголовке TCP используется для накопления подтверждений, и его значение действительно только тогда, когда флаг ACK равен 1.

Подтверждение выбора (SACK)

       Теперь все больше и больше реализаций добавляют еще один тип подтверждения, называемый выборочным подтверждением или SACK. SACK не заменяет ACK, но сообщает отправителю дополнительную информацию. SACK должен сообщать о внепоследовательных блоках данных и повторяющихся блоках сегментов сообщения (т. Е. Полученных более одного раза). Однако нет места для добавления такой информации в заголовок TCP, поэтому SACK реализован как опция в конце заголовка TCP.

Создать подтверждение

       Когда появился ресивер? При разработке TCP было определено несколько правил, которые используются во многих реализациях. Здесь мы приводим некоторые из наиболее часто используемых правил. Порядок этих правил не указывает на их важность.

1. Когда конец A отправляет сегмент сообщения данных на конец B, он должен включать (совмещать) подтверждение, которое дает следующий порядковый номер, который конец A ожидает получить. Это правило уменьшает количество требуемых сегментов и, следовательно, уменьшает объем связи.

2. Если у получателя нет данных для отправки, но он получает сегмент сообщения, который поступает по порядку (ожидаемый порядковый номер), и предыдущий сегмент сообщения был подтвержден, тогда получатель откладывает отправку подтверждающего сообщения до следующего сегмента. прибывает, или прошел период времени (обычно 500 мс). Другими словами, если только один сегмент, поступающий последовательно, не был подтвержден, получатель должен отложить отправку сегмента подтверждения. Это правило также уменьшает объем обмена данными в сегменте ACK.

3. Когда прибывает сегмент с ожидаемым порядковым номером, а предыдущий сегмент, который прибыл в последовательности, не подтвержден, получатель должен немедленно отправить сегмент ACK. Другими словами, в любой момент может быть не более двух поступающих последовательно сегментов, которые не были подтверждены. Это позволяет избежать ненужных повторных передач, которые могут вызвать перегрузку сети.

4. Когда приходит сегмент вне очереди с порядковым номером, превышающим ожидаемый порядковый номер, получатель немедленно отправляет сегмент ACK и объявляет следующий ожидаемый порядковый номер сегмента. Это приведет к быстрой повторной передаче потерянных сегментов.

5. При поступлении недостающего сегмента получатель должен отправить сегмент ACK и объявить следующий ожидаемый порядковый номер. Это сообщает получателю, что сегмент, о котором было сообщено, как отсутствующий, был получен.

6. Если достигается повторяющийся сегмент, получатель отбрасывает сегмент, но должен немедленно отправить подтверждение с указанием следующего ожидаемого сегмента. Это решает некоторые проблемы, вызванные потерей самого сегмента ACK.

Повторная передача

         Ядром механизма контроля ошибок является повторная передача сегментов сообщения. Когда сегмент сообщения отправлен, он будет храниться в очереди, пока не будет подтвержден. Когда таймер повторной передачи истекает или отправитель получает три повторных ACK для первого сегмента в очереди, этот сегмент передается повторно.

Повторная передача после RTO

       TCP отправителя устанавливает таймер времени ожидания повторной передачи (RTO) для каждого соединения. Когда таймер истекает (то есть истекает), TCP отправляет первый сегмент в очереди (то есть сегмент с наименьшим порядковым номером) и перезапускает таймер. Обратите внимание, что здесь мы снова предполагаем, что S (f) <S (n). Эту версию TCP иногда называют Tahoe. Как мы увидим позже, значение RTO в TCP является динамическим и обновляется в соответствии с временем приема-передачи (RTT) сегмента. RTT — это время, необходимое для того, чтобы сегмент достиг конца и получил свое подтверждение.

Повторная передача после трех повторных сегментов ACK

       Если значение RTO не очень велико, достаточно описанных ранее правил повторной передачи сегмента. Однако, если отправителю разрешено ретранслировать быстрее, не дожидаясь истечения срока действия счетчика, это будет в большей степени способствовать пропускной способности сети.Поэтому большинство текущих реализаций соблюдают три повторных ACK и немедленно повторно передают потерянный сегмент. Правило. Эта функция называется быстрой повторной передачей, а версия TCP, использующая эту функцию, называется Reno. В этой версии, если для определенного сегмента поступают три повторных подтверждения (то есть исходный ACK плюс три идентичных копии), следующий сегмент будет повторно передан немедленно, без ожидания тайм-аута.

Сегмент вне последовательности

  Текущая реализация TCP не отбрасывает сегменты сообщения вне очереди, но временно сохраняет эти сегменты сообщения и помечает их как сегменты сообщения вне очереди, пока не появятся недостающие сегменты сообщения. Обратите внимание, однако, что TCP никогда не доставляет процессу сегменты вне последовательности. TCP гарантирует, что данные должны быть доставлены процессу в порядке.

Передача данных TCP FSM (конечный автомат)

  Передача данных TCP близка к выбору протокола ретрансляции, и в то же время немного похожа на GBN. Поскольку TCP принимает сегменты, которые поступают не по порядку, его поведение можно рассматривать как протокол SR, но поскольку его первоначальный механизм подтверждения является кумулятивным, это снова делает его похожим на GBN. Однако если SACK используется в реализации TCP, то он ближе к SR. Наиболее подходящей моделью для TCP является выбор протокола повторной передачи.

Отправитель FSM

       Воспользуемся упрощенным автоматом для описания отправителя протокола TCP. Этот конечный автомат аналогичен тому, что мы обсуждали для протокола SR, но с некоторыми изменениями, специально предназначенными для TCP. Мы предполагаем, что коммуникация состоит из одного элемента, и сегмент сообщения использует ACK для подтверждения. На данный момент мы также проигнорировали вопросы подтверждения выбора и контроля перегрузки. На следующем рисунке изображен упрощенный конечный автомат отправителя TCP. Обратите внимание, что этот конечный автомат является только самым основным. Он не включает такие проблемы, как синдром запутанного окна (алгоритм Нэгла) и закрытие окна. Поскольку он определяет одностороннюю связь, он также игнорирует весь контент, связанный с двусторонней связью.

Есть некоторые различия между FSM выше и FSM в обсуждаемом нами протоколе SR. Одно из отличий — это быстрая повторная передача (три повторяющихся правила ACK), а другое отличие состоит в том, что размер окна должен быть отрегулирован в соответствии со значением rwnd (на данный момент проблема контроля перегрузки игнорируется).

Приемник FSM

      Давайте использовать упрощенный конечный автомат для описания принимающей стороны протокола TCP. Этот конечный автомат похож на конечный автомат обсуждаемого нами протокола SR. Есть только некоторые модификации специально для TCP. Мы предполагаем, что связь является односторонней, и сегмент сообщения использует ACK для подтверждения. Здесь мы также игнорируем вопросы подтверждения выбора и контроля перегрузки. На следующем рисунке изображен упрощенный конечный автомат приемника TCP. Обратите внимание, что мы проигнорировали такие проблемы, как синдром запутанного окна (алгоритм Кларка) и закрытие окон.

Точно так же есть некоторые различия между этим автоматом и автоматом в соглашении SR, которое мы обсуждали. Одно из отличий — технология задержки ACK для односторонней связи. Другое отличие состоит в том, что ACK отправляется повторно, чтобы отправитель мог реализовать стратегию быстрой повторной передачи.

Мы также должны подчеркнуть, что автомат приемника не так прост, как протокол SR в двусторонней связи. Нам необходимо рассмотреть некоторые другие стратегии, например, когда получатель имеет данные для возврата, он должен отправить своевременный ACK.

Например

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

Нормальная операция

       Первый случай — двусторонняя передача данных между двумя системами.Как показано на рисунке ниже, клиентский TCP отправляет один сегмент, а сервисный TCP отправляет три сегмента. На рисунке также указаны правила, которым следует каждое подтверждение. Для первого сегмента клиента и всех трех сегментов сервера следуйте правилам, приведенным ранее: 1. Поскольку в сегменте есть данные, которые должны быть отправлены, отображается следующий ожидаемый номер байта. Когда клиент получает первый сегмент сервера, у него больше нет данных для отправки, поэтому он отправляет только сегмент ACK. Однако, согласно правилу 2, это подтверждение необходимо отложить на 500 мс, чтобы увидеть, прибывают ли еще сегменты, и нельзя откладывать подтверждение навсегда. Когда приходит следующее сообщение, устанавливается еще один таймер задержки ACK. Однако до истечения этого таймера приходит третий сегмент. Согласно правилу 3, приход третьего сегмента вызывает еще одно подтверждение. Мы не показывали таймер RTO, потому что нет потерянных или задержанных сообщений. Определяем, что для таймера RTO все в норме.

Потеря сегмента

       В этом случае мы хотим показать, что происходит, когда сегмент утерян или поврежден. Получатель обрабатывает потерянный сегмент так же, как поврежденный сегмент. Потерянные пакеты отбрасываются в определенном углу сети, а поврежденные пакеты отбрасываются самим получателем. Оба случая считаются потерянными. На следующем рисунке показан случай потери пакета (возможно, он был отброшен маршрутизатором в сети из-за перегрузки сети).

         Мы предполагаем, что передача данных односторонняя: один конец отправляет, а другой принимает. В этом случае отправитель отправляет сегменты 1 и 2 и немедленно получает подтверждение с помощью ACK (правило 3). Но сегмент 3 потерян, получатель получает сегмент 4, и последовательность нарушается. Получатель сохраняет данные в этом сегменте в буфере и оставляет промежуток, чтобы указать, что данные здесь не непрерывны. Получатель немедленно отправляет отправителю подтверждение и указывает ожидаемый следующий байт (правило 4). Обратите внимание, что получатель сохраняет байты 801-900, но никогда не доставит эти байты в приложение, пока пробел не будет заполнен.

TCP отправителя поддерживает только один таймер RTO в течение всего периода соединения. По истечении времени ожидания третьего сегмента TCP отправителя повторно передает сообщение 3. На этот раз оно достигает получателя и обычно подтверждается (правило 5).

Быстрая ретрансляция

       В данном случае мы хотим описать быструю ретрансляцию. Эта ситуация в основном аналогична второй, за исключением того, что RTO имеет большее значение, как показано на рисунке ниже.

          Когда получатель получает четвертый, пятый и шестой сегменты, все они инициируют подтверждение (правило 4). Отправитель получает четыре подтверждения с одинаковыми (три из них — дубликаты). Хотя время таймера еще не истекло, согласно правилам быстрой повторной передачи сегмент 3 должен быть повторно передан немедленно, то есть все эти повторные подтверждения ожидаемого сегмента. После повторной передачи сегмента 3 таймер перезапускается.

Отложенный сегмент

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

Повторяющийся сегмент

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

Автоматически исправить отсутствующий ACK

       В этом случае следует отметить, что информация в одном недостающем подтверждении будет включена в следующее подтверждение, что также является наиболее важным преимуществом использования кумулятивного подтверждения. На следующем рисунке показано, что подтверждение, отправленное получателем данных, потеряно. В механизме подтверждения TCP утраченное подтверждение может даже не быть замечено исходным TCP. TCP использует накопленную систему подтверждения. Мы говорим, что следующее подтверждение автоматически корректирует влияние потерянного подтверждения.

Утраченное подтверждение исправляется повторно переданным сегментом

       На рисунке ниже изображена потеря подтверждения.

        Если следующее подтверждение откладывается на долгое время или следующего подтверждения нет (потерянное подтверждение является последним), таймер RTO запускает процесс исправления, и в результате возникает повторяющийся сегмент. Когда получатель получает этот дублированный сегмент, он отбрасывает его, но следует понимать, что последний ACK должен быть повторно передан, чтобы уведомить отправителя о том, что этот сегмент (или несколько сегментов) был получен.

Обратите внимание, что, хотя на рисунке есть два сегмента, которые не были подтверждены, повторно передается только один сегмент. Когда отправитель получает повторно переданный ACK, он знает, что два сегмента были безопасно и без изменений переданы другой стороне, потому что подтверждение накапливается.

Тупик из-за потери подтверждения

      Также может возникнуть ситуация, когда потеря подтверждения может вызвать тупиковую ситуацию в системе. Эта ситуация возникает, когда получатель отправляет подтверждение при установке rwnd в 0, что означает, что отправителю предлагается временно закрыть свое окно. Через некоторое время получатель намеревается отменить это ограничение, но если у него нет данных для отправки, он отправит сегмент ACK и использует rwnd, равный ненулевому значению, чтобы отменить это ограничение. Если это подтверждение утеряно, то возникнут проблемы. Отправитель ждал подтверждения, чтобы объявить ненулевой rwnd. Получатель думает, что отправитель получил это подтверждение и ждет данных. Эта ситуация называется тупиком (deadlock), то есть обе стороны ждут ответа друг друга, и ничего не происходит. В это время таймер повторной передачи не установлен. Чтобы избежать тупиковой ситуации, необходимо разработать непрерывный таймер, при неправильной обработке потерянное подтверждение может вызвать тупик.