Я разработчик, у которого есть хорошие + плохие ситуации, связанные с проектированием сетевой службы, которая сильно пострадает от клиентов iPhone. За последний год приложение для iPhone было скачано более 10 миллионов раз, и теперь я вывожу пользователей онлайн, чтобы они могли взаимодействовать друг с другом.
Я хотел бы настроить реализацию TCP для серверов, на которых будет размещаться моя сетевая служба на основе TCP. Размер отправленного запроса будет «маленьким» (скажем, <256 байт). Ладно, разобрались, это игровой сервер (шокер!).
К вашему сведению, меня не интересует UDP (или надежный слой поверх UDP, как, например, в ENet и RakNet) для этой конкретной службы, поскольку игры не похожи на Quake; все пакеты должны быть получены надежно, и именно для этого был разработан протокол TCP. Таким образом, связь между клиентом iPhone и сервисом будет «долговечной» (насколько это возможно - к черту туннели и лифты!).
К вашему сведению, я запускаю службу на восходящей линии связи 100 Мбит / с на серверах под управлением Linux 2.6.18-164.9.1.el5.
Мои цели одновременно:
Есть большой количество настраиваемых регуляторов, связанных с TCP! После некоторых фундаментальных исследований выяснилось, что большинство людей рекомендуют оставить настройки как есть. Однако есть ряд настроек, которые кажется как будто они должны быть настроены для конкретных случаев. Я знаю это немного расплывчато, и поэтому прошу о помощи.
Возможные варианты настройки для небольших запросов / ответов в нестабильных сетях с минимизацией памяти в максимально возможной степени:
Рассмотрим TCP алгоритмы контроля перегрузки:
Мои серверы по умолчанию bic чья «цель - разработать протокол, который может масштабировать свою производительность до нескольких десятков гигабит в секунду в высокоскоростных сетях дальней связи, сохраняя при этом высокую справедливость, стабильность и удобство использования TCP».
Просто из крошечного описания, Westwood звучит более уместно, поскольку он «предназначен для лучшей обработки путей продукта с большой задержкой полосы пропускания (большие каналы), с потенциальной потерей пакетов из-за передачи или других ошибок (негерметичные каналы) и с динамической нагрузкой (динамические каналы)».
Я вхожу здесь слишком глубоко или это нормально?
Для каких вещей вы обычно настраиваете TCP / IP? Как? Какие эмпирические правила нужно знать?
Какие мудрые слова у вас есть для моего конкретного случая?
Большое спасибо!
Итак, как вы узнали, управление перегрузкой TCP - довольно сложная область.
В этом конкретном случае из-за небольших запросов вы захотите попытаться сохранить соединения открытыми как можно больше, потому что одно соединение на запрос будет принимать пять пакетов каждый, тогда как вы можете снизить среднее значение до чуть больше двух пакетов, если поддерживать связи.
NODELAY - правильный выбор для игрового сервера; вы хотите, чтобы ваши 256 байтов были доставлены сразу, а это не весь сегмент, поэтому Nagle приостановит выполнение, если вы не используете NODELAY.
Если на ваших серверах много памяти, параметры памяти не имеют большого значения, новые ядра имеют их.
Что касается алгоритмов управления перегрузками, вы заметили Вествуд. Другой вариант - CUBIC. Вы можете просто выбрать один или провести некоторое исследование и сравнить его. Это может быть довольно сложно, но для 10 миллионов клиентов это того стоит. Итак, я бы хотел запустить симуляцию с использованием генератора трафика на Mac или трех (поскольку они имеют ту же реализацию TCP, что и телефон), Linux-бокс между работой в качестве маршрутизатора (подробнее об этом чуть позже) и один из ваших серверов, чтобы посмотреть, как все идет.
Теперь этот средний ящик Linux должен работать нс-3 так что вы можете смоделировать более сложный путь, чем просто коммутатор Ethernet. Затем вы захватываете некоторые следы пакетов на отправляющей стороне TCP-соединений и анализируете их с помощью tcptrace или режимы построения графиков tcptrace программы wirehark. Документация tcptrace - хорошее введение в анализ поведения перегрузки TCP.