TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)

上一次我们知道了TCP协议通过连接管理机制保证可靠性,今天我们继续来看一看TCP协议中其他几种保证可靠性的方法。

· 确认应答机制
· 超时重传机制
· 流量控制
· 拥塞窗口

确认应答机制
在将这部分的内容之前我们应该首先知道的一点就是,在TCP中,TCP将每个字节的数据都进行了编号,即为序列号(对每一个数据的编号)
TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)_第1张图片
TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)_第2张图片
由图分析:当主机1给主机2发送了1~1000这么多数据时,主机2如果收到了就会给主机1应答(ACK报文段,每一个ACK都带有对应的确认序列号),表示你给我发的1~1000的数据我已经全部收到了(收到哪些数据),下次你再给我发就给我从1001数据开始发(下次从哪里开始发)。那么主机1收到应答之后就知道对方已经收到了1~1000的全部数据,所以再一次发送数据的时候他就会从1001开始发,后面都是依此类推的情况。

当然了,当我们的主机1给主机2发送了数据之后,经过一端时间主机1并没有收到主机2的应答的情况也是有的,所以这个时候为了确保数据的准确到达,TCP就有了超时重传机制。
超时重传机制
主机1没有收到主机2的确认应答有以下两种情况:
1、数据根本就没有传送到达主机2,因此主机2就不会回传一个确认应答的报文。
TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)_第3张图片
由图分析:主机1给主机2发送了数据,可能因为其他的原因数据无法到达主机2.(比如网络拥堵)。这个时候主机1等待了一个特定的时间间隔之后发现主机2还没有确认应答,于是就再一次将上一次的数据重新发送过去。

2、主机2收到了数据,也回传了确认应答报文,但是该报文丢失了。
TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)_第4张图片
由图分析:主机2收到了主机1发来的数据,但是发给主机1的确认应答并没有准时到达主机1,所以主机1也会因为没有收到确认应答而再次重新将数据发送过去。但实际情况却是我们的主机2第一次就已经收到了主机1的数据。但是主机1依旧会重发数据已确保主机2已经收到数据,从而进行下一次的数据转发。可想而知主机2就会收到很多的重复数据,但是重复的数据显然是不需要的,那么TCP协议就需要能够识别那些重复的数据并且要将冲符的数据丢弃掉,这个时候序列号就发挥他的一项作用了——去重。每一个数据都有自己的序列号,如果主机2收到重复的数据那么必然机会产生多个序列号相同的数据,那么序列号相同的数据就必然是重复的数据。

我们提到一个特定的时间间隔,这个时间又是如何规定的?

最理想的情况下,找到一个最小的时间保证确认应答一定能在这时间内返回
但是这个时间的长短,随着网络环境的不同,也是有差异的。
如果超时时间设得太长,会影响整体的重传效率
如果超时时间设的太短,有可能平凡的发送冲符的数据包。
TCP为了抱枕个无论在何种环境下都能比较高性能的通信,因此会动态计算这个最大超时时间:
Linux中,超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。
如果重发一次,任然得不到应答,就等待2*500ms后在进行重传
如果还得不到应答,等待4*500ms再重传,一次类推,以指数形式递增。
累积到一定的重传次数,TCP认为网络或者对端主机出现异常,就会强制关闭连接。

流量控制
接收端处理数据的速度是优先的,如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送就会造成丢包,继而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制就叫做流量控制。

接收端将自己可以接受的缓冲区大小放入TCP首部中的“窗口大小”字段,通过ACK段通知发送端;
窗口大小字段越大,说明网络的吞吐量越高
接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知发送端。
发送端接收到窗口大小以后,就会减慢自己的发送速度。
如果接收缓冲区满了,就会将窗口置为0,这时发送方不再发送数据。
但是需要定期的发送一个试探窗口,,目的是为了取探测数据段,是接收端把窗口大小告诉发送端。

TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)_第5张图片

接收端是如何把窗口大小告诉发送端的呢?现在,我们回过头去看一看,在上一篇博客中我们给出了TCP的报头格式,在TCP的首部中有一个16位的窗口大小的字段,就是存放的窗口大小的信息。另外在TCP的首部中的40字节选项中还包含了一个窗口扩大因子M,实际的窗口大小是窗口字段的值左移M位。

拥塞窗口
在后面会讲到TCP提高性能的滑动窗口,滑动窗口能够高效可靠的发送大量的数据,但是如果在一开始就发送大量的数据任然可能引发问题。要知道在网络上有很多的计算机,有可能当前的网络状态已经很拥堵,在不清楚当前的网络状态下,贸然发送大量的数据,这样对于已经很拥堵的网络来说无疑是雪上加霜。
由此,TCP引入了慢启动机制:先发送少量的数据,由此取探测当前的网络的拥堵状态,在决定按照多大的速度传输数据。
TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)_第6张图片

拥塞窗口:
发送开始的时候定义拥塞窗口大小为1
每当收到一个ACK应答以后拥塞窗口加1
每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小作比较,取较小值作为实际发送的窗口。
如图,拥塞窗口的增长速度呈指数形式增长,我们提到说慢启动,只是说出事的时候慢而已,但是增长速度非常的快。为了增长的不呢么快,因此我们不能让拥塞窗口单纯的加倍,这里引入一个慢启动的阈值,当同色窗口超过这个阈值的时候,不再按照指数方式增长,而是改为按照线性的方式增长。
当TCP开始启动的时候,慢启动阈值等于窗口最大值,在每次超时重发的时候,慢启动阈值会变成原来的一半,同时拥塞窗口置为1。

少量的丢包,仅仅只会触发超时重传,而大量的丢包就认为是网络拥堵,当TCP通信开始后,网络吞吐量会逐渐的上升,随着网络发生拥堵,吞吐量会立刻下降,拥塞控制说到底就是TCP协议想尽可能快的将数据传输给对方,但又要避免给网络造成太大的压力的折中解决办法。

至此,TCP协议保证可靠性的极大机制我们已经全部学习完成。
总结一下:
为了确保可靠的数据传输,TCP协议通过连接管理机制,确认应答机制,流量控制以及拥塞控制这些方法让可靠性得以很大程度上的保证,另外,序列号保证了数据的按序到达,就知道哪些数据已经收到,那些没有收到需要重传。而校验和通过CRC校验,如果接收端校验不通过则认为数据有问题,此举也保证了数据的可靠性传输。

你可能感兴趣的:(传输层,tcp协议,网络)