Протокол TCP. Изначально разработанный для функционирования поверх протокола IP, TCP получил «в наследство» от IP некоторые характеристики

Изначально разработанный для функционирования поверх протокола IP, TCP получил «в наследство» от IP некоторые характеристики, которые сегодня вызывают проблемы в магистралях сетей предприятия.

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

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

Если в какой-либо сети конкурируют различные потоки, то каждый из них постоянно пытается захватить себе побольше полосы пропускания. Победители в этом соревновании могли бы быть определены на основании суммарного времени прохождения информации до получателя и получения подтверждения – то есть на основании минимального RTT. При этом некорректная реализация стека TCP/IP могла воспрепятствовать некоторым пользователям получить большую ширину пропускания для своих приложений. Это привело к тому, что существует мнение о том, что стек TCP/IP одного производителя более «эффективен», чем стек другого.

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

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

Доработки протокола TCP уменьшили, но не устранили полностью всех проблем, возникающих при управлении потоком данных. Одной из таких доработок является алгоритм «Медленный старт» (Slow Start). Этот алгоритм предназначен для предотвращения (или смягчения последствий) переполнения сети, которое может возникнуть при быстрой передаче большого числа сегментов. Алгоритм постепенно повышает скорость передачи до возникновения перегрузки (сегменты начинают теряться) или достижения максимальной скорости (получатель не может принимать данные быстрее). Такая схема снижает вероятность потерь сегментов в перегруженных сетях, но не разрешает основную проблему протокола TCP – захвата всей полосы пропускания.

Другое дополнение – алгоритм «Предотвращение перегрузки» (Congestion Avoidance). Он дополняет алгоритм «Медленный старт» (рис. 13.8) и призван обеспечить доставку сегментов к получателю без потерь. Его постулат: лучше исключить перегрузку вообще, чем достичь максимальной скорости передачи, а затем восстанавливать сегменты, которые были отброшены маршрутизаторами. Это алгоритм позволяет снизить скорость передачи в тех случаях, когда в сети возникает перегрузка.

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

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

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

Поэтому второй способ использует в начальный момент функционирования соединения минимальный размер окна отсылки, который ни при каких обстоятельствах не вызовет перегрузку. «Изюминка» состоит в способе наращивания размера окна отсылки. Именно для этого используется алгоритм «Медленный старт» (RFC 1122). Протокол TCP использует новое название окна – окно перегрузки; оно измеряется не в байтах, а в количестве сегментов. В любой момент времени скорость передачи данных протоколом TCP определяется по следующему соотношению:

AWND = MIN [CREDIT, CWND],

где AWND – размер разрешенного окна передачи в сегментах. Иначе говоря, это количество сегментов, которое протоколу TCP разрешено послать на данный момент времени без получения подтверждений на успешный прием. CWND – размер окна перегрузки в сегментах. Это окно используется протоколом TCP в начальный период работы и позволяет снизить скорость передачи данных при наступлении перегрузки. CREDIT – неиспользуемый на данный момент лимит передачи сегментов, который был выдан в последнем подтверждении.

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

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

Выше события изложены с теоретической точки зрения. Правильнее было бы назвать этот алгоритм «экспоненциальным стартом», так как размер окна CWND на самом деле увеличивается экспоненциально. Когда прибывает первое подтверждение, протокол TCP увеличивает размер окна CWND в два раза и посылает сразу два сегмента. После этого окно CWND увеличивается на единицу для каждого приходящего подтверждения. Следовательно, после получения подтверждения на два последних отосланных сегмента отправитель может послать уже четыре сегмента. После того как на эти четыре сегмента поступят подтверждения, протокол может послать восемь сегментов и т. д. На рис. 13.9 показан пример работы алгоритма медленного старта. В этом примере станция А посылает сегмент, имеющий размер 100 байт. После времени, приблизительно равного четырехкратному времени обращения RTT, станция А получает возможность заполнить канал связи непрерывным потоком своих сегментов.

Медленный старт работает достаточно эффективно при создании соединения. Он позволяет протоколу TCP на стороне отправителя быстро определять оптимальный размер окна для данного соединения.

Но если все же, несмотря на эти меры, перегрузка наступила? Рассмотрим поведение этого алгоритма в такой ситуации. Предположим, что устанавливается соединение с медленным стартом и до того момента, когда размер окна перегрузки CWND достигнет лимита, выделенного отправителю другой стороной, происходит потеря сегмента. Этот факт может свидетельствовать о том, что сеть перегружена. Но нет никаких данных, позволяющих оценить серьезность возникшей ситуации. А раз так, то логичнее и безопаснее всего поступить следующим образом: сбросить размер окна перегрузки CWND до первоначального значения (единицы) и начать медленный старт заново.

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

Для разрешения этой проблемы был предложен алгоритм медленного старта с линейным ростом размера окна перегрузки CWND. Теперь при наступлении перегрузки в сети выполняются следующие действия:

1. Устанавливается значение переменной SSTHREST (сокращение означает «порог медленного старта» – slow-start threshold) равным половине текущего размера окна перегрузки, то есть SSTHREST = CWND /2.
2. Устанавливается размер окна перегрузки CWND =1 и выполняется медленный старт до тех пор, пока размер окна CWND не сравняется со значением переменной SSTHREST (см. шаг 1). В этой фазе размер окна CWND будет увеличиваться на единицу после получения подтверждения на каждый посланный сегмент.
3. Если размер окна CWND превысил значение переменной SSTHREST, то размер окна CWND необходимо увеличивать на единицу каждый раз по истечении времени обращения RTT.

На рис. 13.10 показана линейная модификация алгоритма медленного старта. На рис. 13.10, а изображается динамика роста размера окна перегрузки. Она аналогична процессам, показанным на рис. 13.9, за исключением того, что последний сегмент потерян (это приводит к тайм-ауту).

На рис. 13.10, б показана реакция на потерю сегмента. Значение переменной SSTHREST устанавливается равным восьми. До тех пор пока размер окна перегрузки не достигнет этой величины, он растет по экспоненте. После достижения этого порога размер окна CWND увеличивается линейно. Такое поведение показано на рис. 13.11. На рис. 13.11 порог размера окна равен 8. Если до наступления тайм-аута потребовалось четырехкратное время RTT, то для повторного вхождения в этот режим уже потребуется одиннадцатикратное время RTT.

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

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

q Если задержки на стороне получателя изменяются, то и в этом случае оценка RTT не точна.

q Получатель может подтверждать не каждый сегмент, а формировать подтверждение для нескольких сегментов и посылать его при появлении ответных данных. При таком поведении получателя невозможно точно определить RTT.

Понятно, что при завышенном RTO в случае потери сегментов протокол TCP становится инерционным и задерживает повторную передачу. Если протокол на стороне получателя использует правило приема «в порядке отправления», то может быть потеряно множество сегментов. Даже в более благоприятном случае, когда получатель принимает все указанные в окне отправления сегменты, медленная повторная передача также может вызвать проблемы.

Покажем это на примере. Предположим, что станция А передала последовательность сегментов, и в этой последовательности первый сегмент был потерян. До тех пор пока окно отправления станции А не обнулится и не истечет время RTO, станция А и дальше будет продолжать передавать сегменты без получения подтверждения на ранее отосланные сегменты. Станция Б получила все сегменты, за исключением первого. Но она должна отправлять в буфер все новые входящие сегменты до тех пор, пока не получит копию потерянного сегмента. Более того, станция Б не может отправить данные приложению и тем самым очистить свой буфер до поступления этой копии. Если повторная передача потерянного сегмента будет по каким-либо причинам задержана, то станция Б после заполнения буфера начнет отбрасывать новые входящие сегменты.

Для того чтобы снизить влияние негативных последствий, возникающих в вышеописанной ситуации, был предложен алгоритм: «Быстрая повторная передача», который повышает производительность при неоптимальном выборе RTO. Быстрая повторная передача приводит к следующей модификации схемы работы TCP. Если к принимающей стороне сегмент приходит не в порядке отправления, то немедленно формируются подтверждения для последнего сегмента, пришедшего в порядке отправления, и для всех последующих. При этом подтверждения для каждого сегмента будут отсылаться до тех пор, пока не поступит копия пропущенного сегмента. После этого протокол переходит в режим отсылки накопленных подтверждений для всех сегментов, полученных в порядке отправления.

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

На рис. 13.12 показана схема работы алгоритма быстрой повторной передачи.

Станция А отсылает последовательность сегментов по 200 байт в каждом. Предположим, что сегмент 1201 был потерян, но станция А не будет реагировать на это событие до тех пор, пока не пройдет время КТО. Она будет посылать новые сегменты до тех пор, пока не закроется ее окно передачи. Станция Б получает сегмент 1001 (с номерами байтов от 1001 до 1200) и высылает подтверждение на номер байта 1201. Затем она получает сегмент 1401 (с номерами байтов от 1401 до 1600). А так как этот сегмент нарушает последовательность отсылки, станция Б повторит высылку подтверждения на номер 1201 и будет высылать подтверждения на этот номер при поступлении каждого нового сегмента. Это будет продолжаться до получения копии сегмента 1201. За время, прошедшее между отправкой сегмента 1201 и получением четвертого подтверждения на этот номер, станция А успевает отослать семь сегментов. После получения четвертого подтверждения на номер 1201 станция А немедленно повторит передачу сегментов, начиная с 1201.

Дата добавления: 2015-07-13