4.2 Генерация подтверждений
На приемной стороне следует использовать алгоритм задержки подтверждений (delayed ACK), описанный в [RFC1122]. При использовании этого алгоритма для получателя недопустима избыточная задержка генерации подтверждений. В частности, пакеты ACK следует генерировать по крайней мере для каждого второго полноразмерного сегмента и генерация подтверждения должна происходить в течение не более 500 мсек с момента доставки первого неподтвержденного пакета.
Требование, в соответствии с которым пакеты ACK следует генерировать по крайней мере для каждого второго полноразмерного пакета в документе [RFC1122] указано в одном месте как "следует", в в другом - как "должно". Ввиду неоднозначности мы будет использовать трактовку "следует". Подчеркнем также, что уровень следует означает, что разработчик может отказаться от выполнения этого требования лишь после тщательной оценки возможных последствий. Обсуждение проблем, связанных с невыполнением требования генерации подтверждений не реже, чем для каждого второго полноразмероного сегмента, приводится в параграфе "Stretch ACK violation" документа [RFC2525].
В некоторых случаях между отправителем и получателем может отсутствовать согласие по поводу того, что собой представляет полноразм ерный сегмент. Реализация протокола считается совместимой с требованиями этого параграфа, если она передает по крайней мере одно подтверждение каждый раз по получении 2*RMSS байтов новых данных от отправителя (RMSS - максимальный размер сегмента, указанный получателем отправителю, или принятое по умолчанию значение 536 байтов [RFC1122], если получатель не указал опцию MSS при организации соединения). Отправитель может быть вынужден использовать сегменты меньшего, чем RMSS размера в результате ограничения MTU, path MTU или воздействия иных факторов. В качестве примера рассмотрим случай когда получатель анонсирует RMSS = X байтов, но отправитель использует сегменты меньшего размера Y байтов (Y < X) вследствие ограничения path MTU или значения MTU на стороне отправителя. Получатель будет генерировать подтверждения ACK более редко, если он будет дожидаться доставки 2*X перед генерацией ACK. Очевидно, что подтверждения для 2 сегментов по Y байтов передавались бы чаще. Следовательно, несмотря на то, что не определен специфический алгоритм, для получателя желательно попытаться предотвратить подобные ситуации (например, путем подтверждения каждого второго сегмента независимо от их размера). Повторим еще раз, что недопустима задержка передачи ACK более чем на 500 мсек в результате ожидания доставки второго полноразмерного сегмента.
Сегменты, доставленные с нарушением порядка, следует подтверждать незамедлительно для того, чтобы ускорить процесс восстановления (loss recovery). Для включения алгоритма ускоренного повтора (fast retransmit) получателю следует незамедлительно передать дубликат ACK при получении сегмента данных после пропуска порядковых номеров. Для обеспечения обратной связи с отправ ителем, выполняющим процедуру восстановления, получателю следует незамедлительно передать подтверждение ACK при получении сегмента, который полностью или частично заполняет пропуски в порядковых номерах.
Для получателя TCP недопустимо генерировать более одного подтверждения ACK для каждого входящего сегмента, если это подтверждение не является обновлением предлагаемого размера окна в тех случаях, когда принимающее приложение забирает новые данные [RFC813], [RFC793].