zoukankan      html  css  js  c++  java
  • TCP流量控制

    TCP的流量控制,是为了更好的传输数据,控制流量不要发送太快而至于接收端没有足够的缓存的接收。

    利用滑动窗口,可以很方便的控制传输

    rwnd:可以控制接收窗口大小。ACK代表确认位,ack代表确认字段的值。 rwnd是递减趋势。并且只有ACK设置了字段1,小写字段ack才有意义。

    死锁的概念,B的接收窗口rwnd 成了0 ,当B已经完成应用程序数据的交接,已经有空出了的缓存窗口,而传出去的rwnd 可用数据消失。就属于死锁状态。

    这就需要发送端有一个持续计数器,到达一定时间就去询问是否有空闲窗口。如果窗口不是0,那么死锁窗口。

    网络拥塞引起的重传并不会缓解网络拥塞,反而会加剧网络的拥塞。

    所谓拥塞控制就是防止过多的网络数据传到网上去。

    吞吐量和提供负载以及有拥塞控制图

    网络拥塞控制分为开环控制、闭环控制。

    开环控制:将所有的因素都提前考虑到,力求网络在工作时不产生拥塞。

    闭环控制:运行时保存用拥塞信息并进行处理。

    四种拥塞控制方法,慢开始,拥塞避免,快重传,快恢复。

    慢开始:先采取1倍MSS,2倍MSS 相对于一下传输很多,所以是慢开始传输控制。提出一个慢开始门限  ssthresh

    当cwnd<ssthresh 启用慢开始算法,  当cwnd>ssthresh 启用拥塞避让算法。

    路由器重新采取最大门限最小门限来随机采取丢弃,这样就就能避免全部PC进入拥塞状态。

    设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说"我Client端没有数据要发给你了",但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以你先发送ACK,"告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。当Server端确定数据已发送完成,则向Client端发送FIN报文,"告诉Client端,好了,我这边数据发完了,准备好关闭连接了"。Client端收到FIN报文后,"就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!

    【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
    答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

    【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

    答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

  • 相关阅读:
    TCP四种计时器
    TCP滑动窗口机制的简洁模型
    JAVA安全模型
    MongoDB性能优化
    mysql权限管理
    一个类似抖音 APP 拍摄按钮效果的控件
    App 组件化/模块化之路——使用SDK的思路进行模块化设计接口
    在 Android 中如何优雅地配置私密信息
    在Android中使用枚举注解而不是枚举
    Android 组件化/模块化之路——在展示层搭建MVP结构
  • 原文地址:https://www.cnblogs.com/harmmag/p/6733540.html
Copyright © 2011-2022 走看看