Yep, it's the nature of the beast (HTTP) in that you have to somehow exchange some piece of information between the host and the client and vice versa in order to differentiate requests from different clients. There is no way for the server to be sure that any two separate page requests come from the same client. Some users (such as AOL users) may have a different IP address for each request, the user agent string may vary from request to request depending on the browser and any proxies involved, etc.
This pretty much leave you with cookies, URL query string values, and form post data in order for the browser to "identify" itself in any reasonably certain manner. If the HTTP communication is not encrypted (i.e. SSL), then any of those options is essentially equivalent when it comes to being intercepted by a hacker listening on the connection somewhere. The URL query string has the additional down-side of being a usability issue (e.g.: the session ID would be part of a bookmark link), and the form post data obviously is only useful for when a form submission is involved.
Therefore, unless someone chips in here with another alternative of which I'm not aware, I would still opt for cookies as the best means for most session tracking. I would imagine that of the very small percentage of users who surf with all cookies turned off, the vast majority of them know how to turn them on if needed. Therefore, if my page does not receive a cookie, then if I output a message saying that cookies need to be enabled in order to continue and the user opts to not turn them on, then I'm willing to lose that tiny percentage of users who would intentionally refuse to do so.
