计算机网络（5.8）运输层- 以字节为单位的滑动窗口

TCP的滑动窗口是以字节为单位的。现假定A收到了B发来的确认报文段，其中窗口是20字节，而确认号是31（这表明B 期望收到的下 一个序号是31，而序号30为止的数据已经收到 了）。 根据这两个数据，A就构造出自己的发送窗口。

根据B给出的窗口值，A构造出自己的发送窗口。

发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。

A 发送了11个字节的数据：

P3 – P1 = A 的发送窗口（又称为通知窗口）

P2 – P1 = 已发送但尚未收到确认的字节数

P3 – P2 = 允许发送但尚未发送的字节数（又称为可用窗口）

A 收到新的确认号，发送窗口向前滑动。

A 的发送窗口内的序号都已用完， 但还没有再收到确认，必须停止发送。

发送方的应用进程把字节流写入TCP 的发送缓存。

接收方的应用进程从TCP 的接收缓存中读取字节流。

发送缓存用来暂时存放：发送应用程序传送给发送方TCP准备发送的数据； TCP已发送出但尚未收到确认的数据。

接收缓存用来暂时存放：按序到达的、但尚未被接收应用程序读取的数据； 不按序到达的数据。

第一，A的发送窗口并不总是和B的接收窗口一样大（因为有一定的时间滞后）。第二，TCP标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。 第三，TCP要求接收方必须有累积确认的功能，这 样可以减小传输开销。

接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。

但请注意两点：第一，接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。确认推迟 时间不超过0.5秒。

第二，捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。因TCP的通信是全双工通信。通信中的每一方都在发送和接收报文，都有发送和接收窗口。因此一定要确定是哪一方的窗口。