Нет, UDP по-прежнему превосходит по задержке производительности и всегда будет быстрее из-за философии двух протоколов - при условии, что ваши коммуникационные данные были разработаны с учетом UDP или любых других коммуникаций с потерями.
TCP создает абстракцию, в которой поступают все сетевые пакеты, и они приходят в точном порядке, в котором они были отправлены. Чтобы реализовать такую абстракцию на канале с потерями, он должен реализовать повторные передачи и тайм-ауты, которые занимают время. Если вы отправите 2 обновления по TCP, и пакет первого обновления будет потерян, второе обновление не будет отображаться до тех пор, пока:
- Утрата первого обновления обнаружена.
- Повторная передача первого обновления запрашивается.
- повторная передача прибыла и была обработана.
Не имеет значения, насколько быстро это делается в TCP, потому что с UDP вы просто отбрасываете первое обновление и используете второе, более новое, прямо сейчас. В отличие от TCP, UDP не гарантирует, что все пакеты прибывают, и не гарантирует, что они прибывают в порядке.
Это требует, чтобы вы отправляли правильный тип данных и разрабатывали свое общение таким образом, чтобы потеря данных была приемлемой.
Если у вас есть данные, куда должен прибыть каждый пакет, и пакеты должны обрабатываться вашей игрой в том порядке, в котором они были отправлены, то UDP не будет работать быстрее. На самом деле использование UDP в этом случае, вероятно, будет медленнее, потому что вы восстанавливаете TCP и реализуете его с помощью UDP, и в этом случае вы также можете использовать TCP.
РЕДАКТИРОВАТЬ - Добавление некоторой дополнительной информации для включения / адресации некоторых комментариев:
Как правило, уровень потери пакетов в Ethernet очень низок, но он становится намного выше, если задействован WiFi или если пользователь выполняет загрузку / загрузку. Давайте предположим, что у нас совершенно равномерная потеря пакетов 0,01% (в одну сторону, а не в оба конца). На шутере от первого лица клиенты должны отправлять обновления всякий раз, когда что-то происходит, например, когда курсор мыши поворачивает плеер, что происходит примерно 20 раз в секунду. Они также могут отправлять обновления по кадрам или с фиксированным интервалом, который будет составлять 60-120 обновлений в секунду. Поскольку эти обновления отправляются в разное время, они будут / должны отправляться в одном пакете за обновление. В игре на 16 игроков все 16 игроков отправляют эти 20-120 пакетов в секунду на сервер, в результате чего получается 320-1920 пакетов в секунду. С нашей скоростью потери пакетов 0,01% мы ожидаем потерять пакет каждые 5,2-31,25 секунды.
На каждый пакет, который мы получаем после потерянного пакета, мы отправляем DupAck, а после 3-го DupAck отправитель повторно передает потерянный пакет . Таким образом, время, которое требуется TCP для инициации повторной передачи, составляет 3 пакета плюс время, необходимое для того, чтобы последний DupAck пришел к отправителю. Затем нам нужно дождаться прибытия ретрансляции, поэтому в общей сложности мы ожидаем 3 пакета + 1 задержка туда и обратно. Задержка передачи в оба конца обычно составляет 0-1 мс в локальной сети и 50-200 мс в Интернете. 3 пакета обычно приходят через 25 мс, если мы отправляем 120 пакетов в секунду, и через 150 мс, если мы отправляем 20 пакетов в секунду.
Напротив, в случае UDP мы восстанавливаемся из потерянного пакета, как только получаем следующий пакет, поэтому мы теряем 8,3 мс, если отправляем 120 пакетов в секунду, и 50 мс, если отправляем 20 пакетов в секунду.
С TCP все становится еще сложнее, если мы также должны учитывать Nagle (если разработчик забывает отключить объединение отправки или не может отключить задержанный ACK ), предотвращение перегрузки сети или достаточно большая потеря пакетов, что мы должны учитывать несколько потери пакетов (включая потерянные Ack и DupAck). С помощью UDP мы можем легко написать более быстрый код, потому что нам просто не важно быть хорошим сетевым гражданином, как это делает TCP.