HTTP Cookies are a simple work around to the intrinsic statelessness of the HTTP protocol. The basic idea is that the server sends an extra header with an HTTP response. The header might look like this:

Set-Cookie: attribute=value; domain=.arachna.com; path=/edu; expires=Thu, 24-Jun-2004 00:37:39 GMT; secure

Here'a breakdown of components of a Set-Cookie header:

Name/Value Pair	attribute=value	required -- this is the basic data payload. The value can be a URL encoded string with additional parameters in there but from the cookie "envelope" view, there's just a name and a value.
Domain Scope	domain=.arachna.com	optional -- by default the browser is supposed to only send the cookie back to the host it accessed when the cookie was issued. However, the host www.arachna.com can set a cookie for ".arachna.com" such that any web hosts accessed with the arachna.com domain name would get the cookie as well.
Path Scope	path=/edu	optional -- this will limit the URI path for which the cookie should be sent back, the default is all URI's (i.e. the equivalent of "path=/")
Expiration	expires=Thu, 24-Jun-2004 00:37:39 GMT	optional -- by default the cookie will last as long as the browser is open ("a session"). If the expiration is set to sometime in the future, the cookie will be persisted by the browser (usually, that's a text file or a bunch of text files). To expire a persistent cookie, it must be reissued with the expiration set to sometime in the past.
SSL flag	secure	optional -- this tells the browser that the cookie should only be returned via the HTTPS (HTTP over an SSL connection) protocol

As long as all of the constraints are fulfilled, the browser's responsibility is to simply return the name/value pair in the request headers:

Cookie: attribute=value

The browser should continue to do this until the cookie is expired or the session ends.