Почему я не могу надежно отправлять или получать данные по TCP после перемещения серверов?

В настоящее время я имею дело с сетевой проблемой с высокой задержкой (100-400 мс) Интернет-ссылок. У меня есть сеть Minecraft, и я недавно переместил ее в отдельный центр обработки данных, чтобы получить сервер с лучшим процессором и большей оперативной памятью. Пользователи этого сервера разбросаны по всему миру. До переключения сервер находился в Монреале, и пользователи в Европе имели задержку ~ 100-200 мс, а пользователи в Австралии - ~ 200-300 мс. После переключения сервер находится в Германии, пользователи в Северной Америке получают задержку ~ 100-200 мс, а пользователи в Южной Америке и Австралии получают задержку 200-400 мс. В целом, задержка очень похожа, но кто получает большую задержку и кто получает приемлемую задержку, варьируется (обратите внимание, что Minecraft не очень чувствителен к задержке в целом, особенно по сравнению с большинством видеоигр). По данным инструментов MTR и ping, значительных потерь пакетов также не наблюдается. Кроме того, программное обеспечение на обоих серверах практически идентично. Оба сервера работают под управлением Debian 10, и я запрограммировал все программное обеспечение и конфигурацию, которых нет в репозиториях APT, чтобы отправить их, переустановив те же самые пакеты через apt. Таким образом, конфигурация программного обеспечения должна быть практически идентична.

Тем не менее, у многих пользователей возникают проблемы с подключением. Кажется, это происходит только около 18:00 (± несколько часов) на востоке США. Проблема с подключением, в частности, связана с ужасно низкой пропускной способностью всех TCP-подключений. С прокси-сервером SSH + SOCKS для загрузки обычной веб-страницы (Gmail) требовалось минут , а в игре часто требуется несколько минут, чтобы передать даже простое сообщение чата, если несколько мегабайт мира данные в настоящее время передаются. Эффективная задержка TCP-соединения (например, время, которое требуется сообщению чата, чтобы пройти через него) неоправданно значительно увеличивается, когда какие-либо данные передаются через это TCP-соединение. Нормальный сеанс SSH с одним терминалом в основном хорош, и игра в основном в порядке, если не так много происходит, но как только что-то значительного размера отправляется по TCP, и это происходит в течение вышеупомянутого времени, пропускная способность падает. и задержка по TCP (но не через пинг)становится необоснованным, в худшем случае даже до нескольких минут. Когда эта проблема впервые возникла, произошла значительная потеря пакетов (~ 25%), что, как я думал, было виновато, но эта потеря пакетов больше не происходит (согласно пингу и т. Д.), Но проблема остается. Потеря пакетов, но не проблемные симптомы, исчезли после того, как я сделал общий отчет новому хосту о потере пакетов, но до того, как я смог предоставить им более подробные данные с помощью MTR, как они запрашивали в своем ответе на этот отчет. У меня сложилось впечатление от хоста, что они ничего не меняли, но, кто знает, действительно.

Таким образом, на данный момент я подозреваю, что существенное различие между серверами состоит в том, что старый хост (OVH) выполняет своего рода настройка их образов ОС (я знаю, что это так), и что новый хост (Hetnzer) этого не делает.

Я подозреваю, что эта настройка имеет какое-то отношение к размеру окна TCP, но когда я попытался манипулировать эти настройки для внесения изменений, настройки, похоже, не выполняли то, что должны. В частности, когда я устанавливаю различные параметры net.ipv4.mem или net.core.mem , которые я нахожу в Интернете через sysctl, размер окна iperf выбирает (или максимум, который ему разрешено выбирать при использовании параметра -w ), кажется, принимает случайное значение без видимой для меня связи со значениями, которые я установил через sysctl, а не вести себя так, как я ожидал, где максимальное значение - это просто то, что я установил с помощью sysctl. Обратите внимание, что iperf -s ведет себя некорректно еще до того, как к нему подключится клиент, поэтому невозможность внести те же изменения на клиенте не является правдоподобным объяснением.

Таким образом, меня интересуют 2 вещи:

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

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