Windows下做7层软负载的经验分享
本文将为大家介绍在windows下做7层软负载做了一些分析，对负载这块有兴趣的你，可以来看看哦。其实所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;你对7层,有了浅显的印象吧,那大家有啥做7层软负载的经验可以讨论分享一下呢，当然最好是windows平台下的。
性能分析
1、 对外网的连接管理和协议解析使用http.sys(HttpApi.dll,HttpListener)内置机制，http.sys在内核级别进行HTTP的连接管理和协议解析，性能应该可以保证。
2、 对内网RealServer的连接管理和拼包使用HttpWebRequest的内置机制，但有如下问题
a) 连接管理：默认Proxy向RealServer发送请求会新建立一个连接，收到应答后会拆除连接，也就是说Proxy和RealServer之间会建立大量连接，但是由于受端口(65535)限制，出站连接不可能太多。这个问题要想办法解决，可以尝试把RealServer启用KeepAlive解决。
b) 拼包：HttpListener收到包后，虽然自动已经解析成对象，但是还要把这些包重新拼成HttpWebRequest的格式发给 RealServer，这里面包括拷贝Uri,HttpHeader，Cookies,Body等，这些数据量挺大的，在内存中拷贝一遍肯定损耗性能。该问题应该无法规避。
3、如果是常规的web应用(资源访问类)，Request小，Response很大，RealServer返回Response时还要经过Proxy，还要进行内存拷贝，这个也非常影响性能。然后7层又做不到LVS的那种DirectRoute机制(需要修改网络包的mac地址)，实现IP隧道和TCP的状态迁移需要修改操作系统的TCP/IP协议栈。鉴于代价太大，该问题也无法规避。
4、 Http协议规定请求和应答必须成对出现，默认情况下一条连接上发送出去请求后要等到收到该请求对应的应答后才能发送下一个请求，虽然Http1.1有 pipeline功能，可以成批发送请求，不必先等待应答，但是也有诸多限制，比如规定了POST不应该使用pipeline，一条连接上第一次发送请求也不可以使用pipeline机制，还有每批请求的请求数也不好定夺，批量发送请求后，如果连接断开，会有多个请求失败，等等。HTTP协议不像SIP协议那样靠CallID和Cseq来匹配请求和应答，那样可以纯异步的收发请求和应答，所以在实现Http协议栈时要同步等待应答，然后该连接上才能发送下一批请求，这必然会影响性能。
5、 HttpListener的异步接收请求和发送应答是普通的APM模式(BeginXXX,EndXXX格式)，这种异步模式在频繁调用时会大量产生和销毁IAsyncRequest对象，从而增加了GC的压力，而且IAsyncRequest对象还没有提供自定义池化的接口。如果 HttpListener提供了新的基于事件的异步模式(XXXAsync(eventargs)模式，参考Socket.ReceiveAsync方法)会解决这个问题。
6、另外由于HttpLisenter是.net的包装类，在用户态执行，而HTTP.SYS是内核态运行，在接受请求，返回应答会进行两次用户态和内核态之间的切换，从而降低性能，如果能在内核态直接进行7层转发就好了，在linux下LVS(KTCPVS)可以做到内核态的基于内容的7层转发，在 windows下可能需要做TDI或者NDIS开发，查了些资料，太复杂了，所以也不考虑了先。
可靠性分析
为了容灾，提高可靠性，考虑如下方案
1. 7层软负载的前面要有4层负载设备，7层软负载多台，且共享哈希策略，4层设备按Session做随机负载，这样所有的7层软负载机器均可正确处理任何一个请求，且某台7层软负载宕机后，剩下的7层软负载可继续工作，由于4层负载有keepalive功能，可以检测出哪台7层软负载宕机了，并且不给其转发请求。
2. 7层软负载做双击热备，7层软负载直接接入外网，正常情况下由主服务器处理请求，如果主服务器宕机，备份服务器发现后，通过ARP欺骗获取主服务器原有 IP，以把请求吸引到备份服务器上处理(硬件如果支持可能可以考虑主备机共享一个MAC地址)，主备切换时可能会造成短时请求失败的现象。
综合考虑，第二个方案有些山寨和不保险，优先考虑第一个方案。
{else}本文将为大家介绍在windows下做7层软负载做了一些分析，对负载这块有兴趣的你，可以来看看哦。其实所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;你对7层,有了浅显的印象吧,那大家有啥做7层软负载的经验可以讨论分享一下呢，当然最好是windows平台下的。
性能分析
1、 对外网的连接管理和协议解析使用http.sys(HttpApi.dll,HttpListener)内置机制，http.sys在内核级别进行HTTP的连接管理和协议解析，性能应该可以保证。
2、 对内网RealServer的连接管理和拼包使用HttpWebRequest的内置机制，但有如下问题
a) 连接管理：默认Proxy向RealServer发送请求会新建立一个连接，收到应答后会拆除连接，也就是说Proxy和RealServer之间会建立大量连接，但是由于受端口(65535)限制，出站连接不可能太多。这个问题要想办法解决，可以尝试把RealServer启用KeepAlive解决。
b) 拼包：HttpListener收到包后，虽然自动已经解析成对象，但是还要把这些包重新拼成HttpWebRequest的格式发给 RealServer，这里面包括拷贝Uri,HttpHeader，Cookies,Body等，这些数据量挺大的，在内存中拷贝一遍肯定损耗性能。该问题应该无法规避。
3、如果是常规的web应用(资源访问类)，Request小，Response很大，RealServer返回Response时还要经过Proxy，还要进行内存拷贝，这个也非常影响性能。然后7层又做不到LVS的那种DirectRoute机制(需要修改网络包的mac地址)，实现IP隧道和TCP的状态迁移需要修改操作系统的TCP/IP协议栈。鉴于代价太大，该问题也无法规避。
4、 Http协议规定请求和应答必须成对出现，默认情况下一条连接上发送出去请求后要等到收到该请求对应的应答后才能发送下一个请求，虽然Http1.1有 pipeline功能，可以成批发送请求，不必先等待应答，但是也有诸多限制，比如规定了POST不应该使用pipeline，一条连接上第一次发送请求也不可以使用pipeline机制，还有每批请求的请求数也不好定夺，批量发送请求后，如果连接断开，会有多个请求失败，等等。HTTP协议不像SIP协议那样靠CallID和Cseq来匹配请求和应答，那样可以纯异步的收发请求和应答，所以在实现Http协议栈时要同步等待应答，然后该连接上才能发送下一批请求，这必然会影响性能。
5、 HttpListener的异步接收请求和发送应答是普通的APM模式(BeginXXX,EndXXX格式)，这种异步模式在频繁调用时会大量产生和销毁IAsyncRequest对象，从而增加了GC的压力，而且IAsyncRequest对象还没有提供自定义池化的接口。如果 HttpListener提供了新的基于事件的异步模式(XXXAsync(eventargs)模式，参考Socket.ReceiveAsync方法)会解决这个问题。
6、另外由于HttpLisenter是.net的包装类，在用户态执行，而HTTP.SYS是内核态运行，在接受请求，返回应答会进行两次用户态和内核态之间的切换，从而降低性能，如果能在内核态直接进行7层转发就好了，在linux下LVS(KTCPVS)可以做到内核态的基于内容的7层转发，在 windows下可能需要做TDI或者NDIS开发，查了些资料，太复杂了，所以也不考虑了先。
可靠性分析
为了容灾，提高可靠性，考虑如下方案
1. 7层软负载的前面要有4层负载设备，7层软负载多台，且共享哈希策略，4层设备按Session做随机负载，这样所有的7层软负载机器均可正确处理任何一个请求，且某台7层软负载宕机后，剩下的7层软负载可继续工作，由于4层负载有keepalive功能，可以检测出哪台7层软负载宕机了，并且不给其转发请求。
2. 7层软负载做双击热备，7层软负载直接接入外网，正常情况下由主服务器处理请求，如果主服务器宕机，备份服务器发现后，通过ARP欺骗获取主服务器原有 IP，以把请求吸引到备份服务器上处理(硬件如果支持可能可以考虑主备机共享一个MAC地址)，主备切换时可能会造成短时请求失败的现象。
综合考虑，第二个方案有些山寨和不保险，优先考虑第一个方案。
