What caching strategies can I implement between the web load balancer and the web farm

There are two main downsides:

1. Your load isn't evenly distributed. Sticky sessions will stick, hence the name. While initial requests will be distributed evenly, you might end up with a significant number of users spending more time than others. If all of these are initially set to a single server, that server will have much more load. Typically, this isn't really going to have a huge impact, and can be mitigated by having more servers in your cluster.

2. Proxies conglomerate users into single IP's, all of which would get sent to a single server. While that typically does no harm, again other than increasing individual server loads, proxies can also operate in a cluster. A request into your F5 from such a system would not necessarily be sent back to the same server if the request comes out of a different proxy server in their proxy cluster.

AOL was at one point using proxy clusters, and really screwed with load balancers and sticky sessions. Most load balancers will now offer sticky sessions based off of C-Class net ranges, or with the case of F5, cookie based sticky sessions which store the end node in a web request cookie.

While cookie based sessions should works, I've had some problems with them, and typically choose IP based sessions. BIG HOWEVER: I'm mostly working on internal apps - DMZ milage might vary.

All that being stated, we've had some great success with sites running behing F5 with sticky sessions and In-Proc sessions.

You also might want to take a look at one of the in memory distributed caching systems like Memcached or Velocity for an alternative to session being stored in SQL or the out of proc memory service. You get close to the speed of in-proc memory with the ability to run it across several servers.

Your confusion is reasonable - they are often the same thing. But not always. When you refer to a load balancer you are referring to a very specific thing - a server or device that balances inbound requests across two or more web servers to spread the load. A reverse proxy, however, typically has any number of features:

1. load balancing: as discussed above

2. caching: it can cache content from the web server(s) behind it and thereby reduce the load on the web server(s) and return some static content back to the requester without having to get the data from the web server(s)

3. security: it can protect the web server(s) by preventing direct access from the internet; it might do this through simple means by just obfuscating the web server(s) or it may have some more active components that actually review inbound requests looking for malicious code

4. SSL acceleration: when SSL is used; it may serve as a termination point for those SSL sessions so that the workload of dealing with the encryption is offloaded from the web server(s)

I think this covers most of it but there are probably a few other features I've missed. Certainly it isn't uncommon to see a device or piece of software marketed as a load balancer/reverse proxy because the features are so commonly bundled together.