Understanding the TCP/IP protocol suite
Nassos Katsaounis, of Server Density.
Published on the 17th February, 2017.
Transmission Control Protocol/Internet Protocol (TCP/IP protocol suite) is a set of rules and protocols enabling data communication between computers. Developed in the mid 1970’s and widely adopted in the early 1980’s, it has been the de facto standard of computer networking for over 35 years.
TCP/IP provides the necessary framework for two points connected through a network to exchange information. In the Protocol Stack, the set of protocols used in a communications network, TCP/IP plays a particularly important role in two specific layers:
- In the Transport Layer, where correct delivery of data is ensured
- and in the Network Layer, where the correct recipient is located
Transport Layer (“How”)
Transmission Control Protocol is responsible for establishing reliable data exchange between applications. This ensures that data is not lost or misinterpreted along the way: TCP confirms that the message sent is the message actually received.
TCP undertakes the task to open a channel of communication between the two computers. It breaks the data into small units of information (“segments” or “packets”) as required, confirms correct delivery and reassembles them at the destination.
Network Layer (“Where”)
The other, equally important task is to send the data to the correct recipient. This is the responsibility of Internet Protocol, that determines how data will find its intended destination through interconnected networks. In other words, IP dictates the roadmap that data will have to follow. IP ensures that all packets include the information necessary for each node to be able to forward them to the next.
How it works
TCP is activated with every network request/response. For example, in an HTTP request, TCP takes over as soon as the browser knows where the request should be routed, i.e. after DNS resolution has been completed. Based on the socket provided (combination of IP address and server port), the request will reach the target computer and application through the network. The necessary communication channel will open up and data will be broken down to appropriately sized packets. Then, they will be sent over to the server. While the server handles the request and prepares the response accordingly, TCP makes sure that this particular connection channel remains open until the response reaches the source of the request successfully.
While moving data around, TCP/IP protocols annotate segments with extra information (headers) in order to be able to perform all the above tasks successfully. Headers include information regarding the segment sequence number, a number (checksum) to allow confirmation of data validity and information about sender and recipient.
This added information allows data to be segmented and transmitted as efficiently as possible, making sure it is correctly restructured at the destination, without worrying about structure during transportation. But it also plays an important role in the Three-Way Handshake.
Unlike User Datagram Protocol (UDP), reliability is a top priority for TCP/IP. UDP serves as an alternative to TCP for different types of communication services where there is no time or need for confirmation that the correct message was successfully received by the intended party. An example of a case like that is a voice call over IP.
But in most cases, such confirmation is absolutely necessary.
To ensure reliability in communications, TCP establishes a verified connection between the client and the server computer before actual data is transmitted. This is done through the Three-Way Handshake using three segments (hence the “three-way”).
How it works
- To initiate the process, the client sends a SYN segment to the server. SYN stands for Synchronization, and it means that the client requests that the server synchronizes with the sequence numbers that the client will use (new sequence numbers are generated with every new transaction).
- Upon receiving the request, the server responds with a similar message. First, it acknowledges (ACK) the request by confirming the Sequence Numbers sent by the client. And second, it also requests synchronization (SYN) of the client’s Sequence Numbers with its own.
- The final step comes from the client again, that acknowledges (ACK) the Sequence Numbers sent by the server. Transmission is ready to begin.
Click here to read more about the Three-Way Handshake.
The Traceroute utility
TCP/IP comes with utilities that assist admins diagnose and understand problems in network performance. The most well-known of these utilities is probably Ping, that allows you to test whether your computer can open a communication channel with a certain host to exchange data, and how fast.
In a way, Traceroute takes the Ping utility a few steps further. Data transmitted through networks almost always goes through intermediate nodes before reaching its destination. Traceroute is especially designed to identify all the routers or other network devices (“hops”) between the source and the destination and measure the rate at which data is exchanged with each router. So the purpose of Traceroute is twofold:
- To determine the path to a destination, complete with intermediate stops
- To identify possible delay points in this path
Using specific switches, the Traceroute command can be configured with regard to maximum hops, timeouts for each reply, hostname resolution and other options.
How it works
Traceroute takes advantage of the “TTL” field found in all packet headers sent around the internet. TTL stands for Time To Live and indicates the maximum number of hops that a packet is allowed to travel to before being discarded. The purpose of this is similar to a timeout: if a packet is moved around without finding its destination it is wise to discard it after a reasonable number of nodes visited. In order for TTL value to work, all routers are configured to reduce a packet’s TTL value by one before forwarding it to the next node. When a packet is discarded, the router sends a special message all the way back to the source, so the sending host knows where a packet was discarded from.
Traceroute exploits this behaviour by sending packets to a destination and making sure that every time a packet reaches a new intermediate hop it is actually discarded so that a message is sent back containing the intermediate router’s information. Then the packet is send again with TTL increased by 1 so that it won’t be discarded from hops that have already been visited before. The process is repeated until the packet reaches its destination host. There, it is designed to be “unusable” rather than discarded, i.e. the final hop also sends a message, albeit a different one, so that Traceroute knows it is time to stop resending packets.
Here’s how it all works:
- Traceroute creates a packet for the target server with a TTL value of 1, indicating a likely to be unused port number (such port ranges are well-known). This ensures that, as soon as the packet reaches its intended destination a special response is returned, stating that the indicated port is unreachable.
- The packet reaches the first intermediary where its TTL value is reduced by 1, so now TTL is equal to 0 and the packet is discarded. So the first router along the way returns a “packet discarded” response back to the client (“TTL Time Exceeded”).
- Now the client actually knows the first stop in the path. So the next packet created has a TTL value of 2, so that it is not discarded in the first router.
- Each time a packet is discarded, a message arrives at the client providing information regarding its location and indicating data transfer times.
- Each time a packet is created and sent from Traceroute it has a TTL increased by 1
- Finally, the client knows that the server has been reached (and stops sending packets) when it receives a different message from a hop, saying that the port intended is unreachable (“Destination/Port unreachable”).
So Traceroute can prove very useful when a certain host seems unreachable or when you notice an unexpected delay in a data transfer. Traceroute can reveal where the bottleneck might be and help you decide on corrective or alternative action.
In general, to analyze results, we look at the round trip times recorded by Traceroute. For each hop, Traceroute actually sends 3 packets (with different port numbers so that they are completely distinct) so that the sample is more reliable.
Here are a few rules of thumb when reading these results:
- If times are generally consistent there are little conclusions to be derived.
- Times over or close to 150 ms may start to raise some eyebrows especially when accessing same-continent routers.
- Higher numbers towards the first one or two hops is an indicator that a problem might exist in the local network.
- When times increase suddenly but steadily after a specific hop it might indicate a bottleneck at the specific hop.
- Inconsistent “spikes” may merely indicate that the specific router set lower priority to the specific packet.
- Timeouts may indicate various issues or normal situations. For example, some servers are configured to ignore ICMP packets (Internet Control Message Protocol used by Windows when Traceroute is run), but still transfer the request to the next hop.
- Correctly interpreting the results of Traceroute may prove to be a rather complicated procedure. In fact, describing the methodology could be the subject of a separate article altogether. Click here to read such a comprehensive analysis.
What about you? What is your experience with Traceroute?