This is also sometimes referred to as TCP retransmission due to RTO (Retransmit Timeout). What are they and what can you do about them? What Is TCP Retransmission? TCP retransmissions due to RTO is worse than other causes of TCP retransmissions because depending on your TCP implementation, the flow can go to slowstart, congestion window (cwnd) can be cut in half and the performance is hit with major penalties.In an effort to rid the world of needless application and network performance slowdowns, we turn to retransmission timeouts (RTOs). TCP ( the Transmission Control Protocol) connects network devices to the internet.
So the question is what causes the client to pause for that long time.When an outbound segment is handed down to an IP and there's no acknowledgment for the data before TCP's automatic timer expires, the segment is retransmitted.
In this case the RST has sent, beause the server has closed his socket in the meantime of 9 Minutes. After that he is glad and closes the session in the same milisecond as the Request, too. And then after more than 9 Minutes (that is what I meant with delayed) he sends his Request. Because he still wants to send something. Which is more or less immediately ACKED by the client, so the client is still alive.īut the client does not close his half-session, too. Then ~30 sec after the 3WAY Handshake (05:47:39.491) the server terminates the session by a half close (FIN-Bit). So the server starts the discussed "Spurious Retransmission" after ~30 sec. But after the 3WAY Handshake, when normally the POST Request is transmitted nothing happens. So what we see is that the session has been initiated at 05:46:48.155. Which seems to be fine.īut in the second picture the session has a duration of more than 10 Minutes. Also you can see in the primary picture that the whole session inclusive Request has a duration of 13ms. The reason for the session is to transmit the POST Request which can be seen in FRAME 323.
0 kommentar(er)
