数据流的处理方法和装置制造方法
【专利摘要】本发明提供一种数据流的处理方法和装置，该方法包括：通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现内网用户设备与对端设备的三次握手，并在第一线路上建立第一连接；接收内网用户设备发送的数据流的第一个数据请求报文；获取与数据请求报文的协议类型对应的分流策略，并根据分流策略，判断数据请求报文是否需要进行分流处理，若判断出数据请求报文需要进行分流处理，则缓存数据请求报文，并通过第二线路与对端设备重新进行三次握手，以在第二线路上建立第二连接；通过第二连接将缓存的数据请求报文转发给对端设备。
【专利说明】数据流的处理方法和装置
【技术领域】
[0001]本发明涉及网络通信技术，尤其涉及一种数据流的处理方法和装置。
【背景技术】
[0002]随着网络的发展，目前大部分公司或者网络应用场所一般采用多线路作为出口，例如:分别将光纤线路和非对称数字用户环路(Asymmetric Digital Subscriber Line ;简称:ADSL)线路作为出口，其中，一条高质量线路(例如光纤线路)可以用于传输对网络传输时延、抖动等特性敏感的关键应用；另一条低质量线路(例如ADSL线路)可以用于传输对等网络(Peer to Peer ;简称:P2P)等下载应用。因此，根据上述情况，就需要出口网关设备能够根据应用进行报文路由。
[0003]目前，基于应用的路由选路，需要在数据流的第一个报文识别出具体应用业务，SP首报文识别。对于用户数据报文协议(User Data Protocol ;简称:UDP)流，由于第一报文中带有应用层载荷数据，因此，可以通过深度包检测(Deep Packet Inspection ;简称:DPI)技术识别出具体应用业务。但是，对于传输控制协议(Transmission Control Protocol ;简称:TCP)流，由于前面三个报文为握手报文，即不带有载荷特征，因此，无法通过DPI技术对TCP流的第一个报文进行识别，当可以通过TCP流的某个报文识别出具体应用业务后，可能会重新选路，则从服务器角度看，其有可能认为是两个连接，对于重新选路之前的连接由于不再有请求报文而超时断开，对于重新选路之后的连接由于没有正常的握手，则被认为非法拒绝，从而导致断流。
【发明内容】
[0004]本发明提供一种数据流的处理方法和装置，用于解决现有技术中基于DPI技术对TCP流进行分流而造成的断流问题。
[0005]本发明的第一个方面是提供一种数据流的处理方法，包括:
[0006]通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现所述内网用户设备与所述对端设备的三次握手，并在所述第一线路上建立第一连接；
[0007]接收所述内网用户设备发送的所述数据流的第一个数据请求报文；
[0008]获取与所述数据请求报文的协议类型对应的分流策略，并根据所述分流策略，判断所述数据请求报文是否需要进行分流处理，若判断出所述数据请求报文需要进行分流处理，则缓存所述数据请求报文，并通过第二线路与所述对端设备重新进行三次握手，以在所述第二线路上建立第二连接；
[0009]通过所述第二连接将缓存的所述数据请求报文转发给所述对端设备。
[0010]本发明的另一个方面是提供一种数据流的处理装置，包括:
[0011]连接管理模块，用于通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现所述内网用户设备与所述对端设备的三次握手，并在所述第一线路上建立
第一连接；[0012]接收模块，用于接收所述内网用户设备发送的所述数据流的第一个数据请求报文；
[0013]协议分发模块，用于获取与所述数据请求报文的协议类型对应的分流策略；
[0014]分流处理模块，用于根据所述分流策略，判断所述数据请求报文是否需要进行分流处理，若判断出所述数据请求报文需要进行分流处理，则缓存所述数据请求报文；
[0015]所述连接管理模块还用于通过第二线路与所述对端设备重新进行三次握手，以在所述第二线路上建立第二连接；
[0016]发送模块，用于通过所述第二连接将缓存的所述数据请求报文转发给所述对端设备。
[0017]本发明的技术效果是:通过第一线路，为内网用户设备和对端设备转发该数据流的握手报文，以实现内网用户设备和对端设备的三次握手，并在第一线路上建立第一连接，在接收内网用户设备发送的数据流的第一个数据请求报文时，可以获取该数据请求报文的协议类型对应的分流策略，若根据该分流策略判断出该数据请求报文需要进行分流处理，则缓存该数据请求报文，并通过第二线路与对端设备重新进行三次握手，以在第二线路上建立第二连接，以通过该第二连接将缓存的数据请求报文转发给对端设备。由于通过第二线路，重新与对端设备进行三次握手，以建立第二线路上的第二连接，再对缓存的数据请求报文通过第二连接转发给对端设备，因此保证了在数据流重新选路时不会出现断流问题，从而有效地解决了现有技术中基于DPI技术对TCP流进行分流而造成的断流问题。
【专利附图】
【附图说明】
[0018]图1为本发明数据流的处理方法的一个实施例的流程图；
[0019]图2为本发明数据流的处理方法的另一个实施例的流程图；
[0020]图3为本发明数据流的处理方法的又一个实施例的流程示意图；
[0021]图4为本发明数据流的处理方法所基于的网络架构示意图；
[0022]图5为本发明数据流的处理方法的又一个实施例的信令流程图；
[0023]图6为本发明数据流的处理方法的还一个实施例的信令流程图；
[0024]图7为本发明数据流的处理装置的一个实施例的结构示意图；
[0025]图8为本发明数据流的处理装置的另一个实施例的结构示意图。
【具体实施方式】
[0026]图1为本发明数据流的处理方法的一个实施例的流程图，如图1所示，本实施例的方法包括:
[0027]步骤101、通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现该内网用户设备与该对端设备的三次握手，并在该第一线路上建立第一连接。
[0028]步骤102、接收该内网用户设备发送的该数据流的第一个数据请求报文。
[0029]步骤103、获取与该数据请求报文的协议类型对应的分流策略，并根据该分流策略，判断该数据请求报文是否需要进行分流处理，若判断出该数据请求报文需要进行分流处理，则缓存该数据请求报文，并通过第二线路与该对端设备重新进行三次握手，以在该第二线路上建立第二连接。[0030]在本实施例中，第一线路用于传输对网络传输时延、抖动等特性敏感的关键应用。第二线路用于传输P2P等下载应用。
[0031]步骤104、通过该第二连接将缓存的该数据请求报文转发给该对端设备。
[0032]在本实施例中，通过第一线路，为内网用户设备和对端设备转发该数据流的握手报文，以实现内网用户设备和对端设备的三次握手，并在第一线路上建立第一连接，在接收内网用户设备发送的数据流的第一个数据请求报文时，可以获取与该数据请求报文的协议类型对应的分流策略，若根据该分流策略，判断出该数据请求报文需要进行分流处理，则缓存该数据请求报文，并通过第二线路与对端设备重新进行三次握手，以在第二线路上建立第二连接，以通过该第二连接将缓存的数据请求报文转发给对端设备。由于通过第二线路，重新与对端设备进行三次握手，以建立第二线路上的第二连接，再对缓存的数据请求报文通过第二连接转发给对端设备，因此保证了在数据流重新选路时不会出现断流问题，从而有效地解决了现有技术中基于DPI技术对TCP流进行分流而造成的断流问题。
[0033]图2为本发明数据流的处理方法的另一个实施例的流程图，如图2所示，该方法的执行主体为出口设备，则该方法包括:
[0034]步骤201、通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现该内网用户设备与该对端设备的三次握手，并在该第一线路上建立第一连接。
[0035]步骤202、接收该内网用户设备发送的该数据流的第一个数据请求报文。
[0036]步骤203、判断该数据请求报文的协议类型是否为HTTP或者HTTPs协议；若是，则执行步骤204 ;若否，则执行步骤208。
[0037]步骤204、根据该数据请求报文的业务类型，查询预先配置的配置信息，判断该数据请求报文中的数据类型对应的线路是否为该第一线路；若否，则执行步骤205 ;若是，则执行步骤207。
[0038]其中，该配置信息包括业务类型和对应的线路。
[0039]在本实施例中，出口设备一般默认通过第一线路转发接收到的报文。
[0040]步骤205、缓存该数据请求报文，并通过第二线路与该对端设备重新进行三次握手，以在该第二线路上建立第二连接。
[0041]步骤206、通过该第二连接将缓存的该数据请求报文转发给该对端设备。结束。
[0042]步骤207、通过该第一连接将该数据请求报文转发给该对端设备。结束。
[0043]步骤208、判断该数据请求报文的业务类型是否为关键业务类型。若该数据请求报文的业务类型为关键业务类型，则执行步骤205 ;若该数据请求报文的业务类型为非关键业务类型，则执行步骤207。在本实施例中，举例来说，关键业务类型可以指:办公0A、邮件等。非关键业务类型可以指:迅雷、PSSTREAM等。另外，还需要说明的是，哪些为关键业务，哪些为非关键业务，在不同的场景下，可能不太一样，例如:在网吧的环境下，游戏可以为关键业务，而在企业的环境下，游戏可能则为非关键业务，这个取决于用户的配置。一般的，配置走光纤线路的业务，统称为关键业务；而走ADSL线路的业务，则为非关键业务。
[0044]另外，在本实施例中，当该数据请求报文的协议为HTTP协议或者HTTPs协议时，其对应的分流策略可以采用HTTP应用分流或HTTPs应用分流，即可以根据该数据请求报文的业务类型，查询预先配置的配置信息，判断该数据请求报文是否需要进行分流处理。当该数据请求报文的协议不是HTTP协议和HTTPs协议时，其对应的分离策略可以采用TCP应用分流，即根据该数据请求报文的业务类型，判断该数据请求报文是否需要进行分流处理。
[0045]在本实施例中，通过第一线路，为内网用户设备和对端设备转发该数据流的握手报文，以实现内网用户设备和对端设备的三次握手，并在第一线路上建立第一连接，在接收内网用户设备发送的数据流的第一个数据请求报文时，可以根据该数据请求报文的业务类型是否为关键业务，判断该数据请求报文是否需要进行分流处理，若需要则缓存该数据请求报文，并通过第二线路与对端设备重新进行三次握手，以在第二线路上建立第二连接，以通过该第二连接将缓存的数据请求报文转发给对端设备。由于通过第二线路，重新与对端设备进行三次握手，以建立第二线路上的第二连接，再对缓存的数据请求报文通过第二连接转发给对端设备，因此保证了在数据流重新选路时不会出现断流问题，从而有效地解决了现有技术中基于DPI技术对TCP流进行分流而造成的断流问题。同时，由于可以根据数据请求报文的协议类型对应的分流策略，判断该数据请求报文是否进行分流，因此，精确高效地实现了将指定的应用业务的数据流分流到对应的线路。
[0046]图3为本发明数据流的处理方法的又一个实施例的流程示意图，在上述图2所示实施例的基础上，步骤201之后，该方法还包括:
[0047]步骤209、跟踪该数据流的握手报文的序号信息，并记录该第一连接的属性信息。
[0048]在本实施例中，该第一连接的属性信息可以包括:扩大因子和TCP选项等。
[0049]则步骤205的一种具体实现方式为:
[0050]步骤205a、缓存该数据请求报文，并根据该数据流的握手报文的序号信息，以及该第一连接的属性信息，通过第二线路与该对端设备重新进行三次握手，以在该第二线路上建立该第二连接。
[0051]可选地，根据该数据流的握手报文的序号信息，以及该第一连接的属性信息，通过第二线路与该对端设备重新进行三次握手，以在该第二线路上建立该第二连接的一种具体实现方式为:
[0052]通过该第二线路，向该对端设备发送SYN连接请求报文，该SYN连接请求报文包括该数据流的握手报文的序号信息，以及该第一连接的属性信息；
[0053]接收该对端设备返回的应答数据包，以及携带有该对端设备的初始序号的SYN报文；
[0054]通过该第二线路，向该对端设备发送确认报文，以完成与该对端设备的三次握手。
[0055]其中，该对端设备的初始序号为第二连接的初始序号。
[0056]图4为本发明数据流的处理方法所基于的网络架构示意图，如图4所示，该网络架构包括:内网用户设备11、出口设备12和对端设备13。其中，内网用设备11与出口设备12相连接，出口设备12通过第一线路、多条第二线路和互联网与对端设备12相连接。对端设备13可以为服务器，可以包括专门用于网页、游戏和视频等服务的服务器。另外，第一线路可以为光纤，用于传输对网络传输时延、抖动等特性敏感的关键应用。第二线路可以为ADSL线路，用于传输P2P等下载应用。
[0057]图5为本发明数据流的处理方法的又一个实施例的信令流程图，在上述图4所示实施例的基础上，如图5所示,该方法包括:
[0058]步骤301、内网用户设备向出口设备发送SYN请求报文。
[0059]在本实施例中，内网用户设备发起TCP连接请求，请求以一个SYN请求报文为开始，以标记一个TCP连接开始并请求回应一个三次握手协议过程。
[0060]其中，该SYN请求报文的序列号为CSEQ，该序列号CESQ用以表示用户报文的初始序列。
[0061]步骤302、出口设备通过第一线路，将接收到的该SYN请求报文转发给对端设备，以建立第一线路的第一连接，并记录内网用户设备对应的初始序列号，以及第一连接的属性信息。
[0062]本实施例中，记录第一连接的属性信息可以包括:记录时间戳，窗口扩大因子，SACK以及最大报文长度等信息。
[0063]步骤303、出口设备通过第一线路接收对端设备发送的第一请求回应报文，同时接收对端设备发起的SYN的SYN+ACK报文，并记录对端设备的初始序列号。
[0064]其中，该第一请求回应报文的序列号为CSEQ+1，该CSEQ+1用以表示对应于初始序列的应答序列。该SYN+ACK报文的序列号为DSEQ，该序列号DSEQ用以表示对端设备的初始序列号。
[0065]步骤304、出口设备将该第一请求回应报文和SYN+ACK报文转发给内网用户设备。
[0066]步骤305、内网用户设备发送第二请求回应报文给出口设备，以供出口设备通过第一线路将该第二请求回应报文转发给对端设备。
[0067]其中，该第二请求回应报文的序列号DSEQ+1,该序列号DSEQ+1用以表不对应于对端设备的初始序列号的应答序列。
[0068]在本实施例中，上述三个握手报文均经过接口 1，即默认路由(第一线路)进行转发。
[0069]步骤306、内网用户设备向出口设备发送数据请求报文。
[0070]在本实施例中，该数据请求报文的序列号为CSEQ+1，且假设长度为11。
[0071]步骤307、出口设备接收该数据请求报文，并根据该数据请求报文的业务类型，在判断出该数据请求报文需要进行分流处理时，缓存该数据请求报文。
[0072]步骤308、根据记录的内网用户设备对应的初始序列号，对端设备的初始序列号以及第一连接的属性信息，通过该第二线路向对端设备发起SYN连接请求报文。
[0073]在本实施例中，需要说明的是，该SYN连接请求报文使用了内网用户设备原先发起的请求初始序列号CSEQ，且目的是为了后面进行序号空间对其是所必须的TCP header数据转换时，尽可能减少转换计算。
[0074]步骤309、对端设备接收该SYN连接请求报文，并返回应答数据包，同时发起SYN报文以完成TCP的握手列程。
[0075]其中，该应答数据包的序列号为CSEQ+1。该SYN报文的序列号为SSEQ，该序列号SSEQ用于表示内网用户设备发起连接中对端设备的初始序列号。
[0076]在本实施例中，对端设备的初始序号SSEQ和出口设备提供给内网用户设备的对端的初始序号DSEQ是不一样的。
[0077]步骤310、出口设备截获该SYN报文，并通过第二线路，向对端设备发送确认报文，完成和对端设备的三次握手，以建立第二线路上的第二连接。
[0078]在本实施例中，该第二连接对应的接口为接口 2。
[0079]步骤311、出口设备对缓存的数据请求报文进行转换处理，并将转换处理后的数据请求报文通过第二连接发送给对端设备。
[0080]在本实施例中，将数据请求报文中的确认序列号DSEQ+1转换为SSEQ+1。
[0081]步骤312、对端设备响应该数据请求报文，并返回第一回应数据报文，并回送第一应答报文。其中，该第一回应数据报文的序列号为SSEQ+1，且假设长度为12。第一应答报文的序列号为CSEQ+11+1。
[0082]步骤313、出口设备接收回应数据报文后，对该第一回应数据报文中的序列号SSEQ+1转换成DSEQ+1，并将转换后的第一回应数据报文发送给内网用户设备。
[0083]步骤314、对端设备响应该数据请求报文，并返回第二回应数据报文，并回送第二应答报文。其中，该第二回应数据报文的序列号为SSEQ+12+1，且假设长度为13。第二应答报文的序列号为CSEQ+11+1。
[0084]步骤315、出口设备接收第二回应数据报文后，对该第二回应数据报文中序列号SSEQ+12+1转换成DSEQ+12+1，并将转换后的第二回应数据报文发送给内网用户设备。
[0085]步骤316、内网用户设备对接收到的第一回应数据报文和第二回应数据报文进行应答，并将应答报文发送给出口设备。该应答报文的序列号为DSEQ+12+13+1。
[0086]步骤317、出口设备将该应答报文中的序列号DSEQ+12+13+1转换为SSEQ+12+13+1，并将转换后的应答报文发送给对端设备。
[0087]在本实施例中，需要说明的是，出口设备需要对报文进行序号转换，以保持双发的序号空间连续。在上述的过程中，由于只是对报文的二至四层进行修改，并未改动应用层数据，也没有对报文进行拷贝处理，因此，有效地提高了效率。
[0088]在本实施例中，以电驴发起一条TCP流为例，假设未实现电驴的协议分流，则采用TCP应用分流，即在三次握手报文后的第一请求报文(即上述的数据请求报文)识别出具体业务类型，并根据该业务类型判断该TCP流是否需要应用分流。如果该TCP流需要应用分流，则从相应应用路由的通路出发，即出口设备伪装为内网用户设备，同对端设备建立TCP连接新建流，后续并通过新建流和对端设备实现数据交互。另外。该TCP应用分流判定分流时刻为第一请求报文达到出口设备的时刻，当不需要进行应用分流时，即该业务类型为关键业务时，则不进行分流处理。
[0089]图6为本发明数据流的处理方法的还一个实施例的报文交互流程图，在上述图5所示实施例的基础上，如图6所示,该方法包括:
[0090]步骤401、内网用户设备向出口设备发送SYN请求报文。
[0091 ] 在本实施例中，内网用户设备发起TCP连接请求，请求以一个SYN请求报文为开始，以标记一个TCP连接开始并请求回应一个三次握手协议过程。
[0092]其中，该SYN请求报文的序列号为CSEQ，该CESQ用以表示用户报文的初始序列。
[0093]步骤402、出口设备通过第一线路，将接收到的该SYN请求报文转发给对端设备，以在第一线路上建立第一连接，并记录内网用户设备对应的初始序列号，以及第一连接的属性信息。
[0094]本实施例中，记录第一连接的属性信息可以包括:记录时间戳，窗口扩大因子，SACK以及最大报文长度等信息。
[0095]步骤403、出口设备通过第一线路接收对端设备发送的第一请求回应报文，同时接收对端设备发起的SYN的SYN+ACK报文，并记录对端设备的初始序列号。[0096]其中，该第一请求回应报文的序列号为CSEQ+1，该CSEQ+1用以表示对应于初始序列的应答序列。该SYN+ACK报文的序列号为DSEQ，该DSEQ用以表示对端设备的初始序列号。
[0097]步骤404、出口设备将该请求回应报文和SYN+ACK报文转发给内网用户设备。
[0098]步骤405、内网用户设备发送第二请求回应报文给出口设备，以供出口设备通过第一线路将该第二请求回应报文转发给对端设备。
[0099]其中，该第二请求回应报文的序列号为DSEQ+1，该DSEQ+1用以表示对应于对端设备的初始序列号的应答序列。
[0100]在本实施例中，上述三个握手报文均经过接口 1，即默认路由(第一线路)进行转发。
[0101]步骤406、内网用户设备向出口设备发起HTTP的第一个GET请求报文。
[0102]步骤407、出口设备根据该第一 GET请求报文的业务类型和配置信息，若判断出该第一 GET请求报文不需要进行分流处理，则通过第一连接将该第一 GET请求报文转发给对端设备。
[0103]步骤408、内网用户设备向出口设备发起HTTP的第二个GET请求报文。
[0104]其中，该第二 GET请求报文的序列号为CSEQ+X+1，其确认序号为DSEQ+Y+1。
[0105]步骤409、出口设备根据第二 GET请求报文的业务类型，查询预先配置的配置信息，若判断该第二 GET请求报文需要进行分流，则缓存该第二 GET请求报文。
[0106]在本实施例中，举例来说，以第一线路为光纤线路，第二线路为ADSL线路为例。当配置信息为在P2P下载时，需要通过ADSL线路转发的配置信息时，出口设备识别该第二GET请求报文的业务类型，识别出该业务类型为P2P下载业务类型时，则根据上述配置信息，判断出该第二 GET请求报文需要进行分流。
[0107]步骤410、根据记录的内网用户设备对应的初始序列号，对端设备的初始序列号以及第一连接的属性信息，通过该第二线路向对端设备发起SYN连接请求报文。
[0108]在本实施例中，需要说明的是，该SYN连接请求报文使用了内网用户设备原先发起的请求初始序列号CSEQ，且目的是为了后面进行序号空间对其是所必须的TCP header数据转换时，尽可能减少转换计算。
[0109]步骤411、对端设备接收该SYN连接请求报文，并返回应答数据包，同时发起SYN报文以完成TCP的握手列程。
[0110]其中，该应答数据包的序列号为CSEQ+1。该SYN报文的序列号为SSEQ。
[0111]在本实施例中，对端设备的初始序号SSEQ和出口设备提供给内网用户设备的对端的初始序号DSEQ是不一样的。
[0112]步骤412、出口设备截获该SYN报文，并通过第二线路，向对端设备发送确认报文，完成和对端设备的三次握手，以在第二线路上建立第二连接。
[0113]在本实施例中，该第二线路对应的接口为接口 2。
[0114]步骤413、出口设备对缓存的第二 GET请求报文进行转换处理，并将转换处理后的第二 GET请求报文通过第二连接发送给对端设备。
[0115]步骤414、对端设备响应该第二 GET请求报文，并返回回应数据报文，并回送应答报文。其中，该回应数据报文的序列号为SSEQ+1，且假设长度为12。应答报文的序列号为CSEQ+X+11+1 ο
[0116]步骤415、出口设备将该回应数据报文中的序列号SSEQ+1转换为DSEQ+Y+1，并将转换后的回应数据报文发送给内网用户设备。
[0117]需要说明的是，现有技术中，在访问一个包含有许多图像的网页文件的整个过程中包含了多次请求和响应，每次请求和响应都需要建立一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。而HTTP 1.1支持持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输。因此，一条HTTP1.1连接，根据其请求的数据不同，其在不同时刻可能属于不同业务，比如:打开网页建立的HTTP1.1连接可能会有请求Applet, JavaScript,下载flash等。
[0118]在本实施例中，以一条光纤线路(即上述第一线路)和两条ADSL线路(即上述第二线路)，分别为ADSLl和ADSL2为例，详细介绍本实施例的技术方案。在上述HTTP1.1连接中，当上述第二 GET请求报文的业务类型为网页浏览，配置信息为网页浏览时可以通过ADSLl转发时，需要进行分流，即重新进行三次握手，建立第二线路(ADSL1 )，将该第二 GET请求报文转发给对端设备。如果用户内网设备还发送第三GET请求报文或者HTTP请求报文，其类型为P2P下载，且配置信息为P2P时可以通过ADSL2转发时，需要进行分流处理，即重新进行三次握手，建立第二线路(ADSL2)，将该第三GET请求报文或者HTTP请求报文转发给对端设备。
[0119]因此，通过采用上述HTTP应用分流，因此可以将HTTP1.1连接中普通的网页浏览业务和下载业务分成两条流，将流量分到合适的线路上。
[0120]还需要说明的是，所有报文的处理过程中并不使用缓冲区缓存该报文并上传到用户空间，而是直接进行转换后发送，从而有效地避免了应用级代理效率低下的问题。
[0121]本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括:R0M、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
[0122]图7为本发明数据流的处理装置的一个实施例的结构示意图，如图7所示，本实施例的装置包括:连接管理模块21、接收模块22、协议分发模块23、分流处理模块24和发送模块25 ;其中，连接管理模块21用于通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现该内网用户设备与该对端设备的三次握手，并在该第一线路上建立第一连接；接收模块22用于接收该内网用户设备发送的该数据流的第一个数据请求报文；协议分发模块23用于获取与该数据请求报文的协议类型对应的分流策略；分流处理模块24用于根据该分流策略，判断该数据请求报文是否需要进行分流处理，若判断出该数据请求报文需要进行分流处理，则缓存该数据请求报文；连接管理模块21还用于通过第二线路与该对端设备重新进行三次握手，以在该第二线路上建立第二连接；发送模块25用于通过该第二连接将缓存的该数据请求报文转发给该对端设备。
[0123]本实施例的数据流的处理装置可以执行图1所示方法实施例的技术方案，其实现原理相类似，此处不再赘述。
[0124]在本实施例中，通过第一线路，为内网用户设备和对端设备转发该数据流的握手报文，以实现内网用户设备和对端设备的三次握手，并在第一线路上建立第一连接，在接收内网用户设备发送的数据流的第一个数据请求报文时，可以根据获取的与该数据请求报文的协议类型对应的分流策略，若判断出该数据请求报文需要进行分流处理，则缓存该数据请求报文，并通过第二线路与对端设备重新进行三次握手，以在第二线路上建立第二连接，以通过该第二连接将缓存的数据请求报文转发给对端设备。由于通过第二线路，重新与对端设备进行三次握手，以建立第二线路上的第二连接，在对缓存的数据请求报文通过第二连接转发给对端设备，因此保证了在数据流重新选路时不会出现断流问题，从而有效地解决了现有技术中基于DPI技术对TCP流进行分流而造成的断流问题。
[0125]图8为本发明数据流的处理装置的另一个实施例的结构示意图，在上述图7所示实施例的基础上，如图8所示，分流处理模块24包括:应用识别单元241和第一分流处理单元242，其中，应用识别单元241用于获取与该数据请求报文的业务类型；第一分流处理单元242用于判断该数据请求报文的业务类型是否为关键业务类型，若该数据请求报文的业务类型为关键业务类型，则该数据请求报文需要进行分流处理；若该数据请求报文的业务类型为非关键业务类型，则该数据请求报文不需要进行分流处理。
[0126]进一步的，分流处理模块24还包括:配置管理单元243和第二分流处理单元244 ；其中，配置管理单元243用于存储预先配置的配置信息；其中，该配置信息包括业务类型和对应的线路；第二分流处理单元244用于根据该数据请求报文的业务类型，查询该配置管理单元243中的预先配置的配置信息，判断该数据请求报文中的数据类型对应的线路是否为该第一线路；若该数据请求报文中的数据类型对应的线路不是该第一线路，则该数据请求报文需要进行分流处理，且该第二线路为该配置信息中该数据请求报文的业务类型的对应的线路；若该数据请求报文中的数据类型对应的线路是该第一线路，则该数据请求报文不需要进行分流处理。
[0127]可选地，该装置还包括:流跟踪模块26用于跟踪该数据流的握手报文的序号信息，并记录该第一连接的属性信息。
[0128]可选地，连接管理模块21具体用于根据该数据流的握手报文的序号信息，以及该第一连接的属性信息，通过第二线路与该对端设备重新进行三次握手，以在该第二线路上建立该第二连接。
[0129]可选地，发送模块25还用于若该分流处理模块24判断出该数据请求报文不需要进行分流处理，则通过该第二连接将缓存的该数据请求报文转发给该对端设备。
[0130]本实施例的数据流的处理装置可以执行图2、图3、图5或图6所示方法实施例的技术方案，其实现原理相类似，此处不再赘述。
[0131]最后应说明的是:以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。
【权利要求】
1.一种数据流的处理方法，其特征在于，包括: 通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现所述内网用户设备与所述对端设备的三次握手，并在所述第一线路上建立第一连接； 接收所述内网用户设备发送的所述数据流的第一个数据请求报文； 获取与所述数据请求报文的协议类型对应的分流策略，并根据所述分流策略，判断所述数据请求报文是否需要进行分流处理，若判断出所述数据请求报文需要进行分流处理，则缓存所述数据请求报文，并通过第二线路与所述对端设备重新进行三次握手，以在所述第二线路上建立第二连接； 通过所述第二连接将缓存的所述数据请求报文转发给所述对端设备。
2.根据权利要求1所述的数据流的处理方法，其特征在于，当所述数据请求报文的协议类型不为HTTP协议类型和HTTPs协议类型时，所述根据所述分流策略，判断所述数据请求报文是否需要进行分流处理，包括: 获取所述数据请求报文的业务类型，并判断所述数据请求报文的业务类型是否为关键业务类型； 若所述数据请求报文的业务类型为关键业务类型，则所述数据请求报文需要进行分流处理； 若所述数据请求报文的业务类型为非关键业务类型，则所述数据请求报文不需要进行分流处理。
3.根据权利要求1所述的数据流的处理方法，其特征在于，当所述数据请求报文的协议类型为HTTP协议类型或者HTTPs协议类型时，所述根据所述分流策略，判断所述数据请求报文是否需要进行分流处理，包括: 获取所述数据请求报文的业务类型，并根据所述数据请求报文的业务类型，查询预先配置的配置信息，判断所述数据请求报文中的数据类型对应的线路是否为所述第一线路；其中，所述配置信息包括业务类型和对应的线路； 若所述数据请求报文中的数据类型对应的线路不是所述第一线路，则所述数据请求报文需要进行分流处理，且所述第二线路为所述配置信息中所述数据请求报文的业务类型的对应的线路； 若所述数据请求报文中的数据类型对应的线路是所述第一线路，则所述数据请求报文不需要进行分流处理。
4.根据权利要求1至3任一所述的数据流的处理方法，其特征在于，所述接收所述内网用户设备发送的所述数据流的第一个数据请求报文之前，所述方法还包括: 跟踪所述数据流的握手报文的序号信息，并记录所述第一连接的属性信息。
5.根据权利要求4所述的数据流的处理方法，其特征在于，所述通过第二线路与所述对端设备重新进行三次握手，以在所述第二线路上建立第二连接，包括: 根据所述数据流的握手报文的序号信息，以及所述第一连接的属性信息，通过第二线路与所述对端设备重新进行三次握手，以在所述第二线路上建立所述第二连接。
6.根据权利要求5所述的数据流的处理方法，其特征在于，所述根据所述数据流的握手报文的序号信息，以及所述第一连接的属性信息，通过第二线路与所述对端设备重新进行三次握手，包括:通过所述第二线路，向所述对端设备发送SYN连接请求报文，所述SYN连接请求报文包括所述数据流的握手报文的序号信息，以及所述第一连接的属性信息； 接收所述对端设备返回的应答数据包，以及携带有所述对端设备的初始序号的SYN报文； 通过所述第二线路，向所述对端设备发送确认报文，以完成与所述对端设备的三次握手。
7.根据权利要求1至3任一所述的数据流的处理方法，其特征在于，还包括: 若判断出所述数据请求报文不需要进行分流处理，则通过所述第一连接将所述数据请求报文转发给所述对端设备。
8.一种数据流的处理装置，其特征在于，包括； 连接管理模块，用于通过第一线路，为内网用户设备和对端设备转发数据流的握手报文，以实现所述内网用户设备与所述对端设备的三次握手，并在所述第一线路上建立第一连接； 接收模块，用于接收所述内网用户设备发送的所述数据流的第一个数据请求报文； 协议分发模块，用于获取与所述数据请求报文的协议类型对应的分流策略； 分流处理模块，用于根据所述分流策略，判断所述数据请求报文是否需要进行分流处理，若判断出所述数据请求报文需要进行分流处理，则缓存所述数据请求报文； 所述连接管理模块还用于通过第二线路与所述对端设备重新进行三次握手，以在所述第二线路上建立第二连接； 发送模块，用于通过所述第二连接将缓存的所述数据请求报文转发给所述对端设备。
9.根据权利要求8所述的数据流的处理装置，其特征在于，当所述数据请求报文的协议类型不为HTTP协议类型和HTTPs协议类型时，所述分流处理模块包括: 应用识别单元，用于获取所述数据请求报文的业务类型； 第一分流处理单元，用于判断所述数据请求报文的业务类型是否为关键业务类型，若所述数据请求报文的业务类型为关键业务类型，则所述数据请求报文需要进行分流处理；若所述数据请求报文的业务类型为非关键业务类型，则所述数据请求报文不需要进行分流处理。
10.根据权利要求8所述的数据流的处理装置，其特征在于，当所述数据请求报文的协议类型为HTTP协议类型或者HTTPs协议类型时，所述分流处理模块包括: 应用识别单元，用于获取所述数据请求报文的业务类型； 配置管理单元，用于存储预先配置的配置信息；其中，所述配置信息包括业务类型和对应的线路； 第二分流处理单元，用于根据所述数据请求报文的业务类型，查询所述配置管理单元中的预先配置的配置信息，判断所述数据请求报文中的数据类型对应的线路是否为所述第一线路；若所述数据请求报文中的数据类型对应的线路不是所述第一线路，则所述数据请求报文需要进行分流处理，且所述第二线路为所述配置信息中所述数据请求报文的业务类型的对应的线路；若所述数据请求报文中的数据类型对应的线路是所述第一线路，则所述数据请求报文不需要进行分流处理。
11.根据权利要求8至10任一所述的数据流的处理装置，其特征在于，还包括；流跟踪模块，用于跟踪所述数据流的握手报文的序号信息，并记录所述第一连接的属性信息。
12.根据权利要求11所述的数据流的处理装置，其特征在于，所述连接管理模块具体用于根据所述数据流的握手报文的序号信息，以及所述第一连接的属性信息，通过第二线路与所述对端设备重新进行三次握手，以在所述第二线路上建立所述第二连接。
13.根据权利要求8至10任一所述的数据流的处理装置，其特征在于，所述发送模块还用于若所述分流处理模块判断出所述数据请求报文不需要进行分流处理，则通过所述第二连接将缓存的所述数据请求报 文转发给所述对端设备。
【文档编号】H04L29/06GK103475593SQ201310364694
【公开日】2013年12月25日 申请日期:2013年8月20日 优先权日:2013年8月20日
【发明者】刘凌峰 申请人:北京星网锐捷网络技术有限公司