简介：NTRIP协议2.0版官方标准文档（RTCM 10410.1，2021年1月12日发布），面向GNSS高精度定位开发者、测绘与导航算法工程师，以及从事自动驾驶、无人机、精准农业等厘米级定位应用的从业人员。该标准由RTCM第104专门委员会制定，整合了RTCM Paper 111-2009（含修正1）、139-2011（含修正2）及2021-SC104-1216 STD的修订内容，系统阐述通过互联网传输RTCM差分数据的协议框架，涵盖系统概念、服务器与客户端交互、数据流订阅与身份验证、速率控制及RTCM 2.x/3.x消息格式等核心章节，并附有各次修正的替换页说明。压缩包内为1个PDF文件，约863KB，便于离线查阅。已有1340人学习下载。读者可以依据这份文档核对协议字段与握手流程，排查NTRIP客户端连接、挂载点认证、数据断流等问题，也可将其作为RINEX观测数据配套差分服务开发的参考依据。

1. 一句话说清 NTRIP：你的定位器为什么非得“连上网”才能到厘米级

如果你用过手持导航设备，大概都碰到过一个困惑：地图上标的就是脚下这块地方，可屏幕上那个定位点总在十几米开外来回飘，一栋楼的宽度说没就没。这不是设备坏了，而是单靠自己接收卫星信号来测距，天生就带着十几米的模糊。要把它压到厘米级，得有人在旁边“递小抄”，告诉你的接收机：此刻天上那几颗星的信号误差有多大，你把这部分减掉就行。NTRIP（Networked Transport of RTCM via Internet Protocol）就是这份小抄的投递协议，是一套把导航卫星改正数据经互联网稳定送到用户手上的国际标准。它本身不负责“算”，只负责“送”——送得准时、送得省、送得能被五花八门的设备看懂。

2. 为什么需要 NTRIP：十几米的误差，是怎么被一份“共享小抄”抵消的

2.1 单机定位的误差不是随机的，而是“扎堆”出现的

很多人以为定位不准是“信号不好”这么简单，其实背后是一串可以逐项拆开的误差源。卫星上的原子钟并不完美，会有钟差；广播给你的卫星位置（星历）也有偏差；信号穿过电离层和对流层时会被拖慢，延迟量随天气和太阳活动变化；再加上建筑、水面反射造成的多路径效应，这些加起来就是十几米的模糊。

关键在于：这些误差里的大头，比如卫星钟差、星历误差、电离层与对流层的延迟，对地面上相距不远的两个接收机来说几乎是同一条曲线。你在城东，他在城西，隔了五公里，头顶看的是同一批卫星，穿过的是同一片大气，误差的走势高度一致。这种“空间相关性”，就是差分定位能成立的物理底座。距离越远，相关性越弱，误差开始各走各的，所以差分精度会随基线长度衰减——这一点后面还会反复提到，因为它决定了很多使用场景的边界。

2.2 差分：参考站把自己变成一把已知刻度的尺子

差分的思路非常朴素。把一台接收机架在一个坐标已经被精确测定过的点上，这个点就是参考站。它一边接收卫星信号，一边知道自己的真实位置，于是它可以算出：按卫星给的数据，我应该在 A 处，实际量出来是 B 处，差值就是当前的误差量。这个差值被整理成“改正数”，发给附近的用户。

用户接收机拿到改正数后，在自己的观测值上减掉同样的量，剩下的就是接近真实的那部分。打个比方，两个人在同一片浓雾里用步子量距离，其中一个站在已知里程桩旁边，能算出自己每一步偏长了多少，把这个偏差告诉另一个人，另一个人照着修正，虽然雾还在，但量出来的距离就准了。

这就是 DGNSS（差分全球导航卫星系统）的基本原理。分米级、厘米级的差别，取决于你给的是码相位改正数还是载波相位改正数，后者就是常说的 RTK。无论是哪一种，都有一份数据需要“送出去”。

2.3 从无线电台到互联网：NTRIP 要解决的是投递问题

早期把改正数送到用户手上的方式，主要是各种无线链路：长波、中波、超短波电台，或者调频广播的副载波。这些方式能用，但限制很明显——覆盖半径有限，需要架天线、申请频率，一个发射台能同时服务的用户数量也有限，跨城市基本别想。

互联网普及之后，一个自然的想法出现了：既然改正数据只是每秒几百到几千字节的小流量，为什么不让它走网络？网络覆盖广、接入成本低、并发能力强，一台服务器理论上能同时喂给成千上万个用户。

但“走网络”不是插根网线就完事。你得先约定清楚几件事：一个数据流怎么被命名和发现？用户怎么告诉服务器“我要哪一路”？服务器怎么同时向几百个客户端持续推流而不是一问一答就断开？身份怎么验证？手机这种算力和内存都紧张的设备怎么用最小代价实现？这些约定合起来，就是 NTRIP。它是一份应用层协议规范，规定了通信的动作和报文长什么样，而不规定你用哪种编程语言、跑在哪种芯片上。

2.4 RTCM 是“内容”，NTRIP 是“通道”，别指望一个替代另一个

这里有个必须提前分清的分工。RTCM 10403 系列标准定义的是消息的格式，也就是改正数、观测值、星历这些信息怎么编码成一串二进制；而 RTCM 10410.1 定义的 NTRIP，管的是这串二进制怎么从一台机器搬到另一台机器。

通俗地说，前者是快递箱里货物的规格说明书，后者是快递柜的取件流程。你可以用 NTRIP 传 RTCM 格式的数据，也可以用它传别的东西——规范本身就写明它是通用流式协议，不限特定数据类型。反过来，RTCM 格式的数据也可以走电台、走文件、走别的通道。把两者混为一谈，是入门阶段最常见的翻车点之一，后面还会专门展开。

3. 三个角色跑通一条数据流：源、服务器、中枢与客户端各管什么

3.1 NtripSource 与 NtripServer：数据的产地和搬运工

NtripSource 指的是产生数据流的那一端，通常是一台架在已知点上的参考站接收机，它持续输出观测值和改正数。NtripServer 则是把这份数据推送到中枢的软件，它可以和 Source 跑在同一台机器上，也可以分开部署。

这里的关键概念叫“挂载点”（mountpoint）。你可以把它理解为数据流在中枢服务器上的门牌号：一个 Source 对应一个挂载点，用户凭这个门牌号来点单。挂载点由中枢的管理员分配和登记，规范里并没有强制命名规则，但实际部署中通常会带上传送格式、区域、站点类型的缩写，方便用户一眼看出这路数据大概是什么。

需要说清的是：Source 和 Server 是逻辑角色，不是硬件实体。同一台机器上可能同时跑着一个 Source 的采集程序和一个 Server 的上传程序，也可能一个 Server 负责把多个 Source 的数据分别推上去。看文档时不要把它们当成三台必须分开的机器。

3.2 NtripCaster：整个系统的中枢和调度台

NtripCaster 是这套体系里唯一处于中心位置的组件。它做几件事：接收来自各个 NtripServer 的数据流并按挂载点归类；维护一份“源列表”，把所有可用的数据流登记在册；接受客户端的连接请求，把对应的数据流持续推给它们；做身份验证；以及把不该进来的连接挡在门外。

从工程角度看，Caster 是整个系统里最容易成为瓶颈和单点的地方。它要同时维持大量长连接，每个连接都在持续接收数据，内存和带宽的压力都集中在这里。也正因为如此，很多部署会把 Caster 做成多实例、按区域分流，或者在前面加一层负载均衡。

Caster 还有一个容易被忽略的职责：管理员权限。哪些 Source 允许接入、每个挂载点叫什么名字、哪些账号能访问哪些流，这些都由管理 Caster 的人决定。协议规范只规定这些能力怎么在报文里体现，不规定业务策略怎么定。

3.3 NtripClient：用户端的“点单者”

NtripClient 是最终使用数据的一方，可能是一台测量型接收机、一个跑在手机上的软件、一台车载终端，也可能只是桌面上的一个调试工具。它的动作很直接：连上 Caster，说明自己要哪个挂载点，通过验证，然后开始一直接收数据。

一个 Caster 可以同时服务多个 Client，这些 Client 请求同一路数据时，拿到的是完全相同的内容，彼此之间没有干扰。这一点很重要——它意味着数据的分发成本几乎不随用户数线性增长，这是广播式电台做不到的。

Client 这一端还有一个常被忽略的能力：回传位置。规范里定义了客户端可以向 Caster 发送 NMEA 格式的位置报文，Caster 据此判断用户在哪儿，从而在有多路数据可选时给出更合适的那一路。这是网络型 RTK 服务能做“就近分配”的基础。

3.4 一次完整的取数流程，从头到尾走一遍

把上面几个角色串起来，一次典型的取数过程大概是这样：

第一步，客户端与 Caster 建立 TCP 连接，默认端口是 2101（规范里写明的默认值，不是唯一可用的值）。

第二步，客户端先请求源列表，看看这个 Caster 上到底挂了哪些数据流、分别是什么格式、覆盖哪个区域。

第三步，客户端从列表里挑一个挂载点，发出取数请求，同时附上身份凭证。

第四步，Caster 验证通过后开始持续推送该挂载点的数据流，连接保持不断，直到客户端主动断开或者超时。

第五步，客户端解析收到的数据，取出改正数，喂给自己的定位解算模块。

整个过程里，客户端和 Caster 之间是一条长连接，数据是单向持续流动的。这跟普通的网页请求“问一次、答一次、断开”完全不同，也是 NTRIP 必须对 HTTP 做裁剪的原因——完整的 HTTP 语义在这里既用不上，也太重了。

4. 协议长什么样：NTRIP 为什么是 HTTP 与 RTSP 的“精简子集”

4.1 报文长得很像 HTTP，但只保留了流式传输必需的部分

NTRIP 的底座是 HTTP/1.1 和 RTSP，但它只取了这两者中“建立连接、说明意图、持续传输”所必需的那一小块，其余全部砍掉。这样做的好处是实现成本低——一个资源受限的嵌入式设备，用几百行代码就能做出一个能用的客户端。

一个典型的取数请求，长这样：

# 向中枢请求某一路数据流，注意请求行里的路径就是挂载点 GET /EXAMPLE_RTCM32 HTTP/1.1 Host: caster.example.net Ntrip-Version: Ntrip/2.0 User-Agent: NTRIP demo-client/1.0 Authorization: Basic dXNlcjpwYXNz Connection: close

几处需要说明的地方：

请求行里的路径部分，就是你要的挂载点名字，前面加一个斜杠。它不是一个真实存在的文件路径，而是 Caster 内部的一张路由表。

Ntrip-Version这个头部是 NTRIP 自己加的，用来声明客户端使用的协议版本。规范里保留了旧版本头部的兼容处理，同时也明确标注了哪些是已经废弃的写法，实现时要按目标版本对齐。

Authorization走的是标准的 HTTP 认证机制，后面会展开。Connection: close表示这是一条用完即弃的连接语义——虽然实际传输会持续很久，但这个头部在协议演进过程中有过调整，具体行为要看对端实现的版本。

除了取数据，客户端还可以用类似的请求去拿源列表，或者带上位置信息请求一份“过滤后的源列表”，只返回离自己较近的那些数据流。这个过滤能力是 2.0 版相对早期版本的一个重要补充。

4.2 源列表：三张表说清“这里有什么”

源列表是 NTRIP 的“目录页”，它由若干行文本组成，每行以三个大写字母开头，标识这一行描述的是什么类型的对象。三种主要条目可以这样对照：

CAS 条目告诉你“你在跟谁说话”，NET 条目把一组相关的数据流打包描述，STR 条目则是真正可被请求的那一路。用户端解析这份列表，本质上就是在读一份商品目录：有什么、什么格式、覆盖哪里、要不要密码。

值得一提的是，STR 条目里的格式字段既可能写 RTCM 的版本号，也可能写别的自定义格式名。规范对此留了扩展空间，这也从侧面说明 NTRIP 本身并不绑定某一种数据内容。

4.3 三条传输路径：HTTP、RTSP 加 RTP、纯 RTP

NTRIP 2.0 一共给出了三种通信方式，它们是并列可选的，不是逐层递进的关系。

第一种是纯 HTTP 通道，也是最常见的一种。客户端发一个 GET，服务器持续回数据，整个交互都在 TCP 上跑。TCP 保证了数据不丢不乱序，代价是遇到网络抖动时会有重传延迟。

第二种是 RTSP 加 RTP 的组合。RTSP 负责控制——建立会话、开始传输、结束传输，动作分别对应 SETUP、PLAY、TEARDOWN 这几个方法；真正承载数据的 RTP 通常跑在 UDP 上。UDP 不保证送达，但延迟更低、开销更小，适合对实时性敏感、又能容忍偶尔丢包的场景。规范里还专门提到了保活机制，因为 UDP 路径上的连接状态需要靠定期的心跳来维持。

第三种是纯 RTP，跳过了 RTSP 的信令协商，直接在约定的地址和端口上收流。它适合那些信令已经在别处协商好的部署。

三者怎么选，取决于你的网络环境和延迟容忍度，没有一个放之四海皆准的答案。多数通用场景下，HTTP 通道是默认起点。

4.4 认证与传输编码：两个容易被跳过的细节

认证方面，规范列了两种：Basic 和 Digest。Basic 就是把用户名和密码拼起来做一次编码后放在头部里，编码不等于加密，链路上被人截到就能直接读出来。Digest 则是服务器给一个随机数，客户端用密码和这个随机数算出摘要再发过去，密码本身不上链路。能选 Digest 就别选 Basic，这是常识层面的建议。

传输编码方面，2.0 版引入了分块传输，用来解决一个问题：数据流是没有预定长度的，服务器没法事先在头部里写一个准确的内容长度。分块编码让服务器可以边产生边发送，每块自带长度标记，客户端边收边处理。相比早期版本里那种“连接关了才算结束”的做法，这是一个实打实的改进。

5. 容易搞混的几组概念：NTRIP、RTCM、RINEX 到底谁是谁

5.1 误区一：以为 NTRIP 就是 RTCM，两者是一回事

易混点：两个词总是成对出现，很多人顺口就说“NTRIP 数据”，把它当成一种数据格式。

为什么混：NTRIP 的全称里就带着 RTCM 三个字母，而且实际部署中绝大多数 NTRIP 流传输的确实是 RTCM 格式的改正数，久而久之就被画上了等号。

怎么区分：问一句“这份东西是在描述内容，还是在描述搬运方式”。RTCM 10403 系列描述的是二进制消息的内容结构，每一类消息有固定的字段和含义；NTRIP 描述的是请求、认证、推流这些动作。同一个 NTRIP 流里可以装 RTCM，也可以装原始观测、自定义格式甚至测试用的伪数据。把 NTRIP 当成格式，排查问题时就会找错方向——数据解不出来，可能只是格式字段对不上，而不是传输层出了问题。

5.2 误区二：以为 RINEX 和 NTRIP 是替代关系，有了一个就不需要另一个

易混点：两者都跟 GNSS 数据有关，都经常出现在同一批技术文档里。

为什么混：它们处理的确实是同一类原始观测，只是用途完全不同。

怎么区分：看时间维度。RINEX 是一种文本格式的文件，用来把一段时间内的观测数据完整存下来，供事后处理、归档、交换。NTRIP 是实时流，数据产生的同时就往用户那边送，不做留存。做静态基线解算、做数据存档，走 RINEX；做实时厘米级定位、做流动站改正，走 NTRIP。很多生产流程里两者是配合关系——白天用 NTRIP 实时作业，晚上把参考站数据转成 RINEX 做复核。它们不是二选一。

5.3 误区三：以为端口 2101 是协议的一部分，改了就违规

易混点：几乎所有教程都写 2101，让人以为这是硬性规定。

为什么混：默认值被反复引用之后，很容易被当成强制值。

怎么区分：规范里的原话是默认端口，同时明确写了其他端口也可以使用。实际部署中，为了避开端口冲突、做多实例隔离或者配合反向代理，换端口是常规操作。真正需要对齐的是双方的配置，而不是端口号本身。反过来说，如果你连不上，先别怀疑协议实现有问题，检查一下对端到底监听在哪个端口更实际。

5.4 误区四：以为 1.0 到 2.0 只是版本号变大，行为没差

易混点：版本号只差一个数字，看起来像小修小补。

为什么混：很多遗留系统仍在跑旧版本，文档里两套说法并存，读者容易以为可以混着用。

怎么区分：2.0 是一次实质性修订。它清理了早期设计中的问题和对 HTTP 规范的违背之处，替换了非标准的指令，引入了分块传输编码，改进了头部记录，增加了源列表过滤能力，还补上了 RTSP 通信这一整条路径。这些不是措辞调整，是行为差异。写客户端时如果按旧版习惯处理连接结束和长度判断，遇到新版服务端就可能出现读不完或者提前断流的情况。

5.5 误区五：以为挂载点名字一样，拿到的就是同一份数据

易混点：不同服务商可能用了相同或相似的挂载点命名。

为什么混：命名规则不在规范强制范围内，各家自己定，撞名完全可能。

怎么区分：认 Caster，不认挂载点。同一个名字挂在不同 Caster 上，背后可能是两台完全无关的参考站，覆盖区域、采样率、电文内容都不一样。另外，即便在同一台 Caster 上，管理员也可能在不通知的情况下调整某个挂载点背后的数据源。所以排查问题时，主机、端口、挂载点这三样要一起核对，少一样都可能对不上。

6. 什么时候用 NTRIP，什么时候别硬上：几条边界判断

先说适合的。需要实时厘米级或分米级定位，且作业点有可用的网络覆盖，这是 NTRIP 最典型的用武之地。测绘放样、农机自动驾驶、无人机航测的地面控制、变形监测里的实时回传，都属于这一类：数据量小、要求持续、用户端算力有限，正好对上 NTRIP 的设计取向。另一个适合的场景是多用户共享同一路数据——一个 Caster 推给几百个客户端，边际成本几乎为零，这是传统电台做不到的。

再说别硬上的。第一种是网络本身不稳的场景。NTRIP 走 TCP 时，链路一断就得重连、重新认证、重新等待数据稳定，中间那几秒的空窗在一些连续性要求高的作业里是致命的。如果你的作业环境是偏远山区、海上或者地下，先老老实实评估链路质量，别指望协议层能变出花来。第二种是只需要事后精度的场景。做静态数据后处理、做周期性复测，用 RINEX 文件交换就够了，上一套实时流系统纯属给自己找运维负担。第三种是对延迟极端敏感的闭环控制，UDP 路径虽然快，但丢包带来的抖动需要上层有补偿机制，没有相应设计的话，用起来会很别扭。

下面这张表可以当作快速判断的依据：

还有一个常被低估的边界：数据源头的质量。NTRIP 只保证“送到”，不保证“送的东西对”。如果上游参考站的坐标有问题、天线高量错了、电文配置错了，客户端拿到的是一份看起来很正常的错误数据，解算结果照样偏。这套体系里没有内置的纠错机制，也没有“后悔药”。

我自己的血泪经验是这样的：早年调试一套流动站，怎么都对不上固定解，换了三台设备、刷了两版固件、把协议实现翻了个底朝天，最后发现是上游那路数据的挂载点被人悄悄换成了另一台相距几十公里的参考站，名字一模一样。从那以后，我每次接入一路新的数据流，都强制走一遍核对流程：先拉源列表确认挂载点对应的覆盖区域，再对一下 Caster 的主机和端口，最后拿一段已知点的静态数据做一次闭环验证，确认解算结果落在预期范围内才敢上生产。这三步花不了十分钟，能省掉后面几天的玄学排查。希望帮到你。

本文还有配套的精品资源，点击获取