In all network communications one machine - client - initiates communication with another machine - server.
How does your computer then find out which server to ask for translation? Each computer is preconfigured with several addresses of "local DNS servers" - machines internal to the network the computer is currently connected to, that will proxy the translations. Each computer also has a DNS resolver, client application that will initiate translation requests. When you type a domain name, e.g., into your browser the DNS resolver contacts the local DNS server and asks about that name's translation. For example, at USC the server would contact 184.108.40.206 or 220.127.116.11. If another user recently asked for the same domain name the reply may be in the server's cache and it will provide it to the resolver. Otherwise the local DNS server will do one of two things: (1) resolve the name for the client, provide the answer and cache it (recursive service) or (2) point the client to the server that can help it (iterative service).
In both cases the client (or the local DNS server) starts the query at the authoritative server in charge of the longest suffix of the domain name that it knows about. For example, when resolving www.google.com a local DNS server at USC, acting recursively, could start with the server in charge of google.com if that mapping were in its cache. Or with the server in charge of .com if that mapping were in its cache. If no suffix mappings were in the cache the server would start with one of 13 root DNS servers. These servers fully replicate each other's content and are geographically well distributed. The root server would tell the local DNS server what is the IP address of the authoritative server for .com, and this server would tell it what is the IP address of the authoritative server for google.com. This server (google.com) would know the IP addess of www.google.com and would return it to the local DNS server, who would return it to the resolver on your computer. For more details about DNS see DNS On Wikipedia.
Both the TCP and the UDP headers hold source and destination port numbers. If you think of an IP address as the address of a building, the port number would be address of the apartment in that building. There are 65535 ports on each computer. Port numbers help the operating system deliver the network messages to the proper application. For example, imagine that you are running a Web browser on your machine, and a chat client. Both these applications need to communicate over the network, and both are at the same IP adress. When a message comes from the network the OS needs to know which application to give it to. The port number in the message tells the OS where to deliver it. The application in turn listens to events at that port number and consumes messages as they arrive from the network. Servers usually reside at "well-known" port numbers so that client applications always know which number to use to reach them. For example, a Web server always listens on port 80. The client application chooses a port number, attaches itself to it and communicates this number to the server via the "source port" field in the transport header.
UDP stands for User Datagram Protocol. It simply sends messages from source to destination and provides no assurance of their delivery. Applications that care about reliable delivery need to provide this service themselves. For more information about UDP see UDP on Wikipedia
TCP stands for Transmission Control Protocol. It strives to provide reliable delivery from the source to the destination. TCP segments messages from the application into chunks and prepends the TCP header to them. This header holds the sequence and the acknowledgment number for each segment and some other control information. You can think of the sequence number as the number showing the order of this segment in the communication (first, second, third, etc.) except that it starts from a random number and it counts bytes instead of segments. When TCP sends a segment (a packet) to the destination it waits for acknowledgment to come back saying "I got this packet". If the acknowledgment does not come back for a while TCP will repeat this packet. Acknowledgments are most-times cumulative (there are several TCP variations), e.g., if the destination sends "ack 30" it means it got all the segments numbered up to and including 30. Thus if an acknowledgment is lost but another arrives with the higher number the TCP sender will infer from it that all packets up to that number arrived successfully.
The link header is prepended last. It contains information about the sender's and the destination's MAC address - the physical address of the network cards. This information is valid only for one hop and the next router on the path overwrites it.
The source A needs to figure out where to send the packet for B. It looks into its routing table that only says "all traffic must go on interface with MAC address MACA" because this machine only has one interface. It then sends a query on that interface trying to learn the MAC address of the destination. The query looks like this "Who has IPB? Tell MACA" and B replies "MACB has IPB". The protocol that specifies this behavior is called ARP protocol - Address Resolution Protocol. The MAC addresses in the ARP query and the ARP reply help network interfaces at the machines understand that the packet is for them. While in my picture there are only A and B on this link in reality there may be many machines attached to a common channel (e.g., broadcast Ethernet or WiFi). They can all hear all the packets but will only consume those that are for their MAC address. Mappings between IPs and MACs get stored in ARP cache for a limited time.
Now imagine that A and B are three hops away like shown in the picture below. We will skip the ARP request/reply to find out which MAC belongs to which IP, assuming these mappings already exist in ARP cache.
Each node in the picture will first build a routing table showing the next hop to some destination. This table is built by nodes exchanging information with each other about destinations they already know about, such as their own IPs and the IPs of the nodes they are directly connected to. The packet starts from A carring the IPB as the destination IP address in the IP header, IPA as the source IP address in the IP header and MACA and MACC as source and destination MAC addresses in the link header. C looks up in its routing table information about next hop to IPB and overwrites the link header putting MACC and MACD as source and destination addresses. Similarly, D overwrites it with MACD and MACB. Finally, packet arrives at B, which consumes it.