Networking 实时游戏中的网络丢包处理——TCP和UDP

在我的第一个网络游戏中阅读了大量关于这方面的内容，我了解了TCP v UDP的保证交付与交付时间的核心区别。我也读过截然相反的观点，实时游戏应该使用UDP还是TCP！；）

没有人很好地讨论过如何处理丢包问题

TCP：阅读一篇关于FPS使用TCP的文章，该文章建议只使用TCP。使用TCP客户端输入的权威服务器如何处理数据包丢失和延迟中突然出现的epic峰值？这场比赛是不是只是停了一会儿，然后又回到了它结束的地方？TCP数据包丢失是否如此罕见，以至于它不是一个真正的问题，并且TCP上的FPS实际上运行良好

UDP：另一篇文章建议只使用UDP。显然，像“掷手榴弹”这样的一次性UDP事件不够可靠，因为它们在某些时候不会开火。您是否必须手动实现消息接收、重新发送协议？还是其他解决办法

---

我的游戏是一个基于tick的权威服务器，从服务器到客户端和本地模拟都有1/10秒的更新，以使事情看起来更具响应性，尽管这个问题适用于更多的应用程序。

我做了一个实时电视编辑系统。所有实时通信都是通过UDP进行的，但没有一个实时通信使用TCP，因为它更简单。使用UDP，我们将每帧发送一个状态数据包。e、 g.

以100帧、99,98、…3,2,1,0、-1、-2、-3开始视频，因此即使在-3之前没有消息通过，接收器也会在第4帧开始（只是跳过前3帧），希望没有人会注意到，并且知道这比从现在开始延迟要好。我们甚至还添加了大约+¼秒的倒计时（没有人会注意到），这样几乎没有任何帧被丢弃

总之，我们每帧发送相同的状态数据包。它包含关于过去、现在和未来事件的所有实时数据

诀窍是保持这个数据集很小。因此，我们不发送play button pressed事件（其中有一个未绑定的编号），而是发送视频id、帧编号、开始掩码和结束掩码。（开始/停止遮罩是帧编号，如果开始遮罩为正，停止遮罩为负，则在帧编号处显示视频）

现在，我们需要能够在另一个视频期间或视频停止后不久启动视频。因此，我们考虑可以同时播放多少个连续视频。我们需要每个插槽，但我们可以立即重用它们吗？如果我们按了停止键，那么直到那时才知道停止掩码，那么重用插槽将使视频停止。这个视频将没有插槽，所以我们应该停止它。因此，是的，我们可以立即重用插槽，只要我们使用唯一的ID

其他提示：不要发送+1事件，而是发送当前总数。如果两个玩家必须更新一些总数，那么每个玩家都应该有自己的总数，在使用点对所有总数进行合计，但永远不要编辑其他人的总数