-
若发送方数据发送过快,接收方可能来不及接收,造成数据丢失。
-
流量控制
让发送方的发送速率不要太快,要让接收方来的及接收。 -
如何利用
滑动窗口
来实现对发送方的流量控制
发送方的发送窗口不能超过接收方给出的接收窗口的数值。
TCP的窗口单位
是字节,不是报文段。
A向B发送数据。
设每一个报文段是100字节长。数据报文段序号的初始值
设为1。大写ACK表示确认位
(连接建立后所有传送的报文段都必须把ACK置1),小写ack表示确认字段的值
。
连接建立时,B告诉A:我的接收窗口 rwnd
= 400。
接收方的主机B进行了3次流量控制:第一次把窗口减小到300,第二次减小到100,第三次减小到0即不允许A发送数据了。
这种使发送方暂停发送的状态
将持续到主机B重新发出一个新的窗口值
为止。
上图中,若B向A发送了零窗口的报文段
后不久,B的接收缓存又有了一些存储空间。于是B又向A发送了rwnd=400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知
,而B也一直等待A发送的数据。若没有其他措施,这种互相等待的死锁局面
将一直延续下去。
为解决上述问题,TCP为每个连接设有一个持续计时器
。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间
到期,就发送一个零窗口探测报文段 (仅携带一个字节的数据)
,而对方就在确认这个探测报文段时给出现在的窗口值。若窗口仍然是0,那么收到这个报文段的一方就重新设置持续计时器;若窗口不是0,那么死锁的僵局就打破了。 -
持续计时器
用于发送方TCP
收到零窗口大小通知
后的处理。
若接收方TCP
发出了窗口大小为0的报文段
,发送方TCP
就会停止传送报文段,直到接收方TCP
发送确认并给出一个非零的窗口大小。
但这个确认可能会丢失。
在TCP中,对于确认报文段
是不需要发送确认的。
若这个非零窗口大小的确认
丢失了,接收方TCP
无从得知,会一直等待发送方TCP发送数据;而发送方TCP
由于未收到次确认也会等待接收方TCP发送确认来通知接收窗口大小。
要打开这种死锁
,TCP为每一个连接
使用了一个持续计时器
。
当发送方TCP收到一个零窗口的确认
时,就会启动该连接的持续计时器
。当持续计时器期限到时,发送方TCP
就发送一个探测报文段
(此报文段只有一个字节的数据
,探测报文段的有一个序号,但这个序号不需要确认)。探测报文段
提醒接收方TCP:确认已丢失,请重传。
持续计时器的值
设置为重传时间的数值
。若第一个探测报文段
的持续计时器到期也未收到从接收方TCP的响应,那么需要发送另一个探测报文段
,并将持续计时器的值加倍和复位,知道这个值增大到门限值
(通常是60秒)为止。
此后发送端每隔60秒就发送一个探测报文段,直到窗口重新打开。
5.7.1 利用滑动窗口实现流量控制
最新推荐文章于 2023-02-04 16:50:51 发布