Не просто принимайте прямой ответ «да или нет, потому что я так сказал», так как вы можете открыть для себя необходимость бороться с кучей проблем с UDP, с которыми на самом деле вам не нужно сталкиваться.
Ни в одном из других ответов здесь не указан очевидный способ доказать это.
Возьмите несколько простых фактов
- IP-заголовок составляет 20 байтов, независимо от того, какой протокол вы используете.
- Заголовки UDP - 4 байта
- Заголовки TCP 20 байтов
Таким образом, каждый раз, когда вы отправляете сообщение длиной 1 байт по линии, вы фактически отправили 25 или 41 байт в зависимости от протокола, предполагая, что IP-заголовок также необходим.
источники:
Мой совет
Возьмите ситуацию, когда вам необходимо взаимодействие клиент-сервер, оцените количество клиентов, а затем выполните математические расчеты на основе данных, которые вы фактически отправляете между двумя.
Пример
Допустим, я отправляю 10 сообщений по 1 байту на каждое обновление в моей игре, и я обновляю около 60 кадров в секунду, поэтому мне нужно отправить 60 * 10 = 600 байтов в секунду фактических данных сообщения + соответствующие заголовки.
Теперь, в зависимости от игры, я мог бы отправить все это в виде одного сообщения, поэтому мои издержки на уровне TCP составляют всего 40 байтов (фактически стоимость по UDP составляет 20 байтов в секунду), при отсутствии таких издержек потенциальная стоимость составляет 600 байтов ( потому что мне, возможно, придется переслать весь поток сообщений).
Однако, если жизненно важно, чтобы каждое сообщение отправлялось само по себе в момент, когда оно будет готово к отправке, у меня есть 600 сообщений (также 600 байтов) + 40 * 600 = 24 Кбайт издержек TCP или ~ 14 Кб накладных расходов UDP в секунду + 600 байтов данных сообщения.
Опять же, мы задаем вопросы, насколько важны эти сообщения, как часто они и могут ли они быть каким-то образом объединены, чтобы уменьшить накладные расходы?
Это просто основано на куче однобайтовых сообщений, обычно вы делаете что-то совсем другое, но без знания исходных данных сложно доказать в любом случае, что TCP лучше подходит для вашей ситуации, чем UDP.
Так будет ли это работать?
Что ж, если у вас типичный fps, и позиция важна (чтобы избежать мошенничества или неправильных решений), вам нужно знать, что ваш сетевой поток является реальным, но каждый из 32 игроков передает это 24k + сообщение байтов назад и вперед (так 768 КБ / s + messages) ... это примерно 10 Мбит / с широкополосной линии только для отдельных заголовков, основанной на отправке по крайней мере 1 сообщения на кадр от каждого клиента всем другим клиентам через сервер.
Вы, очевидно, не будете кодировать свой сервер и клиент для такой работы, а размеры сообщений, скорее всего, будут намного больше и, вероятно, будут чуть менее частыми, чем 1 байт на кадр, в большинстве случаев, поэтому трудно сказать, не видя реального мира. Пример «это данные, которые мне нужно отправить».
Мое дело
Я сделал вызов в моем случае, что это разумные издержки, но это основано на том, как я строю свои потоки сообщений, чтобы у меня не было огромных накладных расходов по сравнению с некоторыми проектами.
TCP работает нормально, и у меня есть масштабируемый MMO-сервер и клиентская среда, но мне не нужно передавать много данных когда-либо в кадре или множество небольших пакетов, потому что я могу пакетировать свои звонки.
для других: TCP просто не подойдет, и они могут использовать только UDP, но должны признать, что он не даст им гарантии относительно того, что они получают (гарантия заказа / прибытия).
Другие соображения
Многие плохо закодированные игровые движки обрабатывают все в основном потоке на процессоре, поэтому процессору часто дается очень мало времени для обработки сетевого кода, приличная реализация как сервера, так и клиента будет полностью асинхронной и, возможно, push и тянуть сообщения в пакетном режиме.
Есть несколько хороших сетевых библиотек, но, как видно из этого, многие, похоже, придерживаются мнения, что UDP «просто лучше», в первую очередь учитывайте ваши собственные потребности, а это может быть не так, и находите библиотеку, которая этого не делает. Факторы, которые вы делаете, могут привести к плохо закодированной настройке TCP по сравнению с вариантом UDP в той же самой библиотеке (я просто говорю, что видел это, и нагрузочные тесты доказали это).
Создайте что-нибудь сначала из технической базы данных, которые вы хотите отправить, и протестируйте их, затем выполните математические расчеты, чтобы масштабировать их, выполнить тестирование нагрузки в худшем случае, развернув их в облаке, и заставить 50 компьютеров запустить тестовый клиент, чтобы посмотреть, сможет ли он справиться ваш лимит в 32 игрока на игру (или любые другие ограничения, которые вы можете иметь).