Each layer in the stack has its very own function and all layers together form the complete functionality, the "stack".
Ethernet (physical and data link layers) transports packetized data in frames within a local segment. While the physical size of this segment can be many km, it's usually much more limited, to a building for instance.
IP (network layer) uses this functionality and puts logical addresses on top that can be routed on a global scale. Its IP packets are wrapped in Ethernet frames for delivery in a local segment. Multiple segments = IP subnets are connected by routers. Frames can't cross routers but the IP packets inside can.
IP is still only transporting readily packetized data. In order to get a data stream that an application can easily use, a transport layer protocol like TCP creates a virtual, bilateral, stream connection (a socket) that is very similar to a simple, serial connection - think of a telephone call between two parties. The inner workings of TCP are far more complicated than most things on the lower layers and not so easy to grasp. The beauty is that you don't necessarily need to know how it works in order to use it.
HTTP is an application layer protocol that makes use of this socket connection to GET a resource from a web server (a web page, graphics file, ...).
Because TCP does all the packetizing and reassembly work, and IP does all the work traveling across the globe, and Ethernet does all the work messing with the cables and hardware interfaces, HTTP can concentrate on its own job and keep it (rather) simple.
This is a simplified, rough overview. Of course you can use other physical and link layer protocols with IP, but Ethernet is extremely popular. You can also use other transport protocols on top of IP, depending on the application's requirements. And obviously, you can use an extremely large variety of application protocols on top of TCP or UDP or whatever.
The key to packet networks is that you can run all of this together in a single, extremely multi-functional network.