WebSocket上的TLV和子TLV或真正要使用的内容

我有一个利用web套接字传输数据的服务

我需要一种方法来编码一个树结构，并通过websocket传输该树结构。我一直在阅读关于TLV和sub-TLV编码的文章，这似乎是一个很好的想法，即它已经在Radius、LLDP等协议中使用，这证明了这是可行的，但我的问题是，这些协议通常在可信设备之间使用，即交换机/路由器之间（LLDP除外）。我的问题是，我将传输包含子TLV的TLV，子TLV具有随机大小/长度，并且没有静态定义的结构，例如，如果您查看第一个TLV中定义了子TLV的概念，即

扩展IS可达性TLV#22 然后您将看到该tlv具有如下结构：

  /* +-------+-------+-------+-------+-------+-------+-------+-------+
   * |                        Type                                   | 1
   * +---------------------------------------------------------------+
   * |                        Length ID                              | 1
   * +---------------------------------------------------------------+
   * |                        Neighbour ID                           | 7
   * +---------------------------------------------------------------+
   * |                        TE Metric                              | 3
   * +---------------------------------------------------------------+
   * |                        SubTLVs Length                         | 1
   * +---------------------------------------------------------------+
   * |                        SubTLVs value                          | variable
   * +---------------------------------------------------------------+
   * :                                                               :
   */

所谓结构，我的意思是我有预定义的7字节邻居ID，3字节度量，1字节子LVS长度，然后才是可变部分，但至少有一些位是在advanced中定义的，不能更改

现在通过阅读一些书籍（mainlly H Gredler完整的IS-IS路由协议2005-第296页），我发现了4种验证TLV的技术，即

1） 最大长度检查

2） 子TLV溢出检查

3） 离散长度检查

4） TLV内容模式检查

我根本不相信用户所做的事情，但我还有两个问题，即如何验证TLV值的位置 a） 随机长度/大小，即值的范围不小于1字节，不大于700 kb，以及 b） 我无法对该值执行任何模式检查，因为它是加密的，即不是可读形式，因此无法对其执行任何模式

因此，我的问题是： 如何实现相同的目标，即在其他结构中发送树结构，即可能是键值对或类似的结构（http正在使用此结构，这应该是有原因的）

TLV方式真的是在树结构中传输数据的最佳选择吗。我知道，如果我以二进制形式发送，我将一次击中两只兔子，即在发送文件（如图片）时，我不需要使用有趣的base64编码等。但我真正想要的是一个在L5-7上工作的协议（即通过websocket）这将允许be以树结构的形式发送数据，其中接收部分将能够识别和重新组装树，而不必考虑序列化和反序列化部分。那么，考虑到我一边使用java，另一边使用javasctipt，第二个最佳的TLV替代方案是什么呢

这是对评论中问题的回答，而不是原始问题。 有许多选项允许您检查协议错误：

由于您的

类型

使用的是while字节（您可能没有256种不同的类型），因此可以检查

类型

是否有效。如果不是，则存在协议错误

您可以在可变长度

值

字段后添加一个双字节字段，其中包含

值

字段的第一个和最后一个字节。如果这些不匹配，则存在协议错误；或

您可以在

值之后添加一个固定大小的MD5散列字段，并对照散列值检查值的内容。如果数据无效，则表示存在协议错误（或中间人攻击）

使用散列（校验和），如选项3（我建议使用MD-5，但任何校验和方法都很好）是检查数据完整性和协议一致性的好方法

使用第一个和最后一个字节检查（选项2）只检查协议一致性，而不检查数据完整性

验证

类型

字段（选项1）是检查协议完整性的一种简单方法，但容易出错（因为随机数据似乎更有效）

根据实际数据的长度（问题中的选项1-3）检查接收到的数据的长度容易出错，而且很可能 造成错误。这是因为多余的数据可能被视为下一个“帧”的一部分，因此只有在数据丢失且没有收到更多数据时才会显示错误

编辑：关于选项2和选项3的更多详细信息 使用第一个字节和最后一个字节验证时，每帧随机数据通过该验证测试的概率应为1:65536（对于非关键单帧数据来说，这可能是一个足够好的测试）

此外，如果数据树包含多个“数据字段”值，则该值的增长速度会非常快。（当提供随机数据时，4数据字段树的有效性概率仅为1:2^64

i、 e

假设数据长度为1字节，字节值为10（十六进制为0A）

第一个字节和最后一个字节都等于0A，这意味着验证字段必须是两个字节的值0A0A。这是2^16个选项中唯一可接受的值

但是，它不能保证数据的完整性

让我们假设客户端使用

evilproxy.com

的服务连接到我们的服务器

如果该值是一个值为100001的银行账号，

evilproxy.com

可以将账号更改为任何值，只要第一位和最后一位数字相同（即199991），允许

evilproxy.com

在协议消息仍然有效的情况下更改数据

另一方面，使用校验和（如MD5 hush）将意味着在本例中操作帐号时，校验和的值将发生变化

MD5使用128位（16字节），这意味着随机验证字段值“命中目标”的概率为1:2^128（这一概率可以忽略不计）

另一方面，如果

evilproxy.com

知道您使用的算法的“盐”