Задержки повторной передачи TCP - потерянные подтверждения
Может быть, кто-нибудь сможет мне с этим помочь. Я пытаюсь выяснить, есть ли что-нибудь, что можно оптимизировать на стороне сервера, чтобы уменьшить задержки в случае потери пакетов.
Среда: клиент Windows 2012, сервер CentOS 6.x [Couchbase], тот же центр обработки данных, загруженная локальная сеть с межсетевыми экранами для прохождения. Оба являются большими физическими серверами с большим количеством резервных мощностей.
Проблема: время отклика, измеренное со стороны клиента, хорошо распределяется около ~ 1 мс, но мы видим скачок на ~ 200 мс.
Сетевая трассировка показывает следующее:
- Клиент -> отправить запрос
- Сервер -> отвечает (1 мс) пакетом с {ответ приложения + TCP подтверждение для запроса пакета} (78 байт в данном случае)
- Пакет НЕ получен клиентом
- через ~ 30 мс, клиентский стек TCP повторно передает исходный запрос
- Сервер немедленно отвечает DUP ACK (66 байтов, не содержит ответа приложения)
- Через ~ 200 мс после первоначального запроса сервер повторно передает исходный время отклика хорошо распределено около ~ 1 мс, но мы видим всплеск на ~ 200 мс.
Сетевая трассировка показывает следующее:
- Клиент -> отправить запрос
- Сервер -> отвечает (1 мс) пакетом с {ответ приложения + TCP подтверждение для запроса пакета} (78 байт в данном случае)
- Пакет НЕ получен клиентом
- через ~ 30 мс, TCP-стек клиента повторно передает исходный запрос
- Сервер немедленно отвечает DUP ACK (66 байтов, не содержит ответа приложения)
- Через ~ 200 мс после первоначального запроса сервер повторно передает исходный время отклика хорошо распределено около ~ 1 мс, но мы видим всплеск на ~ 200 мс.
Сетевая трассировка показывает следующее:
- Клиент -> отправить запрос
- Сервер -> отвечает (1 мс) пакетом с {ответ приложения + TCP подтверждение для запроса пакета} (78 байт в данном случае)
- Пакет НЕ получен клиентом
- через ~ 30 мс, TCP-стек клиента повторно передает исходный запрос
- Сервер немедленно отвечает DUP ACK (66 байтов, не содержит ответа приложения)
- Через ~ 200 мс после первоначального запроса сервер повторно передает исходный ответ (78-байтовый пакет).
Есть идеи, откуда берется эта задержка в 200 мс и как ее уменьшить? Я бы предположил, что какая-то комбинация tcp отложенных подтверждений, nagle и алгоритмов перегрузки / RTO, но настройка ядра Linux для меня немного загадка.
Есть предложения?
да, wirehark с обеих сторон, tcpdump, сетевые трассировки, снятые на уровне коммутатора (довольно дорогие коммутаторы Arista 10G), трассировки, снятые на межсетевом экране (Fortinet) и т.д. и т.д.
Проблема не в том, почему клиент не получает ответа. Это загруженная сеть с интенсивным трафиком, поэтому потеря одного пакета из 10 000 не является неожиданным. Но мне нужно предоставить SLA, даже когда я теряю пакет, и эти 200 мс задержки отбрасывают его.
Я имею в виду, экспериментируя на DEV, я могу «исправить» проблему, установив TCP RTO для клиентской подсети. до 5 мс с помощью команды маршрута [на стороне сервера]. При этом 99,999% моих запросов получают ответ менее чем за 10 мс, и я выполняю свое SLA. Хорошо, но каковы недостатки этого в продакшене? Является ли RTO реальной проблемой, или я исправляю ее случайно? Это лучшее решение проблемы или есть что-то более умное / лучшее (настроенный профиль? Параметр sysctl? Молитва богам minix?)?
ри-спасибо