WebSockets, UDP и контрольные показатели

Ответ 1

В локальной сети вы можете получить время прохождения в обратном направлении для сообщений через WebSocket размером 200 микросекунд (от браузера JS до сервера WebSocket и обратно), что похоже на необработанные пики ICMP. На MAN это около 10 мс, WAN (над жилым ADSL для сервера в той же стране) около 30 мс и т.д. До 120-200 мс через 3.5G. Дело в том, что WebSocket практически не добавляет латентности к той, которую вы получите, в зависимости от сети.

Накладные расходы на уровне проводов для WebSocket (по сравнению с необработанным TCP) составляют от 2 октетов (незамасленная полезная нагрузка длиной < 126 октетов) и 14 октетов (масляная полезная нагрузка длиной > 64 тыс.) на сообщение (первые цифры предполагают, что сообщение не фрагментированы в несколько кадров WebSocket). Очень низкий.

Для более подробного анализа накладных расходов на уровне проводной сети WebSocket см. этот пост в блоге. Сюда входит анализ покрывая слои за пределами WebSocket.

Кроме того: с помощью реализации WebSocket, способной к потоковой обработке, вы можете (после первоначального рукопожатия WebSocket) запустить одно сообщение WebSocket и кадр в каждом направлении, а затем отправить до 2 ^ 63 октетов без каких-либо накладных расходов. По сути, это делает WebSocket причудливой прелюдией к необработанному TCP. Предостережение: посредники могут фрагментировать трафик по собственному решению. Однако, если вы запустите WSS (это безопасно WS = TLS), никакие посредники не могут вмешиваться, и там вы: raw TCP, с совместимой с HTTP прелюдией (WS handshake).

WebRTC использует RTP (= на основе UDP) для транспорта мультимедиа, но дополнительно нуждается в сигнальном канале (который может быть WebSocket i.e.). RTP оптимизирован для переноса данных в режиме реального времени в режиме реального времени. "Игры в реальном времени" часто означает передачу не средств массовой информации, а вещей, таких как позиции игроков. WebSocket будет работать для этого.

Примечание. Транзит WebRTC может быть более RTP или защищен при использовании SRTP. См. "Профили RTP" здесь.

Ответ 2

Я бы рекомендовал разработать вашу игру с помощью WebSockets в локальной проводной сети и затем перейти к API канала данных WebRTC, когда он будет доступен. Как правильно отмечает @oberstet, средние задержки WebSocket в основном эквивалентны необработанному TCP или UDP, особенно в локальной сети, поэтому для вашей фазы разработки должно быть хорошо. API-интерфейс канала WebRTC разработан так, чтобы быть очень похож на WebSockets (после установления соединения), поэтому его достаточно просто интегрировать, когда он будет широко доступен.

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

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

Игры в режиме реального времени, как правило, не могут терпеть тип задержек, которые могут возникнуть из сокетов TCP, поэтому они используют UDP для большей части игрового трафика и имеют механизмы для обработки данных о выбросах и выходе из строя (например, добавление последовательности номера к данным полезной нагрузки). Это не так уж сложно, если вы пропустите одно обновление позиции вражеского игрока, потому что через пару миллисекунд вы получите другое обновление позиции (и, вероятно, даже не заметите). Но если вы не получите обновление позиции на 500 мс, а затем внезапно получите их все, что приведет к ужасной игре.

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

Вот несколько ссылок:

• Введение в WebRTC
• Часто задаваемые вопросы по WebRTC
• Предложение канала данных WebRTC

Ответ 3

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

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

Я попытался объяснить эти методы в статье: Оптимизация многопользовательской 3D-игры Синхронизация через Интернет (http://blog.lightstreamer.com/2013/10/optimizing-multiplayer-3d-game.html).

Я также поговорил на эту тему в прошлом месяце на конференции разработчиков HTML5 в Сан-Франциско. Видео только что было опубликовано на YouTube: http://www.youtube.com/watch?v=cSEx3mhsoHg

Ответ 4

Нет поддержки UDP для Websockets (там действительно должно быть), однако вы, вероятно, можете использовать API-интерфейс RTCDataChannel WebRTC для UDP-подобных сообщений. Здесь хорошая статья:

http://www.html5rocks.com/en/tutorials/webrtc/datachannels/

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

Я даже не пробовал ничего из этого.

Ответ 5

Я хотел бы знать, будут ли спецификации для HTML6 или что-то еще поддерживать UDP?

WebSockets не будет. Одним из преимуществ WebSockets является то, что связывает существующее HTTP-соединение. Это означает, что для прокси-серверов и брандмауэров WebSockets выглядит как HTTP, поэтому они не блокируются.

Вероятно, произвольные соединения UDP никогда не будут частью какой-либо веб-спецификации из-за проблем безопасности. Самое близкое к тому, что вы после этого, скорее всего, придет как часть WebRTC, и это связано с JSEP.

Есть ли какие-либо надежные тесты... что... сравните протокол WS с низкоуровневым, прямым протоколом сокета?

Не то, чтобы я знал. Я собираюсь выйти на конечность и предсказать, что WebSockets будет медленнее;)