波仔
📹 第十章 GB／T 28181协议原理
📄 一句话概括

国标对控制的要求就一条：快。一般认为 200 毫秒以内，人会觉得「跟着手走」。 这 200 毫秒里，网络只占一半，另一半是机械——所以优化控制的方向不是压字节，是少往返。

📝 本节和前面几节的关系

前面讲的是「怎么转」。这一节讲「转到什么程度算合格」。 它没有具体数值指标，只有工程上的经验阈值，但阈值怎么来的，值得算一遍。

一、200 毫秒怎么分

云台指令从手到画面，要过四段：终端到平台、平台内部处理、平台到设备、设备执行机构。 同城专线两段网络加起来一百毫秒上下，平台内部几十毫秒，机械那一段六七十毫秒。 加起来正好卡在两百毫秒边上。 机械那一段最容易被忽略，也最难优化：电机从静止到额定转速要时间，减速停车也要时间。 这一项和网络无关，换个千兆网也省不下来。 所以「云台反应慢」这个抱怨，一半锅在网络，一半在机械。 拿网络当唯一嫌疑人，往往查不出结果。 还有一个常被忘掉的延迟是「码流本身的延迟」： 编码器要攒一帧才能编，解码器要攒几帧才能播，这两头加起来可能就有两三百毫秒。 所以实际上「操作—看到结果」的总延迟，往往比两百毫秒大。

二、并发不是吞吐

控制指令和视频流是两种完全不同的负载：视频是「持续的大流量」，控制是「偶发的小报文」。 所以评价平台不能只看「能扛多少路视频」，还要看「同一时刻能处理多少条控制指令」。 后者往往先到瓶颈。 原因是控制指令通常要「串行化到设备」：一台球机同一时刻只能执行一条云台指令， 二十个人同时推，后面十九条只能排队。 正确做法是「后到的覆盖先到的」：云台只关心「现在往哪转」，不关心「刚才转过哪」。 把队列改成「只保留最新一条」，延迟立刻降下来。 这就是「控制是有状态的」和「视频是无状态的」的区别： 视频丢一帧没关系，控制丢一条可能就停在那儿了。 所以两者的重发策略也不一样。

三、指令要幂等

控制报文会重发：网络超时、SIP 重传、平台重试，同一条指令可能到两次。 如果指令不幂等，后果很直接：「向左转 10 度」到两次，就转了 20 度。 连续转动是幂等的（转就是转），相对位移和绝对定位不是。 所以设计接口时要先问一句：「这条指令重发一次，结果会不会变」。 会变的，就得带序号去重。 还有一条工程经验：控制指令的超时时间不要设太长。 设五秒，用户早就不看那个方向了，指令才发出去，很难解释。 一秒左右超时、失败就丢，比「保证送达」更符合人的预期。

四、动手 Demo：控制时延的预算，和本机实测的那一段

先把 200 毫秒拆成四段预算，看各占多少。 再用本机回环实测一段「协议栈本身要多久」，看它到底占不占地方。

budget = [("终端到平台", 30), ("平台内部", 30),
          ("平台到设备", 60), ("设备执行机构", 70)]
total = sum(x[1] for x in budget)

# 本机回环一问一答，量协议栈本身
srv.bind(("127.0.0.1", 0)); srv.listen(1)
cli.connect(srv.getsockname())
t0 = time.perf_counter()
for _ in range(500):
    cli.sendall(b"A5 0F 01 02 80 00 00")
    conn.recv(64)
dt = (time.perf_counter() - t0) / 500
print("本机一次往返 %.1f 微秒" % (dt * 1e6))
print("跨城按 40 毫秒算，倍数约 %.0f" % (40 / (dt * 1000)))

实跑输出：

--------------------------------------------------------------------
控制时延的预算，和本机实测的那一段
--------------------------------------------------------------------
**国标对控制的要求就一条：快**。
**云台指令发出去，人要觉得「跟着手走」，一般认为 200 毫秒以内算跟手。**
**这一节把这 200 毫秒拆开，看它花在哪。**

  环节                   预算            占比        说明
  ---------------------------------------------------------------------------
  **终端到平台往返**     **30 毫秒**     **16%**     **同城专线**
  **平台内部处理**       **30 毫秒**     **16%**     **查表、鉴权、转发**
  **平台到设备往返**     **60 毫秒**     **32%**     **设备在另一段网络**
  **设备执行机构**       **70 毫秒**     **37%**     **电机启动＋减速**

  合计 190 毫秒，离 200 毫秒还剩 10 毫秒余量

**第四行占了三分之一还多**，
**这一项是唯一不受网络影响、也最难优化的**——**电机从静止到额定转速要时间，减速停车也要时间。**
**所以「云台反应慢」这个抱怨，一半锅在网络，一半在机械。**

  本机回环一问一答 500 次，平均每次 16.0 微秒
  折算成「往返」概念：0.016 毫秒

**这个数只有十几微秒，比预算里的任何一项都小两个数量级**——**它说明协议栈和报文本身不是瓶颈。**
**但也要说清楚：这测的是本机内存里搬数据，广域网那一段的时延它一点都没测到。**
  同样 7 字节的报文，本机 0.016 毫秒，跨城按 40 毫秒算
  倍数：约 2502 倍

**两个数量级的差距全在路上**，**所以优化控制的正确方向是「少往返」而不是「少字节」。**
**国标把云台指令设计成「一个 SIP 报文带完」，就是要让它一次往返结束**——
**这比把报文压缩一半有用得多。**

**最后一句关于并发的**：**控制指令不该排队。**
**如果平台按顺序处理，二十个人同时推云台，最后一个人的指令要等前面十九条执行完。**
**正确做法是「后到的覆盖先到的」**——**云台只关心「现在往哪转」，不关心「刚才转过哪」。**

四段加起来 190 毫秒，离 200 只剩 10 毫秒余量—— 这个预算本身就说明了为什么现场经常「差一点」。 机械那一段占 37%，是四段里最大的一块，而且它是唯一「换个好网络也省不下来」的一块。 本机实测那一行只有十几微秒：比预算里任何一项都小两个数量级。 这说明协议栈和报文本身完全不是瓶颈。 但要说清楚它测的是什么：这是本机内存里搬数据，广域网那一段的时延它一点都没测到。 同一份七字节报文，跨城按四十毫秒算，差了两千多倍。 所以优化控制的正确方向是「少往返」而不是「少字节」： 把报文压小一半，省下的是微秒；少一次往返，省下的是几十毫秒。 国标把云台指令设计成「一个 SIP 报文带完」，就是这个道理。

30 秒实验

  1. 算一下：四段预算 30＋30＋60＋70，合计多少？（190 毫秒）
  2. 想一下：为什么机械那一段换网络也省不下来？
  3. 想一下：为什么控制指令的队列要「只保留最新一条」？

常见误区

  1. 以为「控制慢一定是网络问题」。 机械那一段占三分之一还多，换网络省不下来。
  2. 以为「并发就是能扛多少路流」。 控制指令的并发是另一个维度，往往先到瓶颈。
  3. 以为「指令保证送达最好」。 控制超时要短，送达一条过期指令没有意义。
自测三问（点开对答案） 1. 控制时延的四段分别是什么？ —— **终端到平台、平台内部处理、平台到设备、设备执行机构**。 2. 哪些控制指令不幂等？ —— **相对位移和绝对定位**；**连续转动是幂等的**，转就是转。 3. 为什么控制指令的超时要设短？ —— **过期指令没有意义**，**用户早就不看那个方向了，发出去反而难解释。**

下一节讲安全：密码怎么做到从头到尾不上线，以及它防不住什么。

相关笔记