JS `WebRTC` `DataChannel` `Reliability` / `Ordered` / `Unordered` 传输模式与性能 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众，晚上好！我是今晚的WebRTC DataChannel可靠性专场讲师。今天咱们不搞那些虚头巴脑的理论，直接上干货，聊聊DataChannel里那些“靠谱”和“不靠谱”的故事。

开场白：DataChannel，你的数据小能手

WebRTC DataChannel，你可以把它想象成一个在浏览器和浏览器之间，或者浏览器和服务器之间，开辟的秘密隧道，专门用来传输各种数据。这数据可以是文本、文件、游戏指令，甚至是视频游戏的同步状态。关键是，它够快、够灵活，而且…某些情况下，还够“靠谱”。

第一幕：可靠性大冒险 – ordered: true, maxRetransmits: N 和 ordered: true, maxPacketLifeTime: T

DataChannel默认情况下是可靠的，并且保证消息的顺序。也就是说，你发出去的消息，对方一定能收到，而且收到的顺序跟你发送的顺序一模一样。这是通过SCTP协议提供的可靠性和拥塞控制机制实现的。

ordered: true 的重要性：

这个选项是默认开启的，它的作用是保证消息的顺序。如果你有一个消息序列 "A", "B", "C"，那么对方收到的顺序一定是 "A", "B", "C"，绝不会是 "B", "A", "C"。
maxRetransmits: N：限制重传次数

这个选项定义了每个消息最多可以重传多少次。如果一个消息在重传了 N 次之后仍然没有被确认，那么DataChannel就会放弃发送这个消息，并且关闭连接。也就是说，虽然保证了顺序，但是如果网络实在太烂，它会选择“壮士断腕”，直接断开连接，也不让你继续折腾。
```
// 创建一个可靠的DataChannel，最多重传3次
const dataChannel = peerConnection.createDataChannel("myChannel", {
    ordered: true,
    maxRetransmits: 3
});
```
适用场景： 对数据完整性要求极高，但对延迟有一定容忍度的场景。例如，金融交易数据，必须保证每一笔交易都正确无误，即使稍微慢一点也无所谓。
maxPacketLifeTime: T：限制消息的存活时间

这个选项定义了每个消息在网络中存活的最长时间（单位是毫秒）。如果一个消息在 T 毫秒内没有被确认，那么DataChannel就会放弃发送这个消息，并且关闭连接。这就像给消息设定了一个“保质期”，过期就作废。
```
// 创建一个可靠的DataChannel，消息存活时间为1000毫秒
const dataChannel = peerConnection.createDataChannel("myChannel", {
    ordered: true,
    maxPacketLifeTime: 1000
});
```
适用场景： 对延迟要求很高，但可以容忍少量数据丢失的场景。例如，在线游戏中的角色状态同步。如果某个状态消息在一段时间内没有到达，那么直接丢弃，使用最新的状态进行更新即可。

代码示例：带重传限制的可靠传输

// 创建PeerConnection
const peerConnection = new RTCPeerConnection(configuration);

// 创建DataChannel
const dataChannel = peerConnection.createDataChannel("myChannel", {
    ordered: true,
    maxRetransmits: 3 // 最多重传3次
});

// DataChannel事件处理
dataChannel.onopen = () => {
    console.log("DataChannel opened!");
    // 发送消息
    dataChannel.send("Hello, reliable world!");
};

dataChannel.onmessage = (event) => {
    console.log("Received: " + event.data);
};

dataChannel.onclose = () => {
    console.log("DataChannel closed.");
};

dataChannel.onerror = (error) => {
    console.error("DataChannel error:", error);
};

// 接收方也需要创建DataChannel，并设置相应的事件处理函数
peerConnection.ondatachannel = (event) => {
    const receiveChannel = event.channel;
    receiveChannel.onmessage = (event) => {
        console.log("Received (from receiveChannel): " + event.data);
    };
};

// ... (SDP协商等其他PeerConnection流程)

第二幕：速度与激情 – ordered: false, maxRetransmits: 0 和 ordered: false, maxPacketLifeTime: 0

如果你对数据的可靠性要求不高，但对速度要求极高，那么就可以选择关闭可靠性，使用不可靠的传输模式。这就像快递小哥，不保证一定送到，但保证速度快。

ordered: false 的意义：

关闭顺序保证，意味着消息的到达顺序可能和发送顺序不一致。想象一下，你给朋友发了三条消息："早上好"，"中午好"，"晚上好"。对方收到的顺序可能是 "中午好"，"晚上好"，"早上好"。
maxRetransmits: 0：不重传

设置为0表示不进行任何重传。如果一个消息在发送过程中丢失了，那就直接丢弃，不会尝试重新发送。
maxPacketLifeTime: 0：立即丢弃

设置为0表示消息立即过期。如果一个消息在发送过程中没有立即到达，那就直接丢弃，不会在网络中停留。
```
// 创建一个不可靠的DataChannel
const dataChannel = peerConnection.createDataChannel("unreliableChannel", {
    ordered: false,
    maxRetransmits: 0
});
```
适用场景： 对延迟极其敏感，可以容忍大量数据丢失的场景。例如，实时视频流、低延迟游戏。在这些场景中，即使丢失一些数据，用户体验的影响也远小于延迟带来的卡顿。

代码示例：不可靠传输

// 创建PeerConnection
const peerConnection = new RTCPeerConnection(configuration);

// 创建不可靠的DataChannel
const dataChannel = peerConnection.createDataChannel("unreliableChannel", {
    ordered: false,
    maxRetransmits: 0 // 不重传
});

// DataChannel事件处理
dataChannel.onopen = () => {
    console.log("Unreliable DataChannel opened!");
    // 发送消息
    dataChannel.send("Hello, unreliable world!");
};

dataChannel.onmessage = (event) => {
    console.log("Received (unreliable): " + event.data);
};

dataChannel.onclose = () => {
    console.log("Unreliable DataChannel closed.");
};

dataChannel.onerror = (error) => {
    console.error("Unreliable DataChannel error:", error);
};

// 接收方也需要创建DataChannel，并设置相应的事件处理函数
peerConnection.ondatachannel = (event) => {
    const receiveChannel = event.channel;
    receiveChannel.onmessage = (event) => {
        console.log("Received (unreliable, from receiveChannel): " + event.data);
    };
};

// ... (SDP协商等其他PeerConnection流程)

第三幕：性能大比拼 – 可靠 vs. 不可靠

特性	可靠传输 (`ordered: true`)	不可靠传输 (`ordered: false`)
数据可靠性	保证数据完整性和顺序	不保证数据完整性和顺序
延迟	较高，因为需要重传丢失的数据	较低，因为不进行重传
带宽占用	较高，因为需要重传丢失的数据	较低，因为不进行重传
适用场景	对数据完整性要求高的场景	对延迟要求高的场景
拥塞控制	内置拥塞控制机制	缺乏拥塞控制，需要手动实现

拥塞控制问题：

可靠的DataChannel内置了拥塞控制机制，可以根据网络状况动态调整发送速率，避免网络拥塞。而不靠谱的DataChannel则缺乏这种机制，需要开发者自己实现。这意味着，如果你使用了不可靠的DataChannel，就需要自己编写代码来监控网络状况，并根据情况调整发送速率，否则很容易造成网络拥塞，导致数据丢失。

实际应用中的权衡：

在实际应用中，选择哪种传输模式，需要在数据可靠性、延迟和带宽占用之间进行权衡。

高可靠性，低延迟： 几乎不可能实现。鱼和熊掌不可兼得。
高可靠性，高延迟： 可以通过可靠的DataChannel实现，但需要牺牲延迟。
低可靠性，低延迟： 可以通过不可靠的DataChannel实现，但需要容忍数据丢失。

代码示例：手动实现拥塞控制 (简单版)

// 假设我们有一个函数可以获取当前的网络状况 (例如，丢包率)
function getNetworkConditions() {
    // 这只是一个模拟，实际应用中需要使用更复杂的方法来获取网络状况
    const packetLossRate = Math.random() * 0.1; // 模拟丢包率 (0-10%)
    return { packetLossRate };
}

// 发送数据的函数
function sendData(data) {
    const { packetLossRate } = getNetworkConditions();

    // 根据丢包率动态调整发送速率
    const sendInterval = 100 + (packetLossRate * 1000); // 丢包率越高，发送间隔越长

    setTimeout(() => {
        dataChannel.send(data);
        console.log("Sent (unreliable): " + data);
    }, sendInterval);
}

第四幕：深入SCTP – DataChannel的幕后英雄

DataChannel的可靠性是由SCTP (Stream Control Transmission Protocol) 协议提供的。SCTP是一种面向连接的、可靠的传输协议，它提供了多流、多宿主、消息边界和拥塞控制等特性。

多流 (Multi-streaming)： 允许在一个连接上同时传输多个独立的流。每个流都有自己的序列号空间，这意味着在一个流中丢失的消息不会影响其他流的传输。
多宿主 (Multi-homing)： 允许一个端点拥有多个IP地址。如果一个IP地址失效，SCTP可以自动切换到另一个IP地址，从而保证连接的持续性。
消息边界 (Message boundary)： 保证消息的完整性。即使消息被分割成多个数据包发送，SCTP也会在接收端将它们重新组装成完整的消息。
拥塞控制 (Congestion control)： 根据网络状况动态调整发送速率，避免网络拥塞。

SCTP参数配置：

你可以通过negotiated选项来控制DataChannel是否使用SCTP协商。如果设置为true，那么DataChannel会使用SCTP协商来确定连接的参数。如果设置为false，那么DataChannel会使用默认的参数。

// 创建一个使用SCTP协商的DataChannel
const dataChannel = peerConnection.createDataChannel("myChannel", {
    ordered: true,
    negotiated: true,
    id: 1 // 需要指定一个唯一的ID
});

注意： 如果你设置了negotiated: true，那么你需要手动处理SDP协商过程，并在SDP中包含SCTP参数。

第五幕：最佳实践 – 如何选择正确的传输模式

明确你的需求： 在选择传输模式之前，你需要明确你的应用对数据可靠性、延迟和带宽占用有什么要求。
权衡利弊： 没有一种传输模式是完美的，你需要根据你的需求权衡各种传输模式的优缺点。
测试和优化： 在实际部署之前，你需要对你的应用进行充分的测试，并根据测试结果进行优化。
监控网络状况： 如果你使用了不可靠的DataChannel，你需要监控网络状况，并根据情况调整发送速率，避免网络拥塞。
考虑使用FEC： 前向纠错 (Forward Error Correction) 是一种可以在发送端添加冗余数据，从而在接收端恢复丢失的数据的技术。FEC可以提高不可靠传输的可靠性，但会增加带宽占用。

表格总结：DataChannel配置选项

选项	描述	默认值
`ordered`	是否保证消息的顺序。如果设置为`true`，那么消息的到达顺序和发送顺序一致。如果设置为`false`，那么消息的到达顺序可能和发送顺序不一致。	`true`
`maxRetransmits`	每个消息最多可以重传多少次。如果一个消息在重传了`N`次之后仍然没有被确认，那么DataChannel就会放弃发送这个消息。如果设置为`0`，那么不进行任何重传。	`null`
`maxPacketLifeTime`	每个消息在网络中存活的最长时间（单位是毫秒）。如果一个消息在`T`毫秒内没有被确认，那么DataChannel就会放弃发送这个消息。如果设置为`0`，那么消息立即过期。	`null`
`negotiated`	是否使用SCTP协商。如果设置为`true`，那么DataChannel会使用SCTP协商来确定连接的参数。如果设置为`false`，那么DataChannel会使用默认的参数。	`false`
`id`	DataChannel的ID。只有在`negotiated`设置为`true`时才需要指定。	`null`
`protocol`	指定DataChannel使用的子协议。	`""`

结束语：DataChannel，无限可能

DataChannel是一个非常强大的工具，它可以用于构建各种各样的实时应用。通过合理地选择传输模式，你可以根据你的需求，最大限度地发挥DataChannel的潜力。希望今天的分享能够帮助你更好地理解和使用DataChannel。

感谢各位的收看，下次再见！

发表回复 取消回复

发表回复取消回复