Я экспериментировал с параметрами TCP в Linux (с ядром 3.5). В основном по поводу этой связи:
Сервер: гигабитный восходящий канал в центре обработки данных, фактическая пропускная способность (из-за совместного использования восходящих каналов) составляет около 70 МБ / с при тестировании из другого центра обработки данных.
Клиент: Гигабитная локальная сеть, подключенная к оптоволокну 200 Мбит. Фактически загрузка тестового файла достигает 20 МБ / с.
Задержка: около 50 мс в оба конца.
Удаленный сервер используется как файловый сервер для файлов размером от 10 до 100 МБ. Я заметил, что при использовании initcwnd 10 время передачи для этих файлов сильно зависит от медленного запуска TCP, загрузка 10 МБ занимает 3,5 секунды (максимальная скорость достигнута: 3,3 МБ / с), потому что он запускается медленно, а затем увеличивается, однако завершается до достижения максимальной скорости. Моя цель - настроить минимальное время загрузки этих файлов (так что не самая высокая сырая пропускная способность или минимальная задержка в оба конца, я готов пожертвовать обоими, если это уменьшит фактическое время, необходимое для загрузки файла)
Итак, я попробовал простой расчет, чтобы определить, каким должен быть идеальный initcwnd, игнорируя любые другие соединения и возможное влияние на другие. Произведение полосы пропускания и задержки составляет 200 Мбит / с * 50 мс = 10 Мбит или 1,310,720 байта. Учитывая, что initcwnd установлен в единицах MSS, и предполагая, что MSS составляет около 1400 байт, потребуется настройка: 1.310.720 / 1400 = 936
Это значение очень далеко от значения по умолчанию (10 * MSS в Linux, 64 КБ в Windows), поэтому устанавливать его таким образом не рекомендуется. Каковы ожидаемые недостатки такой настройки? Например:
Каковы ожидаемые недостатки такой настройки? Например:
Will it affect other users of the same network?
Изменение initcwnd повлияет на:
Could it create unacceptable congestion for other connections?
Конечно.
Flood router-buffers somewhere on the path?
Не имеет значения, но если это не ваши маршрутизаторы, я бы сосредоточился на проблемах, которые вам ближе.
Increase the impact of small amounts of packet-loss?
Конечно, он может это сделать.
В результате это увеличит стоимость потери пакетов, как преднамеренной, так и непреднамеренной. Ваш сервер проще для DOS для всех, кто способен выполнить трехстороннее рукопожатие (вывод значительных объемов данных при небольших вложениях (объем данных) в).
Это также увеличит шансы того, что пачку этих пакетов нужно будет повторно передать, потому что один из первых пакетов в пачке будет потерян.
Я не думаю, что полностью понимаю, о чем вы просите, поэтому вот попытка ответить:
Во-первых, то, что вы пытаетесь сделать, имеет смысл только на стороне отправителя, а не на стороне получателя. Т.е. вам нужно изменить файловый сервер, а не получатель. Предполагая, что вы это делаете:
Изменение initcwnd на (например) 10 означает, что 10 пакетов исчезнут немедленно. Если все они достигнут своей цели, вы можете получить гораздо большее окно в первом RTT из-за медленного старта (экспоненциального увеличения cwnd). Однако при потере пакета cwnd будет уменьшен вдвое, и, поскольку вы разбиваете 10 пакетов, у вас будет значительное количество повторных передач, поэтому вы можете столкнуться с большим количеством проблем, чем вы думаете.
Если вы хотите попробовать что-то более агрессивное и как-то «грубо» по отношению к другим пользователям Интернета, вместо этого вы можете изменить алгоритм контроля перегрузки на стороне сервера. Различные алгоритмы по-разному обрабатывают cwnd. Имейте в виду, что это повлияет на всех пользователей, если ваше серверное программное обеспечение не изменит это для каждого соединения (в чем я очень сомневаюсь). Преимущество здесь в том, что алгоритм будет действовать даже после потери пакета, в то время как initcwnd не играет большой роли.
/ proc / sys / net / ipv4 / tcp_congestion_control - это место, где вы меняете алгоритм управления перегрузкой.
FWIW для таких небольших RTT (50 мс) и для средних или больших файлов initcwnd не должен сильно влиять на вашу среднюю скорость. Если нет потери пакетов, то (т.е. толстая труба) cwnd будет удваиваться при каждом RTT. С RTT = 50 мс на толстой трубе вы поместите 20 RTT за первую секунду, а это означает, что с initcwnd = 2 вы получите cwnd = 2 * 2 ^ 20 через 1 секунду, что, я уверен, больше, чем вы можете ручка ;-)