TCP Retransmission: сколько пакетов будет отправлено повторно?

Как осуществляется повторная передача TCP? Какая формула определяется количеством переадресованных пакетов? Я понимаю, что он установлен где-то в кубическом tcp, но где?TCP Retransmission: сколько пакетов будет отправлено повторно?

Заинтересованы в том, как это работает в Linux. Я использую Debian 8 и просто выглядящие дампы. Я установил соединение, используя netcat, до порта 27000. Обычно я делаю на сервере, что делает iptables удалять все пакеты на порт 27000 и отправлять пакет (и посмотреть, сколько раз пакет был отправлен повторно).

источник

2016-04-04 Alex Panchenko

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

Это очень широкий вопрос.

Нет, это не в основном и не обязательно CUBIC.

Ретрансмиссия во-первых указана в «базовом» документе RFC 793 (1981) TCP, раздел 3.7 «Передача данных», пункт «Тайм-аут повторной передачи».

С тех пор было много (действительно много [*]) усовершенствований. Очень заметным является «медленный старт», последний из которых задан RFC 5681, но корни возвращаются к 1997 RFC 2001, «медленный старт TCP, предотвращение перегрузок, быстрый повтор и быстрый алгоритм восстановления».

В этом домене нет «одного размера подходит всем», всегда есть компромисс. Плюс «умные» алгоритмы будут иметь больше возможностей (программное обеспечение + использование ЦП), поэтому они могут использоваться или не использоваться или просто доступны в зависимости от приложения (думаю, встроенные устройства). И так как эти вещи в реализации (т. Е. Не видели в обмене данными между хостом), вы никогда не сможете точно знать, какое использование хоста, которое. Вы увидите размер окна TCP и масштаб в сегментах, например, но вы не будете знать, каким алгоритмом он управляется.

Что касается Linux, предполагается, что по умолчанию - PRR с момента 3.2. До этого был CUBIC и предыдущий BIC.

Хотя, значение по умолчанию не означает, что оно доступно только одному. раздел: «расширенный контроль перегрузки TCP» На моем DEBiAN запас 4.4.0 ядра, это КУБИЧЕСКОЕ::

[email protected]:~$ cat /proc/sys/net/ipv4/tcp_congestion_control 
cubic

Хотя Рено доступен слишком

[email protected]:~$ cat /proc/sys/net/ipv4/tcp_allowed_congestion_control 
cubic reno

... и есть десяток доступная в конфигурации ядра.

*: https://en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm

источник

2016-04-04 14:57:16 jbm

Я также использую Debian (просто использую netcat и смотрю дампы). Это действительно сложный вопрос, теперь я понимаю, что считается rto, но я не нашел общих rto (или полных пакетов повторной передачи). Я не понимаю, почему опция/proc/sys/net/ipv4/tcp_retries2. Я продолжу смотреть RFC. –

Итак, вы, конечно, читали https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt и, возможно, (122 страницы) RFC 1122. Это тема _huge_ сама по себе, Linux сетевая реализация - это куча кода. 2 совета: 1/Имейте в виду, что в сети Linux не является «одиноким»: я работал над встроенным Linux в течение 15 лет, в основном на сетевом промежуточном программном обеспечении, и чаще всего не встречался с другими версиями TCP/IP , от Windows CE до запатентованных стеков авионики до того, что нет.Так что вы учитесь только из Linux, _not_ переводите в «реальный мир». – jbm

(... и вторая рекомендация) 2/Для изучения можно использовать более простую обработку перегрузки TCP/IP, посмотреть на eCos, RTEMS, FreeRTOS и т. Д. Но если вы хотите сосредоточиться на CUBIC, пусть будет так и возможно, ОК с реализацией Linux. Что касается меня, я даже не знаю (и пока не хочу знать), если '/ proc/sys/net/ipv4/tcp_retries2' каким-либо образом связан с CUBIC. Пример: только для теста я переключился на Reno, и он все еще там с тем же значением «15». – jbm

TCP Retransmission: сколько пакетов будет отправлено повторно?

ответ

Смежные вопросы