I've been looking at the ZF Session component and it looks rather extensive but I continue to have a fundamental misunderstanding on the inner workings of the PHP session, and even though I've been writing in PHP for years, I'm still a little lost in that department. Don't get me wrong, I know what a PHP session is, I know how to use it - I actually wrote a nice little session class years ago based on a tutorial I read, and it has always worked great for my various projects. In my session class I just grabbed the user's randomly generated token via the use of $_SESSION['token'] (which I assumed was stored on the server) and stored/compared it with the token in the database

However, confusion and frustration set in rather recently as I've scaled up my projects. I will be working on large-scale high-traffic web apps that will set on load-balanced server farms. Several people have warned not to use PHP sessions because they can be problematic when it comes to HTTP load balancing and that of course made sense. I've been urged to look at using cookies only, and this is where I really get confused...

If cookies and PHP sessions are two separate methods used to maintain client persistence, what exactly are cookie-based sessions? Reading over the PHP manual it sounds like Sessions have always naturally used cookies (as opposed to URL IDs) and if that is true, why am I being cautioned NOT to use Sessions in load-balanced environments? How does ZF handle sessions?

Thanks for any help!

To fully understand problem You should read more about http protocol - request, response, headers (try also livehttpheaders extension). It's stateless so each command is executed independently. There is no way to identify one client (You can's use IP address - proxies, lan or MAC - different layer of OSI model), so You need to add identifier directly to connection.

Yes I am completely familiar with the fundamentals of HTTP. I am also plenty familiar with what a cookie is and how it is transmitted. My question is not about how HTTP works and how/why it is stateless.

I am simply concerned with the details of the PHP session directly, and how it differs from using a cookie manually, since PHP sessions are supposedly poor candiates for session tracking on larger-scale web apps.

Technically it's no difference. Built-in functions are just wrappers to some functionality. You can extend it with PHP: session_set_save_handler - Manual or write Your own methods and don't even touch $_SESSION:

PHP session info is stored in a text file on the web server, in the directory specified in your php.ini file. The php session cookie stores the session Id on the users local HDD (obviously) so that the web server knows which session file to associate with a particular request.

I've not worked with a load-balancing environment, so I'm not sure how the web server handles distributing the PHP session file across the web servers in the farm, but I'd assume this is where the problem comes into play. In other words, if one request goes to one server, and a subsequent request goes to another server do the servers transfer the session file back and forth?

You are right on the mark. Session data will obviously not be there if a user makes a request from a different server. Apparently there is software out there to relieve this issue but:
1. It is expensive
2. It adds overhead
3. Why?

I mean if you could just use a cookie to check against a database, I can't think of why anyone would want to use such software in the first place.

I guess what's got me is in my older Session Class I always just generated a random token in a Session variable and checked it against a DB. I'm now starting to think the tutorial lead me a bit astray since random sessions ID's are already generated by PHP.

In any case, how does ZF handle sessions then? Does it still use a text file or does it use a custom storage handler?

Zend_Session simply provides a means to interact with PHP sessions, without having to use the $_SESSION global variable. The info is still stored the same way that PHP always stores session info.

If you are doing authentication/authorization on the site then it is generally considered less than ideal to be storing session_id's in a DB, from what I've read.