TCP的可靠传输実现

累积确认方式：

接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。

优点：容易实现，即使确认丢失也不必重传。

缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。

以字节为单位的滑动窗口

设发送方是A，接收方是B。

在没有收到B的确认情况下，A可以连续把窗口内的数据都发送出去。凡是 已发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

A的发送窗口一定不能超过B的接收窗口数值。

发送方的发送窗口大小还要受到当时网络拥塞程度的制约。

发送窗口后沿的后面部分表示已发送且已收到了确认。不需要再保留这些数据了。 发送窗口后沿不可能向后移动，因为不能撤销已收到的确认。发送窗口前沿通常是不断向前移动的，但也有可能不动，这对应于2种情况：①没有收到新的确认；②收到了新确认，但对方通知的窗口缩小了，使得发送窗口前沿正好不动。

TCP标准强烈不赞成发送窗口向后收缩。

A发送的数据若没有得到B的确认，为了保证可靠传输，A只能认为B还没有收到这些数据。则，A经过一段时间（由超时计时器来控制的）就重传这部分数据 ， 重置超时计时器，直到B的确认为止。如果A收到的确认号落在发送窗口内，那么A就可以使发送窗口继续向前滑动，并发送新的数据。

如果收到的分组被检测出有差错，则要丢弃。若接收应用程序来不及读取收到的数据，接收缓存最终会被填满，使得接收窗口减小到零。反之，若接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。

由以上所讨论，还要强调以下3点：

一、虽然A的发送窗口是根据B的接收窗口设置的，但于同一时刻，A的发送窗口并不总与B之接收窗口一致大。这是因为通过网络传送窗口值需要经历一定时间滞后（这个时间还是不确定的）。另外，发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。

二、对于不按序到达的数据应如何处理，TCP标准并无明确规定。 通常为了提高网络资源的利用率，TCP对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到以后，再按序交付上层应用程序。

三、TCP要求接收方必须有累积确认的功能，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便 捎带。但请注意两点：一是接收方不应过分推迟发送确认，否则会导致 发送方不必要的重传，这反而浪费了网络资源。TCP标准规定，确认推迟的时间不超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。二是捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

        最后再强调一下，TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，须一定要弄清楚是哪一方的窗口。