a network and a protocol
Imagine two people who want to talk but are in different rooms. First they need a way to carry sound between the rooms - a telephone line. Second, they need an agreement about how to use it: who speaks first, what language they share, how to say 'I did not catch that, repeat'. A network is the wiring that carries messages between machines; a protocol is the agreement about what those messages mean and in what order they go.
More precisely, a network is a set of machines connected so that bytes can travel from one to another - over copper, fibre, or radio. A protocol is a written rulebook that both sides implement identically: it fixes the exact format of each message (which bytes mean what), the order messages must follow, and what each side does in response. Because both ends follow the same rulebook, a laptop made by one company can talk to a server made by another that it has never met. The internet works only because everyone agrees on the same small set of protocols.
Why it matters: almost nothing in networking makes sense until you separate the wire from the rules. The wire just moves bits; it has no idea what they mean. All the meaning - 'this is a request', 'this is the end of the message', 'resend that piece' - lives in the protocol, which is software you and the other side both run. Most of this field is really about which protocol you are speaking and what its rulebook promises.
When your browser fetches a page, the network (your wifi, your router, fibre across a city) carries the bytes; the protocol (HTTP riding on TCP riding on IP) decides those bytes mean 'GET this page' and 'here is the page, 8421 bytes long'.
The same wire could carry any protocol; the rulebook, not the cable, gives the bytes meaning.
A protocol is not a program you download - it is a specification that many programs implement. Two correct implementations of the same protocol must interoperate even if they share no code.