用于实时数据和元数据的TCP通信协议

Question

我是相当新的网络协议设计，并希望对我的问题提出建议。

我的要求

1. 我需要将实时数据从TCP套接字客户端传输到服务器。我在这里没有UDP的选择
2. 数据需要元数据描述符才能在服务器端正确解码。此描述符可以在运行时代表客户端用户更改
3. 我需要偶尔从客户端向服务器发送控制命令以进行数据操作

设计A

• 设置两对套接字服务器和客户端，一对用于需求#1，另一对用于需求#2和#3；现在就叫它们“数据隧道”和“元数据隧道”

专业人士

• 概念清晰，易于在实现中隔离元数据和数据模块。
• 实时数据，即#1，可以以字节形式发送，不需要额外的数据封装。

欺骗

• 需要在两个隧道之间进行同步，以避免由于控制更改而导致的解码错误或小故障

设计B

• 仅使用一个通道
• 分别为实时数据和元数据设计至少两个分组数据结构。实时数据包将包括其解释
• 让数据和元数据共享唯一的通道

专业人士

• 每个实时封包都与元数据捆绑在一起，并保证正确解码。
• 只使用一个线程。

欺骗

• 在接收器数据处理上更复杂的实现，例如，在接收数据包时必须区分数据和元数据。
• 单个隧道上的流量更繁忙。我打赌控制消息不会阻塞实时数据消耗，但我真的不知道。

我倾向于设计一个比正确解码更安全的“实时”保证。但我想和专家们再次核实我的想法。

我知道有数百种通信协议，但老实说，当看到随机的协议文档时，我会感到头晕目眩。毕竟，我的应用程序相对轻量级，所以滚动自己的应用程序似乎更有意义。

顺便说一下，我使用Google Protobuf进行协议设计。我假设它的性能是实时的。

如有任何建议，将不胜感激。

Answer 1

正如@RonMaupin在评论中提到的，TCP和“实时”并不特别兼容，因为TCP优先考虑“正确获取字节”而不是“在特定时间框架内获取字节”。

也就是说，您可以通过TCP实现的是“尽可能快地获取字节”，只要您同意在某些情况下（例如，一个正在丢弃大量数据包的网络），“尽可能快”可能不会那么快。

关于要使用多少个TCP流，与做出该决定相关的TCP质量是TCP流始终强制按顺序/FIFO传递该流中的字节。也就是说，您发送（）到TCP套接字的所有字节都将按照接收程序的确切顺序为recv（）'d——这是一种对您有效或对您不利的行为，因此您希望以适合您的方式设计您的程序。特别是，在决定是使用一个还是多个TCP连接时，问问自己，“我发送的数据是否需要以与发送相同的顺序接收，还是没关系？”如果严格的FIFO排序很重要，那么单个TCP流是最好的选择；OTOH如果您有两种类型的数据，并且B型数据在逻辑上独立于A型数据，那么您可以考虑为B型数据提供自己的单独TCP流，这样A型数据的丢包就不会减慢B型数据的传输。

在任何情况下，您都希望至少有一些最小的协议/帧（例如，在每个数据消息之前至少有消息类型和消息大小标头字段），以便接收方不必猜测其接收的字节的含义。（即使您一开始不需要它们，您也希望在第二个版本中使用它们，以帮助保持与协议早期版本的向后兼容性）

让您的TCP数据尽可能快/低延迟的其他一些建议：

>

禁用Nagle算法（永久或至少在您完成send（）-ing特定的数据突发之后）-否则您将获得200毫秒的不必要延迟大部分时间。

假设您的程序在具有大量RAM的平台上运行，setockopt（）带有SO_SNDBUF和SO_RCVBUF选项，以使您的发送和接收套接字缓冲区尽可能大；这减少了由于缓冲区中没有空间可用而导致缓冲区填满和数据包丢失的可能性。

如果可能，请设计发送算法，以便仅在最后一个可能的时刻生成要发送的数据，而不是将要提前发送的大量数据排队。例如，如果（由于某些触发事件）您的代码决定需要尽快通过TCP套接字发送特定数据结构的当前状态，而不是序列化数据结构并立即将序列化的字节排入队列（和/或）只需设置指示需要发送结构的脏标志。然后，下次套接字指示它已准备好写入时，即序列化数据结构并将其发送到套接字的时间。这样做的好处是，如果您快速连续收到10个触发事件，使用这种脏标志设计，最终仍然只能跨一次发送最终版本的数据结构，而不是连续发送10次。第二个好处是，这限制了可以排队等待发送的积压数据，从而减少了数据更新的平均延迟。

在接收端，由一个专用的高优先级线程在一个紧密的循环中完成recv（）调用，该线程只需尽快接收数据，然后将其排队以供进一步处理。这里的想法是尽量减少接收TCP套接字的传入数据缓冲区变满的可能性，因为如果它变满，一些传入的TCP数据包可能会被丢弃，迫使TCP退避并重新发送，这将减慢传输速度。