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.