Назад | Перейти на главную страницу

Улучшение пропускной способности одиночной передачи HTTP при подключении с высокой задержкой (Ubuntu Linux)

Я пытаюсь улучшить скорость передачи файлов для моего веб-сервера в Рубе, Франция (размещенного OVH) по соединениям с большим расстоянием / задержкой.

Я знаю, что на TCP-соединения влияет более высокая задержка, однако я слышал, что настройка стека TCP и использование лучших протоколов перегрузки может иметь огромное значение. Я видел официальные документы о TCP BBR, проталкивающем 10 ГБ / с через соединения с высокой задержкой.

Я ожидаю подтолкнуть соединение к пределу в 1 Гбит / с, как я могу с соединениями с низкой задержкой (<20 мс RTT).

Настройка сервера

Тестовый файл: Ubuntu 17.10.1 ISO (1,39 ГБ)

Тестовые «клиенты»:

Расположение:

Полученные результаты:

В Нью-Йорке скорость загрузки составляет около 3,2 - 3,4 МБ / с.

Сидней имеет скорость загрузки около 900-950 КБ / с.

Интересно то, что использование диспетчера загрузок для создания большего количества HTTP / TCP-соединений приводит к увеличению скорости загрузки. Это означает, что ссылка не насыщена.

Проверенные твики:

Сначала я протестировал несколько протоколов перегрузки TCP:

Изменения в протоколе перегрузки почти не имеют значения, максимум 200 КБ / с для соединения в Нью-Йорке и <50 КБ / с для соединения в Сиднее.


Я также пробовал установить другие параметры ядра, например, предложенные здесь: https://medium.com/@frjalex/linux-kernel-high-performance-networking-how-to-2d35f5900974

Эти настройки не оказывают заметного влияния на скорость загрузки.

Вопрос

Как я могу настроить стек TCP / IP Linux, чтобы одиночные TCP (HTTP) соединения максимально увеличивали доступную пропускную способность при соединениях с высокой задержкой?

Проблема

После запуска теста с wget в Linux я обнаружил, что проблема связана с тестируемыми клиентами. Очевидно, Windows (сервер 2016) не увеличивает окно приема TCP в достаточной степени, чтобы максимизировать соединение ..

После запуска теста с wget в Linux я обнаружил, что проблема связана с тестируемыми клиентами. Очевидно, Windows (сервер 2016) не увеличивает окно приема TCP в достаточной степени, чтобы максимизировать соединение ..