TCP的重传

众所周知，TCP通过确认重传（手段之一）来保证数据的可靠传输，这里总结一下几种场景：

• RTO重传，就是数据包发出去之后，如果没有收到ACK，在RTO之后开始重传，一直重传一直重传，直到收到ACK或者最终放弃。RTO重传还会涉及到指数退让。在一般情况下，由于TCP上总是有流在走着，如果中间有丢失包，特别是SACK特性的引入，能够让发送端尽快得到包丢失，启动重传。

• 快速重传。三次dup ack之后，发送端不用等到RTO，直接重传。

• SACK快速重传。本来三次dup ack触发快速重传，SACK功能，定义了新的dup ack场景：如果SACK新确认了在窗口范围内的(HighACK - HighData)数据，则被认为是一个dup ack，那么三次dup ack触发快速重传。

• FACK重传。dup ack（不知道怎么说）情况下，发现中间差了大于3个包，就直接快速重传场景。比如，发送1，2，3，4。而ACK1, SACK4回来。

• thin stream重传。对于数据包很少的（thin stream，TCP主要是通过发送缓存中没有要发的数据来判断，当然还有一些其它的状态控制），会没有足够多的dup ack来启动快速重传。这种情况下，一个dup ack就能够触发快速重传，并且在这种情况下，还可以不使用指数退让RTO。

• ER早重传。一般情况下，三个dup ack引起快速重传，可是如果发送端on flight的数据少（小于dup ack门限加1），并且没有新数据要发送，或者受流控限制不能发太多的情况下，降低dup ack的门槛，比如nr-of-on-flight -1甚至直接降为1，启动快速重传。ER和thin stream的区别在于：

  • thin stream触发条件是dup ack + 没有新数据发送；ER是on flight的数据段少（或者不能发送数据）+dup ack。
  • thin stream情况下一个dup ack就能够触发重传，ER考虑的情况会多一点(也可以是一个）。
  • 如果是还有数据要发（由于拥塞控制不能发）就是ER的场景了。

• TLP尾包丢失检测。就是后面没有数据发送（或者由于流控不能发送的时候）而尾包丢失，由于没有后续的ACK来触发，必须等到RTO重传。为了能够尽快检测出这种状况，TCP会在PTO时间内，重传最后一包数据，或者发送新数据（不受发送窗口限制）。