TCP重传

一、TCP重传
    1、重传的原因
        1）发端计时器超时
        TCP每发送一个报文段，就对这个报文段设置一次计时器。当计时器超时而没有收到确认时，就重传该报文。
        注：原来报文哪去了呢？两种可能：
            1）在中间节点丢了。2）还在路上，走的慢。
        对于第一种情况：接收端是不知情的，而对于第二种情况，接收端表现为收到两个一摸一样的报文。
        2）快重传
        就是说在发送端一连收到4个ack报文，其中3个重复报文时，就立即重传相应的报文而不等到定时器超时。
        注：
            1）原来报文的去向以上同。
            2）重传报文可以与原报文不同，就是说重传报文长度可以比原报文长也可以比原报文短等。
            3）说明下逆序问题。还没到快重传的时候，走丢的包就出现了。这时候接收端保留逆序包，发送端不用对其进行重传。
    2、重传的判定
        TCM监测点要求计算一次HTTP过程的重传率，公式：重传率=重传报文数/有效报文数
        其中有效报文数：指的是除了纯ACK包外的报文总数。因为纯ACK包没有重传的说法。
        重传报文的判定分双向进行，现在的算法（简要说明）：
        设置一个变量MaxSeq，初始化为0.每来一个包，查看其seq，如果该seq大于MaxSeq，则
        MaxSeq = seq，否则判定为重传包。
        该算法的缺点：目前看到的情况，无法区分逆序后来的包和重传包。如同逆序图所示:其实M3只是迟到了，并没有重传，但我们的算法却把它判定为重传报文。
二、因重传引起的问题
    1.在测量过程中发现某个网站TCP连接的重置率特别高，抓包后发现，原来都是重传惹的祸（FIN ACK包重传）。
    可以理解当服务器收到客户端第一个Ack报文时，该次TCP连接就关闭了。再次收到ACK，就出错

Ø 为什么TCP存在重传
    TCP是一种可靠的协议，在网络交互的过程中，由于TCP报文是封装在IP协议中的，IP协议的无连接特性导致其可能在交互的过程中丢失，在这种情况下，TCP协议如何保障其传输的可靠性呢？
    TCP通过在发送数据报文时设置一个超时定时器来解决这种问题，如果在定时器溢出时还没有收到来自对端对发送报文的确认，它就重传该数据报文。
Ø 导致重传的常见状况
    1 数据报传输中途丢失
    发送端的数据报文在网络传输的过程中，被中间链路或中间设备丢弃，这个过程如下图所示：
    2 接收端的ACK确认报文在传输中途丢失
    发送端发送的数据报文到达了接受端，接受端也针对接收到的报文发送了相应的ACK确认报文，但是，这个ACK确认报文被中间链路或中间设备丢弃了，该过程如下图所示：
    3 接收端异常未响应ACK或被接收端丢弃
    发送端发送的数据报文到达了接收端，但是，接收端由于种种原因，直接忽略该数据报文，或者接收到报文但并没有发送针对该报文的ACK确认报文，这个过程如下图所示：
Ø TCP重传间隔时间和TCP重传次数
    一般TCP报文的重传超时时间
    TCP重传时间间隔有着多种不同的算法，最常见的就是《TCP/IP详解卷1》中关于超时重传的算法。具体算法不再赘述，请大家参考《TCP/IP详解卷1》第21章《TCP的超时与重传》。
    SYN报文重传间隔时间
    在实际情况下，由于SYN报文是TCP连接的第一个报文，如果该报文在传输的过程中丢弃了，那么发送方则无法测量RTT，也就无法根据RTT来计算RTO。因此，SYN重传的算法就要简单一些，SYN重传时间间隔一般根据系统实现的不同稍有差别，windows系统一般将第一次重传超时设为3秒，以后每次超时重传时间为上一次的2倍，如下图所示：
    报文重传的次数
    TCP报文重传的次数也根据系统设置的不同而有区分，有些系统，一个报文只会被重传3次，如果重传三次后还未收到该报文的确认，那么就不再尝试重传，直接reset重置该TCP连接，但有些要求很高的业务应用系统，则会不断的重传被丢弃的报文，以尽最大可能保证业务数据的正常交互。
Ø 重传对业务应用的影响
    1 保障了业务的可靠性
    TCP的重传存在原因就是为了保障TCP的可靠性，正是由于TCP存在重传的机制，那些基于TCP的业务应用在网络交互的过程中，不再担心由于丢包、包损坏等导致的一系列应用问题了。
    2 反映网络通讯的状况
    由于IP协议的不可靠性和网络系统的复杂性，少量的报文丢失和TCP重传是正常的，但是如果业务交互过程中，存在大量的TCP重传，会严重影响业务系统交互的效率，导致业务系统出现缓慢甚至无响应的情况发生。
    一般而言，出现大量TCP重传说明网络通讯的状况非常糟糕，需要站在网络层的角度分析丢包和重传的原因。
Ø 在实际的分析过程中，我们如何确认一个TCP报文是重传报文
    在实际的数据交互过程中，重传报文一般具有以下两个特征：一是TCP交互序列号突然下降，二是其在TCP报头中的序列号、数据长度、应用数据等参数跟前面某TCP报文一致。
    1 序列号突然下降（一般是TCP重传）
    在TCP报文传输的过程中，因为其需要不断的交互应用数据，因此，TCP报文的序列号会不断的变大。正常情况下，TCP序列号不会出现下降的情况，出现序列号下降，一般都是TCP的重传报文导致的。如下图所示：
    在上图中，服务器端交互的TCP报文序列号从24481开始一直处于不断上升的趋势，但是服务器的第六个TCP报文序列号却突然下降为20161，这个情形，基本上可以肯定这第六个TCP报文是前面某个报文的重传报文。
    2 根据序列号、长度甚至应用数据等确认是哪一个报文的重传。
    在数据交互过程中，一般情况下，TCP重传的报文跟传输中被丢弃的报文在序列号、数据长度、应用字段值上都是一样的，我们可以利用这个特征来确定某个具体的TCP报文是否是前面某个报文的重传。下图是一个客户端存在重传的数据流图：
    在上图中，我们看到客户端第三个报文和第四个报文的序列号（Seq）、下一个序列号（Next Seq）以及载荷长度都是一样的，那么我们可以肯定客户端的第四个报文是客户端第三个报文的重传。
    现在很多的网络分析工具的专家诊断系统基本上都可以针对TCP重传直接告警，我们不需要在去深入分析这个过程了，为我们节省了大量的分析时间。