通过前面的TCP介绍我们对以后的排错以及网站编写和优化处理有了基础了解，接下来我们讨论一下TCP重传
当我们的数据有的因为网络等原因没有发送过去时通过重传进行重新发送。
我们的重传计时器维护着一个重传超时RTO,当TCP发送的时候计时 ACK确认的时候进行停止，从数据包的发送到确认这段时间就是往返时间。
通过将多个往返时间相加求平均来得到最终的RTO，之后有了固定的值当数据发送出去然而没有回应ack的时候知道没有收到数据，重新发送该部分数据RTO会经过不断的重新发送进而翻倍直到停止结束。
可以看到TCP Retransmission表明是重传
我们重传的这些的内容也是相同的，不会改变。
我们可以看到已经确定之前的接收并期望下一个为1
在看看第二个
看到的是10945这意味着出错需要重传，因为我们本来seqnumber=1
之后就进行重传了，直到收到ack确定。
如果出现了多个数据的丢失，我们如果判断哪个数据丢失了？
目前采用的是在收到确认的时候告诉我收到XX 某个XX没有收到，这样不断的告诉进而重传数据。
了解了这部分也就明白了网络出现故障的拍错的一部分，在设计网站或者程序的时候也就明白该如何去处理了。
希望本文对您有所帮助。
当我们的数据有的因为网络等原因没有发送过去时通过重传进行重新发送。
我们的重传计时器维护着一个重传超时RTO,当TCP发送的时候计时 ACK确认的时候进行停止，从数据包的发送到确认这段时间就是往返时间。
通过将多个往返时间相加求平均来得到最终的RTO，之后有了固定的值当数据发送出去然而没有回应ack的时候知道没有收到数据，重新发送该部分数据RTO会经过不断的重新发送进而翻倍直到停止结束。
可以看到TCP Retransmission表明是重传
我们重传的这些的内容也是相同的，不会改变。
我们可以看到已经确定之前的接收并期望下一个为1
在看看第二个
看到的是10945这意味着出错需要重传，因为我们本来seqnumber=1
之后就进行重传了，直到收到ack确定。
如果出现了多个数据的丢失，我们如果判断哪个数据丢失了？
目前采用的是在收到确认的时候告诉我收到XX 某个XX没有收到，这样不断的告诉进而重传数据。
了解了这部分也就明白了网络出现故障的拍错的一部分，在设计网站或者程序的时候也就明白该如何去处理了。
希望本文对您有所帮助。
