How Does TCP Connection Termination Work With FIN Packets | 4-Way Handshake & Troubleshooting Guide

1. Industry Pain Points & Technical Context

Unlike UDP, TCP requires a specific handshake to establish a connection and a FIN-based sequence to terminate it gracefully. In industrial IoT and automation, four major issues frequently occur:

• 1.1 Violent Termination (RST) Leading to Data Loss: Many legacy devices use RST (Reset) packets to force-close connections. This discards unsent data in the buffer, leading to a packet loss rate of up to 12% in MODBUS/TCP environments.
• 1.2 "Half-Close" Ignorance & CLOSE_WAIT Stacks: If an application fails to acknowledge a FIN packet by closing its own side of the stream, connections hang in the CLOSE_WAIT state, eventually exhausting file descriptors on devices like the TCP-M25.
• 1.3 Port Exhaustion via TIME_WAIT: High-frequency short connections often hit the 65,535 port limit because the default 2MSL (Maximum Segment Lifetime) is too long, causing the device to refuse new sessions.
• 1.4 Zombie Connections in Weak Networks: In environments with unstable 4G or WiFi, connections can stay "Established" indefinitely if no FIN/ACK exchange occurs during a power or signal failure.

2. Core Technology: The FIN Packet & 4-Way Handshake

2.1 Technical Definitions

• FIN Packet: A control flag in the 6-bit field of the TCP header. It notifies the peer that the sender has no more data. This is the only legal method for a Graceful Shutdown under RFC 793.
• Termination Process: Because TCP is full-duplex, the inbound and outbound streams are independent. Closing the connection requires two separate FIN/ACK exchanges.

2.2 The 4-Way Handshake Logic

Using a TCP-M25 Client and a PLC-N16 Server as an example:

1. FIN (First Wave): The Client sends FIN=1. Status: FIN_WAIT_1. This signals the Client is done sending.
2. ACK (Second Wave): The Server replies with ACK. Status: CLOSE_WAIT. The Client enters FIN_WAIT_2. The connection is now "half-closed"; the server can still send data.
3. FIN (Third Wave): Once the Server finishes sending residual data, it sends its own FIN=1. Status: LAST_ACK.
4. ACK (Fourth Wave): The Client receives the FIN, sends a final ACK, and enters TIME_WAIT. After 2MSL, the resources are fully released.

2.3 Graceful (FIN) vs. Forced (RST) Termination

3. Engineering Solutions for Industrial Scenarios

Scenario A: Preventing Port Exhaustion in Sensor Clusters

• The Issue: TCP-M25 modules tracking sensors every 200ms exhausted ports due to long TIME_WAIT cycles.
• The Solution:
  • Compress 2MSL timeout from 60s to 10s by adjusting the MSL to 5s.
  • Enable tcp_tw_reuse (Port Reuse) in the communication stack.
• Result: 85% reduction in TIME_WAIT occupancy; connection failures eliminated.

Scenario B: Solving CLOSE_WAIT Pileup on PLC-N16

• The Issue: Weak network signals caused connections to break, leaving thousands of sessions in CLOSE_WAIT, eventually crashing the PLC.
• The Solution:
  • Implement TCP Keep-Alive: 15s cycle, 3 retries.
  • Optimize application layer logic to force-trigger the second half of the handshake upon detecting a peer's FIN.
• Result: Zombie connections cleared within 20s of a network failure.

4. Best Practices for Deployment

1. Define Protocol Boundaries: Use FIN for all routine shutdowns (polling end, device offline). Reserve RST strictly for application crashes or security anomalies.
2. Set Smart Timeouts:
   • Long-connections (PLC): Keep default 2MSL (60s) for maximum data integrity.
   • Short-connections (Sensors): Reduce MSL to 3-5s and enable port reuse.
3. Mandatory Keep-Alive: All industrial TCP devices should be configured with a 10s initial wait, 5s interval, and 3 retries to prevent resources from being held by dead links.

5. Frequently Asked Questions (FAQ)

Q: How exactly does the TCP connection termination process work with FIN packets?
A: Since TCP is full-duplex, it uses a 4-step process. One end sends a FIN to stop sending data; the other acknowledges (ACK) but can still send data. Then, the second end sends its own FIN to stop, and a final ACK completes the close. This ensures no data is cut off mid-stream.

Q: What is the main difference between a FIN packet and an RST packet?
A: FIN is for a "Graceful Shutdown" (cleaning up properly with no data loss). RST is a "Forced Reset" (cutting the cord immediately, which can cause data loss and errors).

Q: Why must a device stay in TIME_WAIT for 2MSL?
A: It serves two purposes: first, to ensure the final ACK is received by the peer; and second, to allow any delayed packets from the old connection to expire so they don't interfere with a new connection on the same port.

Q: How do I clear a CLOSE_WAIT hang?
A: CLOSE_WAIT is almost always an application-side bug where the program hasn't called the "Close" function after the network stack received a FIN. Enable TCP Keep-Alive and ensure your software handles "half-close" events correctly.