JS `WebTransport` `Datagrams` (`Unreliable`) 用于低延迟游戏同步

哦吼，各位观众老爷，大家好！今天咱就来唠唠 WebTransport 里那个“不太靠谱”但速度飞快的 Datagrams，也就是咱们常说的“Unreliable Transport”，看看它怎么在低延迟游戏同步里大显身手。

WebTransport Datagrams：速度与激情（但可能掉链子）

首先，得明确一点，WebTransport 提供了两种数据传输方式：Streams (可靠，有序) 和 Datagrams (不可靠，无序)。 Streams 就像是 TCP，保证数据按顺序到达，而且不会丢包，但代价就是延迟相对较高。而 Datagrams，则更像是 UDP，速度快，延迟低，但可能会丢包，也可能乱序到达。

在游戏同步中，尤其是对实时性要求极高的游戏，比如射击游戏、赛车游戏，哪怕是几毫秒的延迟都可能影响玩家体验。这时候，Datagrams 就派上用场了。虽然它“不太靠谱”，但只要用得好，就能在延迟和可靠性之间找到一个平衡点。

Datagrams 的优势：快！真的很快！

低延迟： Datagrams 不会像 Streams 那样进行拥塞控制和重传，所以延迟非常低。
无队头阻塞 (Head-of-Line Blocking)： 如果一个 Datagram 丢了，不会影响其他 Datagram 的传输。这意味着即使有丢包，也不会造成延迟的累积。
简单： 使用起来比 Streams 更简单直接。

Datagrams 的劣势：靠不住！真的靠不住！

不可靠： Datagrams 可能会丢失。
无序： Datagrams 到达的顺序可能和发送顺序不一致。
大小限制： Datagrams 的大小通常有限制 (例如，QUIC 协议限制在 MTU 左右)。

代码示例：WebTransport Datagrams 的基本用法

咱们先来个简单的代码示例，演示一下如何在 WebTransport 中发送和接收 Datagrams。

服务端 (Node.js):

const { WebTransportServer } = require('@failsafe/webtransport');
const fs = require('fs');

async function main() {
  const cert = fs.readFileSync('cert.pem'); // 你的证书文件
  const key = fs.readFileSync('key.pem');   // 你的私钥文件

  const server = new WebTransportServer({
    port: 4433, // 监听端口
    cert: cert,
    key: key,
  });

  server.listen();

  server.on('session', async (session) => {
    console.log('New session:', session.id);

    session.datagrams.readable.pipeTo(new WritableStream({
      write(chunk) {
        const message = new TextDecoder().decode(chunk);
        console.log('Received datagram:', message);
        session.datagrams.writable.getWriter().write(new TextEncoder().encode(`Server received: ${message}`));
      }
    }));

    session.on('close', () => {
      console.log('Session closed:', session.id);
    });

    session.on('error', (error) => {
      console.error('Session error:', error);
    });
  });

  console.log('WebTransport server listening on port 4433');
}

main();

客户端 (Browser):

async function main() {
  const url = 'https://localhost:4433/'; // WebTransport 服务器地址

  try {
    const transport = new WebTransport(url);
    await transport.ready;
    console.log('WebTransport connection established!');

    const writer = transport.datagrams.writable.getWriter();
    const reader = transport.datagrams.readable.getReader();

    // 发送 Datagram
    const message = 'Hello from client!';
    await writer.write(new TextEncoder().encode(message));
    console.log('Sent datagram:', message);

    // 接收 Datagram
    const { value, done } = await reader.read();
    if (!done) {
      const receivedMessage = new TextDecoder().decode(value);
      console.log('Received datagram:', receivedMessage);
    }
    reader.releaseLock();

    // 关闭连接
    await writer.close();
    transport.close();
    console.log('WebTransport connection closed.');

  } catch (error) {
    console.error('WebTransport error:', error);
  }
}

main();

注意：

你需要一个有效的 TLS 证书和私钥才能运行 WebTransport 服务器。可以使用 openssl 生成自签名证书，但浏览器可能会提示安全警告。
代码中使用了 @failsafe/webtransport 这个库，你需要先安装它： npm install @failsafe/webtransport。
这段代码只是一个简单的示例，没有处理错误和异常情况。在实际应用中，需要进行更完善的错误处理。

如何在低延迟游戏同步中使用 Datagrams

现在，咱们来聊聊如何在低延迟游戏同步中使用 Datagrams。关键在于：

状态同步：
- 定期发送： 客户端定期向服务器发送玩家的状态信息 (位置、朝向、动作等)。
- 差异更新： 只发送状态的差异部分，减少数据量。
- 服务器广播： 服务器将所有玩家的状态信息广播给所有客户端。
输入同步：
- 客户端预测： 客户端在本地预测玩家的动作，提高响应速度。
- 服务器仲裁： 服务器验证客户端的输入，防止作弊。
- 回滚和纠正： 如果服务器的仲裁结果与客户端的预测不一致，则进行回滚和纠正。

策略选择：权衡延迟与可靠性

在使用 Datagrams 进行游戏同步时，需要根据游戏的类型和需求，选择合适的策略。

策略	描述	优点	缺点	适用场景
纯 Unreliable	直接使用 Datagrams 发送状态和输入，不进行任何可靠性处理。	延迟最低。	丢包会导致状态不一致和操作丢失。	对延迟要求极高，可以容忍一定程度的错误的游戏，比如快节奏的射击游戏，但需要配合客户端预测和服务器仲裁。
Unreliable + 重发	对关键数据 (例如，玩家的死亡状态) 进行重发，直到收到确认。	在保证关键数据可靠性的同时，保持较低的延迟。	重发机制会增加延迟，也可能导致数据冗余。	对关键数据可靠性有一定要求的游戏，比如需要保证玩家的死亡状态能够正确同步。
Unreliable + FEC	使用前向纠错 (Forward Error Correction, FEC) 技术，在发送的数据中加入冗余信息，即使丢失部分数据，也能恢复原始数据。	可以在一定程度上抵抗丢包，提高数据的可靠性。	FEC 会增加数据量，也会增加编解码的开销。	网络状况不佳，但对延迟要求仍然较高的游戏。
Unreliable + ACK	客户端发送数据后，服务器需要发送 ACK 确认，客户端如果没收到ACK，会重发数据。	可以保证数据的可靠性。	ACK机制会增加延迟	网络状况不佳，但对延迟要求仍然较高的游戏。

丢包处理：亡羊补牢，犹未晚矣

即使使用了 Datagrams，也难免会遇到丢包的情况。因此，需要一些机制来处理丢包：

序列号： 为每个 Datagram 分配一个序列号，接收端可以根据序列号检测丢包和乱序。
确认应答 (ACK)： 接收端收到 Datagram 后，发送一个 ACK 确认。发送端如果在一定时间内没有收到 ACK，则重发 Datagram。 (注意：这会增加延迟，需要在延迟和可靠性之间权衡)
前向纠错 (FEC)： 发送端在发送数据时，同时发送一些冗余信息。接收端即使丢失部分数据，也能根据冗余信息恢复原始数据。
插值 (Interpolation)： 在客户端，使用插值算法平滑地估计丢失的数据，减少跳跃感。

代码示例：简单的序列号和 ACK 机制

咱们来个简单的代码示例，演示如何使用序列号和 ACK 机制来处理丢包。

服务端 (Node.js):

const { WebTransportServer } = require('@failsafe/webtransport');
const fs = require('fs');

async function main() {
  const cert = fs.readFileSync('cert.pem');
  const key = fs.readFileSync('key.pem');

  const server = new WebTransportServer({
    port: 4433,
    cert: cert,
    key: key,
  });

  server.listen();

  server.on('session', async (session) => {
    console.log('New session:', session.id);
    const receivedSequenceNumbers = new Set();

    session.datagrams.readable.pipeTo(new WritableStream({
      write(chunk) {
        const message = new TextDecoder().decode(chunk);
        const [sequenceNumber, data] = message.split(':'); // 假设消息格式为 "序列号:数据"
        const seqNum = parseInt(sequenceNumber);

        console.log('Received datagram:', seqNum, data);

        if (receivedSequenceNumbers.has(seqNum)) {
          console.log('Duplicate datagram:', seqNum);
          return; // 忽略重复的数据包
        }
        receivedSequenceNumbers.add(seqNum);

        // 发送 ACK
        session.datagrams.writable.getWriter().write(new TextEncoder().encode(`ACK:${seqNum}`));
        console.log('Sent ACK:', seqNum);

      }
    }));

    session.on('close', () => {
      console.log('Session closed:', session.id);
    });

    session.on('error', (error) => {
      console.error('Session error:', error);
    });
  });

  console.log('WebTransport server listening on port 4433');
}

main();

客户端 (Browser):

async function main() {
  const url = 'https://localhost:4433/';

  try {
    const transport = new WebTransport(url);
    await transport.ready;
    console.log('WebTransport connection established!');

    const writer = transport.datagrams.writable.getWriter();
    const reader = transport.datagrams.readable.getReader();

    let sequenceNumber = 0;
    const sentMessages = new Map(); // 存储已发送但未收到 ACK 的消息

    // 发送 Datagram
    async function sendDatagram(message) {
      sequenceNumber++;
      const payload = `${sequenceNumber}:${message}`;
      await writer.write(new TextEncoder().encode(payload));
      console.log('Sent datagram:', sequenceNumber, message);
      sentMessages.set(sequenceNumber, message);
    }

    // 接收 ACK
    async function receiveAcks() {
      while (true) {
        const { value, done } = await reader.read();
        if (done) {
          break;
        }
        const receivedMessage = new TextDecoder().decode(value);
        if (receivedMessage.startsWith('ACK:')) {
          const ackSequenceNumber = parseInt(receivedMessage.substring(4));
          console.log('Received ACK:', ackSequenceNumber);
          sentMessages.delete(ackSequenceNumber);
        } else {
          console.log('Received unexpected message:', receivedMessage);
        }
      }
    }

    // 重发未收到 ACK 的消息
    async function resendUnackedMessages() {
      for (const [seq, msg] of sentMessages) {
        console.log('Resending datagram:', seq, msg);
        const payload = `${seq}:${msg}`;
        await writer.write(new TextEncoder().encode(payload));
      }
    }

    // 定期发送消息
    setInterval(() => {
      sendDatagram('Hello from client! ' + new Date().getTime());
    }, 100);

    // 定期重发未收到 ACK 的消息
    setInterval(() => {
      resendUnackedMessages();
    }, 500);

    // 开始接收 ACK
    receiveAcks();

  } catch (error) {
    console.error('WebTransport error:', error);
  }
}

main();

注意：

这个示例只是一个简单的演示，没有实现完整的超时重传机制。在实际应用中，需要更完善的超时策略和拥塞控制。
客户端需要维护一个 sentMessages 集合，记录已发送但未收到 ACK 的消息。
服务端需要记录已经接收到的序列号，防止重复处理数据包。

其他优化技巧

压缩： 使用压缩算法 (例如，zstd) 减少数据量。
自定义协议： 设计高效的自定义协议，减少协议开销。
多线程/Worker： 使用多线程或 Web Workers 并行处理数据，提高性能。

总结

WebTransport Datagrams 在低延迟游戏同步中有着重要的作用。虽然它“不太靠谱”，但只要用得好，就能在延迟和可靠性之间找到一个平衡点。关键在于：

理解 Datagrams 的优缺点。
选择合适的同步策略。
处理丢包和乱序。
进行性能优化。

希望今天的讲座能对你有所帮助。记住，没有银弹，只有适合你的解决方案。多尝试，多实践，才能找到最适合你的游戏同步方案。各位，下课！

发表回复 取消回复

发表回复取消回复