Какое описание алгоритма Nagle является правильным? - PullRequest
Новая
       4

Какое описание алгоритма Nagle является правильным?

2 голосов
/ 13 марта 2012

Ниже приведены два простых описания алгоритма Нагла.

Версия 1: Подождите, пока узел подтвердит ранее отправленные пакеты, прежде чем отправлять какие-либо частичные пакеты

Версия 2: Подождите, пока узел подтвердит ранее отправленные частичные пакеты, прежде чем отправлять какие-либо частичные пакеты

Версия 1 является результатом того, что я понимаю из информации о гугле, такой как Wiki (алгоритм Нэгла) или TCP_CORK: больше, чем вы когда-либо хотели знать

Версия 2 - результат того, что я понимаю из реализации ядра Nagle алгоритма Linux 

static inline int tcp_nagle_check(const struct tcp_sock *tp,
                              const struct sk_buff *skb,
                              unsigned mss_now, int nonagle)
{
    return (skb->len < mss_now &&
            ((nonagle & TCP_NAGLE_CORK) ||
             (!nonagle && tp->packets_out && tcp_minshall_check(tp))));
}

Функция tcp_minshall_check () проверяет, все ли отправленные небольшие пакеты подтверждены ACK.

Итак, мои вопросы:

  1. Какое из описаний является правильным?
  2. Если оба они верны, каковы преимущества модификации Linux?

1 Ответ

1 голос
/ 13 марта 2012

Единственное различие между этими двумя, как вы их записали, состоит в том, что (2) отправит один частичный сегмент без задержки, даже если есть незакрытые сегменты, если эти сегменты имеют полный размер.Т.е. если он недавно отправлял только полноразмерные сегменты, а некоторые из них все еще «в воздухе».

Это хорошо, потому что такая ситуация не указывает на болтливое соединение, которое использует небольшие пакеты.Такая ситуация часто возникает в конце массовой передачи данных.Если размер передаваемого файла не делится точно на размер сегмента TCP, так что последний фрагмент заполняет сегмент, что маловероятно, пакет данных будет иметь неполный сегмент в качестве последнего фрагмента.

Нет смысла откладывать отправку последнего фрагмента массовой передачи только потому, что он меньше.

Правило 1 будет тормозить почти каждую передачу HTTP, заставляя отправителя ввести бессмысленную задержку перед отправкойпоследний кусок.

(Вы уверены, что это настоящее правило? Обратите внимание на комментарий Николая Н. Фетисова, обязательно прочитайте реальный RFC, а не подержанные источники.)

...