This is going to be a simplification.... an EXTREME simplification but here is a mental picture to give you an idea....
The responsibility of Internet Protocol (IP) is to get packets from one machine to another by address (Internet Address). In that regard, think of it as a "taxi cab". "I need a taxi to take a packet from 192.168.1.102 to 192.168.0.193!" What is in the packet??? IP really doesn't know....it really doesn't need to know. But, built in to that IP packet, is a cargo. That cargo is a TCP packet.
Transmission Control Protocol (TCP) is the next layer embedded in the IP packet. TCP is addressed by addresses that we call "ports". Ports are the way that packets get steered to the correct software once they have reached the correct machine. Kind of like, when the taxi driver takes you from one street address to another, and that address happens to be an apartment building. The taxi driver's job is to get you to the address....where you go when you get there is not their concern.... you have to get to the correct apartment number.
There are 2 most commonly used protocols under TCP, one called TCP....the other called UDP.
TCP in this sense is a connection based protocol. To use it a program on opens a connection to a port on the remote machine. (Note: the remote machine must have a program up and running ready to receive packets on that port.........called listening. This is the job of a "server"!). Once this connection is made the addressing is established all the way from the senders port on the local machine to the receiver's port on the remote machine. From here you just poke packets in it like a "pipe" and they pop out on the other end, in the correct program, ready to be used at the remote end. TCP in this manner guarantees deliver, properly sequenced and error free. Error detection and retransmission are built in to the protocol.
User Datagram Protocol (UDP) is for sending individual packet-messages, often called datagrams. Each is considered to be self-standing. There is no handshake, no acknowledgement, delivery is not guaranteed.....you should think of this as a "best effort" to deliver the packet to the remote port.
So think of it this way.... if a programmer has data to send, she/he hands it to TCP on a local port. TCP builds the data in to a TCP packet and passes that packet to IP. IP accepts the the TCP as it's own data, builds it into an IP packet and passes it on to the hardware layer. From here it goes to the wire, in to the remote machine where the IP layer receives the packet, strips the data out (which is a TCP packet!) and passes it to the TCP layer. TCP looks at the destination port number, verifies that there is a program listening on that port, and sends the TCP packet's data (which is the original data) to the application program.
Again, this is overly simplified, but it roughly describes the process.
SCJP - 86% - June 11, 2009