Каковы некоторые советы по настройке TCP для службы, используемой клиентами iPhone в мобильных сетях, таких как 3G?

Я разработчик, у которого сложилась хорошая + плохая ситуация при разработке сетевого сервиса, который сильно пострадает от клиентов iPhone. В прошлом году приложение для iPhone было загружено более 10 мм, и теперь я подключаю пользователей к сети, чтобы взаимодействовать друг с другом.

Я хотел бы настроить реализацию TCP для серверов, на которых будет размещаться моя сетевая служба на основе TCP. Размер отправляемого запроса будет "маленьким" (скажем, < 256 байт). Хорошо, вы поняли это, это игровой сервер (шокер!).

К вашему сведению, меня не интересует UDP (или надежный уровень поверх UDP, как, например, в ENet и RakNet) для этой конкретной услуги, поскольку игры не похожи на Quake; все пакеты должны быть надежно получены, и именно для этого был разработан TCP. Таким образом, связь между клиентом iPhone и сервисом будет "долгоживущей" (насколько это возможно - туннели и лифты будут прокляты!).

К вашему сведению, я запускаю службу по восходящей линии связи со скоростью 100 Мбит / с на серверах под управлением Linux 2.6.18-164.9.1.el5.

Мои цели состоят в том, чтобы одновременно:

  • сохранить время ожидания как можно ниже; а также
  • минимизировать объем памяти, используемой для каждого подключенного клиента.

Существует множество регуляторов, связанных с TCP! После некоторых фундаментальных исследований кажется, что большинство людей рекомендует оставить настройки как есть. Тем не менее, существует ряд настроек, которые , как представляется, должны быть настроены для конкретных случаев. Это немного расплывчато, я знаю, и именно поэтому я прошу помощи.

Что нужно учитывать при настройке небольших запросов / ответов в нестабильных сетях при минимальном уменьшении объема памяти:

  • память, доступная для реализации TCP/IP
  • установка опции "nodelay" (отключите алгоритм Nagle, так как это игровой сервер полу-реального времени)
  • алгоритмы контроля заторов
  • и т. д. (что еще?)

Рассмотрим алгоритмы управления перегрузкой TCP:

  • Reno: традиционный TCP используется практически во всех других ОС
  • кубический: CUBIC-TCP
  • BIC: BIC-TCP
  • htcp: Hamilton TCP
  • Вегас: TCP Вегас
  • Вествуд: оптимизирован для сетей с потерями

По умолчанию на моих серверах установлен bic, "целью которого является разработка протокола, который может масштабировать его производительность до нескольких десятков гигабит в секунду в высокоскоростных междугородних сетях, сохраняя при этом высокую справедливость, стабильность и удобство TCP".

Просто из крошечного описания Вествуд звучит более уместно, поскольку он "предназначен для лучшей обработки продуктов с большими полосами пропускания с задержкой (большие каналы), с потенциальной потерей пакетов из-за передачи или других ошибок (утечки каналов) и с динамической нагрузкой (динамическая"). трубы)".

Я вхожу здесь слишком глубоко или это для курса?

Ребята, на какие вещи вы обычно настраиваете TCP/IP? Как? Какие эмпирические правила нужно знать?

Какие слова мудрости у вас есть для моего конкретного случая?

Большое спасибо!

Источник

1 ответ

Решение

Итак, как вы узнали, управление перегрузкой TCP является довольно сложной областью.

В этом конкретном случае из-за небольших запросов вы захотите сохранить как можно больше открытых соединений, поскольку одно соединение на запрос будет принимать пять пакетов каждый, тогда как среднее значение можно уменьшить до чуть больше двух пакетов, если вы сохраняете соединения.

NODELAY - правильная вещь для игрового сервера; Вы хотите, чтобы ваши 256 байтов были доставлены сразу, и это не целый сегмент, поэтому Nagle приостановится, если вы не используете NODELAY.

Если на ваших серверах много памяти, параметры памяти не имеют большого значения, у новых ядер это правильно.

Что касается алгоритмов контроля заторов, вы заметили Вествуд. Другой вариант - CUBIC. Вы можете просто пойти с одним, или вы можете сделать некоторые исследования и сравнить их. Это может быть довольно много работы, но для 10M клиентов это того стоит. Итак, я бы хотел запустить симуляцию с использованием генератора трафика на Mac или трех (так как они имеют ту же реализацию TCP, что и телефон), между Linux-боксом, выступающим в роли маршрутизатора (подробнее об этом позже) и один из ваших серверов, чтобы увидеть, как оно идет.

Теперь этот средний Linux-модуль должен запускать ns-3, чтобы вы могли смоделировать более сложный путь, чем просто коммутатор Ethernet. Затем вы перехватываете некоторые следы пакетов на отправляющей стороне TCP-соединений и анализируете их с помощью tcptrace или графических режимов tcptrace wireshark. Документация tcptrace - хорошее введение в анализ поведения перегрузки TCP.

Источник
Другие вопросы по тегам