Data Transfer Over A Network It's time to explain how data flows across a network - any network, including the Internet. Also time to explain certain key TCP/IP terminology in more detail. So sit back, prop your feet up, and get comfortable - this might be a long one ... Normally, the different layers in the TCP/IP stack don't care about each other. For the most part each layer dumps data to the layer below it, or passes data to the layer above. There are special situations when the layers do interact - establishing a connection is one of them. When you type www.dalantech.com into your browser's Universal Resource Locator (URL) window and hit Return, the browser signals the Transport Layer (TL) that it wants to establish a connection and passes the URL down. The first packet to go down the stack is a User Datagram Protocol (UDP) packet with a destination port of 53 to the Internet Protocol (IP) address of your Domain Name Service (DNS) server to request the IP address of www.dalantech.com Connection Oriented Transfer (TCP) As soon as the IP address for the web site is returned, the transport layer initiates a Transfer Control Protocol (TCP) connection to the server that stores the web site by sending a Synchronization (SYN) packet. In that SYN packet the following values are proposed: Maximum Transmittable Unit (MTU): The maximum size of all the future packets that will be sent while the connection being negotiated is active. The MTU equals the combined data generated by the Application, Transport, and Internet Layers. Maximum Segment Size (MSS): The maximum segment size that will be transmitted from sender to receiver. The segment is the data portion of a TCP/IP packet (MSS = MTU minus the 40 bytes that make up the TCP and IP headers). Receive Window (RWIN): The number of segments transmitted before an acknowledgement is sent by the receiver to the sender. The RWIN value is always a whole number multiple of the MSS (no fractions). The server that provides the web page will either accept or reject your PCs SYN packet by transmitting a Synchronization Acknowledgement (SYN-ACK). If accepted, your PC will send one more SYN packet and the web page will start loading into your browser window. If rejected, the SYN-ACK your PC receives will have the corrected values listed. If your PC accepts the changes it will send another SYN packet and the transfer will start. If your PC cannot accept the new values another SYN packet will be transmitted by your PC to the web server with more changes - and the process continues until both sides agree, or the connection times out or is cancelled. This system of SYN and SYN-ACK is why the transport protocol is referred to as connection oriented - a connection has to be established before the transfer of data can begin. The process of establishing a connection is also sometimes called "hand shaking." Now you have a connection to the web site and data is flowing. Packets are being sent from the web server to your web browser and the page is loading on your PC. Sounds simple ... well, let's talk about what's really going on ... Data from the web page is being "packaged" by the different layers of the TCP/IP stack (Note: all TCP/IP data is packaged). Think of it as a box inside a box. As the data from the Application Layer (AL) on your computer moves down the TCP/IP stack each layer "wraps" the data in its own package. The Transport Layer (TL) adds a TCP or UDP header (depending on the type of data transfer requested by the AL) with a source and destination port number. The Internet Layer (IL) adds an IP address (source and destination). The Network Layer (NL) adds a Medium Access Control (MAC) address (source and destination). The packet is then transmitted over the network to another node on the same network as your computer ... What?! It's not transmitted directly to www.dalantech.com you ask? Nope, it's sent to the default route that you have configured in your TCP/IP settings, or the default route supplied by your Internet Service Provider (ISP) when you logged in. You see, MAC addresses are used to communicate with devices that are on the same logical and physical network. IP addresses are used to communicate with devices on different logical networks (Note: You could have two logical IP networks on the same physical cable, but if you don't have a router or a bridge connecting them the nodes on one IP network will not be able to send data to nodes on the other IP network). So, the source and destination MAC address is constantly changing as a packet is routed across a network (or the Internet). The source and destination IP address remains the same. As the packet is moving up the TCP/IP stack on the receiving computer, each layer "unwraps" the package. The Network layer "unwraps" the Network Layer "packaging" by removing the source and destination MAC, the Frequency Check Sequence (used for error detection, the Network layer calculates a new FCS value and compares it with the FCS that was transmitted with the packet. If the two FCSs don't match the packet is ignored ) and then passes the packet to the Internet Layer. The Internet Layer "unwraps" the Internet Layer packaging by removing the IP header (source and destination IP for example) and then passes the packet to the Transport Layer. The Transport layer removes the Transport Layer header and passes the data to the correct application (determined by the destination port number). Now let's back up a little. Earlier I told you that the Transport Layer on your PC negotiates a connection with the remote computer that you want to connect to - and that is true. But what about all of the routers, bridges, and other pieces of routing hardware that your data has to pass through to reach the destination IP address? What if one of them had a lower MTU than what you negotiated? Would you still get a connection and be able to transfer data? Sure, but not without a few penalties ... keep reading. For the purpose of explanation I'm gonna keep it simple and use a small network. But, what I'm about to tell you applies to all networks - regardless of their size. Take a look at the network below: Your PC - R1 - R2 - R3 - Web Server Router one (R1) and Router three (R3) both have an MTU of 1500 bytes (the TCP/IP maximum) but Router two (R2) has an MTU of 1000 bytes. Your PC can sense the MTU of R1 because both of them are on the same network. Likewise for the web server and R3. So your PC is going to negotiate an MTU of 1500 bytes, and the web server is going to accept. As data is being sent from the web server to your PC, R3 will receive the packets first. R3 can sense the MTU of R2 because they each have a connection on a common network. R3 will then fragment every packet it gets from the web server into two packets at the IP layer (one with an MTU of 1000 bytes and the other with an MTU of 500 bytes, for example) before they are transmitted to R2. R2 will send the packets to R3 and R3 will reassemble the fragments before they reach you. Works great huh? Keep reading ... Let's say that we wanted to transmit 14,600 bytes of data. If the MTU remained a constant across all of the equipment between sender and receiver only 10 packets would have been transferred (MTU - 40 = MSS or 1500 - 40 = 1460 bytes). But since the packets had to be fragmented between R3 and R2 we had to send 20 packets across the R3 to R2 link. Each packet had to have a MAC and an IP address - bits that don't count toward transferring application data. In fact, the extra packaging decreases the Effective Bandwidth (EB) of the data transfer (EB is the actual amount of data that is transferred between two points). But wait! It gets worse ... let's say that during the course of the data transfer one of the fragments gets corrupted or lost. The IP layer (where fragmentation occurs) is connectionless - it can detect corrupt packets and fragments, but it cannot request the retransmission of missing or corrupt data. If the IP layer detects a corrupt packet (or fragment) the entire packet is just "dropped" - the IP layers clears out the offending data. The Transport layer has to request that the entire packet be retransmitted. Since the number of packets needed to transmit a given amount of data increases when the packets are fragmented, the chances that a packet will be lost goes up ... Think it can't get any worse? Bzzzzzt! Wrong! There is a term that impacts effective bandwidth and it's called propagation delay. Propagation delay is defined as the amount of time it takes a signal (data) to flow through a device. The greater the fragmentation and reassembly of packets, the longer it takes those packets to get from point A (a web server) to point B (you) - as propagation delay increases effective bandwidth decreases (ouch!). Fragmentation was incorporated into the Internet Layer to allow for possible differences in MTU - but it's not a good thing. If at all possible you do not want to fragment your data. It is faster to use a lower MTU - one that every piece of gear between the sender and receiver can handle - than it is to send the TCP maximum and force fragmentation. But, if the transport layer on the sender and receiver negotiates the MTU, how can we figure out what the best MTU is between the two points? Hmmm ... The way to figure out the best MTU between two points is to use Path Maximum Transmittable Unit Discovery (PMTUD). Here is how it works: Before a connection is negotiated your PC sends out a packet with an MTU of 1500 bytes - but with one minor difference from before. Every Ethernet packet has a special "flag" (a packet control bit) called the "Don't fragment" flag, and in this packet the bit is set (or active). As the packet moves from router to router it may reach a router that can't send the packet - the MTU of the next device in the path is lower than the MTU of the packet, and since the "Don't fragment" bit is set, the transfer fails. The router that could not forward the data sends an Internet Control Message Protocol (ICMP) error message (trivia: ICMP type three code 4E) back to your PC letting you know that the transfer failed because the MTU was too high. Your PC then sets a lower MTU (how much lower varies depending on who coded the PMTUD function of the TCP/IP stack on your computer) and the process starts all over. Eventually, your PC will get a packet all the way to the server you where trying to reach. Your PC then initiates a TCP session with the correct MTU. Sounds time consuming? Well, it is - but it works and you get faster data transfers. You have now established a connection and the data is transferred. What happens next? Well, for a TCP connection the process that kicked it off (SYNs and SYN-ACKs) is very similar to the process that ends it. Only now your PC is going to send a Finish (FIN) packet and the server you are ending the connection with will send a Finish Acknowledgement (FIN-ACK). Your PC will send a final FIN packet and the connection is gone. Connectionless Transfer (UDP) 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. Port Numbers 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. Data Flow 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. Sender Receiver ====== ======== Application Layer <- Talks to -> Application Layer via the via the Transport Layer <- Talks to -> Transport Layer via the via the Internet Layer <- Talks to -> Internet Layer via the via the Network Layer Network Layer http://www.PCNineOneOne.com