Небольшое количество пакетов, приводящее к высоким значениям RTT - PullRequest
Новая
       39

Небольшое количество пакетов, приводящее к высоким значениям RTT

0 голосов
/ 19 декабря 2018

У меня довольно простое клиент-серверное приложение (TCP).1 экземпляр отправляет 40 пакетов (равномерно распределенных в течение 1 секунды) с данными размером около 1500 байт (часть данных является меткой времени).2 экземпляр получает эти пакеты и отправляет обратно другие пакеты с начальной отметкой времени.Сейчас в одном случае я измеряю разницу между текущей меткой времени и меткой времени из пакетов.Так что я получаю что-то вроде ручной RTT.Также дополнительно я принимаю значение TCP RTT для сокетов с getsockopt и ясно вижу:

  • Мой RTT показывает мне значения около 1 мс (что ожидается при такой низкой скорости пакетов)

  • TCP RTT показывает мне ~ 40 мс И я не понимаю, почему.Я точно знаю, что я получаю свои пакеты раньше, чем за 40 мс.

Кроме того, если я увеличу количество пакетов, например, с 40 до 600, я поймаю TCP RTT как ~ 150mcs, который ожидается для моей конфигурации.

Может кто-нибудь объяснить мне это 40 мс со стороны ядра при низком количестве пакетов?

Спасибо

Ответы [ 2 ]

0 голосов
/ 14 января 2019

Отложенное подтверждение пакетов является ответом.Меньше пакетов вы получите.

0 голосов
/ 19 декабря 2018

40 мс - задержка ACK в Linux.Вот что происходит:

  1. Сторона A отправляет пакет с меньшим количеством данных, чем может вместить пакет.
  2. Сторона B получает его и устанавливает таймер ACK 40 мс.
  3. Приложение стороны А вызывает send.Но пакет не отправляется, поскольку он содержит меньше данных, чем может содержать пакет, и последний пакет содержит меньше данных, чем может содержать пакет.Таким образом, реализация ждет, чтобы увидеть, сможет ли она вместить больше данных в пакет, чтобы избежать потери пропускной способности сети.
  4. Таймер 40 мс истекает, и сторона B отправляет ACK.
  5. Сторона A отвечает на ACKпрервав задержку и отправив данные, которые были задержаны сейчас.

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

...