Обеспечение достоверности и управление скоростью передачи данных

Протокол TCP обеспечивает гарантированную доставку данных приложений, что подразумевает защиту от повреждения, потери, дублирования и нарушения очередности получения данных. Все октеты, передаваемые по TCP соединению, пронумерованы (начиная со случайного числа), все TCP сегменты содержат контрольную сумму, дабы избежать повреждения целостности сегмента. Протокол TCP имеет приёмный и передающий буферы, размеры которых определяются программно на уровне свойств конкретной операционной системы. Исходя из размеров приёмного буфера и его наполнения, протокол TCP принимающего узла определяет текущий размер окна, который и передаётся в сегменте подтверждения «АСК» передающему узлу, чтобы проинформировать передающий узел о максимально возможном количестве одновременно отправляемых сегментов. Таким образом, любой принимающий узел может ограничивать количество одновременно направляемых ему данных, регулируя тем самым скорость передачи.

Пакеты подтверждения «АСК» должны отправляться в ответ на каждый принятый пакет с данными, но существует технология позволяющая подтверждать одним пакетом «АСК» сразу несколько сегментов данных - кумулятивное подтверждение. Такая технология может быть полезна в случае прихода TCP сегментов не в порядке отправления и с запаздыванием. Например, были отправлены сегменты с порядковыми номерами 4, 5, 6 и 7, и в некоторый момент времени получатель принял сегменты 4 и 7. По правилам работы протокола TCP, получатель должен подтвердить сегмент 4 и ожидать (сохранив в буфере сегмент 7) прихода сегментов 5 и 6. Но кумулятивное подтверждение позволяет выждать некоторое время, дождавшись сегментов 5 и 6, и отправить общее подтверждение сегментов 4, 5, 6, и 7 в одном сегменте «АСК».

Гарантировать доставку в негарантированной среде передачи IP означает смириться с возможной потерей некоторых данных и обеспечить их повторную передачу. Существует два разных способа обнаружить потерю TCP сегмента вызванную некорректной работой сети. Во-первых, существует так называемый «тайм-аут повторной передачи» (retransmission timeout), который выжидается после отправки очередного сегмента до решения о потери этого сегмента. После принятия решения о потери сегмента, сегмента высылается повторно. Величина этого таймаута рассчитывается, исходя из времени оборота (RTT - Round-Trip Time). Второй кри-терий обнаружения потери сегмента - поступление трёх повторных сегментов «АСК» (DUP#ACK).

Повторные «АСК» - это сегменты подтверждения ранее подтверждённых данных, отправленные на сегменты пришедшие позднее. Возвращаясь к рассмотренному ранее примеру, если получатель не дождётся всех переданных сегментов, чтобы образовать кумулятивное подтверждение он пошлёт подтверждение получения 4-го сегмента и повторное подтверждение 4-го сегмента в ответ на получение 7-го сегмента. Посылка повторного подтверждения также производится в ответ на прием 8-го и 9-го сегментов. Только после получения потерянных 5-го и 6-го сегментов производится подтверждение всех 9-ти принятых сегментов. Таким образом, если отправитель получает три повторных подтверждения (triple duplicate acknowledgment), он принимает решение об изменении размера окна.

Действительно, потеря пакетов означает, что IP сеть не смогла по каким-то причинам доставить данные, возможно (и очень вероятно), ввиду большой загруженности. Чтобы не загружать сеть ещё больше и, соответственно, не терять ещё больше сегментов, TCP протокол уменьшает скорость отправки данных, снижая текущий 1размер «окна», тем самым, уменьшая количество одновременно отравляемых сегментов.

На данный момент существует больше десятка различных версий протокола TCP (Vegas, Reno, Newreno и т.д.) и основное разнице этих версий заключается в механизмах уменьшения «окна».

Уменьшение «окна» приведёт к одностороннему снижению скорости передачи данных и, возможной, разгрузке сети. Чтобы увеличить скорость передачи данных, необходимо увеличить размер текущего окна. Существуют два последовательно работающих алгоритма для увеличения размера «окна». Первый называется медленный старт» (slow-start) и осуществляется с первого момента увеличения окна и до половинного размера «окна», при котором произошла потеря. На стадии «медленного старта» «окно» увеличивается на один MSS с каждым поступившим сегментом подтверждения, таким образом, осуществляется мультипликативный рост «окна». Как только размер текущего «окна» доходит до поло вины размера «окна», зафиксированного перед потерей, вступает силу алгоритм «предотвращения перегрузки» (congestion avoidance), в котором «окно» возрастает аддитивно: в ответ на каждое подтверждение «окно» увеличивается на величину 1/MSS. Следовательно, при поступлении подтверждения «полного окна») «окно» увеличиться на MSS. Эта часть алгоритма помогает избежать перегрузки сети, подыскивая оптимальную скорость передачи сегментов. Оба этих алгоритма действуют и на начальной стадии соединения, сразу после его установления, чтобы не перегрузить сеть резким выбросом пакетов сразу для большого размер согласованного «окна». Только граница перехода из одного алгоритма в другой не находится эмпирическим путём, а указывает конкретной величиной, специфической для определенной операционной системы.