数据传输方法、装置、系统以及存储介质与流程

1.本技术涉及信息传输技术领域，尤其涉及一种数据传输方法、装置、系统以及存储介质。


背景技术：

2.在数据传输过程中，为了提高数据的处理效率，可以采用多路复用的相关技术。所谓多路复用，就是采用同一个信道同时传输多路数据信号。
3.目前，在多路复用场景下，均使用系统协议栈承载。具体来说，就是当客户端生成一个请求数据，并需要通过服务端发送给外部的服务器时，在客户端内，该请求数据需要调用客户端所在设备中系统协议栈内的相关参数，进而发送至服务端，使得服务端将请求数据发送至相应的外部服务器。或者，当外部服务器需要通过服务端向客户端反馈数据时，服务端在接收到反馈数据后，向客户端发送反馈数据时，也需要调用服务端所在设备中系统协议栈内的相关参数，进而将反馈数据发送至客户端。
4.然而，当服务端与外部服务器属于不同的运营商或者处于跨境这样的弱网场景下时，客户端与外部服务器之间的数据传输效率较低。并且，在客户端发出的请求数据数量较大的情况下，也会出现客户端与外部服务器之间数据传输效率较低，甚至无法传输的情况。


技术实现要素：

5.本技术实施例的目的是提供一种数据传输方法、装置、系统以及存储介质，以提高数据在网络中的传输效率。
6.为解决上述技术问题，本技术实施例提供如下技术方案：
7.本技术第一方面提供一种数据传输方法，所述方法应用于客户端；所述方法包括：获取请求数据；调用用户态协议栈内的相关参数将所述请求数据通过网卡发送至服务端，以使所述服务端将所述请求数据发送至相应的外部服务器，其中，所述用户态协议栈为建立在所述客户端并与系统协议栈相同的协议栈，所述用户态协议栈内的相关参数可基于数据传输场景调整。
8.本技术第二方面提供一种数据传输方法，所述方法应用于服务端；所述方法包括：获取反馈数据，所述反馈数据为所述服务端基于客户端发送的请求数据响应的数据；调用用户态协议栈内的相关参数将所述反馈数据通过网卡发送至客户端，以使所述客户端将所述反馈数据发送至相应的用户，其中，所述用户态协议栈为建立在所述服务端并与系统协议栈相同的协议栈，所述用户态协议栈内的相关参数可基于数据传输场景调整。
9.本技术第三方面提供一种客户端，所述客户端包括：应用数据接入模块、用户态协议栈模块、网卡；所述应用数据接入模块，用于获取请求数据；所述用户态协议栈模块，用于调用用户态协议栈内的相关参数将所述请求数据通过网卡发送至服务端，以使所述服务端将所述请求数据发送至相应的外部服务器，其中，所述用户态协议栈为建立在所述客户端并与系统协议栈相同的协议栈，所述用户态协议栈内的相关参数可基于数据传输场景调
整。
10.本技术第四方面提供一种服务端，所述服务端包括：应用数据接入模块、用户态协议栈模块、网卡；所述应用数据接入模块，用于获取反馈数据，所述反馈数据为所述服务端基于客户端发送的请求数据响应的数据；所述用户态协议栈模块，用于调用用户态协议栈内的相关参数将所述反馈数据通过网卡发送至客户端，以使所述客户端将所述反馈数据发送至相应的用户，其中，所述用户态协议栈为建立在所述服务端并与系统协议栈相同的协议栈，所述用户态协议栈内的相关参数可基于数据传输场景调整。
11.本技术第五方面提供一种数据传输系统，所述系统包括：第三方面中的客户端和第四方面中的服务端。
12.本技术第六方面提供一种计算机可读存储介质，所述存储介质包括：存储的程序；其中，在所述程序运行时控制所述存储介质所在设备执行第一方面或第二方面中的方法。
13.相较于现有技术，本技术第一方面提供的数据传输方法，首先，客户端获取请求数据；然后，客户端调用其用户态协议栈内经过优化调整后的相关参数将请求数据通过网卡发送至服务端，以使服务端将请求数据发送至相应的外部服务器。在客户端发出请求数据时，由于跳过了其所在设备的系统协议栈，即不再调用系统协议栈内不便于修改的相关参数，而是调用了客户端内用户态协议栈中可调的相关参数，因此，客户端与服务端之间的数据传输过程可以得到进一步优化，即降低了与外部服务器分属于不同运营商或者跨境传输所带来的影响，提高了客户端-服务端的网络传输效率。并且，在客户端向外发送请求数据的过程中，由于调用的是客户端的用户态协议栈内的相关参数，而没有调用客户端所在设备的系统协议栈的相关参数，因此，系统协议栈的相关参数还可以供其它模块在进行数据传输或者其它处理时所使用，这样，还能够提高客户端与服务端之间的网络的承载能力，进一步确保其所提供的服务的稳定性以及可用性。
14.本技术第二方面提供的数据传输方法，第三方面提供的数据传输装置、第四方面提供的数据传输装置、第五方面提供的数据传输系统、第六方面提供的计算机可读存储介质，与第一方面提供的数据传输方法具有相同或相似的有益效果。
附图说明
15.通过参考附图阅读下文的详细描述，本技术示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本技术的若干实施方式，相同或对应的标号表示相同或对应的部分，其中：
16.图1为本技术实施例中数据传输方法的架构示意图；
17.图2为本技术实施例中数据传输方法的流程示意图一；
18.图3为本技术实施例中的数据传输方法的流程示意图二；
19.图4为本技术实施例中客户端的结构示意图；
20.图5为本技术实施例中服务端的结构示意图；
21.图6为本技术实施例中数据传输系统的结构示意图；
22.图7为本技术实施例中网络中数据传输的架构示意图。
具体实施方式
23.下面将参照附图更详细地描述本技术的示例性实施方式。虽然附图中显示了本技术的示例性实施方式，然而应当理解，可以以各种形式实现本技术而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本技术，并且能够将本技术的范围完整的传达给本领域的技术人员。
24.需要注意的是，除非另有说明，本技术使用的技术术语或者科学术语应当为本技术所属领域技术人员所理解的通常意义。
25.目前，在采用多路复用技术进行数据传输的过程中，客户端以及服务端无论是向外部服务器发送数据，还是接收外部服务器传输的数据，均调用的是客户端或者服务端所在设备中系统协议栈内的相关参数。但是，当服务端与外部服务器属于不同的运营商或者处于跨境这样的弱网场景下时，客户端与外部服务器之间的数据传输效率较低。并且，在客户端发出的数据量较大的情况下，也会出现客户端与外部服务器之间数据传输效率较低，甚至无法传输的情况。
26.发明人经过研究发现，无论是在服务端与外部服务器属于不同的运营商或者处于跨境这样的弱网场景下，还是在客户端发出的数据量较大的情况下，客户端与外部服务器之间的数据传输效率较低的原因在于：客户端向服务端发出请求数据或者服务端向客户端发送反馈数据时，调用的都是其所在设备中系统协议栈内的相关参数。而这些参数一般来说都是固定不变的。即便可以对这些参数进行改变，也很容易导致客户端或服务端所在设备内其它模块无法正常使用。因此，在客户端通过服务端向外部服务器发送数据，或者客户端通过服务端接收外部服务器传输的数据时，可以考虑跳过客户端或者服务端所在设备中系统协议栈内的相关参数。在客户端以及服务器中重新建立一个相关参数可调的协议栈，可以称之为用户态协议栈。在客户端通过服务端向外部服务器发送数据，或者客户端通过服务端接收外部服务器传输的数据时，通过调整用户态协议栈内相关参数，并进行调用，能够降低客户端与服务端之间数据传输的受影响程度，进而提升网络，即客户端与外部服务器之间的数据传输效率。
27.有鉴于此，本技术实施例提供一种数据传输方法、装置、系统以及存储介质，通过在客户端以及服务端内配置与系统协议栈相同的用户态协议栈，在客户端需要通过服务端向外部服务器发送请求数据，或者客户端需要通过服务端接收外部服务器传输的反馈数据的情况下，客户端或者服务端就能够不再调用其所在设备内的系统协议栈内的相关参数进行数据传输，而是可以调用相关参数可被修改的用户态协议栈内的相关参数进行数据传输。这样，能够基于实际的输出数据传输场景对用户态协议栈内的相关参数进行精准调整，进而降低客户端与服务端之间的数据传输受整个网络的影响程度，能够提升客户端、服务端以及外部服务器所处的网络的数据传输效率。
28.并且，通过本技术实施例提供的数据传输方法、装置、系统以及存储介质，在客户端发送的数据量较大的情况下，由于跳过了调用其所在设备中系统协议栈内的相关参数，因此能够节省大量的系统上下文调用，降低了多路复用所需要的链接数，使得在发送的数据量较大的情况下，还能够确保客户端以及服务器所在设备的稳定运行。
29.首先，对本技术实施例提供的数据传输方法的整体架构进行说明。
30.图1为本技术实施例中数据传输方法的架构示意图，参见图1所示，在该架构中，可
以包括：客户端101、服务端102和外部服务器103。
31.当客户端有数据(即请求数据)需要发送至相应的外部服务器时，首先，客户端通过调用其用户态协议栈内的相关参数将请求数据发送至服务端；然后，服务端再将请求数据转发至相应的外部服务器。由于客户端用户态协议栈内的相关参数可基于实际传输情况调整，因此，客户端与服务端之间的数据传输不会受到服务端与外部服务器之间的不同运营商或者跨境传输这样的弱网环境的干扰，进而能够提升客户端与外部服务器之间的数据传输效率。
32.当相应的外部服务器有数据(即反馈数据)需要发送至客户端时，首先，外部服务器将反馈数据发送至服务端；然后，服务端调用其用户态协议栈内经过调整后的相关参数再将反馈数据转发至客户端。由于服务端用户态协议栈内的相关参数可基于实际传输情况调整，因此，服务端与客户端之间的数据传输不会受到服务端与外部服务器之间的不同运营商或者跨境传输这样的弱网环境的干扰，进而能够提升客户端与外部服务器之间的数据传输效率。
33.接下来，继续针对本技术实施例提供的数据传输方法进行说明。这里的数据传输方法应用于客户端。
34.图2为本技术实施例中数据传输方法的流程示意图一，参见图2所示，该方法可以包括：
35.s201：获取请求数据。
36.这里的请求数据就是客户端需要通过服务端向相应的外部服务器发送的数据，也可以称之为数据包。
37.s202：调用用户态协议栈内的相关参数将请求数据通过网卡发送至服务端，以使服务端将请求数据发送至相应的外部服务器。
38.其中，用户态协议栈为建立在客户端并与系统协议栈相同的协议栈，用户态协议栈内的相关参数可基于数据传输场景调整。
39.当客户端需要将请求数据发送至服务端，进而通过服务端将请求数据发送至相应的外部服务器时，如果调用的是客户端所在设备的系统协议栈内的相关参数，由于一般情况下不会对该参数作出任何调整，因此，采用该参数将请求数据发送至服务端，在传输过程中，如果最终接收数据的外部服务器与服务端属于不同的运营商，或者处于跨境传输这样的弱网环境下，那么客户端与服务端之间的传输过程就会受到较大的影响，进而降低了整个网络，即客户端-服务端-外部服务器的数据传输效率。
40.而如果更换一种新的思路，即在设备的系统之外，可以是在客户端相应的软件中，配置一个与系统协议栈相同的协议栈，即用户态协议栈。在该用户态协议栈内，调用时所需要的相关参数均可以进行修改。用户态协议栈内的相关参数在修改之后，只能够影响到客户端自身，这也是我们希望得到的结果，而不会影响客户端所在设备中其它模块的正常运行。这样，客户端再次有数据数据传输场景时，就可以调用用户态协议栈内经过优化调整后的相关参数将请求数据发送至服务端，进而通过服务端将请求数据发送至相应的外部服务器。这样，能够尽可能的减小不用运营商以及跨境传输等场景对于客户端与外部服务器之间的数据传输效率的影响，进而提高网络的数据传输性能。
41.对于在客户端内配置用户态协议栈的具体过程，与现有的配置文件的具体过程类
似，此处不再赘述。
42.在具体实施过程中，客户端接收到用户的请求数据后，客户端首先调用其用户态协议栈内预先调整后的相关参数。然后，客户端使用该参数将请求数据直接通过网卡发送至服务端，最后，服务端再将请求数据转发至相应的外部服务器。由于客户端在发送请求数据时，跳过了其所在设备的系统协议栈，减少了系统上下文的调用，能够直接通过网卡发送请求数据，进一步提高了数据的传输效率。
43.这里需要说明的是，用户态协议栈内存在有众多的参数，而这里的相关参数是指与请求数据的收发过程相关的各项参数。例如：数据发生丢包时，其对应的降速百分比。再例如：上传数据时，其对应的升速百分比。等等。对于用户态协议栈内需要调整的相关参数的具体类型以及数值，此处不做具体限定。
44.在实际应用中，客户端调用用户态协议栈的相关参数将请求数据通过网卡发送至服务端的过程中，可以使用libpcap或uio技术。libpcap或uio技术都为现有的数据包传输技术，此处不再进行过多的说明。
45.由上述内容可知，本技术实施例提供的数据传输方法，首先，客户端获取请求数据；然后，客户端调用其用户态协议栈内经过优化调整后的相关参数将请求数据通过网卡发送至服务端，以使服务端将请求数据发送至相应的外部服务器。在客户端发出请求数据时，由于跳过了其所在设备的系统协议栈，即不再调用系统协议栈内不便于修改的相关参数，而是调用了客户端内用户态协议栈中可调的相关参数，因此，客户端与服务端之间的数据传输过程可以得到进一步优化，即降低了与外部服务器分属于不同运营商或者跨境传输所带来的影响，提高了客户端-服务端的网络传输效率。并且，在客户端向外发送请求数据的过程中，由于调用的是客户端的用户态协议栈内的相关参数，而没有调用客户端所在设备的系统协议栈的相关参数，因此，系统协议栈的相关参数还可以供其它模块在进行数据传输或者其它处理时所使用，这样，还能够提高客户端与服务端之间的网络的承载能力，进一步确保其所提供的服务的稳定性以及可用性。
46.进一步地，作为对图2所示方法的细化和扩展，在客户端调用其用户态协议栈的相关参数将请求数据通过网卡发送至服务端之前，需要先根据实际传输情况对用户态协议栈内的相关参数进行优化调整，以使得请求数据从客户端发往服务端的过程中，能够以最优的效率进行传输。
47.具体来说，在步骤s201之前，该方法还可以包括：
48.步骤a1：针对不同的数据传输场景修改用户态协议栈内滑动窗口的相关参数。
49.一般来说，根据实际的数据数据传输场景，在用户态协议栈内，调整的都是不同场景对应的相关参数。这样，能够使得数据在客户端与服务端传输的过程中，无论发生哪种情况，都能够按照用户态协议栈内调整后的相关参数进行数据传输。
50.举例来说，当数据传输场景为丢包时，也就是说，客户端在向服务端传输多个数据包时，发生了部分数据包的丢失。如果调用的是系统协议栈内的相关参数进行数据包发送，此时数据包的传输速度就会以指数的速度下降，例如从3m直接降到500k。而通过预先在用户态协议栈内将丢包场景下的滑动窗口的降速百分比进行调整，即将该百分比的数值提高，此后如果客户端再向服务端传输数据包，并发生了丢包，由于调用的是用户态协议栈内经过调整后的相关参数，因此，即便发生了丢包问题，剩余的数据包在传输过程中的速度也
不会降低的过快，例如从3m降到1m。进而提高了数据在网络中的传输效率。
51.再举例来说，当数据传输场景为上传时，也就是说，客户端需要向服务端发送数据包，进而通过服务端将数据包上传至外部服务器。如果调用的是系统协议栈内的相关参数将数据包发送至服务端，此时数据包的传输速度为逐渐上升，直到保持最大传输速度，例如从1m慢慢上升至最大上传速度3m。而通过预先在用户态协议栈内将上传场景下的滑动窗口的升速百分比进行调整，即将该百分比的数值提高，此后如果客户端再向服务端传输数据包，由于调用的是用户态协议栈内经过调整后的相关参数，因此，数据包在上传过程中的上传提速就会有明显的增加，例如从1m更快的上升至最大上传速度3m，进而提高了数据在网络中的传输效率。
52.当然，数据传输场景还可以是除丢包、上传之外的其它场景，例如下载场景等。不同的场景在用户态协议栈内调整的具体的相关参数不同，这需要基于具体的数据传输场景确定。对于具体的数据传输场景及对应调整的相关参数的具体内容，此处不做限定。
53.此外，除了针对不同的数据传输场景调整用户态协议栈内滑动窗口的相关参数之外，还可以基于其它传输需要调整用户态协议栈内的相关参数，例如调整数据的传输格式等。对于调整的用户态协议栈的相关参数的具体内容，此处也不做限定。
54.由上述内容可知，通过根据不同的数据传输场景调整用户态协议栈内滑动窗口对应的相关参数，使得数据在从客户端向服务端传输的过程中，无论发生何种情况，都能够以最高的效率进行传输，进一步提升了数据在网络中的传输效率。
55.进一步地，作为对图2所示方法的细化和扩展，客户端在获得请求数据后，只有确定了用户需要将请求数据发送到哪里，即哪一个相应的外部服务器，后续才能够将用户的请求准确的发送至正确的地址。
56.具体来说，在步骤s201之后，该方法还可以包括：
57.步骤b1：监听请求数据所使用的代理协议。
58.不同的数据进行发送时，其所使用的代理协议所有不同。客户端为了获知请求数据需要发送的地址，就需要先获取请求数据所使用的代理协议，进而基于获取的代理协议解析请求数据，进而获取请求数据需要发送至何处。
59.具体来说，可以通过客户端所在设备上用户指定的端口进行代理协议的监听，使得后续能够基于监听到的代理协议对请求数据进行解析。
60.在实际应用中，请求数据一般使用的是socks5代理协议。当然，请求数据也可以使用其它的代理协议，例如http代理协议。对于请求数据所使用的代理协议的具体类型，此处不做限定。
61.步骤b2：通过代理协议解析请求数据，得到请求数据发送的地址。
62.在获知了请求数据所使用的代理协议之后，就能够基于该代理协议对请求数据进行解析，进而从请求数据的预设字段中获知请求数据需要发往何处。
63.而通过代理协议对请求数据进行解析，以获得请求数据发送的地址的具体过程，与现有的基于传输协议解析数据，并对数据进行发送的过程类似，此处不再赘述。
64.步骤b3：通过客户端与服务端之间的私有协议将请求数据与地址重组。
65.在客户端获知了请求数据发往何处，即发送的地址之后，由于客户端并不是直接将请求数据发送至相应的外部地址，即外部服务器，而是需要通过服务端将请求数据发送
至相应的外部服务器。因此，客户端可以通过其与服务端之间的私有协议重组请求数据和地址。由于私有协议为客户端与服务器之间的私有的、可优化调整的，这样，不仅能够确保请求数据发送的安全性，还能够提高请求数据在客户端与服务端之间的传输效率。
66.而步骤s202具体可以包括：步骤b4：调用用户态协议栈内的相关参数将重组后的请求数据通过网卡发送至服务端，以使服务端将重组后的请求数据发送至相应的外部服务器。
67.客户端在获知了请求数据的发送地址，并将该地址和请求数据采用私有协议重组后，就可以调用用户态协议栈内的相关参数，将重组后的请求数据发送至服务端，使得服务端继续将重组后的请求数据发送至相应的外部服务器。
68.由上述内容可知，通过监听到的代理协议对请求数据进行解析，进而获取请求数据的发送地址，并且将该地址和请求数据采用客户端与服务端之间的私有协议进行重组，进而将重组后的请求数据发送至服务端，由于客户端与服务端之间的私有协议可以根据实际需求进行调整，因此，将请求数据通过私有协议重组，并进行发送，能够确保请求数据传输的安全性，以及提升请求数据的传输效率。
69.进一步地，作为对图2所示方法的细化和扩展，当请求数据的数量较多，即为多个，并且需要同时将这多个请求数据发送出去时，如果每个请求数据都调用一次用户态协议栈的相关参数，就会增加客户端的传输负担，进而降低数据传输效率。
70.具体来说，在步骤s201之后，该方法还可以包括：
71.步骤c1：合并每个请求数据对应的第一链接，得到第一单链接。
72.在这里，第一链接用于指示请求数据的位置。
73.如果每发送一个请求数据，就调用一次用户态协议栈内的相关参数，就会增加客户端的负担，而如果能够只调用一次用户态协议栈内的相关参数，就能够将多个请求数据发出，就可以减轻客户端的负担，并且还有助于提升数据的传输效率。
74.由于每个请求数据存储的位置，即第一链接，有的相同，有的不同，因此，可以将本次待发送的所有请求数据的第一链接进行合并，得到一个第一单链接。此后，基于该第一单链接调用用户态协议栈内的相关参数，即该第一单链接对应的多个请求数据都采用调用的相关参数进行发送。这样，仅调用一次用户态协议栈内的相关参数，就能够实现多个请求数据的发送，减轻了客户端的负担，进一步提升了数据的传输效率。
75.这里需要说明的是，上述的合并，就是传统意义上的将多个事物进行拼接。在这里，就是将多个第一链接进行拼接，得到一个第一单链接。相应的，在服务端中，服务端还是会将其接收到的第一单链接拆分为多个第一链接，进而将每个第一链接对应的请求数据发送至相应的外部服务器。
76.而步骤s202具体可以包括：步骤c2：基于第一单链接调用用户态协议栈内的相关参数将多个请求数据通过网卡发送至服务端。
77.在将多个请求对应的第一链接合并为第一单链接后，就可以基于该第一单链接仅调用一次用户态协议栈内的相关参数就将这多个请求数据发送至服务端。减少了用户态协议栈内相关参数的调用次数，减轻了客户端的负担，进一步提升了数据传输效率。
78.相应的，客户端通过服务端将请求数据发送至外部服务器，外部服务器将反馈数据发送至服务端后，如果反馈数据的数量为多个，那么，服务端也会将多个反馈数据对应的
第二链接合并为第二单链接，并基于第二单链接调用服务端的用户态协议栈的相关参数将多个反馈数据发送至客户端。
79.具体来说，在步骤s202之后，该方法还可以包括：
80.步骤d1：将第二单链接拆分为多个第二链接。
81.其中，第二链接用于指示反馈数据的位置。第二单链接是由多个反馈数据的第二链接合并而成的。多个反馈数据为不同的请求数据发送的外部服务器基于相应的请求数据进行反馈的数据。
82.步骤d2：基于多个第二链接将相应的反馈数据发送至相应的用户。
83.实际上，将单链接拆分为多个链接就是将多个链接合并为单链接的逆过程。两者的本质相同，仅仅是过程相逆而已，后者的具体实现方式可以参考前述的将多个链接合并为单链接的部分，此处不再赘述。将单链接拆分为多个链接也是为了在确保数据传输效率的同时，还能够将各个反馈数据分别发送给相应的用户。
84.由上述内容可知，通过将多个请求对应的链接合并为单链接，进而基于该单链接调用用户态协议栈内的相关参数，使得仅调用一次用户态协议栈内的相关参数就能够实现多个请求数据的发送，减少了用户态协议栈内相关参数的调用次数，减轻了客户端的负担，进一步提升了数据传输效率。
85.进一步地，作为对图2所示方法的细化和扩展，在客户端将请求数据发送至服务端，进而服务端将请求数据发送至相应的外部服务器之后，相应的外部服务器就会对接收到的请求数据作出响应，即发出反馈数据。如果此时通过服务端接收到的多个反馈数据的顺序较乱，就有可能出现数据解析出现错误的情况，进而降低了数据传输的准确性性。
86.具体来说，在步骤s202之后，该方法还可以包括：
87.步骤e1：接收多个反馈数据。
88.其中，多个反馈数据为不同的请求数据发送的外部服务器基于相应的请求数据进行反馈的数据。
89.举例来说，客户端通过服务端依次将请求数据1发送至外部服务器1，将请求数据2发送至外部服务器2，将请求数据3发送至外部服务器3。外部服务器1基于请求数据1生成反馈数据1，外部服务器2基于请求数据2生成反馈数据2，外部服务器3基于请求数据3生成反馈数据3，并分别将反馈数据1、反馈数据2以及反馈数据3通过服务端发送至客户端。这样，客户端就接收到了外部服务器1、外部服务器2、外部服务器3分别基于请求数据1、请求数据2、请求数据3响应的反馈数据1、反馈数据2、反馈数据3。
90.步骤e2：按照多个反馈数据的标识对多个反馈数据进行排序。
91.继续上述举例，在外部服务器1、外部服务器2、外部服务器3分别将反馈数据1、反馈数据2、反馈数据3发送至服务端之后，服务端按照数据接收的先后顺序，依次将反馈数据1、反馈数据2以及反馈数据3发送至客户端。此时，客户端内，反馈数据则是按照反馈数据3、反馈数据2以及反馈数据1的先后接收顺序进行排序的。这是因为，先接收的数据排在后面，后接收的数据排在前面，类似于数据列表中的存储。而客户端当初发送请求数据时，是按照请求数据1、请求数据2以及请求数据3的顺序进行排序的。如果接收的反馈数据按照反馈数据3、反馈数据2以及反馈数据1的顺序进行排序，后续就可能会存在数据转发错误的问题，即针对请求数据1，对应给出了反馈数据3。针对请求数据3，对应给出了反馈数据1。
92.此时，客户端还需要对反馈数据3、反馈数据2以及反馈数据1重新进行排序，即按照其标识，排序成：反馈数据1、反馈数据2、反馈数据3。这样，针对请求数据1，就能够正确对应给出反馈数据1。针对请求数据2，就能够正确对应给出反馈数据2。针对请求数据3，就能够正确对应给出反馈数据3。从而提高了数据传输的准确性。
93.该过程可以称之为乱序重组。当然，除了乱序重组，在客户端将请求数据发送至服务端之后，如果发生丢包，还可以进行丢包重发，即，将请求数据中丢失的数据重新发送。以及，在服务端向客户端发出反馈数据后，客户端如果成功接收了数据，还会向服务端反馈确认字符(acknowledge character，ack)。等等。
94.最后需要说明的是，在实际应用中，可以使用golang语言开发本技术实施例中的客户端以及服务端。当然，也可以采用例如java等其它语言。对于开发本技术实施例中的客户端以及服务端所使用的具体语言，此处不做限定，可以根据实际情况进行选择。
95.由上述内容可知，客户端在接收到多个反馈数据后，通过对多个反馈数据进行排序，使其与当初发送的多个请求数据的排序对应，能够将反馈数据准确地与相应的请求数据对应，避免数据传输错误，提高了数据传输的准确性。
96.基于同一发明构思，作为上述客户端对侧的服务端，本技术实施例还提供了一种数据传输方法。该方法应用于服务端。图3为本技术实施例中的数据传输方法的流程示意图二，参见图3所示，该方法可以包括：
97.s301：获取反馈数据。
98.其中，所述反馈数据为所述服务端基于客户端发送的请求数据响应的数据。
99.s302：调用用户态协议栈内的相关参数将所述反馈数据通过网卡发送至客户端，以使所述客户端将所述反馈数据发送至相应的用户。
100.其中，所述用户态协议栈为建立在所述服务端并与系统协议栈相同的协议栈，所述用户态协议栈内的相关参数可基于数据传输场景调整。
101.在本技术其它实施例中，在所述调用用户态协议栈内的相关参数将所述反馈数据通过网卡发送至客户端之前，所述方法还包括：
102.针对不同的数据传输场景修改所述用户态协议栈内滑动窗口的相关参数。
103.在本技术其它实施例中，所述针对不同的数据传输场景修改所述用户态协议栈内滑动窗口的相关参数，包括：
104.当所述数据传输场景为丢包时，调整所述用户态协议栈内滑动窗口的降速百分比；
105.当所述数据传输场景为上传时，调整所述用户态协议栈内滑动窗口的升速百分比。
106.在本技术其它实施例中，所述反馈数据的数量为多个；在所述获取反馈数据之后，所述方法还包括：
107.合并每个反馈数据对应的第二链接，得到第二单链接，所述第二链接用于指示反馈数据的位置；
108.所述调用用户态协议栈内的相关参数将所述反馈数据通过网卡发送至客户端，包括：
109.基于所述第二单链接调用用户态协议栈内的相关参数将多个反馈数据通过网卡
发送至客户端。
110.在本技术其它实施例中，在所述获取反馈数据之后，所述方法还包括：
111.监听所述反馈数据所使用的代理协议；
112.通过所述代理协议解析所述反馈数据，得到所述反馈数据发送的地址；
113.通过所述服务端与所述客户端之间的私有协议将所述反馈数据与所述地址重组；
114.所述调用用户态协议栈内的相关参数将所述反馈数据通过网卡发送至客户端，以使所述客户端将所述反馈数据发送至相应的用户，包括：
115.调用用户态协议栈内的相关参数将重组后的反馈数据通过网卡发送至所述客户端，以使所述客户端将重组后的反馈数据发送至相应的用户。
116.在本技术其它实施例中，在所述调用用户态协议栈内的相关参数将所述反馈数据通过网卡发送至客户端之后，所述方法还包括：
117.接收多个请求数据；按照所述多个请求数据的标识对所述多个请求数据进行排序；和/或，
118.将第一单链接拆分为多个第一链接，所述第一链接用于指示请求数据的位置，所述第一单链接是由多个请求数据的第一链接合并而成的；基于多个第一链接将相应的请求数据发送至相应的外部服务器；
119.其中，所述多个请求数据为不同的用户发出的数据。
120.这里需要指出的是，以上方法实施例的描述，与前述方法实施例的描述是类似的，具有同前述方法实施例相似的有益效果。对于以上方法实施例中未披露的技术细节，请参照前述方法实施例的描述而理解。
121.基于同一发明构思，作为对上述客户端一侧的方法的实现，本技术实施例还提供了一种客户端。图4为本技术实施例中客户端的结构示意图，参见图4所示，该客户端可以包括：应用数据接入模块401、用户态协议栈模块402、网卡403。
122.所述应用数据接入模块401，用于获取请求数据；
123.所述用户态协议栈模块402，用于调用用户态协议栈内的相关参数将所述请求数据通过网卡403发送至服务端，以使所述服务端将所述请求数据发送至相应的外部服务器，其中，所述用户态协议栈为建立在所述客户端并与系统协议栈相同的协议栈，所述用户态协议栈内的相关参数可基于数据传输场景调整。
124.在本技术其它实施例中，所述用户态协议栈模块，用于针对不同的数据传输场景修改所述用户态协议栈内滑动窗口的相关参数。
125.在本技术其它实施例中，所述用户态协议栈模块，用于当所述数据传输场景为丢包时，调整所述用户态协议栈内滑动窗口的降速百分比；当所述数据传输场景为上传时，调整所述用户态协议栈内滑动窗口的升速百分比。
126.在本技术其它实施例中，所述请求数据的数量为多个；所述装置还包括：多路复用模块；
127.所述多路复用模块，用于合并每个请求数据对应的第一链接，得到第一单链接，所述第一链接用于指示请求数据的位置；
128.所述用户态协议栈模块，用于基于所述第一单链接调用用户态协议栈内的相关参数将多个请求数据通过网卡发送至服务端。
129.在本技术其它实施例中，所述应用数据接入模块，用于监听所述请求数据所使用的代理协议；通过所述代理协议解析所述请求数据，得到所述请求数据发送的地址；通过所述客户端与所述服务端之间的私有协议将所述请求数据与所述地址重组；
130.所述用户态协议栈模块，用于调用用户态协议栈内的相关参数将重组后的请求数据通过网卡发送至所述服务端，以使所述服务端将重组后的请求数据发送至相应的外部服务器。
131.在本技术其它实施例中，所述用户态协议栈模块，用于接收多个反馈数据；按照所述多个反馈数据的标识对所述多个反馈数据进行排序；
132.所述多路复用模块，用于将第二单链接拆分为多个第二链接，所述第二链接用于指示反馈数据的位置，所述第二单链接是由多个反馈数据的第二链接合并而成的；基于多个第二链接将相应的反馈数据发送至相应的用户；
133.其中，所述多个反馈数据为不同的请求数据发送的外部服务器基于相应的请求数据进行反馈的数据。
134.这里需要指出的是，以上客户端实施例的描述，与上述客户端侧方法实施例的描述是类似的，具有同客户端侧方法实施例相似的有益效果。对于以上客户端实施中未披露的技术细节，请参照上述客户端侧方法实施例的描述而理解。
135.基于同一发明构思，作为对上述服务端一侧的方法的实现，本技术实施例还提供了一种服务端。图5为本技术实施例中服务端的结构示意图，参见图5所示，该服务端可以包括：应用数据接入模块501、用户态协议栈模块502、网卡503。
136.所述应用数据接入模块501，用于获取反馈数据，所述反馈数据为所述服务端基于客户端发送的请求数据响应的数据；
137.所述用户态协议栈模块502，用于调用用户态协议栈内的相关参数将所述反馈数据通过网卡503发送至客户端，以使所述客户端将所述反馈数据发送至相应的用户，其中，所述用户态协议栈为建立在所述服务端并与系统协议栈相同的协议栈，所述用户态协议栈内的相关参数可基于数据传输场景调整。
138.在本技术其它实施例中，所述用户态协议栈模块，用于针对不同的数据传输场景修改所述用户态协议栈内滑动窗口的相关参数。
139.在本技术其它实施例中，所述用户态协议栈模块，用于当所述数据传输场景为丢包时，调整所述用户态协议栈内滑动窗口的降速百分比；当所述数据传输场景为上传时，调整所述用户态协议栈内滑动窗口的升速百分比。
140.在本技术其它实施例中，所述反馈数据的数量为多个；所述装置还包括：多路复用模块；
141.所述多路复用模块，用于合并每个反馈数据对应的第二链接，得到第二单链接，所述第二链接用于指示反馈数据的位置；
142.所述用户态协议栈模块，用于基于所述第二单链接调用用户态协议栈内的相关参数将多个反馈数据通过网卡发送至客户端。
143.在本技术其它实施例中，所述应用数据接入模块，用于监听所述反馈数据所使用的代理协议；通过所述代理协议解析所述反馈数据，得到所述反馈数据发送的地址；通过所述服务端与所述客户端之间的私有协议将所述反馈数据与所述地址重组；
144.所述用户态协议栈模块，用于调用用户态协议栈内的相关参数将重组后的反馈数据通过网卡发送至所述客户端，以使所述客户端将重组后的反馈数据发送至相应的用户。
145.在本技术其它实施例中，所述用户态协议栈模块，用于接收多个请求数据；按照所述多个请求数据的标识对所述多个请求数据进行排序；
146.所述多路复用模块，用于将第一单链接拆分为多个第一链接，所述第一链接用于指示请求数据的位置，所述第一单链接是由多个请求数据的第一链接合并而成的；基于多个第一链接将相应的请求数据发送至相应的外部服务器；
147.其中，所述多个请求数据为不同的用户发出的数据。
148.这里需要指出的是，以上服务端实施例的描述，与上述服务端侧方法实施例的描述是类似的，具有同服务端侧方法实施例相似的有益效果。对于以上服务端实施中未披露的技术细节，请参照上述服务端侧方法实施例的描述而理解。
149.基于同一发明构思，本技术实施例还提供了一种数据传输系统。图6为本技术实施例中数据传输系统的结构示意图，参见图6所示，该数据传输系统可以包括：客户端601和服务端602。
150.这里需要指出的是，以上系统实施例的描述，与上述客户端和服务端实施例的描述是类似的，具有同客户端和服务端实施例相似的有益效果。对于本技术系统实施例中未披露的技术细节，请参照本技术客户端和服务端实施例的描述而理解。
151.基于同一发明构思，本技术实施例还提供了一种计算机可读存储介质，该存储介质可以包括：存储的程序；其中，在所述程序运行时控制所述存储介质所在设备执行上述客户端侧或服务端侧的方法。
152.这里需要指出的是，以上存储介质实施例的描述，与上述客户端或服务端实施例的描述是类似的，具有同客户端或服务端实施例相似的有益效果。对于本技术存储介质实施例中未披露的技术细节，请参照本技术客户端或服务端实施例的描述而理解。
153.至此，为了更加清楚的对本技术实施例提供的数据传输方法、装置、系统以及存储介质进行说明，以一个完整的实施例再次针对本技术实施例中所谓的网络中的数据传输过程进行说明。
154.图7为本技术实施例中网络中数据传输的架构示意图，参见图7所示，在网络中，包括有：客户端、服务端、目标服务器(也就是前文中所说的外部服务器)。
155.对于客户端来说，其能够安装在不同的设备中，并且对应有不同的用户，即用户01、用户02、用户03、用户04、用户
…
等等。
156.对于服务端来说，其能够与不同的目标服务器进行数据的收发，即与目标服务器01、目标服务器02、目标服务器03、目标服务器04、目标服务器
…
等等。
157.当一个或多个用户有请求需要发出时，首先，客户端中的应用数据接入模块接收请求数据，并解析出请求数据需要发送至哪一个目标服务器。然后，客户端中的多路复用模块将多个请求数据对应的链接合并为一个单链接。接着，客户端中的用户态协议栈模块基于单链接调用调整后的相关参数将请求数据直接发送至网卡。最后，网卡将请求发送至服务端。
158.服务端通过其中的网卡接收到请求数据后，首先，服务端中的多路复用模块将单链接拆分为多个链接。然后，通过服务端中的应用数据接入模块将多个链接对应的请求数
据发送至相应的目标服务器。
159.至此，就完成了客户端向目标服务器发送请求。接下来，继续说明客户端接收目标服务器的响应。
160.当一个或多个目标服务器有响应需要发出时，首先，服务端中的应用数据接入模块接收反馈数据，并解析出反馈数据需要发送至哪一个用户。然后，服务端中的多路复用模块将多个反馈数据对应的链接合并为一个单链接。接着，服务端中的用户态协议栈模块基于单链接调用调整后的相关参数将反馈数据直接发送至网卡。最后，网卡将反馈数据发送至客户端。
161.客户端通过其中的网卡接收到反馈数据后，首先，客户端中的多路复用模块将单链接拆分为多个链接。然后，通过客户端中的应用数据接入模块将多个链接对应的反馈数据发送至相应的用户。
162.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。