Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

long delay to send [FIN, ACK] after receiving the application data

The client is coding based on Spring-Web RestTemplate, we found long latency for some cases when accessing another service in our prod environment, and grabbed some packages down through tcpdump.

After analysis, there are about 3% of the cases delay is higher than expected, the longest is up to 60+s. Client IP(10.x.x.77), Server IP (10.x.x.192).

For all delay cases, the application data can be received quickly from the server, and the client would send [ACK] in time, but it will wait a long time to send [Encrypted Alert] or [FIN ACK] to terminate the connection. It is confirmed that there is no problem with the background service. So why client need to wait so long to terminate the TCP connection?

For the common cases, the [Encrypted Alert] would be sent from the client immediately after [ACK] the [Application Data], and the connection can be terminated successfully as expected.

Could anyone help to explain what happened? Thanks in advance.

Please find wireshark screenshots from this link.

long delay to send [FIN, ACK] after receiving the application data

The client is coding based on Spring-Web RestTemplate, we found long latency for some cases when accessing another service in our prod environment, and grabbed some packages down through tcpdump.

After analysis, there are about 3% of the cases delay is higher than expected, the longest is up to 60+s. Client IP(10.x.x.77), Server IP (10.x.x.192).

For all delay cases, the application data can be received quickly from the server, and the client would send [ACK] in time, but it will wait a long time to send [Encrypted Alert] or [FIN ACK] to terminate the connection. It is confirmed that there is no problem with the background service. So why client need to wait so long to terminate the TCP connection?

For the common cases, the [Encrypted Alert] would be sent from the client immediately after [ACK] the [Application Data], and the connection can be terminated successfully as expected.

Could anyone help to explain what happened? Thanks in advance.

Please find wireshark screenshots from this link.

long delay to send [FIN, ACK] after receiving the application data

The client is coding based on Spring-Web RestTemplate, we found long latency for some cases when accessing another service in our prod environment, and grabbed some packages down through tcpdump.

After analysis, there are about 3% of the cases delay is higher than expected, the longest is up to 60+s. Client IP(10.x.x.77), Server IP (10.x.x.192).60+s.

For all delay cases, the application data can be received quickly from the server, and the client would send [ACK] in time, but it will wait a long time to send [Encrypted Alert] or [FIN ACK] to terminate the connection. It is confirmed that there is no problem with the background service. So why client need to wait so long to terminate the TCP connection?

For the common cases, the [Encrypted Alert] would be sent from the client immediately after [ACK] the [Application Data], and the connection can be terminated successfully as expected.

Could anyone help to explain what happened? Thanks in advance.