NTRIP Rev1与Rev2格式-详情

NTRIP Rev1与Rev2格式

2023-5-16 22:45:41 来源: GNSSer 发布人: czsgeo

NTRIP Rev1与Rev2格式
创建于2020年11月12日作者支持类别常见问题解答
本文简要解释了NTRIP Rev1（版本1.0）和Rev2（版本2.0）中使用的NTRIP客户端连接格式风格之间的差异，并提供了示例。
出身背景
NTRIP Rev2的创建在很大程度上是因为需要纠正原始Rev1标准中的一些小疏忽。这包括纠正协议细节以遵守新兴的HTTP标准，并为基站增加更高的登录安全性。还添加了一些新功能，但目前它们的采用率和部署率仍然很低。事实上，最初的Rev1版本今天仍然很受欢迎，以至于在NTRIP客户端设备中，Rev1用户的数量比Rev2用户的数量多了大约25:1。
对于那些寻求任何一个版本的具体细节的人，这两个标准都可以从RTCM（此处）获得。这两份文件的正式名称如下。将它们作为一套购买是最具成本效益的。
RTCM 10410.0（RTCM文件200-2004/SC104-STD，1.0版），含修正案1，
通过互联网协议的RTCM网络传输标准（Ntrip）
RTCM 10410.1通过互联网协议的RTCM网络传输标准（Ntrip）
2.0版（含修订1），2011年6月28日
在本文中，我们关注的是漫游者设备（NTRIP客户端）如何连接到NTRIP Caster设备。此信息适用于任何脚轮，而不仅仅是SNIP NTRIP脚轮。在Rev1和Rev2之间，对基站连接（NTRIP服务器）进行了一些类似的更改，但此处未涵盖。
在OSI层上下文中，NTRIP协议位于HTTP协议之上，而HTTP协议又位于TCP/IP协议之上。该协议的目的是允许连接的客户端设备向数据提供商（Caster）进行身份验证，然后选择数据流。一旦这个初始过程发生，选定的数据流就会通过打开的套接字发送回设备。除了额外的周期性NMEA-183$GGA语句（由NEAR流用于为每个用户选择正确的基站）外，NTRIP客户端设备不发送任何进一步的内容。在这种情况下，NTRIP是一种简单而优雅的发布/订阅机制。
注意：在后面的示例中，mountPt是正在请求的基站或“流”的名称。用户和密码用于用户-密码对，然后以Base64编码的格式发送（即用户：密码变为dXNlcjpwYXNzd29yZA==）。所有这些字符串都区分大小写，通常仅限于ASCII内容，不使用空格。有关有效字符串和允许的字符的更多详细信息，请参阅标准。＜cr＞＜lf＞分隔HTTP标头中每一行的末尾。只有＜cr＞＜lf＞的最后一行用于界定标题的末尾（未显示）。
NTRIP客户端Rev1连接
因为NTRIP最初是基于HTTP和一个名为Shoutcast的协议（历史细节），所以它使用常见的GET谓词来请求所需的mountPt。
没有用户登录的最小NTRIP客户端版本1示例是：
获取/mountPt HTTP/1.0＜cr＞＜lf＞
用户代理：NTRIP软件/修订版<cr><lf>
用户登录的最小NTRIP客户端版本1示例为：

GET /mountPt HTTP/1.0<cr><lf>
User-Agent: NTRIP theSoftware/theRevision<cr><lf>
Authorization: dXNlcjpwYXNzd29yZA==<cr><lf>
When a request is accepted by the NTRIP Caster, the Caster replies with:

ICY 200 OK<cr><lf>

然后是二进制内容（通常是RTCM3.x消息）。如果出现任何类型的错误，将返回caster表并断开连接。
细节
在GET关键字之后，预计会找到一个空格，后跟“/”，然后是请求的数据流的名称，另一个空格和HTTP修订版。通常，HTTP需要一个空格（十六进制0x20）作为分隔符，任何额外的空格都可能导致问题。
关键字“用户代理：”用于传达两个关键概念。首先，这是一个NTRIP Caster（而不是浏览器或其他代理），其次是正在使用的软件的品牌/型号。[注：术语“源代理：”是NTRIP为基站发送数据而发明的，并在Rev1中使用。已在第2版中弃用]
由于历史原因，关键字NTRIP被认为是不区分大小写的，尽管大写是最常见的。
此关键字后面跟着正在使用的NTRIP客户端软件的型号。这通常采用“制造商型号/修订版”的格式，没有空格。流行的公共广播上最近的客户端字符串的典型列表可以在这里找到典型的NTRIP设备字符串。
关键字“Authorization：”用于发送以常见Base64格式编码的用户和密码（如果存在）。
最简单的请求在常见的HTTP标头形式中只包含两三行。但HTTP标头通常可以包含额外的元信息。此外，如果使用HTTP 1.1表单，则需要一些附加信息。详见rfc2616。
旁白#1：请求caster表的正确方法是在GET谓词后发送“/”。而不是发送任意字符串，如“CasterTable”，这只会起作用，因为当检测到错误时，NTRIP Caster的默认行为是返回Caster表，然后断开连接。
除了#2：当使用Rev1从基站向Caster发送数据时，会使用关键字“SOURCE”，在Rev2中，这会被替换为“POST”以及其他更改。
除了#3：当向Caster发送NMEA-183$GGA数据时，NTRIP客户端应等待，直到收到指示接受连接的“ICY”回复。

NTRIP客户端Rev2连接
在NTRIP的Rev2中，为了更好地遵循HTTP，对一些细节进行了清理。Rev2的大多数更改都是在NTRIP服务器（基站）连接到脚轮的方式中发现的。在SNIP Caster中，这被称为PUSH In连接。
没有用户登录的最小NTRIP客户端版本2示例是：

GET /mountPt HTTP/1.1<cr><lf>
Host: theCaster.com:2101<cr><lf>
Ntrip-Version: Ntrip/2.0<cr><lf>
User-Agent: NTRIP theSoftware/theRevision<cr><lf>
A minimal NTRIP Client Rev2 example with a user log on is:

GET /mountPt HTTP/1.1<cr><lf>
Host: theCaster.com:2101<cr><lf> 
Ntrip-Version: Ntrip/2.0<cr><lf>
User-Agent: NTRIP theSoftware/theRevision<cr><lf>
Authorization: dXNlcjpwYXNzd29yZA==<cr><lf>
When a request is accepted by the NTRIP Caster, the Caster replies with at least:

HTTP/1.1 200 OK<cr><lf>

A more typical reply includes some additional header details like:

HTTP/1.1 200 OK<cr><lf>
Date: Wed, 11 November 2020 20:29:36 UTC<cr><lf>
Server: SubCarrier Systems Corp SNIP simpleNTRIP_Caster_[2.13.00]RwPRO<cr><lf>
Ntrip-Version: Ntrip/2.0<cr><lf>
Cache-Control: no-store, no-cache, max-age=0<cr><lf>
Pragma: no-cache<cr><lf>
Connection: close<cr><lf>
Content-Type: gnss/data<cr><lf>
And thereafter binary content (typically RTCM 3.x messages) follows.  In case of any type of error, a variety of other error replies are supported (aka HTTP 4xx messages) as well as returning the caster table to the requestor.

细节
Rev2格式建立在Rev1格式以及HTTP1.1中定义和找到的新元信息的基础上。和以前一样，HTTP头通常可以包含额外的元信息。对于请求和回复标头都是如此。
两个额外的（也是必需的）标题行包含“主机：”和“Ntrip版本：”元信息。
meta关键字“Host:”表示请求所指的主机和端口是指哪台特定的服务器。在有一个与一个（也是唯一一个）NTRIP主机关联的IP地址的机器中，不需要此信息，但它是由HTTP强制要求的。在共享主机环境中，或者在使用防火墙或代理的情况下，这些信息对于将请求路由到正确的主机设备至关重要。
元关键字“Ntrip版本：”是由Ntrip Rev2规范发明的，应该遵循上面的确切文本。此时没有定义值文本的其他变体。该行的存在表示使用NTRIP Rev2。
在回复中，请注意，“ICY”（ICY=我能听到你的声音）被HTTP 200 OK行取代，该行还包括所使用的HTTP版本。
回复中可能可选地存在几个其他元关键字，包括日期戳和关于NTRIP Caster软件的详细信息。这里，“服务器：”在传统的网络意义上用于Caster，而不是NTRIP，意思是NTRIP服务器（基站）。上面的例子使用了SNIP Caster的回复，其他品牌也类似。
许多设备不支持Rev2连接。在低成本设备上尤其如此。流行的开源库RTKLIB（请参阅：此处或此处）只能使用Rev1连接样式进行连接。许多分支改进和一些基于它的商业软件，包括Emlid Reach，也没有实现Rev2连接。高级设备（Trimble、Leica、半球、TopCon等）同时支持Rev2和Rev1，通常这些设备默认使用Rev2。有关详细信息，请参阅特定的用户手册。
在Rev2中，NTRIP客户端连接旨在允许与Rev1连接兼容的向后“向下”连接。因此，任何发送Rev2请求的NTRIP客户端也应设计为接受并处理Rev1回复。对于NTRIP服务器连接，情况并非如此。
Rev2，该协议要求使用HTTP 1.1，因此需要使用主机元线（详见rfc2616）。这里可以使用IP或URL名称，也应该使用端口（尽管当前的RTCM标准对此细节不太清楚，但RFC2616不是）。
最后备注
请不要使用直播脚轮来测试新的NTRIP客户端软件。卡斯特运营商很可能会阻止您的IP进行此类使用/滥用。SNIP Caster的控制台日志提供了大量关于NTRIP客户端连接不正确的各种原因的详细信息。一些开发人员只需将SNIP的Lite（免费）副本下载到他们自己的本地机器上进行此类测试。
强烈建议那些正在开发的产品向RTCM寻求任何一个版本的具体细节。
SNIP完全支持客户端、脚轮和服务器的Rev1和Rev2 NTRIP连接样式。SNIP的Lite（免费）副本仅限于Rev 1格式，用于某些连接。通过为每种连接类型启用各种显示选项，您可以在控制台视图中检查所有协议交换的详细信息。
另请参阅
关于NTRIP Rev2的文章在SNIP中使用，SNIP中有进一步的NTRIP服务器连接细节。