利用MBLB解决TCP长连接负载均衡测试方案

1、F5 BIGIP MBLB 测试记录F5 北京 杨明非2009 年 8 月2目录1. 测试环境.31.1 测试环境准备.31.2 测试网络拓扑.31.3 BIGIP MBLB 工作原理：.42. V10 MBLB 测试过程.52.1 TCP 连接测试.52.2 交易分发测试.62.3 启动第二个客户端的连接建立过程及 Timeout.82.4 加入新的客户端观察负载均衡算法.102.5 手工 Disable 服务器测试.122.6 关闭服务器测试.132.7 V10 MBLB 测试总结.142.8 附：TCPdump 数据包分析.143. One Connect 工作模式测试.163.1 On

2、e Connect 模式的工作原理.173.2 TCP 连接测试.173.3 交易分发测试.193.4 启动第二个客户端的连接.203.5 启动多个客户端观察负载均衡算法.223.6 手工 Disable 服务器测试.243.7 重新 Enable 服务器.253.8 关闭服务器测试.283.9 One Connect 模式测试总结：.294. 附录.294.1 如何使用 iRules 来判断交易边界.294.2 关于交易定向发送.314.3 关于会话保持.314.4 两种模式的对比.324.5 还需要研究的部分.3331.1. 测试环境测试环境1.11.1 测试环境准备测试环境准备PC se

3、rver 一台，安装 Windows 2003 Server.BIGIP 1 台，安装 10.0.1 版本TCP Client/Server 软件1.21.2 测试网络拓扑测试网络拓扑所有的 IP 地址均在同一个网段内，TCP client 和 Server 也运行在同一台设备上。通过启动多个不同的实例来模拟多台 Server 和 Client。测试用 BIGIP 配置virtual test_vs snat automappool test_pooldestination 3:9000ip protocol tcprules mblb-basicprofiles mb

4、lb tcp pool test_pool monitor all tcp_half_openmembers 4:9000 4:9001 4注意 mblb 的 Profile 是手工加入的， 在图形界面里没有配置。 另外对于这种类型的 Server，最好使用 tcp_half_open 健康检查模式。rule mblb-basic when CLIENT_ACCEPTED TCP:collectwhen CLIENT_DATA TCP:releaseTCP:notify request#log client_data trigeredTCP:co

5、llectwhen SERVER_CONNECTED TCP:collectwhen SERVER_DATA TCP:releaseTCP:notify response#log Server_data trigeredTCP:collect1.31.3BIGIPBIGIP MBLBMBLB 工作原理：工作原理：客户端首先与 BIGIP 建立 TCP 连接，在客户端发送数据的时候，BIGIP 根据交易将客5户端请求发送到不同的服务器，在发送前，BIGIP 将与后台服务器建立连接。在这种工作模式下，可以支持同步阻塞模式交易或者同连接里的异步交易。同步工作模式：同步工作模式：Client1 Req

6、uestServer1 ResponseClient2 RequestServer2 ResponseClient1 RequestServer2 Response异步工作模式：异步工作模式：Client1 RequestClient2 RequestClient1 RequestServer1 ResponseServer2 Response-Server3 Response在异步工作模式下，不能用下面测试的简单 irules，需要使用 iRules 来判断每个交易的边界，以便将每笔交易请求分发到不同的服务器上。下面的测试基于小包状态， 也就是每笔交易的长度不超过1个MTU， 通常情况下是1

7、460字节的情况，在这种情况下，在一次 CLIENT_DATA 事件触发的时候就可以接收到整个的交易请求或者交易回应。2.2.V10V10 MBLBMBLB 测试过程测试过程2.12.1 TCPTCP 连接测试连接测试首先启动两台 Server，分别侦听 9000 和 9001 端口确认在 BIGIP 里显示两台服务器都是工作的。B conn 显示没有任何的链接产生rootltm3600:Active config # b conn62:14774 4:ssh 4:sshtcp 1/0上面的那个连接是我的 SSH 登录产生的

8、。启动客户端，配置好发送的内容，点击 Connect6观察 BIGIP 上的连接状态：rootltm3600:Active config # b conn62:14774 4:ssh 4:sshtcp 1/04:4933 3:9000 any6tcp 1/1在客户端没有发送数据之前，在 BIGIP 上只有一个 Client-Any6 的连接，此时客户端还没有发送数据，因此 BIGIP 与后台并不建立连接。2.22.2 交易分发测试交易分发测试点击客户端上的发送按钮观察客户端的收

9、发状态7观察 Server 端收发状态观察 BIGIP 上的连接状态rootltm3600:Active config # b connany6 3:9000 4:9000tcp 1/1any6 3:9000 4:9001tcp 1/62:14774 4:ssh 4:sshtcp 1/04:4933 3:9000 any6tcp 1/1可以看到，在客户端开始发送数据后，BIGIP

10、分别和两台 Server 建立了连接，并将客户端的请求以轮询的方式发送到两台服务器上。由于我在这里启用了 SNAT，因此可以看到8第一个 Server 连接是使用的客户端源端口和服务器建立连接，第二个客户端连接使用的另外一个源端口和服务器建立连接。2.32.3 启动第二个客户端的连接建立过程及启动第二个客户端的连接建立过程及 TimeoutTimeout启动第二个客户端建立连接观察 BIGIP 状态rootltm3600:Active config # b conn62:14774 4:ssh 4:sshtcp 1/060.

11、247.114.34:1088 3:9000 any6tcp 1/0怎么没有 Server 端连接了呢？看看 Server 端日志，原来由于俺写文章的时间太长，被 BIGIP timeout 了。好，现在就让 C2 开始发送数据看到 Server 端又开始建立连接了BIGIP 上的连接状态：rootltm3600:Active config # b connany6 3:9000 4:9001tcp 1/0any6 3:9000 4:9000tcp 1/060.247.98.

12、162:14774 4:ssh 4:sshtcp 1/094:1088 3:9000 any6tcp 1/0现在开始启动 C1 发送数据C1 的连接也被断掉了：重新启动 C1 并连接BIGIP 上状况：rootltm3600:Active config # b connany6 3:9000 4:9001tcp 1/0any6 3:9000 4:9000tcp 1/062:14774

13、 4:ssh 4:sshtcp 1/04:1088 3:9000 any6tcp 1/04:1144 3:9000 any6tcp 1/0当 C1 开始发送数据的时候：rootltm3600:Active config # b connany6 3:9000 4:9001tcp 1/0any6 3:9000 4:9000tcp 1/0any6 60.247.

14、114.43:9000 4:9001tcp 1/0any6 3:9000 4:9000tcp 1/062:14774 4:ssh 4:sshtcp 1/04:1088 3:9000 any6tcp 1/04:1144 3:9000 any6tcp 1/0Server 上的状态：可以看到 BIGIP 针对每一个客户端连接， 分别在每台 Server 上建立了同样

15、数量的连接，10并将请求在这些连接里进行分发。2.42.4 加入新的客户端观察负载均衡算法加入新的客户端观察负载均衡算法我们再启动 C3, 看看有什么状况？BIIGProotltm3600:Active config # b connany6 3:9000 4:9000tcp 1/0any6 3:9000 4:9001tcp 1/0any6 3:9000 4:9000tcp 1/0any6 3:9000

16、4:9001tcp 1/062:14774 4:ssh 4:sshtcp 1/04:1088 3:9000 any6tcp 1/04:1144 3:9000 any6tcp 1/04:1231 3:9000 any6tcp 1/1当 C3 开始发送数据的时候：11Server 状态：两台 Server 都收到了 C3 的请求BIGIP 上显示 3 个 client connectio

17、n, 6 个 Server connection:rootltm3600:Active config # b connany6 3:9000 4:9000tcp 1/1any6 3:9000 4:9001tcp 1/1any6 3:9000 4:9000tcp 1/0any6 3:9000 4:9001tcp 1/0any6 3:9000 4:9000tcp

18、 1/0any6 3:9000 4:9001tcp 1/062:14774 4:ssh 4:sshtcp 1/04:1088 3:9000 any6tcp 1/04:1144 3:9000 any6tcp 1/04:1231 3:9000 any6tcp 1/1在 S2 上收到的是 C1 和 C2 的请求在 S1 上收到的是 C1 和

19、C3 的请求停止所有的客户端，然后全部重新发送的时候，Server 端接收发生了变化：S1 上收到的是 C1 和 C2 的请求12S2 上收到的是 C1 和 C3 的请求应该是 Round Robin 的算法导致了这种现象的出现BIGIP 上的连接没有发生变化：rootltm3600:Active config # b connany6 3:9000 4:9001tcp 1/1any6 3:9000 4:9000tcp 1/0any6 3:9000 4

20、:9001tcp 1/1any6 3:9000 4:9000tcp 1/1any6 3:9000 4:9001tcp 1/0any6 3:9000 4:9000tcp 1/62:14774 4:ssh 4:sshtcp 1/04:1144 3:9000 any6tcp 1/04:1231 60.247.114.

21、43:9000 any6tcp 1/4:1271 3:9000 any6tcp 1/12.52.5 手工手工 DisableDisable 服务器测试服务器测试现在手工 Disable 一台服务器在 S1 上收到了 3 个客户端的请求13恢复 disable 的服务器：S1 收到了 C1 和 C2 的请求：S2 重新开始接受请求，收到 C1 和 C3 的请求2.62.6 关闭服务器测试关闭服务器测试关闭 S2所有的 Client 和 Server 都崩溃了！ ！ ！ ！ ！ ！ ！等待服务器程序的改进版本中。 。 。 。 。 。 。 。 。 。

22、 。 。 。142.72.7 V10V10 MBLBMBLB 测试总结测试总结BIGIP V10 已经具备了 MBLB 的处理能力， 可以对长连接里面的 TCP 交易进行拆分处理，将不同的请求发送到不同的服务器上，并将服务器的返回信息发送到正确的客户端。目前发现的一些可能存在的问题：1、对于每个客户端的长连接，BIGIP 将在每个 Server 上建立一个连接，也就是说对于每台 Server 而言，都会有所有的客户端连接数的总和数量的连接，在实际应用中，需要确定服务器是否能处理全部客户端连接数量的连接数。2、关于交易的边界定义，目前的测试中非常简单的使用了 CLIENT_DATA 和SERVE

23、R_DATA 事件，这两个事件默认情况下是每接收一个数据包就触发一次，因此在交易小于 1 个 MTU，通常情况是 1460byte 的情况下，可以不用区分交易边界，默认认为一个数据包就是一次交易。3、如果每次发送交易的长度大于 1460，就需要用 irules 去获取和判断交易的长度。具体的做法是在第一个数据包进来的时候查询数据包中对于交易长度的定义，然后判断当前收集到得数据是否是完整的交易，如果完整，则释放请求，如果不完整，则继续进行收集，直到收集到足够的数据后，释放交易长度的内容到服务器。4、目前测试的应用时阻塞类型的应用， 也就是 Client 必须等待 Server 应答之后才开始发送

24、下一个请求，而且数据包都比较小，肯定在一个 packet 就发送完毕，因此不存在有边界界定的问题5、如果有非阻塞型应用，也就是客户端可能一次发出多个请求，在不等待 server回应的情况下可以持续发出请求，Server 回应也是不等待的情况，从目前的连接状况分析也是可以工作的。但可能需要进一步的编程处理来确定每一个交易的边界6、对于目前客户所要求的 Disable 服务器之后，所有的交易可以正常转发到其他服务器的需求是可以满足的。7、基本确认这种 MBLB 工作模式和 One Connect 在目前测试配置中不能同时工作，因此当客户端关闭连接时，这个客户端对应的所有服务器连接都会被关闭。8、从

25、目前了解到得信息，One Connect 工作模式下可以彻底的区分客户端连接和服务器端连接的关系，但服务器端的连接数量在 One Connect 模式下无法控制。9、由于测试服务器软件问题，没有测试到 Server 端主动关闭连接，是否会造成客户端连接中断。另外，当一台 server 故障，而在健康检查还没有检查到服务器故障期间的交易如何处理目前测试环境中也无法测试。 我的初步考虑是用inbandmonitor 来解决普通 Monitor 的间隔周期和检查周期的问题。10、还没有测试会话保持的情况，比如根据每个交易里的一些内容进行会话保持，还需要改进一下客户端和服务器软件2.82.8 附：附：

26、TCPdumpTCPdump 数据包分析数据包分析客户端数据包发送和接收15包 25, 26, 27 为三次握手建立连接149 开始，客户端发送数据 PSH,ACK，157 为客户端收到一个 BIGIPACK，没有内容，表明 Server 已经收到客户端内容159 BIGIP 给客户端发送数据 PSH,ACK161 客户端给 BIGIP 发送 ACK, 表明数据已经收到163 客户端等待 1000ms 后开始下一个数据包发送服务器端数据包发送和接收152，153，154 为 BIGIP 和后台服务器三次握手建立连接，结合客户端连接建立时间，可以看到 BIGIP 一直等待到客户端有数据发送了才开

27、始和后台建立连接155 BIGIP 给服务器端发送数据 PSH,ACK158 服务器回应 BIGIP 数据 PSH,ACK160 BIGIP 发送给服务器端 ACK，表明数据已经收到164 在 1000ms 以后，BIGIP 重新开始给服务器端发送数据包。数据流程图：比较有意思的地方：157 和 160 看上去是 BIGIP 产生的主动发给客户端和服务器的 ACK16161 从客户端发给 BIGIP，但被 BIGIP 吞掉了。俺的 TCP 理论研究还不是很深刻，是不是一些协议性的东西导致必须这样工作？3.3. OneOne ConnectConnect 工作模式测试工作模式测试在前面的测试中，

28、MBLB 可以支持异步交易，但在一些同步工作模式下，应用希望两边的连接不存在有太大的关联性， 前面一种模式客户端连接一旦中断后， 服务器端这个客户端相关连接会全部中断。通过 One Connect 工作模式，可以消除掉这种强制的绑定关系，而使服务器端的连接不会和客户端强制绑定。因此可以在客户端是长连接和短连接模式下，BIGIP 始终保持和后台服务器是长连接的结构。One Connect 工作模式只支持同步阻塞模式下的 TCP 连接，即客户端必须等待 Server端回应请求之后， 再发送下一个请求。 每笔交易都是以 Client Request-Server Response 的方式工作。和前面

29、的 MBLB 工作模式最大的不同是 One Connect 可以在 V9 版本下工作。测试的结构不变，但 BIGIP 上配置有一些变化virtual test_vs snat automappool test_pooldestination 3:9000ip protocol tcprules one_connect_ruleprofiles oneconnect tcp 注意在 VS 里面必须绑定 Oneconnect Profilerule one_connect_rule when CLIENT_ACCEPTED TCP:collectwhen CLIENT_DA

30、TA LB:detachTCP:releaseTCP:collectpool test_pool members 4:9000 4:9001 173.13.1 OneOne ConnectConnect 模式的工作原理模式的工作原理在上图中是以 HTTP 协议为例，但实际上通过 iRules，也可以支持任何协议类型，包括用户自行开发的 TCP Socket 应用。当第一个 client 连接到 BIGIP 开始发送请求的时候， BIGIP 会以这个 client 的源 IP 地址和后台服务器建立一个连接，并把客户端的 Request 转发到服务器

31、。此时客户端连接和服务器的 TCP 连接形成了绑定的关系。当服务器响应了 Response 之后，由于 BIGIP 可以识别HTTP Response，因此，当 BIGIP 检查到服务器端的 Response 结束了之后，就拆除了第一个Client TCP 连接和服务器 TCP 连接之间的对应关系。 即使在客户端关闭连接的情况下， BIGIP和后台服务器的 TCP 连接也保持 Open 的状态。当下一个用户和 BIGIP 建立连接并发送请求的时候，BIGIP 会在当前和后台服务器之间的 TCP 连接里面挑选一个空闲的连接（当然，还需要满足会话保持、负载均衡的算法的前提下） ，将第二个用户的 R

32、equest 塞到空闲的连接里面发送到服务器，这时，第二个用户的客户端连接和为第一个客户端建立的服务器连接就形成了新的对应关系。 在第二个用户的Response 结束之后，BIGIP 又拆除其对应关系。如果第三个用户连接和请求到达 BIGIP 的时候，第二个用户的 Response 并没有结束，也就是当前 BIGIP 和后台没有空闲连接的时候， BIGIP 就会和服务器端再建立一个新的 TCP连接，传送第三个客户端的请求到服务器。如果第四个用户连接和请求到达 BIGIP 的时候，第二个用户的 Response 传输完成了，第四个用户就会再使用空闲的后台服务器连接进行请求传输。这样，当客户端不停

33、的建立连接，拆除连接的时候，BIGIP 始终可以保持较少的后台服务器连接。BIGIP 在这里面完成的工作主要就是根据 Response 结束和新的用户请求到达的时刻点，来切换连接的不同连接对应关系。3.23.2 TCPTCP 连接测试连接测试18首先看看 BIGIP 上的 VS 状态，看加入了 oneconnect rules 之后是否会 Disable CMP+- VIRTUAL test_vsSERVICE 9000|PVA acceleration none|CMP enable on nonemode: all看上去还好，CMP 属于 enable 状态启动 S1启动 S2启动客户端

34、C1，并建立连接19BIGIP 上的连接状态rootltm3600:Active config # b conn62:47774 4:ssh 4:sshtcp 1/04:1339 3:9000 any6tcp 1/1此时在 Server 端也看不到任何连接3.33.3 交易分发测试交易分发测试C1 开始发送数据S1 上可以收到数据S2 上也可以收到数据由于 SNAT 的原因，服务器收到的 TCP 连接的源端口被改变了，但从数据包中可以看出，两台机器收到的是同一个客户端的同一个源

35、端口发送过来的请求。20BIGIP 上的连接状态：rootltm3600:Active config # b connany6 3:9000 4:9001tcp 1/62:47774 4:ssh 4:sshtcp 1/04:1339 3:9000 4:9000tcp 1/1有一个 Server 端连接显示是 idle 状态注意 idle 状态的连接随时间变化而变化的：rootltm3600:Active

36、config # b connany6 3:9000 4:9000tcp 1/62:47774 4:ssh 4:sshtcp 1/04:1339 3:9000 4:9001tcp 1/1rootltm3600:Active config # b connany6 3:9000 4:9001tcp 1/62:47774 60.247.1

37、14.44:ssh 4:sshtcp 1/04:1339 3:9000 4:9000tcp 1/1在两次执行 b conn 的过程中，idle 状态的 Server 端连接就在发生变化。但请求是被分配到了两台 Server 上。从客户端的 Log 看，收到了两台 Server 的 Response3.43.4 启动第二个客户端的连接启动第二个客户端的连接再启动一个客户端 C2 并建立连接21BIGIP 上的连接状况rootltm3600:Active config # b connany6 60.2

38、47.114.43:9000 4:9000tcp 1/62:47774 4:ssh 4:sshtcp 1/04:1339 3:9000 4:9001tcp 1/4:1427 3:9000 any6tcp 1/1C2 开始发送数据有意思的是此时 S1 上总是 C2 的请求，S2 上总是 C1 得请求S1S2BIGIP 上的连接状态22rootltm3600:Active confi

39、g # b connany6 3:9000 4:9001tcp 1/1any6 3:9000 4:9000tcp 1/62:47774 4:ssh 4:sshtcp 1/04:1339 3:9000 4:9001tcp 1/4:1427 3:9000 4:9000tcp 1/1而此时服

40、务器上的真实连接状况是这样的：客户端到 BIGIP VS 有两个连接，分别是 C1 和 C2，而 BIGIP 到后台服务器分别有两个连接，S1 的两个连接都用的客户端源端口，S2 的两个连接都用的其他端口。3.53.5 启动多个客户端观察负载均衡算法启动多个客户端观察负载均衡算法再启动 4 个客户端，C3,C4,C5,C6，我们来看看有什么情况出现？S1 的收发状态23可以看到，C2,C3,C4,C6 都在 S1 上有请求S2 上的收发状态可以看到，C1,C3,C5,C6 在 S2 上都有请求BIGIP 上的连接显示rootltm3600:Active config # b connany6

41、3:9000 4:9000tcp 1/0any6 3:9000 4:9001tcp 1/1any6 3:9000 4:9000tcp 1/1any6 3:9000 4:9001tcp 1/062:47774 4:ssh 4:sshtcp 1/04:1339 3:9000 60.247.11

42、4.34:9001tcp 1/4:1427 3:9000 4:9000tcp 1/4:1522 3:9000 4:9001tcp 1/04:1527 3:9000 4:9000tcp 1/4:1535 3:9000 4:9001tcp 1/4:1536 3

43、:9000 4:9000tcp 1/0客户端 6 个连接，服务器端 4 个连接而实际上在客户端和服务器系统里显示的呢？24作为客户端发起到 VS 的连接共有 6 个，分别代表 6 个 Client服务器 S1 有 5 个连接，S2 有 5 个连接。过一段时间再观察，这些连接并没有发生变化3.63.6 手工手工 DisableDisable 服务器测试服务器测试Disable S1刚才还在两台服务器之间摇摆不定的 C6 所有的请求都被转发到了 S2。253.73.7 重新重新 EnableEnable 服务器服务器重新 enable S1看到 C5 的请求被分配到两台服务

44、器上了26此时 S1 接收的请求27请求被分配到 S1 的有 C1,C3,C4,C5此时 S2 接收的请求28请求被分配到 S2 上的有 C1,C2,C3,C4,C5,C6可以确定，在 one connect 工作模式下，不同的客户端交易可以被分配到不同的服务器上。3.83.8 关闭服务器测试关闭服务器测试同样的进行关闭服务器测试，在关闭 S2 后，只有 C1 和 S1 在工作，其他客户端全部崩溃了！ ！ ！293.93.9 OneOne ConnectConnect 模式测试总结：模式测试总结：1、在 One Connect 模式下，也是一样的可以实现 MBLB 的工作，但仅限于阻塞模式的应

45、用。2、同样的，本次测试仅限于每笔交易小于 1460byte 的情况。当交易大小可能超过1460 的时候，就需要用 iRules 来进行数据包长度的判断。3、在 one connect 模式下，关闭客户端连接对服务器端的连接没有影响，这个在本次记录中没有被记下来，但实际上我已经测试过了，关闭客户端连接的时候Server 端的连接不会发生变化。4、One Connect 工作模式下，BIGIP 自身的 b conn 输出和实际的情况不大一样，估计是 b conn 输出的是实时信息，因此和实际上的服务器看到的连接数量不能对应5、测试是在 V10 版本上进行的， 但按照其工作原理， 在 V9 平台上

46、应该也可以工作。6、One connect 模式 CMP 是可以正常工作7、在 one connect 工作模式下，应该也同样遇到 monitor 健康检查的实效期间的问题。因此，也需要用 inband monitor 来解决。或者考虑用 when LB_FAIL 的事件来进行处理。4.4. 附录附录4.14.1 如何使用如何使用 iRulesiRules 来判断交易边界来判断交易边界30当客户端的交易可能大于 1460byte 的时候， 就必须使用 iRules 来判断每笔交易的边界。在进行边界分析的时候，必须知道数据包的格式，通常情况下，在长连接交易中，必然会有一个位置来表明每个交易的长度

47、。处理流程处理流程在 iRules 中，需要进行的流程如下：1、在客户端连接建立成功的时候，启用 TCP:collect 进行数据收集2、当客户端请求内容发送时，将触发 CLIENT_DATA 事件，此时就可以通过分析TCP:payload 判断接收到的内容判断交易的长度3、判断当前收集到的 payload 长度和交易的实际长度进行比较，如果相等，在 OneConnect 模式下， 进行 LB:detach 动作， 在 MBLB 模式下， 进行 TCP:notify request动作。如果没有结束，则继续收集，直到收集成功一笔完整的交易。4、在 LB:detach 或 TCP:notify

48、request 完成后，则释放这部分数据，将交易请求转发到服务器。收集完成后，释放交易长度的数据到服务器。5、在数据释放完成后，重新触发 TCP:collect 动作，等待触发下一次 CLIENT_DATA动作。示例代码示例代码下面这段代码以 LDAP 协议为例，演示如何使用 iRules 来判断一个完整的 LDAP 查询请求。when CLIENT_ACCEPTED TCP:collectwhen CLIENT_DATA binary scan TCP:payload xc ber_lenif $ber_len 0 set ber_index expr 2 + 128 + $ber_len

49、else set ber_index 2# message idbinary scan TCP:payload $ber_indexxcI ber_len ber_len_extif $ber_len (4-$ext_len)*8)+(0 x100$ext_len)%(0 x100$ext_len) else set ext_len 0incr ber_index expr 2 + $ext_len + $ber_len# ldap messagebinary scan TCP:payload $ber_indexc ber_typeif expr $ber_type & 0 x1f

50、= 2 log local0. unbind = detach31TCP:payload replace 0 TCP:payload length LB:detachTCP:releaseTCP:collect4.24.2 关于交易定向发送关于交易定向发送由于环境问题， 交易定向发送， 也就是根据交易的内容， 指定将交易发送到某一个 Pool或 member 中的功能还没有进行测试，但从一些案例上看是完全可行的。必须要注意判断完交易内容后，必须在 LB:detach 或 TCP:notify request 动作执行以前，指定将交易要转发到的 Pool，否则一旦 TCP:release 完成后

51、，将无法指定数据包发往的目的地。示例代码如下：when CLIENT_DATA set call_id XXXXXXif $call_id equals “abc” pool pool_aelse pool pool_bTCP:releaseTCP:notify requestTCP:collect4.34.3 关于会话保持关于会话保持同样由于环境问题，会话保持目前还没有进行完全的测试。但从已有的案例上看，这两种模式都支持基于 iRules 的会话保持，可以根据交易里的一些特征代码，将具备相同特征代码的请求发送到同一台服务器。和 Pool 选择一样，Persist uie 指令的位置必须放置在

52、 LB:detach 或 TCP:notify 动作执行之前，否则将无法实现会话保持处理。示例代码如下：when CLIENT_DATA set call_id XXXXXXpersist uie $call_id 360TCP:releaseTCP:notify requestTCP:collect其中 XXXXXX 部分是从 TCP payload 中提取特征码的函数处理。32在长连接的交易处理中，经常可能出现消息串的情况，也就是连续的几笔请求都是为了完成一笔交易，在一些情况下，这些请求必须发往同一台服务器处理，这时，就可以采用会话保持模式实现。 或者在有些情况下， 比如同一个用户的多笔交易请求都需要发送到同一台服务器的时候，也需要使用会话保持来进行处理。4.44.4 关于关于服务器端认证服务器端认证在一些情况下，服务器端需要认证之后才能接受客户端的请求，当 BIGIP 与后台建立连接的时候必须使用客户端的认证信息先和后台建立连接后才能继续发送数据， 这时通常的做法是在客户端第一次连接到 BIGIP 与第一台连接的服务器进行认证的时候，把客户端发送