运输层(6.TCP的流量控制)

一、利用滑动窗口实现流量控制

        所谓流量控制就是让发送方发送速率不要太快,要让接收方来得及接收

        利用窗口滑动机制很容易实现流量控制。

在建立连接时,B告诉A他的接收窗口是400。

死锁:

        B 向 A 发送了零窗口的报文段后不久,B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。

但这个报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知,而 B 也一直等待 A 发送的数据。

        如果没有其他措施,这种互相等待的死锁局面将一直延续下去。

        为了解决这个问题,TCP 为每一个连接设有一个持续计时器

持续计时器:

        只要 TCP 连接的一方收到对方的零窗口通知,就启动该持续计时器

        若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带 1 字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值。

        若窗口仍然是零,则收到这个报文段的一方就重新设置持续计时器。 若窗口不是零,则死锁的僵局就可以打破了。

二、TCP传输效率

        应用进程把数据传输到TCP发送缓存后,剩下的任务就由TCP来完成。

使用不同机制决定发送TCP报文的时机:

        第一种机制是 TCP 维持一个变量,它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时,就组装成一个 TCP 报文段发送出去。

        第二种机制是由发送方的应用进程指明要求发送报文段,即 TCP 支持的推送 (push)操作。

        第三种机制是发送方的一个计时器期限到了,这时就把当前已有的缓存数据装入报文段(但长度不能超过 MSS)发送出去。

Nagel算法:

        发送方 TCP 每次接收到一字节的数据后就发送。

        这样,发送一个字节需要形成 41 字节长的 IP 数据报。若接收方确认,并回送这一字节,就需传送总长度为 162 字节共 4 个报文段。效率很低。

        解决方法就是Nagel算法。

算法内容:

        若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存,则发送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。

        当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继续对随后到达的数据进行缓存。

        只有在收到对前一个报文段的确认后才继续发送下一个报文段。

        当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时,就立即发送一个报文段。

糊涂窗口综合征:

        当接收方的 TCP 缓冲区已满,接收方会向发送方发送窗口大小为 0 的报文。

        若此时接收方的应用进程以交互方式每次只读取一个字节,于是接收方又发送窗口大小为一个字节的更新报文,发送方应邀发送一个字节的数据(发送的 IP 数据报是 41 字节长),于是接收窗口又满了,如此循环往复。

解决方法:

        让接收方等待一段时间,使得或者接收缓存已有足够空间容纳一个最长的报文段,或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一,接收方就发出确认报文,并向发送方通知当前的窗口大小。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值