我的问题是 IP 摄像机如何将数据从家庭网络传输到公共(public)网络。以下是我认为可以做到的方式:
如果我想使用树莓派相机模块设置这样的东西。我可能会在我的接入点/Wifi 路由器上使用端口转发。然而，很明显，这不是一个可扩展的解决方案，而且必须有现成的 IP 摄像机必须做的其他事情。 一种选择是将视频(使用ffmpeg)流式传输到删除服务器，然后该远程服务器可能再次“重新流式传输”？ - 如果确实如此，它是如何做到的？ 我非常了解后端架构，并且曾经开发过相当复杂的架构，所以我确实想要一个相当技术性的答案。
使用 WebRTC，原因如下:
点对点连接。 如果源可以自己完成，则避免仅仅为了中继给几个人而支付流媒体服务器的费用。 NAT 穿越。 在大多数情况下(约 87% 的时间)，UPnP 可能会打一个洞，或者其中一个对等方没有被防火墙保护。因此，可以进行直接连接。如果不能，TURN 服务器可以代理对等点之间的数据。所有这些连接协商都是 ICE 的一部分，由 WebRTC 客户端为您处理。 编解码器协商。 无需担心哪个客户端支持什么。 WebRTC 堆栈会为您协商所有这些，并且还规定了所有 WebRTC 客户端都支持的一些通用编解码器……因此，您永远不应该遇到至少没有某些编解码器配置文件有效的情况。 低延迟。 WebRTC 专为视频 session 而设计，因此优先考虑延迟而不是质量和一般可靠性。也就是说，如果您失去连接，它将在当前时间恢复，而不是试图返回并找出 10 秒前发生的事情。对于您的延迟目标，这是一件好事。 浏览器支持。 WebRTC 有广泛的浏览器支持，所有主要浏览器以及许多其他应用程序库都支持它。 所有优秀的消费级 IP 摄像机都支持 WebRTC。从基础设施的角度来看，他们需要做的就是托管一个信令服务器(它允许对等方最初进行通信和协商他们自己的连接)，以及一个 TURN 服务器用于无法直接一起通信的对等方。这是相当便宜的。信令服务器几乎不占用任何负载和带宽。大多数情况下不需要 TURN 服务器。此外，还有许多供应商提供现成的 WebRTC 堆栈，并配有客户端库。
一些 IP 摄像机不这样做。有些让用户弄清楚 IP 地址是什么，在他们的浏览器或媒体播放器中打洞，然后流式传输 MJPEG 和类似内容。