利用MBLB解决TCP长连接负载均衡测试方案
负载均衡解决方案
负载均衡解决方案引言在计算机网络中，负载均衡是一种分配网络流量的技术，通过将流量分散到多个服务器上，以提高系统的可靠性、稳定性和性能。
负载均衡解决方案是指在实际应用中采用的一系列策略和技术，用于实现负载均衡功能。
本文将介绍负载均衡的基本原理和常见的解决方案。
负载均衡的基本原理负载均衡的基本原理是通过将用户请求分发到多个服务器上，使得每个服务器的负载相对均衡。
负载均衡可以在多个层面进行，包括应用层、传输层和网络层。
应用层负载均衡应用层负载均衡是在应用层上进行的负载均衡。
它通过解析用户请求的内容，如URL、报文头等，来进行请求的分发。
常见的应用层负载均衡算法有轮询、随机、最少连接等。
传输层负载均衡传输层负载均衡是在传输层上进行的负载均衡。
它通过解析传输层协议的头部信息，如TCP头部中的源IP地址、目的IP地址和端口号等，来进行请求的分发。
常见的传输层负载均衡算法有轮询、源IP哈希、最少连接等。
网络层负载均衡网络层负载均衡是在网络层上进行的负载均衡。
它通过解析网络层协议的头部信息，如IP头部中的源IP地址和目的IP地址等，来进行请求的分发。
常见的网络层负载均衡算法有轮询、一致性哈希等。
常见的负载均衡解决方案根据负载均衡的原理和实现方式，常见的负载均衡解决方案可以分为硬件负载均衡和软件负载均衡两大类。
硬件负载均衡解决方案硬件负载均衡解决方案是指使用专用的硬件设备来实现负载均衡功能。
这些设备通常具有高性能、高可靠性和可扩展性，并提供了丰富的负载均衡功能。
常见的硬件负载均衡设备包括F5 BIG-IP、Citrix ADC等。
硬件负载均衡解决方案适用于对性能和可靠性有较高要求的场景。
软件负载均衡解决方案软件负载均衡解决方案是指使用软件来实现负载均衡功能。
这些软件可以运行在通用的服务器上，通过使用负载均衡算法来实现请求的分发。
常见的软件负载均衡解决方案包括Nginx、HAProxy等。
软件负载均衡解决方案相对于硬件解决方案具有成本低、灵活性高等优势，适用于中小型应用场景。
负载均衡MLB方案验证与建议配置参数
负载均衡MLB方案验证与建议配置参数1.背景描述随着LTE业务的不断的发展，热点区域、高业务量区域、景区突发高用户数区域等相继出现。
针对容量不足问题，小区扩容、站点新建等措施不断开展，而通过监控现网KPI指标发现，同覆盖小区间的容量差异问题日益严重，一个因资源耗尽而无法使用正常业务，另一个却因空闲而资源浪费。
移动性负载均衡功能作为业务分担的有效策略，在早期版本中已实现落地。
由最开始的PRB利用率触发方式，到现在的仅用户数触发和PRB与用户数联合触发方式等多种策略方案，为解决业务分担不均问题，提供了的有力的解决方案。
MLB方案在实际落地过程中，室分同覆盖场景的优化效果相对明显，但针对宏站同覆盖场景，却收效甚微。
为研究问题原因，解决宏站同覆盖业务分担不均问题，针对MLB方案涉及的相关参数进行充分验证，指导后续优化并推广应用。
2.方案概述2.1. 基本流程MLB流程整体分为三个阶段如下：第一步：本区监测负载水平，当负载超过算法触发门限时，触发MLB算法，交互邻区负载信息，作为算法输入。
第二步：筛选可以作为MLB的目标邻区和执行UE第三步：基于切换或者重选完成MLB动作。
2.2. 适用场景异频负载均衡的主要适用场景包括如下几类：•同站同覆盖场景•同站大小覆盖场景•同站交叠覆盖场景•异站交叠覆盖场景•宏微站交叠覆盖场景3.实际问题3.1. 异频策略当前温州现网总体的FD频段策略如下：1）D频段重选优先级高于F频段2）F频段异频启测A2门限普遍为-82dBm，D频段为-96dBm该策略的主要目的为F频段作为连续覆盖层，D频段作为容量层，用户在共覆盖区域优先主流D频段小区。
由此，当区域用户集中增加时，D频段小区容易吸收过多用户，而F频段小区因启测门限过高而驻留能力偏弱，导致出现一个过忙一个过闲的现象。
3.2. MLB当前策略针对如上异频策略，前期工作也已经采取了相关负载均衡的优化，但实际效果远没有达到预期。
前期的主要策略如下：1、打开异频负载均衡开关，选择仅用户数触发方式2、开启连接态用户负载均衡，未开启空闲态用户负载均衡3、自定义调整用户数（异频负载均衡用户数门限+负载均衡用户数偏置）触发门限，一般选取同覆盖区域每小区平均用户数为触发门限4、其他参数保持默认状态采用如上方式进行优化后，产生负载均衡效果的小区较少，未能实现充分利用无线资源的预期。
多链路负载均衡解决方案
多链路负载均衡解决方案一、背景介绍在现代网络通信中，负载均衡是一种重要的技术手段，它可以将网络流量分散到多个服务器或链路上，以实现资源的合理利用和提高系统的可用性和性能。
然而，传统的负载均衡方案往往只能针对单一链路进行负载均衡，无法充分利用多个链路资源，因此需要一种多链路负载均衡解决方案来满足不同场景下的需求。
二、多链路负载均衡解决方案的优势1. 提高系统的可用性：多链路负载均衡解决方案可以将流量分散到多个链路上，当某个链路发生故障时，流量可以自动切换到其他正常的链路上，保证系统的持续可用性。
2. 提高系统的性能：多链路负载均衡解决方案可以根据链路的负载情况，动态地调整流量分配策略，将流量分配到负载较低的链路上，从而提高系统的性能和响应速度。
3. 充分利用链路资源：多链路负载均衡解决方案可以将流量均匀地分配到多个链路上，充分利用链路的带宽资源，提高网络的吞吐量和传输效率。
三、多链路负载均衡解决方案的实现方法1. 链路监测与状态检测：多链路负载均衡解决方案需要通过监测链路的状态来判断链路的可用性和负载情况。
可以使用心跳包、PING命令等方式来监测链路的连通性和延迟情况，以及通过流量统计等方式来监测链路的负载情况。
2. 负载均衡算法的选择：多链路负载均衡解决方案需要选择合适的负载均衡算法来实现流量的分配。
常用的负载均衡算法包括轮询算法、加权轮询算法、最少连接算法等，可以根据具体的需求选择合适的算法。
3. 流量分配策略的调整：多链路负载均衡解决方案可以根据链路的负载情况，动态地调整流量分配策略。
当某个链路的负载较高时，可以将流量分配到负载较低的链路上，以实现负载均衡。
4. 故障切换与恢复：多链路负载均衡解决方案需要具备故障切换和恢复的能力。
当某个链路发生故障时，系统可以自动切换到其他正常的链路上，当故障链路恢复正常时，系统可以自动将流量切换回来，实现故障的快速恢复。
四、多链路负载均衡解决方案的应用场景1. 数据中心：在大型数据中心中，常常需要使用多个链路来承载大量的流量，通过多链路负载均衡解决方案可以将流量均匀地分配到各个链路上，提高数据中心的性能和可用性。
A10-链路负载均衡（LLB）解决方案-YL
A10-链路负载均衡（LLB）解决⽅案-YLA10 链路负载均衡解决⽅案1. 概述由于国内各运营商之间的互联互通⼀直存在很⼤的问题，采⽤运营商⾃⾝单条互联⽹出⼝，在为⽤户提供IDC主机托管服务和⼤客户专线接⼊服务时，会遇到⽤户抱怨访问速度差的问题。
同时，单条链路本⾝存在单点故障问题。
因此，通过在多个数据中⼼分别拉不同运营商的线路或者同⼀数据中⼼或公司⽹络出⼝采⽤多条互联⽹链路并使⽤专门的负载均衡设备智能选择最佳链路成为提⾼服务⽔平和⽤户满意度的⼀种有效⽅式，我们把多数据中⼼负载均衡和多链路负载均衡统称为全局负载均衡或者⼴域⽹负载均衡。
2. 需求描述对于全局和链路负载均衡，需要解决两种流量类型的负载均衡以及容灾问题：⼊向流量（Inbound Traffic）：从Internet上的客户端发起，到数据中⼼内部的应⽤服务的流量。
如：Internet上⽤户访问企业Web⽹站。
对于⼊向流量，需要根据当前⽹络延时、就近性等因素，来判断哪⼀条链路可以对外部⽤户提供最佳的访问服务。
出向流量（Outbound Traffic）：从内部⽹络发起的，对Internet上应⽤资源的访问。
如：内部局域⽹⽤户访问Internet上Web⽹站应⽤。
对于出向流量，需要根据当前链路的就近⾏、负载情况、和应⽤服务的重要性等选择最佳的链路。
容灾：多数据中⼼除了可以提⾼服务质量之外，另外⼀个重要的⽬的就是容灾，当⼀个数据中⼼出现故障，将所有⽤户访问由灾备数据中⼼来处理。
3. A10 LLB负载均衡解决⽅案3.1. 出向流量链路负载均衡（Outbound LLB）相对于⼊向流量的链路负载均衡，出向流量的链路负载均衡则⽐较简单。
当内部⽤户发起对外界的访问请求时，链路负载均衡控制器根据链路选择算法选择合适的链路，并对内部⽤户的IP地址进⾏NAT转换。
出向负载均衡是对每个数据中⼼内部的机器来⽽⾔的，通过放置在每个数据中⼼出⼝位置的AX来实现。
关于LVS负载均衡tcp长连接分发的解决思路
关于LVS负载均衡tcp长连接分发的解决思路虽然应⽤keepalived搞定了后端服务负载均衡和⾼可⽤性问题，但是在具体应⽤的时候，还是要注意很多问题。
很多应⽤都⽤tcp或者http的长连接，因为建⽴tcp连接或者http连接开销⽐较⼤，⽽应⽤端其实是需要频繁跟server端通讯的，这时候保持长连接⽆疑是⾮常合适的。
经过摸索lvs & keepalived 长连接的配置主要在三个地⽅：⼀、client端的SoTimeout , 就java来说就是.Socket的setSoTimeout⽅法设置的， setSoTimeout(0)就是表明超时时间⽆限⼤。
这个值是为读取阻塞设置超时的。
⼆、lvs的设置：查看是ipvsadm --list --timeout, ⽐如我的机器就会返回如下结果：# ipvsadm --list --timeoutTimeout (tcp tcpfin udp): 7200 5 60这就表明我的tcp session的timeout时间是7200秒。
设置timeout：ipvsadm --set 7200 5 60这个值如果设置太⼩，你的client将会收到 connection reset by peer此类的错误提⽰。
三、keepalived的配置：就是virtual_server的persistence_timeout ，意思就是在这个⼀定时间内会讲来⾃同⼀⽤户（根据ip来判断的）route到同⼀个real server。
对于长连接类的应⽤，你肯定需要这么做。
配置值最好跟lvs的配置的timeout⼀致。
四、具体实例如下：virtual_server 172.19.1.19 5222 {delay_loop 2lb_algo wrrlb_kind DRpersistence_timeout 7200protocol TCPreal_server 172.19.1.8 5222 {weight 1TCP_CHECK {connect_timeout 10nb_get_retry 3delay_before_retry 3}}real_server 172.19.1.9 5222 {weight 1TCP_CHECK {connect_timeout 10nb_get_retry 3delay_before_retry 3}}}/uid-25723371-id-5749631.html。
负载均衡测试方案
负载均衡测试方案负载均衡是在计算机网络中常用的技术，它的作用是分摊网络服务器的工作负载，确保每台服务器都能得到合理的负载，从而提高系统的性能和可靠性。
为了保证负载均衡的有效运行，测试方案是必不可少的一环。
本文将介绍一种负载均衡测试方案，包含测试目标、测试环境、测试用例和测试工具等内容。
一、测试目标负载均衡测试的目标是验证负载均衡系统是否能够实现预期的功能和性能要求。
具体而言，测试目标包括以下几个方面：1. 功能测试：验证负载均衡系统是否能够正确地将请求分发给后端服务器，并能够根据服务器的负载情况动态调整请求的分发策略。
2. 性能测试：测试负载均衡系统在不同负载条件下的性能表现，包括请求响应时间、吞吐量和并发连接数等。
3. 可靠性测试：测试负载均衡系统在大并发情况下的稳定性和可靠性，包括故障转移、容错能力和负载均衡策略的正确性等。
二、测试环境搭建一个逼近真实生产环境的测试环境是负载均衡测试的基础。
测试环境需要包括多个相同配置的后端服务器、一个负载均衡设备和一个用于模拟用户请求的测试工具。
同时，还需要一个用于监测服务器负载情况的性能监控工具。
三、测试用例测试用例是负载均衡测试的核心内容，它们描述了测试过程中需要执行的操作和预期结果。
测试用例应该覆盖各个方面的功能和性能要求，包括但不限于以下几个方面：1. 正常请求分发：测试负载均衡系统是否能够正确地将请求分发给后端服务器，并确保每个服务器获得的请求数大致相等。
2. 异常请求分发：测试负载均衡系统在后端服务器故障或不可用时的请求处理策略，包括故障转移和容错机制。
3. 负载均衡策略测试：测试不同负载均衡策略在不同负载条件下的表现，比较它们的性能和效果。
4. 性能测试：测试负载均衡系统在不同负载条件下的性能表现，包括请求响应时间、吞吐量和并发连接数等。
四、测试工具选择合适的测试工具对负载均衡系统进行压力测试和性能测试是非常重要的。
以下是一些常用的测试工具：1. Apache JMeter：一个功能强大的开源性能测试工具，可用于模拟大规模用户请求并监测系统的性能。
负载均衡方案
负载均衡方案
目录：
1. 负载均衡方案简介
1.1 什么是负载均衡
1.2 负载均衡的作用
1.3 负载均衡的原理
2. 常见的负载均衡算法
2.1 轮询算法
2.2 最少连接算法
2.3 最快响应算法
3. 负载均衡方案的选择
3.1 网络负载均衡
3.2 集群负载均衡
4. 负载均衡方案的实现
4.1 硬件负载均衡器
4.2 软件负载均衡器
---
负载均衡方案简介
负载均衡是一种将网络流量或工作负载分配给多个服务器或其他计算资源的技术。
通过负载均衡，可以确保每台服务器都能够平衡地处理流量，提高整体性能和可靠性。
负载均衡可以根据不同的算法来分配流量，使得每台服务器都能够高效地处理请求，避免出现单台服务器负荷过重的情况。
在一个负载均衡集群中，通常会有一个前端负载均衡器接收来自客户端的请求，并根据预定的负载均衡算法将请求分发给后端的多台服务器。
这样可以实现资源的合理分配，提高系统的整体性能。
负载均衡的原理是通过监控服务器的负载情况，根据不同的算法将请求分发给不同的服务器。
这样可以避免单台服务器负载过重，提
高系统的稳定性和可靠性。
不同的负载均衡算法适用于不同的场景，可以根据实际需求选择合适的算法来实现负载均衡。
利用MBLB解决TCP长连接负载均衡测试方案
F5 BIGIP MBLB 测试记录F5北京杨明非2009年8月目录1. 测试环境 (3)1.1 测试环境准备 (3)1.2 测试网络拓扑 (3)1.3 BIGIP MBLB工作原理： (4)2. V10 MBLB 测试过程 (5)2.1 TCP连接测试 (5)2.2 交易分发测试 (6)2.3 启动第二个客户端的连接建立过程及Timeout (8)2.4 加入新的客户端观察负载均衡算法 (10)2.5 手工Disable服务器测试 (12)2.6 关闭服务器测试 (13)2.7 V10 MBLB 测试总结 (14)2.8 附：TCPdump数据包分析 (14)3. One Connect工作模式测试 (16)3.1 One Connect模式的工作原理 (17)3.2 TCP连接测试 (17)3.3 交易分发测试 (19)3.4 启动第二个客户端的连接 (20)3.5 启动多个客户端观察负载均衡算法 (22)3.6 手工Disable 服务器测试 (25)3.7 重新Enable服务器 (26)3.8 关闭服务器测试 (29)3.9 One Connect模式测试总结： (30)4. 附录 (30)4.1 如何使用iRules来判断交易边界 (30)4.2 关于交易定向发送 (32)4.3 关于会话保持 (32)4.4 两种模式的对比 (33)4.5 还需要研究的部分 (34)1.测试环境1.1测试环境准备PC server一台，安装Windows 2003 Server.BIGIP 1台，安装10.0.1版本TCP Client/Server软件1.2测试网络拓扑所有的IP地址均在同一个网段内，TCP client 和Server也运行在同一台设备上。
通过启动多个不同的实例来模拟多台Server和Client。
测试用BIGIP 配置注意mblb的Profile是手工加入的，在图形界面里没有配置。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
F5 BIGIP MBLB 测试记录F5北京杨明非2009年8月目录1. 测试环境 (3)1.1 测试环境准备 (3)1.2 测试网络拓扑 (3)1.3 BIGIP MBLB工作原理： (4)2. V10 MBLB 测试过程 (5)2.1 TCP连接测试 (5)2.2 交易分发测试 (6)2.3 启动第二个客户端的连接建立过程及Timeout (8)2.4 加入新的客户端观察负载均衡算法 (10)2.5 手工Disable服务器测试 (12)2.6 关闭服务器测试 (13)2.7 V10 MBLB 测试总结 (14)2.8 附：TCPdump数据包分析 (14)3. One Connect工作模式测试 (16)3.1 One Connect模式的工作原理 (17)3.2 TCP连接测试 (17)3.3 交易分发测试 (19)3.4 启动第二个客户端的连接 (20)3.5 启动多个客户端观察负载均衡算法 (22)3.6 手工Disable 服务器测试 (25)3.7 重新Enable服务器 (26)3.8 关闭服务器测试 (29)3.9 One Connect模式测试总结： (30)4. 附录 (30)4.1 如何使用iRules来判断交易边界 (30)4.2 关于交易定向发送 (32)4.3 关于会话保持 (32)4.4 两种模式的对比 (33)4.5 还需要研究的部分 (34)1.测试环境1.1测试环境准备PC server一台，安装Windows 2003 Server.BIGIP 1台，安装10.0.1版本TCP Client/Server软件1.2测试网络拓扑所有的IP地址均在同一个网段内，TCP client 和Server也运行在同一台设备上。
通过启动多个不同的实例来模拟多台Server和Client。
测试用BIGIP 配置注意mblb的Profile是手工加入的，在图形界面里没有配置。
另外对于这种类型的Server，最好使用tcp_half_open健康检查模式。
1.3 BIGIP MBLB工作原理：客户端首先与BIGIP建立TCP连接，在客户端发送数据的时候，BIGIP根据交易将客户端请求发送到不同的服务器，在发送前，BIGIP将与后台服务器建立连接。
在这种工作模式下，可以支持同步阻塞模式交易或者同连接里的异步交易。
同步工作模式：Client1 RequestServer1 ResponseClient2 RequestServer2 ResponseClient1 RequestServer2 Response异步工作模式：Client1 RequestClient2 RequestClient1 RequestServer1 ResponseServer2 Response-Server3 Response在异步工作模式下，不能用下面测试的简单irules，需要使用iRules来判断每个交易的边界，以便将每笔交易请求分发到不同的服务器上。
下面的测试基于小包状态，也就是每笔交易的长度不超过1个MTU，通常情况下是1460字节的情况，在这种情况下，在一次CLIENT_DA TA事件触发的时候就可以接收到整个的交易请求或者交易回应。
2. V10 MBLB 测试过程2.1TCP连接测试首先启动两台Server，分别侦听9000和9001端口确认在BIGIP里显示两台服务器都是工作的。
B conn显示没有任何的链接产生启动客户端，配置好发送的内容，点击Connect观察BIGIP上的连接状态：在客户端没有发送数据之前，在BIGIP上只有一个Client-Any6的连接，此时客户端还没有发送数据，因此BIGIP与后台并不建立连接。
2.2交易分发测试点击客户端上的发送按钮观察客户端的收发状态观察Server端收发状态观察BIGIP上的连接状态可以看到，在客户端开始发送数据后，BIGIP分别和两台Server建立了连接，并将客户端的请求以轮询的方式发送到两台服务器上。
由于我在这里启用了SNAT，因此可以看到第一个Server连接是使用的客户端源端口和服务器建立连接，第二个客户端连接使用的另外一个源端口和服务器建立连接。
2.3启动第二个客户端的连接建立过程及Timeout启动第二个客户端建立连接观察BIGIP状态怎么没有Server端连接了呢？看看Server端日志，原来由于俺写文章的时间太长，被BIGIP timeout了。
好，现在就让C2开始发送数据看到Server端又开始建立连接了BIGIP上的连接状态：现在开始启动C1发送数据C1的连接也被断掉了：重新启动C1并连接BIGIP上状况：当C1开始发送数据的时候：Server上的状态：可以看到BIGIP针对每一个客户端连接，分别在每台Server上建立了同样数量的连接，并将请求在这些连接里进行分发。
2.4加入新的客户端观察负载均衡算法我们再启动C3, 看看有什么状况？BIIGPServer状态：两台Server都收到了C3的请求BIGIP上显示3个client connection, 6个Server connection:在S2上收到的是C1和C2的请求在S1上收到的是C1和C3的请求停止所有的客户端，然后全部重新发送的时候，Server端接收发生了变化：S1上收到的是C1和C2的请求S2上收到的是C1和C3的请求应该是Round Robin的算法导致了这种现象的出现BIGIP上的连接没有发生变化：2.5手工Disable服务器测试现在手工Disable一台服务器在S1上收到了3个客户端的请求恢复disable的服务器：S1收到了C1和C2的请求：S2重新开始接受请求，收到C1和C3的请求2.6关闭服务器测试关闭S2所有的Client 和Server都崩溃了！！！！！！！等待服务器程序的改进版本中。
2.7V10 MBLB 测试总结BIGIP V10 已经具备了MBLB的处理能力，可以对长连接里面的TCP交易进行拆分处理，将不同的请求发送到不同的服务器上，并将服务器的返回信息发送到正确的客户端。
目前发现的一些可能存在的问题：1、对于每个客户端的长连接，BIGIP将在每个Server上建立一个连接，也就是说对于每台Server而言，都会有所有的客户端连接数的总和数量的连接，在实际应用中，需要确定服务器是否能处理全部客户端连接数量的连接数。
2、关于交易的边界定义，目前的测试中非常简单的使用了CLIENT_DATA和SERVER_DATA事件，这两个事件默认情况下是每接收一个数据包就触发一次，因此在交易小于1个MTU，通常情况是1460byte的情况下，可以不用区分交易边界，默认认为一个数据包就是一次交易。
3、如果每次发送交易的长度大于1460，就需要用irules去获取和判断交易的长度。
具体的做法是在第一个数据包进来的时候查询数据包中对于交易长度的定义，然后判断当前收集到得数据是否是完整的交易，如果完整，则释放请求，如果不完整，则继续进行收集，直到收集到足够的数据后，释放交易长度的内容到服务器。
4、目前测试的应用时阻塞类型的应用，也就是Client必须等待Server应答之后才开始发送下一个请求，而且数据包都比较小，肯定在一个packet就发送完毕，因此不存在有边界界定的问题5、如果有非阻塞型应用，也就是客户端可能一次发出多个请求，在不等待server回应的情况下可以持续发出请求，Server回应也是不等待的情况，从目前的连接状况分析也是可以工作的。
但可能需要进一步的编程处理来确定每一个交易的边界6、对于目前客户所要求的Disable服务器之后，所有的交易可以正常转发到其他服务器的需求是可以满足的。
7、基本确认这种MBLB工作模式和One Connect在目前测试配置中不能同时工作，因此当客户端关闭连接时，这个客户端对应的所有服务器连接都会被关闭。
8、从目前了解到得信息，One Connect工作模式下可以彻底的区分客户端连接和服务器端连接的关系，但服务器端的连接数量在One Connect模式下无法控制。
9、由于测试服务器软件问题，没有测试到Server端主动关闭连接，是否会造成客户端连接中断。
另外，当一台server故障，而在健康检查还没有检查到服务器故障期间的交易如何处理目前测试环境中也无法测试。
我的初步考虑是用inband monitor来解决普通Monitor的间隔周期和检查周期的问题。
10、还没有测试会话保持的情况，比如根据每个交易里的一些内容进行会话保持，还需要改进一下客户端和服务器软件2.8附：TCPdump数据包分析客户端数据包发送和接收包25, 26, 27为三次握手建立连接149开始，客户端发送数据PSH,ACK，157为客户端收到一个BIGIP ACK，没有内容，表明Server已经收到客户端内容159 BIGIP给客户端发送数据PSH,ACK161 客户端给BIGIP发送ACK, 表明数据已经收到163 客户端等待1000ms后开始下一个数据包发送服务器端数据包发送和接收152，153，154为BIGIP和后台服务器三次握手建立连接，结合客户端连接建立时间，可以看到BIGIP一直等待到客户端有数据发送了才开始和后台建立连接155 BIGIP给服务器端发送数据PSH,ACK158 服务器回应BIGIP数据PSH,ACK160 BIGIP发送给服务器端ACK，表明数据已经收到164 在1000ms以后，BIGIP重新开始给服务器端发送数据包。
数据流程图：比较有意思的地方：157和160看上去是BIGIP产生的主动发给客户端和服务器的ACK161从客户端发给BIGIP，但被BIGIP吞掉了。
俺的TCP理论研究还不是很深刻，是不是一些协议性的东西导致必须这样工作？3.One Connect工作模式测试在前面的测试中，MBLB可以支持异步交易，但在一些同步工作模式下，应用希望两边的连接不存在有太大的关联性，前面一种模式客户端连接一旦中断后，服务器端这个客户端相关连接会全部中断。
通过One Connect工作模式，可以消除掉这种强制的绑定关系，而使服务器端的连接不会和客户端强制绑定。
因此可以在客户端是长连接和短连接模式下，BIGIP始终保持和后台服务器是长连接的结构。
One Connect工作模式只支持同步阻塞模式下的TCP连接，即客户端必须等待Server 端回应请求之后，再发送下一个请求。
每笔交易都是以Client Request->Server Response的方式工作。
和前面的MBLB工作模式最大的不同是One Connect可以在V9版本下工作。
测试的结构不变，但BIGIP上配置有一些变化注意在VS里面必须绑定Oneconnect Profile3.1One Connect模式的工作原理在上图中是以HTTP协议为例，但实际上通过iRules，也可以支持任何协议类型，包括用户自行开发的TCP Socket应用。