以字节流为单位的滑动窗口
- 1.rwnd =20 发送窗口大小
- 2.ack 确认报文
- 3.主机在没有收到确认的情况下可以把发送窗口内的数据都发送出去
发送窗口的后沿移动情况
- 1.不动(没有收到新的确认)
- 2.前移(收到了新的确认)
发送窗口前沿的移动情况
- 1.通常是不断向前移动的
- 2.不动
- 没有收到新的确认,对方通知的窗口大小也没有改变
- 收到了新的确认但对方通知的窗口缩小了,使得发送窗口前沿刚好不动
- 向后收缩(对方通知的窗口缩小了,TCP不推荐这样做,因为很可能数据已经发送,还在路上,就会产生错误)
字节流示意图
如何描述发送窗口的状态
如图所示 使用三个指针P1\P2\P3分别指向相应的字节序号
- 小于p1的是已发送并已收到确认的部分.
- 大于等于P3的是不允许发送的部分
- P3 - P1 = 发送的窗口尺寸
- P2 - P1 = 已发送但是未收到确认的字节数.
- P3 - P2 = 允许发送,但是未发送的字节数(又称为可用窗口或有效窗口)
虽然发送方的发送窗口是根据接收方的接收窗口设置的,但在同一时刻,发送方的发送窗口并不总是和接收方的接收窗口一样大.
- 网络传送窗口值需要经历一定的时间滞后,并且这个时间还是不确定的
- 发送方还能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸.
对于不按序到达的数据应如何处理,TCP并无明确的规定.
- 如果接收方把不按序到达的数据一律丢弃,那么接收窗口的管理将会比较简单,但是这样做对网络资源的利用不利,因为发送方会重复传送较多的数据.
- TCp通常对不按时到达的数据先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层应用进程.
TCP要求接收方必须有累计确认和稍待确认机制 ,这样可以减小传输开销.接收方可以在合适的时候发送确认,也可以在自己有数据要发送的时候把确认信息顺带捎上.
- 接收方不应过分推迟发送确认,否则会导致发送方不必要的超时重传,这反而浪费了网络资源.
- 1.TCp标准规定,确认推迟的时间不应超过0.5秒,若收到一连串具有最大长度的报文,则必须每隔一个报文段就发送一个确认[RFC 1122].
- 2.稍待确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据.
TCP的通信是全双工的.通信中的每一方都在发送和接收报文片段.因此,每一方都有自己的发送窗口和接收窗口.在谈到窗口的时候,一定要弄清楚哪一方的窗口.
