一种用于数据传输的方法和系统与流程

本申请涉及网络通信技术领域，特别是涉及一种用于数据传输的方法和系统。

背景技术：

当今的许多设备和基于计算机的服务依赖于通信系统来在彼此之间传送必要的消息。所述通信系统又由多个独立的通信网络构成，其中包括有线和无线网络，所有这些网络需要彼此协作，以便形成一个大的、互连的、无所不在的通信系统。例如，因特网以及大多数商用网络是根据tcp/ip体系结构模型配置的，tcp(transmissioncontrolprotocol，传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。众所周知，发送端和接收端在基于tcp协议进行通信时，必须依赖于物理硬件网卡在链路层中工作，在网络中连接计算机和传输介质。

但是在实际的项目中，出于数据安全性等因素的考虑，会将计算机进行网络隔离，因此这类计算机缺失网卡，或者这类计算机即使有网卡，但是这类计算机之间不可以通过网卡进行通信连接，但是在这类计算机之间通常又需要进行通信以实现数据交换。

技术实现要素：

本申请提供一种用于数据传输的方法和系统，以解决处于网络隔离状态的计算机之间的通信的问题。

本公开实施例的第一方面，提供一种用于数据传输的方法，应用于服务端向多个客户端传输数据的系统，其中，多个所述客户端与所述服务端之间均通过传输介质建立物理连接，包括：

所述服务端设定第一套接字，并且所述第一套接字处于监听状态；

多个所述客户端均一一对应设定各自的第二套接字；

目标客户端通过其自身对应的所述第二套接字向设定了所述第一套接字的服务端发送通信连接请求，其中，所述目标客户端是多个所述客户端中欲请求所述服务端传输数据的一个或若干个；

当所述服务端的所述第一套接字监听到所述通信连接请求，则所述服务端响应所述通信连接请求，所述第一套接字和所述目标客户端对应的第二套接字建立连接，从而使得所述目标客户端与所述服务端通过所述传输介质建立通信连接；

所述目标客户端通过所述通信连接向所述服务端发送数据传输请求；

所述服务端响应于所述数据传输请求查找待传输的目标数据，并将查找到的所述目标数据通过所述通信连接向所述目标客户端发送；

所述目标客户端通过所述通信连接接收所述目标数据。

可选地，在所述第一套接字和所述目标客户端的第二套接字建立通信连接之后，还包括：

所述目标客户端周期性地向所述服务端发送心跳消息；

所述服务端接收所述心跳消息，并根据所述心跳消息判断所述通信连接是否正常；

当所述服务端总能周期性的接收到所述心跳消息，则判定所述通信连接正常；

以及，

当在某次心跳周期结束时，所述服务端未能接收到下一次所述心跳消息，则判定所述通信连接异常，所述服务端销毁所述通信连接。

可选地，当所述服务端为接收端时、所述目标客户端是发送端，当所述服务端是发送端时、所述目标客户端是接收端；

所述方法还包括：

在所述发送端通过所述通信连接向所述接收端发送数据包时，计算并生成所述数据包的第一消息摘要，并将所述第一消息摘要添加至所述数据包的结尾；

在所述接收端通过所述通信连接接收所述数据包时，截取所述第一消息摘要，重新计算并生成接收到的数据的第二消息摘要，校验所述第一消息摘要和所述第二消息摘要是否一致；若检验结果一致，表示所述接收到的数据是完整的所述数据包，则保留所述接收到的数据；以及若检验结果不一致，表示所述接收到的数据不是完整的所述数据包，则丢弃所述接收到的数据。

可选地，当所述服务端为接收端时、所述目标客户端是发送端，当所述服务端是发送端时、所述目标客户端是接收端；

所述方法还包括：

在所述发送端通过所述通信连接向所述接收端发送一个数据包后，在等待时长内，接收确认消息，其中，所述确认消息是所述接收端接收到该数据包后回复给所述发送端的消息；

若在所述等待时长内，所述发送端接收到所述确认消息，则发送下一个数据包；

若在所述等待时长内，所述发送端未能收到所述确认消息，则重新发送该数据包。

可选地，所述方法还包括：

所述发送端按照连续性的时段统计各时段内发生重新发送数据包现象的次数，若在某一所述时段内统计的所述次数大于预设的次数阈值，则执行流量控制操作；

其中，所述流量控制操作包括：

按照逐渐递减的规则，每重新发送一个数据包时，重新发送数据包的数据量减少一定量，直至后续的所述时段内统计的所述次数小于或等于所述次数阈值时，停止减少重新发送数据包的数据量，并按照当前发送数据包的数据量的大小进行数据传输；

和/或，

按照逐渐递增的规则，每重新发送一个数据包，所述等待时长增加一定时长，所述等待时长增加至预设的最大值时停止增加，直至后续的所述时段内统计的所述次数小于或等于所述次数阈值时，将所述等待时长恢复至预设的默认值。

可选地，当所述服务端为接收端时、所述目标客户端是发送端，当所述服务端是发送端时、所述目标客户端是接收端；

所述方法还包括：

在所述发送端向所述接收端发送多个数据包时，为每个所述数据包添加序号；

在所述接收端接收多个所述数据包时，根据所述序号整理多个所述数据包。

可选地，所述方法还包括：

所述客户端向所述服务端发送关闭连接通知，所述服务端响应于所述关闭连接通知断开所述通信连接；或

所述服务端在将所有所述目标数据的数据包全部发送完成后断开所述通信连接。

可选地，在所述服务端设定第一套接字之前，还包括：

定义所述传输介质的接口实例；

并将所述接口实例分别注册至所述服务端和所述客户端的操作系统中，以使所述服务端和所述客户端之间通过所述接口实例耦合。

相应的，本公开实施例的第二方面，还提供了一种用于数据传输的系统，包括：

服务端、多个客户端和传输介质；

所述服务端和多个所述客户端均通过所述传输介质建立物理连接；

所述服务端设定第一套接字，并且所述第一套接字处于监听状态；

多个所述客户端均一一对应设定各自的第二套接字；

目标客户端通过其自身对应的所述第二套接字向设定了所述第一套接字的服务端发送通信连接请求，其中，所述目标客户端是多个所述客户端中欲请求所述服务端传输数据的一个或若干个；

当所述服务端的所述第一套接字监听到所述通信连接请求，则所述服务端响应所述通信连接请求，所述第一套接字和所述目标客户端对应的第二套接字建立连接，从而使得所述目标客户端与所述服务端通过所述传输介质建立通信连接；

所述目标客户端通过所述通信连接向所述服务端发送数据传输请求；

所述服务端响应于所述数据传输请求查找待传输的目标数据，并将查找到的所述目标数据通过所述通信连接向所述目标客户端发送；

所述目标客户端通过所述通信连接接收所述目标数据。

与现有技术相比，本申请至少能够达到如下技术效果：

在实际的项目中，出于数据安全性等因素的考虑，会将计算机进行网络隔离，当两台处于网络隔离状态的计算机之间需要进行通信交互时，选取传输数据的计算机作为服务端，选取接收数据的计算机作为目标客户端。为服务端设定第一套接字，并监听第一套接字，为客户端设定第二套接字，目标客户端通过其自身对应的第二套接字向服务端的第一套接字发送通信连接请求，当第一套接字监听到该通信连接请求，则服务端响应该通信连接请求，第一套接字和目标客户端对应的第二套接字建立连接，从而使得所述目标客户端与所述服务端通过所述传输介质建立通信连接，目标客户端便可以请求服务端开始数据传输目标数据，服务端响应该数据传输请求查找到相应的数据，并向客户端发送，客户端接收目标数据。依此，通过本申请公开的用于数据传输的方法，使得这两台计算机搭建成c/s架构(即client/server架构，即客户端/服务器架构)，从而使得两台处于网络隔离状态的计算机之间实现连接通信进行数据传输。

本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

图1是本申请一实施例提供的一种用于数据传输的系统的示意图；

图2是本申请一实施例提供的一种用于数据传输的方法的流程图；

图3是本申请一实施例提供的一种用于数据传输的方法的通信协议的编码模型示意图；

图4是本申请一实施例提供的一种用于数据传输的方法的通信协议的三层网络模型；

图5是本申请一实施例提供的一种用于数据传输的方法的通信协议的三层网络模型中的数据流向示意图；

图6是本申请一实施例提供的一种用于数据传输的方法的流量控制机制的示例性模型；

图7是本申请一实施例提供的一种用于数据传输的方法的目标客户端与服务端建立通信连接的单次握手过程示意图；

图8是本申请一实施例提供的一种用于数据传输的方法的目标客户端发起与服务端断开通信连接的单次握手过程示意图，以及服务端发起与目标客户端断开通信连接的单次握手过程示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本公开提供一种用于数据传输的方法，应用于服务端向多个客户端传输数据的系统，请参阅图1，所述系统可以是有多个计算机(处于网络隔离状态，后文中的计算机均是处于网络隔离状态的计算机)两两之间通过传输介质建立物理连接，其中，传输介质例如是usb摆渡线缆、串口线等其他数据传输线缆，本申请不做具体限制。在所述系统中，当其中某一台或几台计算机需要向另外的某一台计算机请求数据传输，那么作为数据发送方的计算机就是服务端，作为数据接收方的计算机就是客户端。在图1中，示例性的示意了多个计算机通过传输介质建立物理连接，仅以处于图中中心的计算机为服务端101，剩余的计算机为客户端102，但这不是具体限制，也可以是其他计算机作为服务端，相应的，剩余的其他计算机作为客户端。多个所述客户端102与所述服务端101之间均通过传输介质建立物理连接。

请结合参阅图1和图2，所述方法包括：

s101，所述服务端设定第一套接字，并且所述第一套接字处于监听状态；

s102，多个所述客户端均一一对应设定各自的第二套接字；

s103，目标客户端通过其自身对应的所述第二套接字向设定了所述第一套接字的服务端发送通信连接请求，其中，所述目标客户端是多个所述客户端中欲请求所述服务端传输数据的一个或若干个；

s104，当所述服务端的所述第一套接字监听到所述通信连接请求，则所述服务端响应所述通信连接请求，所述第一套接字和所述目标客户端对应的第二套接字建立连接，从而使得所述目标客户端与所述服务端通过所述传输介质建立通信连接；

s105，所述目标客户端通过所述通信连接向所述服务端发送数据传输请求；

s106，所述服务端响应于所述数据传输请求查找待传输的目标数据，并将查找到的所述目标数据通过所述通信连接向所述目标客户端发送；

s107，所述目标客户端通过所述通信连接接收所述目标数据。

下面示例性的示出这种数据传输方法的通信协议的代码，并说明：

1、服务端建立代码：

2、客户端代码：

以上编码示意了基于本申请的方法的通信协议，应用于服务端向多个客户端传输数据的系统，其编码模型如图3所示。在实际的项目中，出于数据安全性等因素的考虑，会将计算机进行网络隔离，当两台处于网络隔离状态的计算机之间需要进行通信交互时，选取传输数据的计算机作为服务端，选取接收数据的计算机作为目标客户端。

当客户端与服务端进行通信时，首先初始化服务端，为服务端设定第一套接字，即通信名称“test”，并且所述第一套接字开始处于监听状态，实时监控网络状态，且此时服务端的第一套接字在监听时，服务端从输入流中读取客户端发送过来的数据是阻塞式操作，直至所述第一套接字监听到通信连接请求。同时为多个客户端均一一对应设定各自的第二套接字。为了便于描述，此处仅以一个客户端向服务端发起访问为例进行说明，但不是对本申请的限制，对于多个客户端发起访问的过程相似，本领域技术人员很容易类推获知，因此不再赘述。

在所有计算机中现有某台计算机(即目标客户端)需要从服务端获取数据，则目标客户端对应的第二套接字提出连接请求，要连接的目标是服务端的第一套接字。为此目标客户端的第二套接字首先描述它需要连接的服务器的第一套接字，并向所述第一套接字提出连接请求，当服务端的第一套接字监听到(或者接收到)目标客户端对应的第二套接字的连接请求，所述第一套接字响应于所述连接请求，建立一个新的线程，把服务端的第一套接字的描述发给目标客户端，一旦目标客户端确认了此描述，连接就建立好了，目标客户端和服务端通过传输介质也就建立了通信连接。而服务端的第一套接字继续处于监听状态，继续接收其他客户端的第二套接字的连接请求。目标服务端可以开始请求服务端传输数据，服务端响应该请求查找到目标数据并向目标客户端发送，目标客户端接收目标数据，由此实现了两台处于网络隔离状态计算机之间的通信。

依此，通过本申请公开的用于数据传输的方法，使得这两台计算机搭建成c/s架构(即client/server架构，即客户端/服务器架构)，从而使得两台处于网络隔离状态的计算机之间实现连接通信进行数据传输。

当所述服务端为接收端时、所述目标客户端是发送端，当所述服务端是发送端时、所述目标客户端是接收端。如图4所示，基于所述通信协议要实现上述数据传输的方法，需要三个层次：基础传输层、安全传输层和应用层。其中，基础传输层的主要功能是建立服务端和目标客户端的连接，保证主机端与端之间能进行通信连接进行数据传输；安全传输层的主要功能是对数据传输的流量、数据传输的顺序等进行控制，保证数据传输时能及时、准确并有效地从发送端传输到接收端；应用层是实际上需要通信的实体双方，即需要通信的服务器端和客户端。其中在发送端和接收端数据的具体流向请参见图5。

在一示例性的实施例中，在步骤s101，所述服务端设定第一套接字之前，还包括：

定义所述传输介质的接口实例；

并将所述接口实例分别注册至所述服务端和所述客户端的操作系统中，以使所述服务端和所述客户端之间通过所述接口实例耦合。

请结合参照图3和图4，在所述服务端设定第一套接字和所述目标客户端设定第二套接字之前，需要初始化传输介质。首先，定义传输介质的接口实例，以usb摆渡线缆为例，代码如下：

iengineengine＝newusbengine()；//初始化了一个使用usb摆渡线的传输介质接口

表示将传输介质的接口实例定义为使用usb摆渡线的引擎接口实例；

然后将定义接口实例，即该usb摆渡线的引擎接口实例注册到基础传输层，代码如下：

basetransfer.addengine(engine)；//注册传输介质引擎实例

注册完毕后，就表示通信双方的数据便可以通过这个引擎进行相互传输。这个注册过程需要在实际建立通信连接之前进行，而且只需要注册一次。

并且在定义传输介质的接口实例时，会定义如下函数：

eventaction<string,byte[]>onreceive；//消息到达事件

stringgetuniquekey()；//返回引擎唯一标记

voidwrite(byte[]data)；//写入数据

以上函数是所述通信协议要实现上述数据传输的方法时使用的最底层的收发接口函数。

在一示例性的实施例中，在步骤s104，所述第一套接字和所述目标客户端的第二套接字建立通信连接之后，还包括：

所述目标客户端周期性地向所述服务端发送心跳消息；

所述服务端接收所述心跳消息，并根据所述心跳消息判断所述通信连接是否正常；

当所述服务端总能周期性的接收到所述心跳消息，则判定所述通信连接正常；

以及，

当在某次心跳周期结束时，所述服务端未能接收到下一次所述心跳消息，则判定所述通信连接异常，所述服务端销毁所述通信连接。

请参照图4，基础传输层增加了心跳机制，用来判断物理连接是否正常；在目标客户端和服务端建立起通信连接后，目标客户端周期性地向服务端开始发送心跳消息(heartbeatmessage)，直至目标客户端主动断开所述通信连接。服务端开始接收心跳消息，当服务端在某个消息接收周期内(即某个心跳周期结束时)未收到消息，服务端认为目标客户端已经关闭或者通信连接出现故障、或者当前不可用，服务端销毁该与目标客户端的通信连接，以释放资源，减少通信连接线路冗余。

在一示例性实施例中，当所述服务端为接收端时、所述目标客户端是发送端，当所述服务端是发送端时、所述目标客户端是接收端；

所述方法还包括：

在所述发送端通过所述通信连接向所述接收端发送数据包时，计算并生成所述数据包的第一消息摘要，并将所述第一消息摘要添加至所述数据包的结尾；

在所述接收端通过所述通信连接接收所述数据包时，截取所述第一消息摘要，重新计算并生成接收到的数据的第二消息摘要，校验所述第一消息摘要和所述第二消息摘要是否一致；若检验结果一致，表示所述接收到的数据是完整的所述数据包，则保留所述接收到的数据；以及若检验结果不一致，表示所述接收到的数据不是完整的所述数据包，则丢弃所述接收到的数据。

请参照图4，在基础传输层还设定了数据一致性校验机制，在发送端向接收端传输数据时，首先发送端会计算并生成待发送数据的md5值，并将该md5值添加到待发送数据的结尾，其中，md5中的md代表messagedigest，就是消息摘要的意思，不过这个消息摘要不是消息内容的缩写，而是根据公开的md5算法对原消息进行数学变换后得到的一个128位(bit)的特征码。在接收端接收到数据后，截取结尾的md5值，并重新计算生成接收到的数据的新的md5值，将员md5值和新的md5值进行比对，若前后一致，则说明接收的数据是完整的；若前后不一致，则说明接收的数据不完整，将接收到的数据丢弃。

在一示例性实施例中，当所述服务端为接收端时、所述目标客户端是发送端，当所述服务端是发送端时、所述目标客户端是接收端；

所述方法还包括：

在所述发送端通过所述通信连接向所述接收端发送一个数据包后，在等待时长内，接收确认消息，其中，所述确认消息是所述接收端接收到该数据包后回复给所述发送端的消息；

若在所述等待时长内，所述发送端接收到所述确认消息，则发送下一个数据包；

若在所述等待时长内，所述发送端未能收到所述确认消息，则重新发送该数据包。

请参照图4，在安全传输层设定了超时重传机制，以保证每个数据包都能从发送端发送至接收端，并存储于接收端的接收缓冲区中。当发送端发送数据包给接收端后，进入等待状态，并开始接收确认消息，若在所述等待时长内接收到确认消息，则继续发送下一个数据包；若在所述等待时长内未接收到确认消息，则发送端认为该数据包可能丢失了，重新发送刚才发送的数据包，直至接收到接收端回复的确认消息后，继续发送下一个数据包。超时重传可能会导致接收端收到重复的数据包，因此接收端需要判断数据包是否重复，如果重复，则丢弃。

可选地，所述方法还包括：

所述发送端按照连续性的时段统计各时段内发生重新发送数据包现象的次数，若在某一所述时段内统计的所述次数大于预设的次数阈值，则执行流量控制操作；

其中，所述流量控制操作包括：

按照逐渐递减的规则，每重新发送一个数据包时，重新发送数据包的数据量减少一定量，直至后续的所述时段内统计的所述次数小于或等于所述次数阈值时，停止减少重新发送数据包的数据量，并按照当前发送数据包的数据量的大小进行数据传输；

和/或，

按照逐渐递增的规则，每重新发送一个数据包，所述等待时长增加一定时长，所述等待时长增加至预设的最大值时停止增加，直至后续的所述时段内统计的所述次数小于或等于所述次数阈值时，将所述等待时长恢复至预设的默认值。

请参照图4，在安全传输层设定了流量控制机制，当底层连接出现不稳定或者上层建立连接过多，导致数据传输延时增加，确认消息在等待时长之后到达，从而导致大量的超时重传数据包堆积到网络中。因此，为了解决这种问题，增加了流量控制，即在非常频繁的发生超时重传后，通过逐渐地减少重传的数据量、增加超时重传的时间的方式，来解决问题。具体的，以两个客户端同时向服务端发起请求为例说明，但这不是对本申请的限制，只是为了便于理解而进行的示例性说明。

请参见图6，客户端a、b都与服务端s建立了通信连接，此时，客户端a、b为发送端，服务端为接收端。且获知传输介质的传输延时为d1(传输介质的传输延时由其本身性质所决定，可通过测试获得，非本申请需要解决的问题，不再赘述)，将超时重传时间(即等待时长)设置为：2×d1+20毫秒，因此，服务端回复的确认消息(ack)在网络通畅时有足够的时间能反馈给客户端a和/或b。如果在传输过程中，数据未发生丢失，则不会发生超时重传现象。但是，如果出现以下两种情况，可能会导致超时重传现象频繁发生，第一种，传输介质出了问题，比如介质老化，介质硬件故障等等；第二种，客户端a、b传输数据量超过了传输介质的最大带宽，比如a准备发送数据给服务端s，但此时客户端b正在传输大量数据，已经将传输介质带宽占满了，客户端a发送的数据必然会有延时，最终会导致客户端a收到服务端s回复ack的时间已经超过了超时重传时间，a会再次发送数据给服务端s，造成传输了大量重复数据，这势必会造成通信连接路线冗余，占用大量传输介质带宽，浪费资源。

因此通过流量控制机制解决上述问题。客户端a和b按照连续性的时段统计各时段内发生重新发送数据包现象的次数，若在某一所述时段内客户端a统计的所述次数大于预设的次数阈值，则说明现在网络不好，那么客户端a将采取如下措施：

1、减少超时重传数据量。客户端a仍然进行超时重传，但是将超时重传的数据量逐渐减少，按照逐渐递减的规则，每重新发送一个数据包时，重新发送数据包的数据量减少一定量，一直减少到一个最小值(比如正常时超时重传100k的数据，现在重传50k的数据，下下次重传20k等)，减轻传输介质压力，有助于数据及时到达服务端s，从而减少重传次数。直至后续的所述时段内客户端a统计的所述次数小于或等于所述次数阈值时，客户端a停止减少重新发送数据包的数据量，并按照当前发送数据包的数据量的大小进行数据传输。

2、增加超时重传时间。客户端a会逐渐增加自己的超时重传时间，按照逐渐递增的规则，每重新发送一个数据包，所述等待时长增加一定时长，直到一个最大值；如果网络恢复，直至后续的所述时段内统计的所述次数小于或等于所述次数阈值时，将所述等待时长恢复至预设的默认值。

通过以上措施，减少重传次数，减轻传输介质压力。

在一示例性实施例中，当所述服务端为接收端时、所述目标客户端是发送端，当所述服务端是发送端时、所述目标客户端是接收端；

所述方法还包括：

在所述发送端向所述接收端发送多个数据包时，为每个所述数据包添加序号；

在所述接收端接收多个所述数据包时，根据所述序号整理多个所述数据包。

请参见图4，在安全传输层还设定了数据顺序控制机制，安全传输层需要保证数据从发送端到达接收端后，数据顺序要保持一致，不能乱序。为了解决这个问题，基于本申请的用于传输数据的方法的通信协议中，发送端对每个发送的数据包进行编号，在接收端按照编号向上层(应用层)提交数据，从而保证数据顺序的一致性。

在一示例性实施例中，所述方法还包括：

所述客户端向所述服务端发送关闭连接通知，所述服务端响应于所述关闭连接通知断开所述通信连接；或

所述服务端在将所有所述目标数据的数据包全部发送完成后断开所述通信连接。

请继续参见图3，目标客户端与服务端连接的通信建立过程：

通过上述实施例的描述，由于协议基于的传输介质比较稳定，因此建立连接时只采用单次握手，结合图7示出。即：客户端(client)发送通信连接请求后，开始等待；服务端(server)接收到客户端通信连接请求后，反馈连接确认消息；客户端在规定的等待时间内如果收到服务端反馈的连接确认消息，则建立通信连接成功；如果没收到连接确认消息，则通信连接失败。如果服务器反馈了连接确认消息后，客户端刚好到达等待时间，那么此时客户端认为通信连接失败，但是服务端认为连接已经建立，这种情况下，服务端维护的通信连接无法收到客户端发送的心跳消息，因此当心跳超时后，服务端会自动销毁该连接。

目标客户端与服务端通信连接断开过程：

断开通信连接的过程也采用单次握手，结合图8示出。客户端、服务端任意一方都可以主动调用函数接口断开通信连接。当物理链路故障时，表示心跳消息的数据包无法传送到对方，一次心跳超时后，两端的连接也会断开。

调用函数接口断开通信连接过程，发起方向对方发送断开连接数据包后，直接断开自己的连接，不需要接收对方的反馈消息。对方接收到断开连接数据包后，立即执行断开连接过程，断开连接。其中，发起方可以是客户端也可以是服务端。发起方是服务端时，在将所有所述目标数据的数据包全部发送完成后调用函数接口断开通信连接，发起方是客户端时，在将所有所述目标数据的数据包全部接收并存储于缓冲区后调用函数接口断开通信连接。

特别说明的是，本申请的用于传输数据的方法的通信协议中，发送端与接收端之间的传输数据包的格式如下表所示：

本公开还提供了一种用于数据传输的系统，包括：

服务端、多个客户端和传输介质；

所述服务端和多个所述客户端均通过所述传输介质建立物理连接；

所述服务端设定第一套接字，并且所述第一套接字处于监听状态；

多个所述客户端均一一对应设定各自的第二套接字；

目标客户端通过其自身对应的所述第二套接字向设定了所述第一套接字的服务端发送通信连接请求，其中，所述目标客户端是多个所述客户端中欲请求所述服务端传输数据的一个或若干个；

当所述服务端的所述第一套接字监听到所述通信连接请求，则所述服务端响应所述通信连接请求，所述第一套接字和所述目标客户端对应的第二套接字建立连接，从而使得所述目标客户端与所述服务端通过所述传输介质建立通信连接；

所述目标客户端通过所述通信连接向所述服务端发送数据传输请求；

所述服务端响应于所述数据传输请求查找待传输的目标数据，并将查找到的所述目标数据通过所述通信连接向所述目标客户端发送；

所述目标客户端通过所述通信连接接收所述目标数据。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

以上对本申请所提供的一种用于数据传输的方法和系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。