F5会话保持的理解

1．什么是会话保持？在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。   而这一系列的相关的交互过程可能是由客户到服务器的一个连接的多次会话完成，也可能是在客户与服务器之间的多个不同连接里的多次会话完成。不同连接的多次会话，最典型的例子就是基于http的访问，一个客户完成一笔交易可能需多次点击，而一个新的点击产生的请求，可能会重用上一次点击建立起来的连接，也可能是一个新建的连接。   会话保持就是指在负载均衡器上有这么一种机制，可以识别做客户与服务器之间交互过程的关连性，在作负载均衡的同时，还保证一系列相关连的访问请求会保持分配到一台服务器上。2．F5支持什么样的会话保持方法？   F5Big-IP支持多种的会话保持方法，其中包括：简单会话保持（源地址会话保持）、HTTPHeader的会话保持，基于SSLSessionID的会话保持，i-Rules会话保持以及基于HTTPCookie的会话保持，此外还有基于SIPID以及Cache设备的会话保持等，但常用的是简单会话保持，HTTPHeader的会话保持以及HTTPCookie会话保持以及基于i-Rules的会话保持。简单会话保持   简单会话保持也被称为基于源地址的会话保持，是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关连会话的依据。对来自同一IP地址的所有访问请求在作负载均时都会被保持到一台服务器上去。在BIG-IP设备上可以为“同一IP地址”通过网络掩码进行区分，比如可以通过对IP地址进行的网络掩码，这样只要是来自于这个网段的流量BIGIP都可以认为他们是来自于同一个用户，这样就将把来自于网段的流量会话保持到特定的一台服务器上。   简单会话保持里另外一个很重要的参数就是连接超时值，BIGIP会为每一个进行会话保持的会话设定一个时间值，当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值，BIGIP将会将新的连接进行会话保持，但如果这个间隔大于该超时值，BIGIP将会将新来的连接认为是新的会话然后进行负载平衡。   基于原地址的会话保持实现起来简单，只需要根据数据包三、四层的信息就可以实现，效率也比较高。存在的问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 就在于当多个客户是通过代理或地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况上客户机数量很少，但每个客户机都会产生多个并发访问，对这些并发访问也要求通过负载均衡器分配到多个服器上，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。基于Cookie的会话保持Cookie插入模式：   在Cookie插入模式下，Big-IP将负责插入cookie，后端服务器无需作出任何修改   当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIG-IP，BIG-IP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带cookie）被发回BIGIP，然后BIG-IP插入cookie，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP插入的cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入cookie，HTTP回复将不带有cookie，恢复流量再次经过进入BIG-IP时，BIG-IP再次写入更新后的会话保持cookie。Cookie重写模式   当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP，BIGIP根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个空白的cookie并发回BIGIP，然后BIGIP重新在cookie里写入会话保持数值，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP重写的cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有空的cookie，恢复流量再次经过进入BIGIP时，BIGIP再次写入更新后会话保持数值到该cookie。PassiveCookie模式，服务器使用特定信息来设置cookie。   当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP，BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入BIGIP，然后BIGIP根据cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新的会话保持cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。CookieHash模式：   当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP，BIGIP根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入BIGIP，然后BIGIP根据cookie里的一定的某个字节的字节数来决定后台服务器接受请求，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新后的cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。SSLSessionID会话保持   在用户的SSL访问系统的环境里，当SSL对话首次建立时，用户与服务器进行首次信息交换以：1}交换安全证书，2）商议加密和压缩方法，3）为每条对话建立SessionID。由于该SessionID在系统中是一个唯一数值，由此，BIGIP可以应用该数值来进行会话保持。当用户想与该服务器再次建立连接时，BIGIP可以通过会话中的SSLSessionID识别该用户并进行会话保持。   基于SSLSessionID的会话保持就需要客户浏览器在进行会话的过程中始终保持其SSLSessionID不变，但实际上，微软InternetExplorer被发现在经过特定一段时间后将主动改变SSLSessionID，(IE标准缓存SSLID5分钟，BIGIP LTM默认缓存SSLID1小时)这就使基于SSLSessionID的会话保持实际应用范围大大缩小。基于HTTPHeader的会话保持BIGIP可以根据用户HTTP访问里http包头信息信息进行会话保持，HTTP包头里包含以下信息，BIGIP可以将用户访问里这些信息通过表达式来获得相应的数值从而进行会话保持。·Accept：浏览器可接受的MIME类型。·Accept-Charset：浏览器可接受的字符集。·Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。·Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。·Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。·Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP（HTTP默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。·Content-Length：表示请求消息正文的长度。Cookie：这是最重要的请求头信息之一，参见后面《Cookie处理》一章中的讨论。·From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。·Host：初始URL中的主机和端口。·If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“NotModified”应答。·Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。·Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。·User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。基于I-Rules的会话保持BIGIP交换机内置有强大的搜索引擎，可以高效的探测到网络流量中的IP包内容的部分，并可以读出该IP包内容部分的进行会话保持，这些内容部分包括如下部分:下面是一个BIGIP根据IRULES进行会话保持的范例：if(http_uriends_with“.gif”){usepoolimage_servers}elseif(http_uristarts_with“/foo”){usepoolfoo_servers}elseif(http_cookie(“XYZ-Type”)==“direct”){usepoolcookie_servers}elseif(findstr(http_uri,“type=”,6,“&”)==“cgi”){usepoolcgi_servers}else{usepoolweb_servers}在此I-Rules里，可以看到，如果用户的uri部分以.gif字段结尾，也就是说如果用户访问的是图片服务器，则将用户的访问会话保持在图片服务器上；而如果用户的uri部分以/foo开始，则将会话保持到相应的服务器上。同样，根据用户访问中的cookie字段以及uri里面的某个特定便宜字段里是否与规定的类型相符，从而进行相应的会话保持。服务器实际地址与端口提供服务的真实服务器IP地址与提供服务的端口。对外服务地址与端口F5设备向外提供服务的IP地址与端口，此选项可向网络处申请。负载均衡算法F5设备向服务器下发请求的分发方式。F5设备默认的是轮询,（例如：有两个提供服务的真实服务器，F5会把两个请求分别分配给服务器1和服务器2）会话保持类型会话保持可以将一个客户的持续请求落在一台服务器上。常用的会话保持类型有cookie与源地址方式。F5设备默认无会话保持。会话保持时间可以自定义需要保持的会话在多长时间内有效，或者只基于浏览器创建的一个会话。长连接保持一个连接的有效性。客户向提供服务的真实服务器先建立起通讯的连接，连接建立后并不断开（是否断开由长连接的时间决定），然后再进行报文的传输。长连接时间F5默认5分钟允许一个连接空闲的时间有多长，F5设备默认的是5分钟，也就是在5分钟内F5设备不会中断此连接。互访关系提供服务的服务器与服务器之间是否存在互访关系。透传源地址业务层面是否需要对客户的真实地址做了解，如果需要,F5设备将配置透传客户的源地址信息给后端提供服务的服务器。探测类型要求F5设备使用哪种类型做提供服务的服务器健康检查（健康检查就是F5设备检查提供服务的真实服务器是否可用的代名词）。在行内常用到的有HTTP与TELNET，（例如，F5配置了Telnet的类型后，F5设备就会定期对提供服务的真实服务器发送telnet的探测包，如果在定义的时间内没有返回信息给F5，F5便会停止此真实服务器对外提供服务。但F5会一直按照规定发送Telnet探测包至服务器，直到服务器给予正确的回应后，F5便恢复此服务器。）检查条件根据在检查类型中定义的类型，来填写检查条件，（例如“检查类型”填写的是ICMP，“检查条件”应填写）成功返回值如果检查类型填写的是HTTP或者其他自定义的类型，那么在成功返回值中应该填写真实服务器正确返回给F5的是什么信息，F5即认为服务器是可用的。探测包发送间隔第一次探测与第二次探测的间隔时间。F5设备默认的间隔时间是5秒钟。即F5设备会每隔5秒钟对真实服务器发送一次探测包，来探测真实服务器是否正常。探测包重传次数连续探测多少次服务器。F5设备默认的次数是3次。即F5设备会每隔5秒钟对真实服务器做状态探测，如果连续3次没有返回给F5正确的信息后，F5便会将此真实服务器从提供服务的服务组里面摘除，直到其变为可用服务器后在放回提供服务的服务组里面。服务器最大响应时间提供服务的真实服务器在停止多长时间没有给F5正确的探测回应，F5便可以把此服务器从提供服务的服务组里面摘除。F5设备默认的是：间隔时间×重传次数+1=最大响应时间。（例如：F5设备默认的发送间隔是5秒钟，重传次数是3次，那么最大响应时间应该是5×3+1=16秒）一、负载均衡算法随机（Random）——随机分发轮询（RoundRobin） ——将请求依次顺序循环地分发给服务器，从1到N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。权重（WeightedRoundRobin）——根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。动态比率（DynamicRoundRobin）——类似于权重，不过权重值是随着对服务器持续的监控而变化的。这是一个动态的负载均衡算法，基于对服务器性能的实时分析，如连接数或响应时间。最快模式（Fastest）——传递连接给那些响应速度最快的服务器。这种算法可能对于服务器处于不同的逻辑网络中的情况特别有用。均衡器记录着每个服务器的响应时间并选择最快的那一个。这非常直接了当，但是可能会导致拥塞，因为当前的响应时间并不一定真的还是1s或是2s了。最小连接数（LeastConnections）——最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。观察模式（Observed）——以连接数和响应时间这两项的最佳平衡为依据来为新的请求选择服务器。预测模式（Predictive）——预测模式使用和观察模式一样的评选方法，只不过BIGIP会利用收集到的服务器当前的性能指标（连接数和响应时间），进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器来响应用户的请求。预测模式试图修复在观察模式中的一个问题，如果服务器的响应时间已经开始下滑，那么它是不太可能接受下一个请求的。