TCP Header Length Analysis - Section 3

Introduction

The third field under close examination is the TCP Header length. There really isn't that much to say about the Header length other than to explain what it represents and how to interpret its values, but this alone is very important as you will soon see.

Let's take a quick look at the TCP Header length field, noting its position within the TCP structure:

You might also have seen the Header length represented as "Data offset" in other packet sniffers or applications, this is virtually the same as the Header length, only with a 'fancier' name.

Analysing the Header length

If you open any networking book that covers the TCP header, you will almost certainly find the following description for this particular field:

"An interger that specifies the length of the segment header measured in 32-bit multiples" (Internetworking with TCP/IP, Douglas E. Comer, p. 204, 1995). This description sounds impressive, but when you look at the packet, you're most likely to scratch your head thinking: what exactly did that mean?

Well, you can cease being confused because we are going to cover it step by step, giving answers to all possible questions you might have. If we don't cover your questions completely, well... there are always our forums to turn to!

Step 1 - What portion is the "Header length"?

Before we dive into analysing the meaning of the values used in this field, which by the way changes with every packet, we need to understand which portion on the packet is the "Header length".

Looking at the screen shot on the left, the light blue highlighted section shows us the section that's counted towards the Header length value. With this in mind, you can see that the total length of the light blue section (header length) is 28 bytes.

The Header length field is required because of the TCP Options field, which contains various options that might or might not be used. Logically, if no options are used then the header length will be much smaller.

If you take a look at our example, you will notice the 'TCP Options' is equal to 'yes', meaning there are options in this field that are used in this particular connection. We've expanded the section to show the TCP options used and these are 'Max Segment' and 'SACK OK'. These will be analysed in the pages which follow, at the present time though we are interested in whether the TCP options are used or not.

As the packet in our screenshot reaches the receiving end, the receiver will read the header length field and know exactly where the data portion starts.

This data will be carried to the layers above, while the TCP header will be stripped and disregarded. In this example, we have no data, which is normal since the packet is initiating a 3-way handshake (Flags, SYN=1), but we will cover that in more depth on the next page.

The main issue requiring our attention deals with the values used for the header length field and learning how to interpret them correctly.

Step 2 - Header Value Analysis

From the screen shot above, we can see our packet sniffer indicating that the field has a value of 7(hex) and this is interpreted as 28 bytes. To calculate this, you take the value of 7, multiply it by 32 and divide the result by 8: 7x32=224/8=28 bytes.

Do you recall the definition given at the beginning of this page? "An interger that specifies the length of the segment header measured in 32-bit multiples". This was the formal way of describing these calculations :)

The calculation given is automatically performed by our packet sniffer, which is quite thoughtful, wouldn't you agree? This can be considered, if you like, as an additional 'feature' found on most serious packet sniffers.

Below you will find another screen shot from our packet sniffer that shows a portion of the TCP header (left frame) containing the header length field. On the right frame, the packet sniffer shows the packet's contents in hex:

By selecting the Header length field on the left, the program automatically highlights the corresponding section and hex value on the right frame. According to the packet sniffer, the hex value '70' is the value for the header length field.

If you recall at the beginning of the page, we mentioned the header length field being 4 bits long. This means that when viewing the value in hex, we should only have one digit or character highlighted, but this isn't the case here because the packet sniffer has incorrectly highlighted the '7' and '0' together, giving us the impression that the field is 8 bits long!

Note: In hex, each character e.g '7' represents 4 bits. This means that on the right frame, only '7' should be highlighted, and not "70". Furthermore, if we were to convert '7' hex to binary, the result would be '0111' (notice the total amount of bits is equal to 4).

Summary

The 'Header length' field is very simple as it contains only a number that allows the receiving end to calculate the number of bytes in the TCP Header. At the same time, it is mandatory because without it there is no way the receiver will know where the data portion begins!

Logically, wherever the TCP header ends, the data begins - this is clear in the screen shots provided on this page. So, if you find yourself analysing packets and trying to figure out where the data starts, all you need to do is find the TCP Header, read the "Header length" value and you can find exactly where the data portion starts!

Next up are the TCP flags that most of us have come across when talking about the famous 3-way handshake and virtual connections TCP creates before exchanging data.

TCP Sequence & Acknowledgement Numbers - Section 2

Introduction

This page will closely examine the Sequence and Acknowledgement numbers. The very purpose of their existence is related directly to the fact that the Internet, and generally most networks, are packet switched (we will explain shortly) and because we nearly always send and receive data that is larger than the maximum transmission unit (a.k.a MTU - analysed on sections 5 and 6 ) which is 1500 on most networks.

Let's take a look at the fields we are about to analyse:

As you can see, the Sequence number proceeds the Acknowledgement number.

We are going to explain how these numbers increment and what they mean, how various operating systems handle them in a different manner and lastly, what way these numbers can become a security hazard for those who require a solid secure network.

TCP - Connection Oriented Protocol

The Sequence and Acknowledgement fields are two of the many features that help us classify TCP as a connection oriented protocol. As such, when data is sent through a TCP connection, they help the remote hosts keep track of the connection and ensure that no packet has been lost on the way to its destination.

TCP utilizes positive acknowledgments, timeouts and retransmissions to ensure error-free, sequenced delivery of user data. If the retransmission timer expires before an acknowledgment is received, data is retransmitted starting at the byte after the last acknowledged byte in the stream.

A further point worth mentioning is the fact that Sequence numbers are generated differently on each operating system. Using special algorithims (and sometimes weak ones), an operating system will generate these numbers, which are used to track the packets sent or received, and since both Sequence and Acknowledgement fields are 32bit, there are 2^32= 4,294,967,296 possibilities of generating a different number!

Initial Sequence Number (ISN)

When two hosts need to transfer data using the TCP transport protocol, a new connection is created. This involves the first host that wishes to initiate the connection, to generate what is called an Initial Sequence Number (ISN), which is basically the first sequence number that's contained in the Sequence field we are looking at. The ISN has always been the subject of security issues, as it seems to be a favourite way for hackers to 'hijack' TCP connections.

Believe it or not, hijacking a new TCP connection is something an experienced hacker can alarmingly achieve with very few attempts. The root of this security problem starts with the way the ISN is generated.

Every operating system uses its own algorithm to generate an ISN for every new connection, so all a hacker needs to do is figure out, or rather predict, which algorithm is used by the specific operating system, generate the next predicted sequence number and place it inside a packet that is sent to the other end. If the attacker is successful, the receiving end is fooled and thinks the packet is a valid one coming from the host that initiated the connection.

At the same time, the attacker will launch a flood attack to the host that initiated the TCP connection, keeping it busy so it won't send any packets to the remote host with which it tried to initiate the connection.

Here is a brief illustration of the above-mentioned attack:

As described, the hacker must find the ISN algorithm by sampling the Initial Sequence Numbers used in all new connections by Host A. Once this is complete and the hacker knows the algorithm and they are ready to initiate their attack:

Timing is critical for the hacker, so he sends his first fake packet to the Internet Banking Server while at the same time starts flooding Host A with garbage data in order to consume the host's bandwidth and resources. By doing so, Host A is unable to cope with the data it's receiving and will not send any packets to the Internet Banking Server.

The fake packet sent to the Internet Banking Server will contain valid headers, meaning it will seem like it originated from Host A's IP Address and will be sent to the correct port the Internet Banking Server is listening to.

There have been numerous reports published online that talk about the method each operating system uses to generate its ISN and how easy or difficult it is to predict. Do not be alarmed to discover that the Windows operating system's ISN algorithm is by far the easiest to predict!

Programs such as 'nmap' will actually test to see how difficult it can be to discover the ISN algorithm used in any operating system. In most cases, hackers will first sample TCP ISN's from the host victim, looking for patterns in the initial sequence numbers chosen by TCP implementations when responding to a connection request. Once a pattern is found it's only a matter of minutes for connections initiated by the host to be hijacked.

Example of Sequence and Acknowledgment Numbers

To help us understand how these newly introduced fields are used to track a connection's packets, an example is given below.

Before we proceed, we should note that you will come across the terms "ACK flag" or "SYN flag"; these terms should not be confused with the Sequence and Acknowledgment numbers as they are different fields within the TCP header. The screen shot below is to help you understand:

You can see the Sequence number and Acknowledgement number fields, followed by the TCP Flags to which we're referring.

The TCP Flags (light purple section) will be covered on the pages to come in much greater depth, but because we need to work with them now to help us examine how the Sequence and Acknowledgement numbers work, we are forced to analyse a small portion of them.

To keep things simple, remember that when talking about Sequence and Acknowledgement numbers we are referring to the blue section, while SYN and ACK flags refer to the light purple section.

The next diagram shows the establishment of a new connection to a web server - the Gateway Server. The first three packets are part of the 3-way handshake performed by TCP before any data is transferred between the two hosts, while the small screen shot under the diagram is captured by our packet sniffer:

To make sure we understand what is happening here, we will analyse the example step by step.

Step 1

Host A wishes to download a webpage from the Gateway Server. This requires a new connection between the two to be established so Host A sends a packet to the Gateway Server. This packet has the SYN flag set and also contains the ISN generated by Host A's operating system, that is 1293906975. Since Host A is initiating the connection and hasn't received a reply from the Gateway Server, the Acknowledgment number is set to zero (0).

In short, Host A is telling the Gateway Server the following: "I'd like to initiate a new connection with you. My Sequence number is 1293906975".

Step 2

The Gateway Server receives Host A's request and generates a reply containing its own generated ISN, that is 3455719727, and the next Sequence number it is expecting from Host A which is 1293906976. The Server also has the SYN & ACK flags set, acknowledging the previous packet it received and informing Host A of its own Sequence number.

In short, the Gateway Server is telling Host A the following: "I acknowledge your sequence number and expecting your next packet with sequence number 1293906976. My sequence number is 3455719727".

Step 3

Host A receives the reply and now knows Gateway's sequence number. It generates another packet to complete the connection. This packet has the ACK flag set and also contains the sequence number that it expects the Gateway Server to use next, that is 3455719728.

In short, Host A is telling the Gateway Server the following: "I acknowledge your last packet. This packet's sequence number is 1293906976, which is what you're expecting. I'll also be expecting the next packet you send me to have a sequence number of 3455719728".

Now, someone might be expecting the next packet to be sent from the Gateway Server, but this is not the case. You might recall that Host A initiated the connection because it wanted to download a web page from the Gateway Server. Since the 3-way TCP handshake has been completed, a virtual connection between the two now exists and the Gateway Server is ready to listen to Host A's request.

With this in mind, it's now time for Host A to ask for the webpage it wanted, which brings us to step number 4.

Step 4

In this step, Host A generates a packet with some data and sends it to the Gateway Server. The data tells the Gateway Server which webpage it would like sent.

Note that the sequence number of the segment in line 4 is the same as in line 3 because the ACK does not occupy sequence number space.

So keep in mind that any packets generated, which are simply acknowledgments (in other words, have only the ACK flag set and contain no data) to previously received packets, never increment the sequence number.

Last Notes

There are other important roles that the Sequence and Acknowledgement numbers have during the communication of two hosts. Because segments (or packets) travel in IP datagrams, they can be lost or delivered out of order, so the receiver uses the sequence numbers to reorder the segments. The receiver collects the data from arriving segments and reconstructs an exact copy of the stream being sent.

If we have a closer look at the diagram above, we notice that the TCP Acknowledgement number specifies the sequence number of the next segment expected by the receiver. Simply scroll back to Step 2 and you will see what I mean.

Summary

This page has introduced the Sequence and Acknowledgement fields within the TCP header. We have seen how hackers hijack connections by discovering the algorithms used to produce the ISNs and we examined step by step the way Sequence and Acknowledgement numbers increase.

The next page examines the TCP header length field, so take a quick break if it's required and let's continue!

TCP Source & Destination Port Number - Section 1

Introduction

This section contains one of the most well-known fields in the TCP header, the Source and Destination port numbers. These fields are used to specify the application or services offered on local or remote hosts. We explain the importance and functionality of the TCP source and destination ports, alongside with plenty of examples.

You will come to understand how important ports are and how they can be used to gain information on remote systems that have been targetted for attacks. We will cover basic and advanced port communications using detailed examples and colourful diagrams, but for now, we will start with some basics to help break down the topic and allow us to smoothly progress in to more advanced and complex information.

When a host needs to generate a request or send data, it requires some information:

1) IP Address of the desired host to which it wants to send the data or request.

2) Port number to which the data or request should be sent to on the remote host. In the case of a request, it allows the sender to specify the service it is intending to use. We will analyse this soon.

1) The IP Address is used to uniquely identify the desired host we need to contact. This information is not shown in the above packet because it exists in the IP header section located right above the TCP header we are analysing. If we were to expand the IP header, we would (certainly) find the source and destination IP Address fields in there.

2) The 2nd important aspect, the port number, allows us to identify the service or application our data or request must be sent to, as we have previously stated. When a host, whether it be a simple computer or a dedicated server, offers various services such as http, ftp, telnet, all clients connecting to it must use a port number to choose which particular service they would like to use.

The best way to understand the concept is through examples and there are plenty of them below, so let's take a look at a few, starting from a simple one and then moving towards something slightly more complicated.

Time To Dive Deeper!

Let's consider your web browser for a moment.

When you send a http request to download a webpage, it must be sent to the correct web server in order for it to receive it, process it and allow you to view the page you want. This is achieved by obtaining the correct IP address via DNS resolution and sending the request to the correct port number at the remote machine (web server). The port value, in the case of an http request, is usually 80.

Once your request arrives at the web server, it will check that the packet is indeed for itself. This is done by observing the destination IP Address of the newly received packet. Keep in mind that this particular step is a function of the Network layer.

Once it verifies that the packet is in fact for the local machine, it will process the packet and see that the destination port number is equal to 80. It then realises it should send the data (or request) to the http deamon that's waiting in the background to serve clients:

Using this neat method we are able to use the rest of the services offered by the server. So, to use the FTP service, our workstation generates a packet that is directed to the server's IP address, that is 200.0.0.1, but this time with a destination port of 21.

The diagram that follows illustrates this process:

By now you should understand the purpose of the destination port and how it allows us to select the services we require from hosts that offer them.

For those who noticed, our captured packet at the beginning of this page also shows the existence of another port, the source port, which we are going to take a look at below.

Understanding the Source Port

The source port serves analogues to the destination port, but is used by the sending host to help keep track of new incoming connections and existing data streams.

As most of you are well aware, in TCP/UDP data communications, a host will always provide a destination and source port number. We have already analysed the destination port, and how it allows the host to select the service it requires. The source port is provided to the remote machine, in the case of our example, this is the Internet Server, in order for it to reply to the correct session initiated by the other side.

This is achieved by reversing the destination and source ports. When the host (in our example, Host A) receives this packet, it will identify the packet as a reply to the previous packet it sent:

As Host A receives the Internet Server's reply, the Transport layer will notice the reversed ports and recognise it as a response to the previous packet it sent (the one with the green arrow).

The Transport and Session layers keep track of all new connections, established connections and connections that are in the process of being torn down, which explains how Host A remembers that it's expecting a reply from the Internet Server.

Of course the captured packet that's displayed at the beginning of the page shows different port numbers than the ones in these diagrams. In that particular case, the workstation sends a request to its local http proxy server that runs on port 8080, using port 3025 as its source port.

We should also note that TCP uses a few more mechanisms to accurately keep track of these connections. The pages to follow will analyse them as well, so don't worry about missing out on any information, just grab some brain food (hhmmm chocolate...), sit back, relax and continue reading!

The TCP Header/Segment

Introduction

This article shows the TCP Header and Segment. We explain where the TCP Header and Segment are located in an Ethernet frame and also briefly view the available options in the TCP Header. Our easy-to-understand detailed diagrams help ensure all information provided is easily understood.

So buckle up and get ready. It's all really simple, you just need to clear your mind and try to see things in the simplest form and you will discover how easy and friendly TCP really is. You can only feel comfortable with something once you get to know it.

TCP Header and TCP Segment

If we wanted to be more accurate with the terms we use, then perhaps we would title this page as "Analysing A TCP Segment". Why? Well, that's what it's called in the networking world so we need to know it by the correct term.

This of course leads us to another new definition, a TCP segment:

"The unit of transfer between the TCP software on to machines is called a TCP segment."

If your expression has transformed itself to resemble a confused person, then don't worry, just keep reading...

Understanding this term is easier than you thought when reading the definition, just take a good look at the diagram below:

Now you see that a TCP segment is basically the TCP header plus the data that's right behind it and, of course, the data belongs to the upper layers (5,6,7).

The data contents could be part of a file transfer, or the response from a http request, the fact is that we really are not interested in the data's contents, but only in the fact that it's part of the TCP segment.

The screen shot below was taken from my packet sniffer, and it shows the DATA portion belonging to the TCP Header:

If you tried to capture a similar packet from any packet sniffer, it is more likely to display the Data portion within the TCP header, just as the screen shot on the left.

So the question is whether a TCP header and a TCP segment are basically the same thing.

Even though it might seem they are, in most cases, when referring to the TCP header, we are talking about the header without the data, whereas a TCP segment includes the data.

Getting Ready To Analyse The TCP Header

We are now ready to begin examining the structure of the TCP header. However, be sure to keep in mind that the 'TCP Header' is the same thing as a 'TCP Segment', meaning it's the TCP header information plus the Data, just as the diagrams above show.

The last screen shot certainly gives out a fair bit of information, but there is still much that hasn't been revealed, not to mention nothing's really been analysed as yet :)

Quick Overview Of TCP

 

Introduction

As previously mentioned on a number of occasions, TCP is one of the two protocols that lives at the Transport layer and is used to carry data from one host to another. What makes TCP so popular is the way it works when sending and receiving data. Unlike UDP, TCP will check for errors in every packet it receives in an endless struggle to avoid data corruption.

Some common protocols that use TCP are: FTP, Telnet, HTTP, HTTPS, DNS, SMTP and POP3. Let's have a closer look at the main characteristics of this wonderful protocol.

When people refer to "TCP/IP" remember that they are talking about a suite of protocols and not just one protocol, like most people think. TCP/IP is not one protocol. Please see the Protocols section for more information.

Main Features

Here are the main features of the TCP that we are going to analyse:

• Reliable Transport
• Connection-Oriented
• Flow Control
• Windowing
• Acknowledgements
• More overhead

Reliable Transport

It's a reliable transport because of the different techniques it uses to ensure that the data received is error free. TCP is a robust protocol used for file transfers where data error is not an option. When you decide to download a 50MB file from a website, you wouldn't want to find out after the download is complete that the file has an error! Even though, in reality, this does happen, it just goes to show that you can't always be perfect with certain things.

This picture shows the TCP header within an ethernet II frame. Right below this you will find our second diagram that zooms into to the TCP header, displaying the field the protocol contains:

  The diagram on the left shows the individual breakdown of each field within the TCP header along with its length in bits.

Remember that 8 bits equal to 1 byte.

The most popular fields within the TCP header are the Source Port, Destination Port and Code bits. These Code bits are also known as 'flags'.

The rest of the fields help make sure all TCP segments make it to their destination and are reassembled in the correct order, while at the same time providing an error free mechanism should a few segments go missing and never reach their destination.

Keep in mind that in the pages to follow we will have a detailed look into each available field, for now we are just providing an overview of them.

Connection Oriented

What this basically means is that a connection is established between the two hosts or rather, the two computers, before any data is transferred. When the term "connection is established" is used, this means that both computers know about each other and have agreed on the exchange of data. This is also where the famous 3-way handshake happens. You will find the SYN and ACK bits in the Code bits field which are used to perform the 3-way handshake. Thanks to the 3-way handshake, TCP is connection oriented.

The following diagram explains the procedure of the 3-way handshake:

STEP 1: Host A sends the initial packet to Host B. This packet has the "SYN" bit enabled. Host B receives the packet and sees the "SYN" bit which has a value of "1" (in binary, this means ON) so it knows that Host A is trying to establish a connection with it.

STEP 2: Assuming Host B has enough resources, it sends a packet back to Host A and with the "SYN and ACK" bits enabled (1). The SYN that Host B sends, at this step, means 'I want to synchronise with you' and the ACK means 'I acknowledge your previous SYN request'.

STEP 3: So... after all that, Host A sends another packet to Host B and with the "ACK" bit set (1), it effectively tells Host B 'Yes, I acknowledge your previous request'.

Once the 3-way handshake is complete, the connection is established (virtual circuit) and the data transfer begins.

Flow Control

Flow control is used to control the data flow between the connection. If for any reason one of the two hosts are unable to keep up with the data transfer, it is able to send special signals to the other end, asking it to either stop or slow down so it can keep up.

For example, if Host B was a webserver from which people could download games, then obviously Host A is not going to be the only computer downloading from this webserver, so Host B must regulate the data flow to every computer downloading from it. This means it might turn to Host A and tell it to wait for a while until more resources are available because it has another 20 users trying to download at the same time.

Below is a diagram that illustrates a simple flow control session between two hosts. At this point, we only need to understand the concept of flow control:

Generally speaking, when a machine receives a flood of data too quickly for it to process, it stores it in a memory section called a buffer. This buffering action solves the problem only if the data bursts are small and don't last long.

However, if the data burst continues it will eventually exhaust the memory of the receiving end and that will result in the arriving data being discarded. So in this situation the receiving end will simply issue a "Not ready" or "Stop" indicator to the sender, or source of the flood. After the receiver processes the data it has in its memory, it sends out a "Ready" or "Go" transport indicator and the sending machine receives the "Go" indicator and resumes its transmission.

Windowing

Data throughput, or transfer efficiency, would be low if the transmitting machine had to wait for an acknowledgment after sending each packet of data (the correct term is segment as we will see on the next page). Because there is time available after the sender transmits the data segment and before it finishes processing acknowledgments from the receiving machine, the sender uses the break to transmit more data. If we wanted to briefly define Windowing we could do so by stating that it is the number of data segments the transmitting machine is allowed to send without receiving an acknowledgment for them.

Windowing controls how much information is transferred from one end to the other. While some protocols quantify information by observing the number of packets, TCP/IP measures it by counting the number of bytes.

Let's explain what is happening in the above diagram.

Host B is sending data to Host A, using a window size equal to one. This means that Host B is expecting an "ACK" for each data segment it sends to Host A. Once the first data segment is sent, Host A receives it and sends an "ACK 2" to Host B. You might be wondering why "ACK 2" and not just "ACK"?

The "ACK 2" is translated by Host B to say: 'I acknowledge (ACK) the packet you just sent me and I am ready to receive the second (2) segment'. So Host B gets the second data segment ready and sends it off to Host A, expecting an "ACK 3" response from Host A so it can send the third data segment for which, as the picture shows, it receives the "ACK 3".

However, if it received an "ACK 2" again, this would mean something went wrong with the previous transmission and Host B will retransmit the lost segment. We will see how this works in the Acknowledgments section later on. Let's now try a different Window size to get a better understanding.. let's say 3!

Keep in mind the way the "ACK's" work, otherwise you might find the following example a bit confusing. If you can't understand it, read the previous example again where the Window size was equal to one.

In the above example, we have a window size equal to 3, which means that Host B can send 3 data segments to Host A before expecting an "ACK" back. Host B sends the first 3 segments (Send 1, Send 2 and Send 3), Host A receives them all in good condition and then sends the "ACK 4" to Host B. This means that Host A acknowledged the 3 data segments Host B sent and awaits the next data segments which, in this case, would be 4, 5 and 6.

Acknowledgments

Reliable data delivery ensures the integrity of a stream of data sent from one machine to the other through a fully functional data link. This guarantees the data won't be duplicated or lost. The method that achieves this is known as positive acknowledgment with retransmission. This technique requires a receiving machine to communicate with the transmitting source by sending an acknowledgment message back to the sender when it receives data. The sender documents each segment it sends and waits for this acknowledgment before sending the next segment. When it sends a segment, the transmitting machine starts a timer and retransmits if it expires before an acknowledgment is returned from the receiving end.

This figure shows how the Acknowledgments work. If you examine the diagram closely you will see the window size of this transfer which is equal to 3. At first, Host B sends 3 data segments to Host A and they are received in perfect condition so, based on what we learned, Host A sends an "ACK 4" acknowledging the 3 data segments and requesting the next 3 data segments which will be 4, 5, 6. As a result, Host B sends data segments 4, 5, 6 but 5 gets lost somewhere along the way and Host A doesn't receive it so, after a bit of waiting, it realises that 5 got lost and sends an "ACK 5" to Host B, indicating that it would like data segment 5 retransmitted. Now you see why this method is called "positive acknowledgment with retransmission".

At this point Host B sends data segment 5 and waits for Host A to send an "ACK" so it can continue sending the rest of the data. Host A receives the 5th data segment and sends "ACK 7" which means 'I received the previous data segment, now please send me the next 3'. The next step is not shown on the diagram but it would be Host B sending data segments 7, 8 and 9.

More Overhead

As you can see, there is quite a neat mechanism under the TCP hood that enables data to be transferred error free. All the features the protocol supports come at a price, and this is the overhead associated with TCP.

When we talk about overhead, we are referring to all the different fields contained within the TCP header and error checking that takes place to ensure no portion of the data is corrupt. While for most this is a fair trade off, some people simply can't spare the extra processing power, bandwidth and increased time the TCP transactions require, for this reason we have the alternative UDP protocol, which you can read about in the UDP protocol section.

At this point our quick overview of the TCP has reached its conclusion. From the next page onwards, we start to dive in deeper, so take a deep breath and jump right into it!

TCP, A Transport Protocol

Introduction

Understanding how each protocol fits into the OSI Model is essential for any network engineer. This page analyses how TCP is classified as a 'transport protocol' and gives you an insight into what to expect from the protocol.

Fitting TCP into the OSI Model

As most of you are well aware, every protocol has its place within the OSI Model. The OSI Model is an indication of the complexity and intelligence of the protocol. As a general rule, the higher you move up the OSI Model, the more intelligent protocols become. The positioning of the layer also reflects how CPU entensive they are, whereas the lower layers of the OSI Model are quite the opposite, that is, less CPU intensive and less intelligent.

TCP is placed at the 4th layer of the OSI Model, which is also known as the transport layer. If you have read through the OSI model pages, you will recall that the transport layer is responsible for establishing sessions, data transfer and tearing down virtual connections.
With this in mind, you would expect any protocol that's placed in the transport layer to implement certain features and characteristics that would allow it to support the functionality the layer provides.
So as we analyse TCP, you will surely agree that it fits right into the transport layer.

The diagram below shows you where the TCP header is located within a frame that's been generated by a computer and sent to the network. If you rotate it 90 degrees to your left, you would get something similar to the previous diagram. This of course is because each layer appends its own information, or header if you like:

The frame is made up of six 3d blocks so you can see which piece is added by every OSI layer. You can see that the TCP Header containing all the options the protocol supports, is placed right after the IP Header (Layer 3), and before the data section that contains upper layer information (Layers 5,6,7).

Note: For those who are wondering about the presence of the FCS block at the end, it contains a special checksum that is placed by the datalink layer in order to allow the receiving host to detect if the current frame has been corrupt during transit.

Please refer to the Ethernet II Frame page for more information.

Where and why would we use the TCP?

TCP is used in almost every type of network. As a protocol, it is not restricted to any type of network topology, whether it be a local area network (LAN) or wide area network (WAN). Being a transport protocol, we call it a transport protocol because it's located in the transport layer of the OSI model its primary job is to get data from one location to another, regardless of the physical network and location.

As most of you already know, there are two types of transport protocols, TCP being one of them and UDP (User Datagram Protocol) being the other. The difference between these two transport protocols is that TCP offers an extremely reliable and robust method of transferring data, ensuring that the data being transferred does not become corrupt in any way. UDP, on the other hand, offers a non reliable way of transferring data without being able to guarantee the data has arrived to its destination or its integrity when it does arrive.

The Concept of a Transport Protocol

As we mentioned, TCP is a transport protocol and this means it is used to transfer data of other protocols. At first, this might sound weird or confusing but this is exactly why it was designed, adding substantial functionality to the protocols it carries.

The diagram below is the simplest way to show the concept of a 'transport' protocol:

In the pages to follow, we will have a closer look at how TCP manages to provide its reliable data transfer method and make sure packets get to their destination without errors. This whole process is the work of many 'subsystems' within the TCP that work together to provide the reliability that TCP gives us.

Before we dive in deeper though, let's have a quick overall view of the protocol. If you're not interested in too much technical detail, then the next page is for you! For those looking for an in-depth analysis, you should read the quick-overview page to give you an idea on what we will be analysing soon.

File system trong *nix

1. File và inode

Một file là một khối dữ liệu được lưu trữ liên tục hoặc không liên tục (tình trạng dữ liệu bị phân mảnh) trên thiết bị lưu trữ như ổ cứng, ổ mềm, ổ flash,… Người dùng bình thường sẽ nhận dạng một file dựa trên tên của nó (file name).

Mỗi file được liên kết với một inode mà chứa các thuộc tính của file đó như là định dạng (text, binary,…), kích thước, ngày khởi tạo, vị trí trên thiết bị lưu trữ, chủ sở hữu, quyền truy cập,… Thông tin về file mà inode nắm giữ thường được gọi là metadata, đặc biệt inode không chứa tên file và nội dung thật sự của file.

Mỗi inode được xác định bởi một con số (inode number) , có một bảng chỉ mục (inode table) gồm inode number – vị trí inode trên thiết bị lưu trữ. Với inode number có được kernel sẽ tìm trong bảng chỉ mục này và truy cập tới nội dung của inode, bao gồm con trỏ dữ liệu từ đó truy cập tới nội dung của file mà liên kết với inode đó.

Khi một file được tạo, nó được gán một file name + một inode number là số nguyên duy nhất trong một file system. Các file name và inode number tương ứng được lưu trữ thành các mục (entry) trong thư mục, tức là thư mục thực ra chỉ là danh sách các liên kết giữa file name và inode number mà thôi.

Khi người dùng hoặc chương trình sử dụng file name để tham khảo tới một file, hệ điều hành sẽ sử dụng tên này để tìm kiếm inode tương ứng bằng cách tra cứu trong inode table rồi từ đó biết được thông tin và vị trí của file trên thiết bị lưu trữ để phục vụ cho các thao tác về sau (như chỉnh sửa nội dung của file, cung cấp thuộc tính của file,…).

Sử dụng lệnh ls -i để biết inode number của 1 file, và ls -l để biết metadata của file chứa trong inode.

Trên nhiều kiểu file system thì số lượng các inode có thể sử dụng được cố định tại thời điểm khởi tạo file system, dẫn tới việc giới hạn số lượng file mà hệ thống file có thể nắm giữ, quản lý.

2. Directory

Directory (hay folder – thư mục) trong *nix là một loại file đặc biệt, chứa danh sách các liên kết giữa tên đối tượng (file, folder, soft/hard link…) và inode number tương ứng với đối tượng đó.

Current Directory
Hay working directory (thư mục hiện hành) là thư mục mà hiện tại người dùng, chương trình đang “đứng”, tham khảo, làm việc tại đó.

Mọi user luôn luôn đang làm việc bên trong một thư mục nào đó. Chính xác hơn thì mỗi tiến trình (process) có một WK được liên kết linh động với nó. Trong Windows thì process gọi hàm GetCurrentDirectory để xác định vị trí của WK và gọi hàm SetCurrentDirectory để thay đổi WK.

Khi user hoặc process chỉ định một file mà đơn giản chỉ sử dụng tên file hoặc đường dẫn tương đối (relative path) của file thì việc tìm kiếm tới file này bắt đầu từ WK. Ví dụ trong Linux, khi mới mở Shell CLI lên để gõ lệnh thường thì ta đang đứng ở thư mục có đường dẫn tuyệt đối là
/home/user_name thì thư mục user_name là WK. Khi gõ vào

# rm foo.txt

thì lệnh này sẽ thực hiện việc xóa file foo.txt trong thư mục chủ của người dùng.

Thường có 2 cách để thể xác định WK.

Một là nhìn vào dấu nhắc lệnh (command prompt). Với bash thì dấu nhắc lệnh chứa tên người dùng,  máy tính và thư mục hiện hành, ví dụ:

[uit@localhost bluesky]#

thì uit là user name, localhost là computer name và bluesky là working directory, # chỉ ra rằng đây là user root.

Cách thứ hai là sử dụng lệnh pwd (present working directory), lệnh này không có tùy chọn hay đối số để hiện đường dẫn đầy đủ của thư mục hiện hành.

WK thường được biểu thị bởi 1 dấu chấm “.” , còn 2 dấu chấm liên tiếp “..” thay cho thư mục cha của WK. Ta sẽ luôn thấy 2 mục bị ẩn này tồn tại trong mọi thư mục trên *nix bằng cách sử dụng lệnh ls -a

Directory Tree
Gọi là cây thư mục, là hệ thống các thư mục được phân cấp và trong đó có duy nhất một thư mục được gọi là thư mục cha và tất cả các mức độ thư mục con của nó. Bất kỳ thư mục nào cũng có thể là điểm bắt đầu cho 1 cây thư mục của riêng nó nếu nó chứa ít nhất 1 thư mục con.

Hầu hết các hệ điều hành ngày nay đều sử dụng cấu trúc cây thư mục cho việc tổ chức file. Với các hệ *nix chỉ có duy nhất một thư mục gốc (root directory, ký hiệu là /) mà từ đó các cây thư mục khác sinh ra từ đây. Con các hệ Microsoft Windows thì có nhiều thư mục gốc độc lập với nhau có các tên như C: , D: , E: ,…

Lệnh du (disk usage) trong Linux là một tiện ích thu thập thông tin về các cây thư mục, bao gồm tổng không gian đĩa mà một cây chiếm dụng, tên và kích thước mỗi nhánh hoặc file trong cây đó.

3. Hard Link

Hard link (HL) là tên gọi khác cho một file đang tồn tại trên file system.

Một file có thể có nhiều HL và mỗi HL cũng có thể có nhiều HL cho nó. Tuy nhiên, không thể tạo cho HL cho thư mục và cũng không thể tạo ra HL cho một file không nằm cùng phân vùng với HL. Ví dụ, không thể tạo HL trên phân vùng A cho một file nằm trên phân vùng B.

Hệ điều hành không phân biệt giữa file name ban đầu của file với các HL được tạo ra sau này cho file đó. Cả file name và các HL này đều trỏ tới cùng một inode, và vì mỗi inode có một số inode number là duy nhất trong một file system nên HL không thể làm việc chéo qua các phân vùng khác nhau.

Sử dụng lệnh ln để tạo HL. Ví dụ dưới đây sẽ tạo một HL có tên hlink1 cho một file có tên file1, cả 2 file này đều nằm trong cùng thư mục hiện hành.

$ ln file1 hlink1

File name ban đầu và tất cả các HL tới file đều chia sẻ chung inode, có thể thấy rõ điều này bằng cách sử dụng lệnh ls –i. Câu lệnh dưới đây sẽ cho thấy inode number của file1 và hlink1 là giống nhau:

$ ls -i file1 hlink1

Số lượng các HL cho 1 file được thể hiện trong cột thứ 2 trong output của lệnh ls –l. Con số này là tổng của filename ban đầu và HL và số này giống nhau cho target file và mỗi HL, ví dụ:

$ ls -l file1 hlink1

Sử dụng lệnh sau để tìm các file có nhiều hơn một HL

$ find -type f -links +1

Thử chỉnh sửa nội dung của target file và lưu lại. Sau đó mở HL của target file đó lên sẽ những thay đổi được giữ nguyên.

Lệnh rm thực sự làm gì?
Khi sử dụng lệnh rm để xóa file thì thực chất là làm giảm đi một HL. Khi số lượng HL giảm còn 0 thì không thể truy cập tới nội dung của file được nữa (mặc dù nội dung đó vẫn tồn tại trên thiết bị lưu trữ) vì hệ điều hành không còn cách nào để tham khảo tới file này. Dữ liệu của file chỉ thực sự bị mất khi vị trí của nó bị ghi đè bởi các file mới. Điều này giải thích tại sao ta vẫn có thể khôi phục dữ liệu vừa bị xóa và không có dữ liệu nào được tạo ra trên vị trí của dữ liệu cũ.

HL cũng như shortcut trong Windows là cho phép truy cập tới file, chương trình, script từ một vị trí khác thuận tiện hơn.

4. Symbolic link

SL thì hơi khác chút so với HL đó là có thể tạo SL cho 1 thư mục cũng như là tạo SL các file và thư mục trên các phân vùng khác. Tuy nhiên, hạn chế của SL so với HL là khi xóa target file thì SL không có tác dụng nữa. Sử dụng cú pháp lệnh sau để tạo SL

$ ln -s target_file SL_name

End.