这是我参与2022首次更文挑战的第8天，活动详情查看：2022首次更文挑战」。
1.1 基本工作模式
F5支持全代理模式，同时也可以工作在四层转发模式。
全代理模式就是VS配置成standard类型，此模式下客户端和F5建立一个连接，客户端将请求发送给F5，F5再和服务器建立连接，并将请求发送给服务器，服务器返回信息后，F5再将返的回信息送给客户端。在此模式下F5可以查看请求和响应的所有信息，可以根据所有信息进行分发和处理。
四层转发模式就是VS配置成Performance L4类型，此模式下F5只做四层转发，也就是F5只处理四层以下的信息，即端口和IP信息，具体业务数据不做任何处理。客户端发送给F5的数据包，F5只根据需要将IP和端口处理之后就直接发送给服务器，响应信息也类似处理。在此模式下，F5只能查看四层一下信息，不处理业务信息，好处是处理过程简单、速度快。缺点是无法对四层以上的协议数据进行精确处理。
1.2 会话保持
由于负载均衡是按照连接尽心分发的，而很多业务都有会话信息，一个会话信息会包括多个连接，从业务角度看，一个会话的连接都应该分发到同一台服务器上，这样才能保证该会话的一致性。F5 BigIP支持多种的会话保持方法，其中包括：简单会话保持（源地址会话保持）、HTTP Header的会话保持，基于SSL Session ID的会话保持，I-Rules会话保持以及基于 HTTP Cookie的会话保持，此外还有基于SIP ID以及Cache设备的会话保持等，但常用的是简单会话保持，HTTP Header的会话保持以及 HTTP Cookie会话保持以及基于I-Rules的会话保持。
1.2.1.简单会话保持
简单会话保持也被称为基于源地址的会话保持，是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关连会话的依据。对来自同一IP地址的所有访问请求在作负载均时都会被保持到一台服务器上去。在BIGIP设备上可以为“同一IP地址”通过网络掩码进行区分，比如可以通过对IP地址192.168.1.1进行255.255.255.0的网络掩码，这样只要是来自于192.168.1.0/24这个网段的流量BIGIP都可以认为他们是来自于同一个用户，这样就将把来自于192.168.1.0/24网段的流量会话保持到特定的一台服务器上。
简单会话保持里另外一个很重要的参数就是连接超时值，BIGIP会为每一个进行会话保持的会话设定一个时间值，当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值，BIGIP将会将新的连接进行会话保持，但如果这个间隔大于该超时值，BIGIP将会将新来的连接认为是新的会话然后进行负载平衡。
基于原地址的会话保持实现起来简单，只需要根据数据包三、四层的信息就可以实现，效率也比较高。存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况上客户机数量很少，但每个客户机都会产生多个并发访问，对这些必发访问也要求通过负均均衡器分配到多个服器上，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。
1.2.2.基于Cookie的会话保持
1)cookie插入模式
在Cookie插入模式下，BigIP将负责插入cookie，后端服务器无需作出任何修改.当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带cookie）被发回BIGIP，然后BIGIP插入cookie，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP插入的cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入cookie，HTTP回复将不带有cookie，恢复流量再次经过进入BIGIP时，BIGIP再次写入更新后的会话保持cookie。
2)Cookie 重写模式
当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个空白的cookie并发回BIGIP，然后BIGIP重新在cookie里写入会话保持数值，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP重写的cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有空的cookie，恢复流量再次经过进入BIGIP时，BIGIP再次写入更新后会话保持数值到该cookie。
3)Passive Cookie 模式，服务器使用特定信息来设置cookie
当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入BIGIP，然后BIGIP根据cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新的会话保持cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。
4)Cookie Hash模式
当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入BIGIP，然后BIGIP根据cookie里的一定的某个字节的字节数来决定后台服务器接受请求，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新后的cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。
1.2.3.SSL Session ID会话保持
在用户的SSL访问系统的环境里，当SSL对话首次建立时，用户与服务器进行首次信息交换以：1）交换安全证书，2）商议加密和压缩方法，3）为每条对话建立Session ID。由于该Session ID在系统中是一个唯一数值，由此，BIGIP可以应用该数值来进行会话保持。当用户想与该服务器再次建立连接时，BIGIP可以通过会话中的 SSL Session ID识别该用户并进行会话保持。
基于SSL Session ID的会话保持就需要客户浏览器在进行会话的过程中始终保持其SSL Session ID不变，但实际上，微软Internet Explorer被发现在经过特定一段时间后将主动改变SSL Session ID，这就使基于SSL Session ID的会话保持实际应用范围大大缩小。
1.3 健康检查
负载均衡是对后台服务器的流量均衡分发，但分发的前提是要求服务器能够正常提供服务，健康检查就是判读服务器是否能够提供服务的方法。F5提供的健康检查方式有将近40种，这里只介绍常用的三种：ICMP、TCP、HTTP。
1.3.1 ICMP
ICMP是最简单的方式，就是对真实服务器发送”ping”命令。“ping”是常用的程序来确认一个IP地址是否在网络中存在，或者用来确认主机是否正常工作。
1.3.2 TCP
F5会试图联接到一个特定应用在运行的TCP端口。简单理解就是通过telnet连接服务的特定端口，如果能够连通，则正常；如果不能连通，则服务有问题。在深入的情况下，还可以在在连通端口后发送特定命令，并判断返回结果。通过是否符合预期来确定服务器工作状态。
1.3.3 HTTP
HTTP用于检查http服务的状态，用户可以定义发送和接受的字符串，发送字串是指发送到一个服务器的请求命令，例如：“GET /” 字符串发送到一个HTTP 服务器。服务器回应得字符串要求与设定的字符串相匹配，例如“f5.com”。如果不匹配则认为服务器有问题，不能提供正常服务。
1.4 节点状态类型
为了更好的控制流量、迁移流量，F5对后台服务器节点操作，形成三种状态：Enabled、Disabled、Forced Offline。
1.4.1 Enabled
Enabled是服务器节点的正常状态，当服务器能够提供正常服务的情况，将该节点设置为Enabled状态，该状态下，服务器节点能够正常提供服务，接收所有请求。
1.4.2 Disabled
Disabled是当服务器需要进行维护时，希望后续流量不分发到该服务节点上时设定的状态。该模式下该服务节点只接收已经建立的连接的信息和已经存在会话保持记录信息的流量信息，不接收没有会话保持记录的新建连接。该状态下，由于一些业务的连接信息或者会话保持记录信息比较长，可能会在很长时间后依然有流量处理。
1.4.3 Forced Offline
Forced Offline是当服务器需要紧急维护时，需要尽快下线设备情况下设定的状态。该模式下该服务节点只接收已经建立的连接的信息，也就是说已经建立的连接的信息继续完成，其他所有请求都会分发到其他服务节点。该状态下，只要不是长连接，基本上都会很快没有流量。
1.5 SSL卸载
SSL的启用增加了业务的安全性，但SSL的加解密会消耗大量的计算资源，为了解决服务器性能不够的问题，可以在F5上进行SSL卸载，即客户端到F5采用SSL加密协议，F5和服务器之间运行http明文协议。这样既实现了业务的加密处理，保证了安全性，也解决了服务器SSL卸载性能不够的问题。
1.5.1 单向认证
单向认证是只需要在服务端配置证书和key，客户端不需要证书。客户端通过获取服务器证书验证服务器的合法性，同时使用服务器证书和服务器进行加密处理。F5作为SSL服务器端，需要导入证书和key，客户端通过访问F5上的SSL服务，同时和F5进行SSL协商，实现SSL加密。
1.5.2 双向认证
双向认证是在单向认证的基础上，要求客户端也提供证书，服务器在协商过程中，也会验证客户端证书的有效性及身份，确保客户端的真实性。F5在配置层面要求在单向认证的基础上，配置客户端证书的根证书，这个根证书用来验证客户端证书的有效性。
1.5.3 加密算法
在SSL卸载中，F5提供了RSA、ECC等各种算法，满足当前SSL的各个版本的要求，同时提供了各种算法的配置方法，包括SSL版本：SSLv2、SSLv3、TLS1.0、TLS1.1、TLS1.2等。目前支持苹果公司要求ATS以及中国网联SSL算法的要求。
1.6 部署方式（串联、并联）
F5设备支持各种灵活的部署方式，常用的有串联和并联两种部署方式。下面分别介绍一下。
1.6.1 串联
串联是F5的最基本部署方式，在这种情况下，F5上配置2个vlan，分别配置不同网段的地址，客户端和服务器端分别位于这两个不同的网段。该部署方式适用于新建网络或者网络出口，便于使用网络隔离的场景。
1.6.2 并联
并联主要用于F5对服务器负载均衡的情况，F5只配置一个vlan，该vlan和服务器在同一网段，为了保证往返路径的一致性，要求F5上启用SNAT功能，这样服务器收到的请求信息的源地址会转换成F5的地址，这样回包的时候，就能够直接回给F5处理。在此情况下，如果服务器需要审计或记录客户端的正式地址则需要特殊处理。这种模式适用于F5对其后端业务按需做负载均衡，这样只有需要做负载均衡的流量才会经过F5，其他流量可直接通过网络转发，不必再次经过F5。
1.6.3 源地址透传
源地址透传是指，将客户端的源地址传递给服务器，用于对用户业务记录或审计。F5有两种方式可以实现源地址透传，第一种：F5不启用SNAT(源地址转换)，同时服务器网关指向F5；第二种：F5将客户端源地址插入到http header中。
第一种方式，主要用户串接模式，服务器网关指向F5，同时F5关闭SNAT。这样服务器收到的数据包的源地址就是客户端的源地址，直接读取即可。这种方式可以适用于TCP协议，http协议也可以使用，但http协议更多使用第二种方式。
第二种方式：F5将客户端源地址插入到http header中。在http协议中有一个header是x-forwarded-for，这个header就是在源地址发生变化后，存储原来的客户端地址，F5可以在做源地址后，将原来的客户端地址存储到x-forwarded-for中，服务器端需要的时候，直接读取这个header即可获取到客户端地址。该方式只适用于http协议，其他协议没有相应的设置。
