After completing these activities you should be able to:
Up to this point, as we have been working up the TCP/IP Stack we have discussed how data is passed between hosts within a local network, and across the Internet. But, what about programs? How does your web browser fit into the system? After all, you know that your web browser is certainly communicating via the Internet. Well, that is where the Transport Layer comes in; the Transport Layer connects a process on one host to a process on another host. Remember that a process is just a program in execution. Using an example, the Transport Layer will connect a web browser process on Alice's host to a web server process on Bob's web server.
Datagram. A message at the Transport Layer is called a datagram. Beyond connecting processes, Transport Layer protocols start the process of breaking arbitrary length Application Layer messages into smaller pieces for sending across networks. For example, you're on your phone and you want to download and install the latest social messaging app GipGak. The action of initiating the download is your request from the Application Layer, but the GipGak app is over 50MB in size, while most packets are 1500 Bytes in size. At the Application Layer the app store sends the single 50MB file, but the Transport starts to break that single large message into smaller datagrams that can traverse the Internet. The Transport Layer is also the start of the encapsulation process on the sending end in the TCP/IP Stack, and conversely the end of the de-encapsulation process on the receiving end.
Ports. An IP address identifies what host we want our data to go to, but not which of the many processes executing on the host we want that data to go to. If we were to make an analogy to telephone traffic, it's like calling a big office: the phone number gets you to the office, but you need something extra — an extension — to identify which specific phone in the office you're trying to place a call to. At the Transport Layer a port takes the role of the office phone number extension for networked communications. A port number identifies the process on the host communicating. Just like the Data Link Layer and Network Layer addresses, for each networked communication there is a source port and a destination port. The source port identifies the process communicating on the source host, and the destination port identifies the process communicating on the destination host.
A port number is a 16-bit non-negative number, which means it's in the range 0—216-1 = 65535. You might have noticed that a port is much smaller than a MAC address or an IP address, well there's some rationale behind that. Each network interface has a unique MAC address, and MAC addresses are allocated based on manufacturer; hardware manufacturers are assigned large blocks of MAC addresses for the hardware they make. If you were a hardware vendor, would you want to be able to produce and sell a small number or large number of devices? Obviously a large number vice a small number. Additionally, having a large address allows new networking technologies to operate using the same concepts; e.g. Wi-Fi, and Bluetooth both adopted the 48-bit MAC address from Ethernet. Obviously we need a large number (32-bit for IPv4, or 128-bit for IPv6) in order uniquely identify all the hosts connected to the global Internet. But how big does a port number need to be? Is 16-bits enough? Well, how much multitasking do you like to do? Better yet, how much multitasking do you think you can do? Can you manage 65 thousand processes all running at the same time? In practice 16-bits to represent the processes communicating on a host has not been an issue.
netstatrequires an Administrator shell.
There's a utility called
netstat that shows you what port (or Application Layer protocol) combinations are currently in use on your machine.
netstat is a shell utility on both Windows and UNIX.
netstat output on Windows might include an entry like this:
Active Connections Proto Local Address Foreign Address State ... TCP 10.53.33.254:60503 18.104.22.168:443 ESTABLISHED ...
What this tells us is that there is an established connection between the local host (
10.53.33.254) on port
60503 and the remote host (
The Proto in the code listing above is TCP which stands for Transport Control Protocol, we will look at TCP later in this discussion.
The Local Address includes one piece of information that you should recognize, the dotted-quad of the local host's IPv4 address.
The second number, the number after the colon, is the local port that the process on the local host is using for the communications.
It is common to write the combination of an IP address and port with a colon (
: ) separating the two numbers.
The Foreign Address represents the remote host's IP address and port.
The ESTABLISHED state means that the connection is established; i.e. that the hosts are communicating.
You can view all server processes running on your host by name and process ID by running
netstat with the following options in an Administrator shell:
C:\>netstat -bno Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 900 RpcSs [svchost.exe] TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1448 CryptSvc [svchost.exe] TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING 544 [wininit.exe] TCP 0.0.0.0:49376 0.0.0.0:0 LISTENING 608 [services.exe] UDP 0.0.0.0:68 0.0.0.0:0 LISTENING 988 Dhcp [svchost.exe] ...
0.0.0.0 IP address indicates that the local host is listening on any of its IP addresses, remember hosts can have multiple network devices, and therefore can have multiple IP addresses.
Notice that each of the processes listening (State LISTENING) are listening on a specific port; i.e. even though the host is listening on all IP addresses, a process listens on a specific port.
Since the processes are listening for incoming communications, they are considered server processes; in networked communications the process that is listening for incoming communications is the server process.
As server processes they are waiting for an incoming communication from a client process on a remote host.
Once a client process on a remote host sends a message to the server host, the connections would switch to ESTABLISHED as in the first code listing.
Now, we can figure out which network services are running on a computer. This is a big deal when it comes to assessing a computer's risk for intrusion. Think of it this way, if you wanted to protect your home from intruders, then you would want to know where all of the possible entrances are so that you could secure or seal them. The same notion applies to processes providing network services on computers, fewer running services (and hence, fewer open ports) is better (more secure) than more running services. Unnecessary services should be stopped and removed from computers to make them more secure from network based attacks.
There are two protocols that dominate, usage wise, the Transport Layer on the Internet, we will look at both of them. We will first look at the User Datagram Protocol (UDP).
UDP is a bare bones protocol, and doesn't really provide more services than what the underlying Network Layer, and Data Link Layer provide. UDP can detect errors in the UDP header information, similar to the error detecting provided by IPv4 at the Network Layer. Like IPv4, UDP is unreliable; that is datagrams may get dropped along the way, or datagrams may arrive out of order. UDP is said to be a connectionless protocol. Beyond, the unreliable communication concern, connectionless means that to UDP each datagram stands on its own, much like the thank you letter you sent to grandma for the cookies. To UDP multiple datagrams between two communicating hosts are all treated as separate communications. Another way to put this is that UDP datagrams are fire and forget to UDP. If the Application Layer wants reliable communications, then the Application needs to solve that problem. One service UDP does provide is breaking large messages from the Application Layer down into small datagrams that can traverse the Internet.
So, you are probably asking your self one, maybe two questions at this point. The first is when are we going to get a protocol that does provide reliable communications? The next question is, if there is a protocol that provides reliable communications, then why don't we just use that one all the time? Both questions are great questions, we will cover the question about reliable communications in a minute. First, we will tackle the why use UDP if there is a protocol that provides reliable communications. The answer is fairly simple ... overhead.
By not adding on services to what the layers lower in the TCP/IP Stack provide UDP avoids overhead on the sending and receiving end hosts. Providing services requires resources such as CPU, and RAM. By not adding on lots of services, UDP significantly reduces the resources required by the hosts. We will look at two specific examples of Application Layer protocols that specifically use UDP because it is connectionless, and has low overhead.
The other Transport Layer protocol that is commonly used on the Internet is Transport Control Protocol (TCP).
If you have been waiting for reliable connections, then wait no more, TCP is the Transport Layer Protocol for you.
In the TCP/IP Stack, TCP finally adds reliable communications ... well at least as long as the two communicating hosts are reachable (recall
In fact, reliable communications is the big difference between TCP, UDP, and the other networking protocols we have discussed.
TCP is considered a connection oriented protocol; where as UDP was connectionless.
TCP communications are like communicating via the phone: you establish a connection, which requires knowing the phone number (remote IP Address and port), but after the connection is made, you communicate through the connection.
As long as you don't hang up, you don't have to redial the number.
You saw evidence of TCP connections in the
netstat code listings above.
The ESTABLISHED state is the way that
netstat indicates that the TCP session is active, that a connection is established between the two processes on the two hosts.
A TCP connection comes with services that other protocols don't provide, namely TCP provides reliable communications. TCP detects datagrams that are lost, and the sender will resend datagrams that the receiver did not received. TCP also puts datagrams in the correct order. If a receiver receives TCP datagrams out of order, then the receiving host will use information in the TCP header to correctly order that datagrams. TCP also has detects errors in the TCP header.
So, what's the catch, why don't we use TCP for everything? Well, TCP is great, and many Application protocols do make use of the reliable connections that TCP provides, but at the cost of overhead. TCP can only provide those services at the cost of overhead for the sender and receiver. First off, the connection needs to be established before Application Layer messages can be sent. Before Application Layer data can be sent the two hosts have to first establish the connection, in TCP this process is called a "handshake". In the simplest form of the handshake, a three way back and forth process must complete to establish the connection. For example, if Alice wants to talk to Bob via TCP. Alice sends a TCP synchronize request to Bob with some data to synchronize Bob to Alice (Part 1 of Handshake). Bob then replies with a combined TCP acknowledgement, acknowledge the synchronizing data from Alice, and TCP synchronize data for Bob's side of the connection (Part 2 of Handshake). Upon receiving Bob's TCP acknowledgement, Alice sends a TCP acknowledgement back to Bob acknowledging his synchronizing data (Part 3 of Handshake). Once the handshake is complete, then Application Layer data can be sent across the connection.
There is also overhead in detecting, and recovering from dropped datagrams.
Throughout Alice and Bob's communication there is a series of TCP acknowledgements being sent to indicate what datagrams have been received.
If a certain amount of time goes by and Alice has not received an acknowledgement from Bob, then Alice assumes that the datagram was dropped, and then resends the datagram.
There are two details to highlight with that.
First, Alice has to keep a copy of all of the datagrams that she sent until Bob acknowledges them, and Bob is doing the same thing on his end; i.e. each host stores sent datagrams until the other host acknowledges the data.
Again, that is overhead.
Second, it took some amount of time for Alice to realize that Bob did not receive a datagram.
In practice that time is low, on the order of 100s of milliseconds to seconds, but when compared to nanoseconds (
10-9), that is a long time.
TCP also adds some other services that lower layer protocols do not. TCP provides flow control, flow control is a mechanism for the sending host to not overwhelm the resources of the receiving host. For example, flow control will limit the rate that data is sent to the receiver so as to not fill the receivers resources, remember maintaining the connection requires CPU, and RAM. TCP also provides congestion control, congestion control is a mechanism for the sending host to not overwhelm the network infrastructure. If Alice detects a number of datagrams not being received by Bob, then Alice will infer that some portion of the network infrastructure between Alice and Bob is overwhelmed, so Alice will reduce the rate in which she sends datagrams to Bob. Again, congestion control requires processing, CPU time, from the host. Both hosts are maintaining the connection state, managing flow control, and managing congestion control. So, the price of reliable communications is overhead; depending on the application that overhead may be worth it or not.
ncis restricted on USNA systems.
nk) is a very simple but powerful, USNA tool based on netcat (
nk can be used in either server mode, or client mode; i.e.
nk can listen for and accept an incoming phone call, or initiate a phone call.
In the client mode of netkitten, you give it an IP Address (or symbolic name that it will resolve for you via DNS) and a port number, and whatever you type into after pressing enter gets sent to the given address and port using TCP over IPv4.
In the server mode of netkitten. you give the
-l option (listen) and
nk then acts like a server, "listening" for a connection request.
Accepting the first one it receives, then echoing whatever gets sent to it to the screen, and taking whatever gets typed on the screen and sending it to the client whose connection request it accepted.
The diagram below illustrates what commands users on two hosts would have to give to make a TCP connection with netkitten.
C:>nk -l 42123
C:>nk 10.53.88.12 42123
The server command on Host 10.53.88.12 must be given first!
Otherwise, when the client calls there's nobody home!
netkitten with the
-u option (UDP) uses UDP instead of TCP.
Since this is connectionless, the server version accepts datagrams from any and all who send them, rather than making a connection with one client.
As another consequence, the UDP server doesn't exit just because one of the clients exits.
With netkitten, we as users can act like Application Layer programs.
Like most Application Layer programs, we require that the Transport Layer provide us with services, which means at a bare minimum that we decide whether we want UDP or TCP.
There are lots of interesting demos and activities we can do that demonstrate how TCP and UDP work and how they differ from one another; especially if we are using protocols that are text oriented, easy for humans to create and read.