上周对数据中心tcp数据传输的超时重传时间进行了探究，是的，我们可以缩短重传超时时间，但为什么在数据中心内部也会出现丢包呢？下面会对这个问题进行探讨。

下面几种丢包情形是大家所熟悉的：1､数据中心内网的某个端口的带宽跑满2､四层，如lvs状态表溢出，新建连接时无法分配状态，所以放弃新连接3､七层，包括web服务器的监听队列backlog满，丢弃新建的连接请求接下来分析一个跟应用部署架构相关的丢包场景，如下图：

多个发送者向一个接受者发送数据，这样接受方上连的交换机端口，在任何一时刻只能发送一个数据包，而与此同时会收到多个待发送的数据包，交换机有两种办法来应对这样的传输

在数据中心网络内，机器之间数据传输的往返时间(rtt)一般在10ms以内，为此调内部服务的超时时间一般会设置成50ms、200ms、500ms等，如果在传输过程中出现丢包，这样的服务超时时间，tcp层有机会发现并重传一次数据么？如果设置成200ms以内，答案是没有机会，原因是linux系统下第一次重传时间等于传输的往返时间上至少加上200ms的预测偏差值，即如果rtt值是7ms，第一次重传超时时间至少是207ms，这样如果对某个接口的超时时间设置成200ms以内， 即便是rtt时间很小，仍然无法容忍一次丢包，因为在tcp发现丢包之前，该接口已经超时了。

本文针对linux系统tcp数据包第一次重传时间的计算进行探究，结果会让人大吃一惊。提出的优化方法，理论上能够降低内部服务调用时延和出错量。

tcp发送数据包后，会设置一个定时器，到期后如果还没有收到对方的回复(ack)，就会重传数据包。从发出数据包到第一次重传之间的间隔时间称为retransmission timeout(RTO)，rto由数据包的往返时间(rtt)加上rtt的预测偏差(波动值)计算出来。

即 rto = srtt + rttvar，其中srtt是rtt的平滑值，而rttvar是波动值，代表可能的预测偏差。

接下来我们做