NTP / SNTP 网络对时速查（端口 / 报文 / Stratum）
依据 IETF 公开标准 RFC 5905（NTPv4）与 RFC 4330（SNTPv4）整理，适用于支持网络对时的播放器、中控、媒体服务器等设备。具体精度与实现以设备手册为准。
从一次多屏拼接错位说起
展厅入口一面九宫格拼接屏，早上开馆一放同步片，八块屏画面严丝合缝，唯独右下角那块总慢半拍——一辆车开过屏幕，到它这儿画面”咯噔”一下才跟上。你八成先怀疑那台播放器性能差、解码跟不上，换机器、降码率折腾一圈没用。病根往往不在播放，而在时间：这台机器的系统时钟跟其它几台差了几秒，同步播放的引擎按各自的”当前时间”去对齐帧，时钟都没对准，帧自然对不齐。让所有设备先向同一个时间源对准表，是同步播放的地基，这件事通常交给 NTP。这篇把 NTP 的报文、Stratum、四个时间戳怎么算偏移，到内网自建对时和多屏对不齐怎么查，一次讲透。
NTP 是什么
NTP（Network Time Protocol，网络时间协议）是在网络中同步各设备系统时钟的协议，至今仍是互联网上对时的事实标准。它解决的问题很朴素：每台机器都有自己的石英晶振，走时快慢略有差异，放几天就能漂出几秒；NTP 让设备周期性地问一台”表更准”的服务器”现在几点”，再根据网络往返时延校正、平滑地把本地钟拨到与源一致。
它的精妙在于不是简单地”服务器说几点就设几点”——那样会把网络传输的来回耗时算进误差里。NTP 通过一组时间戳估算出报文单程走了多久，把这段时延扣掉再调钟。展厅里多块屏要”齐步走”做同步播放、或多台设备的日志与排程要对齐，前提就是各设备系统时钟先对准同一个时间源，这就是 NTP 的活。
SNTP（Simple NTP，RFC 4330）是 NTP 的一个简化子集：报文格式、端口与 NTP 完全兼容，只是省去了完整 NTP 的多源择优与复杂滤波算法，适合资源有限的嵌入式播放器、终端。客户端用 SNTP、服务端用完整 NTP，二者可正常互通——展厅里绝大多数播放器内置的就是 SNTP 客户端，够用。
关键参数
| 项目 | 值 |
|---|---|
| 传输方式 | UDP（无连接，轻量，容忍偶发丢包） |
| 端口 | UDP 123（IANA 分配，服务端固定监听此口） |
| 当前版本 | NTPv4（RFC 5905），向下兼容 v3 |
| 时间戳格式 | 64 位 = 32 位秒 + 32 位小数（理论分辨率约 233 皮秒） |
| 纪元（epoch） | 1900-01-01 00:00:00 UTC |
| 报文头长度 | 48 字节（不含可选扩展 / 认证） |
| 典型局域网精度 | 亚毫秒至数毫秒（视网络与实现） |
| 2036 年翻转 | 32 位秒计数于 2036-02-07 溢出，需靠纪元编号扩展处理 |
报文头主要字段
| 字段 | 位宽 | 含义 |
|---|---|---|
| LI | 2 位 | 闰秒指示（Leap Indicator），预告本月末是否加/减 1 秒 |
| VN | 3 位 | 版本号，当前为 4 |
| Mode | 3 位 | 关联模式（见下表） |
| Stratum | 8 位 | 层级，离权威时间源的距离（见下表） |
| Poll | 8 位 | 轮询间隔，以 log₂ 秒表示（如 6 = 64 秒） |
| Precision | 8 位 | 本地时钟精度，以 log₂ 秒表示（负数，越小越准） |
| Root Delay | 32 位 | 到一级参考时钟的总往返时延 |
| Root Dispersion | 32 位 | 到参考时钟的累计误差离散度 |
| Reference ID | 32 位 | 参考源标识（Stratum 1 填 GPS/PPS 等 4 字符码） |
| 时间戳 | 各 64 位 | Reference / Origin / Receive / Transmit 四个 |
关键是尾部那四个 64 位时间戳，对时的全部数学都在这里。
Mode 字段取值
| 值 | 含义 |
|---|---|
| 1 | 对称主动（symmetric active） |
| 2 | 对称被动（symmetric passive） |
| 3 | 客户端（client） |
| 4 | 服务器（server） |
| 5 | 广播（broadcast） |
最常见的请求-应答是：客户端发 Mode 3，服务器回 Mode 4。展厅内网若设备极多、想省去逐台配置，也可用 Mode 5 广播——服务器周期性向网段广播时间，客户端被动收，但精度和安全性都不如请求-应答，一般只在轻量场合用。
Stratum（层级）含义
| 值 | 含义 |
|---|---|
| 0 | 未指定 / 无效（Kiss-o’-Death 等） |
| 1 | 一级服务器（直连参考时钟，如 GPS / 原子钟 / 授时电台） |
| 2–15 | 二级及以下服务器（逐级向上同步，每跳 +1） |
| 16 | 未同步（尚未锁定上游源） |
| 17–255 | 保留 |
Stratum 数字越大，离权威时间源越”远”，理论误差越大。它像家谱辈分：GPS 直连的是 Stratum 1，向它对时的是 2，再向 2 对时的是 3。展厅内自建一台对时服务器时，它的 Stratum 取决于它同步到的上游源——若它向公网 Stratum 2 对时，自己就是 Stratum 3；若装了 GPS 授时模块直连卫星，自己就能做到 Stratum 1。你若在服务器上看到 Stratum 显示 16，说明它还没跟任何上游对上，此时它给下游发的时间都不可信。
四个时间戳：偏移和时延怎么算
一次客户端-服务器对时，会用到四个时刻，理解它能帮你看懂为什么”网络慢”不等于”对不准”：
- T1（Origin）：客户端发出请求的本地时刻。
- T2（Receive）：服务器收到请求的时刻。
- T3（Transmit）：服务器发出应答的时刻。
- T4：客户端收到应答的本地时刻。
客户端拿到这四个数，算两件事：
- 往返时延 delay = (T4 − T1) − (T3 − T2)：总耗时减去服务器内部处理的那段，剩下就是报文在网上来回跑的时间。
- 时钟偏移 offset = ((T2 − T1) + (T3 − T4)) / 2：本地钟比服务器快还是慢、差多少。
这么算的妙处是默认来回网络时延大致对称，两个方向各占一半，于是能把单程时延剔除、只留下真正的钟差。你也就明白了：偶尔网络抖一下 delay 变大，NTP 会给这次采样打低权重，多轮采样里挑最干净的那次来定钟——这正是完整 NTP 比 SNTP 强的地方，SNTP 通常只按单次结果拨钟。
展厅落地：设备统一对时怎么搭
展厅里 NTP 很少让你”从零手搓”，它藏在中控和播放系统底层，但链路值得心里有数：
- 多屏同步对时：所有播放器 / 媒体服务器统一指向同一台 NTP 服务器，先把系统时钟对齐到毫秒级，再由播放引擎谈帧级同步。时钟对齐是同步播放的必要非充分条件——钟对齐了帧不一定齐，但钟没对齐帧一定不齐。
- 离线 / 内网展厅：很多展厅在内网、无外网可访问公共 NTP 源。这时在馆内局域网架一台 NTP 服务器（常开的服务器、工控机，甚至中控主机兼任），让全馆设备都向它这一个源对时。哪怕这台服务器自己的绝对时间不是”标准北京时间”也没关系——同步播放要的是所有设备时间彼此一致，而非绝对准，大家都跟同一个源走偏一样多，相互之间就是齐的。
- 对绝对时间也有要求时：若排程要跟真实时钟严丝合缝（比如整点触发外部联动），给内网 NTP 服务器加一个 GPS / 北斗授时模块直连卫星，就能让它做到 Stratum 1，绝对时间也准。
- 日志与排程对齐：设备时钟统一后，定时开闭馆、内容排程、故障日志时间戳才能互相对得上，出问题回溯时能拼出一条完整时间线。
落到运营层，这套对时能力通常被中控封装掉，你在 SoftControl 展厅中控 里配一次时间源、勾上”设备统一对时”，馆内 SoftPlayer 展厅播控 的多台播放器就自动向同一源对齐，同步播放和定时排程随之稳定。这跟 DMX512 灯光协议 里灯光场景被封装成”一键触发”是同一套思路——底层协议交给中控屏蔽，你只面对”设备已对齐、场景可编排”这一层。
故障排查表
| 现象 | 可能原因 | 排查 / 解决 |
|---|---|---|
| 多屏同步播放某块屏总错位 | 该机时钟未与其它机对齐 | 确认它与其它机指向同一 NTP 源且已同步成功 |
| 设备始终对不上时间 | UDP 123 被防火墙拦、或源地址填错 | 放行 UDP 123，核对 NTP 服务器 IP 可达 |
| 服务器 Stratum 显示 16 | 它自己没跟任何上游对上 | 检查它的上游源配置与网络，或接 GPS 授时 |
| 时间对上后又慢慢漂开 | 只设一次没持续对时 / 轮询间隔太长 | 确认对时是周期性的，缩短 Poll 间隔 |
| 内网设备时间统一但与真实时间差一截 | 内网源自身绝对时间不准 | 同步播放不受影响；需绝对准则给源接授时模块 |
| 换季某天时间跳了 1 秒 | 闰秒调整（LI 字段预告） | 正常现象，播放系统应能容忍 |
| 广播模式下部分设备没收到 | 网段隔离 / 交换机未转发广播 | 改用 Mode 3/4 请求-应答，逐台指定源 |
排查口诀：先确认”是否对上同一个源”，再确认”是否持续在对”，最后才谈播放引擎自身的同步。 展厅里绝大多数”对不齐”死在前两步。
进阶与边界
它不管帧同步：NTP 只负责把系统时钟对准，给不了”第 100 帧所有屏同一瞬间刷出”这种画面级同步。帧级同步靠播放系统自身的机制（同步信号、主从帧对齐、专用同步卡），NTP 是其地基而非全部。别指望配好 NTP 多屏就自动像素级同步。
精度天花板：普通网络 NTP 在局域网能做到毫秒级，对同步播放足够。若要求微秒级（工业、金融场景），那是 PTP（IEEE 1588，精确时间协议） 的地盘，靠硬件时间戳把网络设备处理时延也抠掉，展厅一般用不到。
动手检查清单
部署展厅设备对时前后，对着过一遍：
- 全馆播放器 / 中控 / 媒体服务器指向同一台 NTP 源
- 网络放行 UDP 123，源 IP 从各设备可达（ping / 抓包确认）
- 内网源自身已锁定上游或接授时，Stratum 不是 16
- 对时是周期性的，非一次性设置
- 若需绝对准，源已接 GPS / 北斗授时模块
- 时钟对齐后，再验证播放引擎的帧级同步机制已开启
小结
NTP 本身很朴素：UDP 123、48 字节报文、Stratum 记辈分、四个时间戳算出偏移和时延、把本地钟平滑拨准。展厅里它是同步播放和统一排程的地基——多屏对不齐，先别怪播放器，回头看各设备是不是对上了同一个源、是不是在持续对时。地基打牢，上层的帧同步和场景编排才立得住。
延伸阅读：了解 WebSocket 实时控制协议、TCP/UDP 通信基础 与 DMX512 灯光协议，或查看全部设备协议速查。
需要多块屏在展厅里”齐步走”播放？了解 SoftControl 展厅中控 与 SoftPlayer 展厅播控，查看解决方案与落地案例，或直接联系我们聊聊你的定制需求。