仅当web 范围内的第一次点击进行负载平衡
这种方法也称为前端负载平衡，它易于描述，但是有可能不适于执行。为了实现真正的负载平衡，每次
请求都要重新平衡用户。但是在大多数情况下，前端负载平衡就已经足够满足大部分这类服务器维护的
支持者了。

要实现这个目的，就只允许在范围内的第一次点击通过负载平衡器。每个增加的页面负载都将用户保持
在同一个服务器上。这就如同在代码中使用相对路径而不是绝对路径一样简单。

< Form action="http://www.myserver.com/mypage.asp" method=post >

变成

< Form action="/mypage.asp" method=post >

在action 标记中使用相对路径，用户在访问你的站点的整个过程中，都停留在同一个网络服务器上。
这样他们的session集合在同样时间内与他们在一起。毫无疑问，这样会使你的负载平衡计划受到
一定的损失，因为你只有一次机会决定在哪儿处理用户的负载，并且在知道他们将产生多少通信量
之前就要作出决定。但是在大多数情况下，因为允许使用sessions，这种方法已经接近于实现完全的
性能了。

但是，这不是唯一的问题：在某些情况下，这不是一个合适的方法。例如，你的应用程序要求用户离开
当前的服务器，到一个专门用途的服务器上，如email、搜索或安全服务器的话，这种方法就不行了。
另外，如果用户把一个页面设置为书签，或者试图把这个URL 发送给朋友，他们可能要得到特定机器
的地址，进一步削弱你的负载平衡计划。最后，如果机器坏了，所有的用户信息都不可恢复地丢失了，
它没有失败恢复功能。



哪种方法最好？


这个问题的答案可想而知：“看情况”。其它需要考虑的因素包括：

○ 你的站点点击率有多高；
○ 你希望保存多少状态信息；
○ 如果你有专门用途的服务器；
○ 如果你想用第三方组件处理你的站点的宝贵部分。

如果你的站点通信量太大，那么精确的负载平衡对于站点的成功来说就非常重要，那么不用sessions
编程，或使用Session Pro或 Microsoft的站点服务器等第三方组件，是可行的。如果通信量小，或者
只需要保存较少的状态信息，那么使用cookies 或仅仅前端负载平衡就比较可行。

总的来说，在建立站点之前你要充分考虑这些问题。决定采用什么方法要把需要与站点的每个页面相结合，
任何延迟都会导致主要部分的重做，也许会导致整个站点的完全重新构造。确定站点当前和将来会有什么
需要，然后决定如何处理sessions的问题。