Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

TCP as a hose-pipe and HTTP as the water flowing through it

I've just been reading some, and trying to conceptualize the difference between TCP and HTTP. I stole the analogy from here

share|improve this question
No, that implies that HTTP is the payload (or the data content), when it's another (higher-level) protocol. And water is a poor analogy since the data is packetized (and often buffered during transmission) rather than a continuous stream. – sawdust Mar 1 '13 at 2:20
OK thanks. Can you giver me a better way to describe it? – Erik Mar 1 '13 at 2:25
Is it like the difference between and operating system and applications? – Erik Mar 1 '13 at 2:26
up vote 1 down vote accepted

No, it's not a particularly good metaphor, but it kinda works (if you squint a little... and turn your head.... and ignore several problems... )

HTTP is a protocol, but TCP is another protocol as well. Protocol's are simply rules for talking to each other. In that sense, it's unfair to call one a 'hose' and another 'water' implying they have two different jobs.

I think knowing a little bit about the OSI model would be good for you to look at.

Essentially HTTP is a set of rules between applications to talk to each other. It defines rules for web browsers to talk to servers etc. TCP is a set of rules for end to end transmission and control. It handles connection between end points and reliability. But there are other protocol's involved, such as what occurs at a physical layer, network layer etc.

If I was forced to use an analogy I'd put it more like this. Hypothetical building where no one can leave their room yet need to talk to each other. There is a protocol that could communicate between people (say writing notes). If I want to send it to the next room I might need to put it in an envelope and send it according to the office mailing rules (i.e. address it Floor - Room number). If I wanted to send it to a different building I'd need to send it via courier across town (i.e. have the building address).

Suddenly if I want to talk to someone on the other side of town I'd need to write a note (protocol 1), put it in an envelope addressed to my ground floor where the courier picks it up (protocol 2) and get the courier to take it across town to a certain building (protocol 3). At the other end the person at the ground floor would need to unpack the courier box and take out the envelope (back to protocol 2), deliver it to the right floor and room number who opens the envelope and retrieves the note (back to protocol 1).

This "going up and down layers" is what occurs in the OSI model.

share|improve this answer
cheers for forcing yourself to use an analogy – Erik Mar 1 '13 at 23:40

That analogy does show a dependent relationship, but it implies that HTTP is the payload (or the data content), when actually it's another (higher-level) protocol.
And water is a poor choice for a medium since the data is not transmitted as a continuous bit stream. Ethernet data is packetized (and often buffered during transmission & reception).

Protocols are more like sending mail or packages.
Consider a layered scheme for paper mail:

1. intra-office mail,
2. corporate mail, and 
3. a courier service.

You want to sent a bound document to a fellow employee in another office in another city.
So you put the document in an inter-office envelope, and have the mail guy pick it up.

You local mailroom recognizes this is not for a local officemate, so your document is handled as corporate mail.
So to send it to the other office, your doc (in the inter-office envelope) is stuffed into a courier service envelope (think FedEX), and sent off.

On arrival at the other office, the courier service envelope is unwrapped.
The inter-office envelope is then delivered to the addressee, and he unwraps that envelope to read the document.

Your document is like the HTML (or other data) used by HTTP.
HTTP is like the inter-office envelope, that you (the user) relates to.
The mail guy and mailroom are like your web browser that wraps lower-level protocols like TCP/IP over the high-level protocol like HTTP.
The courier service envelope is like TCP/IP.
The courier service is like the Ethernet transport service, that actually moves the goods.

share|improve this answer

TCP is like a phone conversation, I call you, you pick up and say "hello". (SYN)

After we exchange greetings we start talking. As I am telling a long story, you reply every now and then with a "wow" or "ok!" or "that sucks!". (ACK)

The conversation continues until I say "Well I need to go." FIN

As far as the comparison between TCP and HTTP, in the above analogy, TCP is the etiquette of the conversation, whereas HTTP is the type of phone you are talking on. You can use a cell phone(HTTP), or a landline(FTP for example). The conversation method is the same, but the way you accessed the protocol is different.

Im sure someone can improve on that. Thats my attempt!

share|improve this answer
It's more that HTTP is a protocol talked over the phone (landline, cellphone, Skype, whatever). Much like people agreeing to talk in English, or in Spanish. It has its own way of interacting (ask for something, get it, ask for the next, send some data, ...). – vonbrand Mar 1 '13 at 3:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .