Basic TCP analysis with Wireshark

TCP is a reliable connection-based protocol that is used by many of the application layer protocols we use every day. HTTP, HTTPS, and FTP are only a few examples from the list. This is the first article in a series that illustrates the basics of the TCP protocol and its analysis using Wireshark. Basic knowledge of how to use Wireshark is needed.

TCP analysis articles

1. TCP connection establishment and termination
2. Data transmission over TCP

What is TCP

There are many transport layer protocols, from which TCP and UDP are the most popular. TCP is an acronym for Transmission Control Protocol and it has the following characteristics

• Connection based: In TCP, a connection is established between the two communicating hosts and the state of this connection is maintained on the two hosts. Usually, the two hosts are named client and server and the client is the host who initiates the connection to the server.
• Reliable: TCP is a reliable protocol. It will add a checksum to data and headers to ensure that the received bytes are exactly what was sent. Also, it monitors the state of transmitted packets and tries to do retransmission for packets that are lost on the way to their destination.

The Berkeley sockets API is the most common API used for TCP and you will almost find it in all major operating systems.

Connection establishment

The TCP is a connection between two hosts

• Server: This host is normally listening on a certain IP address and a port number waiting for connections from clients
• Client: This is the host that initiates the connection to the server

The TCP defines a 3-way handshake mechanism to initiate the connection.

• The client starts by sending a synchronization packet (SYN) to the server it needs to connect to and waits for the server response.
• The server responds with a packet containing both an acknowledgement (ACK) that it received the client's SYN and a SYN directed to the client.
• The client should then reply with an ACK indicating that it received the server SYN too.

The following sequence diagram illustrates the 3-way handshake process

And this is how the handshake is captured by wireshark

During this handshake, the client and the server also declare their capabilities for each other to agree on the common connection parameters to be used between them. Also during the handshake, each side informs the other one what is its initial sequence number (ISN).

Every time a host sends a TCP packet, it will contain a sequence number which is the total number of sent bytes. The sequence number is not initialized with zero, it's initialized with a random number ISN for each side of the connection.

The expert view of Wireshark for each TCP packet will display packet parameters, flags and options.

Packet parameters

The generic TCP parameters on each packet are:

• Source port: The port number of the side who transmitted this packet
• Destination port: The port number of the side who should receive this packet
• Stream index: This is not a real TCP parameter. It's only a Wireshark representation of the connection 4 values (source address, source port, destination address, and destination port). If one of these values changed, the sequence number will differ. This can happen for example if you are capturing at the server-side and there is more than one client connected to the server, then each connection will have its sequence number.
• TCP segment length: The size of the data contained on this packet
• Sequence number: This is a Wireshark more readable representation of the sequence number. It's calculated starting from 0, so it's easier to track packets.
• Sequence number (raw): The actual sequence number sent on the packet -- the one starts from the ISN
• Next sequence number: Normally it's the current sequence number + the length of data in the current packet. This rule doesn't apply to this packet as it's a SYN packet, and the SYN is considered as 1 byte, so the next sequence number increased by 1 seven if there is no data on the packet.
• Acknowledgment number: This represents the total number of bytes the current transmitting host received from the other side. This field is also a Wireshark added field to make it easier to analyze the TCP capture by counting the acknowledgment number from 0.
• Acknowledgment number (raw): The real Acknowledgment number.
• Header length: The TCP header length. This can range from 20 to 60 bytes depending on the TCP options in the packet.

• Window size value: This is the receive buffer size in the current transmitting host. The host here is informing the other side host how many bytes it can receive to avoid the case of the other side replying with a large number of bytes that can't be handled.
• Checksum: Checksum of the TCP packet. This is used by the receiving host to verify that the received packet is OK
• Checksum status: By default Wireshark is not verifying the packet checksum, but there is an option to enable checksum verification.

TCP flags

• Congestion window reduced: The transmitting host reduced its transmit rate
• ECN-Echo: the transmitting host received an earlier congestion notification
• Urgent: Flag the packet as an urgent to inform the OS to handle it in a higher priority
• Acknowledgment: This flag indicates if the current packet contains an ACK
• Push: The receiving host should pass the data to the receiving APP as soon as possible.
• Reset: Indicates that the connection has some problem and it's reset from the transmitting host side.
• Syn: Indicates that this packet is a SYN packet
• Fin: Indicate that this is a finalization FIN packet. Will see this later when talking about closing the TCP connection.

TCP options

TCP options are used to add capabilities that were not part of the original TCP specifications. We will not discuss options now as they will be discussed later.

The client connection to the server can be refused and the most common causes are that the server is not listening on the port the client is trying to connect to or if there is some firewall rule that prevents the connection. In this case, the server may respond with a reset instead of SYN and ACK

Closing the connection

To close the TCP connection, the closing side should send a FIN packet which also contains an ACK for the last data this side received, then the other side should reply with an ACK that it received the FIN and notify the application that the other side is closing the connection. Usually the application will close the connection too which leads to another FIN to be sent to the side initiate the close and wait for an ACK to know that connection is now closed completely from both sides.
This is the TCP connection close sequence diagram assuming that the client initiated the connection termination

And this is how the connection close is captured in wireshark

The side that initialized the connection closure will not be able to use the same IP and local port again to connect to the same server IP and port for a certain period -- controlled by the operating system. It should wait for some timeout counter set by it's OS to timeout before being able to do so.

If any problems happened during the connection close, then the connection may be terminated with a Reset instead of FIN.

There is also a half closed mode, in which only one side closes the connection to indicate that it will not transmit any more, but it can normally receive data from the other side till it close the connection too.

In this tutorial we discussed the basics of TCP, and how to open and close the connection. In the next tutorial in this series we will talk about actual data transfer over the TCP protocol.

References

• TCP/IP Illustrated, Vol. 1: The Protocols, by W. Richard Stevens
• Connection establishment wireshark capture
• Connection refuse wireshark capture
• Connection close wireshark capture