Tcp协议保证可靠传输机制

我们知道TCP是传输控制协议,面向连接,保证数据可靠传输的。UDP是用户数据报协议,尽最大能力交付。那么TCP是如何保证数据的可靠传递的呢?

TCP保证可靠数据传输的方式:

1. 数据包检验

2. 超时重传机制

3. 确认应答机制

4. 对失序数据包重排序

5. TCP的流量控制与拥塞控制

首先先看下TCP首部格式(TCP首部最少20字节):


一、数据包检验过程:

TCP首部有检验和字段,通过计算比较检验和判断TCP数据包是否在传输过程中发生了改变。

计算方法:

对于发送方,由12个字节的伪首部+TCP报文段(TCP首部+数据)组成原始数据。之后按照每16位按位取反求他们的和,之后对这个和再取反生成最后的结果B,将最后的结果B放在检验和字段中。

对于接收方,由12个字节的伪首部+TCP报文段(TCP首部+数据)组成接收数据,按照每16位按位取反求和(不包括检验和字段),得到一个结果A,之后判断A+B的二进制和是否全为1,如果都是1说明数据无差错;不为1,说明数据有错,丢弃。

二、应答机制:

发送方每发送一个TCP报文段,接收方收到之后就会返回一个确认TCP报文段

1.TCP首部中序号字段表示当前TCP报文段的序号,该序号为当前TCP数据中第一个字节的序号(TCP中每个字节数据都标记了序号)

2. TCP首部中确认序号字段表示接收方TCP期望下个接收的报文段序号

3. TCP采用“累计确认”(B收到A的0-2,5-7序号段,那么B的确认TCP报文段中的确认序号为3)

三、重传 

导致重传的事件有两种:超时和冗余ACK

1. 超时重传:

TCP每发一个报文段就会对报文段设置一次计时器,时间到期但是还没有收到确认,代表该TCP在传输过程   中丢失,则重传。(时间设置采用自适应算法)

2. 冗余ACK:

超时存在等待事件过长的缺点,冗余ACK就是再次确认某个报文段的ACK,TCP规定每当比期望序号大的失    序报文到达时,发送一个冗余ACK报文,指明下一个期望的TCP段序号。当发送方收到3个对同一报文的确认    ACK报文时,就认为被确认的报文段之后的的报文丢失,则开始重传(属于快速重传)

四、TCP流量控制

讲TCP流量控制之前,需要先看下什么是滑动窗口,理解滑动窗口机制是理解流量控制的前提。

     滑动窗口协议


     关于这部分自己不晓得怎么叙述才好,因为理解的部分更多,下面就用自己的理解来介绍下TCP的精髓:滑动窗口协议。
     所谓滑动窗口协议,自己理解有两点:

1. “窗口”对应的是一段可以被发送者发送的字节序列,其连续的范围称之为“窗口”;

2. “滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的,方式就是按顺序“滑动”。在引入一个例子来说这       个协议之前,我觉得很有必要先了解以下前提:
-1. TCP协议的两端分别为发送者A和接收者B,由于是全双工协议,因此A和B应该分别维护着一个独立的发送缓冲区和接收                       缓冲区,由于对等性(A发B收和B发A收),我们以A发送B接收的情况作为例子;
-2. 发送窗口是发送缓存中的一部分,是可以被TCP协议发送的那部分,其实应用层需要发送的所有数据都被放进了发送者                         的发送缓冲区;
-3. 发送窗口中相关的有四个概念:已发送并收到确认的数据(不再发送窗口和发送缓冲区之内)、已发送但未收到确认的                       数据(位于发送窗口之中)、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据;
-4. 每次成功发送数据之后,发送窗口就会在发送缓冲区中按顺序移动,将新的数据包含到窗口中准备发送;
                      TCP建立连接的初始,B会告诉A自己的接收窗口大小,比如为‘20’:
     

字节31-50为发送窗口

     A发送11个字节后,发送窗口位置不变,B接收到了乱序的数据分组:

     只有当A成功发送了数据,即发送的数据得到了B的确认之后,才会移动滑动窗口离开已发送的数据;同时B则确认连续的数据分组,对于乱序的分组则先接收下来,避免网络重复传递:



流量控制

     流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制;二是如何考虑流量控制中的传输效率。
1. 流量控制
     所谓流量控制,主要是接收方传递信息给发送方,使其不要发送数据太快,是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小,并且利用大小来控制发送方的数据发送:

     这里面涉及到一种情况,如果B已经告诉A自己的缓冲区已满,于是A停止发送数据;等待一段时间后,B的缓冲区出现了富余,于是给A发送报文告诉A我的rwnd大小为400,但是这个报文不幸丢失了,于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题,TCP引入了持续计时器(Persistence timer),当A收到对方的零窗口通知时,就启用该计时器,时间到则发送一个1字节的探测报文,对方会在此时回应自身的接收窗口大小,如果结果仍未0,则重设持续计时器,继续等待。
2. 传递效率
     一个显而易见的问题是:单个发送字节单个确认,和窗口有一个空余即通知发送方发送一个字节,无疑增加了网络中的许多不必要的报文(请想想为了一个字节数据而添加的40字节头部吧!),所以我们的原则是尽可能一次多发送几个字节,或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法,即:
*1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存,则发送方就把第一个数据字节先发送出去,把后面的字节先缓存起来;
*2. 当发送方收到第一个字节的确认后(也得到了网络情况和对方的接收窗口大小),再把缓冲区的剩余字节组成合适大小的报文发送出去;
*3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时,就立即发送一个报文段;
     对于后者我们往往的做法是让接收方等待一段时间,或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候,再通知发送方发送数据。


五、拥塞控制

     网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限,当网络的需求超过它们的工作极限时,就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。常用的方法就是:
1. 慢开始、拥塞控制
2. 快重传、快恢复
     一切的基础还是慢开始,这种方法的思路是这样的:
-1. 发送方维持一个叫做“拥塞窗口”的变量,该变量和接收端口共同决定了发送者的发送窗口;
-2. 当主机开始发送数据时,避免一下子将大量字节注入到网络,造成或者增加拥塞,选择发送一个1字节的试探报文;
-3. 当收到第一个字节的数据的确认后,就发送2个字节的报文;
-4. 若再次收到2个字节的确认,则发送4个字节,依次递增2的指数级;
-5. 最后会达到一个提前预设的“慢开始门限”,比如24,即一次发送了24个分组,此时遵循下面的条件判定:
*1. cwnd < ssthresh, 继续使用慢开始算法;
*2. cwnd > ssthresh,停止使用慢开始算法,改用拥塞避免算法;
*3. cwnd = ssthresh,既可以使用慢开始算法,也可以使用拥塞避免算法;
-6. 所谓拥塞避免算法就是:每经过一个往返时间RTT就把发送方的拥塞窗口+1,即让拥塞窗口缓慢地增大,按照线性规律增长;
-7. 当出现网络拥塞,比如丢包时,将慢开始门限设为原先的一半,然后将cwnd设为1,执行慢开始算法(较低的起点,指数级增长);

     上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用,而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间,从而避免传递无用的数据到网络。快重传的机制是:
-1. 接收方建立这样的机制,如果一个包丢失,则对后续的包继续发送针对该包的重传请求;
-2. 一旦发送方接收到三个一样的确认,就知道该包之后出现了错误,立刻重传该包;
-3. 此时发送方开始执行“快恢复”算法:
*1. 慢开始门限减半(新门限阀值 == 当前发送窗口的一半);
*2. cwnd设为慢开始门限减半后的数值;
*3. 执行拥塞避免算法(高起点,线性增长);


流量控制和拥塞控制的区别:

拥塞控制是让网络能够承受现有的网络负荷,从全局的角度来避免网络拥塞。

流量控制是针对传输接收数据的两端而言的,主要是抑制发送端过快的发送数据包导致接收端无法快速消化。

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值