В такой игре, как Tic-Tac-Toe, где игроки ходят по очереди, время ожидания определенно занимает второе место по сравнению с другими факторами в коммуникации. Только по этой причине общение только по протоколу HTTP, обычно с использованием класса XMLHttpRequest или Fetch API , является очень разумным подходом, который сэкономит вам много времени на программирование. усилие.
В противном случае, если вам нужен один или несколько каналов с низкой задержкой и / или RTC , возможно, по какой-то веской причине, оба WebRTC и WebSocket являются жизнеспособными кандидатов.
WebRTC, например, может абсолютно одноранговым, в то время как WebSocket использует модель клиент-сервер. Но даже WebRTC требует, чтобы служба «сигнализации» первоначально обменивалась идентификаторами пиров, прежде чем в конечном итоге переключиться на обмен данными между пирами напрямую. Хотя для установления связи через WebRTC требуются одноранговые идентификаторы, API преднамеренно не охватывает, каким образом обмениваются идентификаторы одноранговых узлов - однако вы хотите создать свою службу сигнализации, решать только вам. Во всех случаях, связанных с WebRTC, вы можете «отправить» одноранговый идентификатор на HTTP-сервер и получить его с помощью веб-браузера другого партнера и наоборот. WebRTC начинается с уже известных одноранговых идентификаторов.
В противном случае, если настроено для этого, WebRTC может использовать службы STUN и / или TURN для поддержания однорангового соединения в сетях, которые в противном случае запрещают прямой IP маршрутизация между любыми двумя клиентами - необходимая предпосылка истинного однорангового взаимодействия.
Услуги STUN / TURN требуются не во всех случаях, но, зная средние условия сети, без использования STUN или TURN или обоих, ваше приложение не будет очень надежным для любых двух клиентов в любой произвольной сети. Как и в сценариях, где обе стороны разделены как минимум одним межсетевым экраном или упрямым маршрутизатором, который функционирует как один.
Служба TURN затем прозрачно маршрутизирует связь WebRTC, работая как ретранслятор.
Служба STUN пробивает дыры в брандмауэрах между клиентами таким образом, что впоследствии становится возможной одноранговая связь. Это означает, что, в отличие от услуги TURN, она не играет никакой активной роли в коммуникации после ее установки.
WebRTC немного сложен, особенно если вы ожидаете API по аналогии с send и receive, но упрощенный пример подключения должен быть понятен для разработчика.
Вам также может не потребоваться использовать API WebRTC напрямую, есть библиотеки, которые инкапсулируют WebRTC в более простой API того или иного вида, API, который одновременно скрывает более ограниченные или «шаблонные» аспекты WebRTC и который также помогает минимизировать риск попадания в неприятности, поскольку разные пользовательские агенты печально известны тем, что реализуют разные части WebRTC немного по-разному.
Одна из этих библиотек PeerJS , но есть и другие, без сомнения.
WebSocket API, в отличие от WebRTC, требует WebSocket-совместимого сервера, а WebSocket API не делает одноранговым. Хорошая новость заключается в том, что 1) WebSocket-совместимая служба, как правило, представляет собой просто расширенный ретранслятор (часто объединенный с логикой бэкенда приложения), хотя и работает на уровне приложения, а не на уровне сеанса для TURN и 2), существует множество ключ "WebSocket серверных реализаций там.