The transport layer of the OSI Network model, Layer 4, is the layer that makes client-server applications a reality. In Layer 3, we looked at routing functionality. Now we need to consider an intermediate layer between routing and a computer application.
A simple server operating inside a corporate Intranet can be configured to carry out many functions. The server could be running Apache web server software, an FTP server daemon, a mail server daemon, and so forth. There are many applications running simultaneously on one high-end, very expensive server.
How is it then when a user launches an FTP application and merely types in an IP address that a directory on a remote server magically appears? The user only specified an IP address of a remote server to download from. The IP packet certainly has no information in its header regarding the type of service required.
Is there some hocus-pocus going on, or is there a protocol that is assisting applications? We're going to examine a special protocol suite, Transmission Control Protocol over IP protocol (TCP/IP), that does exactly this.
Computer bookstore shelves are stacked floor to ceiling with books on the TCP/IP protocol suite. Like the OSI Network Reference seven-layer model, TCP/IP suite outlines a model for several protocols at different layers. The TCP/IP protocol suite is a four-layer model that closely resembles the OSI model. The lowest layer, Layer 1, is the link layer which is identical to the OSI datalink layer. Layer 2 of the TCP/IP suite, is the network layer. Layer 3 is the transport layer and Layer 4 is the application layer.
|
|
Also in Networking as a 2nd Language: |
There is some degree of confusion when first learning this suite. Under the OSI Model, TCP and UDP are Layer 4 protocols. Under TCP/IP, they are Layer 3 protocols, which is now the transport layer. To muddy things up a bit further, there are two distinct protocols operating at the transport layer. They are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). UDP is a part of the TCP/IP suite and it behaves significantly different from its transport layer cousin, TCP.
The primary distinction between TCP and UDP lies in how each protocol behaves. TCP is a complex protocol that provides connection-oriented reliable features to the application layer. Once data is handed off from the application layer to the transport layer, using TCP as the transport protocol, the application also hands off flow control to the lower layer. TCP will use its built-in messaging mechanisms to ensure the application data makes it to the destination device.
UDP is a connectionless and unreliable transport-layer protocol. The UDP protocol is extremely simplistic in nature. Data from the application layer is handed down to the transport layer and encapsulated in a UDP datagram. The datagram is sent to the host with no mechanisms to guarantee the safe arrival on the destination device. This checking is pushed back up to the application layer if reliability is desired.
|
Classically, TCP's connection-oriented mechanism is referred to as a "three-way handshake." The TCP protocol has special messages for establishing a connection. These are: synchronization, or SYN which synchronizes sequence numbers in the TCP header; acknowledge, or ACK which makes sure the acknowledgement number is valid; and maximum transmission unit (MTU). When TCP client wants to create a connection with a remote server, it will send a SYN message.
|
A SYN message is a bit flag in the TCP header. When the SYN flag is set, it means that synchronization is requested with the remote server. The client will send an initial sequence number. Included in this header is also information on the maximum transmission size, or MTU. When the server hears the connection request, the server will respond with a message containing the SYN and ACK bit fields set in the responding TCP header. The header will also contain the sequence number for validation. The client will respond back with an ACK and the sequenced number is incremented by one. This method of TCP connection is called a three-way handshake.
TCP and UDP run over the IP protocol, which means that both the client and the server are required to use IP addressing. The application too must identify itself to the TCP/IP protocol and this is achieved through 16-bit port numbers. Basically, two styles of port numbers exist. They are, well-known port numbers and ephemeral port numbers.
Well-known port numbers, whose range is 1 to 1023, are managed by the Internet Assigned Numbers Authority. Well-known TCP ports include FTP, port 21; and telnet, port 23. This means a Macintosh using telnet to access a Unix machine will request port 23. Well-known port numbers are reserved across platforms for TCP/IP.
Ephemeral ports are used by clients to establish contact with the server. The client doesn't need a well-known port number. Ephemeral ports are in the range of 1024 to 5000. When writing custom applications for a client-server, port numbers can also be selected from this range. An example of a custom application would be an Internet game that requires sending game update messages to all players. The game server would probably use a port number of 2000 and the clients would use a port number value of 2001.
The TCP/IP protocol requires that the protocol be identified (whether it's TCP or UDP) in the IP header along with source and destination IP addresses. For TCP/IP to communicate with the application, a 6-bit port number is required for the source and destination. These three components are required to establish the virtual circuit. Under the TCP/IP suite this virtual circuit is called a socket.
For the Sprockets network, recall that we have robots working on the manufacturing floor. Our network engineer, Nanna Spacely, is only involved in the assigning of IP addresses for these devices. It is up to the application programmers to assign the proper ports numbers for the client and server applications.
|
This has been by no means an exhaustive discussion on the powerful TCP/IP protocol suite. A slightly more in-depth document, Understanding TCP/IP, is available at the Cisco Systems "univercd" web site. Protocols.com is also another good site for expanding your knowledge on TCP/IP. This site is also broken into links by network layer model which makes it kind of nice to use.
For the next installation of Networking as a Second Language, we're going to examine an interesting protocol -- multicast! So don't miss out.
Michael J. Norton is a software engineer at Cisco Systems.
Read more Networking as a 2nd Language columns.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.
