В настоящее время я имею дело с сетевой проблемой при подключении к Интернету с большой задержкой (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 (но не через ping) становится необоснованной, даже до нескольких минут в худших случаях. Когда эта проблема впервые возникла, произошла значительная потеря пакетов (~ 25%), что, как я думал, было виновато, но эта потеря пакетов больше не происходит (согласно пингу и т. Д.), Но проблема остается. Потеря пакетов, но не проблемные симптомы, исчезли после того, как я сделал общий отчет новому хосту о потере пакетов, но до того, как я смог предоставить им более подробные данные с помощью MTR, как они запрашивали в своем ответе на этот отчет. У меня сложилось впечатление от хозяина, что они ничего не меняли, но кто знает.
Таким образом, на данный момент я подозреваю, что существенное различие между серверами заключается в том, что старый хост (OVH) выполняет какую-то настройку своих образов ОС (я знаю, что это так), и что новый хост ( Hetnzer) нет.
Я подозреваю, что эта настройка имеет какое-то отношение к размеру окна TCP, но когда я попытался изменить эти настройки, чтобы внести изменения, настройки, похоже, не сделали то, что должны. В частности, когда я устанавливаю различные net.ipv4.mem или net.core.mem настройки, которые я нашел в Интернете через sysctl, размер окна, iperf выбирает (или максимум, который можно выбрать, при использовании -w option), похоже, принимает случайное значение без видимой для меня связи со значениями, которые я установил с помощью sysctl, в отличие от поведения, которое я ожидал, где максимальное значение - это просто то, что я установил с помощью sysctl. Обратите внимание, что iperf -s ведет себя некорректно еще до того, как клиент подключится к нему, поэтому невозможность внести те же изменения на клиенте не является правдоподобным объяснением.
Таким образом, мне интересно 2 вещи:
1) Как я могу исправить мой сервер и сделать так, чтобы задержка в TCP-соединениях была похожа на фактическую задержку на канале, даже в часы пик и при умеренной нагрузке (несколько Мбит / с)?
2) Как я могу надежно и предсказуемо изменить размер окна TCP для всех приложений? (или, что то же самое, что происходит с настройками sysctl, применяемыми, казалось бы, случайным образом? / какой шаблон мне не хватает?)
Интернет постоянно меняется, не имеет гарантии обслуживания и пересекает множество сторонних транзитных сетей. Вы не можете решить проблемы, просто взглянув на стек IP-адресов вашего сервера, вам нужно завершить исследование первопричины.
Узнайте, какой класс подключения доступен вашим пользователям. Иногда помогает большая пропускная способность, когда это является ограничением. Также измерьте задержку от них до других пунктов назначения в Интернете. Чрезвычайно высокая задержка в Google POP может вызывать подозрение, учитывая одержимость Google скоростью.
Продолжайте собирать mtr от клиента к серверу и сервер клиенту. Протестируйте у нескольких интернет-провайдеров, представляющих вашу пользовательскую базу. Ищите потери и очень большие задержки. Определите, какой интернет-провайдер владеет проблемными переходами.
Захват пакетов для трафика приложения. Опять же, от клиента к серверу и сервер клиенту. Анализируйте TCP с помощью Wireshark, ищите проблемы. Я не думаю, что есть полный диссектор Minecraft, но он не нужен строго для производительности TCP / IP.
Запускайте больше серверов у разных провайдеров в разных частях мира. Проверьте их характеристики производительности, посмотрите, больше ли это на стороне сервера или на стороне клиента. Рассмотрите возможность постоянного использования нескольких серверов (или прокси?) В разных регионах мира, если это то, что нужно для приемлемой производительности.