Hello, I m at Your Service
"Hello, I'm at Your Service""Hello, this is Fred at Fred's Shipping Company. How can I help you today?" Yep, Fred, the owner, is answering the phones at his small shipping company. He's waiting for the phone to ring so that he can send his one driver, Barney, in his one truck to pick up a package and deliver it across town. To be ready for that first phone call, Fred bought a truck; hired Barney; got an office, phone lines, and Internet website; and did some advertising. Finally, the phone rang, giving Fred his first opportunity to ship the goods and make some money. Like Fred, transport layer protocols must be prepared for when an application layer protocol needs its services. If you use TCP/IP applications, the application layer protocols use TCP/IP transport layer protocols to send their messages across the network. Whereas the application layer protocols are typically part of the application software, the transport layer protocols are typically part of the operating system (OS) of the computer. So, the transport layer software hangs around, waiting on the application programspecifically the part of the application program that implements the application layer protocolsto ask it to do something. Figure 9-1 depicts the general idea. Figure 9-1. Application Program and Application Layer Asking the Transport Layer for Help As shown in Figure 8-4 in the previous chapter, the application program includes the user interface and the application layer protocols. In Figure 8-6, you saw some of the SMTP messages that were used to send e-mail. That figure and several others in Chapter 8 showed the messages going back and forth between two PCs. In reality, when an e-mail client like the one in Figure 9-1 sends these types of messages, it asks for a transport layer protocol to help. Generally speaking, when Those Who Came Before Us created networking models like TCP/IP, they defined a bunch of protocols. As it turns out, the protocols at one layer provide services to the protocols at one layer above. Conversely, protocols at one layer expect services from protocols that are one layer below. In this chapter, you'll read about how the application layer protocols such as SMTP expect the transport layer protocols, such as TCP, to provide the service of transporting the data across the network. Full-Service ShippingJust like a company can create its own shipping department, an application layer protocol could avoid using a transport layer protocol, but it almost never happens. Why? Well, the transport layer protocols already exist. They provide great services that many applications need. It takes a lot less time and effort for the application to use a transport layer protocol. In short, it's better, faster, cheaper, and simpler for an application to use a transport layer protocol. So, what do these transport layer protocols do for the application? This chapter focuses on one of those protocols in particularTransmission Control Protocol (TCP), which is defined in RFC 793. TCP/IP does have another transport layer protocolUser Datagram Protocol (UDP)but TCP is much more interesting. TCP provides a lot of features, and UDP doesn't. You can think of TCP as providing premium service and UDP as providing cheap service. This chapter will hit the high points of TCP, such as
You'll learn about each of these features in the next four sections of this chapter. Shipping Basics: Controlling Shipments Using Shipping LabelsWhen you decide to ship a package using any well-known shipping company, you fill out a shipping label, attach it to the package, and leave the package where the shipper will find it when he stops by that day. In short, you tell the shipper where to send the package and then choose among several options for delivery. Magically, the package appears at the correct destination. Although you might think that shipping labels are rather boring, there are a couple of key facts about them that are practically identical to TCP. For instance, shipping labels
Okay, back to networking. The term "encapsulation" refers to the same general idea for networking as does the shipping label for shipping packages. For example, Figure 9-2 illustrates a more detailed example of a simple HTTP GET request for a home page, with TCP encapsulation shown. Keith's browser requests the home page. However, the browser does not actually send the request over the network; it simply asks the TCP software on Keith's computer to send the data for it. (In this chapter, I am ignoring other network detailssuch as the physical transmissionbut that does happen as well.) Figure 9-2. Adding Shipping Information to Data by Encapsulating in a TCP Header Keith's TCP software, which is typically just a part of the OS, is in charge of delivering the data to the web server. TCP provides several services, so it needs a place to record some information about those services. Therefore, TCP defines a header. As mentioned in Chapter 5, "Rules of the Road: How to Use the Local (Network) Roadway," a header is a bunch of overhead bits that a networking protocol adds to some data. The protocol that adds the headerTCP in this caseuses those bits to record things it needs to know to do its job. Many of the upcoming features covered in this chapter record information in the TCP header to perform some useful function. The process of adding the TCP header to the application data is called encapsulation. Refer to Chapter 5 for a review of encapsulation. Imagine that Paul drives a truck for the shipping company. He gets to work each morning, and someone has loaded the truck. He gets in, starts driving, and stops to drop off and pick up packages. Paul doesn't care what's inside the packages. He might care a little about the size of the packages, particularly if a package is too large or heavy to move. Really, he just cares about what's on the shipping label and making sure he delivers the package to the right place. Similarly, TCP doesn't really care what data it's delivering to another computer. Figure 9-3 shows TCP's perspective on what really happens in Figure 9-2. Figure 9-3. TCP Treats All the Data as Data
TCP just needs to worry about the TCP header and doing what it says. In this case, as long as TCP gets the first chunk of data to the server and the second chunk back from the server to the browser, its job is finished. TCP calls the TCP header and the data behind it a TCP segment. Later in this chapter, in the section titled "Big Box, Small TruckWhat Do You Do?," it will be clear why the people who made up TCP chose to call it a segment. One of the largest benefits of a layered networking model relates to how TCP behaves in Figure 9-3. The fact that TCP doesn't have to think about what HTTP is trying to do means that the TCP software does not need to know anything about how HTTP works. So, the person who writes the TCP software can keep it simple. The person who writes HTTP software and any other application protocol that intends to use TCP can keep it simple as well, relying on TCP to deliver the data. If you're feeling a little uncomfortable about TCP at this point, it's okay. So far, this chapter has described some mechanisms that TCP uses, but it hasn't explained much about why TCP is useful to applications. In the next section, you'll learn about error recoveryone of the most important features of TCP. Purchasing Insurance for Your (Network) ShipmentWhen you ship something valuable, you might choose to spend some extra money to buy insurance. Then, if the shipper loses or damages the package, the shipper pays you to replace what you shipped. With TCP, you get something a little better. With a real physical package, if it gets lost, it's lost. If you lose a bunch of bits, though, you can make more! In fact, Chapter 3, "Building a Network: It All Starts with a Plan," covered the basic idea, which I'll repeat in Figure 9-4 for a quick review. Figure 9-4. Assuring Data Delivery
In Figure 9-4, Wilma's computer is sending three TCP segments to Fred. The second segment experienced some errors during transmission, and Fred noticed that errors had occurred. How did he know errors had occurred? Well, you might recall the frame check sequence (FCS) field in Ethernet that tells you whether something transmitted over a LAN had errors. Although this chapter doesn't consider Ethernet much, imagine that an Ethernet is in use, and that Fred does indeed notice that the frame had an error. The process is simple: The sender (Wilma) numbered the segments so that if one got lost, Fred could not only know that one segment had errors, but he could ask for the missing numbered segment. So, Fred asks Wilma to resend segment 2. In the next two sections, you'll read about how TCP determines which segments were delivered successfully, and then how TCP notices that segments were lost and need to be recovered. The Mechanics of Delivery ConfirmationTCP uses the same mechanisms to both confirm that data was delivered, as well as to notice when data wasn't deliveredand then to perform error recovery. To do all these things, TCP puts the interesting information in Figure 9-5 into the TCP header. First, look at a full TCP header in Figure 9-5. Then I'll tell you about the parts of the header that are used for error recovery. Figure 9-5. The Format of the Shipping Label: TCP Headers
When TCP adds the header, it has several different fields to use. For error recovery, it uses the sequence number and acknowledgment number fields. The sequence number identifies the segment, and the acknowledgement number is used when an error occurs. Figure 9-6 shows the sequence and acknowledgement number fields in action, when no errors occur. Figure 9-6. Delivery Confirmation, No Errors
In Figure 9-6, TCP confirms delivery of each segment using the sequence and acknowledgment number fields. However, the acknowledgment number looks a little funny. Wilma numbered the segments 1, 2, and 3, but notice that Fred sent back an ACK field of 4. The ACK field means that this number is the number of the next segment Fred expects to receive. So, Fred is really meaning, "I got everything up to number 4, so send me 4 next." By implication, Fred got 1, 2, and 3, respectively, because he set the acknowledgment field to the next number4 in this case. The use of the acknowledgment field to imply the next segment that should be received is called forward acknowledgment. By using the sequence number field in the segments it sends and watching the acknowledgment number field in the segment it receives, Wilma's TCP software can know that all three segments were delivered successfully to Fred. Next, you'll see how Wilma deals with the loss of a segment. Lose All You WantWe'll Make MoreSo, back to error recovery. Figure 9-7 shows a case in which a segment has errors (segment two), with Fred sending a segment with ACK of 2. Figure 9-7. TCP Error-Recovery Process
The process is identical to Figure 9-4, but Figure 9-7 shows the TCP header field values. Fred gets segment 1 and 3 successfully, so by implication, he knows that Wilma sent segment 2, but it either didn't make it to Fred, or it had errors in it. So, Fred sends a segment back to Wilma, with ACK set to 2. With forward acknowledgement logic, Wilma knows that Fred expects to get segment 2 next, implying that he got number 1, but not number 2. In response, Wilma sends segment 2 again. To be able to re-send segment 2, Wilma must have kept a copy of each segment. After a segment has been acknowledged, Wilma can release the memory to be used for other purposes. However, by keeping a copy, Wilma could re-send any lost segments. Notice that Wilma re-sent segment 2 only, allowing Fred time to send back a segment with ACK of 4. By doing so, Fred acknowledged receipt of the re-sent segment 2, and well as the earlier receipt of segment 3. Big Box, Small TruckWhat Do You Do?When you ship something, the shipper can easily handle your package, using the normal trucks, with a single driver stopping by to pick up your package. But the shipper does have a limit to the dimensions and weight of the package; otherwise, the package might not fit on the truck, or it might be too heavy for the driver to pick up. However, sometimes, companies need to send lots of stuffstuff that, when packaged, far exceeds the shipper's limitations for the size of a package. In some cases, the shipper sends special trucks to pick up the stuff, and maybe uses a forklift to load the truck. Or, the company wanting to ship something works with the shipping company to package the stuff so that the packages can be handled more easily. In networking, if a large piece of data needs to be sent, it's easy to break up a large number of bits into smaller pieces. As it turns out, Those Who Came Before Us decided to have the transport layer protocol break the data into pieces before transmission. If an application has a large amount of data to send, it gives the whole chunk of data to the transport layer protocol, and the transport layer protocol worries about breaking the data into manageable pieces. A maximum number of bytes can be put into a TCP segment (including the TCP header). 1480 is the typical maximum, although it can be larger in some instances. The maximum size of a segment is called the maximum segment size (mss). The application layer protocol does not have a limit to the size of bytes it chooses to send; it just lets the transport layer protocol worry about it. Here's how the application layer protocol thinks about the size of the data that should be sent:
The transport layer gets the bytes from the application layer, but it has an mss to worry about. So, the transport layer thinks something like this:
The process of breaking the data into parts is called segmentation. The bytes that include the data and the TCP header are called TCP segments because TCP often breaks up, or segments, a large chunk of data received from the applications. Figure 9-8 shows an example, where the file that contains the home page has 3000 bytes of data. Figure 9-8. Segmenting Data Before Sending TCP on the web server breaks the 3000 bytes of application data into three segments in this example. HTTP gives all 3000 bytes to TCP. TCP happens to have an mss of 1480, and because each TCP header is 20-bytes in length, only 1460 bytes can be put into the data part of a segment. Because TCP needs three segments in this case, it puts 1/3 or so of the data into each segment, as shown. Why Three Smaller Segments Is Better Than One Big SegmentWhy bother with segmentation? Why didn't the people who made up the TCP protocol just specify a larger mss? To see the need, keep error recovery in mind and consider this example. Imagine that you download a web page, and the web page has a logo of the company in it. The graphics file is called logo.gif, and it is 146 KB(Kilo Bytes) long. Now imagine that TCP sent all the data in one TCP segment. If you send 146 KB of data in one segment, and it gets there, all is well. However, if a single bit had an error during transmission, then the one and only segmentthe one with 146 KB in itwould have to be re-sent. All for one lousy bit error! By sending logo.gif as 100 segments with 1460 bytes in each segment, you would still send the whole file. However, if a single bit error occurred, only one segment would have had an error, so only one segment would have to be re-sent. Because some transmission errors will occur, limiting segments to some maximum size enhances the overall network performance. My Little White Lie About AcknowledgmentsOkay, let me confess something to you: TCP error recovery and acknowledgements do not work exactly like I showed in Figures 9-7 and 9-8. I purposefully simplified the earlier descriptions to get through some of the detail. Now that you've read most of this chapter about TCP, let me clear something up about TCP error recovery.
The TCP sequence number and acknowledgement number fields do not number the segments; they identify the first byte in the data portion of the segment. For instance, if a PC sent a segment, and each segment had just 1 byte in it, then sequence numbers and acknowledgements would work just like you read about earlier in this chapter. However, in the example shown in Figure 9-8, all the segments have 1000 bytes in them. So, Figure 9-9 shows the correct sequence and acknowledgement fields. Figure 9-9. Acknowledging Each Byte When the server sends the first segment, it starts with a sequence number of 1. However, the sequence number with TCP actually numbers the bytes, not the segments. So, from TCP's perspective, the first byte in the first segment is number 1, and the last byte in the first segment is number 1000. Keith's TCP software sees a sequence number of 1, and sees 1000 total bytes, and decides that the bytes are numbered 1 through 1000. When TCP at the server builds the second segment, it thinks like this: "The last sequence number was 1, and the segment had 1000 bytes. My next sequence number ought to be 1001 because the last byte in the previous segment was byte number 1000." So, as shown, the server does exactly that. Similarly, the server sends the third segment as sequence number 2001. The last byte of that segment would be number 3000. Finally, when Keith's TCP software acknowledges the data, it should acknowledge all received data. It received bytes 11000, 10012000, and 20013000 in the three successive TCP segments. Because Keith received all three, without error, Keith's next segment shows an acknowledgement of 3001the next byte he expects to receive. Delivering the Package to the Right Person, Not Just the Right AddressWhen you ship a package, you not only put the address on the shipping label, but you put the name of the person to whom the package is intended. The reason for that is obvious: You want to make sure the right person gets the package you are sending. Transport layer protocols do the same kind of thing. Imagine, for instance, that Keith has two browsers open: one to look at http://www.fredsco.com, and one to look at http://www.espn.com. Keith also has his e-mail client software up all the time, and he has an FTP client working, downloading some files. What happens when a new TCP segment arrives at Keith's computer? Well, the segment gets to the right computer, but it might have data for one of the two browsers, the e-mail client, or the FTP client, as shown in Figure 9-10. Figure 9-10. Keith's Quandary: One Segment, but Four Applications
If a package shows up at your office building, whomever happens to be standing around at the time looks at the shipping label, notices the name, and does what needs to be done to get the package to that person. Similarly, there's a field in the TCP header called the TCP destination port that tells the receiving computer (Keith's PC in this case) which application program needs to be given the data. For each application program that is currently being used on one computer, the computer assigns that application a unique TCP port number. To send data to a specific application on the computer, you send a TCP segment to that computer and plug the correct TCP port number into the destination TCP port number field in the TCP header. An example certainly helps in this case. Figure 9-11 shows how Keith uses the destination port field. Browser1 uses port number 1030, and browser2 uses port 1031. The e-mail client is using port 1040, and the FTP client is using port 1045. So, when the segment arrives, Keith's TCP software checks the TCP destination port field in the TCP header, which tells the PC to give the data to browser2. As long as each application running on Keith's computer uses a different TCP port number, Keith can receive TCP segments and figure out what to do with the data. Figure 9-11. Using the Destination Port Field Like a Recipient's Name on a Shipping Label
When Keith receives the segment, he looks at the destination port field. In this case, he found destination TCP port 1031, so he gave the data to browser2. The Chicken, the Egg, and the Destination Port of the First SegmentTo allow a computer to have lots of applications that use TCP at the same time, the people who created TCP came up with the idea of a destination port number field. However, there's a small chicken-and-egg problem, and it relates to how things get started with TCP. Imagine that Keith just started his second browserthe one I called browser2 in Figure 9-11. Keith starts clicking on something to bring up browser2, and then he fills in the URL for the web page he wants to get from a web server. Figure 9-12 shows an example of the first segment sent by Keith's PC on behalf of this new browser and the response segment from the web server. Figure 9-12. Initializing TCP Port Numbers
When an application on Keith's PC (browser2 in this case) first asks TCP to send data, TCP software running on Keith finds a TCP port number that he's not currently using and uses it for this new application. As long as no other application that is running on Keith's PC uses this same TCP port number, any future TCP segments that Keith's PC receives can be handled correctly. In Figure 9-12, Keith's PC uses port 1031 for browser2. Keith's PC hopes that the server will reply to its request for a web page. Keith expects that the segment he receives from the server will have a destination TCP port number field set to 1031. To make sure that happens, Keith's PC sets the TCP source port field in the first segment to a value of 1031. The TCP source port file contains the port number used by the application that sent the TCP segment. That way, when the server replies, it knows what to put in the TCP destination port field1031 in this example. When a client application first comes up, TCP on that computer dynamically assigns the application a TCP port number. These port numbers are sometimes called dynamically assigned port numbers, or ephemeral port numbers. Well, that's only part of the story. When Keith's PC creates the first segment in Figure 9-12, the one sent to the web server, Keith's PC must put something in the TCP destination port field. Why? Well, the computer where the web server software resides might have multiple applications running, so the server's TCP software would want to look at the destination port field in the received TCP segment to figure out to which application to give the data. In this case, Keith's PC put port 80 in the header because port 80 is the well-known port for web servers. Well-known ports allow the first segment sent between applications on two computers to have a useful destination port in it. Before Keith attempts to connect to the web server, the web server software tells TCP on the web server something like "Hey, if you get something for destination port 80, give it to me." Later, when Keith sends a segment with destination port 80 to that server, the server's TCP software knows to give the data to the web server software. In general, servers use well-known ports, allowing clients to put the correct destination port number in their initial TCP segments. Starting Off on the Right Foot Using a TCP ConnectionSo far in this chapter, you have learned about how TCP provides services to application layer protocols. Those services include basic delivery, segmentation, and error recovery. TCP also allows multiple programs to use it at the same time, keeping track of which segments are for which application using port numbers. To do all these functions, TCP uses several fields in the TCP header. Before useful communication can occur with TCP, both endpoints must agree to the values to use in those fields initially. TCP uses a process called TCP connection establishment to initialize several fields in the TCP header. Each time a browser connects to a new website, each time an e-mail client checks for incoming mail, and so on, a new TCP connection is created when the two computers participate in TCP connection establishment. Connection establishment is performed when the two computers send a specific set of three TCP segments to each other. After that, a TCP connection exists between the application programs on each computer, and the TCP header fields have valid initial values that both endpoints agree upon. The term TCP connection refers to an agreement whereby one application on one computer agrees to talk with another application on another computer. For example, in Figure 9-12, before Keith's PC could request the web page shown in the figure, a TCP connection had to exist between browser2 and the web server software. To create that TCP connection, three TCP segments flow between the browser and the web server. After that is completed, a TCP connection exists, with agreement on such details as what port numbers the browser and server use, what values to start with in the sequence number field, and other details. Any time you start a new TCP-based application, a new TCP connection is formed before application messages or end user data can be transferred. Figure 9-13 shows Keith once again, with his two browsers, one e-mail client, and one FTP client. In this case, the servers are also shown. The lines in the figure represent Keith's four TCP connections. Figure 9-13. Keith's TCP Connections
In this figure, Keith has four TCP connections, one from each of his client applications to their respective servers. |
EAN: 2147483647
Pages: 173