通过 WebRTC 数据通道实现 WebService 是否可能且合理？
Is it possible and plausible to implement a WebService over a WebRTC Data Channel?
是否可以通过 WebRTC 数据通道实现 WebService？
想法是：
- 客户端向服务器发出一个https请求，用于信令和会话建立
- 客户端和服务器开始通过 WebRTC DataChannel 进行双向通信
好处?:
- 性能？
- 请求通过一个连接，标准允许在同一连接（端口）上使用多个数据通道
- 灵活的网络拓扑
- UDP
- 端到端加密
- 服务器可以通过同一连接发送事件
- 负载均衡可以在没有负载均衡器的情况下从服务器池客户端实现，或者各种不同的解决方案
- 目前正在讨论将 DataChannels 添加到 Workers/Service Workers/etc https://github.com/w3c/webrtc-extensions/issues/64
缺点：
- 用于实现请求分段和控制缓冲区限制的应用程序特定代码
- [EDIT 3] 我不知道在性能和 cpu/memory 用法方面与 HTTP/2 Stream
有多大区别
想法：
- 客户端可以是用于同步的数据的只读副本，或者适用于 public IPFS 网络中的 orbit-db https://github.com/orbitdb/orbit-db 的任何其他应用程序，使用 orbit-db 的好处是只允许所有者进行写入，然后服务器可以另外使用他的密钥对所有数据进行签名，以便客户端可以验证并信任它来自服务器，这可以卸载主服务器进行读取，这只是一个想法。
[编辑]
我找到了这个存储库：https://github.com/jsmouret/grpc-over-webrtc
太棒了！
[EDIT2]
稍微调查了一下后，更改了 Orbit-db 的想法并删除了集群 IPFS
[EDIT3]
在为 HTTP/2 搜索 Fetch PROS 后，我发现使用 ReadableStreams 的 Fetch 上传流，我不知道与 运行 GRPC (bidi) 相比有多大区别WebRTC DataChannel 或 HTTP/2 Stream
解释该功能的视频非常棒：https://www.youtube.com/watch?v=G9PpImUEeUA
这里有很多不同点，将尝试解决所有问题。
这个想法是 100% 可行的。查看 Pion WebRTC 的 data-channels 示例。建立连接只需要一个 request/response。
性能
如果您从事对延迟敏感的工作，数据通道更适合。
使用数据通道，您可以测量背压。您可以知道有多少数据已交付，有多少已排队。如果队列变满，您就知道发送了太多数据。浏览器中的其他 API 不会给你这个。有一些未来的 API (WebTransport)，但它们还不可用。
数据通道允许 unordered/unreliable 传送。使用 TCP，您发送的所有内容都将按顺序交付，这个问题被称为线头阻塞。这意味着如果您丢失了一个数据包，则所有后续数据包都必须延迟。例如，如果您发送 0 1 2 3，如果数据包 1 尚未到达，则 2 和 3 尚无法处理。数据通道可以配置为在数据包到达时立即为您提供数据包。
我无法为您提供有关 运行 宁 DTLS+SCTP 与 TLS+WebSocket 服务器的 CPU/Memory 成本的具体数字。这取决于 hardware/network 你有什么，工作量是多少等...
多路复用
您可以通过单个 WebRTC 连接 (PeerConnection) 提供多个 DataChannel 流。您还可以通过单个端口提供多个 PeerConnections。
网络传输
WebRTC 可以 运行 通过 UDP 或 TCP
负载平衡
这更难（但不是棘手）在服务器之间移动 DTLS 和 SCTP 会话对于现有库来说并不容易。使用 pion/dtls 它支持 export/resume 会话。但是我不知道其他图书馆的支持。
TLS/Websocket更容易负载均衡。
端到端加密
WebRTC 有强制加密。这对 HTTP 1.1 来说很好，如果配置不正确，它可能会意外回退到非 TLS。
如果您想通过服务器路由消息（并且不让服务器看到它），我认为您使用的协议并不重要。
拓扑结构
WebRTC 可以在许多不同的拓扑结构中 运行。您可以进行 P2P 或 Client/Server，以及介于两者之间的许多事情。根据您正在构建的内容，您可以构建 hybrid mesh。您可以创建连接图，并根据需要部署服务器。这种灵活性让您可以做一些有趣的事情。
希望能解决您的所有问题！很高兴在 comments/will 继续编辑问题中进一步讨论。
如果您的主要用例交换小内容，您可以看看 CoAP RFC 7252。尽管请求和响应的交换消息共享相同的格式，但对等点可以轻松实现客户端和服务器这两个角色。
对于 DTLS 1.2 的一些高级用法，DTLS Connection ID 可以为您带来一些神奇效果。
如果你不坚持使用java脚本并且java是一个选项，你可以查看开源项目Eclipse/Californium. That's a CoAP/DTLS implementation, which comes with DTLS Connection ID and some prepared advanced examples as built-in-cid-load-balancer-support or DTLS-graceful-restart。
几年前我也想知道这个 HTTP-over-WebRTC DataChannel 的想法。手头的问题是如何安全地从 Web 应用程序连接到位于防火墙后面的物联网设备 (raspberry pi)。
由于没有现成的解决方案，我最终构建了一个原型。它完成了这项工作，并且自 2019 年以来一直处于实时部署状态。
请参阅此技术博客 post，其中更详细地介绍了设计和实现：
https://webrtchacks.com/private-home-surveillance-with-the-webrtc-datachannel/
高级架构：
简化序列图：
最近开始将代码提取到独立存储库中。
是否可以通过 WebRTC 数据通道实现 WebService？
想法是：
- 客户端向服务器发出一个https请求，用于信令和会话建立
- 客户端和服务器开始通过 WebRTC DataChannel 进行双向通信
好处?:
- 性能？
- 请求通过一个连接，标准允许在同一连接（端口）上使用多个数据通道
- 灵活的网络拓扑
- UDP
- 端到端加密
- 服务器可以通过同一连接发送事件
- 负载均衡可以在没有负载均衡器的情况下从服务器池客户端实现，或者各种不同的解决方案
- 目前正在讨论将 DataChannels 添加到 Workers/Service Workers/etc https://github.com/w3c/webrtc-extensions/issues/64
缺点：
- 用于实现请求分段和控制缓冲区限制的应用程序特定代码
- [EDIT 3] 我不知道在性能和 cpu/memory 用法方面与 HTTP/2 Stream 有多大区别
想法：
- 客户端可以是用于同步的数据的只读副本，或者适用于 public IPFS 网络中的 orbit-db https://github.com/orbitdb/orbit-db 的任何其他应用程序，使用 orbit-db 的好处是只允许所有者进行写入，然后服务器可以另外使用他的密钥对所有数据进行签名，以便客户端可以验证并信任它来自服务器，这可以卸载主服务器进行读取，这只是一个想法。
[编辑]
我找到了这个存储库：https://github.com/jsmouret/grpc-over-webrtc 太棒了！
[EDIT2]
稍微调查了一下后，更改了 Orbit-db 的想法并删除了集群 IPFS
[EDIT3]
在为 HTTP/2 搜索 Fetch PROS 后，我发现使用 ReadableStreams 的 Fetch 上传流，我不知道与 运行 GRPC (bidi) 相比有多大区别WebRTC DataChannel 或 HTTP/2 Stream
解释该功能的视频非常棒：https://www.youtube.com/watch?v=G9PpImUEeUA
这里有很多不同点，将尝试解决所有问题。
这个想法是 100% 可行的。查看 Pion WebRTC 的 data-channels 示例。建立连接只需要一个 request/response。
性能
如果您从事对延迟敏感的工作，数据通道更适合。
使用数据通道，您可以测量背压。您可以知道有多少数据已交付，有多少已排队。如果队列变满，您就知道发送了太多数据。浏览器中的其他 API 不会给你这个。有一些未来的 API (WebTransport)，但它们还不可用。
数据通道允许 unordered/unreliable 传送。使用 TCP，您发送的所有内容都将按顺序交付，这个问题被称为线头阻塞。这意味着如果您丢失了一个数据包，则所有后续数据包都必须延迟。例如，如果您发送 0 1 2 3，如果数据包 1 尚未到达，则 2 和 3 尚无法处理。数据通道可以配置为在数据包到达时立即为您提供数据包。
我无法为您提供有关 运行 宁 DTLS+SCTP 与 TLS+WebSocket 服务器的 CPU/Memory 成本的具体数字。这取决于 hardware/network 你有什么，工作量是多少等...
多路复用
您可以通过单个 WebRTC 连接 (PeerConnection) 提供多个 DataChannel 流。您还可以通过单个端口提供多个 PeerConnections。
网络传输
WebRTC 可以 运行 通过 UDP 或 TCP
负载平衡
这更难（但不是棘手）在服务器之间移动 DTLS 和 SCTP 会话对于现有库来说并不容易。使用 pion/dtls 它支持 export/resume 会话。但是我不知道其他图书馆的支持。
TLS/Websocket更容易负载均衡。
端到端加密
WebRTC 有强制加密。这对 HTTP 1.1 来说很好，如果配置不正确，它可能会意外回退到非 TLS。
如果您想通过服务器路由消息（并且不让服务器看到它），我认为您使用的协议并不重要。
拓扑结构
WebRTC 可以在许多不同的拓扑结构中 运行。您可以进行 P2P 或 Client/Server，以及介于两者之间的许多事情。根据您正在构建的内容，您可以构建 hybrid mesh。您可以创建连接图，并根据需要部署服务器。这种灵活性让您可以做一些有趣的事情。
希望能解决您的所有问题！很高兴在 comments/will 继续编辑问题中进一步讨论。
如果您的主要用例交换小内容，您可以看看 CoAP RFC 7252。尽管请求和响应的交换消息共享相同的格式，但对等点可以轻松实现客户端和服务器这两个角色。
对于 DTLS 1.2 的一些高级用法，DTLS Connection ID 可以为您带来一些神奇效果。
如果你不坚持使用java脚本并且java是一个选项，你可以查看开源项目Eclipse/Californium. That's a CoAP/DTLS implementation, which comes with DTLS Connection ID and some prepared advanced examples as built-in-cid-load-balancer-support or DTLS-graceful-restart。
几年前我也想知道这个 HTTP-over-WebRTC DataChannel 的想法。手头的问题是如何安全地从 Web 应用程序连接到位于防火墙后面的物联网设备 (raspberry pi)。
由于没有现成的解决方案，我最终构建了一个原型。它完成了这项工作，并且自 2019 年以来一直处于实时部署状态。
请参阅此技术博客 post，其中更详细地介绍了设计和实现： https://webrtchacks.com/private-home-surveillance-with-the-webrtc-datachannel/
高级架构：
简化序列图：
最近开始将代码提取到独立存储库中。