本申请涉及但不限于通信
技术领域：
：，尤指一种网络通信方法及系统。
背景技术：
：：微服务架构已经成为软件系统开发和部署的主流模式之一。在微服务应用场景下，通常采用docker容器部署服务，以便实现服务的快速部署和实例的动态伸缩。docker是一个开源的应用容器引擎，允许开发者打包应用到容器中。在一般场景下，通常由kubernetes来实现容器集群的管理和调度，同时结合flannel等网络插件来实现docker容器之间的网络互联互通。然而，在很多面向中小企业的应用场景中，应用的服务功能相对比较单一，整体容量要求不高，这时如果再通过kubernetes和flannel来做docker容器的集群管理和网络互联互通，在加大系统整体工作负载的同时，也会使得整个系统变得比较复杂，进一步增大了整个系统运维管理的难度和成本。因此，在这种应用场景下，通常只使用docker基础服务来部署应用微服务，并利用docker基础服务所提供的容器管理接口来实施容器的管理。docker容器网络通常使用桥接(bridge)模式来构建。当docker容器需要对外暴露服务的端口时，在docker容器启动时采用端口映射的方式将docker容器内的端口映射到主机端口上暴露出去。这种端口映射的实现机理是通过在iptables(ip信息包过滤系统)中增加规则链来实现的。然而，在docker容器内需要多端口暴露的情况下，特别是一些数据传输的场景下，比如视频会议、视频分析、媒体服务器等应用，数据基于udp(userdatagramprotocol，用户数据报协议)传输，通常一路数据就需要暴露一对或者多对端口；如果继续使用端口映射方式，一来端口管理变得复杂，二来实际验证测试发现：基于iptables的端口映射和数据包转发，效率极其低下，时延加大，严重影响容器内应用的业务功能。另外，docker容器自身也提供了docker-proxy来实现容器应用的数据包转发，但是它的实现机制是为每个做端口映射的容器端口都提供一个docker-proxy进程来进行数据包的转发，当存在大量的端口映射时，就需要开启大量的docker-proxy进程，同样存在效率低、运维管理难度大的问题。技术实现要素：本申请实施例提供一种网络通信方法及系统，可以降低docker容器的端口管理复杂度，并提高数据传输效率。一方面，本申请实施例提供一种网络通信方法，包括：确定docker容器内的数据转发规则，所述docker容器的一对第一端口映射到所在主机的端口上；根据所述数据转发规则，将通过所述第一端口接收的数据包转发给所述docker容器内部署的应用，或者，将所述docker容器内部署的应用发送的数据包通过所述第一端口转发给外部设备。另一方面，本申请实施例提供一种网络通信系统，包括：部署在docker容器内的数据分发单元以及网络应用单元；所述docker容器的一对第一端口映射到所在主机的端口上；所述网络应用单元包括一个或多个应用；所述数据分发单元，适于确定所述docker容器内的数据转发规则；根据所述数据转发规则，将通过所述第一端口接收的数据包转发给所述网络应用单元内的应用，或者，将所述网络应用单元内的应用发送的数据包通过所述第一端口转发给外部设备。另一方面，本申请实施例提供一种网络设备，包括：处理器和存储器；所述存储器适于存储网络通信程序，所述网络通信程序被所述处理器执行时实现上述网络通信方法的步骤。另一方面，本申请实施例提供一种计算机可读介质，存储有网络通信程序，所述网络通信程序被处理器执行时实现上述网络通信方法的步骤。在本申请实施例中，docker容器的一对第一端口映射到所在主机的端口上；根据docker容器内的数据转发规则，将通过第一端口接收的数据包转发给docker容器内部署的应用，或者，将docker容器内部署的应用发送的数据包通过第一端口转发给外部设备。在本实施例中，docker容器只需在主机上暴露一对第一端口用于传输数据包，不仅降低了端口管理复杂度，而且提高了数据传输效率。本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。附图说明附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。图1为本申请实施例提供的网络通信系统的示意图；图2为本申请实施例提供的网络通信系统的实施流程示意图；图3为本申请实施例提供的网络通信方法的流程图；图4为本申请实施例提供的网络通信方法的一种示例流程图；图5为本申请实施例提供的网络通信方法的另一种示例流程图；图6为本申请实施例提供的网络通信方法的再一种示例流程图；图7为本申请实施例提供的网络通信方法的再一种示例流程图；图8为本申请实施例提供的网络设备的示意图。具体实施方式下面将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。需要说明的是，本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。图1为本申请实施例提供的网络通信系统的示意图。图2为本申请实施例提供的网络通信系统的实施流程示意图。如图1和图2所示，本实施例提供的网络通信系统，包括：部署在docker容器11内的数据分发单元112以及网络应用单元114。其中，docker容器11可以部署在一台网络设备(可以称为主机)上，每台网络设备上可以同时部署多个docker容器。docker容器11上可以部署一个或多个应用，比如，可以根据不同的业务场景实例化得到不同的网络应用。如图2所示，网络应用单元114内可以包括一个或多个应用，比如图2中的应用1、应用2及应用n，其中，应用1绑定端口a，应用2绑定端口b，应用n绑定端口n。在本实施例中，docker容器11的一对第一端口(在图2中采用端口b示意)映射到所在主机的端口上。其中，一对第一端口可以包括一个rtp(realtimetransportprotocol，实时传输协议)端口和一个rtcp(realtimetransportcontrolprotocol，实时传输控制协议)端口，用于传输数据。示例性地，docker容器11可以在启动时采用端口映射方式在所在主机上暴露一对第一端口，用于接收来自外部设备10的数据包，或者，向外部设备10发送数据包。需要说明的是，docker容器11在启动时会初始化docker容器地址与所在主机的网络协议(ip，internetprotocol)地址的对应关系，以及第一端口与所在主机上端口的映射关系。基于此，docker容器11可以实现与外部设备10的数据交互。在本实施例中，数据分发单元112适于确定docker容器11内的数据转发规则，以及根据数据转发规则，将通过第一端口(比如，图2中的端口b)接收的数据包转发给网络应用单元114内的应用，或者，将网络应用单元114内的应用发送的数据包通过第一端口转发给外部设备10。本实施例中，外部设备10可以包括除docker容器11外的其他对象，比如，其他网络设备或者其他docker容器。然而，本申请对此并不限定。本实施例中，docker容器11仅需对外暴露一对第一端口用于数据传输，无论外部设备10和网络应用单元114之间存在几路数据，都会通过第一端口进行传输，不会再动态增加暴露的端口，动态变化的只是docker容器11内的数据转发规则；其中，新增一路数据时，数据分发单元112可以增加一条数据转发规则；删除一路数据时，数据分发单元112可以删除一条对应的数据转发规则。在一示例性实施方式中，数据转发规则可以用于记录每路数据的数据源和数据目的地的信息，其中，数据源或数据目的地可以为网络应用单元114内的应用。在一示例性实施方式中，数据源的信息可以包括源地址以及源端口；数据目的地的信息可以包括：目的地址以及目的端口；其中，源端口或目的端口可以为网络应用单元114内的应用绑定的端口。然而，本申请对此并不限定。例如，在其他实现方式中，当数据源为网络应用单元内的应用，则数据源的信息可以包括：该应用所在的docker容器地址、该应用所绑定的端口以及该应用的标识(id)。比如，当一路数据的源地址和源端口为外部设备的ip地址和端口时，该路数据的目的地址可以为docker容器所在主机的ip地址，该路数据的目的端口可以为docker容器内部署的应用绑定的端口。比如，当一路数据的目的地址和目的端口为外部设备的ip地址和端口时，该路数据的源地址可以为docker容器所在主机的ip地址，该路数据的目的端口可以为docker容器内部署的应用绑定的端口。在一示例性实施方式中，数据分发单元112可以适于通过以下方式根据数据转发规则，将通过第一端口接收的数据包转发给docker容器11内部署的应用：通过查询数据转发规则，确定从第一端口接收到的数据包携带的源地址和源端口所对应的目的端口；将数据包转发给网络应用单元114内绑定该目的端口的应用。在本示例性实施方式中，如图2所示，数据分发单元112通过端口b接收到携带源地址和源端口的数据包；当数据转发规则中记录该源地址和源端口对应的目的地址和目的端口，则根据查询到的目的端口在docker容器11内进行数据包转发。比如，数据转发规则中记录有源地址和源端口对应的目的端口为端口a，则数据分发单元112将接收到的数据包转发到绑定端口a的应用1；当数据转发规则中没有记录该源地址和源端口，则直接丢弃接收到的数据包。在一示例性实施方式中，数据分发单元112可以通过以下方式根据数据转发规则，将docker容器11内部署的应用发送的数据包通过第一端口转发给外部设备10：通过查询数据转发规则，确定docker容器内发送数据包的应用所绑定的端口对应的外部设备的ip地址和端口；通过第一端口将数据包转发至该外部设备。在本示例性实施方式中，如图2所示，数据分发单元112接收到网络应用单元114内的应用1发送的数据包后，从数据转发规则查询是否有端口a对应的目的地址和目的端口，若可以查询到端口a对应外部设备10的ip地址和端口，则数据分发单元112将数据包通过端口b转发给外部设备10，若没有查询到端口a的对应记录，则直接丢弃接收到的数据包。在一示例性实施方式中，如图1和图2所示，本实施例提供的网络通信系统还可以包括：信令处理单元110，适于获取每路数据的通信链路信息，并发送通信链路信息给数据分发单元112；数据分发单元112可以适于根据每路数据的通信链路信息，确定docker容器11内的数据转发规则。在本示例性实施方式中，docker容器11的一个第二端口(比如，图2中的端口a)映射到所在主机的端口上，用于传输信令。其中，信令处理单元110可以适于通过以下任一方式获取每路数据的通信链路信息：方式一、通过第二端口与外部设备(比如，外部设备10)进行信令交互，确定待通过第一端口接收的任一路数据的源地址和源端口(比如，外部设备10的ip地址和端口)；从待接收该路数据的应用获取该应用绑定的docker容器地址和端口；根据该路数据的源地址、源端口、该应用所绑定的docker容器地址和端口，确定该路数据的通信链路信息；方式二、通过第二端口接收外部设备发送的请求消息，从该请求消息中解析出待通过第一端口发送的任一路数据的目的地址和目的端口(比如，外部设备10的ip地址和端口)、待发送该路数据的应用；从待发送该路数据的应用获取该应用绑定的docker容器地址和端口；根据该路数据的目的地址、目的端口、该应用绑定的docker容器地址和端口，确定该路数据的通信链路信息。在本示例性实施方式中，信令处理单元110负责与外部设备(比如，外部设备10)通过标准信令进行交互，完成数据的协商，这些标准信令通常可以包括sip(sessioninitiationprotocol，会话初始协议)、rtsp(realtimestreamingprotocol，实时流协议)、mgcp(mediagatewaycontrolprotocol，媒体网关控制协议)等协议。信令传输通道可以支持tcp(transmissioncontrolprotocol，传输控制协议)、udp(userdatagramprotocol，用户数据报协议)等多种模式。由于信令处理单元110需要和外部设备(比如，外部设备10)进行通信，因此，将一个用于传输信令的端口(即上述的第二端口，比如图2中的端口a)通过端口映射方式暴露到主机上。由于对整个docker容器来说，用于信令传输的端口通常只有一个，因此不会对主机基于iptables规则的数据包转发带来影响。在本示例性实施方式中，数据分发单元112负责与外部设备10通过标准的数据传输协议进行通信，接收并基于数据转发规则来转发数据包。数据分发单元112可以通过端口映射方式在主机上暴露用于数据包传输的一对端口(即上述的第一端口，比如图2中的端口b)。由于对整个docker容器来说，只需要对外暴露一对端口用于数据传输，因此，不会对主机基于iptables规则的数据包转发带来影响。其中，数据转发规则可以根据信令处理单元110发送的通信链路信息来创建或更新，当数据分发单元112接收到数据包时，可以根据数据包携带的源地址和源端口，通过查询数据转发规则来确定转发给docker容器内的哪个端口，或者哪个外部设备。在本示例性实施方式中，网络应用单元114负责与数据分发单元112交互，并可根据不同的业务场景实例化为不同的网络应用(比如，应用1、应用2、应用n)，网络应用单元114可以接收数据分发单元112转发过来的数据包，也可以向数据分发单元112发送数据包，网络应用单元114可以随着docker容器11启动而启动，亦可以由其他单元(比如，信令处理单元110)创建。网络应用单元114和数据分发单元112通常需要为每一路数据(比如，视频或音频数据)绑定一对端口(一对端口包括一个rtp端口和一个rtcp端口)，比如，图2中应用1绑定端口a，应用2绑定端口b，应用n绑定端口n，当需要收发多路数据时，则需要绑定多对端口。网络应用单元114和数据分发单元112之间可以通过docker容器内的socket进行通信。下面基于图2通过一个示例对本实施例提供的网络通信系统的实施流程进行举例说明。在本示例中，信令处理单元110可以从端口a发起数据会话建立请求，可以是sip、rtsp、mgcp等协议或者其它协议，在完成信令协商之后，记录对端数据的源地址和源端口(比如，外部设备10的ip地址和端口号)。在协商的信令中，本端数据的接收地址可以采用docker容器所在主机ip地址及docker容器在主机上暴露的端口b。然后，信令处理单元110通知网络应用单元114，网络应用单元114创建新的应用1，且应用1绑定端口a，应用1将自己绑定的docker容器地址和端口a告诉信令处理单元110，用于处理数据。信令处理单元110将需要转发的数据地址对(其中，包括对端数据的源地址和源端口、以及数据目的地应用1所绑定的docker容器地址和端口a)通知数据分发单元112。数据分发单元112根据接收到的信息创建数据分发映射表，其中，记录以下对应关系：源地址、源端口、docker容器所在主机ip地址以及应用1绑定的端口，作为一条数据转发规则。需要说明的是，由于docker容器在启动时初始化了docker容器地址和所在主机ip地址的对应关系，因此，基于docker容器地址和上述初始化的对应关系可以确定docker容器所在主机ip地址。然后，数据分发单元112开始接收数据包，并根据数据包携带的源地址和源端口，查询数据分发映射表中的数据转发规则，根据查询到的结果，将接收到的数据包转发到docker容器内的端口a；绑定端口a的应用1接收到数据分发单元112转发过来的数据包后，可以执行相应的业务，比如视频分析任务。本实施例提供的网络通信系统中将基于iptables转发和应用分发相结合，docker容器仅需对外暴露一对端口即可实现多路数据传输。针对小规模的政企应用场景，使用docker容器来部署微服务时，通过本实施例提供的网络通信系统可以降低docker容器端口的管理复杂度，提高数据包的传输效率，从而便于运维管理，也提升了可靠性。图3为本申请实施例提供的网络通信方法的流程图。本实施例提供的网络通信方法可以应用于部署在主机上的docker容器，且docker容器的一对第一端口映射到所在主机的端口上。关于docker容器以及第一端口的相关说明可以参照上述网络通信系统中的相关描述，故于此不再赘述。如图3所示，本实施例提供的网络通信方法，包括：步骤201、确定docker容器内的数据转发规则；步骤202、根据数据转发规则，将通过第一端口接收的数据包转发给docker容器内部署的应用，或者，将docker容器内部署的应用发送的数据包通过第一端口转发给外部设备。在一示例性实施方式中，数据转发规则可以用于记录每路数据的数据源和数据目的地的信息，其中，数据源或数据目的地为docker容器内部署的应用。在一示例性实施方式中，数据源的信息可以包括：源地址以及源端口；数据目的地的信息可以包括：目的地址以及目的端口，其中，源端口或目的端口为docker容器内部署的应用绑定的端口。然而，本申请对此并不限定。例如，在其他实现方式中，当数据源为网络应用单元内的应用，则数据源的信息可以包括：该应用所在的docker容器地址、该应用所绑定的端口以及该应用的标识(id)。在一示例性实施方式中，在步骤202中，根据数据转发规则，将通过第一端口接收的数据包转发给docker容器内部署的应用，可以包括：通过查询数据转发规则，确定从第一端口接收到的数据包携带的源地址和源端口所对应的目的端口；将数据包转发给docker容器内绑定该目的端口的应用。示例性地，通过第一端口接收到携带源地址和源端口的数据包后，当数据转发规则中记录该源地址和源端口对应的目的地址和目的端口，则根据查询到的目的端口在docker容器内进行数据包转发；比如，在图2中，数据转发规则中记录有源地址和源端口(例如，外部设备10的ip地址和端口)对应的目的端口为端口a，则可以将接收到的数据包转发到绑定端口a的应用1；当数据转发规则中没有记录该源地址和源端口，则直接丢弃接收到的数据包。在一示例性实施方式中，在步骤202中，根据数据转发规则，将docker容器内部署的应用发送的数据包通过第一端口转发给外部设备，可以包括：通过查询数据转发规则，确定docker容器内发送数据包的应用所绑定的端口对应的外部设备的ip地址和端口；通过第一端口将数据包转发至该外部设备。在本示例性实施例中，数据转发规则中记录的一路数据的源端口可以为docker容器内部署的应用绑定的端口，该路数据的目的地址和目的端口可以为外部设备的ip地址和端口。示例性地，在接收到docker容器内部署的一个应用发送的数据包后，从数据转发规则查询是否有该应用所绑定的端口对应的目的地址和目的端口，若可以查询到对应的目的地址和目的端口，比如为外部设备的ip地址和端口，则将数据包通过第一端口转发给该外部设备，若没有查询到对应记录，则直接丢弃接收到的数据包。在一示例性实施方式中，在步骤201之前，网络通信方法还可以包括：获取每路数据的通信链路信息；此时，步骤201可以包括：根据每路数据的通信链路信息，确定docker容器内的数据转发规则。在一示例性实施方式中，docker容器的一个第二端口映射到所在主机的端口上；其中，获取每路数据的通信链路信息，可以包括以下之一：方式一、通过第二端口与外部设备进行信令交互，确定待通过第一端口接收的任一路数据的源地址和源端口；从待接收该路数据的应用获取该应用绑定的docker容器地址和端口；根据该路数据的源地址、源端口、该应用所绑定的docker容器地址和端口，确定该路数据的通信链路信息；方式二、通过第二端口接收外部设备发送的请求消息，从该请求消息中解析出待通过第一端口发送的任一路数据的目的地址和目的端口、待发送该路数据的应用；待发送该路数据的应用获取该应用绑定的docker容器地址和端口；根据该路数据的目的地址、目的端口、该应用绑定的docker容器地址和端口，确定该路数据的通信链路信息。其中，关于第二端口的说明可以参照上述网络通信系统中的相关描述，故于此不再赘述。本示例性实施例中，docker容器在初始化时通过端口映射方式对外暴露第一端口和第二端口，用于传输数据和信令。由于对整个docker容器来说，用于信令传输的端口通常只有一个，因此不会对主机基于iptables规则的数据包转发带来影响。由于对整个docker容器来说，只需要对外暴露一对端口(第一端口)用于数据传输，因此，不会对主机基于iptables规则的数据包转发带来影响。本实施例中，docker容器仅需对外暴露一对第一端口用于数据传输，无论docker容器内部署的应用与外部设备之间存在几路数据，都会通过第一端口进行传输，不会再动态增加暴露的端口，动态变化的只是docker容器内的数据转发规则；其中，新增一路数据时，可以在数据转发规则中增加一条记录；删除一路数据时，可以在数据转发规则中删除一条记录。本实施例提供的网络通信方法将基于iptables转发和应用分发相结合，docker容器仅需对外暴露一对端口即可实现多路数据传输。针对小规模的政企应用场景，使用docker容器来部署微服务时，通过本实施例提供的网络通信方法可以降低docker容器端口的管理复杂度，提高数据包的传输效率，从而便于运维管理，也提升了可靠性。下面结合图1和图2通过多个示例性实施例对本申请实施例提供的网络通信方法及系统进行说明。图4为本申请实施例提供的网络通信方法的一种示例流程图。本示例可以适用于以下场景：网络通信系统通过sip(sessioninitiationprotocol，会话初始协议)协议向gb28181服务器(即流媒体服务器)拉取数据流，用于视频分析任务；本示例中，网络应用单元可以包括数据分析单元。如图4所示，本示例中网络通信方法可以包括步骤s101至步骤s114。步骤s101、信令处理单元接收到视频分析任务请求；示例性地，视频分析任务请求可以通过网络通信系统所对应的网页上的点击操作触发。然而，本申请对此并不限定。步骤s102、信令处理单元接收到视频分析任务请求后，创建数据分析单元。步骤s103、数据分析单元将自己绑定的docker容器地址以及udp端口信息(比如，端口号)发送给信令处理单元，信令处理单元记录数据分析单元绑定的docker容器地址以及udp端口信息(比如，端口号)。步骤s104、信令处理单元解析视频分析任务请求，拼装出标准的sip点播请求消息；其中，sip点播请求消息包含sdp(sessiondescriptionprotocol，会话描述协议)消息，sdp消息中包括目的地址和目的端口号，本示例中，目的地址为docker容器所在主机的ip地址，目的端口号为docker容器映射到主机的第一端口的端口号(比如，图2中端口b的端口号)。步骤s105、信令处理单元向流媒体服务器发送sip点播请求消息。步骤s106、流媒体服务器在准备就绪后，向信令处理单元发送200ok消息，其中同样包含sdp消息，sdp消息中包括所请求视频数据的源地址和源端口号；本示例中，源地址和源端口号为摄像头的ip地址和端口号。步骤s107、信令处理单元将数据分析单元所绑定的docker容器地址和端口号与对应摄像头的ip地址和端口号拼装成通信链路消息，并下发给数据分发单元。步骤s108、数据分发单元接收通信链路消息，并根据通信链路消息更新数据分发映射表，即在数据分发映射表中新增一条数据转发规则，比如，可以记录数据分析单元所在主机的ip地址和在docker容器内绑定的端口号与对应摄像头的ip地址和端口号的对应关系。其中，数据分析单元所在主机的ip地址可以根据数据分析单元所绑定的docker容器地址、以及docker容器初始化时建立的docker容器地址与所在主机的ip地址之间的对应关系确定。步骤s109、数据分发单元在更新数据分发映射表后，向信令处理单元发送确认(ack)消息。步骤s110、信令处理单元向流媒体服务器发送ack消息。步骤s111、流媒体服务器接收到ack消息后，将对应摄像头的数据发送到数据分发单元；其中，流媒体服务器可以按照sip点播请求消息中携带的目的地址和目的端口号(即docker容器所在主机的ip地址和docker容器映射到主机的第一端口的端口号)，发送摄像头的数据。步骤s112、数据分发单元通过第一端口接收到数据包后，查找数据分发映射表，若能在数据分发映射表查到数据包携带的源地址和源端口号对应的目的端口号，则执行步骤s113，即将接收到的数据包转发到该目的端口号对应的数据分析单元；若查不到记录，则将数据包直接丢弃掉。步骤s114、数据分析单元接收到数据包后，执行视频数据分析任务。图5为本申请实施例提供的网络通信方法的一种示例流程图。本示例可以适用于以下场景：网络通信系统作为数据流服务器，支持gb28181协议，响应外部设备的请求，向外部设备发送数据流；本示例中，网络应用单元可以包括数据流设备。如图5所示，本示例中网络通信方法可以包括步骤s201至步骤s216。步骤s201、信令处理单元接收外部设备发送的数据流设备查询请求消息。步骤s202、信令处理单元向管理的所有数据流设备发送设备状态查询请求消息。步骤s203、处于工作状态的数据流设备(即正常的数据流设备)向信令处理单元返回设备状态查询响应消息；其中，任一正常的数据流设备返回的设备状态响应消息中可以包括：该数据流设备的标识(id)、该数据流设备所绑定的docker容器地址以及端口号。步骤s204、信令处理单元根据接收到的设备状态查询响应消息，更新数据流设备状态列表，并将处于工作状态的数据流设备列表拼装成数据流设备查询响应消息；其中，处于工作状态的数据流设备状态列表中可以记录处于工作状态的全部数据流设备的id。步骤s205、信令处理单元将数据流设备查询响应消息发送给外部设备。步骤s206、信令处理单元接收外部设备发送的sip点播请求消息。步骤s207、信令处理单元从sip点播请求消息中解析出外部设备的ip地址和端口号，以及需要点播的数据流设备id；在数据流设备状态列表中查询需要点播的数据流设备id，若该id对应的数据流设备处于工作状态，则信令处理单元将外部设备的ip地址和端口号以及该id对应的数据流设备所绑定的docker容器地址和端口号拼装成通信链路消息，并执行步骤s208；否则(即该id对应的数据流设备处于非工作状态(即存在异常))，则信令处理单元向外部设备反馈异常通知。步骤s208、信令处理单元将通信链路消息发送给数据分发单元。步骤s209、数据分发单元解析通信链路消息，并根据通信链路消息更新数据分发映射表；即在数据分发映射表中新增一条数据转发规则，比如，可以记录外部设备的ip地址和端口号以及需要点播的数据流设备id所绑定的主机ip地址和在docker容器内绑定的端口号的对应关系。其中，数据流设备所在主机的ip地址可以根据数据流设备所绑定的docker容器地址、以及docker容器初始化时建立的docker容器地址与所在主机的ip地址之间的对应关系确定。步骤s210、数据分发单元在更新数据分发映射表后，向信令处理单元返回ack消息。步骤s211、信令处理单元接收到ack消息后，向外部设备发送200ok消息，其中可以包含sdp消息，sdp消息中可以包括需要点播的数据流设备的id。步骤s212、外部设备向信令处理单元发送ack消息。步骤s213、信令处理单元接收到ack消息后，向需要点播的id所对应的数据流设备发送点播请求消息。步骤s214、需要点播的id所对应的数据流设备接收到点播请求消息后，向数据分发单元发送数据。步骤s215、数据分发单元接收到数据包后，查找数据分发映射表，若能查到数据包携带的源地址和源端口号对应的目的地址和目的端口号，则执行步骤s216，即将数据包转发到对应的外部设备；若查不到记录，则将数据包直接丢弃掉。图6为本申请实施例提供的网络通信方法的一示例流程图。本示例可以适用于以下场景：网络通信系统通过gat1400协议获取数据流用于视频分析任务；本示例中，网络应用单元可以包括数据分析单元。如图6所示，本示例中网络通信方法可以包括步骤s301至步骤314。步骤s301、信令处理单元接收到视频分析任务请求；示例性地，视频分析任务请求可以通过网络通信系统所对应的网页上的点击操作触发。然而，本申请对此并不限定。步骤s302、信令处理单元接收到视频分析任务请求后，创建数据分析单元。步骤s303、数据分析单元将自己绑定的docker容器地址以及udp端口信息(比如，端口号)发送给信令处理单元，信令处理单元记录数据分析单元绑定的docker容器地址以及udp端口信息(比如，端口号)。步骤s304、信令处理单元解析视频分析任务请求，拼装出订阅消息；其中，订阅消息中可以包括目的地址和目的端口号，本示例中，目的地址为docker容器所在主机的ip地址，目的端口号为docker容器映射到主机的第一端口的端口号(比如，图2中端口b的端口号)。步骤s305、信令处理单元向被订阅者发送订阅消息，比如，httppost/viid/subscribes。步骤s306、被订阅的视图库将订阅成功与否的响应消息返回给信令处理单元，其中，响应消息中携带所订阅视频数据的源地址和源端口号，本示例中所订阅视频数据的源地址和源端口号为订阅的视图库的ip地址和端口号。步骤s307、若订阅成功，信令处理单元将数据分析单元所绑定的docker容器地址和端口号以及对应视图库的ip地址和端口号拼装成通信链路消息，并下发给数据分发单元。步骤s308、数据分发单元接收通信链路消息，并根据通信链路消息更新数据分发映射表；即在数据分发映射表中新增一条数据转发规则，比如，可以记录数据分析单元所在主机的ip地址以及在docker容器内绑定的端口号与订阅视图库的ip地址和端口号的对应关系。其中，数据分析单元所在主机的ip地址可以根据数据分析单元所绑定的docker容器地址、以及docker容器初始化时建立的docker容器地址与所在主机的ip地址之间的对应关系确定。步骤s309、数据分发单元在更新数据分发映射表后，向信令处理单元发送确认(ack)消息。步骤s310、信令处理单元向视图库发送ack消息。步骤s311、视图库接收到ack消息后，将订阅的数据发送到数据分发单元；其中，视图库可以按照订阅消息中携带的目的地址和目的端口号(即docker容器所在主机的ip地址和docker容器映射到主机的第一端口的端口号)，发送数据包。步骤s312、数据分发单元接收到数据包后，查找数据分发映射表，若能在数据分发映射表查到数据包携带的源地址和源端口号对应的目的端口号，则执行步骤s313，即将数据包转发到该目的端口号对应的数据分析单元；若查不到记录，则将数据包直接丢弃掉。步骤s314、数据分析单元接收到数据包后，执行视频数据分析任务。图7为本申请实施例提供的网络通信方法的再一示例流程图。本示例可以适用于以下场景：网络通信系统作为数据流服务器，支持gat1400协议，响应外部设备的请求，向外部设备发送数据流；本示例中，网络应用单元可以包括数据流设备。如图7所示，本示例中网络通信方法可以包括步骤s401至步骤s416。步骤s401、信令处理单元接收外部设备发送的数据流设备查询请求消息。步骤s402、信令处理单元向管理的所有数据流设备发送设备状态查询请求消息。步骤s403、处于工作状态的数据流设备(即正常的数据流设备)向信令处理单元返回设备状态查询响应消息；其中，任一正常的数据流设备返回的设备状态响应消息中可以包括：该数据流设备的标识(id)、该数据流设备所绑定的docker容器地址以及端口号。步骤s404、信令处理单元根据接收到的设备状态查询响应消息，更新数据流设备状态列表，并将处于工作状态的数据流设备列表拼装成数据流设备查询响应消息；其中，处于工作状态的数据流设备状态列表中可以记录处于工作状态的全部数据流设备的id。步骤s405、信令处理单元将数据流设备查询响应消息发送给外部设备。步骤s406、信令处理单元接收到外部设备的订阅消息，比如，httppost/viid/subscribes消息。步骤s407、信令处理单元从订阅消息中解析出外部设备的ip地址和端口号，以及需要播放的数据流设备id；信令处理单元在数据流设备状态列表中查询需要点播的数据流设备id，若该id对应的数据流设备处于工作状态，则信令处理单元将外部设备的ip地址和端口号以及该id对应的数据流设备所绑定的docker容器地址和端口号拼装成通信链路消息，并执行步骤s408；否则(即该id对应的数据流设备处于非工作状态(即存在异常))，则信令处理单元向外部设备反馈异常通知。步骤s408、信令处理单元将通信链路消息发送给数据分发单元。步骤s409、数据分发单元解析通信链路消息，并根据通信链路消息更新数据分发映射表；即在数据分发映射表中新增一条数据转发规则，比如，可以记录外部设备的ip地址和端口号以及需要点播的数据流设备id所绑定的主机ip地址和在docker容器内绑定的端口号的对应关系。其中，数据流设备所在主机的ip地址可以根据数据流设备所绑定的docker容器地址、以及docker容器初始化时建立的docker容器地址与所在主机的ip地址之间的对应关系确定。步骤s410、数据分发单元在更新数据分发映射表后，向信令处理单元返回ack消息。步骤s411、信令处理单元接收到ack消息后，向外部设备发送订阅响应消息，其中可以包含需要点播的数据流设备的id。步骤s412、外部设备向信令处理单元发送ack消息。步骤s413、信令处理单元接收到ack消息后，向需要点播的id所对应的数据流设备发送点播请求消息。步骤s414、需要点播的id所对应的数据流设备接收到点播请求消息后，向数据分发单元发送数据。步骤s415、数据分发单元接收到数据包后，查找数据分发映射表，若能查到数据包携带的源地址和源端口号对应的目的地址和目的端口号，则执行步骤s416，即将数据包转发到对应的外部设备；若查不到记录，将数据包直接丢弃掉。综上可知，本实施例提供的网络通信方法及系统针对docker容器应用部署的场景，将iptables转发和应用转发结合，docker容器只需在主机上暴露一对第一端口，用于数据传输，即可实现docker容器内多个端口的数据转发，不仅降低了docker容器端口的管理复杂度，而且提高了数据传输效率，方便了运维管理，也提高了docker容器的可靠性。图8为本申请实施例提供的网络设备的示意图。如图8所示，本申请实施例提供一种网络设备800(比如，部署docker容器的主机设备)，包括：存储器801和处理器802，存储器801适于存储网络通信程序，该网络通信程序被处理器802执行时实现上述实施例提供的网络通信方法的步骤，比如图3所示的步骤。本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的示意图，并不构成对本申请方案所应用于其上的网络设备800的限定，网络设备800可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。其中，处理器802可以包括但不限于微处理器(mcu，microcontrollerunit)或可编程逻辑器件(fpga，fieldprogrammablegatearray)等的处理装置。存储器801可用于存储应用软件的软件程序以及模块，如本实施例中的网络通信方法对应的程序指令或模块，处理器802通过运行存储在存储器801内的软件程序以及模块，从而执行各种功能应用以及数据处理，比如实现本实施例提供的网络通信方法。存储器801可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些示例中，存储器801可包括相对于处理器802远程设置的存储器，这些远程存储器可以通过网络连接至网络设备800。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。此外，本申请实施例还提供一种计算机可读介质，存储有网络通信程序，该网络通信程序被处理器执行时实现上述实施例提供的网络通信方法的步骤，比如，图3所示的步骤。本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。以上显示和描述了本申请的基本原理和主要特征和本申请的优点。本申请不受上述实施例的限制，上述实施例和说明书中描述的只是说明本申请的原理，在不脱离本申请精神和范围的前提下，本申请还会有各种变化和改进，这些变化和改进都落入要求保护的本申请范围内。当前第1页12当前第1页12