FAST TCP (также называемый FastTCP ) — это алгоритм предотвращения перегрузки TCP, специально предназначенный для междугородных соединений с высокой задержкой, разработанный в Netlab Калифорнийского технологического института и в настоящее время коммерциализируемый компанией FastSoft. FastSoft была приобретена Akamai Technologies в 2012 году. [1]
FastTCP совместим с существующими алгоритмами TCP и требует внесения изменений только в компьютер , отправляющий данные .
Название FAST представляет собой рекурсивную аббревиатуру от FAST A QM S Calable T CP , где AQM означает активное управление очередью , а TCP означает протокол управления передачей .
Роль контроля перегрузки заключается в уменьшении скорости передачи данных («перегрузки») в зависимости от пропускной способности сети и скорости передачи данных других пользователей. Как и TCP Vegas , FAST TCP [2] [3] использует задержку в очереди вместо вероятности потери в качестве сигнала перегрузки.
Большинство современных алгоритмов контроля перегрузки обнаруживают перегрузку и замедляют работу, когда обнаруживают, что пакеты отбрасываются, так что средняя скорость отправки зависит от вероятности потери. Это имеет два недостатка. Во-первых, для поддержания высоких скоростей передачи данных необходимы низкие вероятности потерь; в случае TCP Reno требуются очень низкие вероятности потерь, но даже новые алгоритмы предотвращения перегрузки, такие как H-TCP , BIC TCP и HSTCP , требуют более низких показателей потерь, чем те, которые обеспечивают большинство беспроводных глобальных сетей . Более того, потеря пакетов дает только один бит информации об уровне перегрузки, тогда как задержка представляет собой непрерывную величину и в принципе дает больше информации о сети.
Поток FAST TCP стремится поддерживать постоянное количество пакетов в очередях по всей сети. Количество пакетов в очередях оценивается путем измерения разницы между наблюдаемым временем прохождения туда и обратно (RTT) и базовым RTT , определяемым как время прохождения туда и обратно при отсутствии очереди. Базовое RTT оценивается как минимальное наблюдаемое RTT для соединения. Если в очереди находится слишком мало пакетов, скорость отправки увеличивается, а если в очереди слишком много, скорость снижается. В этом отношении он является прямым потомком TCP Vegas.
Разница между TCP Vegas и FAST TCP заключается в том, как регулируется скорость, когда количество сохраняемых пакетов слишком мало или велико. TCP Vegas вносит фиксированные корректировки скорости, независимо от того, насколько далека текущая скорость от целевой. FAST TCP делает более крупные шаги, когда система находится дальше от равновесия, и меньшие шаги вблизи равновесия. Это повышает скорость сходимости и стабильность.
Алгоритмы, основанные на задержке, в принципе могут поддерживать постоянный размер окна, избегая колебаний, присущих алгоритмам, основанным на потерях. Однако они также обнаруживают перегрузку раньше, чем алгоритмы, основанные на потерях, поскольку задержка соответствует частично заполненным буферам , а потеря возникает в результате полностью заполненных буферов. Это может быть как сила, так и слабость. Если единственный протокол, используемый в сети, основан на задержках, то можно избежать неэффективности потерь; однако, если протоколы, основанные на потерях и задержках, совместно используют сеть, [4] тогда алгоритмы, основанные на задержке, имеют тенденцию быть менее агрессивными. Это можно преодолеть путем подходящего выбора параметров, что приводит к сложным взаимодействиям, изученным Tang et al.
Измерения задержки также подвержены джиттеру в результате планирования операционной системы или конфликтов на шине .
Неясно, преобладают ли сильные или слабые стороны, и это во многом зависит от конкретного сценария.
Задержка распространения используется в алгоритме управления окном FAST. В чистой сети задержка в очередях, поддерживаемая существующими потоками FAST, может быть ошибочно принята за задержку распространения новыми потоками, которые присоединяются позже, как показано в моделировании ns-2 в [5] . Эффект этой ошибки оценки эквивалентен изменение базовых функций полезности, чтобы отдать предпочтение новым потокам перед существующими. Способ устранения этой ошибки предложен в [5] .
FAST TCP оказался многообещающим с точки зрения стабильности системы, пропускной способности и справедливости. Однако для этого требуется буферизация, которая линейно увеличивается с количеством потоков, узких мест в канале. В статье [6] предлагается новый алгоритм TCP, который расширяет FAST TCP для достижения ( α , n )-пропорциональной справедливости в устойчивом состоянии, обеспечивая требования к буферу, которые растут только в n-й степени количества потоков. Авторы называют новый алгоритм Generalized FAST TCP. Они доказывают устойчивость для случая одиночного узкого канала с однородными источниками при отсутствии задержки обратной связи. Результаты моделирования подтверждают, что новая схема стабильна при наличии задержки обратной связи и что ее требования к буферизации можно масштабировать значительно лучше, чем стандартный FAST TCP.
В отличие от большинства алгоритмов предотвращения перегрузки TCP, FAST TCP защищен несколькими патентами. [7] [8] Вместо того, чтобы добиваться стандартизации со стороны IETF , изобретатели FAST, в частности Стивен Х. Лоу и Ченг Джин, стремятся коммерциализировать его через компанию FastSoft. В настоящее время FastSoft продает одноюнитовое стоечное устройство, которое можно развернуть на стороне отправителя без каких-либо дополнительных модификаций программного или аппаратного обеспечения с обеих сторон.