我已经使用了一些协议，并编写了自己的协议。我写了一些消息格式，只有1个字符来标识消息，有些则有4个字符。我觉得我没有足够的经验来判断哪个更好，所以我正在寻找一个答案来描述哪个场景可能比另一个好。
对于性能，您可以想象发送2个字节（A%1i）比发送5个字节（ABCD%1i）更快。但是，我注意到在使用1字节前缀编写协议时，如果您的错误导致代码无法从套接字中读取足够的数据，则可能会将垃圾数据传入系统。
4字节前缀的目的是为了保证您的消息是干净的吗？对于你牺牲的表现，它是否值得？你真的在牺牲任何表演吗？也许最好有2或3个字节的前缀？
我不确定这个问题是否应该特定于TCP，或者它是否适用于所有传输协议。对此的建议很有意思。
更新：有兴趣，我会提到Synergy使用4字节的消息前缀，因此对于鼠标移动增量，标头大小与实际数据相同。有人建议只使用1或2字节前缀来提高效率。我想知道这有什么缺点？
更新另外，如果您担心垃圾数据，我想知道握手是否真的很重要。 Synergy有很长的握手（几个字节），所需的4字节消息前缀是什么？我最近制定了一个只有1字节握手的协议，结果证明这是一个坏主意，因为不兼容的协议正在用不良数据向系统发送垃圾邮件（在此背后，我可能会建议至少进行长时间的握手）
答案 0 :(得分：1)
标题的目的是让您更轻松地解决frame synchronization problem（byte aligning in serial communication）。 为了同步，接收器在数据流中查找“看起来像”消息开头的任何内容。 如果你有 lot 不同类型的有效的消息开头标题，并且它们都是1个字节长，那么你将不可避免地得到很多“错误的帧同步” - 来自某些东西的垃圾“看起来像”一个消息开头标题，但不是。 最好选择一些其他标题，使得“不太可能”串行数据流中的任何内容“看起来像”一个有效的消息开头标题。
无论您如何design the packet header，都不可避免地会有垃圾数据进入您的系统。 无论你使用什么来处理这些其他问题（例如消息中间偶尔的位错误）也应该足以处理偶尔的“错误帧同步”垃圾。 在某些系统中，任何不良数据都会被新的良好数据快速覆盖，如果你眨眼，你可能永远不会看到坏数据。 其他系统至少需要某种error detection in the footer来拒绝不良数据。 然而，其他系统不仅需要检测此类错误，而且还要不断地重新发送该消息 - 直到双方都确信已成功接收到该消息的无错误版本。
正如Oleksi暗示的那样，some systems latency Synergy在发送单个二进制位（100 ms）和发送10个字节（102.4 ms）之间没有显着差异。 因此，与使用更详细的标头（更容易调试;更容易实现向后兼容和向前兼容;更容易测试效果）相比，使用微型标头（延迟减少2.4％！）的优势可能不值得“隔离”中的微小变化，而不是将双方同步升级到与旧协议完全不兼容的新协议。
也许你可以通过以下方式获得两全其美：（a）在很少使用的消息上保留冗长，易于调试的标题，以至于小标题的影响太小而无法测量（我怀疑它几乎是所有消息），以及（b）为任何类型的消息引入“微小标题”格式，其中微小标题的效果“明显更好”或至少可测量。 看起来Synergy协议足够灵活，可以以一种易于与其他类型的消息头区分开来的方式添加这种“小头”格式。
我在笔记本电脑和一些台式机之间使用{{3}}。我很高兴有人试图让它变得更好。
答案 1 :(得分：0)
性能取决于您发送的消息的内容。如果您的内容是几千字节，那么标题的字节数并不重要。现在，我会选择最容易使用的方案，因为与您发送的实际数据相比，发送一个字节或四个字节之间的性能差异可以忽略不计。