网络通信入门：NTRIP、RTCM、TCP 概念澄清， NtripSource、NtripServer、NtripCaster、NtripClient 关系梳理

原创于 2026-07-19 12:09:14 发布 · 148 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

本文主线：协议层次 → 系统角色 → 挂载点与 Source Table → 上传与下载 → GGA 回传 → HTTP 解码 → RTCM 组帧 → 实时性、安全与监控

1. 先记住一张关系表

NTRIP、RTCM 和 TCP 不属于同一层次。

名称	本质	解决的问题	通俗理解
TCP	传输层协议	怎样可靠、有序地传输字节流	运输道路
NTRIP	GNSS 实时流应用层协议	怎样接入、请求、认证和分发数据流	物流规则
RTCM	GNSS 消息与帧格式标准	GNSS 观测和改正怎样编码	被运输的货物

一句话理解：

TCP 提供可靠字节流；NTRIP 规定 GNSS 实时流怎样上传、请求和分发；RTCM 规定常见 GNSS 数据怎样编码。

还要区分：

NtripSource
→ 数据从哪里产生

NtripServer
→ 谁把数据上传到Caster

NtripCaster
→ 谁接入、管理和分发数据流

NtripClient
→ 谁请求并使用数据流

第一部分：协议层次

2. 正确的协议栈关系

工程中最常见的 NTRIP 数据链为：

RTCM或其他GNSS实时数据
        ↓ 作为业务负载
NTRIP应用层交互
（HTTP/1.x风格的请求、响应、认证和流控制）
        ↓
TCP可靠有序字节流
        ↓
IP寻址和路由
        ↓
以太网 / Wi-Fi / 4G / 5G

需要注意：

NTRIP 不是“位于 HTTP 上方的另一层协议”；
NTRIP 使用 HTTP 风格或 HTTP/1.1 兼容的交互来传输 GNSS 连续数据流；
建立数据流后，主体通常是连续二进制 GNSS 数据；
NTRIP 2.0 标准还包含 RTSP 等可选能力，但目前工程中最常见的仍是 HTTP/TCP 模式。

3. NTRIP 是什么

NTRIP 的全称是：

Networked Transport of RTCM via Internet Protocol

它是面向 GNSS 实时数据流的应用层协议。

NTRIP 主要解决：

数据源怎样接入中心服务；
Client 怎样选择数据流；
怎样通过挂载点标识数据流；
怎样认证上传方和下载方；
怎样获取 Source Table；
Caster 怎样把一份数据流分发给多个 Client。

虽然名称中包含 RTCM，但 NTRIP 并不限定只能传 RTCM。

4. RTCM 是什么

本文中的 RTCM 主要指 RTCM SC-104 制定的差分 GNSS 和实时 GNSS 数据标准。

RTCM 可以定义或编码：

参考站坐标和天线信息；
GPS、GLONASS、Galileo、BDS、QZSS 等观测值；
MSM 多系统多信号观测；
广播星历；
网络 RTK 信息；
轨道、钟差、码偏差、相位偏差等 SSR 信息。

因此：

RTCM不是一条固定消息
而是一组消息定义和帧格式标准

具体能否使用某类消息，取决于：

RTCM 版本；
数据流实际包含的消息；
接收端解码器；
定位算法需要的系统和信号。

5. TCP 在 NTRIP 中负责什么

TCP 向 NTRIP 提供：

面向连接；
可靠传输；
按序交付；
双向字节流；
流量控制；
拥塞控制；
丢失后的重传。

TCP 不负责：

选择挂载点；
NTRIP 用户认证；
解析 Source Table；
识别 RTCM 消息类型；
判断改正是否过期；
判断定位结果是否正确。

最重要的两个结论：

TCP 不保留应用消息边界，一次 recv() 不等于一帧 RTCM。

TCP 可靠交付不等于数据足够新鲜。重传和排队可能增加实时数据龄期。

第二部分：NTRIP 的角色

6. 三个软件组件和一个数据源

NTRIP 标准体系通常包含三个软件组件：

NtripServer
NtripCaster
NtripClient

完整数据链还包含：

NtripSource

名称	本质	主要作用	建立到 Caster 的连接
NtripSource	数据源	产生连续 GNSS 数据	不一定直接连接
NtripServer	上传软件组件	将 Source 数据上传给 Caster	通常主动连接
NtripCaster	中心 HTTP 服务组件	接入、认证、管理和分发	被动接受连接
NtripClient	下载软件组件	请求并使用指定数据流	主动连接

需要特别注意：

NtripServer、NtripCaster 和 NtripClient 是软件角色；NtripSource 是数据来源。

7. NtripSource：数据从哪里来

NtripSource 可以是：

固定参考站接收机；
网络 RTK 解算引擎；
SSR 产品生成程序；
数据格式转换程序；
实时观测汇集程序。

典型关系：

GNSS接收机
→ 产生原始观测
→ 编码成RTCM
→ 形成连续NtripSource

Source 也可以是算法生成的虚拟流，例如：

VRS 数据流；
网络 RTK 改正流；
SSR 产品流；
广播星历汇总流。

NtripSource 与 Source Table 不是同一个概念：

NtripSource
→ 实际数据来源

Source Table
→ Caster发布的数据流目录

8. NtripServer：上传组件

NtripServer 的职责是：

读取NtripSource
→ 主动连接NtripCaster
→ 提交挂载点和认证信息
→ 持续上传数据

典型方向：

NtripSource → NtripServer → NtripCaster

NtripServer 可以是：

GNSS 接收机内置模块；
参考站采集程序；
RTKLIB str2str；
自研上传程序。

名称中的 Server 容易误导：

在 NTRIP 角色中，NtripServer 负责上传；在 TCP/HTTP 建连关系中，它通常是主动连接 Caster 的客户端。

一个 NtripServer 进程可以管理多路 Source，但每条上传连接通常对应一个挂载点和一条连续数据流。

9. NtripCaster：中心接入与分发组件

NtripCaster 是实际接受 NtripServer 和 NtripClient 连接的中心服务，通常负责：

接受 Server 上传；
管理挂载点；
提供 Source Table；
认证 Server 和 Client；
将指定流复制给多个 Client；
记录在线状态、连接数和流量；
执行访问控制。

基本关系：

一个上游连接上传一份流
          ↓
       NtripCaster
          ↓
多个Client分别建立连接并接收

纯 Caster 的基本职责是接入和转发，通常不修改负载内容。

VRS、MAC、FKP、NEAR 或格式转换可能由：

独立网络 RTK 引擎；
Caster 插件；
Caster 后端业务服务；

生成。

这些算法不属于 NTRIP 传输协议本身。

在部分文献中还会看到 Ntrip Broadcaster。它更偏向描述一套运行中的广播服务；其中真正接受 HTTP/NTRIP 连接的软件组件仍是 NtripCaster。

10. NtripClient：请求和使用组件

NtripClient 负责：

连接Caster
→ 请求挂载点
→ 完成认证
→ 接收GNSS数据
→ 解封装并送入定位或监控模块

常见 Client：

RTK 流动站；
测量手簿；
RTKLIB；
BNC；
PPP/PPP-RTK 软件；
实时质量监控程序；
自研定位程序。

Client 不一定只接收。

对于 VRS、NEAR 或最近站选择服务，Client 还可能在同一条 TCP 连接中向 Caster 回传 NMEA GGA。

11. 完整数据方向

12. 为什么需要 Caster

12.1 降低数据源负担

没有 Caster 时，一个参考站可能要直接维护许多用户连接。

有 Caster 后：

数据源只上传一份
Caster负责复制和分发

12.2 适应 NAT 和移动网络

参考站常处于：

4G/5G 网络；
企业内网；
家用宽带；
运营商 NAT 后。

现场设备主动连接公网 Caster，通常比外部用户直接连接现场设备更容易。

12.3 统一管理

Caster 可以统一管理：

上传和下载账号；
挂载点；
在线连接；
连接数；
流量；
日志；
黑白名单；
访问频率。

第三部分：挂载点和 Source Table

13. 什么是挂载点

挂载点（Mountpoint）是 Caster 上某路服务或数据流的标识。

例如：

BJ01
RTCM3_GREC
NEAR
VRS
SSRA01IGS0

挂载点不一定等于物理测站名。

它可以表示：

单参考站 RTCM；
VRS 或网络 RTK 服务；
最近站选择服务；
SSR 产品；
广播星历；
其他实时 GNSS 流。

同一个 Caster 中，可请求的服务需要用不同挂载点区分。

但是：

挂载点名称只是标识，不足以证明实际负载格式、算法类型和服务覆盖范围。

14. 什么是 Source Table

Source Table 是 Caster 发布的数据流目录。

常见记录类型：

记录类型	含义	Client 是否必须支持
`STR`	一路数据流	应支持
`NET`	数据流网络信息	可选
`CAS`	其他 Caster 信息	可选

STR 记录以分号分隔字段，通常包含：

挂载点；
数据格式；
消息类型和周期；
卫星系统；
参考位置；
是否需要 NMEA；
认证方式；
估计码率；
其他说明。

Source Table 结束标识为：

ENDSOURCETABLE

Client 获取 Source Table 时，应请求不带挂载点的根资源，而不是依赖“故意请求错误挂载点”。

还要注意：

Source Table 字段是服务声明；
实际数据流仍应通过在线监控验证；
表中的经纬度通常是参考位置，不是严格覆盖边界；
Source Table 可能因配置维护不及时而与实时流存在差异。

15. NTRIP 1.0 与 NTRIP 2.0

NTRIP 2.0 相比 1.0 的主要变化包括：

修复早期 HTTP 兼容问题；
替换部分非标准指令；
改进请求和响应头；
支持 chunked 分块传输；
支持 Source Table 过滤；
提供 RTSP 可选通信能力。

工程中常见状态行：

场景	常见状态行
NTRIP 1.0 数据流成功	`ICY 200 OK`
NTRIP 1.0 Source Table	`SOURCETABLE 200 OK`
NTRIP 2.0 成功	`HTTP/1.1 200 OK`

NTRIP 2.0 设计上兼容 1.0，但真实设备和 Caster 的实现可能不完整。

因此 Client 应：

兼容 ICY 200 OK；
兼容标准 HTTP 成功状态；
正确解析完整响应头；
根据响应头处理传输编码；
不将某个厂商的私有格式当成通用标准。

所谓“一条请求使用一条连接”，不表示实时流只能持续很短时间。成功建立后，数据流连接可以持续很久，只是不复用同一连接去请求其他挂载点。

第四部分：下载、上传与 GGA

16. Client 怎样请求数据流

NTRIP 1.0 的简化请求形式类似：

GET /MOUNTPOINT HTTP/1.0
User-Agent: NTRIP ClientName/Version
Authorization: Basic BASE64_USER_PASSWORD

NTRIP 2.0 的简化请求形式类似：

GET /MOUNTPOINT HTTP/1.1
Host: caster.example.com:2101
Ntrip-Version: Ntrip/2.0
User-Agent: NTRIP ClientName/Version
Authorization: Basic BASE64_USER_PASSWORD
Connection: close

以上仅用于说明结构。实际字段应以 RTCM NTRIP 标准和目标 Caster 要求为准。

Client 应处理：

成功响应；
Source Table；
认证失败；
挂载点不存在；
服务暂时不可用；
响应头分段到达；
数据流中断；
自动重连。

17. Server 怎样上传数据流

NTRIP 1.0 和 2.0 的上传方式不同：

NTRIP 1.0 常使用非标准 SOURCE 请求；
NTRIP 2.0 使用更符合 HTTP 语义的上传请求，常见为 POST。

简化流程：

程序不应把某个 Caster 的私有上传报文当成通用 NTRIP 标准。

18. 响应头与首批数据可能一起到达

NTRIP/HTTP 响应头以空行结束：

\r\n\r\n

TCP 一次 recv() 可能得到：

完整响应头
+
第一批RTCM或其他GNSS负载

因此正确处理方式是：

累积字节直到找到 \r\n\r\n；
解析头部；
将分隔符之后已经到达的字节保留下来；
按传输编码继续处理；
再送入 RTCM 或其他业务解析器。

错误做法：

找到响应头后
→ 清空整个接收缓存

这会丢掉与响应头同包到达的第一批 GNSS 数据。

还应设置合理的响应头最大长度，避免异常对端造成无限缓存增长。

19. HTTP chunked 为什么要先解码

NTRIP 2.0 可能返回：

Transfer-Encoding: chunked

分块编码的基本结构为：

十六进制块长度[;可选扩展]\r\n
块数据\r\n
...
0\r\n
可选尾部字段\r\n
\r\n

正确处理顺序：

TCP字节流
→ 解析NTRIP/HTTP头
→ 判断Transfer-Encoding
→ 去除chunked控制字段
→ 得到纯GNSS字节流
→ 按RTCM或其他格式组帧

需要处理：

块长度行可能被分段接收；
块数据可能被分段接收；
一个 recv() 可能包含多个块；
长度可以带 chunk extension；
零长度块表示流的分块主体结束；
末尾可能存在 trailer 字段。

不能把 chunked 长度字符和 \r\n 直接送入 RTCM 解码器。

并非所有 NTRIP 2.0 流都使用 chunked，必须以响应头为准。

20. GGA 为什么要回传

某些位置相关服务需要 Client 提供近似位置，例如：

VRS；
NEAR；
最近站自动选择；
区域化改正服务。

数据方向：

Client → Caster：NMEA GGA
Caster → Client：GNSS改正或虚拟观测

GGA 可能通过：

NTRIP 2.0 请求头；
数据流建立后的同一 TCP 连接；
服务商规定的周期方式；

发送。

固定单参考站流通常不需要 GGA，但应以 Source Table 和服务说明为准。

常见 GGA 句子以 $GPGGA、$GNGGA 等开头，并以 \r\n 结束。若使用 NMEA 校验和，应正确生成 *HH。

GGA 只有 UTC 时分秒，没有日期。判断是否过期时，不能只看 GGA 内部时间，还应结合接收时间和跨日处理。

21. GGA 的质量和隐私

应检查：

经纬度是否有效；
南北、东西半球标志是否正确；
GGA 是否过期；
fix quality 是否满足服务要求；
发送周期是否合适；
是否正确添加校验和及行结束符；
链路是否加密；
服务端是否记录用户位置。

错误或过期 GGA 可能导致：

选择错误参考站；
在错误位置生成 VRS；
网络改正空间相关性变差；
服务拒绝或频繁重建。

第五部分：RTCM 3 字节流解析

22. RTCM 3 帧结构

RTCM 3 帧由：

部分	长度	说明
前导字节	1 字节	固定为 `0xD3`
保留位与长度	2 字节	6 位保留位 + 10 位负载长度
Payload	$L$ 字节	RTCM 消息负载
CRC-24Q	3 字节	帧完整性校验

负载长度解析为：

$L=(b1&0x03)28+b2\boxed{ L = \left( b_1\mathbin{\&}0x03 \right)2^8 + b_2 }$

其中：

$b_1$ ：0xD3 后的第一个字节；
$b_2$ ：其后的第二个字节；
$b_1$ 的高 6 位是保留位，正常帧中应为零。

完整帧长度：

$Lframe=L+6\boxed{ L_{\mathrm{frame}} = L+6 }$

10 位长度字段允许：

$0≤L≤10230\le L\le1023$

所以编码范围为：

$6≤Lframe≤10296\le L_{\mathrm{frame}}\le1029$

但一个具有 RTCM 消息号的实际有效消息，Payload 至少需要容纳开头的 12 位消息类型，因此实际有效帧通常不会只有 6 字节。

RTCM 消息类型位于 Payload 开头 12 位。若 Payload 至少有 2 字节：

$type=256p0+⌊p116⌋\boxed{ \mathrm{type} = 256p_0 + \left\lfloor \frac{p_1}{16} \right\rfloor }$

其中 $p_0,p_1$ 是 Payload 的前两个字节。

CRC-24Q 的计算范围为：

3字节帧头 + Payload

不包含最后的 CRC 字节。

0xD3 和上述结构只适用于 RTCM 3，不能用于解析 RTCM 2 或厂商私有格式。

23. RTCM 在 TCP 中怎样组帧

TCP 可能出现：

一次recv收到半帧
一次recv收到一帧半
一次recv收到多帧

正确状态机：

CRC 失败后不应盲目清空全部缓存，应向后继续寻找新的 0xD3。

为了防止无界增长，还应设置：

接收缓存上限；
最大合法帧长度；
连续 CRC 失败告警；
无有效帧超时。

24. TCP 已可靠，为什么还需要 RTCM CRC

两者检查的层次不同。

机制	检查对象
TCP 校验、序号和重传	TCP 传输段及字节流交付
RTCM CRC-24Q	RTCM 帧是否完整、组帧是否正确

RTCM CRC 仍有价值，因为数据可能经过：

串口转网络；
多级网关；
格式转换；
缓存拼接；
文件记录与回放；
错误拆帧；
HTTP chunked 解码。

在纯 TCP 端到端链路中持续出现 CRC 错误，通常应检查：

上游串口或接收机输出；
chunked 是否正确去除；
响应头是否被混入负载；
缓存组帧逻辑；
数据转发和回放程序；
实际负载是否确实为 RTCM 3。

CRC 只能发现差错，不能认证发送者，也不能防止恶意修改。

25. NTRIP 是否一定传 RTCM

不一定。

NTRIP 可以承载：

RTCM；
原始接收机格式；
实时 RINEX 数据；
BINEX；
广播星历；
SSR 产品；
厂商私有格式；
其他连续 GNSS 数据流。

普通 RTK/CORS 服务中最常见的负载仍是 RTCM 3。

程序不能仅因为“使用 NTRIP”就直接搜索 0xD3，应先根据：

Source Table；
挂载点说明；
Content-Type；
服务商文档；
实际字节特征；

确定负载格式。

第六部分：实时性、缓存和安全

26. TCP 可靠不等于实时数据始终可用

TCP 可以重传丢失字节并按序交付，但重传会产生队头阻塞：

前面的字节没有补齐
→ 后面的字节即使已到达
→ 应用层仍不能按序读取

因此，网络不稳定时可能出现：

数据最终完整到达
但到达时已经过期

对于含历元的消息，可定义：

$tage=tnow−tepoch\boxed{ t_{\mathrm{age}} = t_{\mathrm{now}} - t_{\mathrm{epoch}} }$

其中：

$taget_{\mathrm{age}}$ ：消息数据龄期；
$tnowt_{\mathrm{now}}$ ：统一时间系统下的当前时刻；
$tepocht_{\mathrm{epoch}}$ ：消息对应的数据历元。

并非所有 RTCM 消息都包含观测历元。对于参考站坐标、天线信息等低频或静态消息，更适合监测：

最后到达时间；
实际重复周期；
是否在连接建立后收到必要消息。

还要区分：

最后收到任意字节的时间间隔
≠
最后收到有效RTCM帧的时间间隔
≠
消息内部历元对应的数据龄期

27. 实时系统不能无限缓存

TCP 发送速度低于 Source 产生速度时，会出现反压：

Source持续产生数据
网络发送跟不上
→ 应用缓存不断增长
→ 数据越来越旧

实时 GNSS 程序应优先保证“新鲜”，而不是无限保存每个旧字节。

建议：

设置发送和接收缓存上限；
监测队列字节数和最老数据年龄；
发生持续拥塞时主动断开并重连；
对可丢弃的实时产品制定明确丢弃策略；
原始数据长期保存应走独立文件记录链路；
不要让日志或磁盘写入阻塞网络接收线程。

需要区分：

实时转发通道
→ 优先低延迟和最新数据

归档记录通道
→ 优先完整保存

28. 掉线检测和自动重连

TCP 没有瞬时链路存活检测能力。

网线断开、移动网络失联或 NAT 状态失效后，应用可能要等到：

读写错误；
TCP 重传超时；
Keepalive；
应用数据超时；

才发现连接失效。

建议同时使用：

连接超时；
读取超时；
最后有效帧超时；
数据龄期超限；
TCP Keepalive；
指数退避重连；
随机抖动，避免大量设备同时重连；
稳定运行一段时间后重置退避级别。

Keepalive 只能帮助判断连接，不等于业务数据正常。

29. NTRIP 安全性

传统 NtripClient 常使用 HTTP Basic Authentication。

Basic Authentication 中的凭据只是 Base64 编码，不是加密。

上传认证还需区分版本：

NTRIP 1.0 常使用独立 Source 密码；
NTRIP 2.0 可使用更规范的 HTTP 认证方式；
不同 Caster 可能有兼容或私有扩展。

不可信网络中应优先考虑：

TLS/HTTPS；
正确校验服务器证书和主机名；
VPN 或专网；
强密码；
上传和下载账号分离；
最小权限；
连接频率限制；
日志审计；
凭据安全存储。

还要注意：

并非所有 Caster 都支持 TLS；
不应在忽略证书校验的情况下误以为连接已经安全；
GGA 可能暴露用户实时位置；
CRC 不能替代身份认证和加密。

第七部分：程序结构与工程监控

30. NtripClient 程序结构

实现时还要考虑：

IPv4/IPv6；
DNS 地址变化；
部分 send() 和部分 recv()；
响应头大小上限；
TLS SNI 和证书校验；
接收缓存上限；
无业务数据超时；
网络线程与定位线程隔离；
安全退出和资源释放。

31. NtripServer 程序结构

NtripServer 应分别监控：

Source 是否产生有效数据；
到 Caster 的连接状态；
Caster 是否接受上传；
部分发送是否正确续传；
实际上传字节率；
发送队列大小和数据龄期；
RTCM CRC 和消息类型；
必要消息是否齐全；
挂载点是否真正在线。

32. 工程监控不能只看“TCP 已连接”

建议监控：

指标	说明
TCP/TLS 连接状态	传输通道是否建立
NTRIP 响应状态	请求是否成功
挂载点状态	上游服务是否在线
字节率	是否持续有数据
最后有效帧间隔	是否发生业务断流
RTCM CRC 错误率	组帧和数据完整性
消息类型	必要消息是否存在
消息周期	播发频率是否正常
数据龄期	数据是否足够新鲜
缓存长度和队列龄期	是否发生持续拥塞
GGA 状态	位置输入是否有效
重连次数	链路稳定性
认证失败次数	配置或安全异常

关键判断链：

TCP已连接
≠
TLS和认证成功
≠
NTRIP请求成功
≠
持续收到业务数据
≠
负载格式正确
≠
必要消息齐全
≠
数据龄期合格
≠
定位结果正确

33. 常见概念混淆

33.1 NTRIP 就是 RTCM

错误。NTRIP 是实时流传输协议，RTCM 是常见负载格式。

33.2 NTRIP 就是 TCP

错误。TCP 提供字节流，NTRIP 规定挂载点、认证、目录和流交互。

33.3 NtripServer 是给用户下载数据的网站服务器

错误。NtripServer 是上传组件，真正接受下载请求的是 NtripCaster。

33.4 NtripSource 和 Source Table 是同一个概念

错误。前者是数据来源，后者是 Caster 发布的数据流目录。

33.5 Caster 一定生成 VRS

错误。纯 Caster 主要接入和转发，VRS 通常由网络 RTK 引擎生成。

33.6 Client 一定只接收数据

错误。VRS、NEAR 等服务可能要求 Client 回传 GGA。

33.7 一次 `recv()` 就是一帧 RTCM

错误。TCP 不保留 RTCM 帧边界。

33.8 解析完 HTTP 头后可以清空当前接收缓冲

错误。响应头后可能已经包含第一批 GNSS 负载，必须保留。

33.9 NTRIP 2.0 数据一定使用 chunked

错误。是否使用分块传输必须以响应头为准。

33.10 NTRIP 数据一定以 `0xD3` 开始

错误。NTRIP 可以传输非 RTCM 数据；即使是 RTCM 3，也要先去除 NTRIP/HTTP 封装。

33.11 TCP 已连接就说明改正正常

错误。还需检查响应、格式、消息类型、周期、CRC 和龄期。

33.12 TCP 可靠意味着数据不会过期

错误。重传、队头阻塞和缓存积压会增加实时数据龄期。

33.13 Basic Authentication 已经加密密码

错误。Base64 只是编码，明文链路仍可能泄露凭据。

33.14 RTCM CRC 可以证明数据来源可信

错误。CRC 只检测帧差错，不提供身份认证。

34. 最终关系图

35. 总结

TCP 是可靠、有序、双向的字节流，但不保留 RTCM 帧边界，也不保证数据始终新鲜。

NTRIP 使用 HTTP 风格交互传输 GNSS 实时流，负责挂载点、认证、Source Table、上传和下载。

RTCM 是 NTRIP 最常见的 GNSS 负载标准，但不是唯一负载。

NtripSource 产生数据，NtripServer 上传数据，NtripCaster 接入和分发数据，NtripClient 请求并使用数据。

Client 必须先解析 NTRIP/HTTP 响应和传输编码，再按照真实负载格式进行 RTCM 组帧或其他协议解析。

对实时 GNSS 服务而言，“TCP 已连接”远远不等于“改正数据可用”。

参考资料

RTCM 10410.1：Standard for Networked Transport of RTCM via Internet Protocol (Ntrip), Version 2
RTCM 10403 系列：Differential GNSS Services, Version 3
BKG：Ntrip Real-Time GNSS Documentation
RFC 9293：Transmission Control Protocol
NMEA 0183：GGA 等 NMEA 语句格式

标签

#tcp/ip #网络协议 #NTRIP #RTCM #编解码