选择协议？
我正在为视频会议应用程序设计自己的传输协议。我想知道基于连接的方法还是基于无连接的方法是否更适合此应用程序。
I am designing my own transport protocol for a video conferencing application. I would like to know whether a connection based or connectionless based approach is better for this application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我开发过游戏，包括那些被归类为“抽搐”游戏的游戏，例如赛车和 FPS 游戏。对于此类游戏，延迟极其重要。您不能使用 TCP，因为它保证按顺序传送，并在处理重新发送时保留传入数据包。
我们对其中大部分所做的就是使用我们所谓的“有状态 UDP”。这实际上意味着我们在消息中添加了一个数据包 ID。当我们收到消息时，我们检查了 ID。如果 ID 高于我们迄今为止看到的最高 ID，我们就会接受并处理该数据包。如果它更低，我们就放弃它。当延迟很重要时，这种方法很有效，因为即使使用 UDP，您也会收到大部分数据包，而且大多数数据包都是有序的。
I've developed games, including ones that are classified as "twitch" games like racing and FPS titles. For this type of game, latency is extremely important. You can't use TCP because it guarantees in-order delivery and will hold incoming packets while a resend is processed.
What we did for most of these was use what we called Stateful UDP. All that really means is that we added a packet ID to the message. When we received a message, we checked the ID. If the ID was higher than the highest ID we'd seen to far, we accepted and processed that packet. If it was lower, we dropped it. This approach works well when latency is important, as even with UDP you'll receive most of your packets, and most will be in-order.
TCP 需要注意的事情是（假设某种 MPEG-ish 编码）如果数据包由于网络问题而延迟，视频将冻结或延迟，直到数据到达。根据 TCP 的定义，视频不会出现错误。
使用 UDP，虽然视频是连续的，但您可能会在视频中出现错误。使用 MPEG 风格的协议，其中数据以周期性关键帧的形式发送，然后在它们之间发送增量帧，如果包含增量帧的 UDP 数据包无法到达，那么您的视频将变得块状并且通常容易出错，如下所示连接性能下降。如果错过了关键帧，那么您将收到其他错误，甚至可能根本没有视频。
如果您将相机指向的物体正在移动，并且丢失的增量帧确实会扰乱图像，那么可能需要 TCP 才能保证您获取的视频至少是准确的。但是，如果您指向相当静止的物体（如果用于视频会议，则可能不是），那么 UDP 可能就足够了，因为偶尔的增量帧丢失可能不会影响整体视频质量。
另请注意，如果您确实从头开始推出自己的解决方案，那么您可以添加代码以允许出现故障并尝试以特殊方式处理它们（例如，如果帧滞后太多，则使 TCP 连接超时，并通知用户相应）。
Things to note with TCP is that (assuming some sort of MPEG-ish encoding) if packets get delayed because of network problems, the video will freeze, or delay, until data arrives. The video, by definition of TCP, will be error free.
With UDP, while the video will be continous, you can get errors in the video. With an MPEG style protocol, where data is sent in the form of periodic key frames, and then delta frames in between them, if a UDP packet that contains a delta frame fails to arrive, then your video will become blocky and generally error prone as connection degrades. If a key frame is missed, then you will get other errors, perhaps with no video at all.
If what you are pointing the camera at is moving, and delta frames getting dropped would really mess up the image, then TCP may be required in order to guarantee that if you are getting video, it is at least accurate. However, if you are pointing at something fairly stationary (which you probably aren't if it is for video conferencing), then UDP may suffice, since an occasional delta frame loss probably won't effect the overall video quality.
Note also that if you are really rolling your own solution from the ground up, then you can add code to allow for glitches and attempt to handle them in a special way (such as timing out a TCP connection if frames lag to much, and notifying the user accordingly).
TCP 不适合这种应用。问题在于重传。如果接收方确定数据包丢失或损坏并请求重传，则 TCP 不允许重传单个数据包。从丢失/损坏的数据包开始的每个数据包都会被重新传输。当持续的高带宽数据包流通过网络时，一个小故障就会导致视频流出现不可接受的延迟，您可能无法从中恢复。
使用 UDP 作为传输，并设计应用程序层，以便在网络状况恶化时可以优雅地降级。
TCP is inappropriate for this kind of application. The problem is with retransmission. If the receiver decides that a packet is lost or corrupted, and requests a retransmission, TCP does not allow for a single packet to be retransmitted. Every packet from the lost/corrupted packet on is retransmitted. With a constant, high-bandwidth stream of packets going across the network, one little glitch is going to cause unacceptable lags in the video stream that you may not be able to recover from.
Use UDP as your transport, and design the application layer such that you can gracefully degrade when network conditions worsen.
视频和音频流并不是那么简单。您应该查看已经存在的内容 - RTP，了解您想要做什么重新发明;-)
Video and audio streaming is not that simple. You should look at something that already exists - RTP, to know what are u trying to reinvent ;-)