Я разработчик, у которого есть и хорошая, и плохая ситуация: я проектирую сетевой сервис, который сильно пострадает от клиентов iPhone. За последний год приложение для iPhone скачали более 10 млн раз, и теперь я вывожу пользователей в онлайн, чтобы они могли взаимодействовать друг с другом.
Я хотел бы настроить реализацию TCP для серверов, на которых будет размещен мой сетевой сервис на основе TCP. Размер отправляемого запроса будет "маленьким" (скажем, < 256 байт). Ладно, вы поняли, это игровой сервер (шок!).
FYI, мне не интересен 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: Гамильтон TCP
- Вегас: TCP Вегас
- westwood: оптимизировано для сетей с потерями
Мои серверы по умолчаниюбик«Целью является разработка протокола, который может масштабировать свою производительность до нескольких десятков гигабит в секунду в высокоскоростных сетях на большие расстояния, сохраняя при этом высокую справедливость, стабильность и дружественность TCP».
Только из крошечного описания,Вествудзвучит более уместно, поскольку он «предназначен для лучшей обработки больших путей с большой задержкой и полосой пропускания (большие каналы), с потенциальной потерей пакетов из-за ошибок передачи или других ошибок (дырявые каналы) и с динамической нагрузкой (динамические каналы)».
Я слишком глубоко вникаю или это в порядке вещей?
Для каких вещей вы, ребята, настраиваете TCP/IP вообще? Как? Какие правила нужно знать?
Какие мудрые слова вы можете посоветовать для моего конкретного случая?
Большое спасибо!
решение1
Итак, как вы уже поняли, контроль перегрузки TCP — довольно сложная область.
В этом конкретном случае, из-за небольших запросов, вам следует попытаться поддерживать соединения открытыми как можно дольше, поскольку одно соединение на запрос будет содержать пять пакетов, в то время как вы можете снизить среднее значение до чуть более двух пакетов, если будете поддерживать соединения.
NODELAY — это правильный выбор для игрового сервера; вы хотите, чтобы ваши 256 байт были доставлены немедленно, и это не целый сегмент, поэтому Nagle приостановит передачу, если вы не используете NODELAY.
Если на ваших серверах много памяти, то параметры памяти не имеют большого значения, в новых ядрах они есть.
Что касается алгоритмов управления перегрузкой, вы заметили Westwood. Другой вариант — CUBIC. Вы можете просто использовать один, или провести исследование и сравнить их. Это может быть довольно много работы, но для 10 млн клиентов это того стоит. Поэтому я бы рассмотрел возможность запуска моделирования с использованием генератора трафика на Mac или трех (поскольку у них такая же реализация TCP, как у телефона), Linux-бокса между ними, действующего как маршрутизатор (подробнее об этом вскоре) и одного из ваших серверов, чтобы посмотреть, как все пойдет.
Теперь эта средняя Linux-машина должна работатьнс-3так что вы можете смоделировать более сложный путь, чем просто коммутатор Ethernet. Затем вы захватываете некоторые пакетные трассировки на отправляющем конце TCP-соединений и анализируете их с помощьюtcptraceили графические режимы tcptrace в wireshark. Документация tcptrace — хорошее введение в анализ поведения перегрузки TCP.