NTRIP协议学习（一）

这篇博客讲得很清晰。 　　https://blog.csdn.net/sinat_19447667/article/details/67637167

可以参考的文献包括：《多系统GNSS实时数据质量分析及软件实现》《北斗地基增强系统数据通信综述》

1.NTRIP是实时数据流所需的HTTP/RTSP的简化子集。NTRAP通信通常通过HTTP/TCP/IP或RTSP/TCP/IP和RTP/UDP/IP连接进行。默认端口是TCP 2101，但可以使用其他端口。这不妨碍Ntrip在因特网上或任何其他协议之上实现，或者分别在调制解调器连接或基于UDP的传输连接协议等其他网络上实现。

2.包含三部分：

客户端，用户，caster中转站。

3.NTRIP是一个开放的非专有协议。NTRIP基于互联网的流传播技术的主要特点有：

基于流行的HTTP/RTSP标准；
客户端或服务器资源有限，易于实现；
不限于特定的数据类型，而是设计为通用流协议；
组件分离允许使用可用的基础设施；
支持移动用户和固定用户。

4.该文档描述了应用层的协议。一般知识通常需要TCP/IP连接、套接字处理（TCP用主机的IP地址加上主机上的端口号作为TCP连接的端点，这种端点就叫做套接字（socket）或插口。）和编程。实现。NTRAP是基于某些其他开放标准。这些参考文献是附录A中注明。

/*************************************************************************以下为NTRIP协议2.0的全部翻译**********************************************************************************************************/

1.整体

1.1 NTRIP

Ntrip“通过互联网协议进行RTCM的网络传输”（Ntrip）代表通过互联网传输“全球导航卫星系统（GNSS）”数据的应用级协议。 Ntrip是一种基于超文本传输​​协议（HTTP / 1.1）和实时流协议（RTSP）的通用无状态协议。 Ntrip是实时数据流所需的HTTP / RTSP的缩减子集。 Ntrip通信通常通过HTTP / TCP / IP或RTSP / TCP / IP和RTP / UDP / IP连接进行。默认端口是TCP 2101，但可以使用其他端口。这并不妨碍Ntrip在互联网上的任何其他协议之上，或在其他网络（如调制解调器连接或基于UDP的传输或连接协议）上实施。 Ntrip被设计用于通过因特网向固定或移动用户传播差分校正数据（例如，以RTCM特别委员会104的格式）或其他种类的GNSS流数据。 Ntrip由三个系统软件组件组成：客户端，服务器和脚轮：•脚轮中央服务器应用程序•用于数据访问的客户端用户应用程序•用于从输入源上传数据的服务器提供程序应用程序Ntrip是一种开放的非专有协议。 Ntrip基于互联网的流媒体传播技术的主要特点是 - 基于流行的HTTP / RTSP标准;易于使用有限的客户端或服务器资源实现;不限于特定的数据类型，而是设计为通用流媒体协议;组件分离允许使用可用的基础设施;并支持移动和固定用户。本文档描述了应用程序级别的协议。实现通常需要了解常规TCP / IP连接，套接字处理和编程。 Ntrip基于某些其他开放标准。这些参考文献在附录A中标注。本文档描述了Ntrip 2.0版。

与版本1.0相比的主要变化是：清除和修复设计问题以及HTTP协议违规; 取代非标准指令; 分块传输编码; 标题记录的改进; 可源化过滤; 和RTSP通信。 关于Ntrip版本1.0与当前协议之间的更改的详细说明包含在协议描述中的适当位置。

1.2目的

由于被称作“选择性可用性”的GPS信号的故意退化被关闭，独立GPS接收机通常经历10-15米的位置误差，并且这些误差遵循随机行走模式。虽然这种精度对于各种各样的应用是足够的，但是在其他应用中，米级、甚至厘米级的精度是需要的。对于这样的高精度应用，可以成功地使用差分全球导航卫星系统（DGNSS）。DGNSS通过从一个或多个参考站向移动接收机提供测量或校正数据来提高位置、速度和时间的精度。每个参考站的位置是精确已知的，因此它的测量对于附近的其他接收机起校准的作用，因为主要的误差源是共同的：卫星星历和时钟、对流层和电离层延迟。DGNSS精度随着用户和参考接收机之间的距离的增加而降低，因此对于某些应用，需要来自多个参考站的信息。DGNSS可以利用对任何GNSS（GPS、GLONASS、伽利略）的微分校正来实现米级精度，或者它可以使用实时运动学（RTK）信息来实现分米或厘米精度。DGNSS数据需要每隔几秒钟刷新一次，以跟上卫星时钟的变化。RTCM 104DGNSS标准在世界范围内使用。许多流行的GNSS接收机接受RTCM-104的差分校正消息，并且许多专用RTK接收机使用RTK消息。RTCM SC-104标准定义包含参考站和系统数据的消息。这些消息通常通过传输链路广播并由移动用户接收，然后移动用户应用消息中包含的信息以实现高精度操作。数据可以在任何数量的通信通道，例如传输，通过无线传输（LF、MF、HF、UHF），或通过移动通信网络，使用不同的通信协议。无线互联网能力的引进和部署开辟了传播这些信息在互联网上的潜力。本文档定义了基于HTTP和RTSP的差分数据传播协议标准（或其他种类的GNSS数据流）固定或移动互联网上的接收器。它使同步PC，笔记本电脑，PDA，或接收器连接到一个广播主持人，通过移动IP网络，如GSM、GPRS、UMTS的边缘，或。因为最初的应用是RTCM SC-104消息的传播，作为一个整体的系统提出了一种传输协议，将这里称为NTRIP协议（网络传输协议通过Internet协议）。

1.3系统概念

Ntrip分为三个不同的软件组件：NtripClient，NtripServer和NtripCaster。 NtripCaster是主服务器组件，而NtripClient和NtripServer充当客户端程序。

此Ntrip系统由以下元素组成：

•NtripSources，在特定位置生成数据流，

•NtripServers，将数据流从源传输到NtripCaster，

•NtripCaster，主要系统组件，以及

•NtripClients，最终在NtripCaster上访问所需NtripSource的数据流。

NtripServers使用“mountpoint”作为标识将NtripSource的数据上传到NtripCaster。几个NtripClient可以通过NtripCaster上的挂载点请求源来并行访​​问所需数据流的数据。

如果在NtripCaster程序中实施，授权人员可以使用Internet浏览器或其他通信方式通过受密码保护的HTTP会话远程控制NtripCaster。本文档不处理特定的软件实现。运行NtripCaster的管理员负责允许新的NtripServers与新的NtripSources连接。管理员组织所有可用的NtripSource并定义所有挂载点。

NtripClients必须能够通过NtripCaster上的挂载点选择NtripSource。因此，可以在NtripCaster中引入和维护源表。此源表的每个记录包含描述数据流属性，数据流网络或NtripCaster的参数。流属性在NtripServer端为每个NtripSource定义。

1.4 系统元素

DGNSS参考站采用最简单的配置，由位于探测良好位置的GNSS接收机组成。因为这个固定的GNSS接收器知道卫星在任何时间点在空间中的位置，以及它自己的确切位置，所以接收器可以计算自身与每个卫星之间的理论距离和信号传播时间。当将这些理论值与实际观察结果进行比较时，差异表示接收信号中的误差。 RTCM校正源自这些差异。为移动用户实时提供这些更正是Ntrip系统元素的主要目的，尽管Ntrip也可用于通过其系统元素NtripServer，NtripCaster和NtripClient传输其他类型的GNSS流数据（如RTK）。 。

1.4.1 Ntrip服务器

NtripServer用于将NtripSource的GNSS数据传输到NtripCaster。每个NtripSource都需要NtripCaster上的唯一安装点。沟通细节见后面几节。服务器密码和挂载点必须由NtripCaster的管理员定义，并交给参与的NtripServers的管理员。 NtripServer最简单的设置是在PC上运行的计算机程序，该计算机程序将NtripSource的校正数据（例如，通过串行通信端口从GNSS接收器接收）发送到NtripCaster。 Ntrip协议可以用于传输非物理参考站的RTCM数据。基于来自多个参考站的数据，针对用户的近似位置处的虚拟点导出RTCM校正。该虚拟参考站的数据表示可由NtripServer传输的单个NtripSource。 NtripSources提供连续的GNSS数据（例如RTCM-104校正）作为流数据。单个源通常表示涉及特定位置的GNSS数据。源表中编译的源描述参数指定使用的格式，位置坐标和其他信息。

1.4.2 NtripCaster

NtripCaster是一个服务器，支持HTTP / RTSP请求和响应消息的子集，并调整为低带宽流数据（每个流从50到500字节/秒）。 NtripCaster接受来自NtripServer或NtripClient的单个端口上的请求消息。根据这些消息，NtripCaster决定是否有要接收或发送的流数据。 NtripServer可以是NtripCaster程序的一部分。如果是这样，只有接收NtripClient消息的能力必须在组合的NtripCaster / NtripServer中实现。内置的基于HTTP的远程管理功能是一项可选功能。

1.4.3 NtripClient

如果NtripClient发送正确的请求消息，NtripClient将被NtripCaster接受并从NtripCaster接收数据。关于消息格式和状态代码，基于HTTP的NtripClient到NtripCaster通信与HTTP 1.1完全兼容，但在此上下文中，Ntrip仅使用非持久连接。

2.基于HTTP的通信

Ntrip的标准TCP通信基于HTTP [RFC2616]。虽然不需要阅读本文档来理解Ntrip协议，但如有疑问，应咨询该文档。超文本传输​​协议（HTTP）被设计为用于分布式协作超媒体信息系统的应用级协议，但它也可以用于线性流媒体。

HTTP主要用于批量流量，其中每个对象都有明确定义的开头和结尾。虽然广泛用于包括RTCM应用程序的IP流应用程序，但它并非设计用于此类用途。 HTTP通信的基本单元由与语法匹配的结构化八位字节序列组成，在协议中定义并通过TCP / IP连接传输。客户端和服务器必须了解HTTP请求消息，并且必须使用足够的HTTP响应消息进行应答。

Ntrip协议由HTTP功能的子集和一些附加的信息标题行组成。 Ntrip 1.0的协议违规已在此版本2.0中修复。 Ntrip协议的HTTP部分尚不支持持久连接。通信系统组件（NtripClient到NtripCaster，NtripServer到NtripCaster）之间的TCP连接丢失将由TCPsockets自动识别。此效果可用于触发软件事件，例如自动重新连接。

任何通信都由NtripClient或NtripServer启动，并由NtripCaster响应。这种请求响应通信的基本结构看起来像

REQUESTCOMMAND values HTTP/1.1<CR><LF>
Headerline1: values<CR><LF>
Headerline2: values<CR><LF>
<CR><LF>
HTTP/1.1 CODE Response<CR><LF>
Headerline1: values<CR><LF>
Headerline2: values<CR><LF>
<CR><LF>

序列<CR> <LF>是字符序列0xD和0xA，是HTTP通信的标准行终止。 每个请求都包含一个标题行，或多或少的可选标题行（标题描述见2.6）和结束标题部分的空行。 在这些标题之后，数据可能会或可能不会跟随（取决于实际的消息）。 以下示例假设NtripCaster正在主机ntrip.example.com端口2101（Ntrip协议通信的默认端口）上运行。

2.1 NtripClient到NtripCaster通信

本节介绍Ntrip系统中的大多数通信。 NtripClient是接收NtripCaster提供的来自Internet的数据流的任何软件。该协议必须在任何最终用户应用程序或设备中实现。

这些通信的基本任务是：

•将系统信息从NtripCaster传输到NtripClient（可源表）

•NtripClient对数据的请求（使用mountpoint，用户名，密码指定）

•从NtripCaster向NtripClient传输请求的数据

•处理错误状态，错误请求等。

可以在[SRCNC]找到示例NtripClient实现。

2.1.1请求可源表信息要获得可用数据源的概述，可以请求源表（见6.3）。

GET / HTTP/1.1<CR><LF>
Host: ntrip.example.com<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
User-Agent: NTRIP ExampleClient/2.0<CR><LF>
Connection: close<CR><LF>
<CR><LF>
HTTP/1.1 200 OK<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
Ntrip-Flags: st_filter,st_auth,st_match,st_strict,rtsp<CR><LF>
Server: NTRIP ExampleCaster/2.0<CR><LF>
Date: Tue, 01 Jan 2008 14:08:15 GMT<CR><LF>
Connection: close<CR><LF>
Content-Type: gnss/sourcetable<CR><LF>
Content-Length: 1234<CR><LF>
<CR><LF>
sourcetable data

NtripClient将初始请求发送给NtripCaster。第一行请求sourcetable，最后一行请求结束。 7个标题行是可选的，但建议最小。

NtripCaster将请求的数据作为回复发送。同样，所有标题行都是可选的，但建议最小值。

对于Ntrip1.0，NtripCaster的响应有点不同。如果缺少挂载点而不是错误回复，也会使用此响应。

SOURCETABLE 200 OK<CR><LF>
Server: NTRIP ExampleCaster 2.0/1.0<CR><LF>

Connection: close<CR><LF>
Content-Type: text/plain<CR><LF>
Content-Length: 1234<CR><LF>
<CR><LF>
sourcetable data

2.1.2请求GNSS数据

实际访问想要的GNSS数据，必须使用以下请求。

GET /ExampleMountpoint HTTP/1.1<CR><LF>
Host: ntrip.example.com<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
User-Agent: NTRIP ExampleClient/2.0<CR><LF>
Authorization: Basic bnRyaXA6c2VjcmV0<CR><LF>
Connection: close<CR><LF>
<CR><LF>
HTTP/1.1 200 OK<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
Server: NTRIP ExampleCaster/2.0<CR><LF>
Date: Tue, 01 Jan 2008 14:08:15 GMT<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>
<CR><LF>
data

再次，大多数标题行是可选的，但建议使用。 “授权”行用于传输用户名和密码。

2.3节解释了授权消息。不受保护的数据流不需要此行。有关传输编码的信息在2.4中给出。

有关非物理参考站（虚拟参考站）（用户位置相关）数据流的处理，请参见2.1.3。

违反HTTP，标准Ntrip版本1.0服务器将回答以下行：

ICY 200 OK<CR><LF>

任何客户端都应该能够检测到这个答案并假设Ntrip 1.0传输（这意味着没有Ntrip 2.0的功能可用））。当初始请求来自仅限Ntrip 1.0的客户端时，任何脚轮都应回答此消息。如果出现错误（非法密码除外），Ntrip 1.0施法者将发送源表而不是错误回复。

2.1.3 NMEA请求消息

对于某些依赖于网络的应用程序，必须将NtripClient的位置发送到NtripCaster。 NtripCaster可以使用该位置为非物理参考站提供数据流或确定要广播的最佳数据流。如果streams <nmea>参数设置为“1”（参见6.3），则NtripCaster会等待至少一个位置字符串来准备数据并开始发送。为了支持这些动态数据流，可以通过两种方式修改对某个挂载点的请求：Ntrip 2.0 NtripClient的首选方法是在标题行中传输NMEA位置。

为此，使用以下附加标题行：

Ntrip-GGA：$ GPGGA，040941.00,5034.91174，... 47.7，M ,, * 51 <CR> <LF>

Ntrip 1.0中也支持的第二种方法是转移NMEA位置在向服务器发出请求后未经修改（例如在空行之后）。

$ GPGGA，040941.00,5034.91174，... 47.7，M ,, * 51 <CR> <LF>

NtripClient可以随时发送多个NMEA GGA字符串或其他类型的NMEA字符串。请注意，发送包含纬度和经度信息的NMEA字符串允许NtripCaster跟踪NtripClient的位置。 NtripCaster的运营商可能希望考虑通知客户这个潜在的隐私问题。

2.1.4请求过滤的源表格

为了减少传输给用户的可源表信息的数量，在Ntrip 2.0中引入了仅请求部分源表的接口。

这是Ntrip协议版本2.0的可选功能。 NtripClients可能支持也可能不支持。 NtripCaster必须支持过滤后的源表，但如果未实现完全过滤器支持，则可能会传输超出过滤器字符串请求的信息。

sourcetable请求在URL中编码。在对源表（“/”）的正常请求之后，附加问号和请求字符串。

GET /？requeststring HTTP / 1.1 <CR> <LF>

“requeststring”包含一个或多个变量及其值。它们以form1 = value＆variable2 = value＆variable3 = value的形式指定。

定义的变量包括：

•auth“auth = 1”的使用将sourcetable限制为允许用户访问的所有元素。这也意味着必须将正确的授权与sourcetable请求一起传递。

•strict使用“strict = 1”会强制NtripCaster返回非法请求的错误（包括有用的错误消息）。默认值是尽可能容错，并在出现问题时返回包含所有请求信息（可能还有更多）的源表。

•match 简单字符串比较的简易过滤方法

•filter 复杂过滤方法

“匹配”和“过滤”这两种方法基于相同的结构。 sourcetable条目的每个字段都是字符串或整数值。请求字符串由分号分隔的元素组成，这些元素表示该条目的一列。最后的空字段可以省略。一些示例：

GET /？match = CAS ;;;;; 0; DEU HTTP / 1.1 <CR> <LF>

请求（德国境内）NMEA功能的所有Caster条目。

GET /？match = CAS HTTP / 1.1 <CR> <LF>

请求所有Caster条目。

GET /？match = STR ;;;;;;; EUREF HTTP / 1.1 <CR> <LF>

请求所有EUREF流。

GET /?filter=STR;;;;;;;EUREF;;>=50+<=51;>=8.1+<=8.6;;;;;N
HTTP/1.1<CR><LF>

北纬50至51度，东经8.1至8.6度（编码问题见下文）。

GET /？auth = 1＆match = STR HTTP / 1.1 <CR> <LF>

请求用户有权访问的所有流。这需要额外传输授权信息。

两种方法“匹配”和“过滤”的复杂性不同。 “匹配”方法只进行简单的字符串比较;它只测试条目是否等于给定元素。 “filter”方法添加逻辑运算符（从左到右计算多个运算符）和更复杂：

•字符串和数字的逻辑运算符：

o运算符不反转请求：！

o运算符AND选择多个要求：+

o运算符或选择备选项：|

•数字运算符：

o方程式：<n（低于），> n（高于），<= n（低于或等于），> = n（高或相等），= n（等于），！= n（不等于）

o近似值（最近值）：~n

•字符串运算符：

o *表示任何字符串（例如“* REF”选择EUREF和GREF，“RTCM *”选择任何RTCM类型）。

o方括号（）可用于分组元素：（EU | G）REF | IGS将选择EUREF，GREF或IGS。

每当不需要“过滤器”的增强功能时，NtripClient应使用“匹配”方法。如上所述，可以在一个请求中使用多个过滤器。结果是所有过滤器的逻辑“与”。

要在GET行中输入字符串，必须使用URL编码对其进行编码（请参阅[RFC2396]的第2.4章）。请求

GET /?filter=STR;;;;;;;EUREF;;>=50+<=51;>=8.1+<=8.6;;;;;N
HTTP/1.1<CR><LF>

编码后

GET /?filter=STR;;;;;;;EUREF;;%3E%3D50%2B%3C%3D51;%3E%3D8.1%2B%3C%3D
8.6;;;;;N HTTP/1.1<CR><LF>

编码超过必要的字符是没有错的。

对于NtripCaster实现，支持可源表（sourcetable filtering）过滤是可选的。 如果未实施过滤，则必须检测请求并将其作为正常的源表格请求处理。 客户端可以通过分析Ntrip-Flags标题行来检测服务器是否支持过滤。

2.2 NtripServer到NtripCaster通信

NtripServer只有一个目的。 将数据上传到NtripCaster。 因此协议很简单。 与NtripClient一样，每个连接都由NtripServer启动，并由NtripCaster响应

POST /ExampleMountpoint HTTP/1.1<CR><LF>
Host: ntrip.example.com<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
Authorization: Basic bnRyaXA6c2VjcmV0<CR><LF>
User-Agent: NTRIP ExampleServer/2.0<CR><LF>
Connection: close<CR><LF>
<CR><LF>

HTTP/1.1 200 OK<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
Server: NTRIP ExampleCaster/2.0<CR><LF>
Date: Tue, 01 Jan 2008 14:08:15 GMT<CR><LF>
Connection: close<CR><LF>
<CR><LF>

在请求响应对之后，随后是从NtripServer到NtripClient的数据传输。其他可选标头（特别是标头Ntrip-STR）在2.6中描述。有关传输编码的重要说明，请参见2.4。

Ntrip 1.0协议使用不同的请求。它使用SOURCE而不是POST，并在SOURCE之后直接传输密码（无用户名）。标题User-Agent重命名为Source-Agent。可选标头Ntrip-STR仅命名为STR。

SOURCE secret /ExampleMountpoint HTTP/1.1<CR><LF>
Source-Agent: NTRIP ExampleServer/2.0<CR><LF>
<CR><LF>

服务器应答

OK <CR> <LF>或ICY 200 OK < CR> <LF>

Ntrip 1.0错误处理不符合2.5中描述的标准。如果密码无效，则回复为

ERROR - Bad Password<CR><LF>

，或者在已使用或无效的挂载点的情况下，它是

ERROR - Mount Point Taken or Invalid<CR><LF>

ERROR - Already Connected<CR><LF>

可以在[SRCNS]中找到示例NtripSource实现。

2.3身份验证

HTTP的身份验证在文档[RFC2617]中描述。对于Ntrip 1.0，这在NtripClient中用于NtripCaster通信。 Ntrip 2.0还在NtripServer中引入了NtripCaster通信。 Ntrip所需的最低要求是基本身份验证方法。

2.3.1基本身份验证客户端（NtripClient或NtripServer）在发送给NtripCaster的请求中包含用户名和密码作为标头。

Authorization: Basic bnRyaXA6c2VjcmV0<CR><LF>

本例中的传输字符串是Basetr传输编码中的“ntrip：secret”，如[RFC2045]中的6.8所述，其中“ntrip”是用户名，“secret”是密码。

如果挂载点受到保护且未传输“授权”行或数据错误，则服务器将回答401错误代码并在回复中包含以下行。

WWW-Authenticate: Basic realm="/ExampleMountpoint”<CR><LF>

基本认证方案是一种过滤HTTP服务器上资源的未授权访问的非安全方法。它基于客户端之间的连接的假设并且服务器可以被视为可信赖的运营商。由于在开放网络中通常不是这样，因此应该谨慎使用基本认证方案.

2.3.2摘要认证

NtripCaster必须支持基本认证。可以选择支持摘要认证对于需要更高安全性的用户身份验证的应用程序。源代码流条目包含一个标志，无论是否必须使用基本身份验证或摘要身份验证。为了兼容性，NtripCaster还应该在请求摘要时支持基本身份验证，除非安全性考虑阻止使用Basic身份验证。

与基本一样，摘要访问身份验证可验证通信双方是否都知道共享密钥（密码）。与Basic不同，这种验证可以在不明确发送密码的情况下完成，这是Basic的最大弱点。与基本访问身份验证一样，摘要方案基于简单的质询响应范例。 Digest方案使用nonce值进行挑战。有效响应包含用户名，密码，给定nonce值，HTTP方法和请求的URI的校验和（对于Ntrip，MD5 [RFC1321]校验和是强制的）。因此，密码永远不会以明文形式发送。

摘要访问认证方案在概念上类似于Basic方案。修改后的WWW-Authenticate标题行和Authorization标题行的格式在[RFC2617]中指定。

2.4传输编码

Transfer-Encoding: chunked<CR><LF>

分块传输编码用于传输一系列块，每个块都有自己的大小信息。这允许将流数据与信息一起传输以验证传输的完整性。每个NTRIP 2.0组件都必须能够处理此传输编码。建议使用分块传输编码来传输流数据（脚轮到客户端和服务器到脚轮）。它在[RFC2616]的第3.6章中描述。基本思想是在块本身之前将以下数据块的大小发送为十六进制数。

以下是以分块传输编码传输的14（十六进制E）和19（十六进制13）字节串的示例。

E<CR><LF>
TEST TEST TEST<CR><LF>
13;extension<CR><LF>
TEST TEST TEST TEST<CR><LF>

HTTP标准允许传输编码头部的扩展（由a分隔从字节数开始的分号），如果未知则应忽略。确切的定义可以在HTTP标准中找到。对于使用软件的Ntrip，只需要在分号后开始扩展，并且应该忽略。上面示例的第三行包含此类扩展。 “扩展名”一词是要忽略的文本的占位符。

来自NtripCaster的起始RTCM 2数据传输的示例可能如下所示。

HTTP/1.1 200 OK<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
Server: NTRIP ExampleCaster/2.0<CR><LF>
Date: Tue, 01 Jan 2008 14:08:15 GMT<CR><LF>
Cache-Control: no-store, no-cache, max-age=0<CR><LF>
Pragma: no-cache<CR><LF>
Connection: close<CR><LF>
Transfer-Encoding: chunked<CR><LF>
Content-Type: gnss/data<CR><LF>
<CR><LF>
2D<CR><LF>
fAFC~cM{x|}@pT\PrgRi@|`VjmMC@RAKFeTl}_Tdoxgju<CR><LF>
1E<CR><LF>
Y~x|K\rLAHhUPzCQAjoY\EDn`pp~Uj<CR><LF>
1E<CR><LF>
fAGCtcir~gWjoEYQAjo|cz{Qzpp~UO<CR><LF>
...

2.5错误处理

每当客户端（NtripServer或NtripClient）发出错误请求时，NtripCaster都会响应错误代码。

HTTP/1.1 code text<CR><LF>
Ntrip-Version: Ntrip/2.0<CR><LF>
Server: NTRIP ExampleCaster/2.0<CR><LF>
Date: Tue, 01 Jan 2008 14:08:15 GMT<CR><LF>
Content-Type: text/html<CR><LF>
Connection: close<CR><LF>
<CR><LF>
long text

有3个字段，根据错误情况而变化。最重要的是代码字段。代码后面的文本是描述字段，长文本是（可选的）更好的描述（通常是HTML格式）。下表列出了客户可能期望的一组错误及其含义。有关状态代码的更详细说明，请参阅HTTP文档[RFC2616]的第6.1.1章和第10章。

Code Short text 　　　　　　　　Description
200 OK 　　　　　　　　　　　　　　everything was fine
401 Unauthorized 　　　　　　　　No or wrong authorization (see also header WWW-Authenticate)
404 Not Found 　　　　　　　　　　Mountpoint of request not found (see 2.1.1 for Ntrip 1.0)
409 Conflict 　　　　　　　　　　Mountpoint already in use by another NtripServer
500 Internal Server Error 　　e. g. some internal errors
501 Not Implemented 　　　　　　e. g. Requested function not implemented in NtripCaster
503 Service Unavailable 　　　　e. g. in case of NtripCaster overload or bandwidth limitations

在NtripCaster过载或带宽限制的情况下Ntrip 1.0中的错误处理并不总是遵循此标准并在适当的位置进行描述。

2.6标题行列表

标题行用于在请求或响应中传输附加信息。这些可分为三大类。

•接收器必须在特定协议版本中支持的标题行

•可选或信息标题行

•可以支持或可以忽略的行（可选功能）。

三个Ntrip组件不会同等使用这些线型。一些仅由NtripCaster使用，一些由NtripServer或NtripClient使用，一些由多个组件使用。本节详细讨论了标题行及其用法。可以在HTTP文档中找到更详细的信息。

对于每个标题行和Ntrip组件，将给出一个注释，标题行是必需的，推荐的，可选的还是在发送时不使用。请注意，接收端需要知道如何处理这些线路（例如，NtripCaster和NtripServer使用Transfer-Encoding，因此NtripClient和NtripCaster都需要知道如何在接收线路时处理线路）。

2.6.1标准HTTP

Authorization: Basic bnRyaXA6c2VjcmV0<CR><LF>
Caster: not used Server: required Client: required

必需要将授权信息传输给脚轮，使用此标头。另见2.3。

Cache-Control: no-store, no-cache, max-age=0<CR><LF>
Caster: recommended Server: optional Client: not used

未使用告诉代理服务器禁用缓存。另请参见Pragma标头。接收方信息。

Connection: close<CR><LF>
Caster: recommended Server: recommended Client:
recommended

告诉接收组件不使用持久连接。有关Ntrip软件的接收方信息。

Content-Length: 1234<CR><LF>
Caster: optional Server: not used Client: not used

未使用此标头指定标头部分结束后的字节数。这不能用于流数据，因为字节计数未知。对于可源代码传输和错误代码，建议使用。接收方信息。

Content-Type: gnss/data<CR><LF>
Caster: recommended Server: not used Client: not used

未使用标头用于通知传输数据的数据类型。 NtripCaster使用的类型可能是：“text / html”，例如对于错误消息，文本的“text / plain”（例如sourcetable）和两个特殊的NTRIP 2.0类型“gnss / sourcetable”和“gnss / data”。接收方信息。

Date: Tue, 01 Jan 2008 14:08:15 GMT<CR><LF>
Caster: recommended Server: optional Client: optional

日期格式记录在HTTP文档[RFC2616]的第3.3章中。接收方信息。

Host: ntrip.example.com<CR><LF>
Caster: optional Server: recommended Client:
recommended

此行包含请求的主机名。它是虚拟主机所必需的（在一个服务器上具有相同端口的NtripCaster的多个不同实例）。有关接收方的信息，但虚拟脚轮需要。

Server: NTRIP ExampleCaster/2.0<CR><LF>
Caster: recommended Server: not used Client: not used

NtripCaster发送的服务器标识字符串。它应包含以下序列：“NTRIP”+空格+ SoftwareName +“/”+版本（+空格+附加文本）。这是接收方的信息。

对于Ntrip 1.0，此行遵循以下顺序：“NTRIP”+ space + SoftwareName + space + Version +“/ 1.0”。斜杠后面的版本包含Ntrip 1.0版。

Pragma: no-cache<CR><LF>
Caster: recommended Server: optional Client: not used

告诉代理服务器禁用缓存。另请参见Cache-Control标头。接收方信息。

Transfer-Encoding: chunked<CR><LF>
Caster: recommended Server: recommended Client: not used

此标头指定使用的传输编码。见2.4。连接的接收端必须能够正确处理编码。

User-Agent: NTRIP ExampleServer/2.0<CR><LF>
Caster: not used Server: recommended Client:
recommended

NtripClient或NtripServer发送的客户端标识字符串。它应包含以下序列：“NTRIP”+空格+ SoftwareName +“/”+版本（+空格+附加文本）。对于NtripServer协议版本1.0，使用字符串Source-Agent。接收方信息。

WWW-Authenticate: Basic realm="/ExampleMountpoint”<CR><LF>
Caster: required Server: not used Client: not used

此标头是401类型错误响应所必需的。另请参见2.3.

2.6.2 Ntrip特定的

Ntrip-GGA: $GPGGA,040941.00,5034.91174, ... 47.7,M,,*51<CR><LF>
Caster: not used Server: not used Client:
recommended

此行用于将初始用户位置传输到NtripCaster，因此虚拟化可以计算参考站。最好在NTRIP版本2.0中使用此标题行.

Ntrip-Version: Ntrip/2.0<CR><LF>
Caster: recommended Server: recommended Client:
recommended

通知接收端有关使用的Ntrip版本目前1.0和2.0是可能的.Ntrip 2.0需要选择正确的通信协议.

Ntrip-STR: ;ExamplePlace; ... ;none;N;N;400;none<CR><LF>
Caster: not used Server: recommended Client: not used

这用于将sourcetable条目与上传的数据一起传输。提供的字符串从s的STR条目的入口3开始ourcetable（跳过行标识符和挂载点）。对于Ntrip 1.0，标头是STR而不是Ntrip-STR。

Ntrip-Flags: <flag1>,<flag2>,...<CR><LF>
Caster: recommended Server: not used Client: not used

这用于指定Ntrip程序的功能。此标头中包含的每个元素都指定一个可选或扩展功能。目前只有源表过滤以这种方式定义。也允许私人扩展实施者。这些必须遵循“x_companyname_value”形式，以防止与未来扩展冲突。任何施法者都应至少在每个源表格请求中传输此标题行。

当前定义的是以下标志：

•st_auth支持源表过滤的元素“auth”。

•st_match支持源表过滤的元素“匹配”。

•st_filter支持源表筛选的元素“过滤器”。

•st_strict支持源表过滤的“严格”元素。

•支持rtsp RTSP / RTP协议

•支持plain_rtp仅RTP协议

2.6.3过时的Ntrip 1.0标头

Ntrip 1.0协议使用一些不再推荐用于较新实现的标头（向下兼容性除外）。

STR: ;ExamplePlace; ... ;none;N;N;400;none<CR><LF>
Caster: not used Server: optional Client: not used

Ntrip 1.0使用STR而不是标头Ntrip-STR。

Source-Agent: NTRIP ExampleServer/2.0<CR><LF>
Caster: not used Server: recommended Client: not used

Ntrip 1.0在NtripServer中使用源代理而不是用户代理。