LINUX.ORG.RU
ФорумAdmin

Настройка повторения TCP пакетов при привышении таймаута. Дублирование пакетов.

 , прозводительность, твик, ,


0

1

Задача: Есть ли нестабильный линк, при этом весьма шикорий. Он весьма часто теряет пакеты (при это происходит именно потеря, скажем 2-60% за секунду, однако сам канал активен (на это время не линк полностью не пропадает). Иногда канал может упасть на пару минут. Необходимо, что TCP делал много попыток перепослать недошедшие пакеты с МАЛЫМ интервалом (около 0.2 секунды, т.к. у линка очень малая латентность) перепосылки пакетов, либо вообще слал дубликаты постоянно (канал куда шире, чем необходимый траффик).



Контролировать количество попыток отправки можно через tcp_retries1, tcp_retries2, tcp_syn_retries, tcp_synack_retries, tcp_fin_timeout, tcp_keepalive_intvl, tcp_keepalive_probes

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

Однако, нужно также изменить время таймаута подтверждения. Согласно RFC 2988bis он составляет 1 секунду (раньше был RFC 1122 на 3 секунды).
Согласно посту http://serverfault.com/questions/295390/how-can-i-tune-the-initial-tcp-retran... в ядре ( ./include/net/tcp.h ) TCP_TIMEOUT_INIT следует поменять его значение на меньшее (можно ли указать дробное значение? 0.1, например?).

Однако, моё внимание привлекают также близлежащие параметры TCP_RTO_MAX и TCP_RTO_MIN, и, в особенности, параметр TCP_TIMEOUT_FALLBACK. Также непонятно, зачем нужен TCP_RESOURCE_PROBE_INTERVAL.

Тут ( http://stackoverflow.com/questions/1232249/setting-tcp-retransmission-timeout... ) вообще предлагают играть с параметром TCP_WINDOW_CLAMP

Тут ( http://stackoverflow.com/questions/5907527/application-control-of-tcp-retrans... ) вообще пишут про какой-то непонятный TCP_USER_TIMEOUT.

Также существует патч, но полный смысл его мне не ясен: http://www.spinics.net/lists/netdev/msg164645.html

Подскажите, что же нужно править для решения моей задачи?




Обсуждения:
http://fixunix.com/tcp-ip/555894-question-about-tcp-retransmission-timeout.html
http://www.linuxquestions.org/questions/linux-networking-3/tcp\ip-ack-timeout...

Статья IBM: http://www.ibm.com/developerworks/aix/library/au-lowertime/index.html

☆☆☆

Последнее исправление: ktulhu666 (всего исправлений: 1)

Ответ на: комментарий от zolden

Это больше теоретическая задача (как и большая часть моих вопросов). На данной момент нет такого уж плохого линка, однако есть WiFi и 3G. :)

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

может попробуешь openvpn инфрастуру поднять, чтобы по ней столь большие задержки поддержать.

pinachet ★★★★★
()
Ответ на: комментарий от zolden

Плюсую. Данные по такому каналу можно будет гонять, но чисто теоретически и ОЧЕНЬ неспешно...

Pinkbyte ★★★★★
()

Либо был, либо можно написать (если очень приспичит, например, на базе MIRROR) таргет для iptables, который ретрансмитит пакет n-раз.

berrywizard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.