上一篇介绍 TCP 的文章「TCP 三次握手,四次挥手和一些细节」反馈还不错,还是蛮开心的,这次接着讲一讲关于超时和重传那一部分。
我们都知道 TCP 协议具有重传机制,也就是说,如果发送方认为发生了丢包现象,就重发这些数据包。很显然,我们需要一个方法来「猜测」是否发生了丢包。最简单的想法就是,接收方每收到一个包,就向发送方返回一个 ACK,表示自己已经收到了这段数据,反过来,如果发送方一段时间内没有收到 ACK,就知道很可能是数据包丢失了,紧接着就重发该数据包,直到收到 ACK 为止。
你可能注意到我用的是「猜测」,因为即使是超时了,这个数据包也可能并没有丢,它只是绕了一条远路,来的很晚而已。毕竟 TCP 协议是位于传输层的协议,不可能明确知道数据链路层和物理层发生了什么。但这并不妨碍我们的超时重传机制,因为接收方会自动忽略重复的包。
超时和重传的概念其实就是这么简单,但内部的细节却是很多,我们最先想到的一个问题就是,到底多长时间才能算超时呢?
超时是怎么确定的?
一刀切的办法就是,我直接把超时时间设成一个固定值,比如说 200ms,但这样肯定是有问题的,我们的电脑和很多服务器都有交互,这些服务器位于天南海北,国内国外,延迟差异巨大,打个比方:
- 我的个人博客搭在国内,延迟大概 30ms,也就是说正常情况下的数据包,60ms 左右就已经能收到 ACK 了,但是按照我们的方法,200ms 才能确定丢包(正常可能是 90 到 120 ms),这效率实在是有点低。
- 假设你访问某国外网站,延迟有 130 ms,这就麻烦了,正常的数据包都可能被认为是超时,导致大量数据包被重发,可以想象,重发的数据包也很容易被误判为超时。。。雪崩效应的感觉
所以设置固定值是很不可靠的,我们要根据网络延迟,动态调整超时时间,延迟越大,超时时间越长。
在这里先引入两个概念:
- RTT(Round Trip Time):往返时延,也就是**数据包从发出去到收到对应 ACK 的时间。**RTT 是针对连接的,每一个连接都有各自独立的 RTT。
- RTO(Retransmission Time Out):重传超时,也就是前面说的超时时间。
比较标准的 RTT 定义:
Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowle