Not all applications use TCP. Some use a connectionless protocol called User Datagram Protocol (UDP). With UDP no connection is made to the remote computer that you are sending data to – the packets just go. If a packet gets lost or corrupt your PC will never know because there is no mechanism built into UDP to recover data. An application can be written to perform segmentation and error recovery, but why bother when the same application could be written to use TCP. UDP is useful for DNS requests, audio, and video data – if you lose a packet in an audio or video stream do you really want to wait for it to be retransmitted? Nope, just drop the packet and move on. UDP also has a smaller header size than TCP, so you use less bandwidth on packaging and have more bandwidth for the actual data that is being sent.
UDP, like TCP, uses port numbers (source and destination) so the Transport Layer can keep track of the data – you could have multiple applications sending and receiving data across the network. But each application receives a unique port number from the Transport Layer. Every time an application sends data to the Transport Layer, the Transport Layer “tags” the data with the application’s unique port number. When a reply to an application’s request comes back, the Transport Layer knows which application to give the data to because the reply will contain the application’s port number.
Port numbers range from 1 to 65,553. The numbers below 1024 are reserved for services (like Hyper Text Transfer Protocol – HTTP is always port 80). Numbers above 1023 are available for client applications, like the web browser you are using to read this page. Every browser window that you have running was assigned a unique port number when you opened the window. That’s how you can have multiple windows open, all surfing to different pages, and the correct web site loads into the window that requested the data.
We have covered how data flows through the TCP/IP stack from a physical standpoint. But there is also a logical aspect to cover. You see, the different layers in the TCP/IP stack are independent for the most part. The Application Layer at the sender sends data down to its own Transport Layer, but for all practical purposes the sender’s Application Layer is logically communicating directly with the application layer on the receiver.
The same holds true at the sender’s Transport Layer. The Transport Layer on the sender sends data down to its own Internet Layer, but the sender’s Transport Layer is logically communicating directly with the transport layer on the receiver. The sender’s Internet layer sends data down to its own Network layer, but the Internet Layer on the sender is logically communicating directly with the Internet layer on the receiving side of the connection.
The Network layer communicates with other network layers on the Local Area Network (LAN) that it is physically connected to – there is no logical connection to the destination computer’s network layer.