CN114759965A - 数据包传输方法、装置、存储介质 - Google Patents

Abstract

本公开提供一种适合遥感卫星在轨信息服务的数据包传输方法、装置存储介质，涉及遥感技术领域，所述方法包括：获取待传输的数据包，判断所述待传输的数据包的类型，所述数据包的类型包括文件和消息，当所述数据包的类型为文件时，采用预设的可靠文件传输方式或不可靠文件传输方式传输所述数据包，当所述数据包的类型为消息时，对所述消息进行序列化封装，并对封装后的消息进行传输。

Description

数据包传输方法、装置、存储介质

技术领域

本申请涉及遥感技术领域，尤其涉及一种适合遥感卫星在轨信息服务的数 据包传输方法、装置、存储介质。

背景技术

近年来，各类遥感卫星爆发式增长，天基信息服务的时效性不断增强，但 仍难以满足应急救灾等应用的实时信息服务要求。实现天基信息服务的高时效 响应的可行方法是在轨完成信息处理并直接面向用户终端进行分发。为了实现 这一目标，需要在卫星互联网络基础上建立一套适合遥感信息分发的应用层通 信方法。

现有的空间通信网络技术主要由空间数据系统咨询委员会(CCSDS，Consultative Committee for Space Data System)主持制定，CCSDS提出了CFDP (CCSDSFile Delivery Protocol)协议实现星际互联网数据的传输、交换和共享。 该协议要求传输的数据是以文件的形式并采用统一标准的传输协议，这种方式 能提高传输的效率以及节约有限的空间链路资源，还可以提高空间任务间的交 互操作能力。通过CFDP协议可以用文件传输的方式来操作航天器或者进行远 程文件系统管理。它提供了有确认和无确认两种工作模式，而且可以应用于单 向、半双工及全双工链路，适应从近地轨道空间到星际间的不同传输延时。在 点对点传输任务中，可以只通过单向链路来完成传输任务；在非点对点传输任 务中，可以通过有限个中继节点的存储转发功能来完成传输任务。

此外，国内外研究人员还采用了按字节定义等方式来实现遥感信息的传输， 该方法能够较好地对待传输的信息进行编码，实现信息的高效传输。

针对天基遥感信息在轨传输，传统方法存在如下缺点：

CFDP协议是一种通用的空间通信网络传输协议，仅支持文件传输方式。 而在天基遥感信息在轨实时服务中，需要传输的信息包括用户服务请求、任务 控制指令与执行状态信息、图像、文字报等，CFDP协议不能满足多样化的数 据传输需求。

采用按字节定义的方式能够实现遥感信息的高效传输，但该方法需要按照 卫星载荷数据类型进行定制，通用性较差，不利于遥感信息空间传输的标准化。

发明内容

本申请的主要目的在于提供一种适合遥感卫星在轨信息服务的数据包传输 方法、装置、存储介质，旨在针对天基遥感信息在轨传输问题，建立一套标准 化的应用层数据包传输方法，能够兼容各类消息和文件的传输，适应不同类型 遥感信息的星间和星地传输。

为实现上述目的，本申请实施例第一方面提供一种数据包传输方法，包括；

获取待传输的数据包；

判断所述待传输的数据包的类型，所述数据包的类型包括文件和消息；

当所述数据包的类型为文件时，采用预设的可靠文件传输方式或不可靠文 件传输方式传输所述数据包；

当所述数据包的类型为消息时，对所述消息进行序列化封装，并对封装后 的消息进行传输。

可选的，在采用预设的可靠文件传输方式传输所述数据包的过程中，包括：

发送端将所述待传输数据包进行拆包，得到多个子数据包：

所述发送端将所述多个子数据包一起同时发送给接收端；

所述发送端向接收端所述发送数据包传输结束指令，并等待所述接收端发 送回复信息；

若所述发送端接收到所述回复信息，则所述发送端解析所述回复信息，确 定需要重传子数据包，并执行所述发送端将所述多个子数据包一起同时发送给 接收端的步骤。

可选的，在采用预设的可靠文件传输方式传输所述数据包的过程中，包括：

所述接收端对接收到的所述多个子数据包进行解析和校验，判断所述多个 子数据包中发生损坏的数据包以及完好的数据包；

所述接收端存储所述完好的数据包，并提取所述发生损坏的数据包的信息；

所述接收端将所述发生损坏的数据包的信息作为所述回复信息发送给所述 发送端。

可选的，所述多个数据包中的每个数据包中均含有一个指定域，所述指定 域包含数据包所携带的文件的内容的起始位和终止位；

所述接收端通过检查接收到的数据包中包含的指定域所携带的文件的内容 的起始位和终止位，确定所述丢失数据包信息。

可选的，在采用预设的不可靠文件传输方式传输所述数据包的过程中，包 括：

发送端将数据包依次传输给接收端，所述数据包内包括本次事务ID号以及 文件信息，以使接收端接收数据包，并解析所述数据包获取文件信息，落盘所 述文件信息直至传输结束。

可选的，当所述数据包的类型为消息时，所述数据包的固定包头字段包括 版本、数据包类型、消息分类、消息长度、源端应用ID、目的端应用ID、指 令序列化方式、消息内容。

可选的，当所述数据包的类型为文件时；

所述数据包包括文件控制指令类型的数据包和文件类型的数据包；

所述文件控制指令类型的数据包包头字段包括版本、数据包类型、消息序 列号长度、保留、消息长度、传输ID、消息序列号、控制指令、控制指令内容；

所述文件类型的数据包包头字段包括版本、数据包类型、消息序列号长度、 保留、消息长度、传输ID、消息序列号、传输ID、消息序列号、起始位置、 结束位置、文件包数据。

可选的，当所述数据包的类型为消息时，对所述消息进行序列化封装，并 对封装后的消息进行传输，包括：

将所述数据包按照预置优先级策略进行排序；

按优先级排列顺序依次响应接收到的数据包，并将所述数据包转发到相应 的应用组件。

本申请实施例第二方面提供一种适合遥感卫星在轨信息服务的数据包传输 装置，所述装置包括：

获取模块，用于获取待传输的数据包；

判断模块，用于判断所述待传输的数据包的类型，所述数据包的类型包括 文件和消息；

第一传输模块，用于当所述数据包的类型为文件时，采用预设的可靠文件 传输方式或不可靠文件传输方式传输所述数据包；

第二传输模块，用于当所述数据包的类型为消息时，对所述消息进行序列 化封装，并对封装后的消息进行传输。

本申请实施例第四方面提供了一种计算机可读存储介质，其上存储有计算 机程序，所述计算机程序被处理器执行时实现本申请实施例第一方面提供的 方法。

本公开可以实现以下有益效果：

同时支持消息和文件传输，计算复杂度低，能够适应星间和星地传输要求， 同时具备良好的可扩展性，能够适应各类遥感信息的空间传输特点。针对消息 的传输设计了通用的数据类型方便上层业务使用；针对文件的传输，根据卫星 网络的移动性特点设计了可靠传输和不可靠传输两种机制，同时支持断点续传。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施 例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述 中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创 造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1a为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输方 法的架构图；

图1b为本申请一实施例提供的适合遥感信息传输的应用层通信方法的示意 图；

图2为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输方 法处理上行消息的流程图；

图3为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输方 法处理下行消息的流程图；

图4为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输方 法可靠传输的框架图；

图5a为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输 方法发送、端可靠传输的工作流程图；

图5b为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输 方法接收端可靠传输的工作流程图；

图6a为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输 方法发送端可靠传输中ARQ传输机制的工作流程图；

图6b为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输 方法接收端可靠传输中ARQ传输机制的工作流程图；

图7a为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输 方法发送端可靠传输的断点续传的工作流程图；

图7b为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输 方法接收端靠传输的断点续传的工作流程图；

图8为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输方 法发送端不可靠传输的框架图；

图9为本申请一实施例提供的适合遥感卫星在轨信息服务的数据包传输装 置。

具体实施方式

为使得本申请的申请目的、特征、优点能够更加的明显和易懂，下面将结 合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描 述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基 于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的 所有其他实施例，都属于本申请保护的范围。

请参阅图1a和图1b，如图1a所示，本公开提供的适合遥感卫星在轨信息 服务的数据包传输方法采用协议实现，该协议工作在应用层，可向上层应用服 务程序提供消息和文件传输服务，底层通过调用传输层接口实现数据收发。协 议主体包括消息传输实体、文件传输实体、虚拟文件库。

消息传输实体：协议实体通过调用底层传输协议接口实现数据的发送和接 收，并向应用程序提供唯一的服务接口，支持数据安全校验。

文件传输协议实体：协议实体通过调用底层传输协议接口实现数据的发送 和接收，并向应用程序提供唯一的服务接口，支持可靠传输和不可靠传输两种 传输方式，传输性能取决于服务质量的选择。

虚拟文件库：文件传输协议的操作是将文件从一个存储介质复制到另一个 存储介质，因此协议实体需要访问本地的存储介质。各种介质提供的访问能力 和方式是不同的，为了避免这种底层访问的差别带来的问题，本方法提供了虚 拟文件库，为文件操作提供了统一的访问接口，虚拟文件库实质上是一套接口 函数。其中，通信网络的各节点在协议实现时需要将虚拟文件库与本地实际存 储介质的软件和硬件进行映射。

如图1b所示，该方法包括：

S101、获取待传输的数据包；

S102、判断所述待传输的数据包的类型，所述数据包的类型包括文件和消 息；

S103、当所述数据包的类型为文件时，采用预设的可靠文件传输方式或不 可靠文件传输方式传输所述数据包；

S104、当所述数据包的类型为消息时，对所述消息进行序列化封装，并对 封装后的消息进行传输。

请参阅图2和图3，如图2和图3所示，应用层根据数据包类型分为消息 和文件进行处理，同时设计了用户身份安全验证和服务权限验证接口，有利于 提高网络应用的安全性。

对于消息传输，本公开提供的应用层通信方法对消息类型封装、消息传输 管理、消息传输安全性进行设计。

对于消息类型封装，在天基遥感信息服务中，需求传输的消息包括数据查 询、下载请求、观测需求、任务规划结果等信息，按照传统对消息按字节定义 的方式通用性差，不便于解析。支持对消息进行序列化封装，序列化的方式包 括protobuf和JSON等，具体采用哪种方式进行封装可由开发人员根据链路带 宽、处理器性能等因素综合考虑。对于星地上行微波链路、星间UHF等微波通 信链路，由于带宽较低，可考虑编码效率较高的protobuf方式进行封装。对于 激光通信等高速星间和星地链路，可考虑易于编程实现的JSON方式进行封装。 此外考虑到协议兼容性，也可支持按字节定义的消息类型。

对于消息传输管理，结合限时轮询和消息生命周期管理机制，有效实现对 星间和星地通信请求的闭环、及时响应，进而完成了消息交互功能。当通信链 路建立后，消息传输管理立即开始接收请求，并把接收到的消息按照优先级进 行排序。消息传输管理将优先响应高优先级消息，并将其转发到相应的应用组 件。然后等待应用组件回复。通信管理采用限时轮询机制，当应用组件长时间 无回复时自动重发消息，避免了接收阻塞，多次重发失败后则自动结束消息响 应周期，并且向对端发送消息转发失败信号。最后，消息传输管理将接收到的 回复消息通过通信链路回传到发送端。当通信链路中断后，禁止使用链路收发消息。

对于消息传输安全性，随着卫星组网规模的不断扩大，对通信网络的安全 性要求不断提高。应用层消息传输服务必须包含对网络通信安全性的设计，在 星间和星地组网通信时，需要对设备身份进行认证，对于各类服务请求也要进 行权限的验证。因此本方法的设计增加了安全类数据包，可在各类消息进行传 输时加入安全验证机制，从而保证整个网络具有较强的安全防御能力，避免被 攻击破坏。

请参阅图4，如图4所示，可靠传输的协议实体由三部分组成，拆包连续 发送，校验组包和自动重传。拆包连续发送包括将文件拆包并且连续发送。正 常的星地通信时延在毫秒量级，也就是说一次有效及时的消息同步需要几毫秒 时间，因此数据文件必须被拆分为若干个数据包，并且一次性全部发出，这样 可以充分利用通信链路时间而不需要将有效的通信时间浪费在同步确认消息 中。校验组包是在发送端将所有需要一次性发送的数据包发送完之后，发送同 步结束指令，并且等待接收端回复接收信息，接收端需要根据接收到的回复信 息，来确认是否需要需要重传，接收端在接收到数据包后，需要对数据包进行 校验并且将有效的数据包信息存储，等待接收到发送端发来的结束指令后将已 经接收到的数据包信息回穿到发送端。丢包重传包括等待发送端接收到接收端 回复的结束指令消息后，自动解析消息，并且确认需要重传的数据包并且连续 发送丢失的数据包。

请参阅图5a和5b，如图5a和5b所示，可靠传输的工作流程包括以下步 骤：发送端将所述待传输数据包进行拆包，得到多个子数据包：所述发送端将 所述多个子数据包一起同时发送给接收端；所述发送端向接收端所述发送数据 包传输结束指令，并等待所述接收端发送回复信息；若所述发送端接收到所述 回复信息，则所述发送端解析所述回复信息，确定需要重传子数据包，并执行 所述发送端将所述多个子数据包一起同时发送给接收端的步骤。所述接收端对 接收到的所述多个子数据包进行解析和校验，判断所述多个子数据包中发生损 坏的数据包以及完好的数据包；所述接收端存储所述完好的数据包，并提取所述发生损坏的数据包的信息；所述接收端将所述发生损坏的数据包的信息作为 所述回复信息发送给所述发送端。

具体来说：

第一步，开始发送前，发送端先发送元数据包，内含本次事务ID号、源 IP地址、目的IP地址、以及文件名和文件大小等参数；

第二步，接收端收到后并不发送ACK确认报文；

第三步，无论接收端是否收到了元数据包，发送端此时都开始发送文件数 据，直至文件结束；

第四步，接收端通过正确接收到的协议数据单元(PDU，Protocol Data Unit) 报文中的一些选项，如序列号，起始字节和终止字节等来判断中途是否有PDU 在传输中丢失。若接收端收到一个或多个正确的PDU，内含一个相同的新事务 号，则证明新的文件传送已经开始，而且元数据包已丢失；

第五步，文件发送完毕，发送端发送结束数据包，接收端接收到后需响应 结束应答数据包；

第六步，接收端发送NAK报文请求重传丢失的数据包，并重复这个过程， 直到它获得所有的数据为止。接收端收到所有正确的数据后，发送结束指令， 请求关闭本次事务，发送端响应FINACK报文，至此文件传输结束。

请参阅图6a和6b，如图6a和6b所示，在可靠传输中，引入了“事务”的概 念，每一次事务代表一次文件传输过程。本方法在需要发送数据时，每次发送 一组数据，即在每次事务中发送固定数目的PDU。发送端首先发送元数据包， 内含本次事务ID号、源文件名、目的文件名、文件大小和ID等参数，通知接 收端开始传输文件。与数据包相同，元数据包无确认信息，即使没有成功被接 收端正确接收，发送端同样可继续传输文件数据包。即发送端和接收端不需要 握手便可开始传输文件。如果接收端接收到了一个标有新的ID的PDU，就代表一个新的文件传输开始了，本方法中的每一个数据包都含有一个特殊的域， 它标明这个数据包所携带的文件内容的起始位和终止位，接收端通过检查已经 接收到的数据包序列就可以确定哪些数据包发送失败。

在可靠传输方式中需要进行重传来保证信息的可靠性。本方法应用的自动 重传机制，与传统方案相比，本方法将连续发送PDU给接收端，将接收端将接 收到的数据包保存起来，特别地，当传输数据出现错误时，接收端并不即时向 发送端发送否定确认信息，而是将数据包自动丢弃，继续接收下一个数据包。 当接收到结束指令后，接收端会根据一定的规则核对已经接收到的数据包，并 且将丢包信息整合成数据包发送给发送端，请求重新发送丢失数据包。需要说 明的是，为了充分利用通信时间和通信带宽，发送端发送的含有文件信息以及 拆包信息的请求数据包是和文件数据包一起发送的，也就是说接收端可能再接 收到结束数据包之前只接收到文件数据包而没接收到请求数据包，这样接收端 就无法得知需要再传哪些包，因此可靠传输协议对结束指令包回复规则做了特 殊设计来保证可靠高效传输。

请参阅图7a和7b，如图7a和7b所示，断点续传机制是在自动回传机制 上，通过建立合理的数据包管理方案来实现的。在天基信息系统应用中，由于 星地链路通信时间窗口有限，加之上行行速度有限，所以在一个窗口时间内往 往无法完成一次完整的文件传输，为了避免重复发送数据包造成时间和带宽上 的浪费，有必要建立合理的断点续传机制，在收发方检测到星地链路断开后， 可以及时保存当前文件传输的状态，在下一次星地链路恢复正常后可以根据用 户手动启动或者系统自动设置开始续传文件。为了在星地特殊链路状态下提高 文件传输效率，可靠传输协议中的断点续传机制和传统应用层中的断点续传协 议最大的不同是，在收发两方增加了文件管理数据库模块管理文件传输状态， 文件管理数据库的设计成为了断点续传的核心关键技术。

文件管理数据库模块作为收发方实体的一部分，在首次启动系统时初始化 完毕，在之后开关机过程中或者断电过程中不会重新初始化，只会即使保存数 据库文件，除非接收到特殊的指令。在每一次启动文件传输之后，发送端会首 先根据文件名字查询数据库中相关的记录，若是有相同的文件名字，则提示用 户或者系统是否要续传文件，用户和系统可以根据需求决定是否续传文件，若 是需要续传，发送端就会提取出此文件对应的事务ID(每一次文件传输唯一的 标识)，然后获取当前事物的传输状态，并且解析拆包状态，最后决定开始传 输哪个数据包。接收端同样会在系统第一次启动时初始化一个数据库表用于管 理接收文件状态。当接收端接收到数据包时，会根据相应的事务ID来更新数据 库表，记录续传状态，知道直到传输结束为止。

接收端/发送端文件管理数据库模块中单独设计一个文件状态表，记录每次 文件传输的状态，表1为文件状态表表结构说明，其中EVENT_ID是作为标识 文件传输唯一键，表2是表1中STATUS含义说明，表3是事务信息表结构说 明。

表1

表2

取值	说明
		FINISHED	表示当前文件传输结束
FAILED	表示当前文件传输失败
		UNFINISHED	表示当前文件传输未结束

表3

请参阅图8，如图8所示，不可靠传输是一种单向通信模式，实现起来比 较简单。它是一种不可靠的服务模式，即接收端不会向发送端返回任何确认信 息，因此无法保证数据的完整性和正确性，只适用于一些对服务质量要求不高 的传输任务。

在不可靠传输中，文件的基本信息都包含在数据包包头中，接收端通过解 析数据包包头来获取文件信息。

不可靠文件传输的工作流程描述如下：

第一步，发送端将数据包依次传输给接收端，内含本次事务ID号、以及文 件名和文件大小，文件数据等参数，直到结束；

第二步，接收端接收数据包，解析获取文件信息，并且落盘，直至文件传 输结束。

以上不可靠传输和可靠传输两种策略可根据链路质量、数据的重要性和完 备性要求来选择确定。

本公开提供的适合遥感信息传输的应用层通信方法的数据包类型分为消息 和文件两种，在文件类型中，还分为文件控制指令和文件数据包两种。表4为 消息固定包头说明，表5为文件控制指令包头说明，表6为和文件数据包包头 说明。

表4

表5

表6

请参阅图9，本公开还提供了一种适合遥感卫星在轨信息服务的数据包传 输装置，该装置包括：

获取模块901，用于获取待传输的数据包。

判断模块902，用于判断所述待传输的数据包的类型，所述数据包的类型 包括文件和消息。

第一传输模块903，用于当所述数据包的类型为文件时，采用预设的可靠 文件传输方式或不可靠文件传输方式传输所述数据包。

第二传输模块904，用于当所述数据包的类型为消息时，对所述消息进行 序列化封装，并对封装后的消息进行传输。

进一步地，本公开实施例还提供了一种计算机可读存储介质，该计算机可 读存储介质上存储有计算机程序，该程序被处理器执行时实现前述图1所示实施 例中描述的数据包传输方法。进一步地，该计算机可存储介质还可以是U盘、 移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM， Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，在本公开各个实施例中的各功能模块可以集成在一个处理 模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在 一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功 能模块的形式实现。

所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或 使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明 的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或 部分可以以软件产品的形式体现出来。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述 为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的 动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。 其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施 例，所涉及的动作和模块并不一定都是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详 述的部分，可以参见其它实施例的相关描述。

以上为对本发明所提供的一种适合遥感卫星在轨信息服务的数据包传输方 法、装置、可读存储介质的描述，对于本领域的技术人员，依据本发明实施例 的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容 不应理解为对本发明的限制。

Claims (10)

1.一种适合遥感卫星在轨信息服务的数据包传输方法，其特征在于，所述方法包括：

获取待传输的数据包；

判断所述待传输的数据包的类型，所述数据包的类型包括文件和消息；

当所述数据包的类型为文件时，采用预设的可靠文件传输方式或不可靠文件传输方式传输所述数据包；

当所述数据包的类型为消息时，对所述消息进行序列化封装，并对封装后的消息进行传输。

2.根据权利要求1所述的数据包传输方法，其特征在于，在采用预设的可靠文件传输方式传输所述数据包的过程中，包括：

发送端将所述待传输数据包进行拆包，得到多个子数据包：

所述发送端将所述多个子数据包一起同时发送给接收端；

所述发送端向接收端所述发送数据包传输结束指令，并等待所述接收端发送回复信息；

若所述发送端接收到所述回复信息，则所述发送端解析所述回复信息，确定需要重传子数据包，并执行所述发送端将所述多个子数据包一起同时发送给接收端的步骤。

3.根据权利要求2所述的数据包传输方法，其特征在于，在采用预设的可靠文件传输方式传输所述数据包的过程中，包括：

所述接收端对接收到的所述多个子数据包进行解析和校验，判断所述多个子数据包中发生损坏的数据包以及完好的数据包；

所述接收端存储所述完好的数据包，并提取所述发生损坏的数据包的信息；

所述接收端将所述发生损坏的数据包的信息作为所述回复信息发送给所述发送端。

4.根据权利要求2或3所述的数据包传输方法，其特征在于，所述多个数据包中的每个数据包中均含有一个指定域，所述指定域包含数据包所携带的文件的内容的起始位和终止位；

所述接收端通过检查接收到的数据包中包含的指定域所携带的文件的内容的起始位和终止位，确定所述丢失数据包信息。

5.根据权利要求1所述的数据包传输方法，其特征在于，在采用预设的不可靠文件传输方式传输所述数据包的过程中，包括：

发送端将数据包依次传输给接收端，所述数据包内包括本次事务ID号以及文件信息，以使接收端接收数据包，并解析所述数据包获取文件信息，落盘所述文件信息直至传输结束。

6.根据权利要求1所述的数据包传输方法，其特征在于，当所述数据包的类型为消息时，所述数据包的固定包头字段包括版本、数据包类型、消息分类、消息长度、源端应用ID、目的端应用ID、指令序列化方式、消息内容。

7.根据权利要求1所述的数据包传输方法，其特征在于，当所述数据包的类型为文件时；

所述数据包包括文件控制指令类型的数据包和文件类型的数据包；

所述文件控制指令类型的数据包包头字段包括版本、数据包类型、消息序列号长度、保留、消息长度、传输ID、消息序列号、控制指令、控制指令内容；

所述文件类型的数据包包头字段包括版本、数据包类型、消息序列号长度、保留、消息长度、传输ID、消息序列号、传输ID、消息序列号、起始位置、结束位置、文件包数据。

8.根据权利要求1所述的数据包传输方法，其特征在于，当所述数据包的类型为消息时，对所述消息进行序列化封装，并对封装后的消息进行传输，包括：

将所述数据包按照预置优先级策略进行排序；

按优先级排列顺序依次响应接收到的数据包，并将所述数据包转发到相应的应用组件。

9.一种适合遥感卫星在轨信息服务的数据包传输装置，其特征在于，所述装置包括：

获取模块，用于获取待传输的数据包；

判断模块，用于判断所述待传输的数据包的类型，所述数据包的类型包括文件和消息；

第一传输模块，用于当所述数据包的类型为文件时，采用预设的可靠文件传输方式或不可靠文件传输方式传输所述数据包；

第二传输模块，用于当所述数据包的类型为消息时，对所述消息进行序列化封装，并对封装后的消息进行传输。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求1至8中的任一项所述的数据包传输方法中的各个步骤。

Images