Table of Contents
TCP is a connection-oriented data transmission protocol and widely used across the networks. It is very popular due to its security and reliability of data transmission between clients and servers. TCP 3-way handshake process ensures data transmission happens in a reliable manner; however sometimes, it is bogged down by some common issues related to connection closures during data transmission between two systems.
In today’s topic we will learn about common TCP FIN issues which hamper the normal functioning of TCP FIN or TCP connection closure, usual scenarios and how to troubleshoot them.
Related: TCP FIN vs RST Packets: Know the Difference
About TCP FIN
The TCP FIN (Finish) flag is a control bit used in the Transmission Control Protocol (TCP) to indicate the end of data transmission from one side of a connection. When a device sends a TCP packet with the FIN flag set, it signals that it has finished sending data but can still receive data from the other side.
TCP Connection Release Techniques
TCP FIN is required to terminate TCP sessions normally. TCP supports two types of connection release techniques.
Graceful Connection Release
The connection is open until both parties agree to close their side of connection.
Abrupt Connection Release
One TCP entity is forced to close the connection or one user closes both side connections.
An abrupt connection release happens when an RST segment is being sent. An RST segment can be sent for any of the below reasons:
- Receiving of a non-SYN segment for a non-existing TCP connection
- In open connection, when a segment with an invalid header is received some TCP implementations send an RST segment
- An RST segment is sent when some implementations need to close an existing connection
- Existing TCP segment might be closed due to lack of resources or remote host in unreachable and there is no response
Common TCP Fin Issues
Common TCP FIN issues could be related to high session counts, latency, sporadic disconnections etc and these issues could originate due to configuration errors, software bugs and improper handling of TCP sessions.
- Network Latency and Congestion – when a TCP connection is terminated by a client it sends a FIN packet where the receiving system confirms receipt of FIN packet however, in situations of high level of congestion on networks this process may take longer than usual. This delay may cause the sending system to assume there was an error in transmission resulting in sending FIN packet again which could lead to half-open connections.
- Sporadic Disconnections could show in initial analysis that packet drop right after TCP-FIN packet is sent but not acknowledged. Such cases could be the result of misconfigured timeout settings or synchronization lacking between client and servers and often prevalent in network environments which are big and complex.
- Non-responsive Peers or Servers – in certain cases when one client does not want to close connection and doesn’t respond at all during the termination process the initiating party must time out. The time out could be long and can create significant latency issues while trying to establish new connections.
- Misconfigured Firewalls – at times interfere with TCP connection termination process and block legitimate packets required for proper termination; it could result in half open connections. Half open connections cause resource exhaustion, security vulnerabilities and degradation in performance.
Best Practices for Successful TCP FIN
Graceful terminations help to ensure data integrity and allows both parties to complete all data transfer before closure of connections. The graceful technique involves sending FIN packets with sequence numbers to indicate no more data to be sent.
- Firewall and load balancer proper configurations – The network devices should be configured to allow inbound traffic on established connections and deny traffic from unknown networks.
- Monitoring – TCP termination process involves proactive monitoring of network connections for any abnormal behaviours such as Wireshark, tcpdump and netstat etc.
ABOUT THE AUTHOR
I am here to share my knowledge and experience in the field of networking with the goal being – “The more you share, the more you learn.”
I am a biotechnologist by qualification and a Network Enthusiast by interest. I developed interest in networking being in the company of a passionate Network Professional, my husband.
I am a strong believer of the fact that “learning is a constant process of discovering yourself.”
– Rashmi Bhardwaj (Author/Editor)
