超时重传的等待时间设置为多少合适？
超时重传的等待时间：Retransmission Time Out, RTO。
等待时间过长，若丢包严重，则传输的吞吐量低。
等待时间过短，会导致频繁的发包，增加网络拥堵，占用带宽。
等待时间只能尽可能的短，按照正常的节奏，一端发送报文到收到ACK报文的时间（往返时间Round Trip Time）就是最短的等待时间，RTO可以略微大于RTT，以增加一点容错范围。
但RTT并不是固定的，因为网络拥堵状况随时在发生变化，所以RTT应当不停的动态计算，有一系列的算法支持。
基于定时器的超时重传存在什么问题？
会重发接收方已经收到的报文，浪费带宽，通信时间被拖长。
接收方发送的ACK报文中确认的报文序号有个特点，就是这个序号之前的报文接收方一定都已经收到了。
这样就会导致一个问题，如果发送方发了一系列序号连续的报文，接收方只有中间的几个报文没有收到，那么收到序号较大的报文后回应的ACK里的确认序号是较小的，这会导致发送方无法确认较大序号的报文接收方有没有收到。
此时发送方该重发哪些报文就成了问题，此时有两种策略：
一种策略是只重传ACK期待的序号的报文，序号较大报文暂时不重发，等待它们的定时器超时了再重发，如果较大序号的报文接收方都接受到了倒没问题，但如果较大序号的报文接收方都没收到，一个个等待报文超时无疑是拖慢了整体的传输时间。
另一种策略就是重传ACK序号后所有的报文，如果丢包严重，这种做法效率挺高，但如果丢包并不严重，这种做法会浪费很多流量。
如果能知道没有收到的报文序号是哪些就很好办了，用SACK可以解决这个问题。
例如发送方发了序号为1、2、3、4、5、6的报文，接收方收到了1、2、4、5、6，唯独为没有收到3（3可能卡在某个网络节点上），在接收到1后回应ACK 2，接收2后回应ACK 3，接收到4、5、6，也是回应ACK 3，此时发送方对3、4、5、6的定时器都会超时，然后都会重发3、4、5、6，但实际4、5、6已经接收到了，重发4、5、6其实是浪费带宽，也增加了整体传输时长。