第三章 服务器负载均衡技术进阶

对于一个刚刚接触负载均衡器的用户来说，我们已经讨论了足够多的负载均衡方面的知识。但是要想使用高级的功能时，就需要了解一些高级的技术。本章中，我们将讨论应用系统负载均衡时必不可少的技术，会话保持和URL交换。

由于TCP协议提供可靠的数据传输，因此主流的应用系统都是运行在TCP协议之上。TCP是一个面向连接的协议，客户端和服务器需要建立一个TCP连接来交换数据。但是我们在第二章谈到，基于Web的应用系统，如HTTP，在客户端和服务器之间会产生多个TCP连接。如果把应用级的最小单位定义为一个交易，那每个交易都会产生多个TCP连接。负载均衡器是针对每个TCP连接进行分发，并不了解TCP层以上的应用交易的处理情况。在本节，我们会讨论TCP协议之上的应用交易的行为，是如何影响负载均衡器功能的。

首先我们定义一个应用交易的任务，比如在Amazon.com上面购买一本书。一个应用交易需要客户端和服务器之间建立多个TCP连接，交互数次才能完成。以电子商务网站的购物车应用为例，客户端浏览器与Web服务器之间请求和响应的流程如图3.1所示：

首先，浏览器新建一个访问Web站点的TCP连接，并发送一个HTTP GET请求。服务器返回组成页面的所有的对象，浏览器获取每个对象并组成一个完整的页面。当用户点击其他的链接，如“购买此书”或“搜索”时，浏览器打开另外一个TCP连接发送请求，并接收服务器回应的多个对象组成一个页面。当用户向购物车中添加商品时，服务器必须保留客户的购物车信息。当后台只有一台服务器时，用户所有的连接都会发送给同一台服务器。

现在为了提高系统的可扩展性，我们部署了负载均衡器在多台服务器之间分发请求。负载均衡器接收每个TCP连接，并根据每台服务器的压力不同转发给不同的服务器，如图3.2所示。假设用户通过第一个连接在购物车中添加了一个商品，这个连接被负载均衡器转发到第一台服务器，如果下一个连接被发送到第二台服务器，而这台服务器没有购物车的任何信息，应用就被迫中断。为了解决这个问题，负载均衡器必须在整个交易过程中把同一个客户端所有的请求转发到同一服务器上，如图3.3所示。负载均衡器将来自同一个客户端的所有的会话保持在一台服务器上面，我们称之为会话保持，有时也称做会话粘滞。问题是，负载均衡器是如何确认一个应用级会话的开始和结束的呢?

在一个只读的环境中，所有的服务器都提供相同的内容，这时并不存在会话保持的问题。例如，如果客户浏览Yahoo主页，把客户端连接分发到不同的服务器并不会产生任何问题。如果客户在Yahoo上注册一个账号，并个性化设置页面，那么服务器根据客户的账号信息来提供正确的内容。这时，就出现了会话保持的问题。

我们先快速回顾一下会话保持的定义，它是指在应用交易的过程中把一个用户所有的会话都转发到同一台服务器。为了实现会话保持，负载均衡器必须做两件事： 如何确定是同一个客户，如何确认应用交易的开始和结束。

当负载均衡器接收到一个新的连接时，它的处理方式有两种，进行负载均衡或者做会话保持处理。更确切的说，第一种处理方式就是根据服务器的健康状况和负载情况选择一台服务器接收这个连接，另外一种就是根据TCP SYN数据包头的信息在负载均衡器的会话表中查找，确认是否保存有会话信息，并根据会话信息找到相应的服务器接收此连接。也就是说，负载均衡是根据服务器的状态来选择服务器，而会话保持则根据数据包中的信息来选择服务器。

为了实现会话保持，TCP SYN数据包中哪些信息是有用的呢？TCP SYN数据包中包含源IP地址、源端口、目的IP地址和目的端口。首先想到的就是源IP地址，除此之外，负载均衡器能否根据用户请求的内容选择服务器呢？通过查看用户请求的数据，我们能够获取很多有用的应用层信息。基于上述内容，会话保持技术可以大致分为两类：根据TCP SYN数据包的信息来实现会话保持，或者根据用户请求的应用层信息来做会话保持。根据TCP SYN数据包的信息实现会话保持的技术就是基于源IP地址来实现的，这是确认一个用户的关键，我们称之为基于源IP地址的会话保持方法。

当接收到一个TCP SYN数据包后，负载均衡器会在其会话表中查询是否有这个源IP地址的会话纪录。如果没有找到，负载均衡器就认为这是一个新用户的请求，根据负载均衡算法选择一台合适的服务器，并转发此TCP SYN数据包，同时在会话表中增加一条纪录。如果在会话表中存在这个源IP地址的纪录，负载均衡器将会把这个TCP SYN请求包转发到之前处理请求的同一台服务器上，不再通过负载均衡算法选择服务器。当接收到一个TCP FIN或RESET数据包，负载均衡器将中止这个会话，但是在会话表中会继续保留这条纪录，以记住这个连接的源IP地址，和处理这个连接的服务器的地址。

由于负载均衡器并不理解应用层协议，它不知道应用交易何时开始和结束，以便继续或中止会话保持处理。因此，在进行会话保持时，负载均衡器会为会话表中每一条记录都启动一个计时器，计时器从用户最后一次活动的连接结束时开始计时。这个计时器也称作会话保持计时器，主要记录连接空闲的时长。在计时器超时之前如果用户没有新的连接请求，负载均衡器就会把这个用户相应的会话保持记录删除。如果在计时器超时之前收到了用户新的连接请求，负载均衡器会重置计时器，并在用户最后一次活动连接结束时重新启动。

基于源IP地址的会话保持也有几种不同的方式，理解它们的不同非常重要。当进行会话保持时，负载均衡器将后续的连接发送到同一台服务器而不考虑服务器的负载压力状况。如果那台服务器很繁忙，客户端的响应就会非常缓慢，尽管有其他的服务器能够提供更快的响应。会话保持与负载均衡是背道而驰的，负载均衡专注于把请求发送到负载最小的服务器上，而会话保持技术则专注于将请求发送到之前提供服务的同一台服务器上。为了能够得到最好的可扩展性和响应时间，我们需要在满足应用需求的前提下尽可能少地采用会话保持技术，以便最大程度的进行负载均衡。

当采用这种方式时，负载均衡器根据每个TCP SYN数据包中的源IP地址、目的IP地址和目的端口号码进行会话保持。在客户端发出的TCP SYN数据包中，目的IP地址是负载均衡器上的虚拟IP(VIP)地址，目的端口号码表示客户端想要访问的应用。采用这种方式时，对于客户端的第一个连接请求，负载均衡器会根据负载均衡算法选择一台服务器，对于源IP地址、VIP和目的端口这三项相同的后续连接都会转发到同一台服务器，直到会话保持计时器超时。采用这种方法关键的一点是，如果用户访问不同的应用，不同的目的端口号码或者VIP，负载均衡器不会把此类请求发送到同一台服务器，如图3.4所示，而是根据服务器的负载状况转发到一个合适的服务器上。

图3.5给出了一台服务器上两个应用互相共享数据的例子，用户往购物车中添加不同的商品后，HTTP应用会把购物车的信息传递到SSL应用上。当用户在网页上点击结帐按钮时，浏览器在443端口打开一个新的TCP连接。SSL应用需要这个用户的购物车信息以便正常的使用其信用卡结帐。因为HTTP和SSL应用都在同一个服务器上，它们可以通过共享内存、消息或者其他机制来共享数据。为了保证应用系统正常工作，负载均衡器必须把一个用户访问VIP地址的所有连接都发送到同一台服务器，忽略目的端口号码。采用基于源IP和VIP的会话保持模式，负载均衡器就可以把同一客户端的所有请求转发到同一台服务器上，不管是HTTP请求还是HTTPS请求。

如果服务器上运行的所有应用系统都需要互相共享数据，这种方法就非常适合。但是如果有些应用是相互关联的，而另外一些应用不是，那么这种方法可能就不是最佳的方法。例如，同一个VIP地址上面还运行FTP，那么所有访问FTP的连接也将会被发送到同一台服务器上。如果其他运行FTP的服务器比较空闲的话，负载均衡就失去了意义。针对这个问题，我们接下来要介绍的端口分组将会是一个更好的方案。

当一个VIP地址上面运行多个应用，并且多个应用之间并不互相关联的情况下，我们可以使用这种方法将互相关联的应用分成一组。我们需要在负载均衡器上设置一个应用端口的列表，作为一个组来对待。例如在图3.5中所示购物车的应用中，由于HTTP应用和SSL应用共享数据，我们把端口80和443定义为一组。负载均衡器使用端口分组的会话保持处理过程如图3.6所示，当收到C1访问VIP1的80端口的第一个连接后，负载均衡器根据服务器的压力状况选择RS1提供服务。第二个连接是C1访问VIP1的443端口，由于443端口和80端口绑定在一个组中，负载均衡器就对连接进行会话保持，同样转发到RS1。下一个连接C1访问VIP1的端口21，由于FTP应用不需要跟HTTP或者SSL应用共享任何数据，所以21端口没有跟80端口和443端口绑定在一组，这样，负载均衡器就根据服务器的压力状况选择RS2提供服务。下一个连接C1访问VIP2的80端口，尽管客户端源地址相同，但是访问的VIP地址不同，负载均衡器根据服务器压力状况选择RS3提供服务。最后一个连接，C2访问VIP2的443端口，由于这是C2访问VIP2的第一个连接，因此被负载均衡到RS2。

这种方法是专门为被动FTP之类的应用而设计的。让我们先了解一下FTP被动模式的基础知识(详细内容请参阅RFC 959)。图3.7简要描述了FTP被动模式的工作流程。首先，客户端打开一个TCP连接，访问服务器的21端口。客户端和服务器在这个连接上交换如何传输文件的控制信息，因此这个连接被称为控制连接。如果客户端在这个连接上发送一个PASV的命令，服务器会选择另外一个端口监听，用来跟客户端传输文件，并把这个端口号回应给客户端。然后客户端打开一个TCP连接，访问这个指定的端口来交换文件。与被动的FTP相反，主动FTP意思是指客户端选择一个端口监听，等待服务器主动连接。通常，客户端前面的防火墙会阻挡任何来自外界主动发起的连接请求，为了使客户端能够访问Internet，防火墙会允许客户端发起的对外的连接请求。在这种情况下，主动式FTP将不能够正常工作，因为由服务器主动发起的访问客户端的数据连接将会被防火墙阻挡住，被动式FTP采用从客户端主动发起请求访问服务器的方式解决了这个问题。

当对被动式的FTP流量做负载均衡时，我们必须采用合适的会话保持方法来保证数据连接和控制连接都能被转发到相同的服务器上。基于源IP和VIP的会话保持方法可以满足上述需求，它将所有的从同一个源IP访问同一个VIP地址的连接都发送到同一台服务器上。但是我们的要求仅是将一个被动FTP会话的控制连接和数据连接发送到同一台服务器上，基于源IP和VIP的会话保持方法会带来更多的负面效应。使用在线连接的会话保持方法，负载均衡器只需检查是否存在给定的源IP访问给定的VIP地址的活动连接即可，如果有，则转发到之前处理请求的同一服务器上。

换句话说，主动FTP不需要会话保持。但是如果服务器使用私有的IP地址或者它们在负载均衡器之后，就需要做NAT，我们已经在第二章的反向NAT技术中已经作了介绍。

迄今为止，我们已经讨论了基于源IP地址做会话保持的几种不同方式。但是，在某些特定的情况下，基于源IP地址的方法并不能很好的确定一个用户，比如高速代理的问题。高速代理问题有两个方面：会话保持问题和负载均衡问题。

大多数的ISP和企业都在其网络中部署代理服务器。当一个ISP或者企业的用户访问互联网时，所有的请求都会经过一个代理服务器。代理服务器会终止连接，并查找客户端请求的内容，代替客户端来发送这个请求。接收到回应之后，代理服务器再把回应发送给客户端。这里有两组连接，任何一个客户端的浏览器到代理服务器之间的连接都会对应一个代理服务器到目的WEB站点的连接。高速代理是指在一个大的ISP或者企业中部署的高性能的代理服务器，能够同时为成千上万的用户提供代理服务。高速代理服务器的处理流程如图3.8所示：

当用户打开多个连接，如果这些连接被分发到多台代理服务器，那么每台代理服务器会为每个连接分别产生请求访问目的Web站点。这时尽管是由同一个用户发起的连接，但被分发到多台代理服务器，由于目的Web站点的负载均衡器看到的源地址都是代理服务器的IP地址，导致每个连接的源地址都不同。如果负载均衡器仍然采用基于源IP地址的会话保持方法，那么同一个用户的连接将有可能被转发到不同的服务器上，导致应用交易失败。所以，在这种情况下负载均衡器不能够根据源IP地址来标识客户。

即便一个客户端所有的连接都被发送到同一台代理服务器，仍然还存在负载均衡的问题，如图3.9所示。例如一个ISP有两台性能强劲的代理服务器，每台代理服务器能够同时对100,000个用户提供服务。这时一个客户端所有连接的源地址都是相同的，会话保持也能很好的发挥作用，但是依然会有问题存在。来自某一台代理服务器的所有的连接都会被负载均衡器转发到同一台应用服务器来保证会话保持。这样就可能会导致一台应用服务器同时需要处理100,000个客户的连接请求，而其他的服务器处于空闲状态，从而使负载均衡变得毫无用处。通过标识代理服务器后面每个单独的用户，负载均衡器就能够在进行会话保持的同时更好的进行负载分发。代理服务器是否会导致负载均衡的问题主要取决于它产生的流量有多少，一些运营商，如美国在线(AOL)，微软网络，EarthLink等，都部署了很多高性能的代理服务器，为成千上万的用户提供Internet访问。但是如果一个网站有10台WEB服务器，而来自AOL用户的流量仅占总流量的2%，在这种情况下我们就不需要担心负载均衡问题。但是如果来自AOL用户的流量超过总流量的50%时，我们绝对会面临负载均衡的问题。这只是上述问题简化的表述，因为类似AOL这样的ISP会有很多的代理服务器。不管怎么说，我们都可以想象每台代理服务器后面成千上万的用户，依然会造成负载均衡的问题。

在处理用户通过不同的代理服务器来与服务器建立连接之类的高速代理会话保持问题时，我们还可以使用另外一种会话保持方法，虚拟源地址，来进行会话保持。例如有四台代理服务器，我们把这四台代理服务器的IP地址添加到一个组中，把这个组作为一个虚拟的源地址处理。来自这四个地址的连接都会被负载均衡器当作一个虚拟源地址来处理。通过这种方法，负载均衡器就可以把来自这四台代理服务器的用户转发到同一台应用服务器。这样一来我们就解决了会话保持的问题，但这可能违背了负载均衡的初衷，主要取决于来自这些代理服务器的流量占总流量的比例。

到目前为止，我们已经讨论了负载均衡和会话保持。当接收到TCP SYN数据包后，负载均衡器会选择一台服务器，一旦服务器被选定，所有后续的数据包都会被发送到这一台服务器上。然而，在TCP连接建立之后，数据包中有许多非常有用的应用层信息。如果负载均衡器能够识别应用层信息，就能够进行更智能的判断。以WEB应用为例，HTTP请求中包含了URL和Cookies，负载均衡器可以根据这些信息选择更合适的服务器。为了检查应用层数据，负载均衡器必须在收到应用层的请求信息之后，才能把这个TCP连接转发到一台服务器，这就是延迟绑定，也就是指推迟将一个TCP连接绑定到一台服务器，直到收到应用层信息的过程。

为了理解延迟绑定的工作方式，我们需要讨论一些TCP协议的细节，特别是TCP序列号。

首先，客户端发送初始序列号为100的SYN数据包，如图3.10所示。服务器记录客户端的序列号，并生成自己的序列号，封装在SYN ACK数据包中，回应给客户端。SYN ACK数据包给客户端传递了两个信息，首先，服务器的起始序列号码是500；第二，服务器收到了客户端序列号为100的SYN数据包。后续客户端和服务器发送的每个数据包序列号都会递增。客户端和服务器通过序列号来保证数据包的可靠传输。客户端会在每个数据包中设置应答信息以确认收到来自服务器端的数据包。初始序列号的选择取决于TCP的实现方法，如需了解详细内容请参考RFC 793。

为了接收到应用层请求，负载均衡器需要代替服务器与客户端建立TCP连接。负载均衡器必须自己给客户端回应SYN ACK数据包，如图3.11所示。在这个过程中，负载均衡器并不知道服务器会用什么序列号，必须自己生成序列号。一旦收到HTTP请求，负载均衡器选择合适服务器，与服务器建立连接，并将HTTP请求发送给这台服务器。服务器生成的初始序列号可能与负载均衡器跟客户端建立连接的初始序列号不一样。因此，负载均衡器必须转换所有的服务器回应数据包中的序列号以便与客户端连接的序列号保持一致。同样，由于客户端回应中包含一个应答序列号号，负载均衡器同样需要转换。

由于负载均衡器必须进行额外的序列号转换的工作，因此延迟绑定会影响负载均衡器的性能。显然，不同的负载均衡产品所受的影响也会不一样。但是延迟绑定的优势在于负载均衡器可以获取更多的信息来选择服务器，不必局限于TCP SYN数据包中有限的信息。它可以识别应用层请求的内容，有效地扩展了负载均衡器的能力。 在之前定义高速代理服务器问题时，我们讨论了采用虚拟源地址的方式来解决会话保持的问题。但是虚拟源地址的方式并不是在任何情况下都能够解决问题。也就是说，我们还没有找到有效解决高速代理服务器情况下负载均衡的问题，主要是受限于TCP SYN数据包中非常有限的信息，无法标识每一个最终客户端。

通过采用延迟绑定，我们能够识别应用层信息。对于HTTP应用，负载均衡器可以查看HTTP GET请求，其中包含大量有用的信息。RFC 2616提供了完整的HTTP1.1版本的定义，RFC 1945提供了完整的HTTP1.0版本的定义。

在后续的章节中，我们主要讲述基于HTTP的WEB应用，如何根据应用层的信息，比如Cookies和URL，来选择服务器。当采用延迟绑定来获取Cookise或者URL时，在第一个HTTP请求的数据包中可能没有完整的URL或者Cookies，负载均衡器需要等待后续的数据包并组成完整的URL。RFC 1738定义了URL的语法和语义，URL可以横跨多个数据包。如果负载均衡器需要等待后续的HTTP请求包，其内存空间可能会被大量地占用。在等待的过程中，负载均衡器不得不复制并保存数据包，一旦接收到所有的数据包，获取到所需要的Cookies和URL信息后，负载均衡器把这些数据包发送给服务器并继续保存在内存中，直到服务器发回ACK数据包确认已经接收到这些数据包。

在开始讨论如何利用Cookies进行负载均衡之前，我们先了解一下Cookies的工作原理。

Cookie是由Web服务器控制的一个对象，当收到客户端的请求之后，Web服务器生成一个Cookie作为响应的一部分返回给客户端。浏览器把Cookie存储到客户端本地，后续每次访问时客户端都会带着这个Cookie。Cookie的内容就是一个“名称=值”的数据对，就是表示这个Cookie的名字和其给定的值。比如，“user=1”，即表示Cookie的名字是“user”而其值是“1”。Cookie接收和存储的过程如图3.12所示。在客户端，浏览器负责管理Cookie，对最终用户来说是透明的。

关于Cookie的属性和格式，请参考Simon St.Laurent著McGraw-Hill出版的《Cookies》一书。

常用的Cookie交换有三种不同的方式：Cookie-Read，Cookie-Insert，和Cookie-Rewrite。每种方式对负载均衡器的性能和服务器端应用的设计都会产生不同的影响。

Cookie-Read的工作方式如图3.13所示，还是采用高速代理服务器的例子帮助我们更好的理解Cookie-Read。客户端第一次发起访问请求，请求到达第一台代理服务器，由于是第一次访问这个Web站点，所以没有Cookie。这个请求被负载均衡到RS1，谨记负载均衡器已经进行了延迟绑定以确认请求中是否存在Cookie。现在，RS1发现没有Cookie，所以它设置一个“Server=1”的Cookie。当客户端浏览器接收到回应，发现有Cookie，就把Cookie存储到客户端本地硬盘上。这时TCP连接可能会结束，取决于浏览器的行为和客户端与服务器之间采用的HTTP协议的版本。当用户请求下一个Web页面，可能需要建立一个新的连接。连接建立之后，浏览器在发送HTTP请求的时候会带着“Server=1”的Cookie。由于负载均衡器被设置成Cookie-Read模式，它会进行延迟绑定并查看HTTP请求中的Cookie信息。负载均衡器发现Cookie的内容“Server=1”，就将请求转发到RS1。即使这个新的连接是由不同的代理服务器处理也没有关系，因为负载均衡器不再根据源地址来做会话保持，而是根据Cookie来标识每个用户，这样做也解决了高速代理服务器的负载均衡问题。

现在，我们来讨论如何才能让Cookie-Read模式正常工作。首先，负载均衡器必须支持Cookie交换。更重要的是，服务器上的Web应用必须设置一个“Server=服务器ID”的Cookie。服务器必须知道它自己的ID是什么，而负载均衡器必须知道如何将服务器ID唯一的对应到这台服务器。以三台服务器为例，ID可能只是一个数字，例如1、2和3，也可能是一个名字，例如RS1、RS2和RS3。这取决于不同厂家的负载均衡器对Cookie的支持情况。

采用Cookie-Read方式的优点是负载均衡器不需要承担太多的工作，只需要读取服务器回应给客户端的Cookie信息。Cookie-Read方法的缺点是需要服务器自己产生Cookie，产生Cookie并不困难，但是需要应用开发商的配合。服务器的应用系统需要知道在负载均衡器中定义的服务器的ID。当增加一台新的服务器或者改变某台服务器的配置时，网络管理员必须设置或修改服务器的ID，以便与负载均衡器的配置保持一致。

当采用Cookie-Insert模式的时候，如图3.14，应用系统不需要做任何改变。第一个请求因为没有Cookie，所以被负载均衡到RS1。当服务器回应时，负载均衡器查看服务器的回应包，并插入一个包含服务器ID信息的Cookie，比如“server=1”。后续的HTTP请求都将包含“Server=1”的Cookie，如果负载均衡器在把请求转发给服务器之前时没有将Cookie删除，服务器会看到这个Cookie。通常负载均衡器会保留数据包中的Cookie，因为服务器应用并不关心Cookie。

采用Cookie-Insert模式的优点是对于服务器应用来说是完全透明的。无论是增加还是删除服务器，或者变更负载均衡器的配置，网络管理员都不需要担心去更新服务器的配置。采用Cookie-Insert方法的缺点是负载均衡器的性能压力和潜在的数据延迟。我们来看一下负载均衡器需要做的工作，负载均衡器在HTTP回应的数据包中插入一个新的Cookie，如图3.15所示。因为需要在数据包中插入新的Cookie，所以负载均衡器需要把数据包保存到内存中。而且，插入一个Cookie会增加数据包的大小。如果新的数据包的大小超过了以太网允许的最大值，还需要把这个数据包分片。负载均衡器还必须处理数据包丢失而造成的重传，由于数据包分片有额外的数据包增加，因此还需要调整序列号。我们还需要考虑到进行上述处理所造成的延迟，虽然这些延迟相对于广域网络延迟来说可能微不足道。

总的来讲，Cookie-Insert模式的优点很明显，不需要对服务器和应用做任何调整，但可能会对负载均衡器的性能产生很大的影响。注意，如果服务器也需要设置Cookie，Cookie的名称不能与负载均衡器中设置的Cookie名称一样。满足要求很简单，因为负载均衡器生成的Cookie名称是可以随意设置的。

Cookie-Read不像Cookie-Insert那样需要负载均衡器做很多工作，但是它要求服务器修改应用程序的配置，而Cookie-Insert不需要服务器做任何改变，Cookie-Rewrite则取二者之所长。 采用Cookie-Insert最大问题是在Cookie插入的过程中需要复杂的内存管理机制，并且插入Cookie之后如果数据包大小超过网络允许的最大值还需要分割数据包。如果服务器回应的数据包中预留Cookie的位置，而负载均衡器只需要给这个Cookie设定一个正确的值将会怎么样呢？

在Cookie-Rewrite方法中，需要修改服务器应用，生成一个Cookie并赋予一个缺省的数值，如图3.16所示，应用系统插入一个Cookie“server=XXX”。应用系统不需要关心服务器ID，都设置成“XXX”。当负载均衡器接收到服务器的HTTP回应数据包后，查找Cookie并设置为正确的服务器的ID号码。因为负载均衡器没有在数据包中增加任何字节，这将保证数据包长度不变，从而排除了分割数据包的可能性。

这种方法的优点是没有数据包分割所带来的巨大的性能损耗，也不需要复杂的内存管理机制。这种方法要比Cookie-Read好，尽管都需要服务器端生成Cookie，但Cookie Rewirte只需要生成一个赋有缺省值的Cookie即可，应用系统不需要关心服务器的ID。这样也减轻了管理员的负担，不必担心增加或减少服务器时修改负载均衡器配置的问题。

在我们讨论的这三种模式中，优先选择Cookie-Rewrite，因为它既不像Cookie Read那样增加了管理的难度，也不像Cookie-Insert那样增加了负载均衡器的负担。

Cookie交换不仅能够解决高速代理服务器的问题，还有其他几种用途。举例来说，假设有一个提供网上经纪咨询的公司把它的客户分成三个不同的等级：白银、黄金、白金，如图3.17所示。服务器的配置不等，有高端的，也有低端的，我们可以把高端服务器预留给白金客户使用，防止大量白银用户的访问影响到白金用户的服务质量和响应速度。

我们需要把服务器分成三组，把一些高端服务器放到第一组里面。当白金客户第一次访问时，服务器会设置一个Cookie“User-Group=1”。后续所有包含Cookie“User-Group=1”的请求都会被发送到第一组服务器，所有的白金客户就可以得到更好的服务而不受其他客户的影响。

Cookie交换技术也经常被用于提高服务质量。传统的二、三交换机只能够看到IP包头信息，但是负载均衡器能够识别更高层次的内容并能够设置QoS或ToS以调整数据包的优先级。通过查看Cookies，负载均衡器能够智能地识别客户或者流量类型等并作出智能的选择。可能目前许多负载均衡器还不支持这样的功能，但这是一个发展趋势。

虽然Cookie交换是一个解决负载均衡和会话保持问题并提供智能的流量控制的强有力的工具，但还是有一些问题需要我们考虑。因为网站可以根据Cookie来跟踪用户的上网行为，所以Cookie交换会涉及到用户隐私的问题。有两种类型的Cookie：永久的和临时的。永久的Cookie存储在客户端的电脑上，永久有效。临时Cookie只在当时会话中有效，在会话结束后随即被删除。大部分浏览器都提供选项，可以禁用永久或临时的Cookie。例如，微软IE5.0就可以分别设置是否接受临时或者永久的Cookies。

如果用户关闭了Cookies，就不能再采用Cookie交换的方式对其进行负载均衡了，这个用户可能就无法正常使用WEB应用。许多流行的电子商务网站要求用户不要禁用Cookies，否则这些网站将无法正常提供服务。事实上，这也许并不是一个大问题，因为大多数用户并没有关掉Cookies，即使有些用户真的禁用了Cookies，我们还可以采用备用的基于源地址的会话保持方法。

安全套接字层协议(SSL)是一种能够提供安全、保密的数据交换的协议。采用SSL时，所有的数据都会被加密，传输到另外一端，再进行解密。它是由Netscape开发出来的，广泛应用于电子商务领域，进行信用卡信息等敏感数据的传输。在交换敏感数据时，是由运行在SSL协议之上的HTTP来提供端到端的安全性。运行在SSL之上的HTTP也被称为HTTPS，因为这种请求的URL是以HTTPS为开头的，如“https://www.foundrynet.com”，将触发浏览器采用基于SSL之上的HTTP协议访问这个站点。 对于负载均衡器来说，处理SSL流量最大问题是无法识别应用层的数据，因为它们都是加密的。这其中就包括了Cookies和URL。因此，在处理HTTPS流量时，负载均衡器无法利用Cookie来实现会话保持或者解决高速代理服务器的问题。SSL运行在TCP协议之上，是一个有状态的协议，它使用会话标识符（会话ID）来唯一标识一个会话，因此负载均衡器可以采用SSL会话ID来进行会话保持。

目前存在几个不同版本的SSL协议，本章主要讨论SSL协议V3.0。在V3.0版本之前，负载均衡器是不能识别SSL会话ID的，因为会话ID也是被加密的。V3.0以后的版本，SSL会话ID采用明文传输。有一点需要注意，负载均衡器是不能够读取任何加密的信息的，只有服务器才能。 客户端与服务器之间采用HTTPS进行传输的流程如图3.18所示，首先，客户端建立一个TCP连接并发送一个客户端问候消息，服务器回应一个服务器问候消息，这个过程是SSL握手的一部分。在SSL握手过程中，双方协商加密和解密的相关参数。如欲了解SSL握手的详细过程，可以参考Netscape网站上公布的SSL V3.0的定义。其中一个参数就是在服务器回应问候消息时设置的会话ID，客户端的浏览器把会话ID信息保存在内存中，并在后续连接中继续使用这个会话ID，以避免重新协商相关参数。此外，浏览器也可以利用这个会话ID同时建立多个TCP连接。

再回到HTTPS流量的负载均衡上来，如图3.19所示，当客户端第一次发起SSL连接时，服务器会产生SSL会话ID并将其作为服务器问候消息的一部分返回给客户端。当负载均衡器收到从RS1发出的服务器问候消息时，就把会话ID提取出来，在内存建立一张对应表，把这个会话ID和RS1关联起来，然后把这个问候消息转发给客户端。一旦接收到这个问候消息，客户端浏览器就把会话ID保存到内存中。当浏览器在同一个应用交易中发起新的TCP连接时，它会继续使用这个会话ID。这次，另外一台代理服务器处理这个新的连接，如图3.19所示，负载均衡器通过延迟绑定提取会话ID信息。负载均衡器在对应表中查找，找到会话ID所对应的服务器RS1，并这个连接转发给RS1以保证会话保持。采用这种方法时，负载均衡器不再根据源地址来标识用户，因此高速代理服务器负载均衡的问题也相应得到解决。所有没有会话ID或会话ID不在负载均衡器的对应表中的连接都会被负载均衡到一台可用的服务器上。

一旦从服务器端接收到SSL会话ID，浏览器在多长时间内会复用这个会话ID还不确定，这段时间不一定和应用交易的时间相吻合。当用户在网上购物时，一个SSL会话的时间可能会很短，但是对于银行或证券等在线交易的会话时间可能会比较长，因为用户可能不会关闭浏览窗口，使其一直处于打开状态。Web服务器的应用系统可能会采取超时机制，强制让用户重新登录和认证。问题是，如果浏览器在应用交易过程中重新协商一个SSL会话ID，那这种会话保持方法就会失效。避免这个问题的方法就是使用基于源地址的会话保持方法作为备份，但这就会带来高速代理服务器的问题，也可以采用SSL加速的技术来解决这个问题。另外还有应用系统可能在众多服务器群中共享客户数据的情况，我们会在后序的章节中讨论。

我们已经讨论了什么是会话保持以及实现会话保持的几种方法，但是我们需要认真考虑会话保持的根源，那就是服务器、应用系统、负载均衡器等组件设计的问题。

我们退一步来考虑会话保持需求的产生，主要取决于服务器应用是有状态的还是无状态的。有状态是指在多个请求/回应数据交换的过程中需要携带一些上下文或者状态信息。无状态是指，应用系统在请求/回应过程中不需要任何状态信息。我们以购物车应用为例进行说明，客户端发出的第一个请求添加一本书到空的购物车里面，如果客户端发出请求向购物车内增加第二本书时，服务器的应用系统就需要知道购物车内已经有一本书了。购物车内已经有一本书的信息就是状态信息，它需要从第一次数据交互的过程传递到第二次数据交互的过程。但是服务器的应用系统不一定必须设计成有状态的，我们下面探讨三种无状态应用的实现方式。

第一种方法是采用Cookie保存状态信息，如图3.20所示。当接收到第一个请求，把Book1放入购物车内时，服务器设置一个名称为购物车的Cookie并设定其值为：Book1。客户端接收到Cookie之后，浏览器将Cookie内容存储到本地计算机，并在后续增加Book2到购物车的请求中携带这个Cookie。假设这时客户端打开一个新的TCP连接，而负载均衡器不做任何的会话保持，只是简单地把新的连接分发到RS3。RS3上的应用系统发现Cookie信息：Cart-=Book1，就知道这个用户的购物车里面已经有Book1了。RS3简单地将第二本书增加到购物车上并设置Cookie：Cart=Book1；Book2，然后返回给客户端。浏览器继续保存得到的Cookie信息并在下一个请求中继续携带这个Cookie。如此，我们已经通过Cookie的方式实现了信息的连贯性。这个过程对于用户来说是透明的，因为浏览器处理Cookie信息的过程对用户来讲是透明的。

第二种方法是采用URL来纪录状态信息。URL可以包含要传递给应用系统的数据。当客户端在把Book1放入购物车内时，服务器必须把后续页面中“添加到购物车”接钮所对应的链接修改成“HTTP://www.bookstore.com/cgibin/buybooks?cart=book1&numitems=1”。在“?”后面的字段即是传递给应用程序的参数，其中包括购物车内商品的数量和购物车中的商品：Book1。 第三种方法是采用后端共享存储的方式来保存购物车信息。当向购物车内添加商品时，服务器就会将购物车信息存储在共享存储中以便于其他的服务器也能够访问。如果下一个TCP连接被转发到另外一台服务器，那台服务器就能够从共享的存储中获取购物车的信息。但是这种方法成本较高，因为用户信息发生变化时，服务器必须更新共享存储，因此在实际应用中并不常用。然而，在共享存储的更新工作量不大的情况下，这种方法是非常有效的，在下一章节HTTP到HTTPS的转换中我们将进行讨论。

在上述三种方法中，最常用的是基于Cookie的方法，因为这种方法易于实现。然而，基于Cookie的方法存在安全隐患。用户可以改变计算机中的Cookie，所以无法通过这种方法来跟踪用户账户余额，但是可以用来跟踪购物车内容等信息。采用Cookie方式的缺点是如果状态信息内容较多，我们就需要来回传送大量的Cookie信息，从而浪费带宽并增加了延迟。并且，使用URL或Cookie方式，传输的状态信息的数量还受到HTTP头长度的限制。

会话保持跟负载均衡是互相对立的，但有状态的应用系统需要会话保持来保证交易的完整性。无状态的应用不需要任何的会话保持，所以负载均衡器可以把每个新建TCP连接转发给当前压力最小的服务器，以获取最佳的负载均衡效果。显然，一个应用系统完全可能是无状态的，然而，如果采用共享存储的方式的话，可能会造成整个系统的性能下降，这又违背了负载均衡提高可扩展性和更快的响应速度的初衷。

在购物车应用中，购物者首先在购物车中增加商品，然后再点击“结帐”按钮来购买。这时，浏览器就跳转到HTTPS来进行交易，也就是运行在SSL之上的HTTP协议。假定购物车的应用系统是有状态的，那么就需要在用户请求从HTTP转换到HTTPS的过程中把状态信息传递过去。因此，我们需要找到一种方法，把一个用户所有的连接，不管是HTTP还是HTTPS，都转发到同一台服务器。而我们之前讨论的会话保持方法只是将HTTPS或者HTTP协议分别实现会话保持，但是在当客户从HTTP协议转换成HTTPS协议时如何保证会话保持呢？当接收到第一个HTTPS的连接请求时，负载均衡器需要找出一种方法把请求转发到之前处理同一个客户端的HTTP请求的服务器上面。通常同一个客户端发出的HTTP和HTTPS请求的源IP地址是一样的，所以，我们可以在HTTP协议转换到HTTPS协议时采用源IP地址的会话保持方法。但是源IP地址会话保持方法在高速代理服务器情况下工作的并不好，我们在前面章节中已经讨论过。虽然我们能够采用Cookie交换的方法来解决高速代理服务器问题，但是在从HTTP转换到HTTPS的过程中，负载均衡器已经不能识别Cookie的内容了，因为它们已经被加密了。而源IP地址也可能会发生变化，这样负载均衡器就无法将SSL会话与HTTP会话关联在一起。因此，负载均衡器可能将SSL会话发送到一个不同的服务器上，而这台服务器完全没有购物车的信息，从而使得客户的交易中断。对于这个问题，很难找到一个简单易行的解决方案，让我们先探讨几种可行的方法。

首先是采用后端共享存储或者数据库系统的方式解决HTTP到HTTPS转换的问题，如图3.21所示。当用户点击结账的按钮时，购物车服务器必须要把状态信息写到后台的数据库中。当初始化SSL会话时，SSL服务器从后端的数据库中获取购物车的信息并进行处理。通过在后端共享存储或数据库系统中共享购物车信息的方法，我们就基本解决了这个问题。这种方法的本质是从HTTP转换到HTTPS的过程是无状态的，但是HTTP和HTTPS应用本身是有状态的。我们还必须使用基于Cookie和SSL会话ID的方法解决HTTP应用和HTTPS应用会话保持的问题。

第二，我们可以采用一些中间件，如图3.22所示。中间件是一种运行在服务器上面，并能够通过消息互相通讯的软件。中间件给应用程序提供编程接口，这样应用系统就可以不受它所运行的服务器的约束。中间件使用类似Cookie这样的标志来跟踪用户身份。一旦应用系统接收到HTTPS的请求，它就会利用Cookie来获取状态信息。中间件可以从其他的服务器透明的获取到状态信息，如果其他服务器有的话。

第三，我们可以在负载均衡器和服务器上做一些特殊的设置，在会话保持的前提下完成交易。我们把VIP的80端口绑定到所有服务器的80端口上。但是对于SSL的443端口，我们给每个服务器都分配一个端口号码。例如有三台服务器，SSL交易的VIP的端口号就从2001到2003。我们把VIP的2001端口绑定到RS1上的443端口，2002端口绑定到RS2的443端口，2003端口绑定到RS3的443端口。每台服务器上包含结帐按钮的页面中，结帐按钮所对应的链接必须是这台服务器自己的VIP地址和端口号。举例来说，RS1上面的链接指向VIP的2001端口。由于这个端口只绑定到RS1，所以负载均衡器只是简单地把连接转发到RS1，这样就可以保证应用的持续性。这种方法需要在负载均衡器上作一些设置，当然，在服务器上也需要做相应的调整。

还有一些其他的方法，比如借助SSL加速设备。SSL加速器终结SSL连接并将HTTPS请求转换成HTTP请求。这种产品像负载均衡器一样放置在服务器群之前。因为HTTPS已经被转换成HTTP，负载均衡器能够基于Cookie进行交换，从而保证会话的持续性。除了提供会话保持以外，SSL加速器还能提供高性能的SSL处理。SSL连接的处理占用了大量的运算资源，而且不能方便的扩展。SSL加速产品配备了专有的硬件来帮助加密和解密，因此，提高了系统每秒钟处理的SSL连接的数量。SSL加速器和负载均衡器一起部署的网络结构如图3.23所示。负载均衡器把所有访问443端口的请求转发到SSL加速器上，SSL加速器终结SSL连接请求并建立一个新的访问VIP80端口的TCP连接，发送相应的HTTP请求。负载均衡器再把请求分发到服务器上，由于已经解密，所以负载均衡器可以采用基于Cookie或者其他的会话保持方法来实现会话的持续性。

在负载均衡器上定义了VIP，并绑定到真实服务器的指定端口之后，就意味着访问这个VIP的请求可能会被转发到任意一台真实服务器。负载均衡器认为这些真实服务器提供内容的能力是相同的，选择服务器唯一要考虑的事情是，这台服务器是否健康，它现在的负载压力有多大，是否需要会话保持？但是如果这些服务器并不是完全一样的呢？如果需要提供服务的内容过于庞大以至于无法在一台服务器上部署呢？我们就必须给不同的服务器分配不同的内容。比如一个提供新闻的网站，所有的美国新闻放在服务器1、2和3上；所有的中文新闻放在服务器3和4上，所有的印度新闻放在服务器4和5上。我们将服务器1、2、3添加到组1中；把服务器3、4添加到组2中；把服务器4、5添加到组3中(如图3.24)。这种情况下，负载均衡器就必须根据请求的URL来选择服务器。由于URL是包含在TCP连接建立以后的HTTP GET请求包中，负载均衡器必须采用延迟绑定来查看URL。而且，还需要在负载均衡器上设定URL交换的算法，使负载均衡器能够根据请求内容的不同转发到不同的服务器。针对前面的例子，制定规则：“www.news.com/usa*”将被导向服务器组1，其中*表示以“/usa”开头的任意内容，这样负载均衡器就把所有以“www.news.com/usa*”开头的请求转发到服务器组1。

多个Web站点共用一个公网IP地址的情况也可以使用URL交换。由于公网IP地址资源有限，运营商不可能为每个托管的网站都提供一个公网IP地址。虽然每个用户的空间有限，但是所有用户总共需要的空间较大，超出单台服务器所能够提供的容量。运营商利用URL交换技术就可以使用一个或几个VIP为所有的用户提供网站托管服务。

图3.25给出了一个站点使用一个VIP为多个用户站点提供服务的例子。由于所有的内容不能放在一台服务器上，我们把内容分成三组：用户名首字母从A到G，H到P，和Q到Z。如果我们把每一部分内容部署到一台服务器上面，这台服务器有可能成为稳定性和性能的瓶颈。首先在负载均衡器上定义一个VIP，并将其绑定到所有服务器的80端口。接下来就在负载均衡器上定义URL规则，把所有的从“www.isp.com/user/A*”到“www.isp.com/user/G*”的请求转发到第一组服务器，依此类推。负载均衡器就会把用户的请求转发到相应服务器组中的服务器上。如果某个组的用户数量激增或者访问量过大，可能会造成该组服务器的响应时间变慢，只需要在该组中增加一台服务器即可。在这个例子中，通过使用URL交换的算法，就可以通过一个公网IP地址提供高可扩展性，高稳定性和高性价比的网站。

URL交换也可以用来实现通过一个公网IP地址来为多个域名提供服务。举例来说，可以通过URL交换使用一个VIP为HTTP://www.news.com/、HTTP://www.sports.com/和HTTP://www.stocks.com/三个站点同时提供服务。可以在负载均衡器上面设置URL交换的算法，来匹配主机名中是否包含news、sports或者stocks，并转发到相应的服务器上。另外，如果news内容过于庞大，还可以进一步进行划分，比如把www.news.com/USA和HTTP://www.news.com/International分别转发到不同的服务器组。不同的负载均衡产品，URL交换的具体细节和配置有所不同。

URL交换还可以用来区分静态内容和动态内容。静态内容是指所有不经常改变的内容，如背景图案、公司LOGO和静态的文本内容。动态内容经常发生改变，并可能根据用户的不同做出相应的调整。举例来讲，网上银行的帐户信息就是动态内容，每个用户的帐户信息都是唯一的，是在用户初次访问的时候动态生成。静态内容相对来说比较容易管理，在内容需要更新的时候发布到服务器上即可。动态内容却相反，需要频繁更新，而且可能需要与数据库建立接口，根据用户的请求动态产生内容。将动态内容与静态内容分开，存储在不同的服务器中是合理的，这样我们就可以更方便的进行管理。动态内容通常包括CGI、ASP、Visual Basic或者JavaScript等，当用户发出请求后这些程序就会在服务器上执行。例如，打开站点HTTP://www.google.com/，输入关键字“load balancing”并点击Search，就会在下一个网页中得到结果。当点击Search按钮时，浏览器请求URL：HTTP://www.google.com/q?load&balancing，而“q”表示在Google的网站服务器上运行的一段脚本或程序，而“?”后面的数据是传递给这个程序的参数。服务器会根据输入的内容产生结果，也就是我们所看到的搜索结果页面。

我们需要将服务器分成两组，组1和组2，分别提供静态内容和动态内容。另外还需要在负载均衡器上定义URL规则区分动态内容，判断URL中是否包含“？”、“CGI”、“ASP”，并将其导向到不同的服务器组。

虽然URL交换为组织和管理内容提供了极大的灵活性，但是如果所有内容可以部署在一台服务器上，就完全没有必要使用URL交换。采用URL交换时，必须要小心谨慎的定义URL规则。否则，用户将得到“object not found”错误，因为负载均衡器可能将请求发送到没有这个内容的服务器中。另外，URL交换也会影响负载均衡器的性能，因为它需要时间来搜索URL并执行相应的规则，当然还要加上延迟绑定所带来的性能影响。每条规则都会给负载均衡器带来性能的损耗。一般来讲，一条判断URL是否是以“.asp”结尾的规则要比在URL任意位置搜索是否包含“CGI”的规则所产生的性能损耗要小。当然，实际处理性能还取决于负载均衡器本身，不同厂家产品的性能会有所差异。

当采用URL交换来选择合适的服务器时，可能需要会话保持，用Cookie交换与URL交换相结合的方式即可实现。例如，如果采用Cookie-Read的会话保持方法，也就是由服务器插入Cookie，负载均衡器首先会查看请求中是否包含Cookie。如果Cookie存在，负载均衡器简单地将请求发送到相应的服务器即可。如果请求中没有Cookie，负载均衡器就利用URL交换规则来选择合适的服务器提供服务。

HTTP 1.0在一个TCP连接中只允许包含一个HTTP请求，而HTTP 1.1允许一个TCP连接中可以包含多个HTTP请求。显然，HTTP1.1更为有效，因为它不用为每个HTTP请求都建立并拆除TCP连接。然而，它给URL交换带来了一定的影响。如图3.24所示，如果第一个HTTP请求访问HTTP://www.usa.com/news/usa，第二个HTTP请求访问HTTP://www.usa.com/india，而这两个请求都是在一个TCP连接中该怎么办呢？负载均衡器执行延迟绑定并查看第一个HTTP请求，根据第一个请求的URL信息，负载均衡器将连接转发到组1中的服务器上，但是第二个请求应当转发给组3中的服务器。负载均衡器可以终止跟组1中的服务器的连接，并跟组3中的某台服务器建立连接，并发送第二个HTTP请求。这样会带来更多的延迟并影响负载均衡器的性能，因为负载均衡器需要结束连接并建立一个新的TCP连接。更重要的是，HTTP 1.1支持一种被称为流水线的技术，它可以让一个客户端浏览器可以同时发送多个请求而不需要等待任何回应。所以负载均衡器可能在服务器回应第一个请求之前接收到第二个HTTP请求。在这种情况下，负载均衡器有两个选择，首先，与组3中的某台服务器建立一个新的连接并在得到第一个请求的回应之前发出第二个HTTP请求。但是这样会使事情变得非常复杂，因为负载均衡器必须接收不同服务器发来的第一个和第二个请求的回应，并合成为一个回应包返回给客户端。这样对于IP包的封装，排序和保证传输方面带来极大的挑战。另外一种方案是等待第一个请求的回应，收到应答数据之后发送第二个请求。

因为存在这些复杂的问题，所以不建议针对HTTP 1.1使用URL交换，除非有明确的需要并能够解决上述问题，否则尽量避免使用URL交换。

在设计和维护有状态应用系统进行负载均衡时，会话保持是一个基本的概念。基于源IP的会话保持方法简单有效，但会存在高速代理服务器的问题。基于Cookie和SSL会话ID的会话保持方法能够有效解决高速代理服务器的问题。购物车之类的应用需要着重考虑从HTTP转换到HTTPS交易时的情况，并确保应用软件和负载均衡设置中都考虑到了这一点。本章还涉及到了延迟绑定，一个在负载均衡器上面实现四层以上交换的基本概念。 当网站的内容非常庞大时，URL 交换提供了独到的便利，但是对于网站内容很少的网站，这种便利就显得微不足道。但是URL交换技术对于主机托管商来说就非常有用，因为它们可以借助这一技术只用一个公网IP地址为多个域名和网站提供服务。