Эндрю Уэзеролл - Компьютерные сети. 5-е издание

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

Теперь давайте изучим протокол 4 и посмотрим, насколько он устойчив к нестандартным ситуациям. Предположим, что машина A пытается послать кадр 0 машине B, а машина B пытается послать кадр 0 машине A. Предположим также, что на машине A установлен слишком короткий период ожидания подтверждения. Соответственно, машина A посылает серию одинаковых кадров со значениями полей seq=0 и ack=1.

Когда первый неповрежденный кадр прибудет на машину B , он будет принят, и значение переменной frame_expected будет установлено равным 1. Все последующие входящие кадры будут проигнорированы, поскольку машина B будет теперь ожидать кадр с порядковым номером 1, а не 0. Более того, поскольку у всех кадров дубликатов значение поля ack=1, а машина B продолжает ожидать подтверждения для кадра 0, то B и не станет запрашивать новый пакет у своего сетевого уровня.

В ответ на каждый отвергнутый дубликат, присылаемый машиной A, машина B посылает кадр, содержащий поля seq=0 и ack=0. Наконец, один из этих кадров принимается машиной A , в результате чего машина A переходит к передаче следующего пакета. Никакая комбинация потерянных кадров или преждевременно истекших интервалов ожидания не может заставить этот протокол ни выдать сетевому уровню дубликат пакета, ни пропустить пакет, ни зависнуть. Протокол работает корректно.

Рис. 3.12. Два сценария для протокола 4: а — нормальная ситуация; б — нештатная ситуация. Нотация: (seq, ack, номер пакета). Звездочка означает, что сетевой уровень принял пакет

Однако отношения между протоколами могут быть довольно непростыми. Если обе стороны одновременно вышлют друг другу начальный пакет, возникает запутанная ситуация, проиллюстрированная на рис. 3.12. В левой части рисунка показано нормальное функционирование протокола. Правая часть рисунка демонстрирует аномальную ситуацию. Если машина B ожидает первого кадра от машины A, прежде чем послать свой первый кадр, то последовательность будет такой, как показана в левой части рисунка. При этом принимается каждый кадр.

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

3.4.2. Протокол с возвратом на n

До сих пор мы по умолчанию подразумевали, что время, необходимое на передачу кадра от отправителя к получателю, и время, необходимое на передачу подтверждения от получателя к отправителю, пренебрежимо мало. Иногда это предположение является совершенно неверным. В таких ситуациях большое время прохождения кадров по сети может значительно снижать эффективность использования пропускной способности канала. В качестве примера рассмотрим спутниковый канал связи с пропускной способностью 50 Кбит/с и временем, требуемым для прохождения сигнала в оба конца, равным 500 мс. Попытаемся использовать протокол 4 для пересылки кадров размером в 1000 бит через спутник. В момент времени t = 0 отправитель начинает посылать первый кадр. В момент времени t = 20 мс кадр полностью послан. В момент времени t = 270 мс получатель принял кадр полностью и отправил обратно подтверждение. В итоге в лучшем случае только через 520 мс после начала передачи кадра подтверждение будет получено отправителем. В данном случае еще предполагается, что приемник не тратит времени на обработку принятого кадра и подтверждение такое короткое, что временем его передачи и приема можно пренебречь. Это означает, что передающая машина была заблокирована в течение 500/520, или 96 % времени. Другими словами, использовалось только 4 % доступной пропускной способности. Очевидно, что сочетание большого времени прохождения сигнала, высокой пропускной способности и коротких кадров совершенно неприемлемо с точки зрения эффективности.

Описанная выше проблема является следствием правила, заставлявшего отправителя дожидаться подтверждения, прежде чем посылать следующий кадр. Смягчив это требование, можно значительно повысить эффективность. Решение проблемы заключается в разрешении отправителю послать не один кадр, а несколько, например w, прежде чем остановиться и перейти в режим ожидания подтверждений. Если подобрать достаточно большое число w , то отправитель сможет безостановочно посылать кадры, так как подтверждения для предыдущих кадров будут прибывать до того, как окно заполнится, и блокировка отправителя производиться не будет.

Для того чтобы найти подходящее значение w, необходимо понять, сколько кадров «вмещается» в канал, в то время как они путешествуют от отправителя к получателю. Емкость определяется путем умножения полосы пропускания в битах в секунду на время пересылки в одну сторону. Это значение можно разделить на число бит в кадре, чтобы выразить количество кадров. Назовем это количество BD (bandwidth-delay product, то есть полоса пропускания, умноженная на задержку). Следовательно, значение w нужно выбрать как 2BD + 1. 2BD — это число кадров, которое может находиться в пути (неподтвержденные кадры), если отправитель отправляет кадры непрерывно (двойка обозначает, что мы также учитываем время, необходимое на получение подтверждения). Единица прибавляется, так как кадр подтверждения отправляется только после получения полного кадра данных.

Возьмем в качестве примера канал с полосой пропускания 50 Кбит/с, в котором на пересылку кадра в одну сторону тратится 250 мс. Значение BD равно 12,5 Кбит/с или 12,5 кадра, каждый из которых включает 1000 бит. 2BD + 1 равно 26 кадрам. Отправитель начинает, как и ранее, с передачи кадра 0 и отправляет очередной кадр каждые 20 мс. К тому моменту, когда он закончит отправку 26 кадров (в момент времени t = 520 мс), как раз прибудет подтверждение кадра 0. Затем подтверждения станут прибывать каждые 20 мс. Таким образом, отправитель будет получать разрешения на передачу следующего кадра как раз вовремя. Начиная с этого момента у отправителя будет 25 или 26 неподтвержденных кадров и, следовательно, достаточно будет окна размером 26.