分享未来 ^Internet _Technology

HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。 

通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。 

通用头域 

通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。 

Cache-Control头域 

Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下： 

Public指示响应可被任何缓存区缓存。 

Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。 

no-cache指示请求或响应消息不能缓存 

no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。 

max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。 

min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。 

max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。 

Date头域 

Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。 

Pragma头域 

Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache- Control:no-cache相同。 

请求消息 

请求消息的第一行为下面的格式： 

MethodSPRequest-URISPHTTP-VersionCRLFMethod 表示对于Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、 TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。 HEAD方法也是取回由Request-URI标识的信息，只是可以在响应时，不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息，可以用于提交表单，向新闻组、BBS、邮件群组和数据库发送消息。 

SP表示空格。Request-URI遵循URI格式，在此字段为星号（*）时，说明请求并不用于某个特定的资源地址，而是用于服务器本身。HTTP- Version表示支持的HTTP版本，例如为HTTP/1.1。CRLF表示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。 

典型的请求消息： 

GET http://download.microtool.de:80/somedata.exe 
Host: download.microtool.de 
Accept:*/* 
Pragma: no-cache 
Cache-Control: no-cache 
Referer: http://download.microtool.de/ 
User-Agent:Mozilla/4.04[en](Win95;I;Nav) 
Range:bytes=554554- 

上例第一行表示HTTP客户端（可能是浏览器、下载程序）通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息，绿色的部分表示通用头部分。 
Host头域 

Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。 

Referer头域 

Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。 

Range头域 

Range头域可以请求实体的一个或者多个子范围。例如:

表示头500个字节：bytes=0-499 

表示第二个500字节：bytes=500-999 

表示最后500个字节：bytes=-500 

表示500字节以后的范围：bytes=500- 

第一个和最后一个字节：bytes=0-0,-1 

同时指定几个范围：bytes=500-600,601-999 

但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（PartialContent）返回而不是以200 （OK）。 

User-Agent头域 

User-Agent头域的内容包含发出请求的用户信息。 

响应消息 

响应消息的第一行为下面的格式： 

TTP-VersionSPStatus-CodeSPReason-PhraseCRLF 

HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。Status- Code是一个三个数字的结果代码。Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自动识别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别，后两个数字没有分类的作用。第一个数字可能取5个不同的值： 

1xx:信息响应类，表示接收到请求并且继续处理 

2xx:处理成功响应类，表示动作被成功接收、理解和接受 

3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理 

4xx:客户端错误，客户请求包含语法错误或者是不能正确执行 

5xx:服务端错误，服务器不能正确执行一个正确的请求 

响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和 Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一般将会作为实体头域处理。 

典型的响应消息： 

HTTP/1.0200OK 

Date:Mon,31Dec200104:25:57GMT 

Server:Apache/1.3.14(Unix) 

Content-type:text/html 

Last-modified:Tue,17Apr200106:46:28GMT 

Etag:”a030f020ac7c01:1e9f” 

Content-length:39725426 

Content-range:bytes554554-40279979/40279980 

上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体头域的信息。 

Location响应头 

Location响应头用于重定向接收者到一个新URI地址。 

Server响应头 

Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。 

实体 

请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括Allow、Content- Base、Content-Encoding、Content-Language、 Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流，它的编码方式由Content-Encoding或Content-Type定义，它的长度由Content-Length或Content-Range定义。 

Content-Type实体头 

Content-Type实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型 Content-Range实体头 

Content-Range实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式： 

Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth 

例如，传送头500个字节次字段的形式：Content-Range:bytes0- 499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围， Content-Length表示实际传送的字节数。 

Last-modified实体头 

Last-modified实体头指定服务器上保存内容的最后修订时间。  

目的：动态解析home.sst.cn的下级域名，username.home.sst.cn，实现基于虚拟域名（动态域名）的个人空间访问 。

实现步骤：

1.DNS的泛域名解析

以上是在unix bind9下的设置，在windows server中的DNS设置与之同理，略。

2. web服务的设置

为改变虚拟主机顺序，使提供泛域名的web服务为非中心主机(main host)，加入此句：
ServerAlias *.home.sst.cn

　　分析访问过程：
　　　　用户输入[username].home.sst.cn
　　　　　　　　　　　｜
　　　　　　　　　　　｜
　　　　　　　　　　　｜
　　　　　　　　　　　｀－－＞apache分析主机头的值，不匹配任何一
　　　　　　　　　　　　　　　个虚拟主机名，则交送中心主机的目录
　　　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　 接下来应该有两种方法处理：＜－－＇
　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　＾ 
　　　　　　　　　　　　＇　　｀
　　　　　　　　　 　　／　　　　＼
① 在home.sst.cn的根目录     　　　　② 用mod_rewrite重写
设跳转文件，ASP代码举例：                URL指向[username]目录。
　　　　　｜　　　　　　　　　　　　　　　　　｜
　　　　　｜　　　　　　　　　　　　　　　　　｜
　　　　　｜　　　　　　　　　　　　　　　　　｜

方法①纯代码方式，无用户目录。

方法②用mod_rewrite重写URL，指向用户目录。

在blog的主目录下建立.htaccess文件，内容为:

[code="plain"]

RewriteEngine On
#RewriteRule ^(.*)/home/(.*)$ $1.php?$2

[/code]

一、问题起源

稍大一些的网站，通常都会有好几个服务器，每个服务器运行着不同功能的模块，使用不同的二级域名，而一个整体性强的网站，用户系统是统一的，即一套用户名、密码在整个网站的各个模块中都是可以登录使用的。各个服务器共享用户数据是比较容易实现的，只需要在后端放个数据库服务器，各个服务器通过统一接口对用户数据进行访问即可。但还存在一个问题，就是用户在这个服务器登录之后，进入另一个服务器的别的模块时，仍然需要重新登录，这就是一次登录，全部通行的问题，映射到技术上，其实就是各个服务器之间如何实现共享 SESSION 数据的问题。

二、PHP SESSION 的工作原理

在解决问题之前，先来了解一下 PHP SESSION 的工作原理。在客户端（如浏览器）登录网站时，被访问的 PHP 页面可以使用 session_start() 打开 SESSION，这样就会产生客户端的唯一标识 SESSION ID（此 ID 可通过函数 session_id() 获取/设置）。SESSION ID 可以通过两种方式保留在客户端，使得请求不同的页面时，PHP 程序可以获知客户端的 SESSION ID；一种是将 SESSION ID 自动加入到 GET 的 URL 中，或者 POST 的表单中，默认情况下，变量名为 PHPSESSID；另一种是通过 COOKIE，将 SESSION ID 保存在 COOKIE 中，默认情况下，这个 COOKIE 的名字为 PHPSESSID。这里我们主要以 COOKIE 方式进行说明，因为应用比较广泛。

那么 SESSION 的数据保存在哪里呢？当然是在服务器端，但不是保存在内存中，而是保存在文件或数据库中。默认情况下，php.ini 中设置的 SESSION 保存方式是 files（session.save_handler = files），即使用读写文件的方式保存 SESSION 数据，而 SESSION 文件保存的目录由 session.save_path 指定，文件名以 sess_ 为前缀，后跟 SESSION ID，如：sess_c72665af28a8b14c0fe11afe3b59b51b。文件中的数据即是序列化之后的 SESSION 数据了。如果访问量大，可能产生的 SESSION 文件会比较多，这时可以设置分级目录进行 SESSION 文件的保存，效率会提高很多，设置方法为：session.save_path="N;/save_path"，N 为分级的级数，save_path 为开始目录。当写入 SESSION 数据的时候，PHP 会获取到客户端的 SESSION_ID，然后根据这个 SESSION ID 到指定的 SESSION 文件保存目录中找到相应的 SESSION 文件，不存在则创建之，最后将数据序列化之后写入文件。读取 SESSION 数据是也是类似的操作流程，对读出来的数据需要进行解序列化，生成相应的 SESSION 变量。

三、多服务器共享 SESSION 的主要障碍及解决办法

通过了解 SESSION 的工作原理，我们可以发现，在默认情况下，各个服务器会各自分别对同一个客户端产生 SESSION ID，如对于同一个用户浏览器，A 服务器产生的 SESSION ID 是 30de1e9de3192ba6ce2992d27a1b6a0a，而 B 服务器生成的则是 c72665af28a8b14c0fe11afe3b59b51b。另外，PHP 的 SESSION 数据都是分别保存在本服务器的文件系统中。如下图所示：

确定了问题所在之后，就可以着手进行解决了。想要共享 SESSION 数据，那就必须实现两个目标：一个是各个服务器对同一个客户端产生的 SESSION ID 必须相同，并且可通过同一个 COOKIE 进行传递，也就是说各个服务器必须可以读取同一个名为 PHPSESSID 的 COOKIE；另一个是 SESSION 数据的存储方式/位置必须保证各个服务器都能够访问到。简单地说就是多服务器共享客户端的 SESSION ID，同时还必须共享服务器端的 SESSION 数据。

第一个目标的实现其实很简单，只需要对 COOKIE 的域（domain）进行特殊地设置即可，默认情况下，COOKIE 的域是当前服务器的域名/IP 地址，而域不同的话，各个服务器所设置的 COOKIE 是不能相互访问的，如 www.aaa.com 的服务器是不能读写 www.bbb.com 服务器设置的 COOKIE 的。这里我们所说的同一网站的服务器有其特殊性，那就是他们同属于同一个一级域，如：aaa.infor96.com 和 www.infor96.com 都属于域 .infor96.com，那么我们就可以设置 COOKIE 的域为 .infor96.com，这样 aaa.infor96.com、www.infor96.com 等等都可以访问此 COOKIE。PHP 代码中的设置方法如下：
[code="php"]
ini_set('session.cookie_domain', '.infor96.com');
?>
[/code]

这样各个服务器共享同一客户端 SESSION ID 的目的就达到了。

第二个目标的实现可以使用文件共享方式，如 NFS 方式，但设置、操作上有些复杂。我们可以参考先前所说的统一用户系统的方式，即使用数据库来保存 SESSION 数据，这样各个服务器就可以方便地访问同一个数据源，获取相同的 SESSION 数据了。

解决办法如下图所示：

四、代码实现

首先创建数据表，MySQL 的 SQL 语句如下：
[code="sql"]
CREATE TABLE `sess` (
`sesskey` varchar(32) NOT NULL default '',
`expiry` bigint(20) NOT NULL default '0',
`data` longtext NOT NULL,
PRIMARY KEY (`sesskey`),
KEY `expiry` (`expiry`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
[/code]

sesskey 为 SESSION ID，expiry 为 SESSION 过期时间，data 用于保存 SESSION 数据。

默认情况下 SESSION 数据是以文件方式保存，想要使用数据库方式保存，就必须重新定义 SESSION 各个操作的处理函数。PHP 提供了session_set_save_handle() 函数，可以用此函数自定义 SESSION 的处理过程，当然首先要先将 session.save_handler 改成 user，可在 PHP 中进行设置：
[code="php"]
session_module_name('user');
?>
[/code]
接下来着重讲一下 session_set_save_handle() 函数，此函数有六个参数：
session_set_save_handler ( string open, string close, string read, string write, string destroy, string gc )

各个参数为各项操作的函数名，这些操作依次是：打开、关闭、读取、写入、销毁、垃圾回收。PHP 手册中有详细的例子，在这里我们使用 OO 的方式来实现这些操作，详细代码如下：

[code="php"]
define('MY_SESS_TIME', 3600); //SESSION 生存时长
//类定义
class My_Sess
{
function init()
{
$domain = '.infor96.com';
//不使用 GET/POST 变量方式
ini_set('session.use_trans_sid', 0);
//设置垃圾回收最大生存时间
ini_set('session.gc_maxlifetime', MY_SESS_TIME);

//使用 COOKIE 保存 SESSION ID 的方式
ini_set('session.use_cookies', 1);
ini_set('session.cookie_path', '/');
//多主机共享保存 SESSION ID 的 COOKIE
ini_set('session.cookie_domain', $domain);

//将 session.save_handler 设置为 user，而不是默认的 files
session_module_name('user');
//定义 SESSION 各项操作所对应的方法名：
session_set_save_handler(
array('My_Sess', 'open'), //对应于静态方法 My_Sess::open()，下同。
array('My_Sess', 'close'),
array('My_Sess', 'read'),
array('My_Sess', 'write'),
array('My_Sess', 'destroy'),
array('My_Sess', 'gc')
);
} //end function

function open($save_path, $session_name) {
return true;
} //end function

function close() {
global $MY_SESS_CONN;

if ($MY_SESS_CONN) { //关闭数据库连接
$MY_SESS_CONN->Close();
}
return true;
} //end function

function read($sesskey) {
global $MY_SESS_CONN;

$sql = 'SELECT data FROM sess WHERE sesskey=' . $MY_SESS_CONN->qstr($sesskey) . ' AND expiry>=' . time();
$rs =& $MY_SESS_CONN->Execute($sql);
if ($rs) {
if ($rs->EOF) {
return '';
} else { //读取到对应于 SESSION ID 的 SESSION 数据
$v = $rs->fields[0];
$rs->Close();
return $v;
} //end if
} //end if
return '';
} //end function

function write($sesskey, $data) {
global $MY_SESS_CONN;

$qkey = $MY_SESS_CONN->qstr($sesskey);
$expiry = time() + My_SESS_TIME; //设置过期时间

//写入 SESSION
$arr = array(
'sesskey' => $qkey,
'expiry' => $expiry,
'data' => $data);
$MY_SESS_CONN->Replace('sess', $arr, 'sesskey', $autoQuote = true);
return true;
} //end function

function destroy($sesskey) {
global $MY_SESS_CONN;

$sql = 'DELETE FROM sess WHERE sesskey=' . $MY_SESS_CONN->qstr($sesskey);
$rs =& $MY_SESS_CONN->Execute($sql);
return true;
} //end function

function gc($maxlifetime = null) {
global $MY_SESS_CONN;

$sql = 'DELETE FROM sess WHERE expiry<' . time();
$MY_SESS_CONN->Execute($sql);
//由于经常性的对表 sess 做删除操作，容易产生碎片，
//所以在垃圾回收中对该表进行优化操作。
$sql = 'OPTIMIZE TABLE sess';
$MY_SESS_CONN->Execute($sql);
return true;
} //end function
} ///:~

//使用 ADOdb 作为数据库抽象层。
require_once('adodb/adodb.inc.php');
//数据库配置项，可放入配置文件中（如：config.inc.php）。
$db_type = 'mysql';
$db_host = '192.168.212.1';
$db_user = 'sess_user';
$db_pass = 'sess_pass';
$db_name = 'sess_db';
//创建数据库连接，这是一个全局变量。
$GLOBALS['MY_SESS_CONN'] =& ADONewConnection($db_type);
$GLOBALS['MY_SESS_CONN']->Connect( $db_host, $db_user, $db_pass, $db_name);
//初始化 SESSION 设置，必须在 session_start() 之前运行！！
My_Sess::init();
?>
[/code]

Q: 服务器负载均衡有哪些实现方法？
A: 实现服务器负载均衡有多种方法，常见的方法有：
1.基于DNS 轮询的方法：即在DNS 服务器中对同一域名设置多条DNS A 记录，
通过DNS 的轮询机制实现服务器负载均衡。
2.基于服务器集群的方法；
3.基于应用软件的实现方法，在应用软件设计中就考虑了多服务器之间的协同工作
与任务调度。这种方法一般会有一台服务器作为中枢对访问请求进行调度，同时
要求在应用层支持访问重定向或任务调度、跳转机制。
4.采用专门的L4/L7 层交换机来实现，也即我们常说的负载均衡器。一般都是通过
在L4/L7 层交换机作地址转换（NAT）来实现。
5.基于代理方式的负载均衡算法。

----------------------------------------------------------------------------------
Q: 请简单介绍F5 L4/L7 层交换机对服务器作负载均衡的工作过程。
A: F5 L4/L7 层交换机对服务器作负载均衡时主要包括以下几个过程：
1.截获和检查分析流量：保证只有合适的数据包才能通过
2.服务器监控和健康检查：随时了解服务器群的可用性状态
3.负载均衡和应用交换功能：通过各种策略或负载均衡算法将访问请求导向到合适的服务
器，这一过程包括目标服务器的选择及地址转换（NAT）过程。
4.会话的保持(Persistence)：通过会话保持，保证一系列相关连的会话不会被负载均衡到
不同的服务器上。

 
----------------------------------------------------------------------------------
Q: F5 L4/L7 层交换机对服务器作负载均衡时是怎样做地址转换的（NAT）。
A: F5 L4/L7 层交换机对服务器作负载均衡是采用基于网络地址转换(NAT)的负载均衡技
术 。 如：负载均衡器后面的一组服务器10.1.1.4:80、10.1.1.5:80、10.1.1.6:80 对外构成一台虚拟
的服务器（Virtual Server）192.168.101.1:80，对外提供服务。当一个访问虚拟服务器
192.168.101.1:80 的请求到达负载均衡器以后，负载均衡器根据预先设定的负载均衡算法从服
务器pool(WEB_POOL)中挑选一台服务器来服务该请求，例如选定的是10.1.1.4:80；然后通
过网络地址转换（NAT）将访问请求包的目的地址与端口转换成10.1.1.4:80，并将数据包发给
10.1.1.4。服务器10.1.1.4 处理访问请求，并作出回应。回应的包必须返回到负载均衡器上，
由负载均衡器将回应包的源地址与端口转换回虚拟服务器的地址与端口，并返回给客户。这样
完成一次访问过程。

----------------------------------------------------------------------------------
Q: 什么叫会话保持(Persistence)?
A: 会话保持(persistence)是负载均衡中一个特定而重要的概念。
一个客户与服务器经常经过好几次的交互过程才能完成一笔交易。由于这几次交互过
程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互
过程的处理结果，这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡
器分散到不同的服务器上。
而这一系列的相关的交互过程可能是由客户到服务器的一个连接的多次会话完成，也
可能是在客户与服务器之间的多个不同连接里的多次会话完成。不同连接的多次会话，最典型
的例子就是基于http 的访问，一个客户完成一笔交易可能需多次点击，而一个新的点击产生
的请求，可能会重用上一次点击建立起来的连接，也可能是一个新建的连接。
会话保持就是指在负载均衡器上有这么一种机制，可以识别做客户与服务器之间交互
过程的关连性，在作负载均衡的同时，还保证一系列相关连的访问请求会保持分配到一台服务
器上。

----------------------------------------------------------------------------------
Q: 基于Layer 4 的负载均衡与基于Layer 7 的负载均衡有什么区别？
A: 基于Layer 4 的负载均衡在截取数据流以后，对数据包要检查与分析的部份仅仅限于IP 报
头及TCP/UDP 报头，而不关心TCP 或UDP 包内部信息。而基于Layer7 的负载均衡，则要
求负载均衡器除了支持Layer4 负载均衡以外，还要理解数据包中4 层以上的信息，也即应用
层的信息。例如，可以理解分析http 协议，从数据包中提取出http uri 或cookie 信息。基于
Layer4 与基于Layer7 负载均衡或交换对数据包检查的深度不一样，基于Layer4 的交换偏重
的是网络层，而Layer7 偏重的是应用层，与应用结合很紧密。负载均衡器在作这两种方式的
负载均衡时的性能也不一样。

----------------------------------------------------------------------------------
Q: 为什么需要基于Layer7 的负载均衡？
A: 简单来说，之所以需要基于Layer7 的负载均衡，有以下原因：
1.会话保持(Persistence)的需要：在很多应用中，单靠Layer4 层的信息，也即IP 地址
与端口的信息，是不足以分辨出会话的相关性。这样要实现会话保持，就必须依靠
于Layer7 交换。
2.应用安全的需要：要做到应用级的安全，负载均衡器必须能检查、分析应用层的信
息，并以此作为流量分发、访问控制的依据。
3.服务器、应用健康检查的需求：如前面所述，负载均衡器还有一个重要任务就是要及
时发现服务器上的异常情况，这种异常情况不仅仅限于网络故障，还包括服务或应
用能不能对访问请求作出正确的响应。这也是要通过对数据包的应用层进行分析才
能实现。

----------------------------------------------------------------------------------
Q: 对Lay4-7 层交换机或应用交换机一般要关注、了解哪些方面？
A: 一般来说，对Lay4-7 层交换机或应用交换机，一般会提到以下几个因素：
支持的负载均衡算法
支持的服务器健康检查的方法
如何保持客户端和服务器的会话
速度/性能指标
安全性与可靠性
端口数量

----------------------------------------------------------------------------------
Q: F5 Bigip 负载均衡器支持哪些负载均衡算法？
A: F5 Bigip 负载均衡器支持的负载均衡算法包括：
1.轮询（RoundRobin）：顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器
发生第二到第7 层的故障，BIG/IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复
正常。
2.比率（Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每
个服务器。当其中某个服务器发生第二到第7 层的故障，BIG/IP 就把其从服务器队列中拿出，不参加
下一次的用户请求的分配，直到其恢复正常。
3.优先权（Priority）：给所有服务器分组，给每个组定义优先权，BIG/IP 用户的请求，分配给优
先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服
务器出现故障，BIG/IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的
方式。
4.最小的连接数（LeastConnection）：传递新的连接给那些进行最少连接处理的服务器。当其
中某个服务器发生第二到第7 层的故障，BIG/IP 就把其从服务器队列中拿出，不参加下一次的用户请
求的分配，直到其恢复正常。
5.最快模式（Fastest）：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7
层的故障，BIG/IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
6.观察模式（Observed）：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服
务器。当其中某个服务器发生第二到第7 层的故障，BIG/IP 就把其从服务器队列中拿出，不参加下一
次的用户请求的分配，直到其恢复正常。
7.预测模式（Predictive）：BIG/IP 利用收集到的服务器当前的性能指标，进行预测分析，选择
一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被big/ip 进行检测)
8.规则模式（iRule）：针对不同的数据流设置导向规则，用户可自行编辑流量分配规则，BIG/IP
利用这些规则对通过的数据流实施导向控制。

 
----------------------------------------------------------------------------------
Q: F5 Bigip 负载均衡器支持哪些服务器健康检查方法？
A: F5 Bigip 负载均衡器支持以下的服务器健康检查方法：
1.服务器 (Node) - Ping (ICMP)
2.服务 (Port) － Connect
3.可扩展的应用验证 (EAV) :不仅仅检查服务器上指定服务的端口是否处于监听状态，还要检查该
服务端口能否对应用访问请求作出回应，例如可以检查对http 请求或对数据库的查询能否作出
回应。
4.可扩展的内容验证 (ECV)：Bigip 除了可以通过EAV 对服务进行检查，还可以通过ECV 对服务
器的响应作进一步分析，通过分析读取服务器回应中的指定内容来判断服务器上服务的运行情
况。上述检查方法的检查频度（e.g. 10 seconds）与检查响应Timeout 时间（ e.g. 5
seconds）都可以根据应用情况进行灵活定制。
对于ECV、EAV，在Bigip 中已经包含了一些常见应用的检查与内容验证的方法，例如
http 的检查、Ldap、SQL Server 等。如果碰到一些应用、Bigip 上没有提供相应的检查
方法，Bigip 还提供了一个扩展的接口，用户只需要编写相应的应用检查脚本或程序并加载
到Bigip 就可实现对该应用的检查或内容验证。

----------------------------------------------------------------------------------
Q: F5 Bigip 支持哪些会话保持方法？
A:
1.简单会话保持
– 根据客户端源IP 地址保持客户会话的技术
2.HTTP Header
– 根据HTTP 包头信息保持会话的技术
3.SSL ID 会话保持
– 根据SSL ID 保持客户/服务器连接的技术
4.HTTP Cookie 会话保持
– 插入模式,改写模式, 被动模式, 散列模式(Cookie Hash)
5.SIP ID 会话保持
6.Cache 设备的专用会话保持
7.i-Mode 移动应用的会话保持技术
8.i-Rules 客户定制的会话保持方法

----------------------------------------------------------------------------------
Q: Lay4-7 层交换机或应用交换机有哪些速度、性能指标比较重要？
A:
1.Session/Second :
– 每秒处理的会话数量,有Lay4 和Lay7 的区别
2.Maximum connection :
– 最多能够保持的连接数量,即最多能够保持多少个并发的会话连接
3.Throughput : 吞吐率 (bps)
– 有Lay4 和Lay7 的区别
4.VIP Maximum Number :(支持的虚拟服务器个数)
– 最多同时多少应用可以做负载均衡

----------------------------------------------------------------------------------
Q: F5 Bigip 应用交换机支持的最大连接数是多少？
A: F5 Bigip 应用交换机对客户到服务器之间的每一条连接都要维护一条记录，当连接开始
建立时，Bigip 会根据负载均衡算法将客户的请求分配到一台服务器上。连接建立以后，对这
个连接内的所有会话将不再需要通过负载均衡算法来选择服务器，而是根据系统中原有的连接
表直接进行地址转换及交换。如果连接没有被主动关闭，即使连接处于闲置状态，应用交换机
中的相应的连接表也会保持一段时间，直到Timeout 为止。
F5 Bigip 应用交换机采用的是共享内存与中央CPU 的体系结构，系统支持的最大连接数只与
系统配置的内存数量有关。一般来说：
当系统配置的内存是512M 时，支持的最大连接数是100 万；
当系统配置的内存是1G 时，支持的最大连接数是200 万；
当系统配置的内存是2G 时，支持的最大连接数是400 万；
上述参数适用于Bigip1000、 Bigip 2400、Bigip 5000 三个型号。至于随着Bigip 上连接数
的增加，系统处理会话的速度会不会下降，由于Bigip 对连接表的查询是采用的hash 算法，
查询速度与连接表的数量没有关系。

----------------------------------------------------------------------------------
Q: F5 Bigip 应用交换机每秒会话处理能力是多少？
A: 在应用交换机中Layer4 的每秒会话处理能力与Layer7 的每秒会话处理能力是不一样的。
另外每秒会话处理能力还与数据包的大小有关系。每秒会话处理能力反应了应用交换机对数据
包或会话的处理能力，与系统的负载均衡算法、地址转换能力有关。
Lyaer4 的交换可以通过ASCI 芯片硬件来处理，所以性能会高一些。而Layer7 的会话处理过
程必须通过CPU 进行，更多的依赖于CPU 的处理能力。
在F5 Bigip 产品系列中，Bigip2400 采用了最新的Layer4 ASCI 芯片，所以Layer4 的每秒会
话处理能力最强；而Bigip5000 采用了两个CPU，所以Layer 7 的每秒会话处理能力最强。
F5 Bigip2400 的Layer4 最大会话处理能力是：125000 Layer 4 sessions per second at a data return
file size of 64 bytes。
F5 Bigip5000 的Layer7 最大会话处理能力是：19000 sessions per second。