Есть ли один таймер повторной передачи для каждого отправленного TCP-пакета?

Question

У меня есть вопрос относительно таймера повторной передачи TCP. Я прочитал много статей, записей в блогах и других материалов о TCP-перегрузке, и, конечно же, я столкнулся с таймером повторной передачи.
Возможно, это глупый вопрос, но иногда упоминается, что для каждого отправленного сегмента запускается таймер, а в других местах говорят, что таймер сбрасывается для каждого отправленного сегмента.
Итак, есть один таймер повторной передачи для каждого отправленного сегмента, так что есть столько таймеров, сколько отправленных сегментов, или есть только один таймер повторной передачи?

Answer 1

Обычно (отдельные реализации могут, конечно, делать что-то нестандартное), один таймер повторной передачи, и он сбрасывается, когда новые данные были подтверждены другой стороной. Время, с которого были отправлены данные и когда оно подтверждено, используется для обновления RTT (время в оба конца).

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

Answer 2

Я не совсем в курсе последних достижений в реализации TCP, но в течение довольно долгого времени реализации TCP имели «быстрые» часы (как правило, с разрешением 200 мс) и «медленные» часы (как правило, с 500 мс). См., , например.this.

Так как каждый пакет будет иметь время повторной передачи, связанное с ним, то зернистость часов для повторной передачи - это медленные часы. И поскольку RFC 6298 говорит, что вы «НЕ ДОЛЖНЫ» быть более агрессивными, чем указанные алгоритмы, он округляется до ближайшего 500 мс. Это связано с тем, что ядро ​​не обрабатывает многие события таймера для повторной передачи, а скорее обрабатывает все повторные передачи в течение 500 мс за один раз.

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

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

Но поскольку ACK (или, еще лучше, выборочный ACK) может подтвердить получение нескольких сегментов, имеет ли смысл, чтобы пакет имел время повторной передачи, связанное с ним. Ответ - да. Данные, переданные в сегменте, будут повторно переданы после вычисленного RTO. Если он ACKed до RTO (возможно, вместе с другими сегментами), то он не будет.

В зависимости от реализации вашего TCP-стека все может быть очень иным.

Answer 3

Ниже строки взяты из «TCPIP Illustrated, том 1», поэтому, кажется, существует только один таймер, новый заменяет старый.

Once a sending TCP has established its RTO based upon measurements of the time-varying values of effective RTT, whenever it sends a segment it ensures that a retransmission timer is set appropriately. When setting a retransmission timer, the sequence number of the so-called timed segment is recorded, and if an ACK is received in time, the retransmission timer is canceled. The next time the sender emits a packet with data in it, a new retransmission timer is set, the old one is canceled, and the new sequence number is recorded. The sending TCP therefore continuously sets and cancels one retransmission timer per connection; if no data is ever lost, no retransmission timer ever expires.