统包括客户端、服务器，及与所述客户端和所述服务器分别连接的上述任一项所述的数据 引流装置。
[0055] 本发明的基于应用类型的数据引流方法、装置及系统，通过接收客户端发送的SYN 数据包，并将该接收的SYN数据包分别通过至少两条链路发送给服务器；接收该服务器分 别通过至少两条链路返回的SYN+ACK数据包；并将最快返回的SYN+ACK数据包发送给所述 客户端，将所述最快返回的SYN+ACK数据包对应的链路确定为初步目标链路；接收所述客 户端发送的ACK数据包，并将所述接收的ACK数据包通过所述初步目标链路发送给所述服 务器；接收所述客户端发送的业务数据包，并识别该业务数据包对应的应用类型；根据该 业务数据包对应的应用类型和所述初步目标链路，确定最终目标链路，将该业务数据包通 过所述确定的最终目标链路发送给所述服务器；即在客户端与服务器的第二次握手中，先 确定客户端与服务器的初步目标链路，然后再根据客户端发送的业务数据包的应用类型和 初步目标链路确定最终目标，将该业务数据包通过确定的最终目标链路发送给服务器，实 现对业务数据包的引流，可灵活的对业务数据包进行引流，提高引流效率和网络资源利用 率。
【附图说明】
[0056] 图1为本发明基于应用类型的数据引流方法的第一实施例的流程示意图；
[0057] 图2为本发明基于应用类型的数据引流方法中客户端通过数据引流装置与服务 器进行第一次握手的示意图；
[0058] 图3为本发明基于应用类型的数据引流方法中客户端通过数据引流装置与服务 器进行第二次握手的示意图；
[0059] 图4为本发明基于应用类型的数据引流方法中客户端通过数据引流装置与服务 器进行第三次握手的示意图；
[0060] 图5为本发明基于应用类型的数据引流方法中根据该业务数据包对应的应用类 型和初步目标链路，确定最终目标链路，将该业务数据包通过所述确定的最终目标链路发 送给服务器的细化流程示意图；
[0061] 图6为本发明基于应用类型的数据引流方法中客户端通过数据引流装置与服务 器进行业务数据包传输的第一实施例示意图；
[0062] 图7为本发明基于应用类型的数据引流方法中客户端通过数据引流装置与服务 器进行ACK数据包传输的一实施例示意图；
[0063] 图8为本发明基于应用类型的数据引流方法中客户端通过数据引流装置与服务 器进行业务数据包传输的第二实施例示意图；
[0064] 图9为本发明基于应用类型的数据引流方法的第二实施例的流程示意图；
[0065] 图10为本发明基于应用类型的数据引流装置的优选实施例的流程示意图；
[0066]图11为本发明基于应用类型的数据引流装置中的第二确定模块的一实施例细化 结构示意图；
[0067]图12为本发明基于应用类型的数据引流系统的优选实施例的结构示意图。
[0068] 本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
【具体实施方式】
[0069] 应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0070] 参照图1，图1为本发明基于应用类型的数据引流方法的第一实施例的流程示意 图，该方法应用于数据引流装置，该方法包括：
[0071]S10、接收客户端发送的SYN数据包，并将该接收的SYN数据包分别通过至少两条 链路发送给服务器。
[0072] 该SYN数据包是客户端待发送给服务器的，用于请求与服务器建立连接，该SYN数 据包的序列号是客户端随机产生的一个数，标记为cliid，该SYN数据包的确认号为0。
[0073] 在该步骤中，将该SYN数据包分别通过至少两条链路发送给服务器，在一实施例， 如图2所示，将该SYN数据包分别通过第一链路和第二链路发送给该服务器；在另一实施 例，将该SYN数据包分别通过第一链路、第二链路和第三链路发送给该服务器。
[0074] 在一实施例中，在该步骤中，在将SYN数据包通过第一链路发送给该服务器时，先 将该SYN数据包的源IP地址换成第一链路的IP地址，然后再该SYN数据包通过第一链路 发送给该服务器；在将SYN数据包通过第二链路发送给该服务器时，先将该SYN数据包的源 IP地址换成第二链路的IP地址，然后再将该SYN数据包通过第二链路发送给该服务器；在 将SYN数据包通过第三链路、第四链路等发送给该服务器时，也先将SYN数据包的源IP地 址换成对应链路的IP地址。
[0075] 即当该客户端与该服务器之间有多条链路时，则分别将该SYN数据包通过各条链 路发送给该服务器，该客户端通过各条链路与该服务器进行第一次握手。在本发明中，以该 客户端与该服务器端之间的链路包括第一链路和第二链路为例，对本发明进行详细描述。
[0076] 该服务器在接收到通过第一链路发送的SYN数据包后，如果允许通过第一链路与 该客户端建立连接，则确认该SYN数据包，同时自己也发送一个SYN数据包，即向该客户端 发送SYN+ACK数据包，序列号为srvidl，该序列号由该服务器对该第一链路随机生成，确认 号为cliid+1。
[0077] 同理，该服务器在接收到通过第二链路发送的SYN数据包后，如果允许通过第二 链路与客户端建立连接，则确认该SYN数据包，同时自己也发送一个SYN数据包，即向该客 户端发送SYN+ACK数据包，序列号为Srvid2,该序列号由该服务器对该第二链路随机生成， 确认号为cliid+1。
[0078]S20、接收该服务器分别通过至少两条链路返回的SYN+ACK数据包；并将最快返回 的SYN+ACK数据包发送给该客户端，将该最快返回的SYN+ACK数据包对应的链路确定为初 步目标链路。
[0079] 在该步骤中，接收该服务器分别通过至少两条链路返回的SYN+ACK数据包，通过 各链路返回的SYN+ACK数据包的序列号不同，确认号相同，通过各个链路返回的SYN+ACK数 据包有先后顺序，将最快返回的SYN+ACK数据包发送给该客户端，该服务器与该客户端进 行第二次握手；并将该最快返回的SYN+ACK数据包对应的链路确定为初步目标链路，如在 一实施例中，最快返回的SYN+ACK数据包对应的链路为第一链路，则将第一链路确定为初 步目标链路。
[0080] 在该步骤中，还记录各个链路对应的序列号等信息，如表一所示。
[0081]表一
[0082]
[0083] 在该步骤中，如图3所示；只将从该服务器中最快返回的SYN+ACK数据包发送给 该客户端，从该服务器中返回的其他SYN+ACK数据包不发送给该客户端，但是会记录其他 SYN+ACK数据包所在链路的信息。如该服务器从第二链路返回的SYN+ACK数据包比从第一 链路返回的SYN+ACK数据包时间慢，则不会将第二链路返回的SYN+ACK数据包发送给该客 户端，而只是记录该第二链路的信息。
[0084] S30、接收该客户端发送的ACK数据包，并将该接收的ACK数据包通过该初步目标 链路发送给该服务器。
[0085] 该客户端在接收该服务器端返回的SYN+ACK数据包后，需要向该服务器发送ACK 数据包（确认包），进行第三次握手。当在步骤SI1中，该客户端接收的SYN+ACK数据包是从 第一链路返回，则在该步骤S12中，该ACK数据包的序列号为cliid+Ι，确认号为srvid+1， 即该ACK数据包的序列号为SYN+ACK数据包的确认号，该ACK数据包的确认号为SYN+ACK 数据包的序列号加1。
[0086] 在该步骤中，如图4所示，将接收的ACK数据包通过该初步目标链路发送给该服务 器，即通过第一链路发送给该服务器。
[0087]S40、接收该客户端发送的业务数据包，并识别该业务数据包对应的应用类型。
[0088] 在前面三个步骤完成三次握手后，该客户端可向该服务器发送业务数据包。
[0089] 在该步骤中，接收该客户端发送的业务数据包，该业务数据包的序列号为 cliid+1，确认号为srvid+l〇
[0090] 识别该业务数据包对应的应用类型，具体的，对该业务数据包进行分析，得到统一 资源定位符URL，根据该URL确定业务数据包对应的应用类型。
[0091] 业务数据包对应的应用类型包括web游戏应用、web视频应用、web即时通讯应用 等等。
[0092] S50、根据该业务数据包对应的应用类型和该初步目标链路，确定最终目标链路， 将该业务数据包通过该确定的最终目标链路发送给该服务器。
[0093] 不同应用类型的数据包的传输要求不同，比如，对于P2P类应用、下载工具类应 用、网盘类应用，占带宽大，但是由于是在后台运行，客户体验不敏感，因此，可将这类应用 引流到传输质量较差的链路；对于游戏类应用、炒股类应用、主流网站应用等用户体验比较 敏感的应用，希望引流到传输质量好的链路。
[0094] 在该步骤中，可根据业务数据包对应的应用类型先确定一个默认传输链路，然后 从该默认传输链路和初步目标链路中，选择一个作为最终目标链路；再将该业务数据包通 过该最终目标链路发送给该服务器，如最终目标链路为第一链路，则将业务数据包通过该 第一链路发送给该服务器。
[0095] 采用上述实