TCP 超时重传时间的选择
TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。
TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。
加权平均往返时间
TCP 保留了 RTT 的一个加权平均往返时间 RTTS（这又称为平滑的往返时间）。
第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：
式中，0 ≤ α ＜ 1。若 α 很接近于零，表示 RTT 值更新较慢。若选择 α 接近于 1，则表示 RTT 值更新较快。RFC 2988 推荐的 α 值为 1/8，即 0.125。
超时重传时间 RTO
RTO (Retransmission Time-Out) 应略大于上面得出的加权平均往返时间 RTTS。
RFC 2988 建议使用下式计算 RTO：
RTTD 是 RTT 的偏差的加权平均值。
RFC 2988 建议这样计算 RTTD。第一次测量时，RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD：
β 是个小于 1 的系数，其推荐值是 1/4，即 0.25。
Karn 算法
在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。但是，超时重传时间就无法更新。
修正的 Karn 算法
报文段每重传一次，就把 RTO 增大一些：
系数 γ 的典型值是 2 。当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。
选择确认 SACK
设法只传送缺少的数据而不重传已经正确到达接收方的数据。
接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。
由于首部选项的长度最多只有 40 字节，而指明一个边界就要用掉 4 字节，因此在选项中最多只能指明 4 个字节块的边界信息。（4 * 2 * 4 = 32字节，另外两个字节是SACK选项字节和指明字节，指明这个选项要占有多少个字节。）
然而，SACK文档并没有指明发送方应当怎样响应SACK，因为大多数实现是重传所有未被确认的数据块。
流量控制
流量控制 (flow control) 就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。
利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。
可能发生死锁
B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。但这个报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。
为了解决这个问题，TCP 为每一个连接设有一个持续计时器 (persistence timer)。只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。
TCP报文发送时机
发送方糊涂窗口综合症：发送方 TCP 每次接收到一字节的数据后就发送。
Nagle 算法
- 若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。
- 当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。
- 只有在收到对前一个报文段的确认后才继续发送下一个报文段。
- 当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。
接收方糊涂窗口综合症：当接收方的 TCP 缓冲区已满，接收方会向发送方发送窗口大小为 0 的报文。
解决方法：让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。
