Hmm.... How to better explain this. Well, here's how I learned, which made things much much more comprehensible.
If you ever really want to know what's going on, grab
WireShark. It can capture all ethernet traffic, and display it using protocol filters. As IP, TCP, and HTTP are quite common, they're supported protocols. Set it running on your default ethernet device to capture all TCP traffic on port 80 (you can probably select this filter rule from a dropdown), and then make a few web requests. It may help to shut down other things that make web requests so your capture log doesn't get polluted with their stuff. Right click on one of the captured packets, and choose "Follow Stream". You can then see the HTTP headers, along with the HTML response bodies. Do a few runs to try an empty page, a page with an embedded picture or two, going through a login process (look for cookie headers in particular there), and form submissions. Maybe try a few variants on the form submission stuff. You probably want to use a seperate capture session each time, and stop to look at the results before continuing on to try the other requests. There may be multiple streams to follow if there is enough traffic, so it's easier to do things and examine it piecemeal, plus, it's just less information to sort through all at once.
Important points to note:
1) The request/responses have an HTTP status line (such as "HTTP/1.1 200 OK"), followed by "Header: Value" lines, followed by a blank line, and then finally the request/response body. Each line is terminated by a full CR LF (13 10, or 0xD 0xA pair, even on Linux).
2) A page with embedded images results in separate GET requests for the page and each referenced image or file.
Note: As each HTTP request is stateless, any needed authentication will need to be done for each request.
3) Check for the Set-Cookie header in the response from the server to the client after the login is processed (most likely), followed by further requests from the client with the Cookie header set. You might also check into the Set-Cookie sent when logging out (most likely).
Note: Some sites will set a cookie before login, and just set internal values in a database of some sort during login to map that cookie to the login session, and then delete those internal values during logout. Hence there might not be a Set-Cookie at those points. Usually though there are, particularly since doing it the other way is perhaps not the greatest efficiency or security setup.
4) When submitting forms, check out the difference between GET and POST form submission. Watch how the variables are passed. Try a form with multiple controls with the same name attribute.
Finally note that there are 3 ways for the client to pass data to the server, all of which you should now have observed:
1) The initial HTTP line in the URL (such as the "?varname=value&var2=value2" part often used in form GET submits, or some non form related URLs).
2) The HTTP Cookie header.
3) The HTTP response body (such as in form POST requests).
Understanding these three ways of passing data, and how they work will help greatly in writing login and form processing code (such as a login form). They will also be the basis for further security discussion.
Also, if there are terms you don't understand, which ones in particular?
