Some clever people came up with a method of passing information, such as user login, from one page to another in the early days of the internet.
The way it worked is that when the browser requests a page from a website, the server checks to see if a session ID is being sent with the request. If there is no session ID, then the server will generate a random one (the random bit is important later), and send the new session ID with the rest of the page. At this point, the server has also created a session file (or a database record) associated with that ID to act as a datastore for information which might be needed. A timer is usually set as well, so that the session is only valid for a limited time (which is why, sometimes, when you spend 30 minutes agonising over whether to get the new Super-Scary-Epic Movie and then click 'buy', your shopping basket empties out).
The next time the user clicks on a link, the session ID is also sent, and the server checks to see if there is a valid file (or record) that matches, and makes the information in the file available to whatever scripts are being used to generate the new page. The timer is reset, so you get another 30 minutes to agonise over getting the sequel.
The session ID is usually stored as a cookie on the client. In fact, cookies can store the same information that might be stored in the session file on the server. However, there are issues of security and performance (all cookie information for a particular site is sent back and forth every time a page is requested) - so it is a good idea to store as little as possible in cookies. I won't be talking much about cookies for the rest of this article, but I will come back to them some other day. For now, the only cookie that matters is the one that stores our session ID, and we don't really have a lot more to say about it.
The last thing about the session cookie on the client is that it will "stay alive" until the browser is closed. This means that if you go to a completely different site, and then return to the shop a little later (before the session timeout), your selected items will still be there. This is also why you can easily recover sessions if your Firefox crashes on you (I don't regularly use IE, but I expect version 7 is likely the same).
If cookies are blocked by a client, for whatever reason, then the resort is to put the session ID in the URL. For example, a site might have its links looking like http://www.example.com/page.php?PHP_SESS_ID=a1fbfbf120c02 or somesuch. Most servers are configured to do this transparently these days and, besides, blocked cookies are becoming less and less common these days, so it isn't really a problem.
So, a session is the time over which a user is interacting with your site, and the session data is the information collected and stored over that time