TCP连接管理机制-确认应答,超时重传,滑动窗口,拥塞控制,流量控制,延迟应答

TCP通过确认应答和超时重传可以保证数据可靠传输

使用滑动窗口完成流量控制和拥塞控制

使用延迟应答来保证滑动窗口足够大

接下来对这些机制进行详细的介绍

确认应答(ACK)机制

TCP将每个字节的数据都设置了序列号,每一个ACK都带有对应的确认序列号,告诉发送者,我收到了数据,你下一次应该从哪一个序列号开始发

超时重传机制

当主机A向主机B发送的数据发生丢包,无法到达主机B时,主机A在一段时间内没有收到主机B的确认应答,就会进行重发

超时时间的确认:

Linux中,超时以500ms为一个单位进行控制每次判定超时重发的时间都是500ms的整数倍

如果重发一次后,仍然得不到应答,经过2*500ms后重新发送

以此类推,以指数的形式增长,累计到一定的重传次数,TCP会强制关闭连接

滑动窗口

在确认应答中,对每一个发送的数据段,都要有一个ACK应答,收到ACK应答后才能再发送下一个数据段,这样做性能较差。

于是TCP采用滑动窗口机制一次发送多条数据,将多个段的等待时间重叠在一起来提高性能

 

滑动窗口的大小就是无需等待确认应答可以持续发送的数据的大小,上图中的窗口大小为4000

当收到第一个确认应答后,窗口后移继续发送第五个段的数据,以此类推

操作系统内核为了维护滑动窗口,开辟了一个缓冲区来记录当前还有那些数据没有做出应答,只有应答了之后才会从缓冲区里删除掉

丢包的两种情况:

  • ACK丢失:部分ACK丢失,不要紧,可以通过后序的ACK进行确认
  • 数据包丢失:
    • 假如上图中1001~2000的数据段丢失,主机B会不断的给主机A发送ACK=1001的回复,当主机A连续三次收到ACK=1001的回复后,会重新发送1001~2000的数据段,再次返回的就是7001了(因为2001-7000)接收端之前就已经收到了,只是被放到接收缓冲区中了。

流量控制

接收端处理数据的速度有限,如果发送端发送数据太快,导致接收缓冲区满了,如果发送端再进行发送数据,就会造成丢包

所以TCP支持根据接收端的处理能力来决定发送端的发送速度,也就是流量控制

  • 接收端将自己的缓冲区大小放入TCP首部中的“窗口大小”字段,通过ACK告诉发送端;
  • 窗口越大,说明网络的吞吐量越高
  • 接收端发现自己的缓冲区快满的时候,就会减小窗口的大小,当发送端接收到这个消息后也会降低自己的发送速度
  • 当接收端的缓冲区满了之后,接收端会将窗口大小设置为0,这时发送端就不会再发送数据了,但是它会定期发送一个窗口探测数据段来获取接收端的窗口大小

拥塞控制

同一时间可能有多人上网,造成网络拥堵,如果此时滑动窗口在开始阶段就发送大量的数据同样有可能出现问题

TCP引入慢启动机制,先发少量的数据,探探路,摸清网络当前的拥堵状态,再决定按照多大的速度传输,此时就引入了拥塞窗口这个概念

  • 刚开始将拥塞窗口置为1
  • 每接收到一个ACK,拥塞窗口加1
  • 每次发送数据时,将拥塞窗口与接收端反馈的缓冲区窗口作比较,选择较小的窗口传输
  • 拥塞窗口的增长是指数级增长,为了不让增长的太快,引入一个慢启动的阈值
  • 当拥塞窗口按指数级增长超过阈值时,就以线性方式增长
  • 当TCP开始启动的时候,慢启动阈值等于窗口最大值
  • 在每次超时重发的时候,阈值会变成原来的一半,拥塞窗口重新置为1

少量的丢包,仅仅是触发超时重传,但是当大量的丢包时就是网络拥塞

拥塞控制归根结底是想尽可能快的把数据发送给对方,但又避免造成网络拥堵

延迟应答

如果接受数据的主机立刻返回ACK应答,这时返回的窗口可能比较小

接收端处理数据的速度很快,可能很快就处理完缓冲区的数据,接收端稍微迟一会儿作出应答,完全可以给发送端返回一个更大的窗口发送数据。

窗口越大,网络吞吐量就越大,传输效率就会提高

但是也并不是所有的包都需要延时应答,一般每隔2个包就应答一次,超过最大延迟时间就应答一次(一般取200ms)

捎带应答

在延迟应答的基础上,很多情况下,客户端服务器在应用层也是“一发一收的”,这时ACK就可以搭顺风车和服务器回应的消息一起发给客户端

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值