CN108337183A - 一种数据中心网络流负载均衡的方法 - Google Patents

Abstract

本发明公开了一种数据中心网络流负载均衡的方法，其利用网络设备中广泛部署的ECMP方法，在主机发送方和主机接收方分别对同一条网络流中的每个数据包进行处理，使包均匀分散在等价的不同链路上，以实现更细粒度的负载均衡；所述的主机发送方的处理方法是为每个包生成随机数，以此修改唯一确定元组，并把随机数嵌入在包头的某个字段中；所述的主机接收方的处理方法是从包头的字段中提取随机数，并把唯一确定元组还原。本发明能有效地缓解ECMP方法在不同大小的网络流同时共存时或发生哈希碰撞时负载均衡能力较差的缺陷，从而达到最佳的负载均衡效果，具有实现方法简单、运行高效的特点。

Description

一种数据中心网络流负载均衡的方法

技术领域

本发明属于计算机网络领域，尤其涉及一种能使计算机数据中心部署的网络流负载均衡的方法，具体地说是一种数据中心网络流负载均衡的方法。

背景技术

随着社会的不断发展，数据中心已经成为了我们日常生活中不可或缺的一部分。数据中心为Web应用和手机应用提供了后端支撑，服务了云计算、社交、支付、娱乐等领域。网络流是指使用网络协议栈(通常是TCP/IP协议栈)传输的数据包序列，每条流可以通过数据包中的某个元组唯一确定，最常见的元组是(源IP，目的IP，源端口，目的端口)。网络流负载均衡一直是数据中心的重要问题之一，因为数据中心内有为各种不同应用服务的服务器，它们对网络流的需求经常不一致，比如搜索、直播要求低时延；存储备份要求高吞吐量。所谓负载均衡就是这些应用都能得到适量的网络服务，不会出现应用过多占用网络资源，或者得不到网络资源而饥饿的情况。

目前最常用的网络流负载均衡方法是“等价多路径路由”(ECMP，Equal-costMulti-path Routing)，这里简要介绍其主要思想。由于数据中心网络通常是“胖树”(FatTree)结构，两台服务器之间存在多条代价相同而路径不同的通信链路，它们有互相冗余备份的关系。如果把这两台服务器之间的网络流比较均匀的分散在这些链路中，即不会出现某条链路过载而其他链路空闲的现象，就达到了负载均衡的目的。ECMP采用的均匀分散的方法是哈希算法。哈希算法的基本思想是把一个任意大小的输入数据映射到固定大小的输出范围中。如果把某条网络流的唯一确定元组作为哈希算法的输入，可用发送链路的全体编码组成的集合作为哈希算法的输出范围，那么就形成了一种映射关系。只要所选的哈希算法的性质足够好，就能保证不同的网络流均匀分散在各个链路中。ECMP是一种主动的、无状态的方法，可以在路由器、交换机中逐跳(per-hop)运行，实现简单，因此得到广泛应用。

ECMP方法存在两个主要问题。其一，如果网络流大小不一，则负载均衡的效果会受到影响。由于ECMP方法针对不同的网络流做负载均衡，假如一条流传输量大而另一条流传输量小，即使它们分散在不同链路上，显然也是不均衡的。其二，哈希碰撞问题。发生哈希碰撞时，不同的网络流不能被均匀分散。这个问题尽管可以靠选择性质更好的哈希算法缓解，但是并不能根除。

网络流负载均衡的实现往往需要依靠网络数据包处理技术，比如提取、修改数据包包头中的字段信息以影响包的转发链路。目前常用的数据包处理方法有三种：在虚拟机监控程序中；在虚拟交换机Open vSwitch中；在Linux内核网络协议栈中。网卡卸载(offloading)是当前数据中心网络中广泛应用的一个技术。当网卡开启这个功能时，Linux内核网络协议栈最多能一次性处理近64KB大小的数据包，而不是传统的最大报文段长度(MSS，Max Segment Size)1460字节的包。分包和计算校验码将交给网卡完成，减轻了CPU的负载，有利于整个系统在高速数据中心网络中的可扩展性。

如果把一条网络流按某种方式分割成各个小段，每个小段都可以称为原网络流的一条子流(sub-flow)。在本发明中，将开启网卡卸载后Linux内核网络协议栈一次性处理的大包以及后续网卡将这个大包分割后的数个包称作子流。

发明内容

本发明所要解决的技术问题是针对上述现有技术现状，而提供能在很大程度上缓解当不同大小的网络流同时共存时或发生哈希碰撞时的缺陷，且具备在数据中心中实际部署的能力的一种数据中心网络流负载均衡的方法。

为实现上述技术目的，本发明采取的技术方案为：

一种数据中心网络流负载均衡的方法，其特征是：利用网络设备中广泛部署的ECMP方法，在主机发送方和主机接收方分别对同一条网络流中的每个数据包进行处理，使包均匀分散在等价的不同链路上，以实现更细粒度的负载均衡；所述的主机发送方的处理方法是为每个包生成随机数，以此修改唯一确定元组，并把随机数嵌入在包头的某个字段中；所述的主机接收方的处理方法是从包头的字段中提取随机数，并把唯一确定元组还原。

为优化上述技术方案，采取的具体措施还包括：

上述的主机发送方的处理方法具体包括以下步骤：

A1)利用Linux内核网络协议栈获取待发送的数据包；

A2)获取数据包的源端口号和目的端口号；

A3)生成随机数；

A4)重新计算新的源端口号和新的目的端口号；

A5)将生成随机数、新的源端口号和新的目的端口号写回数据包。

上述的主机接收方的处理方法具体包括以下步骤：

B1)利用Linux内核网络协议栈获取待接收的数据包；

B2)获取写回数据包的生成随机数、新的源端口号和新的目的端口号；

B3)计算并还原原来的源端口号和目的端口号；

B4)将还原后的源端口号和目的端口号写回数据包。

上述的步骤A1)中利用Linux内核网络协议栈获取待发送的数据包，获取待发送的数据包需要自行实现Netfilter框架的NF_INET_LOCAL_IN钩子的回调函数；得到的数据包是以sk_buff结构体的形式表现的。

上述的步骤A2)中如果传输层协议是TCP，则通过tcp_hdr函数获取指向skbuff中TCP首部的指针，根据TCP首部tcphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号；

如果传输层协议是UDP，则通过udp_hdr函数获取指向skbuff中UDP首部的指针，根据UDP首部udphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号；

上述的步骤A3)中使用Linux内核网络协议栈提供的真随机数产生函数get_random_bytes，它可以指定获得的随机数占用存储空间的字节数。

上述的步骤A4)中新的源端口号和新的目的端口号的计算方法是取随机数的低6位bit，分别和两个端口号的低6位做异或操作得到新的两个端口号，两个端口号将在有效范围[0,65535]内发生变化。

上述的步骤A5)中如果传输层协议是TCP，则把新的源端口号和新的目的端口号写回tcphdr结构体的source字段和dest字段即可；生成随机数放在包首部IP头的区分服务字段里。

如果传输层协议是UDP，则把新的源端口号和新的目的端口号写回udphdr结构体的source字段和dest字段即可；生成随机数放在包首部IP头的区分服务字段里。

上述的步骤B1)中获取待接收的数据包为在Linux内核网络协议栈中，自行实现Netfilter框架的NF_INET_LOCAL_OUT钩子的回调函数；

上述的步骤B2)中如果传输层协议是TCP，则通过tcp_hdr函数获取指向skbuff中TCP首部的指针，根据TCP首部tcphdr结构体的定义分别用source字段和dest字段获取数据包的新的源端口号和新的目的端口号；通过ip_hdr函数获取指向skbuff中IP首部的指针，再由IP首部iphdr结构体tos字段获取随机数；

如果传输层协议是UDP，则通过udp_hdr函数获取指向skbuff中UDP首部的指针，根据UDP首部udphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号；通过ip_hdr函数获取指向skbuff中IP首部的指针，再由IP首部iphdr结构体tos字段获取随机数；

上述的步骤B3)中将新的源端口号和新的目的端口号两个新的端口号的低6位与随机数再做一次异或即可计算并还原原来的源端口号和目的端口号；

上述的步骤B4)中如果传输层协议是TCP，则还原后的源端口号和目的端口号写回tcphdr结构体的source字段和dest字段即可。

如果传输层协议是UDP，则还原后的源端口号和目的端口号写回udphdr结构体的source字段和dest字段即可。

与现有技术相比，本发明充分利用了网络设备中广泛部署的ECMP方法，路由器、交换机发现同一条流的各个包或子流的唯一确定元组是不同的，将把它们均匀分散在等价的不同链路中。ECMP方法处理大小不一的网络流的缺陷将被缓解，因为每条流都被分割成细粒度的单元，原始流大小不再重要。ECMP方法处理哈希碰撞的缺陷也将被缓解，因为本发明不存在流粒度的哈希碰撞，只存在细粒度单元的哈希碰撞，碰撞即使发生，产生的坏处也大大弱于原始ECMP方法。

唯一确定元组在主机端发送方被修改，在接收方被还原，这样应用层协议不会感知到流的唯一确定元组曾经发生过变化，因此无需做任何修改。

通过采用以上技术方案，本发明具有如下优点：

1.缓解ECMP方法在不同大小的网络流同时共存时或发生哈希碰撞时负载均衡能力较差的缺陷，达到更好的负载均衡效果。

2.软件实现简单，运行效率高。

3.充分利用已经大规模部署在网络设备中的ECMP方法，只需对主机端底层软件做简单升级，无需修改主机端应用和网络设备，具备在真实数据中心中部署的可行性。

4.由于在设计中考虑了网卡卸载，本发明可运行在10Gbps、25Gbps甚至更高带宽的数据中心网络中，具有可扩展性。

附图说明

图1为本发明在Linux内核网络协议栈的实施位置。

图2为本发明在主机发送方的实施流程图。

图3为本发明在主机接收方的实施流程图。

具体实施方式

以下结合附图对本发明的实施例作进一步详细描述。

以下本发明提到的“包”或“子流”通常是可以互换的两个词，都是网络流分割后更细粒度的单元。

如果数据中心中的设备都开启了网卡卸载，NF_INET_LOCAL_IN和NF_INET_LOCAL_OUT钩子的自定义回调函数通常获取到的是接近64KB的大包，可以认为是对子流做负载均衡；如果为了兼容老旧的设备没开启网卡卸载，则是对包做负载均衡。网卡卸载只影响本发明在高速数据中心网络的可扩展性，并不影响核心原理。

图1至图3为本发明的工作原理示意图，如图所示，本发明的一种数据中心网络流负载均衡的方法，利用网络设备中广泛部署的ECMP方法，在主机发送方和主机接收方分别对同一条网络流中的每个数据包或子流进行处理，使包均匀分散在等价的不同链路上，以实现更细粒度的负载均衡；主机发送方的处理方法是为每个包生成随机数，以此修改唯一确定元组，并把随机数嵌入在包头的某个字段中；所述的主机接收方的处理方法是从包头的字段中提取随机数，并把唯一确定元组还原。

本发明的主机发送方的处理方法具体包括以下步骤：

A1)利用Linux内核网络协议栈获取待发送的数据包；

A2)获取数据包的源端口号和目的端口号；

A3)生成随机数；

A4)重新计算新的源端口号和新的目的端口号；

A5)将生成随机数、新的源端口号和新的目的端口号写回数据包。

主机接收方的处理方法具体包括以下步骤：

B1)利用Linux内核网络协议栈获取待接收的数据包；

B2)获取写回数据包的生成随机数、新的源端口号和新的目的端口号；

B3)计算并还原原来的源端口号和目的端口号；

B4)将还原后的源端口号和目的端口号写回数据包。

本发明的步骤A1)中利用Linux内核网络协议栈获取待发送的数据包，获取待发送的数据包需要自行实现Netfilter框架的NF_INET_LOCAL_IN钩子的回调函数；得到的数据包是以sk_buff结构体的形式表现的。

本发明的步骤A2)中如果传输层协议是TCP，则通过tcp_hdr函数获取指向skbuff中TCP首部的指针，根据TCP首部tcphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号；

如果传输层协议是UDP，则通过udp_hdr函数获取指向skbuff中UDP首部的指针，根据UDP首部udphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号。

本发明的步骤A3)中使用Linux内核网络协议栈提供的真随机数产生函数get_random_bytes，它可以指定获得的随机数占用存储空间的字节数。

本发明的步骤A4)中新的源端口号和新的目的端口号的计算方法是取随机数的低6位bit，分别和两个端口号的低6位做异或操作得到新的两个端口号，两个端口号将在有效范围[0,65535]内发生变化。

本发明的步骤A5)中，

如果传输层协议是TCP，则将新的源端口号和新的目的端口号写回tcphdr结构体的source字段和dest字段即可；生成随机数放在包首部IP头的区分服务字段里。

如果传输层协议是UDP，则将新的源端口号和新的目的端口号写回udphdr结构体的source字段和dest字段即可；生成随机数放在包首部的附加字段里或放在IP头的区分服务字段里。

本发明的步骤B1)中获取待接收的数据包为在Linux内核网络协议栈中，自行实现Netfilter框架的NF_INET_LOCAL_OUT钩子的回调函数；

本发明的步骤B2)中如果传输层协议是TCP，则通过tcp_hdr函数获取指向skbuff中TCP首部的指针，根据TCP首部tcphdr结构体的定义分别用source字段和dest字段获取数据包的新的源端口号和新的目的端口号；通过ip_hdr函数获取指向skbuff中IP首部的指针，再由IP首部iphdr结构体tos字段获取随机数；

如果传输层协议是UDP，则通过udp_hdr函数获取指向skbuff中UDP首部的指针，根据UDP首部udphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号；通过ip_hdr函数获取指向skbuff中IP首部的指针，再由IP首部iphdr结构体tos字段获取随机数；

本发明的步骤B3)中将新的源端口号和新的目的端口号两个新的端口号的低6位与随机数再做一次异或即可计算并还原原来的源端口号和目的端口号；

本发明的步骤B4)中

如果传输层协议是TCP，则还原后的源端口号和目的端口号写回tcphdr结构体的source字段和dest字段即可。

如果传输层协议是UDP，则还原后的源端口号和目的端口号写回udphdr结构体的source字段和dest字段即可。

本发明通过为每个被分割的网络流单元引入随机因子即随机数，主机发送方以此修改其唯一确定元组，借助网络设备中大规模部署的ECMP方法做细粒度的负载均衡，能缓解ECMP方法在网络流大小不一或发生哈希碰撞时的缺陷。主机接收方恢复各个单元的唯一确定元组，上层协议无需做任何修改。

本发明需要修改主机发送方和接收方的数据包。在Linux内核网络协议栈中实现时，可以借助Netfilter框架。如图1所示，Netfilter框架在网络协议栈的IP层提供了5个钩子拦截并处理流过的数据包，箭头所指为数据包的流动方向。本发明之所以为发送方和接收方分别选择NF_INET_LOCAL_IN和NF_INET_LOCAL_OUT这两个钩子作为实施位置，是为了仅处理必要的数据包。这两个钩子的位置更临近传输层协议，无需处理经过NF_INET_FORWARD转发的包。通过自定义钩子的回调函数，发送方和接收方都能对包做比特级的处理，因为数据包以sk_buff结构体的形式呈现，存取数据包可由存取结构体的字段实现，比如可以分别用source字段和dest字段获取包的传输层源端口号和目的端口号。同时，可以根据实际应用情况精确控制哪些类型的数据包需要被处理，在本发明中简单认为处理经过两个钩子的全部数据包。在Linux内核中，通过指定nf_hook_ops结构体的hooknum的字段指定钩子的编号，进而确定要使用哪个钩子；通过指定hook字段的函数指针为自定义回调函数，完成回调函数与钩子的绑定；最后使用nf_register_hook函数注册nf_hook_ops结构体，这样数据包在经过网络协议栈时将被钩子截获，发送方和接收方后续的处理流程是在自定义回调函数中完成的，其主要步骤可以分别参考图2和图3。

网卡卸载影响内核网络协议栈中的数据包大小，即sk_buff结构体的大小。目前主机发送方常用的网卡卸载包括TCP报文段卸载(TSO，TCP Segmentation Offload)、通用报文段卸载(GSO，Generic Segmentation Offload)。TSO和GSO主要的区别在于后者同时支持TCP、UDP协议，但前者只支持TCP协议。主机接收方对应的网卡卸载是通用接收卸载(GRO，Generic receive offload)，它能把多个小包尽力合并成一个接近64KB的大包，方便CPU一次性处理，是TSO和GSO的逆过程。是否开启网卡卸载、当开启网卡卸载时选用TSO或GSO对本发明是没有任何影响的，以Linux内核协议栈为例，编程时只需存取sk_buff结构体所需的字段即可，不必关心sk_buff的大小。开启网卡卸载的系统由于减轻了CPU的负载，将能更好地部署在10Gbps、25Gbps甚至更高速的数据中心网络中，因此本发明具有在高速数据中心网络中的可扩展性，同时能兼容不支持网卡卸载的系统。

主机发送方为每个包生成随机数是为后续修改包的唯一确定元组服务的。为了方便主机接收方还原唯一确定元组，这个随机数需要保存在数据包中某个位置。Linux内核生成随机数的原理是，由于计算机运行时存在各种各样的噪音，比如用户敲击键盘、移动和点击鼠标、硬件产生中断的时间等，Linux内核用它们来产生高质量的真随机数序列，并提供如下函数原型供编程使用：void get_random_bytes(void*buf,int nbytes)。函数返回nbytes字节的缓冲区buf，这个buf就是长度可控的随机量。如果本发明采用其他实施方法，可能会使用不同的随机数发生器，但真随机数发生器在理论上的效果是最好的。

主机发送方重新计算新的源端口号和目的端口号的目的是为了修改包的唯一确定的元组。本发明定义包的唯一确定元组是(源IP，目的IP，源端口，目的端口)。修改其中源IP和目的IP是不妥的，因为可能导致数据包无法准确发送到主机；而源端口和目的端口的意义是局部的，只对单台主机有用，比较适合做修改。由于网络设备部署的ECMP方法以唯一确定元组作为哈希算法的输入，在对同一条网络流被分割的各个包分别生成一个独特的随机数的前提下，对包的唯一确定元组加以随机化扰乱，这些包将被分散到代价相同而路径不同的通信链路上，实现负载均衡。从这里可以看出，如果采用真随机数序列，扰乱效果将更好。

对唯一确定元组的修改方式可以是多种多样的，均能在Netfilter框架钩子自定义回调函数中完成。综合考虑便利性和有效性，本发明采用的修改方式是对随机数和端口号做异或运算。异或运算⊕有两个优秀的性质。其一，如果有A、B两个数，A⊕B⊕B＝A。假如A是端口号，B是随机数，那么A⊕B就是修改后的端口号，接收方提取到B后，只要再做一次异或运算就可以很简单地把A还原出来。其二，在计算机中异或运算可以按二进制位运行，非常高效，而且运算结果不会产生进位，保证端口号不会溢出。值得注意的是，其它合理修改唯一确定元组的方法也是可行的，并不脱离本发明的关键思想。源端口号和目的端口号长度都是2字节，即16bit，直观看来发送方应该生成16bit大小的随机数，而本发明选用6bit随机数，理由有二。第一，随机数最终需要保存在包头某个字段中才能被接收方提取，而TCP/IP协议可用的字段已经很少了，太大的随机数不利于保存。一个比较合理的字段是IP头部的区分服务，可以通过iphdr结构体的tos字段存取。它具有一个字节大小，前6bit用于服务质量(QoS，Quality of Service)，后2bit用于显式拥塞通知(ECN，ExplicitCongestion Notification)协议，本发明认为前6bit是一个可以保存随机数的位置。针对不同的应用和协议，其它大小的随机数、包头其它字段可能也是可行的，并不脱离本发明的关键思想。第二，使用6bit随机数对唯一确定元组做扰乱已经足够。在做异或运算后，端口号的值将在2⁶＝64的范围内变动。如果网络设备ECMP方法选用的哈希函数的性质足够好，微小的输入变化将生成一个完全不同的输出值，即包被分散在完全不同的链路上。另外，本发明同时修改源端口号和目的端口号，增加了唯一确定元组的变化。

ECMP方法存在的两个主要缺陷都将被大幅缓解。第一，当网络流大小不一时，由于ECMP方法的负载均衡粒度为单条流，大流经过的链路的负载将高于小流经过的链路，导致负载均衡效果不佳。而本发明的优势在于负载均衡的粒度为网络流被分割后的每个包，而且这些包通常情况下大小相等，经过网络设备的ECMP方法处理后，它们彼此独立地选择发送链路，从统计学意义上看，每条链路的负载将是比较均匀的。第二，如果不采用本发明，当ECMP方法发生哈希碰撞时，将会出现过多的流经过同一条链路发送的缺陷。采用本发明后并不能根除哈希碰撞，但是由于负载均衡的粒度更细，过多包经过同一条链路的影响显然比过多流经过同一条链路小很多，因而哈希碰撞的缺陷也得到了缓解。

在开启网卡卸载的情况下，Linux内核网络协议栈中每次修改的是一个通常情况下接近64KB的大包的唯一确定元组。在离开内核协议栈后，大包的有效载荷(payload)将被网卡分割，并添加合适的包头、重新计算校验码，组成链路最大传输单元(MTU，MaximumTransmission Unit)大小的数据包，通常是1500字节。可以看出，由同一个大包经网卡处理得到的一系列小包的唯一确定元组都是相同的，本发明称这一系列小包组成了原网络流的一个子流，它们被网络设备的ECMP方法处理后将经过同一条链路被发送，此时负载均衡的粒度即为子流。而关闭网卡卸载时，负载均衡的粒度为单个MTU大小的数据包，可见开启网卡卸载的代价是负载均衡时的粗粒度。在开启网卡卸载时，如果网络中小流居多，那么本发明的运行效果并不明显，因为此时对子流做负载均衡近似于ECMP方法对原网络流做负载均衡。但是小流居多的情况下，ECMP方法对大小不一的网络流做负载均衡的能力缺陷也不再明显，因此本发明依然实现了自身的目标。如果网络中大流居多，以子流为粒度做负载均衡可以很好的工作，因为多数网络流都能被分割成多段子流且子流的大小比较一致，本发明实现了子流的负载均衡。综上，以子流为粗粒度的负载均衡产生的坏处不大，本发明在开启网卡卸载时能有效发挥作用。

主机接收方对数据包的处理可以看成是发送方的逆过程。还原每个包的唯一确定元组使得上层协议无需修改，本地主机和远程主机的应用进程都不知道自己发出的数据包曾经被修改过。

在Linux内核网络协议栈中具体实施本发明时，可以采用内核模块或源码补丁两种方式实现。由于每台主机的处理逻辑是一致的，可以把相同的内核模块或源码补丁分发到数据中心所有主机上。由于本发明是简洁、高效、一致的，具备在真实数据中心实际部署的能力。

以上仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。

Claims (9)

1.一种数据中心网络流负载均衡的方法，其特征是：利用网络设备中广泛部署的ECMP方法，在主机发送方和主机接收方分别对同一条网络流中的每个数据包进行处理，使包均匀分散在等价的不同链路上，以实现更细粒度的负载均衡；所述的主机发送方的处理方法是为每个包生成随机数，以此修改唯一确定元组，并把随机数嵌入在包头的某个字段中；所述的主机接收方的处理方法是从包头的字段中提取随机数，并把唯一确定元组还原。

2.根据权利要求1所述的一种数据中心网络流负载均衡的方法，其特征是：所述的主机发送方的处理方法具体包括以下步骤：

A1)利用Linux内核网络协议栈获取待发送的数据包；

A2)获取数据包的源端口号和目的端口号；

A3)生成随机数；

A4)重新计算新的源端口号和新的目的端口号；

A5)将生成随机数、新的源端口号和新的目的端口号写回数据包。

3.根据权利要求2所述的一种数据中心网络流负载均衡的方法，其特征是：所述的主机接收方的处理方法具体包括以下步骤：

B1)利用Linux内核网络协议栈获取待接收的数据包；

B2)获取写回数据包的生成随机数、新的源端口号和新的目的端口号；

B3)计算并还原原来的源端口号和目的端口号；

B4)将还原后的源端口号和目的端口号写回数据包。

4.根据权利要求3所述的一种数据中心网络流负载均衡的方法，其特征是：所述的步骤A1)中利用Linux内核网络协议栈获取待发送的数据包，获取待发送的数据包需要自行实现Netfilter框架的NF_INET_LOCAL_IN钩子的回调函数；得到的数据包是以sk_buff结构体的形式表现的。

5.根据权利要求4所述的一种数据中心网络流负载均衡的方法，其特征是：所述的步骤A2)中如果传输层协议是TCP，则通过tcp_hdr函数获取指向skbuff中TCP首部的指针，根据TCP首部tcphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号；

如果传输层协议是UDP，则通过udp_hdr函数获取指向skbuff中UDP首部的指针，根据UDP首部udphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号。

6.根据权利要求5所述的一种数据中心网络流负载均衡的方法，其特征是：所述的步骤A3)中使用Linux内核网络协议栈提供的真随机数产生函数get_random_bytes，它可以指定获得的随机数占用存储空间的字节数。

7.根据权利要求6所述的一种数据中心网络流负载均衡的方法，其特征是：所述的步骤A4)中新的源端口号和新的目的端口号的计算方法是取随机数的低6位bit，分别和两个端口号的低6位做异或操作得到新的两个端口号，两个端口号将在有效范围[0,65535]内发生变化。

8.根据权利要求7所述的一种数据中心网络流负载均衡的方法，其特征是：所述的步骤A5)中如果传输层协议是TCP，则把新的源端口号和新的目的端口号写回tcphdr结构体的source字段和dest字段即可；生成随机数放在包首部IP头的区分服务字段里。

如果传输层协议是UDP，则把新的源端口号和新的目的端口号写回udphdr结构体的source字段和dest字段即可；生成随机数放在包首部IP头的区分服务字段里。

9.根据权利要求8所述的一种数据中心网络流负载均衡的方法，其特征是：所述的步骤B1)中获取待接收的数据包为在Linux内核网络协议栈中，自行实现Netfilter框架的NF_INET_LOCAL_OUT钩子的回调函数；

所述的步骤B2)中如果传输层协议是TCP，则通过tcp_hdr函数获取指向skbuff中TCP首部的指针，根据TCP首部tcphdr结构体的定义分别用source字段和dest字段获取数据包的新的源端口号和新的目的端口号；通过ip_hdr函数获取指向skbuff中IP首部的指针，再由IP首部iphdr结构体tos字段获取随机数；

如果传输层协议是UDP，则通过udp_hdr函数获取指向skbuff中UDP首部的指针，根据UDP首部udphdr结构体的定义分别用source字段和dest字段获取数据包的源端口号和目的端口号；通过ip_hdr函数获取指向skbuff中IP首部的指针，再由IP首部iphdr结构体tos字段获取随机数；

所述的步骤B3)中将新的源端口号和新的目的端口号两个新的端口号的低6位与随机数再做一次异或即可计算并还原原来的源端口号和目的端口号；

所述的步骤B4)中如果传输层协议是TCP，则还原后的源端口号和目的端口号写回tcphdr结构体的source字段和dest字段即可。

如果传输层协议是UDP，则还原后的源端口号和目的端口号写回udphdr结构体的source字段和dest字段即可。