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

повторная передача пакета

отправка данных

Предпосылкой повторной передачи с потерей пакетов является то, что отправитель может знать, успешно ли получатель получил сообщение. Следовательно, в протоколе TCP получатель возвращает отправителю уведомление, также известное как подтверждение (ACK), которое указывает, что получатель получил пакет.

Согласно анализу заголовка TCP в предыдущем разделе, значение ACK равно порядковому номеру следующего отправляемого пакета данных. Поэтому ACK можно понимать и как: «Отправитель, в следующий раз начни отправку с этой позиции!». На следующем рисунке показан процесс отправки и подтверждения данных:

И пакеты, и ACK могут быть потеряны, и в этом случае отправитель повторно отправит данные, если не получит ACK в течение определенного периода времени:

Даже при нормальном сетевом соединении получатель может получать повторяющиеся пакеты данных из-за наличия задержки, поэтому получатель определяет, был ли получен пакет данных с помощью SYN в заголовке TCP. Если он был получен, пакет будет отброшен.

Время ожидания повторной передачи (RTO)

Если отправитель не получает подтверждение ACK после ожидания в течение определенного периода времени, он инициирует повторную передачу по тайм-ауту. Это время ожидания называется временем ожидания повторной передачи (RTO, Retransmission TimeOut). Каково конкретное значение RTO?

Во-первых, значение RTO не является фиксированным, это динамически изменяющееся время. Это время всегда немного больше, чем время приема-передачи соединения (RTT, Round Trip Time). Эту настройку можно понять так: «Данные отправляются другой стороне, а затем возвращаются мне. Если это занимает 10 секунд, то я буду ждать 12 секунд. Если это превышает 12 секунд, считается, что они не будут Вернись."

RTT является динамическим, потому что никто не знает, будет ли сеть перегружена в следующий момент. Текущее RTO необходимо оценивать на основе будущего RTT. Значение RTO не может быть оценено как слишком большое, иначе оно будет ждать слишком много времени; оно также не может быть слишком маленьким, иначе данные, которые не должны быть повторно переданы, будут переданы повторно из-за внезапного замедления работы сети.

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

TCP-окно

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

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

Не будет ли проблемой отправить несколько пакетов данных подряд, не дожидаясь подтверждения? Давайте сначала рассмотрим проблему потери пакетов.

Мы знаем, что поле ACK в заголовке TCP указывает последнюю позицию данных, которые получил получатель. Следовательно, после того, как получатель успешно получит 1-1000 байт данных, он отправит пакет подтверждения с ACK = 1001. Предполагая, что 1001-2000 байт пакетов данных потеряны, отправитель будет продолжать отправлять 2001-3000 байтов пакетов данных из-за большой длины окна. Получатель не возвращает подтверждение для этого пакета, так как последними данными, которые он получил, был пакет размером 1-1000 байт.

Следовательно, ACK пакета, возвращенного получателем, по-прежнему равен 1001. Это означает: "Эй, отправь данные, не отправляй потом, данные начиная с 1001-го байта еще не пришли". Возможно, что значение ACK равно 1001 в подтверждении, получаемом отправителем каждый раз, когда он посылает пакет данных. После получения трех последовательных подтверждений отправитель поймет: «Другая сторона не получила данные, и этот пакет необходимо передать повторно».

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

Процесс использования окна для отправки данных можно представить следующим рисунком:

Что делать, если пакет данных не потерян, но потерян пакет подтверждения? С этим лучше всего справляются окна. Предположим, что ACK в пакете подтверждения, отправленном отправителем, равен 1001 в первый раз и 4001 во второй раз. Тогда мы можем полностью поверить, что два пакета в середине успешно получены. Потому что если есть неполученные пакеты, получатель не будет увеличивать ACK.

В этом случае, если окно не используется, отправителю необходимо повторно передать второй и третий пакеты, но с концепцией окна отправитель опускает две повторные передачи. Поэтому использование окон на самом деле можно понимать как «пространство во времени».

управление потоком

размер окна

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

медленный старт

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

Управление потоком совместно контролируется отправителем и получателем. Мы только что сказали, что получатель запишет максимальную длину окна, которую он может выдержать, в заголовке TCP.На самом деле, на стороне отправителя также есть управление потоком, которое называется окном перегрузки. Окно в протоколе TCP относится к меньшему значению окна отправителя и окна получателя.

Процесс медленного старта выглядит следующим образом:

1. Когда связь начинается, размер окна перегрузки отправителя равен 1. Каждый раз, когда принимается ACK, окно перегрузки удваивается.
2. Поскольку экспоненциальный рост очень быстрый, очень скоро произойдет тайм-аут пакета подтверждения.
3. В этот момент устанавливается «порог медленного запуска», который составляет половину размера текущего окна перегрузки.
4. В то же время установите размер окна перегрузки на 1 и повторно войдите в процесс медленного запуска.
5. Поскольку «порог медленного старта» уже сейчас существует, то при достижении порога размер окна перегрузки не удваивается, а увеличивается линейно.
6. Поскольку размер окна продолжает увеличиваться, оно может получить три повторных подтверждения и войти в стадию «быстрой повторной передачи».
7. В это время TCP устанавливает «порог медленного запуска» равным половине текущего размера окна перегрузки, а затем устанавливает размер окна перегрузки равным пороговому размеру (также говорят, что он добавляет 3).
8. Окно перегрузки будет снова линейно увеличиваться до следующего тройного подтверждения или тайм-аута.

Описанный выше процесс можно резюмировать на следующем рисунке:

Читателям настоятельно рекомендуется проконтролировать вышеперечисленные восемь шагов, чтобы понять эту картину!