Надежность Tcp по сравнению с Трудностями Udp для серьезного, высокоэффективного сервера

Определите «серьезная высокая производительность» - о скольких одновременных соединениях вы говорите и сколько данных передается?

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

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

Итак, ИМХО, если вам нужна 100% надежность И для доставки заказа, тогда используйте TCP; не пытайтесь повторно реализовать TCP в UDP.

Я думаю, что самая большая часть TCP / IP, которая препятствует масштабируемости, заключается в том, что он поддерживает буфер для всех входящих / исходящих соединений вплоть до размера окна . Поэтому, если у меня высокая задержка, но клиент с высокой пропускной способностью, с которым я разговариваю, я должен хранить все отправленные пакеты в буфере до тех пор, пока я не получу подтверждение. Так что для нескольких подключений это нормально, но для обработки 100K-подключений это может вызвать проблемы с накладными расходами. На принимающей стороне, если пакет отброшен, он снова буферизует все новые полученные пакеты, пока не будет повторно передан требуемый.

Если вы собираетесь реализовать повторную передачу, вам нужно сделать то же самое, и, следовательно, будут те же накладные расходы. Однако UDP дает вам преимущество, если вы знаете скорость сквозного соединения, или если определенное сообщение может быть доставлено не по порядку, или если определенные сообщения не нуждаются в повторной передаче.Сохранение игрового сценария:

пакет 1 = перейти на 1,1 пакет 2 = выстрелить пакет 3 = перейти на 2,2

Большинство разработчиков игр, если пакет 1 потерян , но пакет 3 получен, пакет 1 больше не важен, потому что он все равно содержит устаревшую информацию. Однако вы можете сказать, что пакет 2 важен, поэтому, если он не подтвержден, отправьте повторную передачу.

Если вам нужна высокая пропускная способность и вы напрямую подключаете два сервера к Ethernet со скоростью 1000 Мбит / с, TCP / IP потребуется некоторое время для масштабирования и дополнительных накладных расходов, и, вероятно, никогда не будет достигнуто истинное гигабитное соединение из-за механизмов предотвращения перегрузки. Однако вы знаете, что это 1 Гбит / с, поэтому вы можете самостоятельно настроить UDP для передачи со скоростью до 1 Гбит / с (минус накладные расходы).

Чтобы ответить на ваши вопросы более прямо: Если вы все равно собираетесь подтверждать каждый пакет, использование UDP не дает большого преимущества, кроме того, что вы можете обрабатывать некоторые сообщения, ожидая повторной передачи ( если вы не хотите, чтобы доставка была заказана).

Udp не так сильно учитывается для игровых серверов, в основном из-за описанного выше сценария, и для боевых систем в реальном времени, таких как шутеры от первого лица, где сообщение может быть сброшено, а новое сообщение будет аннулировано. в любом случае. World of warcraft может обойтись без использования TCP, поскольку они не должны быть такими точными с таймингом и, вероятно, имеют хорошую логику, которая в любом случае затрудняет вам различение. Боевая система просто не требует скорости.

Я также утверждаю, что отчасти это оправдание - пережиток лет назад, когда у всех были менее надежные и медленные интернет-соединения. TCP также более мягок для совместного использования сети, поэтому, если происходит много событий, он замедляется, чтобы каждый получил свою долю соединения (предотвращение перегрузки).

TCP / IP - это протокол, разработанный людьми намного умнее меня за годы исследований. Настройка за последние несколько лет позволила ему работать лучше с более высокими и высокими средними скоростями сети, которые мы наблюдаем, и не требует большого понимания для использования.

Однако замена этого на UDP требует глубокого понимания работы в сети. Я видел, как плохо написанные программы UDP насыщали каналы 1 Гбит / с и убивали весь трафик по каналу, потому что они реализовали довольно наивный алгоритм повторной передачи.

Вот список вещей, которые теперь могут делать TCP / IP, которые вы бы упустили, перейдя по UDP: - для поступления в вашу программу - повторная передача (теперь с быстрой повторной передачей, выборочное подтверждение и другие функции) - Максимальный размер сегмента - Обнаружение MTU пути - Обнаружение черной дыры (расширение MTU пути) - Предотвращение перегрузки

Поэтому я настоятельно рекомендую придерживаться TCP / IP, если он вам подходит.

Также не для придирки, но вы комментируете, что Интернет, работающий по TCP / IP, неверен, на самом деле существуют десятки маршрутизируемых Интернет-протоколов , их можно посмотреть здесь . Я думаю, вы имели в виду веб-страницы, и все веб-серверы работают поверх TCP / IP.Что опять же для Интернета, это здорово, когда мы, люди, не заметим задержки, пока страница отображается правильно. Даже для TCP / IP их проблема заключается в том, что TCP / IP недостаточно агрессивен для Интернета: Google считает, что протокол tcp / ip должен быть более агрессивным по умолчанию

Надежность против производительности.

FPS-игры не требуют, чтобы все пакеты достигли места назначения, чтобы достичь его, чтобы они были исключительно большими или обеспечивали большую пропускную способность. Они только требуют, чтобы пакеты достигли сервера КАК МОЖНО СКОРЕЕ. Это высший приоритет, а накладные расходы TCP - просто ненужная нагрузка.

WoW, при его общении «не совсем в реальном времени» и зачастую тоннах данных для передачи (в местах скопления людей), возможно, придется иметь дело с пакетами, превышающими MTU (требующими фрагментации), и требует надежности (меньше пакетов большего размера = потеря пакета причиняет больше вреда ). Так что его выбор TCP логичен. То же самое касается большинства пошаговых стратегических игр и тому подобного. В играх, где игрок с пингом 30 мс побеждает игрока с пингом 50 мс UDP - король.

Во-первых, я просто перефразирую Стивенса из Сетевое программирование Unix , раздел 22.4. «Когда использовать UDP вместо TCP»:

В основном он говорит следующее:

1. UDP - единственный вариант для широковещательной / многоадресной рассылки, поэтому вы должны использовать его там.
2. UDP может использоваться для приложений простого запроса / ответа. Но вы должны добавить собственное обнаружение ошибок, означающее как минимум подтверждение, тайм-аут и повторную передачу.
3. UDP не должен использоваться для массовой передачи данных (передачи файлов), так как вам придется встроить все функциональные возможности прямо в TCP, чтобы он работал правильно.
4. UDP следует использовать для данных в реальном времени, когда скорость доставки наиболее важна и некоторые потери данных не являются проблемой, например, данные датчиков в реальном времени, живые мультимедийные потоки, котировки акций в реальном времени и т. Д.

Ответ на ваш первый вопрос очень зависит от вашего определения понятия «высокая производительность». Если вас больше всего беспокоит низкая задержка, то есть отдельные пакеты / запросы данных прибывают как можно быстрее, чем UDP. Для этого есть две основные причины. Если предположить, что пакеты / запросы в значительной степени независимы друг от друга, то при использовании TCP возникнет проблема, известная как блокировка заголовка строки .

Допустим, вы отправили два независимых пакета / запроса. Сначала А, затем Б.Поскольку TCP основан на потоке, если A теряется в сети и его необходимо повторно передать, тогда, даже если B уже успешно прибыл, он не может быть доставлен в приложение стеком до прибытия A, что приводит к ненужной задержке. Не только это, но до прибытия A стек не может подтвердить B, что может привести к повторной передаче B, вызывая ненужную перегрузку сети.

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

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

Ответ на ваш второй вопрос заключается в том, что WoW, вероятно, отправляет потоки данных, а не независимые пары запрос / ответ. Кроме того, некоторая задержка TCP может быть устранена путем отключения алгоритма Nagle . Если они действительно используют какие-либо коммуникации типа запрос / ответ, они, возможно, просто приняли проектное решение, что надежность для них важнее, чем время ожидания.