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