У нас есть несколько выделенных серверов, арендованных в дата-центре с debian 7, ядром 3.2.
Мы используем один из этих серверов в качестве сервера базы данных. Сеть между нашим сервером приложений и сервером базы данных не предназначена для нас, а используется другими клиентами центра обработки данных.
Время от времени мы распознаем повторные передачи TCP в этой строке. Мы думаем, что это связано с перегрузкой или DDoS-атаками. Наш провайдер пытается предотвратить атаки, но, конечно, не всегда удается сразу.
Тем не мение. Обычно наш сервер приложений получает результаты из базы данных в течение 20 миллисекунд, поскольку серверы баз данных работают очень быстро, а среднее время приема-передачи (RTT) составляет 0,3 мс (то есть менее 1 мс).
Когда TCP-пакет теряется на этой линии, начинается тайм-аут повторной передачи (RTO). Он рассчитывается по времени приема-передачи, но составляет не менее 200 мс. Таким образом, когда необходимо повторно передать один пакет, у нас есть 220 миллисекунд до того, как наш сервер приложений получит данные только из-за RTO.
Для меня rto_min = 200 мс кажется слишком высоким для ссылки с rtt менее 1 мс.
Можно установить rto_min с помощью ip как это:
ip route change default via 144.76.176.65 dev eth0 rto_min 5ms
RTO по-прежнему рассчитывается, но может снизиться до 5 мс, поскольку наше RTT очень мало.
Стоит ли мне это учитывать или есть другие ловушки TCP, в которые я попаду, устанавливая значение rto_min таким маленьким? Какое значение для rto_min приемлемо или его лучше не трогать?