У меня есть сервер с подключением 10GbE к коммутатору и 10 клиентов, каждый с подключением 1GbE к тому же коммутатору.
Запустив nuttcp параллельно на каждом из клиентов, я могу направить 10 TCP-потоков данных на сервер одновременно со скоростью, близкой к проводной (то есть почти 100 мегабайт в секунду от всех 10 клиентов одновременно).
Однако, когда я меняю направление и отправляю данные с сервера клиентам, то есть 10 потоков TCP, по одному на каждого клиента, повторные передачи TCP резко возрастают, а производительность падает до 30, 20 или даже 10 мегабайт в секунду. на клиента. Я хочу получить эти цифры, потому что эта схема трафика характерна для определенных приложений, которые мне небезразличны.
Я подтвердил, что мой сервер способен насыщать канал 10GbE, выполнив тот же эксперимент через соединение 10GbE с аналогичным сервером. Я убедился, что ни на одном из моих портов нет ошибок.
Наконец, когда я принудительно ограничиваю (ограничиваю) размер окна TCP получателя, я могу немного увеличить пропускную способность (30-40 мегабайт / сек); и если я зажму его очень низко, я смогу обнулить повторные передачи (с невероятно низкой пропускной способностью).
Таким образом, я достаточно уверен, что переполняю буферы коммутатора, что приводит к потере пакетов из-за перегрузки. Однако я думал, что контроль перегрузки TCP должен был справиться с этим хорошо, в конечном итоге стабилизировавшись на уровне выше 50% от скорости передачи данных.
Итак, мой первый вопрос очень прост: какой алгоритм управления перегрузкой TCP лучше всего подходит для моей ситуации? Их очень много, но в основном они нацелены на сети с потерями, сети с высокой пропускной способностью и высокой задержкой, или беспроводные сети ... Ничего из этого не применимо к моей ситуации.
Второй вопрос: что еще я могу попробовать?
Вам нужен алгоритм, в котором размер окна не уменьшается резко при отбрасывании пакета. Резкое уменьшение размера окна приводит к внезапному падению пропускной способности TCP-трафика.
Если ваш коммутатор и ваш сервер поддерживают управление потоком, попробуйте включить управление потоком. Насколько хорошо это работает, почти полностью зависит от микросхемы и прошивки коммутатора. По сути, коммутатор будет обнаруживать перегрузку на выходе на порту, который подключен к клиенту, определять, откуда пришли пакеты, и отправлять кадры управления потоком через входной порт (то есть обратно на сервер). Если сервер распознает кадры управления потоком, он снизит скорость передачи. Если все работает хорошо, вы получите оптимальную пропускную способность с практически нулевым отбрасыванием пакетов в выходном буфере коммутатора.