Андрей Робачевский - Операционная система UNIX

Обычно предлагаемое окно больше одного сегмента, поэтому отправитель передает один сегмент и ожидает подтверждения. Когда подтверждение приходит, он увеличивает значение окна переполнения до двух сегментов, таким образом, два сегмента разрешены к передаче. После того как получение каждого из этих сегментов подтверждено, размер окна переполнения становится равным четырем сегментам. Можно показать, что по мере отправления сегментов и получения подтверждений размер окна переполнения растет экспоненциально, соответственно растет и эффективная скорость передачи. [76] Легко вывести формулу изменения размера окна, предполагая, что время передачи данных от отправителя к получателю и обратно (Round Trip Time, RTT) гораздо больше времени передачи сегмента отправителем. Здесь параметр sz равен размеру сегмента (например, MSS): cwnd 0 = sz cwnd 1 = cwnd 0 + (cwnd 0 /sz)*sz = 2*cwnd 0 ... cwnd n = 2*cwnd n-1 = 2 n *sz

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

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

Алгоритмы, позволяющие избежать заторов, основываются на предположении, что потеря данных, вызванная ошибками передачи по физической среде, пренебрежимо мала (гораздо меньше 1%). Следовательно, потеря данных свидетельствует о заторе, произошедшем где-то на пути следования пакета. В свою очередь, о потере данных отправитель может судить по двум событиям: значительной паузе в получении подтверждения или получении дубликата(ов) подтверждения.

Хотя устранение затора и медленный старт являются независимыми механизмами, каждый из которых имеет свою цель, обычно они реализуются совместно. Для их работы необходимо два дополнительных параметра виртуального канала; [77] Для простоты мы рассматриваем несимметричный виртуальный канал, в котором данные передаются в одну сторону, а управляющие сообщения (подтверждения, обновления окна и т.д.) передаются в обратную сторону. Эти рассуждения легко могут быть распространены и на случай полнодуплексного канала, когда каждая из сторон одновременно является и получателем и отправителем данных. окно переполнения cwndи порог медленного старта ssthresh. Работа комбинированного алгоритма определяется следующим правилам:

1. Начальные значения cwndи ssthreshинициализируются равными размеру одного сегмента и 65535 байтов соответственно.

2. Максимальное количество данных, которое может передать отправитель, не превышает меньшего из значений окна переполнения и предлагаемого окна.

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

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

Если значение cwndменьше или равно ssthresh, то TCP находится в фазе медленного старта, в противном случае производится устранение затора. Таким образом, режим медленного старта продолжается до тех пор, пока эффективная скорость передачи не достигнет половины скорости, при которой был обнаружен затор. [78] Поскольку скорость передачи определяется текущим окном, половина размера окна, сохраненная в ssthresh , определяет 1/2 скорости, при которой произошел затор. После этого включается процедура устранения затора.

Как мы только что видели, медленный старт начинается с отправления одного сегмента, затем двух, затем четырех и т.д., что порождает экспоненциальный рост размера окна. В фазе устранения затора вычисление нового значения cwndпроизводится по следующей формуле при каждом подтверждении сегмента: [79] Предполагается, что получатель подтверждает каждый сегмент. На самом деле это не так, и в этом случае приращение производится фактически на число подтвержденных сегментов.

cwnd n+1= cwnd n+ 1/cwnd n

Таким образом, формула дает зависимость роста размера окна, при которой максимальная скорость приращения составит не более одного сегмента за время передачи данных туда и обратно (Round Trip Time, RTT), независимо от того, сколько подтверждений было получено. Это утверждение легко доказать. Допустим, в какой-то момент времени размер окна составлял cwnd n. Тогда отправитель может передать максимум cwnd n/szсегментов размером sz, на которые он получит такое же число подтверждений. Можно показать, что

cwnd n+1≤ cwnd n+ (cwnd n/sz)×(1/cwnd n) = cwnd n+ sz

На рис. 6.16 показан рост окна переполнения при медленном старте и последующем устранении затора. Заметим, что переход в фазу устранения затора происходит при превышении размером окна порогового значения ssthresh.

Рис. 6.16. Рост окна переполнения при медленном старте и устранении затора

До сих пор рассматривалось получение дублированных подтверждений как свидетельство потери сегментов и затора в сети. Однако согласно RFC 1122 "Requirements for Internet Hosts — Communication Layers", модуль TCP может отправить немедленное подтверждение при получении неупорядоченных сегментов. Цель такого подтверждения — уведомить отправителя, что был получен неупорядоченный сегмент, и указать порядковый номер ожидаемых данных. Поскольку ожидаемый порядковый номер остался прежним (получение неупорядоченного сегмента не изменит его значение), данное подтверждение может явиться дубликатом уже отправленного ранее.

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