简介面向GNSS高精度定位从业者与导航通信开发者的NTRIP协议标准文档聚焦通过互联网传输RTCM差分数据的规范与实现依据。文件为1个PDF压缩包约863KB内容为RTCM 10410.1《Networked Transport of RTCM via Internet Protocol (Ntrip) Version 2.0》2021年1月版属于单一标准正文型资料便于检索条款与修订说明。已有1340人学习说明其在GNSS数据服务、参考站网和接收机联调场景中具有一定参考需求。文档围绕Ntrip系统概念、服务器与客户端角色、数据流管理、身份验证、速率控制及RTCM消息等核心内容展开并保留Amendment 1、Amendment 2与2021年最新修订信息可帮助读者对照协议字段、梳理数据链路和排查连接问题也适合作为教学引用与开发实现的案头资料。1. NTRIP 2.0一条差分改正流为什么不直接开个 TCP 端口第一次抓 NTRIP 的包多数人会愣一下满屏明文GET /BASE01 HTTP/1.1跟着User-Agent、Authorization、Transfer-Encoding: chunked就是一段被拉长的 HTTP 请求。这不是省事是刻意为之。NTRIP 2.0RTCM 10410.1从头到尾没打算发明新协议它把 HTTP/1.1 和 RTSP 砍到只剩“拉一条永不结束的流”所需要的那一小撮语义然后在上面跑 GNSS 改正数。值得较真的是这件事背后的约束厘米级定位依赖每一两秒刷新一次的差分改正这段数据要穿过移动网络、NAT、代理、鉴权还要一对多地分发给成百上千个流动站。自己造一套私有二进制协议这些轮子得重造一遍套在 HTTP 上代理、抓包工具、curl 全都白捡。RINEX 是事后复盘的观测文件NTRIP 是同一套数据在实时链路上的形态两边对照着看消息号和历元才咬得合。2. 四个角色与 mountpointCaster 在中间到底挡下了什么标准把系统拆成四块NtripSource、NtripServer、NtripCaster、NtripClient。名字看着像四个程序其实只有三个是软件实体第一个是逻辑概念。这个不对齐的地方是理解整套分发模型的第一道坎。2.1 NtripSource 不是一个程序四个角色的边界怎么划NtripSource 指的是“在某个物理位置产生数据流的那件事”可能是一台参考站接收机可能是网络 RTK 算法进程也可能是一段回放的历史数据。它本身不联网、不懂 HTTP只负责按秒吐 RTCM 帧。真正把它接上互联网的是 NtripServer——一个上传端程序从串口、本地 TCP 端口或内存队列里捞出字节用一条 HTTP 风格的 PUT/POST 长连接推到 Caster并声明“我推的是哪个 mountpoint”。这么切分的好处很直接参考站换机器、换串口卡、换采集程序只要 Server 还推同一个 mountpoint下游几百个流动站不需要改任何配置。反过来如果 Source 和 Server 合成一个程序更换硬件就等于更换服务地址运维成本会立刻变得难以控制。Caster 是唯一常驻的中心组件它维护 mountpoint 到“当前推流那条 TCP 连接”的映射表并把这一个上行流复制给 N 个下行连接。所谓一对多分发本质上就是在这个进程里做扇出。Client 端通常是接收机固件里的一个精简实现也可能是跑在手机或工控机上的软件。它对协议的要求极低能发一个 GET、能读字节、能按 RTCM 帧头0xD3切帧就行。标准反复强调“easy to implement with limited client or server resources”说的就是这条Client 侧的内存和算力预算往往只有几十 KB。2.2 mountpoint把“一条流”变成可寻址、可鉴权的资源mountpoint 是一个字符串标识符形如BASE01挂在 Caster 的根路径下客户端用GET /BASE01请求它。这个设计把“流”降维成了“资源”于是 HTTP 那一整套东西——路径、鉴权、状态码、缓存控制——全部可以原样套用。约束藏在细节里。一个 mountpoint 在同一时刻只允许一个 Server 推流否则 Caster 无法判断该把哪条数据复制给客户端常见的实现是后到的 Server 被拒绝或者把先到的踢掉两种策略在不同 Caster 上都能见到写对接代码时不能想当然。mountpoint 一般大小写敏感字符集限制在字母、数字和少数符号长度也有上限把空格、斜杠、#塞进去轻则注册失败重则被当成路径分隔符解析成另一个资源。提示客户端配置里多敲一个尾随空格表现是“认证一直失败”而不是“mountpoint 不存在”因为路径匹配失败常常被实现归到鉴权分支里统一返回 401。这个坑后面第 5 章还会碰到。2.3 sourcetable为什么服务发现用纯文本而不是接口Caster 必须让客户端知道“这里有哪些流、分别是什么格式、在哪个国家、大概多少码率”。标准给出的答案是 sourcetable一份纯文本表客户端GET /就能拿到表体以ENDSOURCETABLE结尾。它有三类记录每行一条分号分隔CAS;caster.example.net;2101;Demo Caster;demo-op;0;DEU;12.34;56.78;fallback.example.net;2101; NET;BASE01;demo-op;B;N;none;http://caster.example.net; STR;BASE01;Demo Site;RTCM 3.3;1004(1),1005(10),1012(5),1033(30),1074(1),1084(1),1094(1),1124(1);2;GPSGLOGALBDS;BASE01;DEU;12.34;56.78;0;0;sNTRIP;none;B;N;9800;CAS 描述 Caster 自身主机、端口、运营商、备用地址NET 描述一个网络运营方认证方式、是否收费、主页STR 描述一条具体的流。真正的信息密度在 STR 上FORMAT声明是大类RTCM 2.x / RTCM 3.x / 其他FORMAT-DETAILS列出这条流里实际会出现哪些消息号以及各自的周期比如1004(1)表示每秒一条 GPS 载波相位改正1074(1)表示每秒一条 GPS MSM4 观测。括号里是秒数不是频率——这个反直觉的写法坑过不少人。用文本而不是 JSON 接口取舍很清楚任何 Caster 都能在几十行代码里拼出这张表任何客户端用一个readline加split(;)就能解析出了问题用 curl 一看便知。代价是没有类型、没有转义字段里出现分号就完蛋扩展字段只能靠末尾的MISC兜着历史上不同厂商往里塞过各种私有内容。2.4 鉴权放在 Caster凭据在哪一层生效上传和下载用的是两套凭据。Server 推流时带的是“我有权发布这个 mountpoint”的凭据Client 拉流时带的是“我有权订阅”的凭据两者都在 Caster 上校验Source 和 Server 之间通常不做认证。放在 Caster 的理由是它掌握全局只有它知道当前有哪些 mountpoint、谁在线、某个账号是否已经超过了并发连接数。如果鉴权下放到 Server就得在每个参考站侧维护一份用户表几百个站点的账号同步会立刻变成运维灾难。代价是 Caster 成为单点认证逻辑的任何性能问题都会放大到全部连接上所以真实系统里这一层前面往往还挡着一层 TLS 终结和限流。3. HTTP 通道GET /MOUNTPOINT 之后那几百毫秒里发生了什么这是绝大多数 NTRIP 客户端实际走的路也是标准里被改得最多的一段。1.0 到 2.0 之间那些“清掉的设计问题和 HTTP 协议违规”八成集中在这里。3.1 请求行与 Ntrip-Version1.0 与 2.0 的分水岭就在这一行一个 2.0 客户端发出的请求大致长这样GET /BASE01 HTTP/1.1 Host: caster.example.net:2101 Ntrip-Version: Ntrip/2.0 User-Agent: NTRIP demo-client/0.1 Accept: */* Connection: close Authorization: Basic dXNlcjpwYXNz对应的成功响应HTTP/1.1 200 OK Ntrip-Version: Ntrip/2.0 Server: NTRIP demo-caster/1.0 Date: Mon, 11 Jan 2021 08:00:00 GMT Cache-Control: no-store, no-cache, max-age0 Pragma: no-cache Connection: close Content-Type: gnss/data Transfer-Encoding: chunkedNtrip-Version: Ntrip/2.0这一行是整个协议的开关。Caster 读到它才允许启用 chunked 编码、才按 2.0 的 header 语义回包读不到就退化成 1.0 兼容模式用最保守的方式往外吐字节。这也是为什么很多“明明 Caster 支持 2.0我的程序却在收 1.0 行为”的问题根因只是请求头漏了一行。响应里的Content-Type: gnss/data是 NTRIP 自定义的 MIME 类型不是标准注册类型但它有实际作用中间的代理和防火墙看到这个类型就知道这是一条不该缓冲、不该缓存的流。Cache-Control: no-store和Pragma: no-cache是配套的保险因为改正数一旦被缓存客户端拿到的就是过期星历。sourcetable 请求走的是同一个入口只是路径是/。1.0 时代这里返回的状态行是SOURCETABLE 200 OK一个不合法但被广泛容忍的写法2.0 改成了标准的HTTP/1.1 200 OK加Content-Type: text/plain并且因为表体长度有限可以正常给Content-Length不需要 chunked。这个改动看似洁癖实际解决的是“通用 HTTP 客户端解析不了这张表”的问题。3.2 反向 NMEA客户端为什么要把自己的位置发给 Caster网络 RTK 的核心是“按流动站的位置生成虚拟观测值”所以 Caster 必须知道客户端大概在哪。HTTP 是请求-响应模型请求发完之后理论上只能读但 TCP 连接本身是全双工的NTRIP 2.0 就利用这一点连接建立后客户端可以持续往这条连接的上行方向写 NMEA GGA 语句Caster 解析出经纬度高程转给对应的 ServerServer 再据此生成改正数。这个设计的巧妙之处在于零额外连接不需要为“上报位置”再建一条链路也不需要定义新的协议动词上行数据就是裸文本行。条款里专门为此留了位置说明它不是灰色 hack而是被正式承认的能力。频率上常见的做法是 1 Hz高动态场景会提到 5 Hz 甚至 10 Hz。发太快没意义——虚拟观测值的历元间隔受源端观测采样率限制把 GGA 刷到 20 Hz 只会让 Caster 多做无用解析发太慢则会在移动过程中拿到滞后于真实位置的改正数表现为“停车时精度很好一开起来就飘”。还有一个容易忽略的点GGA 里的定位质量指示和卫星数如果填得离谱比如固定填 0 颗星部分 Caster 会直接判定为无效语句丢弃链路看起来是通的实际根本没生效。3.3 chunked一条永不结束的响应怎么划边界这是 2.0 相对 1.0 最实质的一处改动。GNSS 流没有终点Content-Length无从填起1.0 的做法是干脆不给长度让客户端一直读到连接关闭为止靠 EOF 判断结束。这个方案在直连时能用一遇到代理就崩代理不知道响应体多长要么一直缓冲到连接关闭于是客户端一个字节都收不到要么按自己的超时把连接掐掉。Transfer-Encoding: chunked把流切成自描述的块每块前面一行十六进制长度块尾回一个 CRLF长度为 0 的块表示结束。代理可以边收边转客户端也能在每块边界上做一次 flush而不必猜“这堆字节到底是不是完整的一帧”。import socket HOST, PORT, MOUNT caster.example.net, 2101, BASE01 req ( fGET /{MOUNT} HTTP/1.1\r\n fHost: {HOST}:{PORT}\r\n Ntrip-Version: Ntrip/2.0\r\n # 漏掉这行Caster 会按 1.0 行为回包 User-Agent: NTRIP demo/0.1\r\n Authorization: Basic dXNlcjpwYXNz\r\n # base64(user:pass)不是明文 \r\n ) sock socket.create_connection((HOST, PORT), timeout10) sock.sendall(req.encode(ascii)) f sock.makefile(rb) # 1) 先把响应头读干净逐行读到空行为止状态码和 Transfer-Encoding 都在这里 while True: line f.readline() if line in (b\r\n, b\n, b): break # 2) 之后进入 chunked 帧十六进制长度[;扩展]\r\npayload\r\n while True: size_line f.readline().strip() size int(size_line.split(b;)[0], 16) # 分号后面是 chunk 扩展可忽略 if size 0: break # 0 长度块 流结束 payload f.read(size) f.read(2) # 吃掉块尾固定两字节 CRLF feed_rtcm(payload) # 交给 RTCM 3.x 帧解析器几个参数值得盯住size_line.split(b;)[0]必须写因为允许出现 chunk 扩展f.read(size)要用精确读用read(4096)会把下一块的长度行一起吃进去f.read(2)那两字节不能省省掉之后下一次readline读到的是\r\n拼上长度解析会一路错位。feed_rtcm这层要做的事是按0xD3找帧头、读 10 位长度、校验 CRC24Q然后按消息号分发——这一步和 NTRIP 无关属于 RTCM 本身的帧格式。还有一个现实约束chunk 大小由 Caster 决定可能一条 RTCM 消息一个 chunk也可能攒几百毫秒一个 chunk。客户端不能假设“一个 chunk 正好一帧”必须自己维护缓冲区做粘包拆包。3.4 认证与错误处理401 之后 Caster 到底在等什么标准列了两种认证Basic 和 Digest。Basic 把user:password做一次 base64 塞进Authorization头本质是明文只能靠外层 TLS 保命Digest 用 nonce 做挑战应答密码不上链路但需要服务端保存明文口令或等价物实现复杂度也高。现实里绝大多数 Caster 只支持 Basic于是部署方式变成“Basic 认证 TLS 前置”。这套组合不是协议规定的是被生态逼出来的接收机固件里塞一个完整的 Digest 实现成本不低而运营商又不太愿意在公网裸奔密码。错误处理遵循 HTTP 状态码语义凭据缺失或错误回 401 并带WWW-Authenticatemountpoint 不存在回 404请求头畸形回 400Caster 侧源端掉线或达到连接上限则常见 503 之类。这里有个容易误解的行为401 之后 Caster 可能不会立刻断开而是保持连接等你重发带凭据的请求具体是关还是留取决于实现。写客户端时不要假设“401 意味着连接已断”重试之前先确认 socket 状态否则会踩到向半关闭连接写数据的坑。4. RTSP/RTP 通道标准作者为什么又开了第二条路如果 HTTP 已经够用2.0 没必要引入 RTSP。这条分支存在说明纯 TCP 方案在某些场景下确实不合适。4.1 在 HTTP 之外再开一条路的动机差分改正是“最新值有效”的数据一个 3 秒前的改正数如果这 3 秒里卫星几何或电离层已经变了它的价值远低于刚生成的那个。而 TCP 的可靠传输语义是“不丢、按序”一旦中间某段丢包触发重传后面已经攒好的新数据全部堵在接收缓冲区里排队等重传补上才继续交付。这就是队头阻塞在高实时流上的具体表现带宽没满延迟却涨了。RTP over UDP 把这条约束反过来丢了就丢了接收端拿到的永远是当前最新的包不会为了补一个过期包而卡住后面的。代价是要自己处理乱序、丢包统计和会话保活——这些正是 RTSP 那部分控制逻辑要干的活。4.2 SETUP / PLAY / TEARDOWN控制面与数据面被拆开RTSP 的分工很明确控制走 TCP数据走 UDP两条通道各管各的。# 1) 建立会话告诉 Caster 我在哪个 UDP 端口上等数据 SETUP rtsp://caster.example.net:2101/BASE01 RTSP/1.0 CSeq: 1 Transport: RTP/UDP; unicast; client_port6000-6001 # 2) Caster 回自己那一侧的端口并给出会话号 RTSP/1.0 200 OK CSeq: 1 Transport: RTP/UDP; unicast; client_port6000-6001; server_port7000-7001 Session: 12345678 # 3) 开始推送 PLAY rtsp://caster.example.net:2101/BASE01 RTSP/1.0 CSeq: 2 Session: 12345678 # 4) 结束 TEARDOWN rtsp://caster.example.net:2101/BASE01 RTSP/1.0 CSeq: 3 Session: 12345678client_port给的是成对的端口偶数给 RTP 数据下一个奇数给 RTCP 控制报文。Caster 收到PLAY之后开始往这对端口打 UDP 包TEARDOWN之后停止。Session是后续所有请求的凭据没有它 Caster 认不出你属于哪个会话。这个拆分带来一个明显好处控制通道可以承载鉴权、错误回执、参数协商而数据通道保持极简接收端只需要一个 UDP socket 加一个 RTCM 解析器。坏处是两条通道的生命周期要自己对齐一条断了另一条未必知道——这正是下一节要说的。4.3 Keep-Alive 与初始 RTP 包UDP 上没有“连接”这回事UDP 是无连接的Caster 无法通过 socket 状态判断客户端还在不在。它唯一的信息来源是 RTSP 控制连接上的保活。客户端必须周期性地发保活请求常见实现是发一个带Session头的空 RTSP 请求或用GET_PARAMETER探测间隔要短于 Caster 的超时阈值。具体数值各家不同标准给的是原则性建议工程上一般取几十秒量级配置时以对端文档为准。漏发保活的后果很典型数据流跑了几十分钟突然安静客户端 socket 还开着就是收不到包。原因是 Caster 侧判定会话超时回收了 UDP 发送通道但控制连接可能还没断干净于是出现“连接活着、数据死了”的假象。初始 RTP 包解决的是另一个问题。客户端大多在 NAT 后面NAT 只为“从内向外发过包的端口”保留映射。如果客户端只发了SETUP和PLAY就干等NAT 上可能还没有 6000 端口出向流量的记录Caster 打过来的第一个 UDP 包会被直接丢弃。标准的做法是 Caster 在正式开始推流前先往客户端端口发一个初始 RTP 包把 NAT 的映射关系“捅”出来。这个包可能不含有效载荷序号和时间戳也可能是占位值接收端必须能识别并丢弃它而不是当成第一帧数据塞进解析器。4.4 Plain RTP砍掉控制面之后剩下什么第三种模式更彻底不要 RTSPCaster 直接往一个事先约定好的地址和端口推 RTP。适合的场景很明确——固定接收端、内网分发、一对多的单向广播比如把一路改正数同时推给同一网段里的多台设备。砍掉控制面之后鉴权、会话管理、按需启停全没了取而代之的是静态配置。它的可靠性完全依赖网络本身接收端重启Caster 不知道Caster 重启接收端也不知道只能靠超时自己发现没数据了再重建。所以这种模式在生产环境里通常只出现在受控网段公网场景还是得走前两种。5. 排查NTRIP 链路上最容易翻车的五种现场协议本身不复杂复杂的是它横跨了应用层、传输层和网络边界。下面这五类现象基本覆盖了对接新 Caster 时八成以上的时间消耗。5.1 现象200 OK 回来了读到的却是十六进制长度行现象连接建立、状态码 200但读出来的前几个字节不是0xD3开头而是一串像1a4这样的十六进制数字加 CRLF。原因Caster 回了Transfer-Encoding: chunked客户端没解帧把 chunk 长度行当成了 RTCM 数据。1.0 时代的代码直接裸读 socket升级到 2.0 后就暴露了。解决先在响应头里查Transfer-Encoding有 chunked 就走解帧路径同时确认请求里带了Ntrip-Version: Ntrip/2.0否则某些 Caster 会用不带 chunked 的老方式回包你的解帧逻辑反而会读错。# 只看响应头确认 Caster 到底用了哪种 framing curl -s -o /dev/null -D - --max-time 5 \ -H Ntrip-Version: Ntrip/2.0 -u user:pass \ http://caster.example.net:2101/BASE015.2 现象凭据明明对Caster 一直回 401现象用户名密码在别处能登这里反复 401日志里看不到任何请求到达业务逻辑。原因三种可能——base64 编码前拼错了分隔符mountpoint 带了尾随空格或大小写不匹配被路径匹配失败统一归到鉴权分支密码里含、:、#等字符配置文件的解析环节把它截断了。解决用 curl 的-u而不是手写Authorization头先排除编码问题再单独请求/拉 sourcetable很多 Caster 对 sourcetable 不鉴权确认表里确实有你想要的 mountpoint 原始拼写逐字符比对注意大小写。5.3 现象跑了半小时好好的突然静默现象数据流正常接收几十分钟后停止TCP 连接没断也没有 FIN就是没有新数据。原因Caster 侧会话超时被回收。走 HTTP 通道时可能是触发了最大连接时长限制走 RTSP 通道时是保活没发或间隔太长。也可能是源端 Server 掉线Caster 没关客户端连接只是不再有数据可转发。解决客户端侧加一个“数据静默超时”超过 N 秒没收到完整帧就主动断开重连别指望对端通知你。RTSP 通道按对端要求周期发保活。同时向运维确认源端在线状态——区分“我这边断了”和“上游没数据”这一步能省掉大量无效排查。5.4 现象定位只有米级怎么调都不是厘米级现象链路完全正常消息也在解但固定解始终拿不到最好也就是浮点解或者米级。原因多数是拿错了流。sourcetable 里FORMAT-DETAILS决定了这条流里到底有什么如果只有1004GPS L1/L2 观测而没有1074、1084这类 MSM 消息多系统多频的整周模糊度就固定不了如果流动站距离参考站几十公里以上电离层和对流层的空间去相关会让误差直接吃掉厘米级余量。解决把 sourcetable 里目标 STR 记录的FORMAT-DETAILS抄出来和接收机实际解出的消息号列表逐项对照。缺 MSM 就换流距离太远就换更近的站或改用网络 RTK 服务并且确认 GGA 一直在正常上行。5.5 现象RTSP 走通了UDP 端口一个包都没收到现象SETUP和PLAY都回 200Session也拿到了抓包看本机 UDP 端口干干净净。原因NAT 或防火墙把入向 UDP 挡了。客户端的 6000 端口还没产生出向流量映射不存在或者企业防火墙策略默认拒绝所有入向 UDP。解决先确认接收端确实 bind 在client_port指定的偶数端口上且先于PLAY完成再检查 Caster 是否发了初始 RTP 包很多实现有开关实在不行退到 RTSP over TCP 或直接回 HTTP 通道用可控的延迟换连通性别在 UDP 上死磕。6. 设计取舍把流协议做成 HTTP 子集代价付在哪里NTRIP 的设计哲学可以用一句话概括用最小的实现成本换取最大的生态兼容性。这个选择带来的收益在二十年后依然明显——任何一台能发 HTTP 请求的设备都能当客户端任何懂 HTTP 的工程师半天就能看懂抓包。但代价也是实打实的值得在选型时想清楚。维度HTTP 通道RTSP/RTP 通道Plain RTP传输TCP控制 TCP 数据 UDPUDP丢包行为重传可能队头阻塞丢弃拿最新值丢弃拿最新值鉴权Basic/Digest成熟借 RTSP 头承载无会话管理无靠连接本身Session Keep-Alive无穿透性好走标准端口需处理 NAT 与 UDP 策略差适合场景公网、移动网络、通用客户端低延迟、内网、可控网络固定接收端广播真正值得琢磨的是第二列和第一列的差异。同样的数据走 TCP 会为了补一个已经过期的包而拖慢后面的新包这在“最新值有效”的流上是纯粹的成本但换成 UDP 就要自己补上会话、保活、NAT 穿透这三块复杂度和排障难度成本文还有配套的精品资源点击获取