Network Uptime

Let's illustrate using the telephone call analogy. Once you place a call, the party you are calling hears the phone ringing, picks up the hand set and says hello (SYN). You then say hello (SYN ACK), the party you are calling then greets you (ACK), and the conversation starts.

Each time you or the party speaks, the other side periodically responds at times with a verbal queue such as "yes" or some sort of acknowledgement signaling that he or she understood what was said thus far (ACK). If you are going too fast, the party will ask you to slow down (window) or restate your information (retransmission).

Once the conversation ends, you say your good-bye (FIN), the other party says their good-bye (FIN ACK), and you hear the phone hang up (ACK).

TCP works in the same manner as a telephone call in order to keep the data flow reliable. However, the drawback is some overhead needed for acknowledgements and control. Instead of using telephone numbers to communicate between people, TCP uses port numbers to communicate between services running workstations.

There have been many RFCs written about this protocol, the most basic are RFC 793, 761, and 675.

This tutorial spans 88 frames, however not all the frames will have commentary. Some FTP commands will be shown but the underlying TCP functionality, windowing and sequencing will be our main focus.

The first frame shows the FTP client sending a control frame to the FTP server. The control connection port number is 1183, making the data connection port number 21. The port number 1184 (FTP command) is calculated in the FTP header. You will understand where these port numbers fit in the whole scheme of things as you follow this trace.

Frame Source Address Dest. Address  Summary
    1 [192.168.10.4] [192.168.10.5] FTP: C PORT=1183 
                                    PORT 192,168,10,4,4,160

Did you catch the port command string in the FTP header?

[PORT 192,168,10,4,4,160]

This will define the TCP file transfer connection port number. The first four comma-delimited numbers represent the IP address. This is where it gets interesting: The last 2 numbers (4, 160) are numbers inserted in a simple equation calculating the data connection port number that will be used to transfer the requested file.

4 x 256 + 160 = 1184. Watch for port 1184 in the next few frames.

In frame 2, the FTP server responds back with a Port Command Okay in the FTP header and a source port of 21 in the TCP header. The RFC standard port number for FTP is 21.

Frame Source Address Dest. Address  Summary
    2 [192.168.10.5] [192.168.10.4] FTP: R PORT=21   
                                    200 Port command okay.

Now the FTP client sends a file retrieve message in the FTP header to the FTP server - "RETR ftpfile.txt".

Frame Source Address Dest. Address  Summary
    3 [192.168.10.4] [192.168.10.5] FTP: C PORT=1183   
                                    RETR ftpfile.txt

The next frame is sent by the FTP server, initiating the file transfer. The server sends this message in its FTP header: "Sending "/ftpfile.txt" (72436 bytes). Mode STREAM Type ASCII NO-PRINT."

The file is being sent in ASCII mode, it's 72,436 bytes long and is using the STREAM mode utilized by UNIX systems. Note the port numbers in the TCP header, 21 and 1183, this is how TCP keeps track of each connection.

Frame Source Address Dest. Address  Summary
    4 [192.168.10.5] [192.168.10.4] FTP: R PORT=21   
                                    150 Sending "/ftpfile.txt"
                                    (72436 bytes).
                                    Mode STREAM Type ASCII NO-PRINT.

Frame 5 is also sent by the FTP server, but this is where the fun begins. TCP has now taken over the file transfer session by initiating the new port number, thus identifying a separate connection. FTP data port number 20 is usually used for data transfers, but is not being used here. Ports 1184 and 1045 are used. We know where the 1184 came from, that's the data connection port number calculated in frame 1. But where does port 1045 come from? Why isn't port 20 used? In this example, port 20 is already being used by another connection, so the server assigns and substitutes port 20 to a new connection port number (1045).

A timing algorithm generates the Initial sequence number (5010870). This number will be incremented as the frames are transferred between the server and the client. This number is to create a starting point where the sending and receiving nodes can keep track of missing frames for retransmission. The initial sequence number field in the TCP header is shown when the SYN bit is set to 1, afterwards it disappears from the TCP header.

The Next Expected Sequence number is (5010871). Notice it's one increment greater than the Initial sequence number. Since the SYN bit set to 1 is considered data, the Next Expected Sequence number is incremented by 1. Sequence numbers are incremented by the amount of data they hold within the frame, as you'll see later.

Note the MSS (Maximum Segment Size) field of 1460 in the TCP header. This is a TCP negotiation that takes place in the first few frames of the TCP handshake or call-setup process. This dictates the largest amount of data that TCP will send in a single frame. MSS only appears when the SYN bit is set to 1. The segment size cannot be larger than the MTU (Maximum Transfer Unit).

The SACK option can be found in RFC 1072. SACK is a mechanism that quickly handles multiple dropped windows.

Frame Source Address Dest. Address  Summary
    5 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045 SYN
                                    SEQ=5010870 LEN=0 WIN=8192

The next frame is a SYN frame from the FTP client. Note the MSS field, it remained the same. In this case, both machines agree to use the same maximum data size. If one of these machines were connected through a different network topology (such as a dial-up line), the MSS number may be different.

The acknowledgement number in the TCP header (5010871) corresponds to the Next Expected Sequence number from frame 5, indicating that this is the next sequential frame. Since this is the second Synchronization (SYN) frame connecting the TCP call, the FTP client sends it's own Initial Sequence Number (3374583) as well.

Since IP frames traverse multiple routers, switches, or hubs, a frame can arrive out of sequence. This sequential numbering scheme keeps the frames aligned for re-assembly on the other side of the conversation. To insure data continuity, TCP is in charge of fragmenting frames going out and sequentially re-assembling the frames coming in.

Frame Source Address Dest. Address  Summary
    6 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184 SYN 
                                    ACK=5010871 SEQ=3374583 LEN=0 WIN=8760

Sequence numbers not only insure data continuity, but also double as byte counters. The sequence numbers are incremented by the number of bytes within the data portion of the frame.

In frame 7, the FTP server sends this standard acknowledgement frame back to the FTP client. This acknowledges the Next Expected Sequence Number, 3374584. Note that this specific sequence number (3374584) belongs to the FTP client. A second sequence number belongs to the FTP server, as shown below (5010871).

Keep in mind that we're seven frames into this trace, and no file data has been sent yet.

Frame Source Address Dest. Address  Summary
    7 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     
                                    ACK=3374584 WIN=8760

And now the TCP sequence number dance begins, as the previous frame's Next Expected Sequence number (5010871) becomes the sequence number of the next frame.

This is also where the first frame of data is being sent to the FTP client with 1460 bytes of data, as indicated at the end of the TCP header. This makes the Next Expected Sequence number increment appropriately.

The Next Expected Sequence Number jumps to 5012331 from 5010871, which results in 1460 increments (the number of bytes contained within this packet). Note also that the acknowledgement number, 3374584, didn't change. Why not? That's because the acknowledgement number the FTP client. If the FTP client sends data back to the FTP server, this number will increment upward. Because the FTP client is the recipient of data and only sends standard acknowledgement frames (containing no data), this number remains the same throughout.

The FTP server sends this frame with the data.

Frame Source Address Dest. Address  Summary
    8 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584 
                                    SEQ=5010871 LEN=1460 WIN=8760

Now the FTP server sends another frame with 588 Bytes of data. Notice the acknowledgement number 3374584, it still hasn't changed. However the Next Expected Sequence Number is incremented by 588 and the Sequence Number of this frame (5012331) matches the Next Expected Sequence Number of the previous frame. This is how TCP sequencing works.

Frame Source Address Dest. Address  Summary
    9 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584 
                                    SEQ=5012331 LEN=588 WIN=8760

The acknowledgement number (5012919) in frame 10 sent by the FTP client is different - it matches the Next Expected Sequence Number in the previous frame! Remember, the previous frames containing data were sent by the FTP server and were not acknowledged by the FTP client (except for this next frame, which is a standard acknowledgement frame).

Wait a minute! If TCP is supposed to acknowledge each frame, why was the frame before this one not acknowledged by the FTP client? You've just experienced the WINDOWING MECHANISM at work. Later frames will show one acknowledgement frame per 5 data frames sent by the FTP server. This is done for network efficiency, reducing control overhead.

Also, note the Window size (8760). This number changes or 'slides' depending on the free space that each machine has for packet buffers at each socket. A socket is known as a connection which comprises of an IP address and a corresponding port number, i.e., 192.168.10.4: 1184.

Frame Source Address Dest. Address  Summary
   10 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     
                                    ACK=5012919 WIN=8760

Now that the previous two frames were acknowledged by the FTP client, this next frame sent by the FTP server contains even more data. The server sends 1460 bytes of data, which dictates the Next Expected Sequence Number (5014379). TCP will send 3 frames of data containing 1460 bytes each. This is where the window gets smaller.

Have you ever noticed that when you download a file, the bytes per second counter steadily increases? This is a direct result of the TCP windowing mechanism.

Let's skip to frame 14 to the next acknowledgement sent by the FTP client as these next 3 frames contain data sent to the client by the FTP server.

Frame Source Address Dest. Address  Summary
   11 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584 
                                    SEQ=5012919 LEN=1460 WIN=8760
   12 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584 
                                    SEQ=5014379 LEN=1460 WIN=8760
   13 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584 
                                    SEQ=5015839 LEN=1460 WIN=8760

Three frames of data have been sent by the FTP server. Now, the FTP client acknowledges these frames by sending a standard acknowledgement frame back to the FTP server.

Remember, the windowing mechanism uses the Window field in the TCP header to determine how much data the receiver can accept at one time. This dictates the window size. You can note this number in this next frame.

Acknowledgement frames control the flow of data, and the throttle is dictated by the packet buffer at the receiving end. As you will see, this packet buffer gets full because FTP is sending a lot of data at one time and is not being handled fast enough by the receiving end. The receiving end has to pull back on the throttle by sending a smaller window size in the TCP header.

Look at the frame below and then jump ahead to packets 33 and 34.

Frame Source Address Dest. Address  Summary
   14 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5017299
                                    WIN=8760
   15 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5017299 LEN=1460 WIN=8760
   16 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5018759 LEN=1460 WIN=8760
   17 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5020219 LEN=1460 WIN=8760
   18 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5021679 LEN=1460 WIN=8760
   19 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     
                                    ACK=5023139 WIN=7300
   20 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5023139 LEN=1460 WIN=8760
   21 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5024599 LEN=1460 WIN=8760
   22 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5026059 LEN=1196 WIN=8760
   23 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5027255 LEN=1460 WIN=8760
   24 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5028715 LEN=588 WIN=8760
   25 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5029303
                                    WIN=1136
   26 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5029303
                                    WIN=8760
   27 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5029303 LEN=1460 WIN=8760
   28 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5030763 LEN=1460 WIN=8760
   29 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5032223 LEN=1460 WIN=8760
   30 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045 ACK=3374584
                                    SEQ=5033683 LEN=1460 WIN=8760
   31 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5035143 LEN=1460 WIN=8760
   32 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5036603 LEN=1460 WIN=8760

This frame (33) sent by the FTP client which acknowledges frame 29, indicates a full buffer, and halts the data transfer. The FTP server thinks there were frames lost and waits to see what happens next. Note the acknowledgement number in the TCP header of this packet (5032223). This was the sequence number of frame 29, not frame 32. Also, notice the Window size of 5840.

Frame Source Address Dest. Address  Summary
   33 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5032223
                                    WIN=5840

The next frame (34) is also sent by the FTP client. This frame acknowledges the last frame of data (Frame 32) with the acknowledgement number of 5038063. HOWEVER, note the Window size in this frame, 0!

What does this mean? The FTP client is saying STOP THE TRANSMISSION, I CAN'T HANDLE ANY MORE! The FTP server now patiently waits for another frame from the FTP client in order to continue.

Frame Source Address Dest. Address  Summary
   34 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5038063
                                    WIN=0

The next frame is also sent by the FTP client. This frame contains a suitable window size. This indicates to the FTP server, which is waiting to send more data, that it is okay to start sending more data frames. In other words, this standard acknowledgement frame signals the FTP server that everything is clear. The window size is back to 8760, SEND AT FULL THROTTLE.

Frame Source Address Dest. Address  Summary
   35 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5038063
                                    WIN=8760

The FTP server replies in kind, and sends data again as seen in frame 36.

To make things even more interesting, the network connection was pulled to simulate a connection break. You can see this in frame 55.

Frame Source Address Dest. Address  Summary
   36 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5038063 LEN=1460 WIN=8760
   37 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5039523 LEN=1460 WIN=8760
   38 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5040983 LEN=1460 WIN=8760
   39 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5042443 LEN=1460 WIN=8760
   40 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5043903 LEN=1460 WIN=8760
   41 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5045363 LEN=1460 WIN=8760
   42 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5046823
                                    WIN=0
   43 [192.168.10.4] [192.168.10.5] TCP: D=21 S=1183       ACK=4966456
                                    WIN=8506
   44 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5046823
                                    WIN=1460
   45 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5046823 LEN=1460 WIN=8760
   46 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5048283
                                    WIN=8760
   47 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5048283 LEN=1460 WIN=8760
   48 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5049743 LEN=1460 WIN=8760
   49 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5051203 LEN=1460 WIN=8760
   50 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5052663 LEN=1460 WIN=8760
   51 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5054123 LEN=1460 WIN=8760
   52 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5055583 LEN=344 WIN=8760
   53 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5055927
                                    WIN=1116
   54 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5055927
                                    WIN=8760

The delta time of this frame is 18.5 seconds! Since this frame was sent after an acknowledgement from the FTP client, the FTP server is quiet and patiently waiting until it is connected to the network again to send this frame. Following this frame is another acknowledgement frame from the FTP client, then more frames from the FTP server.

Let's skip to frame 77.

Frame Source Address Dest. Address  Summary
   55 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5055927 LEN=1460 WIN=8760
   56 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5057387
                                    WIN=8760
   57 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5057387 LEN=1460 WIN=8760
   58 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5058847 LEN=1460 WIN=8760
   59 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5060307
                                    WIN=8760
   60 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5060307 LEN=1460 WIN=8760
   61 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5061767 LEN=1460 WIN=8760
   62 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5063227
                                    WIN=8760
   63 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5063227 LEN=1460 WIN=8760
   64 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5064687 LEN=1460 WIN=8760
   65 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5066147
                                    WIN=8760
   66 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5066147 LEN=1460 WIN=8760
   67 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5067607 LEN=1460 WIN=8760
   68 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5069067 LEN=1460 WIN=8760
   69 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5070527
                                    WIN=8760
   70 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5070527 LEN=1460 WIN=8760
   71 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5071987 LEN=1460 WIN=8760
   72 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5073447  LEN=912 WIN=8760
   73 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5074359
                                    WIN=8760
   74 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5074359 LEN=1460 WIN=8760
   75 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5075819 LEN=1460 WIN=8760
   76 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5077279 LEN=1460 WIN=8760

In frame 77, the FTP server signals through TCP connection 1183 that the file transfer has completed via FTP header message. The last few frames of data will be sent to the FTP client, then the connection will be torn down. Note the push flag (PSH) is set to 1, meaning that this is data to be handed up to the application and ultimately to the user's screen.

Frame Source Address Dest. Address  Summary
   77 [192.168.10.5] [192.168.10.4] FTP: R PORT=1183   
                                    226- Transfer finished
                                    successfully. Data connection closed.

DLC:  ----- DLC Header -----
DLC:
DLC:  Frame 77 arrived at  21:01:20.3152; frame size is 172 (00AC hex)
DLC:     bytes.
DLC:  Destination = Station NGC   031731
DLC:  Source      = Station 3Com7 5E7A3E
DLC:  Ethertype   = 0800 (IP)
DLC:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:       000. ....   = routine
IP:       ...0 ....   = normal delay
IP:       .... 0...   = normal throughput
IP:       .... .0.. = normal reliability
IP: Total length    = 158 bytes
IP: Identification  = 24837
IP: Flags           = 4X
IP:       .1.. .... = don't fragment
IP:       ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live    = 128 seconds/hops
IP: Protocol        = 6 (TCP)
IP: Header checksum = 03FB (correct)
IP: Source address      = [192.168.10.5]
IP: Destination address = [192.168.10.4]
IP: No options
IP:
TCP: ----- TCP header -----
TCP:
TCP: Source port             = 21 (FTP)
TCP: Destination port        = 1183
TCP: Sequence number         = 4966456
TCP: Next expected Seq number= 4966574
TCP: Acknowledgment number   = 3329981
TCP: Data offset             = 20 bytes
TCP: Flags                   = 18
TCP:               ..0. .... = (No urgent pointer)
TCP:               ...1 .... = Acknowledgment
TCP:               .... 1... = Push
TCP:               .... .0.. = (No reset)
TCP:               .... ..0. = (No SYN)
TCP:               .... ...0 = (No FIN)
TCP: Window                  = 8695
TCP: Checksum                = D3F8 (correct)
TCP: No TCP options
TCP: [118 Bytes of data]
TCP:
FTP: ----- File Transfer Data Protocol -----
FTP:
FTP: Line  1:  226- Transfer finished successfully. Data connection closed.
FTP:
FTP: Line  2: 226 UL: 0 DL: 9 Ratio: 0:0 Credit: unlimited *disabled
FTP:

In frame 77, you'll see many TCP flags or fields. Thus far, you have seen six fields in the TCP header, right after the Flags field. The flags field is basically a counter for the flags beneath. Let's briefly go through each one.

The Urgent (URG) field tells the recipient of the frame that urgent data is contained within the frame and that it must reach the application at once. This is usually sent when a user initiates an interrupt command, like CTRL-C.

The Acknowledgement (ACK) field signals an acknowledgement of a previous frame.

The Push (PSH) field tells the recipient that it does not want the data to remain in the buffer waiting for another segment of data, but to hand over the data to the application at the time of arrival. It indicates that the data within the frame is in its entirety and not segmented.

The Reset (RST) field is sent when a connection request arrives and no process is listening on the destination port. Usually, this is sent with an end of file or by the user hitting a control key to end a session. This can also indicate that there are limited resources at the other end of the connection, and the connection cannot be supported any longer.

The Synchronize (SYN) field is a request to initiate a connection.

Finally, the Finish (FIN) field is a request to close a connection.

Speaking of closing connections, let's skip to frame 83 to see this actually occur.

Frame Source Address Dest. Address  Summary
   78 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5078739
                                    WIN=8760
   79 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5078739 LEN=1460 WIN=8760
   80 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5080199 LEN=1460 WIN=8760
   81 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5081659 LEN=1460 WIN=8760
   82 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374584
                                    SEQ=5083119 LEN=188 WIN=8760

Once the last frame of data arrives to its destination (the FTP client), the client acknowledges the last frame by sending a standard acknowledgement frame with the acknowledgement number 5083307. This matches the previous frame's Next Expected Sequence number. This confirms that all of the data has successfully been transmitted, and now the connection can be torn down.

Remember, each opened connection takes up a certain amount of system resources, so it's important to close the connection once the transaction is completed.

Frame Source Address Dest. Address  Summary
   83 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5083307
                                    WIN=8572

Frame 84 is sent by the FTP server and has the FIN bit set to 1. This begins the connection tear-down of port 1045. Remember, port 1045 was substituted as the FTP control port 20 by the FTP application.

Frame Source Address Dest. Address  Summary
   84 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045 FIN ACK=3374584
                                    SEQ=5083307 LEN=0 WIN=8760

The FTP client now acknowledges the previous FIN frame with a standard TCP acknowledgement frame.

Frame Source Address Dest. Address  Summary
   85 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184     ACK=5083308
                                    WIN=8572

The FTP client sends another frame to the FTP server with the FIN bit set to 1, acknowledging the close of the TCP connection.

Frame Source Address Dest. Address  Summary
   86 [192.168.10.4] [192.168.10.5] TCP: D=1045 S=1184 FIN ACK=5083308
                                    SEQ=3374584 LEN=0 WIN=8572

As a final acknowledgement, the FTP server sends a standard TCP acknowledgement back to the FTP client, effectively closing the connection. This last acknowledgement frame is sent as a verification that resources are now available for other connections. If this frame was not sent, the FIN, FIN, ACK (connection tear-down) sequence will have to start again.

Frame Source Address Dest. Address  Summary
   87 [192.168.10.5] [192.168.10.4] TCP: D=1184 S=1045     ACK=3374585
                                    WIN=8760

The last frame is sent by the FTP client as an acknowledgement of frame 77, which contained FTP data for the user stating that the file transfer was completed.

Frame Source Address Dest. Address  Summary
   88 [192.168.10.4] [192.168.10.5] TCP: D=21 S=1183       ACK=4966574
                                    WIN=8388

With this introduction to TCP, you should now be able to look at any network trace and watch the conversations between workstations. Good luck, and good analysis!